Всем привет. Столкнулся со следующей проблемой.

Тест nand: стираю блок, записываю несколько страниц нулями, читаю (запись/чтение без использования ECC). Имею ошибки, т.е. не все биты равны 0. Частота ошибок - порядка 8...20 на 64 страницы по 8192 байт. Не особо часто, но и не редко...

Насколько я понимаю, для NAND характерны битовые ошибки, они появляются в процессе юзания NAND, для их устранения применяется ECC.
-- Меня смущает достаточно большая частота их проявления в новой микросхеме. Так и должно быть?

В datasheet-е не нашел информации какой должна быть вероятность (BER, Bit Error Rate), в статьях в интернете натыкался на цифры 10^(-8)... 10^(-11), т.е. значительно реже, чем я наблюдаю (2 * 10^(-6) и выше).

В тесте работаю с корректными блоками ( 1. не помеченные как битые с завода, 2. проверка после стирания показывает, что все байты равны 0xFF), проверял тест на нескольких блоках.
Повторные чтения уже записанных данных, показывают что ошибки остаются на своих местах, т.е. в тех же страницах, по тем же смещениям в пределах страницы, ошибка в том же бите. В разных ошибочных байтах ошибки могут быть в разных битах.
Если еще раз стереть блок и заново обнулить страницы, то часть ошибок остается (те же страницы, те же смещения в пределах страницы...), часть пропадает/появляется в новых местах.
чтение ID, страницы параметров - верно читается.

память Micron mt29f512g08, MLC

Сообщение отредактировал savver - Aug 27 2014, 21:41

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

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

Это не так. Если взять MTD в линуксе (конкретно для TI AM3517) - то там используются коды БЧХ, корректирующие 4 или 8 бит в 512-байтном блоке (а это 16 или 32 бита в 2048-байтном). Но я за все время работы с ним не видел в логе ни разу, чтобы произошла коррекция ошибки!

для ТС:
Так что, ищите баги где-то в другом месте, во времянках, в питании, и т.п.

Не то чтобы "должно быть"... Все зависит от флэшки и технологии. В одной может быть от пара ощибок (или вообще не быть) на всю флэш, в другой их могут быть сотни. Много ошибок в основном в дешевых с 8кб страницами. Из даташита вы ничего не узнаете про "реальное примерное" количество ошибок. Использовать и проверять ECC придется в любом случае. Вопрос в другом - нужны ли вам такие флэшки с кучами ошибок и так ли важна такая экономия? Будет ли ваш контроллер корректировать ECC ошибки автоматически или переложите это на софт? В общем, это ваш выбор. Да и вообще, на данный момент, проще возложить все это на eMMC и не использовать нанд в чистом виде.

з.ы. Как вам советовали - проверяйте все времянки и сигналы для уверенности.

Это не большая частота.
Гораздо опасней если в NAND в которой должны быть ошибки вы их не видите. Тогда вопросы к вашему софту.

NAND-ы от Micron использую периодически.

И заметил одну странную вещь.
Когда закупил партию 100 шт. NAND для индустриального диапазона MT29F2G08ABDHC-ET:D TR (от -40), то в ней была плотность ошибок примерно как у вас. В среднем около 128 кБ памяти было неработоспособно.
Когда же закупил 100 шт. с коммерческим диапазоном MT29F2G08ABAEAH4:E-ND они все были без ошибок.

Я, вообще, тоже нарывался на память с большим кол-вом ошибок, но дело в том, что там были помечены заводом куча блоков! И не 128 кБ (это всего-то один блок), а десятки блоков, причем не один десяток. При этом в рабочих блоках фактов срабатывания ECC-коррекции так же не было замечено. А вот прямо сейчас - MT29F4G16ABBEAH4-IT:E - из 250 микросхем всего ОДИН блок помечен в одной из них.

PS
А что за -ET? Индустриальные, они -IT

PPS
Кстати, у меня тоже в AHC-корпусе была партия с кучей плохих блоков. Этот корпус мне на плату еле-еле влез (пришлось купить, так как AH4 не было в разумный срок) Разводил то под AH4 , поэтому больше опытов с AHC не ставил. Подозреваю, что там кристалл по более старой технологии сделан, иначе бы зачем ему такой слоновый корпус.

Спасибо за ответы!
Есть пища для размышлений...

Как будут новые результаты / прояснится ситуация отпишусь.

Для MLC частота появления ошибок довольно высока. В Вашем случае посмотрите еще у Микрона файл DSV на конкретную микросхему, там отклонения от DS в худшую сторону для -ET. Возможно, что это отклонения по времянкам. Обычно, когда возникают ошибки, они повторяются на тех же местах после стирания.

Ошибки во времянках "чтения" исключаю.
Read Parameter Page, Read Uniq ID, чтение более 5000 раз подряд не выдало ни одной ошибки (т.е. всегда считывается одно и то же).
-- Интересно, если например в Features писать-читать кучу раз для проверки правильности обращения к nand при записи, наверное ж там ничего не испортится/не затрется? (писать естественно адекватные значения, чтоб не сбоить работу nand).

Пробовал запись-чтение нулей в timing_mode 0...5 (выставление в features в nand), результаты примерно одинаковые.

Доп.задержки в софте при выполнении команд, использование read status enhanced вместо read statusnдля отдельного LUN-а чтоб всякие конфликты исключить, успехов не дало. "Мучить" софтовую библиотеку пока перестаю.
на выходных попробую ее на МК запустить, нашел платку с nand, hardware_level правда другой будет, но хотя бы убежусь что с командами нормально работаю.

Собираю статистику по каждому типу ошибок (сколько остаются на своих местах при повторных стираниях-записях, сколько остаются при повторных чтениях...).
Ну и буду внимательнее времянки смотреть...

Чем вы читаете из памяти?
В любом случае проверте времянки.
Потом проверьте напряжение питания и уровни сигналов.
Может и помехи в линиях надо проверить.

" чтение более 5000 раз подряд не выдало ни одной ошибки" - не есть критерием правильности работы!

угу, придется) спасибо.
Да, напряжения питания и уровни сигналов проверяли, в норме, 1.8 В как и должно быть, фронты не завалены.
Остаются времянки и помехи...

доступ к nand - через самописный контроллер nand-памяти (писал другой разработчик, я реализую софт под microblaze). Поначалу прочли ID, параметры, записали-прошли маленький буфер, все совпало и успокоились. Времянки на 1й взгляд тоже нормальные были (но теперь понимаю надо детальнее посмотреть). Потом начал писать по несколько страниц, и как раз вылезли битовые ошибки...


Сообщение отредактировал savver - Aug 29 2014, 16:55

давно не писал, переключался на другие задачи.

Проверил софтовую часть общения с nand (на уровне команд nand) на другой плате. там стоял SLC чип от micron MT29F2G08(ABD) + ARM. Те же тесты, 8 битых "заводских" блоков, битовых ошибок нет вообще(!) (запись-чтение нулей, отладочных счетчиков...) без всяких ECC. Т.о. софтовая ошибка отпадает...

ну...тогда статистика по указанным нанд'ам Вам в помощь.

Возвращаюсь к данной теме... вспоминаем понемного...

Тест:
стираем, пишем нули. Несколько раз считываем уже записанные данные.
( стираем nand, проверяем что после стирания == 0xFFFF, всегда норм, нет ошибок )

Типы ошибок:
-- есть ошибки которые при каждом чтении остаются на своих местах, (их большинство)
-- есть ошибки, которые при повторных чтениях - то есть, то нет (их меньше)
если перезалить плису и прочесть ранее записанные нули, ошибки остаются на тех же местах,

- повторное стирание и запись этого же блока
-- есть ошибки которые остаются на тех же местах, что и при прошлой записи
-- есть ошибки, которые возникают на новых местах

скриншот прилагается.

To be continue...

Сообщение отредактировал savver - Jan 16 2015, 10:58