Столкнулся с такой проблемой, после 3-х – 5-и месяцев использования перестает работать Dflash AT45DB161D. Причем выпадает вся память, даже те страницы в которые не велась запись. Память используется для хранения счетчиком, и накопления статистики; средняя частота записи 1 мин.
Кто сталкивался с такой проблемой отзовитесь плиз!!!
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
Itch но ведь при превышении ресурса наверно умерли бы только те страницы куда часто писали, автор утверждает что умирает вся флеш.
Samel а буферы то хоть в микросхеме продолжают работать?
шо там умрет при превышении одному кремнию известно )
Топикстартер не уточнил, что означает "перестает работать" в его случае.
Из стародавнего чтения результатов тестирования на живучесть (endurance tests) разных производителей флэш-памяти осталось воспоминание, что основная причина отказов - умножитель напряжения. Т.е. отваливается запись, но не чтение.
Если такая интенсивность записи топикстартеру действительно необходима, то его спасет только что-нить вроде FRAM.
или взять флешку побольше и организовать циклический буфер.
Цитата(Itch @ Sep 16 2009, 13:17)

или взять флешку побольше и организовать циклический буфер.
Циклический буфер там реализован, единственое что не делается так ето, что если писать в одну страницу больше чем 10000 раз подряд, то надо перезаписывать весь сектор. Насколько ето кретично и как ето делать?
Цитата
Насколько ето кретично и как ето делать?
В даташите написано и даже вроде нарисовано было.
Если у вас циклический буфер, т.е. пишете во все страницы флешки и с примерно одинаковой частотой, то проблема 10K не должна вас волновать.
Цитата(xemul @ Sep 15 2009, 12:00)

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

Дааа, вот это экстрим, циклически во флэш писать, я бы на такое не решился. Думаю автору альтернативы как FRAM нету.
А что тут такого экстремального в циклической записи? Наоборот, для флеша самое то!
Если в одну и ту же страницу писать - это да, согласен...
zltigo
Sep 25 2009, 20:33
Цитата(andron86 @ Sep 25 2009, 14:19)

Дааа, вот это экстрим, циклически во флэш писать, я бы на такое не решился.
Никакого экстрима - FLASH побольше, благо копейки и накрутка десятков тысяч циклов наступит очень нескоро в заявленных Автором условиях.
RW9UAO
Sep 26 2009, 13:30
закладывал в разработку такую же флэшку и циклическую запись страниц. перезаписывал страничку каждую минуту. гонял в этом режиме неделю - ничего не дохло. в штатном режиме во флэшку пишется примерно раз в час. флэха заполнялась примерно за три месяца. умножаем на 10 тыс циклов. судя по отзывам, работает уже не первый год. срок работы закладывали три года. первые экземпляры его прошли давно.
з.ы. речь идет не о фрам, а именно о ат45dbXXX
Александр Куличок
Sep 26 2009, 15:15
Подозреваю, что
andron86 неверно понимает фразу "циклическая запись в ФЛЕШ"

2
andron86:Циклическая запись - это не запись в цикле (в одни и те же ячейки памяти). Под циклической записью подразумевается такой метод записи в память, когда каждый обновившийся блок данных пишется не по старому адресу, а по новому, еще не занятому. По заполнению всей флеши выполняется стирание и запись начинается сначала. Т.е. цикл идет по адресам флеши. Естетственно, рзмер флеши должен быть в N раз больше размера блока данных. Таким образом мы продлеваем жизнь флеши в N раз.
Алгоритмы записи в общем случае могут различаться, но принцип остается тот же.
Собсна, недостаток видится только один - необходимость просканировать практически всю флешку на предмет свободного блока при инициализации.
HARMHARM
Sep 28 2009, 08:24
Цитата(Itch @ Sep 28 2009, 10:04)

Собсна, недостаток видится только один - необходимость просканировать практически всю флешку на предмет свободного блока при инициализации.
Или иметь EEPROM/Battery RAM, куда просто писать последние параметры данных во флешке. Если пропало - не беда, можно и просканировать
Цитата(Itch @ Sep 28 2009, 10:04)

Собсна, недостаток видится только один - необходимость просканировать практически всю флешку на предмет свободного блока при инициализации.
Свободный блок - это тот, на котором последовательный номер записи прыгает вниз.
Т.е.
|... 521 522 105 106 107 ...| - свободный 105-ый.
Через надцать кругов работы
|50001 50002 ... 55123 55124| - свободный 50001-ый
На старте везде нули.
Такой перепад ищется не полным сканированием флешки, а методом половинного деления, для 1024 блоков прочитать придётся, если не глючу, 11.
IgorKossak
Sep 28 2009, 18:47
Цитата(ReAl @ Sep 28 2009, 11:35)

Свободный блок - это тот, на котором последовательный номер записи прыгает вниз.
Только спустя некоторое время после перехода через ноль такой "прыжок" застрянет в одном месте, т. е. при
|65534 65535 0 1 ... 10 65123 ... | сканирование покажет на 0 как на свободный, а не на 65123 если подобное не учесть в алгоритме сканирования.
Цитата(IgorKossak @ Sep 28 2009, 22:47)

Только спустя некоторое время после перехода через ноль такой "прыжок" застрянет в одном месте, т. е. при
|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
Sep 28 2009, 20:42
Цитата(Petka @ Sep 28 2009, 23:18)

Уже не один раз кидал ссылку на Атмеловский Appnote AVR101: High Endurance EEPROM Storage.
Не такие уж там и откровения. Честно говоря, мне сложно представить условия для использования такой схемы.
Цитата(Petka @ Sep 28 2009, 23:18)

имелась ввиду конструкция вида:
Код
((A[i]+1) % max_cnt) != (A[i+1])
Та не, имелся ввиду таки перепад вниз, при двоичном поиске для выбора половины важно именно больше/меньше. Но я не вижу проблемы в том, чтобы сделать в качестве ключа, к примеру, 32-битный unixtime, который в логе и так не помешает. При этом даже несколько записей в одну секунду не поломают алгоритм.
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.