[juvf 17]

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

 

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

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

[zombi 0]

Разработан девайс с фрамкой FM25CL64.

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

 

На практике оказалось, что если снять питание с фрамки во время операции чтение/запись, то в ней портятся данные.

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

 

[xemul 0]

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

Запись во FRAM ничем не отличается (кроме скорости) от записи в EEPROM/flash. Чтение из FRAM ничем не отличается от записи в неё же.

Поэтому используются те же способы обеспечения целостности чтения/записи, что и для EEPROM/flash.

Н-р, монитор входного напряжения стабилизатора и ёмкость на его (стабилизатора) выходе, достаточная для завершения чтения/записи.

Если же только программно ... ФС с журналированием подойдёт?

[AHTOXA 18]

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

[GenaSPB 11]

если снять питание с фрамки во время операции чтение/запись

Операции чтение/запись у FRAM нет. Есть отдельно чтение, есть отдельно запись. Причём, запись с явным разрешением (перед каждой операцией записи) отдельной командой.

Т.е., если при чтении снять питание в середине передачи например адреса - портятся данные во многих ячейках?

А Вы выжидаете время после подачи питания на микросхему памяти перед тем, как начинать читать данные (hint: читать даташит внимательно)?

brown out detecor у микропроцессора есть?

Изменено 30 мая, 2012 пользователем Genadi Zawidowski

[xemul 0]

Операции чтение/запись у FRAM нет.

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

[juvf 17]

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

 

Операции чтение/запись у FRAM нет. Есть отдельно чтение, есть отдельно запись.

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

 

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

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

 

Т.е., если при чтении снять питание в середине передачи например адреса - портятся данные во многих ячейках?

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

Для FRAM'а существенно напряжение питания: 4.5 ..5.5 В. Если питание будет ниже 4.5 В во время обращения к чипу (все равно - по записи или чтению), вы рискуете потерять не только данные в ячейке обращения, но и во всех связанных с ней ячейках строки регенерации - конкретно для FM25C160 - 4 байта в 4-х разных банках. Поэтому производитель настоятельно рекомендует (page 3) контролировать питание и принимать меры, чтобы хотя бы сигнал CS был "1" при пониженном напряжении.

 

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

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

[GenaSPB 11]

Для FRAM'а существенно напряжение питания: 4.5 ..5.5 В.

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

[juvf 17]

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

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

Note: The FM25CL64 contains no power

management circuits other than a simple internal

power-on reset circuit. It is the user’s

responsibility to ensure that VDD is within

datasheet tolerances to prevent incorrect

operation. It is recommended that the part is not

powered down with chip enable active.

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

[MaslovVG 0]

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

[Aner 8]

...Длительность циклов запись/чтение у FRAM десятки наносекунд.

И где это вы такое прочитали?

[Aner 8]

.

[juvf 17]

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

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

 

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

[MaslovVG 0]

...Длительность циклов запись/чтение у FRAM десятки наносекунд.

И где это вы такое прочитали?

Посмотрите параметр tD минимум 60ns между последовательными обращениями.

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

 

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

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

[Ruslan1 17]

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

 

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

можете попробовать в любом сочетании:

1. Уменьшить частоту общения с FRAM насколько это возможно (обращаться на к ней, а к однажды считанной и хранящейся в RAM копии)

2. Исключить общение с FRAM во время переходных процессов (сразу после включения, после переключения мощного потребителя, при резком зафиксированном падении измеряемых величин...)

3. Использовать избыточное кодирование для восстановления данных

4. Использовать CRC для определения валидности пакета хранящихся данных.

5. иметь дубль хранимых данных на случай битого основного пакета.

 

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

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