Сделал какие-то коррекции большого проекта, загрузил в среде в контроллер, контроллер перестал программироваться вообще. Лог внизу.
Записал старую версию проекта через бутлоадер + at200. Все работает. Вернулся к последней версии большого проекта. Он запрограммировался один раз, и все повторилось сначала.
1) И как ошибки искать? Что такое криминальное я мог сделать? Всего, что добавил - циклические буферы по UART0.
2) Может, JTAG нужно как-то совсем правильно подключать? Сейчас RTCK не подключен, может это увеличит возможность перепрограммирования через JTAG?

Кстати, zltigo, Вы, как автор at200 - сброс в режиме бутлоадера в какие моменты должен подаваться?
Этот вопрос отпал - фирменный нуль-модемный кабель был без перемычек 4-6.

Спасибо

Mon Mar 02 13:55:51 2009: Loaded macro file: D:\Program Files\IAR ARM 520\ARM\config\flashloader\NXP\LPC23xx24xx.mac
Mon Mar 02 13:55:52 2009: DLL version: V3.90d, compiled Sep 1 2008 13:56:39
Mon Mar 02 13:55:52 2009: Firmware: J-Link ARM V6 compiled Jul 30 2008 11:24:59
Mon Mar 02 13:55:52 2009: JTAG speed is initially set to: 32 kHz
Mon Mar 02 13:55:52 2009: TotalIRLen = 4, IRPrint = 0x01
Mon Mar 02 13:55:52 2009: Resetting target using RESET pin
Mon Mar 02 13:55:52 2009: TotalIRLen = 4, IRPrint = 0x01
Mon Mar 02 13:55:52 2009: Halting CPU core
Mon Mar 02 13:55:52 2009: Using DBGRQ to halt CPU
Mon Mar 02 13:55:52 2009: Resetting TRST in order to halt CPU
Mon Mar 02 13:55:52 2009: Resetting target using RESET pin
Mon Mar 02 13:55:52 2009: TotalIRLen = 4, IRPrint = 0x01
Mon Mar 02 13:55:53 2009: Halting CPU core
Mon Mar 02 13:55:53 2009: Using DBGRQ to halt CPU
Mon Mar 02 13:55:53 2009: Resetting TRST in order to halt CPU
Mon Mar 02 13:55:56 2009: Hardware reset with strategy 0 was performed
Mon Mar 02 13:55:56 2009: Initial reset was performed
________тут появляется сообщение - не могу остановить ядро
Mon Mar 02 13:55:56 2009: Fatal error: Scan chain length is expected to be 4 or 5. Found (0) // если нажать - продолжить.

А может вы случайно JTAG отключили, ну там настройки GPIO например (особенно регистры PINSEL)

Можно узнать, как с помощью регистров PINSEL отключить JTAG? ETM можно, JTAG не нашел.

да у 24xx действительно PINSEL не влияет на ноги JTAG.
но бутлоадер как то умеет его отключать. на прежних чипах это как раз делалост через PINSEL

Программа виснет где-то в дебрях инициализации efsl, буду разбираться почему и делать дополнительные проверки.

Но ситуация с невозможностью возобновления работы по JTAG без бутлодера непонятна и весьма огорчает.

Для LPC21xx где-то в AN было документировано управление активизацией JTAG - на первых порах даже закладывал возможность "секретной" командой с консоли активизировать заблокированный в bootloader JTAG - потом как-то все это похерил за ненадобнстью и сейчас уже в текущих исходниках не нашел . Действительно, возможно на этот регистр наступили. А может и все много проще, например, грохнули тактовый генератор.....




Неважно, главное сниматься при установленной перемычке bootloader-а.

Может, вот так:

Попробуйте так - подайте '0' на порт 2.10 - процессор после сброса перейдет на NXP-шный загрузчик и будет в нем "сидеть". Если специально CRP не активировали то JTAG должен "откликнуться". Я таким образом решал проблему "отваливания" JTAG-а при активации энергосберегающего режима Idle на LPC23xx.

Спасибо за подсказку, запустил программку, дергающую флоу-контролем порта, вроде помогает.
Последовательность такая: RTS ON, DTR ON-OFF (reset), запуск отладки, через пару секунд RTS OFF.

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

Дык, это вроде ключик -boot был всегда, или не работает?

Дык в ключиках еще разбираться надо!
Ключик действительно есть, но сейчас проверить не могу.
И еще - все равно нужен терминал, то есть востребована ситуация снятия ISP с продолжением работы в терминалке, а после -boot снять ISP можно только при выходе, не так ли?

Так это в консоле bootloader-a директивой G address куда угодно послать можно. Собственно так и происходит в AT200 после заливки - если есть в HEX файле адрес точки входа, то по нему и переходит, если нет - тогда уж сброс. Состояние перемычки, контрольной суммы векторов, естественно, при переходе совершенно безразлично.

После часов работы с большим проектом в IAR+Jlink7, могу сделать некоторые выводы:
Если JTAG не подключен, то все хорошо.
Если JTAG подключен, и сделано несколько шагов по функции инициализации, то дальше все работает.
Если эти пару метров не проползти, то контроллер где-то виснет
Аналогичный результат у коллег и на других экземплярах платы, и с клоном MT-link.
Старт-кит на старой ревизии LPC2478 работает устойчиво.
Жалко, что с самого начала не пошли по пути кросс-отладки на PC с частичной симуляцией железа.

В таких случаях надо проверить порядок инициализации всего. Или по крайней мере того, что подвержено Вашим изменениям. Старая версия осталась? diff сделать можно?

В Atmel'ах натыкался на аналогичный симптом - если обращаться к периферии от которой отключен клок на момент обращения.
В LM3S тоже натыкался на аналогичную батву, пошагово все ОК, делаешь Run - и глухой вис. Причина та же - обращение к регистрам периферии к которой еще не подан клок.

вот, что я имею в виду (упрощенно):



Может и в LPC24xx есть нечто подобное? (просьба сильно не пинать - 24xx серию не пробовал пока).


Да ерунда эта кросс отладка на PC, она бы наверняка ничего не дала в такой ситуации. Только нахлебались бы ошибок "симуляции", а в реальном железе получили бы ту же проблему.
Двойная работа короче говоря.

Спасибо за идею, где-то в районе инициализации клока и GPIO все и происходит. Действительно было обращение без инициализации клока. Убрал - стало устойчивее. Еще поиграюсь с задержками ну и некоторые тупые ожидания разблокирую по тайм-ауту с переинициализацией.


Тут еще и "чиста" софта полно - экраны, события, менюшки... Не связанного с железом, я такую отладку имел виду.

Охренеть, простите.
Висим. Кликаю на останов. По коду - не в прерывании, в начале подготовки дебажного сообщения проверяется полнота отправки предыдущего. Оно не отправляется - потому что в VICADDRESS вектор прерывания таймера (нулевой приоритет), а прерывание UARTа приоритет 1.
Такого не может быть потому что не может быть никогда!