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 такая запись без стирания возможна. В еррате ничего нет.

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

[aaarrr]

Дозапись возможна, но только блоками, размер которых кратен 16 байтам. По крайней мере, для LPC13xx так. В мануале на 17xx вопрос обошли стороной почему-то...

[jcxz]

Ясен пень - пишу блоками по 256 (пробовал и по 512). Иначе бы IAP вообще вылетал-бы с ошибкой.
И в UM на 17x не обошли это стороной - чётко указаны возможные размеры блоков для записи:
------------------------------------------------------------------------------------------
Param0(DST): Destination flash address where data bytes are to be written. This
address should be a 256 byte boundary.
Param1(SRC): Source RAM address from which data bytes are to be read. This
address should be a word boundary.
Param2: Number of bytes to be written. Should be 256 | 512 | 1024 | 4096.
------------------------------------------------------------------------------------------

Ясно что перед записью своей записи, я определяю границы блока выбранного размера, в который она входит, считываю данные блока в буфер в ОЗУ,
копирую туда свою запись, и потом пишу весь блок.

[aaarrr]

Ясен пень - пишу блоками по 256 (пробовал и по 512). Иначе бы IAP вообще вылетал-бы с ошибкой.

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

Ясно что перед записью своей записи, я определяю границы блока выбранного размера, в который она входит, считываю данные блока в буфер в ОЗУ,
копирую туда свою запись, и потом пишу весь блок.

Так вот "своя запись" выровнена по границе 16?

[Axel]

Вполне себе работает. У меня таким образом организован кольцевой буфер из двух 32к секторов (контроллер LPC1778, блоки по 256 байт). Может у Вас чего не так с таймингом?

[jcxz]

Не о тех блоках речь. На каждые строку (16 байт) флеш приходится один байт ECC, поэтому дозапись страницы можно вести исключительно целыми строками.
Так вот "своя запись" выровнена по границе 16?

Хмм... Нет, она выровнена только на 4.
Странно, что нигде в UM нет упоминания про это... Надо будет попробовать. Спасибо за наводку!

Может у Вас чего не так с таймингом?

Что Вы имеете в виду?

[Axel]

Что Вы имеете в виду?

Да собственно ничего кроме настроек регистра FLASHCFG и парметра частоты при вызове функций IAP драйвера

[jcxz]

SYSCFG.FLASHCFG = (CCLK - 1) / 20000 << 12 | 0x3A;
где: CCLK - тактовая процессора [кГц]. Это-же значение передаётся IAP.
Если с предварительным стиранием, то Flash пишется нормально всегда.

[Axel]

SYSCFG.FLASHCFG = (CCLK - 1) / 20000 << 12 | 0x3A;
где: CCLK - тактовая процессора [кГц]. Это-же значение передаётся IAP.

Ну да, у меня так же... Пока действительно, кроме выравнивания идей нет.

[Sanya_kv]

Та же проблема (В один блок нельзя писать более 1 раза без стирания).
Ошибка происходит не всегда, а при некоторой комбинации данных (у меня происходила примерно 1/20). Зависимость не выявил.
При записи изменял байты, которые до этого были равны 0xFF. Например до записи блок == 12 34 FF FF FF FF ..., записываю 12 34 56 78 FF FF ..., по идее должно получиться 12 34 56 78 FF FF ..., но почему-то не всегда.
Пробовал писать блоки по 256, 512 и по 1к. Делал частоту в 2 раза медленней. Победить проблему так и не удалось. Обнаружил достаточно давно на LPC24xx, далее подтвердилась на LPC1778.
Ставит в тупик, это то что иногда ошибка появляется появляется в соседнем блоке, отличном от кого в который писал.
Данная тема уже подымалась на этом форуме в районе 1 - 2-х лет назад.

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

Спасибо за инфу. Как доберусь до железки обязательно проверю.

[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)

[aaarrr]

а вот в 17xx и 11xx ограничение в 256 байт есть.

Оно и для 13xx есть, записать можно только целую страницу, 256 или более байт.
Вопрос же стоит в возможности и ограничениях по дозаписи внутри страницы.
Кстати, в мануале на LPC11 работа ECC тоже описана (26.3.7).

[jcxz]

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

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

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

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

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