Проблема с LPC1768, Не записывается внутренний флеш по адресу 0x70000 Опции

[VslavX]

Имеется LPC1768. Написан свой загрузчик по UART, расположен в первых 16K флэш памяти. Все работало нормально. Но недавно программа увеличилась в размерах и потребовалась запись уже в предпоследний сектор флешки - по адресу 0x70000. И тут произошла засада - оно просто не пишется, функция IAP возвращает SUCCESS, а данные по адресу не записаны.
Начал разбираться что до как. В итоге есть две платы, на обоих LPC1768, но с разными маркировками. На одной память пишется нормально, на второй - такая вот ерунда. И эта проблемная плата не одна такая - на данный момент три опытные штуки, процессоры на них из одной партии.
Прочитал BootROM, дизассемблировал, нашел много интересного . У LPC-ей оказывается есть 2 килобайта теневого флеша, и там записано много любопытных вещей - ID процессора, точки старта, методы блокировки JTAG, и - таблица адресов секторов. Так вот - у сбойных чипов эта таблица для предпоследнего сектора содержит 0x78000 вместо законных 0x70000 в нормальном чипе. Такая информация в теневой флешке могла быть записана только на заводе. Вопрос такой - кто-нибудь уже написал такую большую программу для LPC17xx, что понадобился сектор по адресу 0x70000? Или просто у кого-нибудь были проблемы с флешкой по адресу 0x70000?

[scifi]

А вообще LPC1768 уже официально доведённый продукт? Может быть, это у Вас инженерные образцы?

[oman]

Прочитал BootROM, дизассемблировал, нашел много интересного . У LPC-ей оказывается есть 2 килобайта теневого флеша, и там записано много любопытных вещей - ID процессора, точки старта, методы блокировки JTAG, и - таблица адресов секторов.

не расскажешь как? ну или результаты поподробнее.
заранее спасибо

[GetSmart]

не расскажешь как? ну или результаты поподробнее.
заранее спасибо

Это всё в отладчике видно. Даже если нет отладчика, то просто залить прогу, которая будет сливать память (флэш) бутлодера через любой инентерфейс (UART например).

Вопрос такой - кто-нибудь уже написал такую большую программу для LPC17xx, что понадобился сектор по адресу 0x70000? Или просто у кого-нибудь были проблемы с флешкой по адресу 0x70000?

Чертовски странно. Я такую большую прогу не писал, но зато сохранял настройки по адресу 0x78000, в последний сектор. Проблем не было. Зачем было извращаться (разработчикам) с предпоследним сектором - непонятно.

[VslavX]

А вообще LPC1768 уже официально доведённый продукт? Может быть, это у Вас инженерные образцы?

Рабочие процессоры: S61873.1 ZSD0936- - 36 неделя 2009-го
Нерабочие процессоры: SU5617.1 ZSD1012- - 12 неделя 2010-го
Обе партии вполне серийные
Еще отличие - в ранних чипах загрузчик 4.1, в новых - 4.2. Судя по всему - загрузчик тоже записан во отдельную флеш, так как ревизия чипа не менялась, поэтому маловероятно чтобы делали новую маску только для изменения BootROM.

не расскажешь как? ну или результаты поподробнее.
заранее спасибо

Берем считываем отладчиком или своей программой 8 килобайт по адресу 0x1FFFE000 в файл, потом запускаем IDA и много думаем
Потом выясняем как осуществляется доступ к теневым 2K и соответственно пишем свою программку чтобы эти 2 килобайта прочитать.
А результаты пока такие что в партии процессоров в этих 2килобайтах глючная таблица адресов начала предпоследнего сектора

Чертовски странно. Я такую большую прогу не писал, но зато сохранял настройки по адресу 0x78000, в последний сектор. Проблем не было.

А для последнего сектора проблем и нету - для него в теневой таблице записан правильный базовый адрес.

[GetSmart]

FlashMagic тоже не может прописать адреса 0x70000..0x77fff ?

Сообщение отредактировал GetSmart - Dec 7 2010, 15:15

[VslavX]

FlashMagic тоже не может прописать адреса 0x70000..0x77ffff ?

Не пробовал. А что - это идея, надо бы проверить, спасибо. Правда у меня там RS-232 нету и перемычки на 2.10 тоже.

Upd: попробовал. Программа flashmagic ублюдочная - 6 мегабайт инсталлятор, полчаса грузит в свой внутренний буфер большой хекс файл.
Сначала просто выполнил стирание и записал большой файл. Он записался нормально! Я даже обалдел слегка. Потом вспомнил что IAP то возвращает успех. И записал снова и выполнил верификацию - опа - олень попался - ничего не записано! То есть баг тот же самый.
Общий итог - через FlashMagic и заводской загрузчик тоже не работает. И на том же самом месте.

В-общем-то у меня к NXP основная претензия - закрытость загрузчика и алгоритма записи в память. А теперь они еще и напортачили там

[GetSmart]

Возможно напортачили только в 2к теневого флэша. Ненарошно. Скорее всего это поправимо, ручками программера.

[VslavX]

Возможно напортачили только в 2к теневого флэша. Ненарошно. Скорее всего это поправимо, ручками программера.

Я на NXP написал, посмотрим что ответят. У нас таких чипов вроде всего около сотни пока куплено. Я думаю что патч для внутренней флешки они даже под NDA не дадут - а то можно будет, например, из 1766 программно делать 1768.

[GetSmart]

VslavX, у Вас есть код для чтение 2к теневого флэш 17хх?

[igorsk]

Теневой ром виден при установке бита 0x40 в слове 0x40084000. Виден по адресу 0.

[VslavX]

VslavX, у Вас есть код для чтение 2к теневого флэш 17хх?

А как бы я его иначе прочитал?

CODE

DWORD save[512];

__ramfunc void copy_hidden_flash(void)
{
DWORD i;
PDWORD s, d;

i = 512;
s = (PDWORD)NULL;
d = save;
*((volatile DWORD*)0x40084000) |= 0x40;
do
{
*d++ = *s++;
}
while(--i);
*((volatile DWORD*)0x40084000) &= ~0x40;
}

Функция должна быть в RAM, потому как программный флеш полностью отрубается при переключении на теневую флешку.
Приведенной выше функцией я скопировал теневой флеш в RAM и потом его уже разбирал.

[VslavX]

Я балдею дорогая редакция...
NXP ответил что девайсы маркированные с 11 по 34 неделю 2010 года могут иметь 480 килобайт флеша вместо 512 ("sector 28 should be skipped"). Эти чипы подлежат "ретестированию" (гы, теневую флешку перезапишут, нет чтобы кодом с народом поделитцо) и на упаковках таких "ретестированных" чипов приклеют этикетку "RESCREEN". Мои экземпляры предложили вернуть и обменять на нормальные. Я уже постеснялся переспрашивать "Ничо шо паянные?"
Капец процесс у них поставлен - полгода бнопню гнали.

[vmp]

В-общем-то у меня к NXP основная претензия - закрытость загрузчика и алгоритма записи в память.

А после дизассемблирования алгоритм записи в память не появился? Если напрямую, без использования их ПЗУ работать?
И как еще один вариант. Попробовать настроить регистры отладчика или MPU на перехват обращения к глючной части теневого ПЗУ и подправить результат.

[VslavX]

А после дизассемблирования алгоритм записи в память не появился? Если напрямую, без использования их ПЗУ работать?

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

И как еще один вариант. Попробовать настроить регистры отладчика или MPU на перехват обращения к глючной части теневого ПЗУ и подправить результат.

Думал я об этом, возни достаточно много - когда идет обращение к теневой флешке, то основная флеш не работает - это обработчик исключения надо в ОЗУ размещать, а все обработчики у меня по шаблону автогенерируюся и на HAL/RTOS завязаны. Но, наверное от шаблона отступить все-таки можно. MPU у меня уже используется, все регионы заняты, а вот точка останова по обращению к данным - вполне подойдет, cпасибо за идею.

Upd: почитал про DWT (Data Watchpoint and Trace) - не пойдет, процессор именно останавливается, а не генерирует исключение. Таки остается только MPU.

[vmp]

Upd: почитал про DWT (Data Watchpoint and Trace) - не пойдет, процессор именно останавливается, а не генерирует исключение. Таки остается только MPU.

А про Flash Patch and Breakpoint (FPB)? Как я понимаю, надо читать документацию от ARM, а не от NXP.

[VslavX]

А про Flash Patch and Breakpoint (FPB)? Как я понимаю, надо читать документацию от ARM, а не от NXP.

Угу, нуна читать "Cortex™-M3 r2p0 Technical Reference Manual".
FPB патчит I-шину, можно "на лету" заменить код инструкции. Мест там несколько, и одной инструкцией на место не обойдешься. На подпрограмму просто не перейдешь RAM от BootROM далеко, LR испортится, появляется вариабельность по версиям загрузчика и прочее. Проще патчить D-шину, а такой фичи в FPB нету. Хотя... Можно пропатчить на инструкцию SWI. Но, блин, это исключение у меня тоже используется. Думаю что на MPU сделать проще, во-первых не весь загрузчик дизассемблирован, возможно где-то есть еще обращения к глючной таблице, во-вторых c MPU уже досконально разобрался и он уже для виртуализации используется, проблема только в выносе части кода в RAM.

Upd: вчера провели ревизию склада - куплено пока всего две упаковки по 90 штук, на одной из них есть зеленая круглая наклейка и этикетка "RESCREEN". С MPU решил не возиться, вместо этого разбираю алгоритм прямой записи, хочется еще маленькими кусочками память писать а не по 256 байт.

[GetSmart]

С MPU решил не возиться, вместо этого разбираю алгоритм прямой записи, хочется еще маленькими кусочками память писать а не по 256 байт.

Вроде итак можно, хоть по 16 байт. Только ненужные байты забиваются 0xff.

Сообщение отредактировал GetSmart - Dec 10 2010, 23:13

[vmp]

Этот же баг обнаружился в LPC1759, SN1566.1 01 ZSD1009-.
Версия загрузчика 4.2.
Кстати, чтобы собрать всю информацию в одном месте:
Если смотреть память процессора через SWD с притянутой к земле P2.10 (запуск загрузчика), то по нулевым адресам видно ПЗУ загрузчика. Если с отпущенной - видно зашитую программу.
То же самое происходит при попытке верификации 0 сектора через ISP - возникает ошибка верификации.