Проблема следующая.

Не удаётся загрузить LPC3250 через последовательный интерфейс в режиме ‘Service boot’. Это режим загрузки, который включается при установке линии ‘BOOTSEL’ в ‘0’. В нём после ‘Reset’ из ROM процессора запускается заводской загрузчик ‘bootstrap’, который позволяет через UART5 загрузить во внутреннюю IRAM и запустить бинарник.

1. Выяснилось, что ‘bootstrap’ в запаянных на наши платы LPC3250 ревизии ‘-’ ведёт себя немного отлично от того, как он должен это делать судя по UserManual.
В UserManual говорится, что процесс ‘Service’ загрузки такой:
LPC32x0 Host
-> BootID (0x35=’5’)
<- 0x41=’A’
-> BootID (0x35=’5’)
<- 0x55=’U’
<- 0x33=’3’
-> 0x52=’R’
<- StartAddress (4 bytes)
<- CodeSize (4 bytes)
<- Code

А наш процессор почему-то в самом начале выдаёт не 1 код ‘BootID’ а сразу 2 штуки:

[смотри картинку "01_osc_dbl_'5'.png"]

Последующие этапы обмена процессор отрабатывает верно. Но у программы «LPC3250 Loader» из NXP’s CSP v2.01 “nxpmcu/software/csps/lpc32xx/tools/LPC3250 loader” всё равно сносит крышу и она прерывает процесс загрузки. (Причём физически два ‘BootID’ идут сразу друг за другом, а крышу у программы сносит немного позже, когда проходит несколько этапов обмена):

[смотри картинку "Serial_loader_dbl_'5'.PNG"]


2. Был сделан «Передатчик» на первой попавшейся подходящей плате, который транслирует данные с 1-го UART, подключенного к компьютеру, на 2-ой UART, подключенный к LPC3250. Но при трансляции «Передатчик» вырезает второй ‘BootID’, посылаемый LPC3250:

[смотри картинку "02_osc_do_single_'5'.png"]


После этого процесс ‘Service’ загрузки продвинулся дальше:

[смотри картинку "Serial_loader_cut_dbl_'5'.PNG"]


«LPC3250 Loader» начинает загружать бинарник. Но всё равно! Примерно через 1,42 секунды LPC3250 опять инициализирует процесс ‘Service’ boot, выдавая двойной ‘BootID’ и в дальнейшем выдавая ‘BootID’ в ответ на каждый байт продолжающегося грузиться бинарника:

[смотри картинку "07_osc_boot.png"]


3. Маркировка нашего LPC3250 следующая:

LPC3250FET296
POG454.00 01
ESD0920-

То есть ревизия нашего процессора ‘-’, дата производства: 11-17 Мая 2009 года.

PS: К сообщению прицеплен PDF с иллюстрациями: скриншоты и осциллограммы.
PPS: Также к сообщению прицеплены иллюстрации в виде отдельных файлов.

Here is illustrated problem description in PDF (in English).

Победить проблему не удалось, но обнаружилась интересная вещь. Из 3-х плат не работают 2 - глючит 'bootstrap' как описано выше. А на третьей плате всё работает нормально, загручик выдаёт, как и положено 1 'BootID', а затем нормально грузит бинарник.

Есть предположение, что процессоры на первых двух платах повреждены при монтаже. Перегрели их что ли, да так, что ROM слетела...

Ага. А всего-то - резет дважды идет...

'DpInRock' зря вы так, уж что-что, а Reset я в первую очередь проверял. И вообще, где по вашему должен случаться Reset? После передачи 1-го 'BootID' и перед 2-м? Не получается так... Обратите внимание, на осциллограмме 2 'BootID' идут без задержки друг за другом, как будто в контроллер UART были посланы cразу 2 байта.
А ещё после Reset'а в режиме 'Service Boot' загрузчик должен выполнить определённые действия: проинициализироваться самому, проверить "RTC_KEY", проверить и проинициализировать "OTG ATX", проинициализировать UART. И всё это на частоте ядра 13 МГц. Можно смело тактов 200-400 на все эти дела отвести. Было бы видно эту задержку на осциллограмме...

Подниму, пожалуй, тему.

У меня совсем глупый вопрос наверное, в программировании не силен. Случилось так, что нужно вручную переписать этот LPC3250 Loader с некоторым его интерфейсным облегчением. Но Я никак не пойму, как обратиться к конкретному адресу регистра в этой микрухе. Собственно не пойму, как передавая через VCP данные, она понимает, что Я ей передаю адрес, а не число? Вот например, следуя по даташиту, в процессе перехода в Service Boot нужно проверть RTC_KEY==0xB5C13F27 на правильность. А это значит, что нужно запросить это чиселко из конкретного регистра 0x4002 4018, ну или хотябы сразу туда его записать. В любом случае...В общем ступоры на ровном месте, почти убежден, что делается тривиально.

http://www.nxp.com/documents/user_manual/UM10326.pdf

Можно еще указать что. Я использую дрова ftd2xx. Поэтому как вариант можно сначала передать 4 байта 0x4002 4018 через функцию FT_WRITE(..., ..., ..., &...), потом еще 4 байта самого числа 0xB5C13F27 тоже через FT_WRITE(). Но вот будет ли оно работать так, как Я думаю, бог знает. Ей то до фени.

Судя по вопросу вы похоже никогда не писали програму для этого АРМа. Проще наити в примерах компилятора которым вы пользуетесь как обьявляются регистры. Вот например в IAR:
Кроме того когда вы передаете данные по UART в процессе boot, то следуете жесткому алгоритму зашитому в АРМ бутлоадере. Предполагаю вы хотите таким способом загрузить свои бутлоадер а затем продолжить загрузку через него. Тогда вам надо разработать свои протокол обмена с вашим бутлоадером.
Хотя глядя на ваш последнии абзац похоже я вас не до конца понял

Да, спасибо. Сегодня поковырял этот АРМ еще немного. Действительно там все жестко прописано, и только успевай слать нужные комбинации.

На самом деле задача, то предельно проста да вроде бы не очень. В процессе работы с этой платой требуется автоматизировать процесс залития кода в boot режиме. То есть убрать операции с нажатием кнопочек reset и p2.10. И сделать соответствующее управление через FT232R, установленную на эту плату. В теории можно было бы использовать программку, которая создает эмулированные порты на основе одного реального. То есть можно к одному порту подключить сразу несколько управляющих программок. И путем нажатия кнопки сброса DTR и RTS в приложении запускать процесс прошивки с помощью Loader'a, но тут обнаружился косяк с этими перемычками. Ибо LPC3250 Loader работает при незамкнутых перемычках сброса и р2.10, а FT-шка при замкнутых. ( Поэтому вот приходится вот так корячиться.

А в программировании Я олень, меня до сих пор вводят в ужас такие команды типа __READ_WRITE, и при программировании всяких AT90 стараюсь избегать все что с этим подчеркиванием. Беда нынешней системы управления будущими кадрами, в том числе и образовании.

У меня один в один реализация. Сигналы UART кроме TxD и RxD не использую. CBUS0 и CBUS1 запрограмировал каk IOs. Пустил их через полевики (инверторы) на SERVICE и RESET, не забудьте затворы на zемлю притянуть порядка 100к. Далее просто командами в FTDI пишите в CBUS0/1 единицу(ноль там после сброса), затем отпускаете RESET и начинаете общаться с ботлоадером. Был нюанс с COM портом. Я не использую VCP в драивере(убрал галочку). Кажется изза того что нельзя одновременно открыть FTDI для записи в IOs и VCP. Поетому по UARTу общался через простые команды READ/WRITE FTDI.
Далее загружаю свои ботлоадер которыи занимается загрузкои c PC основного кода и прошивки его на плате