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

[juvf]

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

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

[juvf]

2gerber
Вот это мысль! Спасибо. По диагонали глянул в вики - вроде должно решить проблему... Наверняка есть готовые библиотеки с реализацией Рида-Соломона? Случайно у вас нету?

Есть же всякие алгоритмы с избыточным кодированием с возможностью восстановления.... можно свое что-то написать. но я думаю что велосипед уже изобретён.... Кто может ещё, что-то посоветовать, какие нибудь алгоритмы восстановления?

2Plain
Не совсем понятно что и кому вы хотите показать? Несостоятельность моего девайса, я не собираюсь это оспаривать, или свою несостоятельность как инженера? Решить проблему перезапуском плат - любой сможет... любой школьник встретив такую трудность скажет - "перезапуск плат". Была бы возможность перезапуска плат - я бы тут даже не постил тему. Перезапустил бы молча. Но зачем компании нужен такой инженер, который не может решить "невыполнимые" задачи. Архимед один выполнил задачу которую не смогло решить 100500 рабочих(солдат) - столкнуть корабль. Придёте вы на собеседование к работодателю.... дадут вам тест "программно сделать безопасное чтение/запись фрамки без контроля питания". Что вы им скажете? "Ну да, чтобы заменить им пару соплей и резисторов, с гордостью отвергнутых чуть выше:". А другой кандидат применит Рида-Соломона и/или разберётся со строением фрамки и предложит живучий алгоритм сэкономив тем самым компании 1000нефти.

Понятно, что всех как магнитом тянет на аппаратное решение проблемы. Но аппаратно не возможно. Я могу обосновать почему невозможно, на несколько страниц расписать... но зачем? Скажу просто:

Вводная: (2Plain считай что это абстрактная задача, допустим математическая олимпиада)
программно сделать безопасное чтение/запись фрамки без контроля питания и без аппаратного вмешательства

ps
2Plain возможно вы правы на счет невозможности. и у вас есть такой опыт.... т.е. вы пробовали применить разное избыточное кодирование с восстановлением и применительно к фрамке это не работает... т.к. во время окончания последнего 8-го бита данных в фрам открывается такой-то транзистор.... происходит выборка строки .... регенерация адреса .... бла бла бла .... В результате чего портится то-то и то-то.... и восстановить такую информацию математически не представляется возможности.... Самую низкую вероятность сбоя показал восстановительный код Иванова-Сидорова, но при прогоне в климатической камере при t<-10°C и при t>50°C частота возникновения ошибки увеличиваются и вероятность сбоя возрастает до такой-то величины. .....
Конечно если предоставить компании подобные доводы и/или результаты исследования, то будут искаться другие пути решения проблемы. Но пока тупо - "Так сделать невозможно" или "Если платы не работают, они не сделаны. Можно повторять это бесконечное число раз, ничего не изменится." выглядит как маза.
Один инженер обосновал мне теоретически, на низком уровне (строение фрам), что црц+дублирование не поможет. Но с др. стороны практик

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

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

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

[maksimp]

считай что это абстрактная задача, допустим математическая олимпиада)
программно сделать безопасное чтение/запись фрамки без контроля питания и без аппаратного вмешательства

Этого нельзя.

Доказательство примерно:
Допустим питание сбилось и есть испорченная ячейка.
При каждом следующем включении питания и запуске алгоритма, он пытается сверить данные и исправить повреждения. Для этого он сначала читает сколько-то ячеек, проводит с ними вычисления, и затем записывает исправленное значение в испорченную ячейку. Среди прочтённых (до выполнения первой записи исправленного значения) ячеек сколько-то верных и сколько-то уже испорченных. Если все прочтённые ячейки испорчены то записать что-либо верное он уже не сможет. Значит надежда есть только если среди прочтённых значений есть верные. Но тогда дёрнем питание во время чтения какой-либо из верных ячеек. В результате испортилась ещё одна ячейка, а восстановить что-либо алгоритм не успел - всё это происходит до того как алгоритм собирается записывать что-либо. Так одну за одной испортим все ячейки.