Всем доброго времени суток! Вот такая проблема:

Есть некий девайс, собранный на МК AVR, в качестве энергонезависимой памяти на борту присутствует SPI DataFlash AT45DB041B. МК мониторит несколько датчиков и производит запись в DataFlash. Данные записываются в память с интервалом от 1 секунды до 3 минут, в зависимости от состояния датчиков, круглые сутки... Вопрос: стоит ли включать в управляющую программу AVR проверку сбойных ячеек, составлять соответствующие таблицы сбойных ячеек и т.п.? Существует мнение, что для современной флэш памяти проблема сбойных блоков не актуальна. Так ли это на самом деле? Или, возможно, не для данного конкретного типа памяти? В даташите на AT45DB041B что то я не нашел максимальное количество циклов перезаписи.

Спасибо.

Ресурс DataFlash около 100К циклов на страницу. При частоте записи около 1 раза в минуту, ИМХО, следует озаботится контролем состояния памяти.

Может есть какая то ссылка, или я в даташите, по усталости, просмотрел? Не ткнете носом?

FM20L08 - параллельная, 128кб
FM25L265 - SPI 32кб
У обоих количество циклов записи не ограничено, да и цикл записи равен циклу чтения.

Хм, речь я здесь завел про DataFlash 4MBit...

Я просто предложил альтернативу.
Извините, несколько по теме.

А умалчивают :-(. Однако число 10,000 до "освежения" командой "Auto Page Rewrite" официально фигурирует. Других чисел тоже не нашел, хотя слишком сильно и не искал, поскольку ресурса в моих условиях явно должно хватить - даже "освежение" только на страницу с FAT заложил. Все остальные только при "форматировании".

В своё время я запрашивал эту информацию у Atmel.
И получил ответ - 50000 циклов на страницу.

То есть, при такой интенсивности записи, проверка, все таки нужна... А есть какая то альтернатива данному типу памяти, желательно подешевле?... :-)))

А зачем альтернатива? Датафлэш, по Атымельим рекомендаццыям, ориентирована на потоковые приложения. Типа диктофона. Вот и пиши аналогично. Размер страницы там тоже неспроста такой горбатый. Там может храниться служебная инфа для адресации. Рядом с данными. Так что, при толковой организации, 50000циклов хватит до полного физицкого износа устройства.

Ладно, будем пробовать и толково организовывать...Пошел за пивом...

Вот ссылка. Но дело темное: количество циклов зависит от технологии изготовления, и раньше действительно упоминались цифры 10К и 50К.

Спасибо, че то я ходил-бродил по Атмелю вчера ночью, и не видел этого. На самом деле упоминается цифра в "...100K program/erase cycles per page..."

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

Ребята, соседи делали. Но они точно не проверяли. Проблем вроде не было.

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

))) Я сам ни разу не пользовал сей девайс...
Это, в принципе, не ново...Ладна, пусть пальма первенства достанется евреям)

Раз в минуту - это структура данных, пока имеющая размер в 12 байт...Так как все еще в стадии разработки, то размер может и уползти немного вверх, но это не принципиально ) Буферизировать ничего, скорее всего не надо будет, так как в данном чипе есть два буфера по 264 байта, - данные можно и там собирать...К тому же имеются отдельные команды для доступа к буферу и слива данных из него в обе стороны, и даже есть команда сравнения содержимого буфера и страницы. Так что проблема потихоньку становится прозрачной )))

Мы работали с 45db081. На некоторых микросхемах появлялись битые ячейки на страницах. Пришлось делать проверку на сбойные ячейки.

Это уже серъезный довод... Ладно, буду делать Bad Sector Allocation Table (((

Как вели себя сбойные биты ? Залипали на 0, на 1 или были и такие, и такие ?

в них было одно и тоже значение.

чтото трудно поверить что появляются битые биты - это своиственно NAND flash, а AT45D - NOR flash. AT45D чувствителнь к сбоям по питанию и нередко появляются аномалии при стыковке его с 5вольтовым контроллером. исползовал 04,08,16 и пока не было проблем , при том сохраняю фаилы с контролем. если обязательно надо контрол за исправность данных то хемминг лучше чем таблица неисправных ячеек т.к. кол-во последних будет расти при эксплуатации.

Какое ?

Поясните пожалуйста про хэмминг - что то знакомое со второго курса универа))) Имеете ввиду кодирование данных перед записью?

Коды Хэмминга - это одно из семейств кодов с восстановлением поврежденных данных.
Подробности с математикой есть на Википедии: http://en.wikipedia.org/wiki/Hamming_code

Да, хорошая штука, исправляет однократные ошибки в байте, сигнализирует (но не исправляет) о двукратных... Правда, размер данных увеличивается в два раза... Надо с заказчиком посоветоваться...

Вообще-то, в полтора раза для байта. Если возьмете размер побольше, скажем 16 бит, то накладные расходы будут еще меньше (<1/3). Правда, и вероятность обнаружения/исправления ошибок при этом уменьшится.

Если склероз не подводит, то в своё время у нас делали платы с контролем по Хэммингу. С однократным восстановлением и двукратной сигнализаццыей. Стояла 555ВЖ1 на 16 бит данных и 4 бита синдрома. На байт нуна 3 бита синдрома. Во...Кажысь не перепутал.

Я, вообще-то, изобретаю не кодировщик по Хэммингу, а соооовсем другое изделие, и мне еще важна производительность, которая не сопоставима с, допустим, ARM. Если еще я начну все уплотнять...Возможно, производительности МК не хватит... Эх...А у заказчика, похоже, кабель Езернет вырубили, не могу связаться второй день...

Ага, ага, а вместо МК комплект AMD 1804 применить, супер!!! )))

кодировку можно делать с look-up table, 2x256 баит берет, но задержка незаметная получается. правда, декодирование не так быстрая получается. а какие еще варианты? мажоритание 2 из 3-х жрет 3 раза больше flash. еще есть цикловые счетчики но они годятся для счета каких то событии а не для даталоггера.

Дык...в те времена оно само то и было. Правда, ставили в машину на 8086.
Зато на ходу отвёрткой РУ5 из панельки - цмык! А оно работает! Зелёных человечков впечатляло...

Я в ТЕ времена читать еще не умел....И учился писать не мимо горшка))) Счас надо чтоб все желательно одном чипе и дырдочек на плате тока чтоб закрепить...И то не всегда.)

Для любого семейства кодов с обнаружением/исправлением ошибок сначала задаются длина блока данных и требуемое число обнаруживаемых/исправляемых битов, а по этим данным рассчитываются требуемая длина блока коррекции и функции свертки/проверки.
По скорости смотрите сами - имхо, поиск по таблице сбойных байтов и ремап будут ой не быстрыми. А когда предполагается производить поиск сбойных байтов? При записи блока данных с проверкой по факту сбоя (все равно как минимум CRC как предельный случай упомянутых кодов) или предварительно/периодически?

Хм...если мне память не изменяет, Хэмминг предполагает защиту одного n-разрядного слова...

Поиск сбойных байтов произвести очень легко. В данной серии есть команда Main Memory Page to Buffer Compare , что облегчает контроль. Так как размер блока данных, относительно, не большой, можно производить запись только в буфер, а, в случае переполнения буфера, проверять целостность записанных данных. Кроме того, делать то же самое при пропадании питания (в устройстве два питания). Вот только не определился с таблицей сбойных...чего? Толи сбойных страниц, то ли страницу разбить на сектора размерности структуры данных. Смысла контролировать отдельные ячейки я не вижу...

И? Давайте считать Ваш блок данных n-разрядным словом (кста, Вы поминали 12 байтов - блок данных 8-15 байтов требует 8 дополнительных битов для исправления 1-кратных ошибок).

Посмотрите AT45DB041B Reliability Qualification Report (http://www.atmel.com/dyn/resources/prod_documents/45DB041B.pdf), но как-то оно там слишком шоколадно.
А выполнять проверку целостности при чтении блока Вы не предполагаете? Хозяин - барин.

Я не понял сначала Ваш ход мыслей...Счас понял...Но копаться с битами, на первый взгляд, геморно... Хотя, глаза боятся - руки печатают))) Может быть проще вместо UCHAR объявить UINT...?Объем расходуемой памяти, правда увеличится в два раза...

По поводу проверки при чтении - а что, есть ситуэйшн, когда будучи уже записанны, данные могут испортиться? Я имею ввиду не глобальные катаклизмы с питанием, или вследствии упавшей рядом ядреной бомбы, а в следствии порчи ячеек...

UCHAR удобнее, т.к. используемый Вами контроллер скорее всего работает с 1-байтовыми данными.
Любой алгоритм контроля целостности предполагает неудобную (скрытую) операцию вычисления номера бита. Использование таблиц делает ее скрытой. Но для блока данных в 12 байт таблица получится немерянной.
Т.к. у Вас частота записи во флеш невысока, то вычисление контрольного кода можно вести в фоне.

Дык именно это враги и проверяют при всяких endurance test памяти - частоту искажения информации. А чем оно (искажение) вызвано - взрывом ядреной бомбы, отказом ячейки или преждевременной утечкой заряда с затвора транзистора - дело следующее. Я почему и сказал, что результаты тестов ну очень шоколадные - ни одного сбоя ни в одном тесте. Если исходить из этого, то можно вообще ничего не контролировать.

Тгда, может быть проще, добавить к структуре два байта CRC? Расформатировать флэшину на сектора по размерности структуры (к примеру размером, допустим, в степени 2, или чтобы размер точно делился на размер буфера/страницы), да и шут с ним. Пишем - проверяем цеостность данных сравнивая с буфером, читаем - у нас есть CRC...

Если нужно только контролировать целостность данных, то, естесно, достаточно контрольной суммы какого-либо вида. Если же хочется их и восстанавливать, то... Ну Вы сами знаете.

Данные считываются с нескольких датчиков, с некоторых циклически, с некоторых по событию, раз в сутки предполагается эти данные снимать, за тем все повторяется. Так что, ИМХО, защиту восстанавливающими кодами, вводить не стоит, ограничусь CRC на структуру...

Так, вдогонку ...
Когда-то делал контроллер для пейджингового передатчика, пришлось кодировать кодом БЧХ. 20 битов данных защищались 10 битами кода, исправлял пять ошибок и от шести обнаруживал. Кодирование БЧХ очень простое, набор полиномов, Z80 справлялся на лету. Декодирование чуть сложнее. Но, наверное, это для параноиков

если вы читаете данные из флэшины раз в сутки, то видимо за сутки вы сделаете максимум один цикл её записи......... даже если брать минимальный ресурс приведённый в этой теме 10к - то получается 27 лет............ из практики использования флэшин ат45db321 ошибок не было....... правда до 10к дело ещё не дошло........))))) а контроль ошибок в качестве CRC на буфер вводить помойму целесообразно..... ресурсов ест немного, а на душе спокойней))))))

Чего то я не понял... Я собираюсь записывать данные во флэш с интервалом от 1 сек до 1(3) мин. Об этом я написал в первом посте. Пусть я буду кэшировать данные в обоих буферах пока они не заполнятся... Как у меня получится всего один цикл записи, если я сливаю данные круглосуточно?

Алгоритм Хемминга - частный случай алгоритма BCH. В POCSAG'е используется BCH(32,21,5) - 32-бит. блок = 21 бит данных + 11 бит контроля, до 2 ошибок исправляется, до 5 - обнаруживается.

Если писать данные в сектор последовательно то все должно работать OK, никаких сбоев не наблюдалось, по крайней мере у меня работает.
Более подробно можно поммотреть -> http://www.gaw.ru/html.cgi/txt/ic/Atmel/me.../at45/about.htm