Потребовалось запоминать несколько байт при выключеном питании.

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

Подскажите советом или простеньким примером, как наиболее оптимально проверять данные на битость и как исправлять поврежденные данные?

Для проверки есть контрольные суммы и CRC
Если собираетесь писать часто -- тогда лучше использовать внешние носители, у них гарантированное число циклов записи/стирания на порядки выше чем у встроенной флеши МК

Следует учитывать, что цикл записи во внутреннюю Flash порядка 3-4 десятков мс составляет. Поэтому нужно иметь соответствующий запас времени между детектированием пропадания питания и падением напряжения до критического (2,7В для MSP430F169).
Дублирование лишь ускорит "износ" памяти. Лучше используйте CRC для контроля целостности записи. Т.е. алгоритм такой: запись-верификация записи-запись CRC, если верификация успешна.
Flash у MSP430 по NOR технологии изготавливается, т.е. без ошибок. Если после стирания и записи при нормальных условиях (напряжение питания, тактовая частота FTG, температура) верификация не проходит, то такой кристалл просто нужно в утиль отправлять.
Проверять на правильность запись можно/нужно простым сравнением с исходными данными. Еще раз потворяю, что "битости" во Flash по NOR-технологии быть не может. Если появились сбойные биты/байты/слова, то такой кристалл подлежит замене. А чтобы избавится от случайной порчи содержимого Flash-памяти, нужно ставить внешний супервизор питания и правильно разрабатывать функции записи. Примеры в User's Guide и Apllication Notes имеются.

Я тоже в своё время озаботился данной проблемой - что будет с флешью (в частности с сегментом А или В, предназначенным для пользовательских данных), если стирать её раз в минуту в течение, скажем, пары лет.
Расчёт простой:
60(минут)*24(часа)*365(дней)=525600 циклов.
И это за 1 год.
Многовато для флеши!

Вывод:
Нужно либо писать реже (остановился на 5 минутах), либо писать не на одно место, а заполнять сегмент последовательно. Тем более что писать надо было всего 3 слова.

Алгоритм следующий:
При чтении по порядку перебираем данные с начала сегмента, пока не упрёмся в FF.
(Кстати говоря, мои данные обязательно содержали нулевые биты).
Далее считываем предыдущие N байт и размещаем в нужные переменные.

При записи то же самое, доходим до FF, только не читаем, а пишем данные дальше начиная с текущего места. Если дошли до конца сегмента - стираем его и пишем с начала.

//********************************

В результате - количество циклов стирания/записи уменьшается в 128/N раз.
В моём случае - в 21.33 раза.

Если использовать кодовые сегменты, то они длиннее в 2 раза, можно стирать в 2 раза реже.

Для контроля можно использовать CRC, контрольную сумму, или школьный пример - код Хэмминга
(находит двойные ошибки в 12-разрядных словах и исправляет одинарные, избыточность - 1,5)
А я однажды писал диплом, в котором использовал код, гарантированно исправляющий любые 3 ошибки в 24-битном слове (при избыточности 2)

Кольцевая запись во флеш-память это один из самых распространенных методов продления ее ресурса. Однако в дополнение к нему неплохо бы предусмотреть способ записи только в аварийной ситуации, когда пропадает питание или требуется перезагрузка. А уж для трех-то слов и в ОЗУ должно найтись место. ОЗУ не изнашивается так, как Flash.
ИМХО внутренняя Flash вообще не предназначена для журналирования. В INFO принято хранить какие-нибудь настроечные/калибровочные/пользовательские данные, которые не меняются столь часто. А для журналирования более подходит внешняя DataFlash, EEPROM, SD/MMC и т.д. с той же самый колцевой записью данных. Но это именно для журнала событий, который имеет большой размер и должен копиться продолжительное время. Например, в течение 2-3 лет, пока прибор не будет подвергнут очередной поверке. Если же требуется сохранять часто, понемногу и не нужно копить эти данные, то предпочтительнее реализовать отдельную цепь, которая будет сигнализировать об аварийной ситуации или использовать энергонезависимое ОЗУ (часто в RTC имеется место) или FRAM какую-нибудь. И производить сохранение данных, только в аварийном режиме. Кстати, DataFlash для этого подходит весьма неплохо, т.к. имеет свой собственный буфер. А запись из буфера во Flash одной командой выполняется.

ИМХО как раз для этого она и предназначена ибо зачем к примеру в ATMEGA128 столько памяти? Аж 128 кБайт... Никогда не мог занять больше 12 как бы не старался.. А всю оставшуюся память использую всегда для ведения журнала событий... Очень удобно.. За 8 мСек пишется целая страница, а в EEPROM за это же время пишется только 1 байт.. Когда журнал заполняется (месяца за 4)"сливаю" его на PC. И так можно повторять 10 000 раз, т.е. 3 000 лет !!!!

Доктор, вы меня уже утомлять начинаете. Какая Мега? Вы название раздела форума и корневое сообщение топика почитайте внимательно!

Да какая разница? Или в MSP флэшь на других физических приницпах организована?
Смысл в том, что журнал всегда лучше вести во внутренней флэшь контроллера если объём её позволяет это делать

Доктор, катастрофически падает столь любимая надежность.
И перестань троллить.

У кого-то падает, а кого-то повышается(как например у Вашего покорного слуги). Тут всё зависит от драйверов: руки.sys и голова.com



Не понял.. К чему это Ваше высказывание?
И перестаньте пытаться свести обсуждение на обсуждение моей личности

Примеры посмотрел, пока что все получается. За ссылки - спасибо.