ECC для Atmel DataFlash, 16 "резервных" байт на 512 байт страничке. Опции

[Velund]

Напоролся тут на то, что в одном проекте которому уже более 3 лет начали потихоньку сыпаться эти датафлеши. Заменить - сложно, там корпус SO-28 в котором атмель эти чипы не делает уже года два. Приходится городить переходник с SO-8, что неприятно.

А уже тем более неприятно то, что как правило битые всего несколько страничек (те, в которых в первых версиях firmware были FAT и директория файловой системы - позже все было решено несколько по другому) и проблемы как правило с 1-2 битами на страничке (из того, что видел своими глазами).

Может быть кто то уже думал, как с наибольшей пользой запользовать эти "резервные" 16 байт чтобы хотя бы 1-битовую ошибку исправлять, а большее количество сбойных бит - надежно детектировать?

Пока просто обрезал в прошивке использование той области, где повышенная вероятность появления сбойных страниц, но не нравится такой подход...

[scifi]

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

http://www.st.com/stonline/products/literature/an/10123.pdf

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

[Velund]

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

Просчитываться то они просчитываются. Когда есть исходные данные для просчета.... ;-)

А когда железо сначала делается под одну задачу, в процессе ТЗ радикально меняется, причем железо уже сделано и на объектах... Бывают разные варианты.

А если серьезно - в изначальном ТЗ было среднее - 5-6 записей в сутки, по прикидкам ресурса хватало на пару сроков службы устройств с лихвой. В результате изменения ТЗ пришлось переделывать код (в пожарном порядке) под логгирование по внешним событиям, и некоторые девайсы писали что то каждую минуту или около того. Понятно сразу стало, что добром это не кончится, но быстро выдать модифицированную версию было просто _необходимо_. Пока переделывали файловую систему, пока добрались до всех "точек" чтобы обновить прошивку - железо работало, и успели неслабо "удолбиться" во многих флешки в зоне директории и фата. А сейчас это начало вылезать потихоньку, хотя они давно уже работают в гораздо более "гуманном" режиме, с распределением нагрузки практически равномерным по всем секторам.