Не нашел лучшего раздела в это форуме

Разработан девайс с фрамкой FM25CL64. Фрам воткнули как энергонезависимую память для конфигурационных параметров, серийного номера и т.п. На практике оказалось, что если снять питание с фрамки во время операции чтение/запись, то в ней портятся данные. Как программно решить эту проблему?
На достоверность информации можно в фраме хранить crc. Но допустим данные недостоверны - и что? К их восстановить? Есть мысль хранить данные+црц и копию данных+црц. но где-то в инете натыкался на описание такого сбоя... в результате чего допустим 4-ый байт в каждом банке был битый. получается что если испортятся данные, то и копия тоже может испортится. Кто-нибудь решал подобную проблему программно и как?

Что в Вашем девайсе пишет/читает фрам?

Т.е. питание у них разное и можно отключить питание только у фрам?

Запись во FRAM ничем не отличается (кроме скорости) от записи в EEPROM/flash. Чтение из FRAM ничем не отличается от записи в неё же.
Поэтому используются те же способы обеспечения целостности чтения/записи, что и для EEPROM/flash.
Н-р, монитор входного напряжения стабилизатора и ёмкость на его (стабилизатора) выходе, достаточная для завершения чтения/записи.
Если же только программно ... ФС с журналированием подойдёт?

Я пишу две копии, у каждой crc16. Случаев одновременного сбоя обеих копий не замечено. (Хотя, если честно, то это не сильно критичные данные, так что я особо и не смотрел.)

Операции чтение/запись у FRAM нет. Есть отдельно чтение, есть отдельно запись. Причём, запись с явным разрешением (перед каждой операцией записи) отдельной командой.
Т.е., если при чтении снять питание в середине передачи например адреса - портятся данные во многих ячейках?
А Вы выжидаете время после подачи питания на микросхему памяти перед тем, как начинать читать данные (hint: читать даташит внимательно)?
brown out detecor у микропроцессора есть?

Сообщение отредактировал Genadi Zawidowski - May 30 2012, 19:09

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

Ещё раз хочу повторить..... аппаратно платы сделанны. Очень большой объем и очень дорогой. Аппаратную часть ни кто переделывать не будет. Поэотму изыскиваю пути исправить ошибру разработчиков платы программным путём.


ну то это понятно, просто сократил, читайте - "Во время отдельной операции записи с явным разрешением и во время отдельной операции чтения".

Я сейчас пока так и сделал. надеюсь что обе копии не попортятся.

Вот, нашел где я это видел


это я и хотел сказать. А что за восстанавливающая запись?

У Вас строго 3.3 должно быть. Имеется?

моя микросхема FM25CL64. питание по даташиту Voltage Operation 2.7-3.65V. я её питаю 3.3. Смотрю 3-ю страницу:

Прям как говорил sgs. У него микросхема очевидно FM25C160 и питается от 5 В.

Длительность циклов запись/чтение у FRAM десятки наносекунд. Это еще нужно очень постаратся за это время снять питание. Скорее всего при снятии питания прцессор улетает куда нибудь не туда. Я в своих схемах применял супервизор по питанию и его сигналом блокировал сигнал CS на память.

...Длительность циклов запись/чтение у FRAM десятки наносекунд.
И где это вы такое прочитали?

.

рубильнег дернул - вот и попал в эти "десятки наносекунд", за месяц на опытном образце раз 5 уже такое произошло. Причем можно в нормальном режиме, без ИБП только читать фрам, а в настроечном режиме, с ИБП, можно писать. Но баг происходит и при чтении.

да и действительно, от куда десятки нс?

Посмотрите параметр tD минимум 60ns между последовательными обращениями.
Я лично работал с FRAM c паралельным интерфейсом и их параметры практически совпадают со статической памятью SRAM с временем выборки 50-120ns


А конденсатор по питанию у вас стоит. И сколько времени он разряжается пока питание упадет на 10%. А если вы не позаботитесь чтобы процессор после снижения питания не начал писать что попало куда попало то он и флеш может потереть.

можете попробовать в любом сочетании:
1. Уменьшить частоту общения с FRAM насколько это возможно (обращаться на к ней, а к однажды считанной и хранящейся в RAM копии)
2. Исключить общение с FRAM во время переходных процессов (сразу после включения, после переключения мощного потребителя, при резком зафиксированном падении измеряемых величин...)
3. Использовать избыточное кодирование для восстановления данных
4. Использовать CRC для определения валидности пакета хранящихся данных.
5. иметь дубль хранимых данных на случай битого основного пакета.

У меня была одна конструкция на RAM с аккумулятором (тогда DataFlash еще не было), там годами по кругу данные записывались, CRC16+номер блока хватало для корректной валидизации блоков длиной 256 байт.
В другой конструкции (NANDFlash) применял избыточное кодирование плюс CRC - за несколько месяцев активных испытаний не было ни одного случая битого блока, а до применения избыточного кодирования это фиксировалось (благодаря CRC)