при отключении/включении питания происходит изменение содержимого EEPROM в tiny26... было предположение, что на одном из входов АЦП в этот момент присутствует отрицательное напряжение, поставил диод - не помогло. где искать причину?

Добрый вечер.
Не знаю как в tiny26 но в Мега 16, 32 первая ячейка EEPROM может измениться при включении/выключении источника питания.
Поэтому там советуют не хранить информацию.

А BOD включен? Если нет, то именно эти проблемы и проявляются.

и BOD не включен, и данные изменяются именно в 1-й ячейке, в остальных вроде нормально все... уже большое спасибо!
могут быть еще какие-то варианты?

Я немного уточню. Изменяется не совсем первая ячейка, изменяетса ячейка, на которую указывает EEAR. (К стати, было бы более правильно говорить не о первой ячейке, а о байте, находящемуся по адресу 0х00 -- нулевом байте.) Поскольку при включении в EEAR заносится нулевай адрес, то получается, что повреждается содержимое именно нулевого байта.

В свое время у меня так колбасило AT90S2313. Потом TINY2313. Причем, прога записью в EEPROM не занималась вообще, только читала. А через некоторое время я где-то прочитал про этот глюк. (Уже я не помню где, не важно.) Там рекомендовали не использовать нулевой байт. Но мой бывший работодатель -- парень, которого еще поискать надо -- умудрался портить и последующие байты. Как он подключал мои девайсы, это отдельная песня. Сноп искр! Свидетелей выносили ногами вперед... После чего, я решил, что после любых операций с EEPROM, в EEAR записывать нулевой адрес. Ну и, разумеется, нулевой байт не использовать вообще. После этого глюков больше не наблюдалось.

Странно, я думал, АТМЕЛ уже давно победил этот глюк.

Как бы да. Рекомендовав либо включать внутренний супервизор, либо использовать внешний. Но: - Грррр шмяк... - сказала японская лесопилка.
- Ну дык, еб тыть! - сказали суровые русские мужики и пошли валить лес двуручными пилами.

Еще как есть. Вот когда решите все эти детские проблемы, останется одна взрослая - на всё время цикла записи в EEPROM нужно гарантированно поддерживать Vdd хотя бы в пределах допустимого минимума. Ни BOR, ни внешний супервизор сами по себе тут не помогут.

цикл записи в EEPROM у меня происходит по нажатию кнопки, так что если пользователь не решит одновременно с записью отключить питание, то эта проблема не должна по идее проявиться... спасибо!
кстати видимо и BOD тут не при чем, скорее всего проблема именно в том, что модифицируется только нулевая ячейка... так что в японской бензопиле просто бензин кончился

Проблема стара как AVR, IAR, например, давным давно не использует 0-ую ячейку ЕЕПРОМ за счет настроек XCL файлов. Сам Атмел рекомендует внешний супервизор, либо БОД для относительно новых моделей.

Просто поверьте/запомните, что при использовании EEPROM хотя бы на чтение нужно снабдить контроллер каким-либо супервизором питания (внутренним или внешним - это уже от задачи).
Без этого, как уже отметили, может запороться та ячейка EEPROM, на которую смотрит регистр адреса в момент просада питания.
Частичное решение проблемы при неприятии супервизоров по религиозным мотивам:
- не обращаться к EEPROM во первых строках программы (делайте таймаут на время установления напряжения(-ий) питания контроллера);
- по завершению работы с EEPROM устанавливать регистр адреса на неиспользуемый адрес.

Заметьте, что я нигде не упомянул AVR ввиду универсальности проблемы и ее решения.

все понятно... спасибо за ответы! я и запись в нулевую ячейку убрал, и BOD включил - пока все нормально

Да, вот ещё есть малые сапёрные грабли (те, что по пояс ). На время записи в EEPROM лучше будет запретить прерывания, если конечно они используются. Как-то я очень весело провёл почти сутки в поисках сбоев процесса калибровки прибора по этой причине.

да, прерывания запрещены... в принципе я вроде как решил этот вопрос, сначала перестал использовать нулевой байт - ситуация улучшилась, но в конце концов сбой поймал-таки, потом BOD включил и пока все нормально... спасибо большое!

в 16 меге ЕЕПРОМ слетала при сбоях питания и при внутреннем, и при внешнем визоре, причем портилась не только 0-вая ячейка. питание было сильно шумным и побороть этот шум не удавалось, пришлось ставить внешнюю память

тоже изредка наблюдается у меги 8 в моём
проекте...
питание от USB. Слетает вся память полностью...
МК пишет/читает епром по требованию от ПК.
сам МК в неё не лезет... чтение епрома сильно не часты...

На все время записи ?
ИМХО, это ерунда, запрещать нужно только на время спецпоследовательности запуска записи,
иначе 1,8-8,5мс (зависит от чипа) прога не может ничем заниматься,
запрещение прерывания на все время записи это костыль который скрывает ошибки в
проектировании проги.

Прерывание можно использовать для ЕЕПРОМА

наверное Вы правы... главное проверить в подпрограмме обработки прерывания завершилась ли предыдущая запись (если надо что-то писать), а так прерывание не должно повлиять на результат записи... может он не это имел ввиду?

Да, именно так, проверили и если еще не закончилась ушли заниматься другими делами...
Если запрос на запись возникает спонтанно(те в практически в любой момент времени),
тогда нужно организовать очередь из запросов.
Не должно ни разу, проблемы могут быть только если очень часто пишем и очередь
образовалась внушительная, типа если в одной и той же еще необработанной очереди может
попасться две записи одного данного...

Это стопудовый программный хомут. У меня серийное изделие выпускается на м8 с питанием от USB. Перед ним стаял комплект из м8515+т2313 ну и так далее. Конфигурация этого прибора хранится в EEPROM. Причём так, что с вероятностью близкой к 100% если запортится, то изделие ко мне вернётся. И так уже много лет. Ну нет проблем! Просто нет. Единицы тысяч изделий.

Аналогичная ситуация и именно с тини26
Слетают ячейки еепром то ли по включению, то ли по выключению - естественно, выяснить не удалось.
Все что выше советовалось, пробовал - вопрос в статистике.
собрал автомат - клацалку с периодом в 10 секунд. Более 2-х суток не выдерживала никакая идея.
Что помогло:
Значений мне надо сохраниять немного.
Каждое значение сохранил в 3-х местах.
По включению сравниваю считанные. Если 2 значения равны между собой, записываю его в 3-ю ячейку.
вылетов одновременно 2-х ячеек, относящихся к одной переменной, пока не наблюдалось (клацанье пошло уже на вторую неделю).

мажорирование вещь хорошая, конечно, но вылет и 2-х ячеек дело времени... Вы знаете, у меня после включения BOD нормально все работает.

Да BOR-то включен...
Я понимаю, 2 ячейки тоже вопрос времени. Но надеюсь, что время будет достаточно большим.
Но все остаьные меры, что я пробовал, существенно ситуацию не улучшали

может быть надо питание посмотреть в момент включения/выключения? может быть время ресета увеличить? что-то не то... надо причину найти, наверное, а не с последствиями бороться...

Верю, что причину найти было бы лучше.
Прблема,что сбои слишком редкие.
Проверка каждой идеи - день-два прогона.
Долбался, долбался, да и решил устранить последствие

а регистр адреса EEPROM тоже пробовали устанавливать на неиспользуемый адрес после записи, как советовали выше?
эта ошибка одного кристалла или системная для tiny26?

проверял на 3-х кристаллах. может партия неудачная. 0735
записывал сразу пакет из 6 байтов данных. после выключения-включения иногда один из битов может изменить состояние из 0 в 1.
расположение бита по этим 6 байтам произвольное. Поэтому думаю, что прямой связи адреса ЕЕПРОМ и потерянного данного нет. Кстати, ячейка с адресом, на который указывал регистр, портилась, пожалуй, пореже остальных...

да... засада... не знаю, как у вас, а у меня прибор, в котором я использую tiny, скважинный и доступа к нему во время работы нет... поэтому и понять, что с ним происходит, невозможно... если будет проявляться такой эффект, то он будет просто гнать наверх ложную телеметрию...

В одном из изделий у меня слетала EEPROM на некоторых изделиях. Причина проста. Изделие работало от 14745600 на 3.3V. BOD, согласно документа, выставлен на 2.7V. Скорее всего сбой происходит либо в момент включения либо выключения (нарастания либо спада) при напряжении граничном с BOD. Перевод изделия на 11059200 полностью устранил проблему.

Мои рекомендации таковы. Увеличьте скорость нарастания/спада питания источника. Выберите частоту контроллера согласно даташиту при выбранном напряжении BOD. Борьба с последствиями - сможет уменьшить вероятность возникновения, но проблему не устранит. Если процессор молотит неправильно, то он может запортить любую инфу. Даже на внешнем носителе информации.

Overclock все равно остался ;>

Как-то по недосмотру зашили BOD 2.7В (вместо 4.0В) в партию девайсов (100 шт) с питанием 5В и частотой 11.0592. В девайсах есть особенность - быстрое нарастание и очень медленный спад питания.
В одном из девайсом слетел блок eeprom через месяц работы причем слетел "по-взрослому", CRC8 проверка выдала "Ok" в, то время как данные запортились напрочь. В остальных 99 устройствах слетов не наблюдалось.

Мораль байки:
Atmel гарантирует работу на частотах до 8Mhz с питанием 2.7В, для частот выше 8Mhz и питании ниже 3В есть риск и неопределенность.

Я это понимаю. Но там уже выхода не было. А в новых переделали сделали два питания. На контроллер 5V.


PS: Кстати один раз помню засаживали питание для быстрого спада.

Не нашел, упоминался ли еще один момент.
Фуз размаха генератора обязательно выставлять на полный размах. В противном случае генератор легко сбивается и EEPROM улетает.
А CRC в EEPROM непонятно зачем нужен, поскольку сбой происходит переходом на ПП записи и вероятность записи правильного CRC и непонятных данных велика при сбое, а постоянные данные лучше хранить во флеше.

???
может я чего-то не понимаю? а откуда сбой знает адрес ПП записи? или вы хотите сказать, что при сбое в счетчик команд загружается случайное значение? но тогда были бы и зависания, и прочие несанкционированные действия...

В первом посте было про вкл/выкл. Какие еще возможны видимые действия за несколько первых/последних мс.
Неоднократно пробовал выкинуть команды записи в EEPROM и сбои уходили . Ну ничем не собьешь. Только повышением напряжения до 9В
В малополезности CRC EEPROM убеждался на чужих примерах, когда проверка CRC проходит, а данные странные. Это дополнительно говорит о сбое PC. Несколько помогало при борьбе с хилым генератором 90S2313 разнесение установки разрешения записи и собственно записи. Но на мегах таких проблем с полным размахом генератора нет.

ну может быть... правда только если речь идет о сбое при выключении, т.к. при сбое в момент включения все-таки видимые действия скорее всего проявились бы (конечно все зависит от того, что делает ПО)... у меня, во всяком случае, точно...