прошу поделиться опытом.
Какова надёжность этого типа флеши (Samsung), требуется ли всегда читать бит правильности записи (чтения)?
И ещё мне остался совсем непонятен механизм замещения "битых" ячеек и включения ECC, в PDF расплывчато очень написано об этом.

Только начал использовать и статистики по надежности пока нет.
Пишут что 100.000 циклов. Если использовать ECC то должно намного больше, а если еще сделать предварительное кэширование, изоляцию битых страниц и блоков + циклическая запись для равномерного распределения обращений, то вообще должно получиться супер.
Все только программно.
Коды ECC в spare. После RAW чтения, коррекция одиночных выпаданий битов в основной 2048 области (например 1-н бит на 256 байт, или даже 2 бита). Пользовательские данные в spare защищены своим ECC, меньшей длины.
Блоки у которых 1-й байт spare нуль (правильнее число бит <7, т.к. теоретически в нем тоже могут быть выпадания бит) программно не использовать. После стирания блока, при выдаче плохого статуса, самому пометить как плохой.
Статус при записи бесполезен, т.к. возможные битовые ошибки могут быть исправлены кодом ECC, а он выдаст что это ошибка. Надо еще раз прочитать с коррекцией и сравнить с оригиналом.
После всех этих операций NAND проживет дольше всего устройства.
Хотя думаю очень многие просто используют не напрягаясь, и в этом случае все в итоге халявно.

Спасибо!
Я подключаю к ПЛИС флешку, поэтому мне сложнее малость, надо всё это на машине состояний раскручивать, поэтому каждый "лишний" цикл обращения - определённая сложность, а уж выделить инвалидный блок - совсем тяжело.
Я не совсем понял, как "включить" использовние spare area и собственно ECC. Или код туда заносится тоже самим пользователем?
Кстати, возможно состояние, когда выход R/B залипнет в нуле?

spare никак не отличается от обычной области. Можно сразу писать все в page (2048+64), а можно и по частям, а можно установить адрес на 2048 и писать только в spare. Также и читать: все, только spare или часть spare.

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

ECC считается (и выбирается тип кода) самим пользователем, NAND только как тупой носитель (2048+64) байт с возможностью битовых ошибок после длительного использования (У себя битовых ошибок пока не заметил, а вот битых блоков несколько штук, но это только начало использования).
Наверно, когда последовательно пишите в NAND, то и считайте ECC, и после 2048 байта, пишите байт FF(как статус хорощего блока), затем подсчитанный ECC. А вот как потом при чтении исправить плохой бит - для ПЛИС наверно очень много геморроя.

R/B в нуле максимум 3ms при стирании, и при записи или чтении гораздо меньше. Залипаний не замечал, правда у меня там таймаут на превышение этого предела.

Думаю что для ПЛИС, использование ECC уже слишком, много ресурсов отъест, да и аппарат состояний не простой, может проще, если алгоритм использования в устройстве позволяет, при ошибке записи пометить страницу как стертую(программно, например байт 2 в spare) и перейти к следующей. Потом при чтении предварительно анализировать этот байт, и сделать такой же переход. Будет проще, при тойже надежности, правда емкость "израсходуется" быстрее.

На мой взгляд подключить к NAND MSP430 а ПЛИСину уже к нему.
Вариант дешевый и надежный.
Мы работали с NAND. При чтении записи не пользовались коррекцией ECC и всегда получали корректные данные, правда писали их в NAND со своей контрольной суммой, а с битыми блоками, маркировали сами после полного стирания NAND. Тут есть подводный камень, если ужотслеживать битые блоки, то инфа о них должна хранится никак не меньше чем во Flash, которая сохранит даже после какого нибудь КЗ. На самом деле не так уж часто они выходят из строя. У нас ни разу за год эксплуатации на 30 устр.

bmf, спасибо... Буду думать, просто в этой флеши образ операционки будет, а это всё ж ценная информация...

vvvvv, нет, никаких микроконтроллеров по ТЗ не должно быть. А то так бы я давно поставил, но правда, AVRку.

Если потребуется файловая система для NAND-флеш, настоятельно рекомендую посмотреть в сторону yaffs (_http://www.aleph1.co.uk/yaffs/) - имеет типа порта - direct - позволяя использовать практически без ОС, решает вопрос с "битыми" секторами, позволяет эмулировать NAND-диск как в RAM, так и в NOR-флеш, достаточно компактна + ряд других достоинств.
P.S. Компилить можно не только в gcc (с небольшой доработкой исх.текстов)

А чем отличается yaffs от yaffs2?

Там же четко писано
http://www.aleph1.co.uk/yaffs/yaffs2.html

* zero page rewrites means faster operation. (YAFFS1 uses a single rewrite in the spare area to delete a page).

*ability to exploit simultaneous page programming on some chips.

* improves performance relative to YAFFS1 speed(write:1.5x to 5x, delete: 4x, garbage collection: 2x)

* lower RAM footprint (approx. 25% to 50% of YAFFS1).

* Can support Toshiba/Sandisk MLC parts.

c YAFFS работал
скажу про недостатки:
она не доделана (по тексту много замечаний) и больше не развивается (замещена пользу YAFFS2)
сразу расчитайте сколько надо RAM - для 128M NAND при кластере в 8KB - 128K, а в оригинале кажется для 2K нужно - 512K это минимум
Время запуска (ускоренная вычитка всех областей) для 128M - около 4sec
Непредсказуемые задержки в процессе выполнения (при накоплении данных в gabrage collection происходит их длительная очистка и перемещение)
для YAFFS2 структуры в памяти и требовательность к ресурсам еще больше
соответствнно для 512M NAND - все в 4 раза больше и дольше

единственное преимущество это нечувствительность к пропаданию питания

как по мне - она (что YAFFS, что YAFFS2) только для ресурсоемких систем, а по времени старта вообще сомнительна для embedded
Принцип работы - просто загрузить всю информацию о всех секторах и блоках в RAM и работать с ней, поэтому и такая ресурсоемкость и монстровитость.

С YAFFS2 (direct-mode, ARM CPU 90 Mhz) работаю и сейчас (раньше использовал портированную jffs - это небо и земля) и не совсем с Вами согласен.
1. Расход памяти (RAM) - зависит от конфигурирования (исходных параметров).
2. Gabrage collection - медленноват для NOR-flash, для NAND - очистка сектора (страницы) достаточно быстра (~ 2 ms) и тормозов практически нет
3. перемещение - в этом же суть ФС для флеш-памяти! Благодаря этому, сохраняется ресурс секторов на запись - нет их быстрого "убивания" (идет равномерное использование)!
4. Для обеспечения быстродействия - разумный компромис между RAM и Flash диском (используя все ту же YAFFS2).
5. Приблизительно - у меня в embedde-system - 3 раздела/диска (1 RAM, и 2 - на разных чипах - flash) темп поступления инфо - не менее 500-800 байт в 20-100 мс, все прекрасно (размер конечного файла - не менее 6-8 МБ + 30-40 статичных БД/ИФ файлов, из к-рых читается инфа)
6. Небольшую чистку исх. файлов YAFFS2 можно сделать - с точки зрения оптимизации.
Нормальный расход флеш (мой опыт): максим. использование объема - не более 60-70% (т.е., если, например, файлы совокупно будут использовать до 1 МБ, желательна флеш объемом не менее 1.6 МБ)

P.S. 1. Для NAND - приведено время очистки блока, а не страницы. Например, если размер страницы 2К, то размер блока м.б. 128К - т.е. 64 страницы, и время очистки блока - порядка 2 миллисекунд
2. YAFFS работает с NAND со страницами в 512 байт (+ 16), YAFFS2 - с NAND со страницами в 2К

А что это за проц такой? На 90 Мгц...

Cir Logic - EP7312-90 - 74/90 Мгц

Особо не наконфигурируешь - на каждый сектор NADN надо как минимум 30 байт (точно не помню) RAM для хранения служебной информации.
Проще сказать так, если у вас OS типа Linux (и соответственно камень), то и эта файловая система для вас.
Для себя я выход нашел в следующем. Информация всегда пишется по кольцу и cтарая просто замещается новой. Логическая целостность обеспечивается link, прописанными в spare. При таком допущении требования к дополнительной памяти, сложности и объема кода, быстродействие всей системы получается более чем на порядок! Время старта - доли секунды. И все эти навороты полноценной файловой системы мне не к чему, т.к. задача архивирования актуальной информации решена, при полном использовании специфики NAND (одноктартное программирование, исправление однобитовых ошибок, учет битых блоков, стирание целым блоком).

Да нет, как раз Linux и не пользую - слишком много гробится времени в переключателе задач/обработке пр-ий и относительно много RAM жрет. Здесь меня пока выручает uCOS (минимальные накладные расходы и время отклика). В YAFFS1/2 как раз и нет "наворотов полноценной файловой системы" - т.к. собственно сам интерфейс файловой системы (для direct-mode) реализован буквально в одном примитивном файле с набором вызовов к ядру ФС, но тем не менее, реализовано все, что требуется - например, я работаю с полнофункциональной СУБД собственной разработки ("минималистская" реализация) и не испытываю никаких ограничений. Но, естественно, это мой опыт и мое мнение

Так у вас проц нехилый и видно NAND маленкая. А в других (не 32-x разрядных) работа с выделяемой heap памятью (а вся YAFFS интенсивно использует malloc), будет проблематична. И если heap > 64K ? При использовании YAFFS это так. Например 128M/2048= 64.536 секторов, на каждый сетор надо хранить как минимум link 4 байта + еще флаги.
Хотя конечно в перспективе, нужно просто переходить на более мощные процы и не заморачиваться с этим.

Процессор по нынешним понятиям - середнячек и загружен при работе до 70% (больше не даю, т.к. должен обязательно быть запас на обработку пиковых ситуаций), а в отношении более мощных - Вы правы, ведь сейчас это уже стоит "копейки" и новые МК по энергетике хороши.
P.S. Просто я достаточно долго выбирал ФС, прошел и jffs, и jffs2 (были и другие в течение 5 лет) - в результате с точки зрения ресурсов/надежности/удобства - для меня это лучший выбор