У меня была такая же мысль. Но! А кстати, этот алгоритм проверенный? Точно работает?

Но. Мне кажется, что многоразовое туннелирование заряда в уже прошитые затворы может снизить срок их службы. Честно скажу, не владею информацией о влиянии многоразового программирования на долговечнойсть ячейки флэш. Только ли стирание ячейки сокращает срок её службы? В то же время программирование ячеек значением 0xff не разрушает их с вероятностью 100%. С другой стороны, многократное перепрограммирование ячейки повышает долговечность хранимой информации. Но в данном случае этого не требуется.

Сообщение отредактировал GetSmart - Jan 20 2009, 12:45

Лучше 0xFF. Тогда не будет жарить уже прожаренные ячейки. Вот только где я на это натыкался, уже не вспомню

Да, тут на форуме проблемы с 16 байтовостью как-то обсуждали и я писал тест. Работает.

Как я понял, наличие "0xff" (GetSmart) или "аналогичное" (zltigo) означает для IAP, что эту ячейку не следует перепрограммировать во флэш (как я понимаю: перезапись - это стирание + запись нового значения)?
Где это указано? В мануале никакого намёка нет.

Не. Стирание - это отдельная операция. После того, как заполните весь сектор (32К допустим), потом стираете его целиком и пишете заново с начала.
А перезапись - это запись нулей поверх едениц.

Т.е. запись в ячейку флеш "0xff" эквивалентна не записи, и счётчик перезаписей ячейки 100000 - 1 = 100000?


Это плохо, придётся стирать весь буфер, а у меня реализован алгоритм восстановления предыдущего значения в случае сбоя при записи текущего. На два буфера переходить чтоли ...

Ага. Примерно так.


Берите два буфера (сегмента). Стирать можно только сектор целиком. В начале флэш там есть 7 свободных сегментов по 4К, не считая нулевой, в котором таблица исключений. А в 128К, 256К и 512К процах много сегментов по 32К.

А в серии LPC23xx об этом не упоминается, выходит нет этого ограничения.

Проверил программирование по 16 байт 0xFF. Работает как надо. Проблема могла быть в том, что для 16-ти байт 0xFF контрольные биты ECC могли быть не все еденичные. Но, как говорится, пронесло.


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

Сообщение отредактировал GetSmart - Jan 20 2009, 14:38

то есть пишем только изменения ? если можем записать... иначе сттираем страницу и перезаписываем...
так ?


Насколько я ничего не понимаю,
NXP просто не дал других вариантов нам юзерам...
флеш точно можно писать по 16байт минимум, но описания как это делать, нет...
можно конечно дизасемблировать их процедуру записи/стирания, но никто не гарантирует что
процедура не изменится в будующем...
тч минимум для записи это 256 байт

Ясно.
Но если мы можем писать блок 256 байт, в котором все "0xff" (не изменяется ничего) и нет проблем с ECC, то записывая блок 256 байт, в котором первый "0x00" и далее все "0xff" (пишем первый байт только) будут проблемы?

Какие проблемы? Вполне корректно запишется первый байт нулём и обновится ECC для первых 16 байт. Из-за чего нельзя будет дописывать эти 16 байт. Но другие группы по 16 байт можно продолжать записывать. Можно даже прочитать флэшку и если в ней есть выравненные группы по 16 байт, то их запросто можно переписать не стирая сектор.

Я не корректно выразил свою мысль, имелось ввиду следующее:
во флеш имеем группу из 16-ти байт: 00,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff
пишем поверх: ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff , без проблем с ECC
но если пишем поверх: ff,00,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,ff , то получаем ошибку, почему? Если ECC формируется по результату записи, то проблем не должно быть, а если по записываемым данным, то проблемы должны быть и со всеми ff.

Дело в том, что после первой записи ECC сбросит некоторые из своих бит в 0. Даже если во второй раз записать в следующий байт группы не затронув предыдущий первый байт, то ECC изменится и с большой вероятностью некоторые биты ECC изменятся с "0" на "1", а так как флэш это не допускает делать без стирания байта (в LPC только сектор целиком), то ECC приобретёт совершенно некорректное значение. После этого читая эти 16 байт в них будут случайные биты (немного, возможно 1, 2 или 3) искажены алгоритмом ECC. Хотя большая часть бит в 16-ти байтах будет похожа на записанные значения.

Сообщение отредактировал GetSmart - Jan 21 2009, 09:36

Дошло.

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