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

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

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

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


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

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


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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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