IAP в LPC17x, запись без стирания - возможно-ли? Опции

[jcxz]

Пытаюсь дописывать в сектор программной flash LPC1758 без предварительного стирания сектора.
Исходное состояние области в которую пишу - все 0xFF.
Так вот: иногда запись проходит нормально, иногда - записанное не соответствует записываемому (как правило - в каком-либо одном байте).
Если предварительно стереть сектор - то всегда всё ок.
Перепробовал уже вроде всё, что можно: запрещал прерывания на всю процедуру записи, менял сектора, размеры записываемого сегмента, писал кодом из ОЗУ и flash и т.п. - всё без толку.
Вот такой блок (hex):
18,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,81,15,3A,18
,94
даёт сбой каждую 4-ю запись. После проверки получаю что записано:
18,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,20,00,81,15,3A,18
,94
И результат всегда такой. Каждая 4-я запись у меня идёт по адресу, кратному 0x20 (может это как-то влияет).
Повторная многократная запись поверх по этим-же адресам этого-же блока не помогает.

Согласно AN11008 с сайта NXP такая запись без стирания возможна. В еррате ничего нет.

Сталкивался-ли кто-нибудь с подобным?

[KRS]

Вообще в описании IAP однозначно указано что адрес должен быть выравнен на 256 байт! И размер блока может быть тоже от 256 байт.

про 16 байт - это размер шины флеша - 128 бит + ECC, но это был хак опубликованный для LPC2000. Для новых чипов в принципе тоже можно по 16 байт писать, но это не документировано.
Если хотите штатно - размер блока 256 байт и выравнены они на 256 байт! Все работает отлично!

[aaarrr]

про 16 байт - это размер шины флеша - 128 бит + ECC, но это был хак опубликованный для LPC2000. Для новых чипов в принципе тоже можно по 16 байт писать, но это не документировано.

Для LPC13xx документировано. По какой причине "забыли" для других - вопрос.

[KRS]

Для LPC13xx документировано. По какой причине "забыли" для других - вопрос.

с 13xx не работал.
а вот в 17xx и 11xx ограничение в 256 байт есть.
причем и IAP и бутлоадер ЕМНИП выдавал ошибку при нарушении. (DST_ADDR_ERROR)

[jcxz]

причем и IAP и бутлоадер ЕМНИП выдавал ошибку при нарушении. (DST_ADDR_ERROR)

Вы просто не поняли о чём речь. Перечитайте ещё раз переписку.
Дело не в размере блока, передаваемом функции IAP и не в его стартовом адресе - здесь всё согласно UM, иначе IAP выдавал-бы ошибку.
Дело в записи ПОВЕРХ ранее записанного блока (скажем 256-байтного), новых данных без стирания.
Так вот, уважаемый aaarrr утверждает, что внутри такого 256-байтного блока, нельзя менять те его 16-байтные строки, в которых уже есть 0-ые биты, а можно менять только те 16-байтные строки, в которых только исключительно все биты ==1. Мне кажется это вполне правдоподобная версия и проверю её.
Я же делил страницу (4КБ) флеш на блоки не кратные 16 байт, соответственно записи у меня часто перекрывали (не полностью) несколько соседних 16-байтных строк или даже переходили через границу страницы (256байт) в соседнюю.

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

Вопрос же стоит в возможности и ограничениях по дозаписи внутри страницы.

Возможность определённо есть (этому посвящён Application Notes котоорый я упоминал выше), но вот насчёт ограничений я не в курсе.
Может там это и описано, но я его читал по диагонали и уже после реализации своего алгоритма.

[KRS]

Так вот, уважаемый aaarrr утверждает, что внутри такого 256-байтного блока, нельзя менять те его 16-байтные строки, в которых уже есть 0-ые биты, а можно менять только те 16-байтные строки, в которых только исключительно все биты ==1. Мне кажется это вполне правдоподобная версия и проверю её.

Это однозначно верно!!! Потому что так устроен флешь у NXP - 128 бит с ECC.


Правда штатно никто не гарантирует корректную запись блока поверх существующих данных! В любой новой ревизии легко может перестать работать. (поэтому в описании и нет ничего про 16 байт)