реклама на сайте
подробности

 
 
> ECC для Atmel DataFlash, 16 "резервных" байт на 512 байт страничке.
Velund
сообщение Sep 21 2008, 22:45
Сообщение #1


Знающий
****

Группа: Свой
Сообщений: 693
Регистрация: 19-11-04
Пользователь №: 1 177



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

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

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

Пока просто обрезал в прошивке использование той области, где повышенная вероятность появления сбойных страниц, но не нравится такой подход...
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов (1 - 2)
scifi
сообщение Sep 22 2008, 07:03
Сообщение #2


Гуру
******

Группа: Свой
Сообщений: 3 020
Регистрация: 7-02-07
Пользователь №: 25 136



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

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

Вообще-то такие ситуации просчитываются заранее. Всем известно, что ресурс флэш ограничен. Следовательно, на этапе проектирования выполняется анализ и при необходимости принимаются меры (wear-levelling, ECC и т.д.).
Go to the top of the page
 
+Quote Post
Velund
сообщение Sep 23 2008, 06:25
Сообщение #3


Знающий
****

Группа: Свой
Сообщений: 693
Регистрация: 19-11-04
Пользователь №: 1 177



Цитата(scifi @ Sep 22 2008, 11:03) *
Вообще-то такие ситуации просчитываются заранее. Всем известно, что ресурс флэш ограничен. Следовательно, на этапе проектирования выполняется анализ и при необходимости принимаются меры (wear-levelling, ECC и т.д.).


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

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

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

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 25th July 2025 - 11:07
Рейтинг@Mail.ru


Страница сгенерированна за 0.01342 секунд с 7
ELECTRONIX ©2004-2016