eeprom в atmega8

[EKuzmich]

Добрый день. У меня проблема, запутался в 3-х соснах. Может ли при отключении устройства на базе mega8 изменяться содержимое eeprom и если да то что необходимо предпринять для предотвращения этого?

[urry]

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

[SasaVitebsk]

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

Если правильно написана программа, установлен BOD (это обязательно), то EEPROM портится не должен. Если он портится, то это ни чем не уберёшь. Никакими CRC. Отнеситесь также внимательно к источнику.

[E97]

Нарушается содержимое EEPROM если микроконтроллер работает при пониженном напряжении. Для сброса контролерра при снижении напряжения в ATmega предусмотрен встроенный супервизор питания BOD для того чтобы он работал нужно установить фюз BODEN.
Но чтобы полностью обезопасится от несанкционированного изменения EEPROM нужно делать выдержку времени 100мкс после выхода из спящего режима до обращения к EEPROM. Дело в том что схема BOD отключается при входе в режимы Extended Standby, Standby, Power Save и Power Down для экономии электропотребления. А включается не сразу при входе в рабочий режим.

[urry]

Выпускали тысячи устройств на м8, да и других тоже. Если меняется EEPROM, то очень велика вероятность неработоспособности устр-в. Возвратов по этой причине не наблюдали.
Если правильно написана программа, установлен BOD (это обязательно), то EEPROM портится не должен. Если он портится, то это ни чем не уберёшь. Никакими CRC. Отнеситесь также внимательно к источнику.

Вы большой оптимист. Помнится, несколько лет назад продвинутый заказчик тестировал устройство, втыкая дроссель помощнее последовательно в 220 вольт, один конец - к корпусу моего устройства и на напильник. Второй вывод на отвертку и отверткой водил по напильнику.
Впрочем, не навязываю, но лично я всегда прописываю одну и ту же инфу в 3 местах и закрываю КС. Кстати, спасает.

[kison]

Впрочем, не навязываю, но лично я всегда прописываю одну и ту же инфу в 3 местах и закрываю КС. Кстати, спасает.

Ну так и правильно делаете. BOD не панацея - он спасает только от хаотической записи в случайные ячейки еепром при снижении питания. А вот если при записи многобайтной переменной произойдет перезапуск процессора, информация будет потеряна. Способ с трехкратным резрвированием как раз от этого и спасает. При наличии CRC можно всего две копии хранить.

[SasaVitebsk]

Я не беру в расчёт ситуации с пропаданием питания в момент записи. Для таких случаев необходима дополнительная аппаратная защита. То есть должно происходить прерывание при падении напряжения ниже какого-то (допустимого уровня) и в прерывании проц должен успеть завершить все начатые операции и зациклится. сли ему не хватает времени, то должен стоять кондёр или ионистор.

Я говорю только о разрушении информации при неправильной работе проца, в момент падения напряжения. В этом случае, при включенном BOD разрушения EEPROM, равно как и FLASH не наблюдалось с момента выхода at90s8515. И я не оптимист, а реалист. Если бы у меня такие случаи были, то я бы полностью отказался от использования EEPROM. Как можно пользоваться памятью, если иногда она сохраняет туфту???

Мой личный опыт показывает, что если идут сбои, то софтом можно минимизировать их влияние, но не убрать их полностью. Их надо убивать в точке их возникновения, а не бороться с проявлениями. Спецконтроль за спецнадзором - безперспективен.
Индуктивная нагрузка - это классический способ проверки и мы им активно пользуемся. Хотя это больше проверяет эффективность написания проги и применения WDT.

У меня было одно составное уст-во на 2 МК. К сожалению нельзя было сделать реинициализацию "на ходу". То есть возникала проблема, если одно из устр-в сбойнуло и перезапустилось. В результате был так написан софт, что подвисание и перезапуск устр-ва в 90% случаев не был заметен для второго. То есть по вылету от WDT, МК анализировал своё состояние и пытался восстановить его.
Я к чему это пишу? К тому, что на сегодняшний день надёжность устр-ва в значительной части определяется софтом! Начиная с проектирования структур данных и применёнными протоколами и заканчивая реализацией программы. Другой вопрос, что это всё не даром. Когда у меня заказчик спрашивает "а можно?" - ответ всегда "да". Правильный вопрос будет "насколько целессообразно", а в конечном счёте "сколь это будет стоить". Поэтому есть изделия, которые создаются как ширпотреб, а есть изделия (например для облтелекома модемы делали, которые уже лет 10 непрерывно работают), которые пишутся с учётом специфики и вылизываются до безобразия.

[EKuzmich]

спасибо за ответы! постараюсь поправить программу под этот случай. Но у меня возникают сомнения так как сбивается все время одна и та же ячейка причем с адресом 0х0а и в нее записывается одно и тоже значение 1 в независимости от того что там было записано например 180.

[ish0]

Попробуйте после каждой операции чтения-записи EEPROM записывать в регистр EEADR адрес неиспользуемой ячейки. Мне с тини26 помогло.

[SasaVitebsk]

2 EKuzmich. Вот это очевидно указывает на ошибку в программе.