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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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


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

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



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

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

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

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

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


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


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


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


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

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