Защита FRAM Опции

[juvf]

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

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

[juvf]

2 maksimp
Теоретически вы правы. Сейчас я сделал единождое чтение фрамки при вкл. питания в озу и работа с данными из озу. Это должно снизить вероятность потери данных. Планируется эксплуатация 24 часа 15 лет. Один раз за весь срок службы включили - одна операция чтения. Но я понимаю, что теоретически лошадь, а практически упала. Добавлю копию+црц, добавлю восстановительный код с большим избытком. Думаю, что вероятность выключения питания сразу после включения, да многократно, да с порчей каждый раз новых ячеек теоретически равна..... это всё похоже на теорию о бесконечных обезьянах.

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

Всем спасибо

Сообщение отредактировал juvf - Jun 4 2012, 17:53

[barabek]

2 maksimp
Теоретически вы правы. Сейчас я сделал единождое чтение фрамки при вкл. питания в озу и работа с данными из озу. Это должно снизить вероятность потери данных. Планируется эксплуатация 24 часа 15 лет. Один раз за весь срок службы включили - одна операция чтения. Но я понимаю, что теоретически лошадь, а практически упала. Добавлю копию+црц, добавлю восстановительный код с большим избытком. Думаю, что вероятность выключения питания сразу после включения, да многократно, да с порчей каждый раз новых ячеек теоретически равна..... это всё похоже на теорию о бесконечных обезьянах.

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

Всем спасибо

Честно говоря не знал, что у FRAM разрушающее чтение. Сам использовал много раз и никогда проблем не было. Может повезло или не заметили. Есть приборы, порядка сотени-двух штук. В них запись текущего положения идет 10 раз в секунду. В этой же памяти хранится конфигурация, при сбое которой прибор перестанет запускаться. Приборы работают 24 часа. Еще, тьфу-тьфу-тьфу, не одного сбоя. А у Вас вот как. Самому лень, но может Вы, раз у горит проведете более качественные тесты. Я бы делал так. На тестовой плате сделать возможность отключать питание с FRAM. Написать прогу, работающую по такому алгоритму. Запись каждый раз случайных значений в память, дабы не было корреляции между ячейками. Затем чтение и во время чтения выключение питания, например транзисторным ключем, а лучше реле, чтобы была и случайность времени отключения и дребезг. Потом включение и повторное считывание. Сравнивая с записанным можно определить, во-первых, вероятность отключения, во-вторых, если сбоев будет много - зависимость между сбойными ячейками. И так по кругу. Даже по одной секунде на цикл за сутки уже получается 86400 опытов. Довольно много. Для чего нужно "во-первых" понятно, а "во-вторых" может повысить восстанавливающие способности кода. Допустим, выяснится, что между собой зависят биты (а не байты!) в ячейка, скажем 0-31-63- ... и портится только в одному ряду/колонке, а не по нескольким, то тогда можно сделать Рида-Соломона с соответствующим перемежением бит. Что повышает восстанавливающую способность в 8 раз! Т.е. не, скажем, 4 символа, а 4*8=32 бита. Если у Вас вдруг хватит сил это проделать отпишитесь, пожалуйста, сюда.
ОФФ. А советы "Кац предлагает сдаться, предлагает сдаться" (цэ) не слушайте. Мне понятно Ваше раздражение по этому поводу.

[juvf]

но может Вы, раз у горит проведете более качественные тесты

однако целый ниокр. время выкраю, проведу такое исследование.

Есть приборы, порядка сотени-двух штук.

а какая конкретно фрам стоит?

И при понижении питания Cyclon III "летает" где хочет и творит что угодно с фрам.

Может быть.... однако если идет команда чтения..... ну улетел ниос.... Это как он должен улелеть? пошла команда на чтение.... ниос полетел и вместо чтения передал команду Write Enable Latch, потом снял cs, потом выставил cs и передал команду записи и записал кудато мусор. Как-то маловероятно что с Write Enable Latch ниос улетит так, что попортит фрам. вся конфигурация плис хранится в другой памяти, в epcs. Если бы ниос так "летал" то он бы мог и епцс попортить. но случаев разрушения данных в епцс во время чтения замеченно не было и ни от кого ни разу не слышал о таком. думаю что это всётаки фрам виноватая.
Буду тест проводить..... процесор не будет выключаться, чтоб не улетал, только фрам буду отрубать.

то измерить напряжение питания можно с помощью самой FRAM.

мысль не понял.


Сообщение отредактировал juvf - Jun 5 2012, 06:24

[barabek]

а какая конкретно фрам стоит?

FM24C64

Может быть.... однако если идет команда чтения..... ну улетел ниос.... Это как он должен улелеть? пошла команда на чтение.... ниос полетел и вместо чтения передал команду врайт-протект, потом снял cs, потом выставил cs и передал команду записи и записал кудато мусор. Как-то маловероятно что с врайт-протектом ниос улетит так, что попортит фрам. вся конфигурация плис хранится в другой памяти, в epcs. Если бы ниос так "летал" то он бы мог и епцс попортить. но случаев разрушения данных в епцс во время чтения замеченно не было и ни от кого ни разу не слышал о таком.
Буду тест проводить..... процесор не будет выключаться, чтоб не улетал, только фрам буду отрубать.

В общем-то вероятность есть. Если начал летать то на ногах появляется такой дребезг от которого память что угодно может сделать. Из разряда милиона обезьян и написания ими "войны и мира", но с гораздо большей вероятностью. Допустим у Вас идет чтение. Пошел дребезг. Все что нужно для порчи это выдать повторный старт, совпасть адрес с адресом устройства и бит WR и вот, дальнейший дребезг - это запись чего-то куда-то. Может и маловероятно, но ...


А в epcs запись подубовей, времени больше требуется. Может по этому. Да и запись там повышенным напряжением.