Эта псевдопостоянная EEPROM в AVR и не только

[n441]

Тема довольно интересная и, я считаю, злободневная. Прошу поделиться опытом, кто как борется с этим явлением? Мною испробованы и программные способы с многократным дублированием и последующим восстановлением данных "по наибольшему количеству повторяющихся" и экзотические,с применением электролита в качестве этакого АПСа.Рекомендации АП-нотов использовались по умолчанию.
Интересны будут отзывы по МК других фирм и варианты внешних ЭСПЗУ бюджетных версий(всякие там dsp применять вместо Tiny - абсурд), наименее подверженых этим явлениям?

[Shov]

Проблема с EEPROM в AVR не такая уж страшная. При соблюдении определенных условий потеря данных никогда не возникает. Рецепты давно описаны, хотя многие часто наступают на эти грабли.
В частности я только что убил трое суток докапываясь до причины перезаписи данных в ATMega328P. Может это кому-то поможет.
Приборы на ATMega168 несколько лет беспроблемно выпускаются довольно большим тиражом. Когда программа разрослась, перешел на ATMega328P. Глюк заметил не сразу, так как происходил он редко и портились данные в совершенно случайных ячейках. Если после включения прибора происходила запись EEPROM, а потом прибор выключался, то при следующем включении какая-то из ячеек могла слетать. Если записи перед выключением не было, то эффект не наблюдался. Проблему с BOD сначала даже не рассматривал - в программаторе включается всегда, по-умолчанию! Перепахал кучу кода, перерыл весь нет - глухо...
Здесь следует отметить, что программатор - AVReal. Штука отличная и проверенная многолетней работой! Спасибо Александру Редчуку!
Я настолько доверяю этой программе, что обновляю версии только, когда старая не поддерживает новый кристалл или обнаруживаю какой-то баг.
Версия 1.26 давно проверена и как будто бы поддерживает mega328P...
Но как оказалось, в этой версии фузы BODELEVEL для ATMega328P обрабатываются не правильно. BOD просто не включался, хотя я был уверен в обратном. Саша Редчук решил эту проблему почти год назад, а я попал на грабли только сейчас.
Короче - после обновления AVReal все стало на свои места. И фузы и EEPROM и мои мозги и вера в Atmel !
Мораль сей басни такова - не ищите загадочных барабашек в кристалах. Просто проверьте еще раз - все ли вы делаете правильно?
Все глюки с EEPROM у AVR давно описаны в даташитах.
И периодически обновляйте используемые программы!

[niXto]

Тема довольно интересная и, я считаю, злободневная. Прошу поделиться опытом, кто как борется с этим явлением

Я никак не борюсь. Ибо за лет пять - начиная с AT90S - ещё ни разу не прокалывался с ЕЕПРОМом. Естественно в первые 8-16 ячеек ничего не пишу, сразу после старта и после записи регистр адреса устанавливаю в 0, и всегда ставил супервизор а в новых чипах включаю БОД. А в пико-поверных его ещё отключаю на время сна

[OneTech]

Глючила EEPROM, стирались некоторые ячейки в состояние 0xFF в ATmega16, BOD был активен. Причина оказалась в сильных помехах по цепям питания и связи RS-485. Новая разводка печатки и изменение режима работы 3-х киллоВаттного корректора коэффициента мощности с разрывных токов дросселя на неразрывные токи.