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

[yanvasiij]

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

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

[yanvasiij]

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

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

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

[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, чтоб не "протереть дырку" в каком-то часто используемом месте.

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

[jcxz]

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

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

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

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

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

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

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

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

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

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

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