Насколько я понимаю, вероятность порчи данных в eeprom AVR большая, и желательно застраховаться от их порчи.

Допутим у меня в приборчике используется какая-то уставка, я ее храню в eeprom, в пяти копиях.
Кроме того во флеш записаны верхний и нижний допустимые пределы этой уставки.
При включении прибор читает копии уставки из еепром и если есть больше половины одинаковых, то проверяет лежат ли они в допустимых пределах, если да, то эта уставка присваивается переменной в RAM и дальше прибор с ней работает.
________________
Вопросы.
А какая вероятность порчи данных в ячейке RAM и FLASH?
Имеет ли смысл проверять правильность данных и в этих областях?
Если да, то как это лучше сделать?

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

Думаете в RAM долговременно хранится лучше чем в EEPROM?

Что-то мне не нравится это определение -- "порча". Возникают какие-то нездоровые ассоциации со сглазом, с гаданием на кофе, с П.Глобой, со звездами, со святой водой и т.д. Какой-то ненаучный термин -- "порча". Наверно лучше говорить о потере информации или искажении данных. Но это так, потрындеть...

Вам, в общем-то, правильно сказали, что если питание МК выполнено правильно и программа работает без побочных эффектов (то есть вы умеете писать робастые программы -- стеки не переполняются, код одной функции не искажает данные другой), то ни нет никакой разницы, где вам хранить -- в RAM, EEPROM или во внешнем EEPROM. Если у вас питание выполнено по принципу "тяп-ляп", если вы начинающий программер и пишите корявый код, то нет никакой гарантии, что ваши данные не будут случайно изменены.

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

Что же конкретно делать? В основном советы сводятся к тому, что в схему нужно добавлять супервизор, если у вас затянутые фронты питающего напряжения (Vcc при включении/выключении медленно нарастает/спадает), и после операции с EEPROM устанавливайте в регистре EEAR адрес ячейки, которая не используется.

Ладно, пусть я не умею правильно обращаться с еепром (писать программы, разводить платы), но дело в том, что и в промышленных устройствах я несколько раз сталкивался с тем, что данные в eeprom портились. Учитывая, что я имел дело с очень небольшим количеством устройств, то проблема наверное все таки есть.

_________

Я не знаю, предполагаю, что лучше, но сомневаюсь, поэтому и спрашиваю.
Сделать голосование для eeprom очень просто, так как чтение у меня только при пуске, а свободных ячеек много.
А как проверять целостность данных в RAM я не знаю. Предположения есть, но при этом простенькая програмка станет монстром.

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

_________

Это вроде бы это у первых AVR были плохие внутренние супервизоры, а в новых вроде бы нормальные.

_________

А как лучше сделать, если програмка пишется в WinAVR, то если ввести неиспользуемую еепром-переменную и после любых обращений к еепром еще добавлять строчку с чтением этой переменной, будет это работать?

А это совсем не важно -- умеете Вы или нет. Важно -- хотите ли Вы научиться. Ваша жизнь не просто точка по пространстве. Ваша жизнь -- это движущаяся точка. Не важно, где Вы сейчас находитесь. Важно -- в каком направлении Вы двигаетесь.


Все мы люди. И все разные. Кто-то делает на совесть, а кто-то абы-как. Кто-то пишет картины, а кто-то красит заборы.


Э-э... стоп-стоп-стоп! Я немного не понял. Мы говорим о проблемах несанкционированного изменения данных в EEPROM. Это, как мы знаем, происходят в моменты включения/выключения питания. Мы так же предполагаем, что программа написана правильно и не выполняет неожиданных действий. Иначе говоря, мы абсолютно понимаем как работает наша программа. Но, если нас беспокоят проблемы включения/выключения питания, то тогда причем здесь RAM? При выключении питания информация в RAM полностью теряется.


Да ну! Что за фигня? Если Вы не изменяете флешь, то это граничит с паранойей. Так никто не делает. Что за аппарат такой Вы изобретаете, где требуется такая сверх-надежность?


Я лично с проблемами EEPROM не сталкивался. Может везло ... хз.


1. Создайте переменную в EEPROM, которую читаете. Ее значение не принимает участия в программе. Проследите, чтобы компилятор не "соптимизировал" код.
2. Тупо записывайте в регистр EEAR адрес неиспользуемой ячейки. Для этого дела как нельзя к стати подходит байт с адресом ноль.

Включайте brown out контроль и спите спокойно, никуда информация не денется.

Когда не было brown out при выключении происходило несанкционированное выполнение случайного кода, что не редко приводило к сбоям всякого рода, в том числе порче памяти.

Причин может быть воз и маленькая тележка. Причем 99% - вина разработчика.

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


У первых - супервизоров не было вообще.

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

А можно подробнее про это.
Дело в том, что в устройстве, которое я сейчас делаю (пока работает одно, всего собираюсь сделать пять штук) я тоже читаю EEPROM только при подаче питания.
А как правильно?


Ну я имел ввиду, когда они уже появились, то первые были ненадежные, и было общепризнанным правилом их не использовать, а ставить внешние.

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

Наверное правильно читать EEPROM регулярно всё время.

Подобная проблема есть у FPGA - они читают конфигурационную флеш 1 раз при включении, и потом работают на копии в ОЗУ. Но может пролететь космическая частица и произойти сбой. Вот и придумывают для борьбы с этим всякие костыли к FPGA - подсчёт контрольной суммы содержимого конфигурационного ОЗУ, реализация 3 одинаковых схем внутри и т.д.

Подробнее - двусторонний брелок системы Pantera XS-3300....


Правильно - регулярное обновление. Как вариант - выбрать некоторое событие (нажатие на кнопку или к примеру выключение зажигания) по которому устройство проводить через RESET - с полным обновлением памяти (кроме статусного регистра флагов) и битов портов.
ЗЫ. Ну и естественно если читать EEPROM однократно, то при любом RESET (в т.ч. и по WDT), а не только при подаче подаче питания.
ЗЗЫ. А вообще - если переменная в EEPROM не вижу смысла ее хранить в другом месте.

А эту ситуацию устранили? и каким образом? тупо многократным чтением EEPROM?
И потерю SN списали на зловредные космические частицы?

ЗЫ.Предполагаю что SN это всего несколько байт и их можно восстанавливать из епрома а как быть если необходимо иметь 4/8/16/32 и т.д. кб данных в RAM?

Мы небыли связаны с производителем этих систем. Поэтому устранили самым простым способом - перестали закупать эти модели...

Возвращаясь к первому вопросу - какая вероятность порчи данных в ram, eeprom, flash?
И вытекающий из первого - нужно ли принимать меры по проверки целостности данных и какие?

У меня сложилось мнение, что конкретные цифры никому не известны, и соответственно нет общепринятых мнений.
Просто кому какие случае на практике попались, тот и считает их главной проблемой. У меня это eeprom, у ArtemKAD - ram.

Чрезвычайно низкая при соблюдении требований по питанию, помехоподавлению и пр. За более чем 10 лет работы с AVR проблем с несанкционированной порчей данных не встречал. Да, были глюки в программе, было дерьмовое питание от автомобиля, но в конце концов все наладилось, все выявленные ошибки - следствие огрехов в аппаратной части и программировании.
Причем содержимое флэша и еепром с помощью контрольных сумм не проверяю, и по 10 раз одно и то же не считываю

Это не корректный вопрос , так как нет начальных условий.
А они зависят от всего комплекса задач стоящих перед вашим проектом. Питание , помехозащещённость , программа , активность солнца , ориентация платы в пространстве, даты выпуска процессора , условия в цехе при его изготовлении ( влажность давление температура , чистота воздуха) ..... Когда Вы будете знать все эти условия - сможете , крайне приблизительно, расчитать вероятность отказа.
З.Ы У меня дисплей 5 лет отработал на разработке всевозможных проектов , в какие только "переделки" не попадал, а тут на ровном месте взял и сдох , причём красиво так , мирно и без пыли .

У меня исторически сложилось что при запуске проверяется контрольная сумма и памяти программ и памяти данных.
Если проблемы - индицируем пользователю.
Прошивка может обновляться, поэтому чтобы быть уверенным что все залилось корректно - проверяю CRC flash.
Параметры в eeprom влияют на алгоритмы работы прибора. Параметры также могут меняться юзером. Потому проверяю CRC eeprom. Если есть возможность храню две копии параметров. Одна сбойнет - читаем другую и восстанавливаем порченную....

Насчет контроля ОЗУ. никогда не применял. ИМХО этот изврат может понадобиться крайне редко. например если рядом включаются- выключаются многокиловатные движки или взрываются атомные бомбы...


как то так

Регулярное обновление чего? данных в RAM? или данных в EEPROM?

Мне все же схема автора кажется куда более правильной, единственное нужно помочь ему подправить ее напильником:

1. Необходимо иметь несколько копий уставок (обычно две) в энергонезависимой памяти, защищенных контрольной суммой.
2. При старте устройства, необходимо выполнить чтение и верификацию всех копий уставок - прочитать каждую копию и проверить контрольную сумму.
3. Обновить поврежденные копии "до победы", - т.е. записывать уставки и считывать их до тех пор пока все копии не пройдут верификацию.
4. Скопировть любую копию уставок в ОЗУ - после чего работать исключительно с уставками в ОЗУ.
5. После того как копия уставок загружена в ОЗУ - прибор можно считать готовым к работе.
6. При изменении любого параметра в ОЗУ - обновить все копии уставок в энергонезависимой памяти (здесь можно записью без проверок, а можно и "до победы" как в п.3).

энергонезависимая память здесь любое из:
внутренний/внешний eeprom/флеш, SD карточка, MMC, и т.д. и т.п.


Могу дать свои цифры для таких начальных условий: Планируется эксплуатировать устройство 1 год, включать-отключать раз в неделю, BOD выключен, нет внешнего супервизора питания, в программе есть функции записи флеш (команда SPM):
вероятность "порчи" флеш - 100%.
такая же самая вероятность и "порчи" eeprom, при тех же начальных условиях. Всё это из-за 100% "порчи" RAM при выходе питания за допустимые пределы.

Включение BOD - практически полностью убирает возможность искажения RAM по вине железа. Но если в коде будут вызовы SPM, тогда даже с включенным BOD'ом вероятность что-то угробить во флеш/eeprom будет очень высока. Ключевой момент - запись в EEPROM и FLASH - длительная операция, достаточно рубануть питание в момент записи, для того чтобы появилась "порча" данных (данные записались/стерлись не польностью). Делайте выводы.

Была недавно проблема с eeprom в серии девайсов, где на атмеге до кучи сделаны и часы. Научить потребителей обращаться с платами аккуратно - это нечто нереальное, а включать BOD - тоже не вариант, потребление от батарейки возрастает почти на порядок. Несколько раз из эксплуатации возвращались платы с полностью занулённой eeprom, хз как такое получается (ИМХО очень маловероятно). В итоге пришли к тому, чтобы критически важные данные (такие как серийник) писать во flash и устанавливать lock, после этого безобразие прекратилось.

В EEPROMе пусть хранится набор данных с возможностью проверки (CRC, две копии и т.д.) Читаем из EEPROM в RAM когда юзер начал пользоваться прибором, или там вызвал меню. Если такого события нет, то раз в десятки минут - часы. Если данные повреждены, восстанавливаем их из FLASH, где лежит дефолтный набор. Настройки обнуляются - сбой серьёзный, но не смертельный.
Если основная программа содержит SPM, проверяем её CRC при включении питания. Не сходится CRC - уходим на бут-лоадер, если он есть, и бесконечно мигаем индикаторами.
У меня бывало, слетали и флеш и епром, при больших неприятностях по питанию - например, резко клинит большой коллекторный движок, или лопается мощная галогеновая лампа. Тогда происходят разные электромагнитные процессы, горят предохранители, срабатывают защиты, ну вылетал флеш пару раз...

В новых AVR (PA) используйте коммутируемый BOD. Или прежде чем писать EEPROM проверяйте АЦП хватит ли питания для записи.