Борьба со сбоями данных в EEPROM

Предпринял еще одну попытку забороть сбои в EEPROM. На этот раз программным путем. На одном из труднодоступных объектов хранение данных RFID-меток в EEPROM примерно раз в неделю заканчивается тем, что метки приходится сбрасывать и запоминать снова. Не знаю с чем это связано, в других местах такое бывает гораздо реже, примерно раза в два в год, а кое-где не было и ни разу. То ли питание там скачет, то ли статика пробивает, то ли партия МК неудачная, пока не пойму. Перенос данных из начальных ячеек не помог, добавление конденсатора для сглаживания скачков питания не помогло, настройки BOD не помогли.

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

 

Может в критических случаях внешнюю память прикручивать - дешевле в итоге получится?

 

Круто! RAID 5 Distributed Data Guarding на EEPROM.

В серверную память SDRAM ставят дополнительные чипы и блок контроля четности (ECC), что позволяет исправлять ошибки на лету, исключать из обращения сбойные страницы памяти.

 

То ли прошивка кривая -- не рассматривали такой вариант, что в функционал прошивки работает не корректно, из-за чего происходит повреждение данных в EEPROM?
Есть известная проблема с нулевым байтом, подтверждённая производителем. Но больше проблем с EEPROM вроде как быть не должно. С проблемой нулевого байта сам не сталкивался, о ней узнал только от Вас на этом форуме и гугление показало, что проблема есть и желательно её учитывать. А так EEPROM свою работу делает и делает качественно.

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

Конечно нельзя исключить и аппаратные проблемы -- питание, воздействие ЭМИ и т.п. Но из-за отсутствия информации -- что за устройства, где установлены, что вокруг -- предположить ни чего нельзя. Вам самим придётся оценивать влияют ли аппаратные проблемы или нет.

Боюсь, что результат будет тем же.

С RAID5 ни чего общего нет.

 

Устройство критично к размеру, внешней EEPROM лепить некуда. Да и к себестоимости есть пожелания. А есть уверенность, что внешний не дуркует так же?

 

Как минимум покажет возможные ошибки в коде. Один образец можно сделать чтобы посмотреть.

 

Какие могут быть ошибки в коде которые сбивают записи? Запись меток происходит один раз при первом запуске, в дальнейшем они только считываются при подаче питания один раз за сессию. Никаких обращений к EEPROM в процессе дежурства нет.

Еще вот подсказывают из зала добавить задержку при запуске миллисекунд на 100 до обращения к EEPROM. Поможет избавиться от "дребезжащего" включения при котором работа с EEPROM может некорректно завершаться. Надо попробовать.

 

Может даже ухудшить ситуацию путем затягивания фронтов при включении-выключении. Внешняя память может помочь, если использовать ногу WP. Вы же метки прописываете однократно? Вот только на это время и разрешайте WP, а потом джамперочек перебросили - и никто память не перепрошьет, даже взбесившийся котроллер.

 

Совет хороший. Но пока буду стараться сделать без применения внешнего EEPROM, изделие и так бюджетное.

 

А если данные записывать три раза в разные области памяти (к примеру адреса 1, 512, 1024) и счтиав все три, выводить то значение, которе имеет два и более совпадений.
Если уж совсем заморочиться, разделить EEPROM на три части и создать там что то типа RAID5.

 

Ну примерно так и сделано у меня. Ближе скорее к РАЙД 2 чем к 5, избыточность информации повышает ее надежность. Насколько это эффективно покажет время, но сбои вряд ли могут затронуть несколько байт в разных местах памяти.

 

Тут основное, чтоб в случае обнаружения сбоя, система востанавливала данные автоматически.

 

Так и есть, и об этом я писал.

 

Ячейки памяти не независимы. У них есть общие шины для выбора, записи и чтения. Они могут физически находиться рядом и влиять друг на друга.

Зеркалирование данных не позволяет отличить дефектную копию от исправной. Нужны какие то контрольные суммы, указывающие на то, что копия исправна.

https://ru.wikipedia.org/wiki/Код_Хэмминга

 

Небольшое исследование показало, что сбой происходит в одном-двух байтах при обращении к памяти, в т.ч. и при считывании. если в это время творятся нелады с питанием. То есть начали считывать данные, все погасло, данные испортились. Во всяком случае пока что все сбои наблюдались при дребезге питания, которое заказчик какого то хрена не может устранить. Соответственно вить косички из данных методом Хэмминга (реализации чего на С найти пока не удалось) смысла нет никакого. Да и так код уже едва влазит в 8Кб, зачем одну маленькую часть задания раздувать больше чем все остальное вместе взятое? Для вычисления же больного байта достаточно просто сравнивать данные из трех копий находя несовпадение. Теоретически, могут сбойнуть и два байта в копиях, и даже все три, но при таком раскладе и Хэмминг не спасет, у него это называется двойной ошибкой и она неисправима. Так что довольствуемся всего лишь понижением вероятности потери данных в несколько десятков раз, что уже неплохо. А ведь можно сделать и пять копий и больше! Но перфекционизм не моя болезнь. )

ПС: контрольные суммы штука хорошая, использую их в пакетах данных при передаче с одного контроллера на другой, там где вероятность намотать помеху вполне реальна. Не совпала КС, пакет игнорируем, ждем следующий. А при данных из памяти что это даст? Ну не совпало, дохлый пакет, как жаль...

 

Значит все равно придется решать проблему с питанием. Что там сейчас имеется и как именно вы пытались ситуацию исправить? Есть возможность организовать для МК отдельно чистое питание на некоторое гарантированное время?

 

Есть мнение, что с питанием проблемы при включении, при дребезге. Он длится до 100 мс. То есть, теоретически, достаточно эти 100 мс не лезть к памяти. Но ошибка такая, что быстро статистику не собрать.

 

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

 

Если есть свободный вход АЦП, то можно мерять напряжение опоры относительно питания и таким образом выждать момент, пока питание не стабилизируется на нужном уровне (за установленное время не просядет ниже порога), а уж потом дергать епром.

 

Это если проц не будет сбрасываться от дребезга...
Для выжидания интервала достаточно просто воткнуть задержку в самое начало.