Проблема с DataFlash AT45DB161D, Умирает память Опции

[Samel]

Столкнулся с такой проблемой, после 3-х – 5-и месяцев использования перестает работать Dflash AT45DB161D. Причем выпадает вся память, даже те страницы в которые не велась запись. Память используется для хранения счетчиком, и накопления статистики; средняя частота записи 1 мин.
Кто сталкивался с такой проблемой отзовитесь плиз!!!

[Itch]

60*24*30*5 = 216000, что уже в 2 раза больше гарантируемого ресурса.
Во вторых, там есть приписка, что если писать в одну страницу больше чем 10000 раз подряд, то надо перезаписывать весь сектор

Each page within a sector must be
updated/rewritten at least once within every 10,000 cumulative page erase/program operations
in that sector

[uriy]

Itch но ведь при превышении ресурса наверно умерли бы только те страницы куда часто писали, автор утверждает что умирает вся флеш.
Samel а буферы то хоть в микросхеме продолжают работать?

[Duhas]

шо там умрет при превышении одному кремнию известно )

[xemul]

Топикстартер не уточнил, что означает "перестает работать" в его случае.
Из стародавнего чтения результатов тестирования на живучесть (endurance tests) разных производителей флэш-памяти осталось воспоминание, что основная причина отказов - умножитель напряжения. Т.е. отваливается запись, но не чтение.
Если такая интенсивность записи топикстартеру действительно необходима, то его спасет только что-нить вроде FRAM.

[Itch]

или взять флешку побольше и организовать циклический буфер.

[Samel]

или взять флешку побольше и организовать циклический буфер.

Циклический буфер там реализован, единственое что не делается так ето, что если писать в одну страницу больше чем 10000 раз подряд, то надо перезаписывать весь сектор. Насколько ето кретично и как ето делать?

[uriy]

Насколько ето кретично и как ето делать?

В даташите написано и даже вроде нарисовано было.

[Itch]

Если у вас циклический буфер, т.е. пишете во все страницы флешки и с примерно одинаковой частотой, то проблема 10K не должна вас волновать.

[Prov]

Если такая интенсивность записи топикстартеру действительно необходима, то его спасет только что-нить вроде FRAM.

Полностью поддерживаю. Для накопления большой статистики, действительно, альтернативы flash-памяти нет. Но тогда нужно помнить о необходимости erase/write достаточно больших страниц данных, которые иногда просто негде хранить на время erase. Когда лет 6 назад я предложил писать статистику во fram у меня было мало сторонников - очень высокая стоимость. Тем не менее, я настоял на fram 32K (всего, хотя это было не 5 копеек). Работает без проблем по сей день. Применяю и в новых разработках, только 64K (цена уже таже). Проще поработать над форматом действительно необходимых данных и не разрабатывать велосипедные алгоритмы перезаписи по счетчику, который тоже нужно где-то хранить. Если данные изменяются не часто, тогда flash без проблем. Есть еще и eeprom, но это зависит от конкретной задачи, правильная формулировка которой уже должна привести к оптимальному решению.

[andron86]

Дааа, вот это экстрим, циклически во флэш писать, я бы на такое не решился. Думаю автору альтернативы как FRAM нету.

[HARMHARM]

Дааа, вот это экстрим, циклически во флэш писать, я бы на такое не решился. Думаю автору альтернативы как FRAM нету.

А что тут такого экстремального в циклической записи? Наоборот, для флеша самое то!
Если в одну и ту же страницу писать - это да, согласен...

[zltigo]

Дааа, вот это экстрим, циклически во флэш писать, я бы на такое не решился.

Никакого экстрима - FLASH побольше, благо копейки и накрутка десятков тысяч циклов наступит очень нескоро в заявленных Автором условиях.

[RW9UAO]

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

[Александр Куличо...]

Подозреваю, что andron86 неверно понимает фразу "циклическая запись в ФЛЕШ"
2 andron86:
Циклическая запись - это не запись в цикле (в одни и те же ячейки памяти). Под циклической записью подразумевается такой метод записи в память, когда каждый обновившийся блок данных пишется не по старому адресу, а по новому, еще не занятому. По заполнению всей флеши выполняется стирание и запись начинается сначала. Т.е. цикл идет по адресам флеши. Естетственно, рзмер флеши должен быть в N раз больше размера блока данных. Таким образом мы продлеваем жизнь флеши в N раз.
Алгоритмы записи в общем случае могут различаться, но принцип остается тот же.

[Itch]

Собсна, недостаток видится только один - необходимость просканировать практически всю флешку на предмет свободного блока при инициализации.

[HARMHARM]

Собсна, недостаток видится только один - необходимость просканировать практически всю флешку на предмет свободного блока при инициализации.

Или иметь EEPROM/Battery RAM, куда просто писать последние параметры данных во флешке. Если пропало - не беда, можно и просканировать

[ReAl]

Собсна, недостаток видится только один - необходимость просканировать практически всю флешку на предмет свободного блока при инициализации.

Свободный блок - это тот, на котором последовательный номер записи прыгает вниз.
Т.е.
|... 521 522 105 106 107 ...| - свободный 105-ый.
Через надцать кругов работы
|50001 50002 ... 55123 55124| - свободный 50001-ый
На старте везде нули.
Такой перепад ищется не полным сканированием флешки, а методом половинного деления, для 1024 блоков прочитать придётся, если не глючу, 11.

[IgorKossak]

Свободный блок - это тот, на котором последовательный номер записи прыгает вниз.

Только спустя некоторое время после перехода через ноль такой "прыжок" застрянет в одном месте, т. е. при
|65534 65535 0 1 ... 10 65123 ... | сканирование покажет на 0 как на свободный, а не на 65123 если подобное не учесть в алгоритме сканирования.

[Petka]

Только спустя некоторое время после перехода через ноль такой "прыжок" застрянет в одном месте, т. е. при
|65534 65535 0 1 ... 10 65123 ... | сканирование покажет на 0 как на свободный, а не на 65123 если подобное не учесть в алгоритме сканирования.

имелась ввиду конструкция вида:

Код

((A[i]+1) % max_cnt) != (A[i+1])

P.S.
Уже не один раз кидал ссылку на Атмеловский Appnote AVR101: High Endurance EEPROM Storage.
Советую всё-таки ознакомиться.

[HARMHARM]

Уже не один раз кидал ссылку на Атмеловский Appnote AVR101: High Endurance EEPROM Storage.

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

[ReAl]

имелась ввиду конструкция вида:

Код

((A[i]+1) % max_cnt) != (A[i+1])

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