Почему LPC2478 отказывается программироваться через JTAG?, Ничего не понимаю в этих АРМах :( Опции

[Dog Pawlowa]

Сделал какие-то коррекции большого проекта, загрузил в среде в контроллер, контроллер перестал программироваться вообще. Лог внизу.
Записал старую версию проекта через бутлоадер + 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) // если нажать - продолжить.

[VslavX]

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

[Dog Pawlowa]

Попробуйте так - подайте '0' на порт 2.10 - процессор после сброса перейдет на NXP-шный загрузчик и будет в нем "сидеть".

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

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

[zltigo]

Zltigo, есть шанс расширить функциональность a200 - войти в режим программирования, но не программировать

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

[Dog Pawlowa]

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

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

[zltigo]

И еще - все равно нужен терминал, то есть востребована ситуация снятия ISP с продолжением работы в терминалке, а после -boot снять ISP можно только при выходе, не так ли?

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

[Dog Pawlowa]

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

[defunct]

После часов работы с большим проектом в IAR+Jlink7, могу сделать некоторые выводы:
Если JTAG не подключен, то все хорошо.
Если JTAG подключен, и сделано несколько шагов по функции инициализации, то дальше все работает.
Если эти пару метров не проползти, то контроллер где-то виснет

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

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

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

Код

void UartInit(void)
{
    SYSCTL_RCGC1_R |= SYSCTL_RCGC1_UART0;  // enable peripheral clock for UART0

//<--- на первый взгляд тут все ОК, вначале включается клок, потом идет обращение к периферии, но
//    неучтено время подачи клока.
//    если между этими строчками вставить что-то еще весомое (напр инициализацию кольцевого буфера),
//    что даст требуемую задержку для подачи клока, то будет все в порядке.
//    если же между этими строками другого кода нет, тогда при "Run" - зависнет наглухо,
//    т.к. на момент выполнения второй строки клок еще к UARTу не подан.
//    при пошаговой отладке будет все ОК, т.к. требуемая задержка для подачи клока есть

    UART0_CTL_R = (UART_CTL_RXE) | (UART_CTL_TXE) | (UART_CTL_UARTEN); // enable RX, TX and UART unit
}

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

Жалко, что с самого начала не пошли по пути кросс-отладки на PC с частичной симуляцией железа.

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

[Dog Pawlowa]

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

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

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

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

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

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