NANDFlash + микроконтроллер - как бороться с битыми секторами? Опции

[yanvasiij]

Доброго времени суток!

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

[aaarrr]

1. Битыми считаются блоки, а не сектора. Разница существенная.
2. Таблицу можно хранить в той же памяти в двух экземплярах.

[XVR]

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

Зачем их запоминать? Они никуда не денуться, так что можно просто их не использовать при записи информации.

Я правильно понимаю, что мне нужна другая энергонезависимая память (например флеш на процессоре), чтобы хранить таблицу битых адресов? И нет других способов борьбы с ними?

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

[yanvasiij]

1. Битыми считаются блоки, а не сектора. Разница существенная.
2. Таблицу можно хранить в той же памяти в двух экземплярах.

Да, верно блоки.

Зачем их запоминать? Они никуда не денуться, так что можно просто их не использовать при записи информации.
Неправильно понимаете. Нужен такой алгоритм работы с FLASH, что бы он мог не использовать (как то обходить) сектора, которые являются битыми (более того, новые битые сектора могут появиться и в процессе работы)

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

А по поводу алгоритма неиспользования битых секторов можно по-подробнее - этот как?

[XVR]

Но как только я начал писать во флешку это признак теряется.

Пишите так, что бы этот признак не терялся (там всего 1 байт в расширенной области за это отвечает). Можно расширить признак - например хранить в этой области ECC (она для этого и сделана), и если ECC не совпал и коррекция невозможна, то проверять этот байт, если он не FF - то блок изначально битый

А по поводу алгоритма неиспользования битых секторов можно по-подробнее - этот как?

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

В принципе обычный FAT подойдет (если сделать ему возможность перемещать сам FAT). Хотя FAT не самый лучший вариант для FLASH по другим причинам

[dm.pogrebnoy]

Следовательно таблицу битых блоков можно хранить в самой же флешке, но по какому адресу ее разместить, ведь от флешки к флешке один и тот же адрес может оказаться битым.

Нулевой блок гарантированно не битый. Я бы хранил таблицу битых блоков в нескольких фиксированных местах. Вероятность того, что они все одновременно будут/станут битыми очень мала.
Для исправления и детектирования ошибок используют код Хэмминга. Загуглите для начала tn2908_NAND_hamming_ECC_code.pdf При превышении определенного количества ошибок в блоке, нужно помечать блок как битый и обходить его при работе с флешкой.

[jcxz]

способ 1:
Хранить таблицу битых блоков в первом исправном блоке. Таблица содержит CRC. Если CRC неверная - значит таблицы в этом блоке нет (вероятно блок битый), значит таблица в след. блоке.
И так далее, даже если с начала флешки цепочка битых блоков, всё равно таблица найдётся в первом исправном.
способ 2:
Что значит битые блоки? Блоки которые нельзя стереть (перевести в сост. "все FF")? А дописать в них можно?
Если да - алгоритм простой: резервируем в каждом блоке 1 байт для маркера блока. Если маркер==0xFF - блок исправный, иначе - неисправный. При первом старте на заводе все битые блоки метим, записывая в маркер !=0xFF (ну или там уже !=0xFF). При старте ПО в ОЗУ создаём таблицу битых блоков по маркерам.

[yanvasiij]

Резюмируя вышесказанное XVR, dm.pogrebnoy , jcxz:

- Хранить таблицу битых блоков можно в самой флешке. Способ 1, который предложит jcxz мне понравился. Второй способ не подойдет, насколько я понял в битых блоках может быть, всё что угодно;
- Для выявления новых битых блоков и исправления ошибок, использовать алгоритм Хемминга, с занесением в таблицу битых блоков новые испорченные блоки;

Вопрос вероятно глупый, но если поднять файловую систему, она не будет делать все это за меня?

[novikovfb]

Что значит битые блоки? Блоки которые нельзя стереть (перевести в сост. "все FF")? А дописать в них можно?

битый блок содержит одну или более сбойную ячейку, т.е. может искажать информацию. Эти блоки могут беспроблемно стираться, но при последующей записи возможны ошибки, причем за счет кода с исправлением ошибок (Хэмминга и т.п.) возможно исправление этой единичной ошибки.
Лучше в помеченные сбойными блоки ничего не записывать, а при штатной записи оставлять байт с признаком небитого блока равным FF.
По поводу того, где хранить таблицу битых блоков - я делал считывание заголовков всех блоков при включении питания и хранение таблицы в ОЗУ.

[esaulenka]

Второй способ более правильный. Табличка битых блоков в ОЗУ, при старте пробегать по первым страницам каждого блока и смотреть:
- данных нет (всё 0xFF) - нормальный чистый блок
- данные есть, ECC сходится - нормальный занятый блок
- данные есть, ECC не сходится - битый блок


Идея поднять файловую систему правильная. Вопрос только в том, что компактных ФС для "голого" NAND'а в открытом доступе особо и не видно...
Разве что NXFFS из NuttX должна довольно легко выдираться. Или yaffs смотреть. Я не пробовал, мы свой велосипед строили (зря, наверное, куча времени уходит...).
Всевозможные реализации Fat16/32 в чистом виде на NAND не ложатся никак.

Ещё есть всевозможные платные решения, но, мать их, всё закрыто - исходников нет, тестов нет, одни рекламные обещания "дайте нам денег, у нас всё самое-самое лучшее".

[jcxz]

Второй способ не подойдет, насколько я понял в битых блоках может быть, всё что угодно;

Вы не поняли. Скажем для флага выбрали 0-й байт блока.
Если в 0-м байте изначально не 0xFF - блок сбойный, даже не надо ничего делать. Если там не 0xFF - проверяем блок, если в любом байте !=0xFF, пишем в 0-й байт любое значение !=0xFF (не стирая страницы!).
Я не знаю как в данной флешке, но те SPI-FLASH с которыми я работал - всё позволяли модифицировать 1 байт внутри страницы не меняя остальные.
Если здесь не так и есть какой-то встроенный контроль блочными кодами исправления ошибок, то очевидно такой способ не подходит.

битый блок содержит одну или более сбойную ячейку, т.е. может искажать информацию. Эти блоки могут беспроблемно стираться, но при последующей записи возможны ошибки, причем за счет кода с исправлением ошибок (Хэмминга и т.п.) возможно исправление этой единичной ошибки.

Вы уверены что этот чип это умеет? Те SPI-FLASH с которыми мне довелось работать, не имели никакого контроля кодами исправления ошибок и позволяли дописывать нулевые биты без стирания страницы.

Идея поднять файловую систему правильная. Вопрос только в том, что компактных ФС для "голого" NAND'а в открытом доступе особо и не видно...

А что мешает использовать FatFS? LowLevel-IO там свой можно написать.

[esaulenka]

Вы уверены что этот чип это умеет? Те SPI-FLASH с которыми мне довелось работать, не имели никакого контроля кодами исправления ошибок и позволяли дописывать нулевые биты без стирания страницы.

Я уверен, что разговор не о том.
Во-первых, слова 'SPI' в теме не было. Зато была ссылка на даташит и слово 'NAND'.
А во-вторых, там была мысль о том, что битый блок можно стереть (и он, возможно, сотрётся). Потом можно записать туда информацию, и она, возможно, корректно считается обратно. Или некорректно. Как повезёт.

А что мешает использовать FatFS? LowLevel-IO там свой можно написать.

Мешает отсутствие готового нижнего уровня. Этот нижний уровень, собственно, и должен решать вопросы:
- не каждый блок можно использовать (битые блоки)
- минимальный размер стирания - блок (16 килобайт в данной конкретной микросхеме)
- полезная штука - wear leveling, чтоб не "протереть дырку" в каком-то часто используемом месте.

А вот поверх этого всего можно и "обычную" ФС надстраивать...

[yanvasiij]

Что-то посидел, подумал, порисовал алгоритмы всего этого. Многовато работы выходит, великоват велосипед. Наверно все-таки лучше попытаться yaffs. Если верить описанию он умеет и бэды и wear leveling. Его натягивание будет не быстрее чем писать самому, но думаю надежнее.

[novikovfb]

Вы уверены что этот чип это умеет? Те SPI-FLASH с которыми мне довелось работать, не имели никакого контроля кодами исправления ошибок и позволяли дописывать нулевые биты без стирания страницы.

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

[jcxz]

Во-первых, слова 'SPI' в теме не было. Зато была ссылка на даташит и слово 'NAND'.
А во-вторых, там была мысль о том, что битый блок можно стереть (и он, возможно, сотрётся). Потом можно записать туда информацию, и она, возможно, корректно считается обратно. Или некорректно. Как повезёт.

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

Мешает отсутствие готового нижнего уровня. Этот нижний уровень, собственно, и должен решать вопросы:
- не каждый блок можно использовать (битые блоки)

Это решается самой ФС.

- минимальный размер стирания - блок (16 килобайт в данной конкретной микросхеме)

В обычных SD размер стирания тоже как правило гораздо больше размера блока записи. И ничего - работает FatFS.
Хотя не разбирался как там это реализовано.

- полезная штука - wear leveling, чтоб не "протереть дырку" в каком-то часто используемом месте.

Несложно реализовать самостоятельно. Недавно я как раз реализовывал что-то подобное для SPI-FLASH-ки.
Тут будет конечно немного сложнее, так как в одном блоке стирания может быть несколько кластеров, но возможно.

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

Что-то странное Вы говорите....
Я конечно на практике с параллельными FLASH не работал, но с SPI-FLASH (разными) у меня куча проектов. И готовых давно работающих, и в процессе разработки несколько.
И работают эти девайсы в далеко не тепличных условиях - на почти неотапливаемых подстанциях в тайге в мороз и жару.
И куча важной информации там хранится на этой флешь - и конфигурация и журналы событий и срезы мощности, а сейчас и осциллографирование туда осуществляется. И пишутся непрерывно и контроль непрерывно идёт. И почему-то нет сбоев как ни странно.

Неужто такое именно с параллельными FLASH происходит???