ARM удумал новый отладочный интерфейс. Причем даже не отладочный интерфейс, а прошивку на базе CMSIS для железного отладчика который через RDDI-DAP dll общается с дебагером на хосте.



проект в стадии: Version 0.01 - Beta (даты файлов 19.06.2012)

ЗЫ ознакомится можно в местных закромах.

Отличная новость.
Как понимаю, дело обстоит так, что теперь можно приобрести плату LPC-Link-II , например в составе LPCXpresso, залить туда прошивку из CMSIS-DAP и получить JTAG отладчик круче чем J-Link или его клоны?

Странно только, что вместе с исходниками не дают схемы того самого LPC-Link-II.

Впрочем имея исходники никто не мешает сделать свой JTAG отладчик на любом микроконтроллере.
Ну щас гонка копеечных JTAG-ов начнется!

Оптимально LPC1343. ROM HID можно заюзать, да и прошиву первоначально залить через встроенный usb загрузчик.

Только вот быстрее J-Link оно вряд ли будет. У J-Link годами наработанная поддержка, исполняемый код в отлаживаемых контроллерах, "аппаратный" JTAG и оптимизированный BULK. А здесь похоже пока только ногодрыг по HID USB. Ну и только Keil (хотя это будет недолго).

тут весь вопрос в скорости, причем даже не самого "ногодрыганья" для JTAG или SWD, а именно обмена с компом. Т.к. USB еще и HID если не будет нормальной очереди команд каждая транзакция по USB в лучшем случае 2 ms.

Например на Beaglebone установлен XDS100v2 (просто FTDI) подключил к IAR (ну о том что он работает один раз, потом надо перегружать среду, я не буду говорить, т.к. он использует тулзы от TI) но только при открытых регистрах CPU время шага несколько секунд. Потому что вместо того что бы сразу спустить вниз очередь команд и получить ответ, все идет мелкими шажками по 2 ms....



Даже ногодрыганьем можно получить отличную скорость - главное что бы с хостом нормальные очереди команд были!
Не только keil, еще DS-5. Т.е. возможно будет получить отладчик для Cortex-Ax.
Хотя сейчас IAR уже умеет работать через J-link, например с Beaglebone AM3359 попробовал!

Именно это и имел ввиду - "ногодрыг по HID USB".

Протокол в общем не уровня GDB сервер, где уже сразу память, регистры процессора и т.п. читаются.
Но и гораздо выше уровня ногодрыганья! Блочная передача, полинг DAP регистра есть. В общем название правильное - протокол именно доступа к DAP. Скорость должна вполне приличная получиться.

Есть желающие поковыряться?
По быстрому совокупил с примером HID для LPC1343.
Вроде подает признаки жизни - девайс определяется, реагирует на настройки.
Но дальше что то никак...
В части ногодрыга все на макросах.
Что то лыжи остановилмсь
Сообща все веселее...

ЗЫ:
Нашел ашЫПку:


Клокается вроде все правильно, но все-равно не дышит...

IMHO для начала надо попробовать законнектится через SWD и считать IDCODE напрямую вызывая функции SW-DP.
Там в начале надо подать от 50 клоков при SWDIO = 1 (что бы очистить возможные незавершенные транзакции), потом подать 0xE79E, потом еще раз от 50 клоков при SWDIO = 1.
А потом считать IDCODE.

Дык задача так не стоит - во что бы то ни стало к чему-нить подключиться...
Задача - заюзать в том же Keil штатно без всякого шаманства

Ну так надо же определить почему не работает.
А хотя бы лог команд которые по USB приходят есть?

Теперь есть:



Для LPC1768:
Сначала 51 клок при высоком уровне и 8 клоков при низком
Срубается на команде ID_DAP_Transfer
01 02 посылается и ожидается от LPC1768 3 бита подтверждения ACK.
Смотрел осциллографом - LPC не отвечает...

Для STM32 ( ничего не подключено):

DAP command = 12 Seq: 33-FF FF FF FF FF FF FF
DAP command = 12 Seq: 10-B6 ED 00 00 00 00 00
DAP command = 12 Seq: 33-FF FF FF FF FF FF FF
DAP command = 12 Seq: 08-00 00 00 00 00 00 00
DAP command = 05 Seq: 00-01 02 00 00 00 00 00
DAP command = 03 Seq: 00-00 00 00 00 00 00 00
DAP command = 01 Seq: 00-00 00 00 00 00 00 00

Так 0xE79E не посылается - чип не будет по SWD работать! (может LPC1000 и будет т.к. JTAG нету) но именно эта последовательность переключает на SWD!


посмотрел свои старые исходники на битбанге - у меня 16 клоков при низком уровне.

т.е. общая последовательность такая:
64 клока при высоком уровне.
16 клоков отправка 0xE79E
16 клоков при низком уровне
50 клоков при высоком уровне
16 клоков при низком уровне

Первые 64 клока нужны для очистки состояния если SWD уже работал.
я уже не помню зачем нужны 16 клоков при низком уровне.

Но 0xE79E надо обязательно посылать!

Может быть Вам просто стоит подправить исходники что бы при первой команде ID_DAP_SWD_Configure или ID_DAP_SWD_Clock отправлялось
64 клока при высоком уровне.
16 клоков отправка 0xE79E
16 клоков при низком уровне

Первым делом это попробовал, гогда углУбился
Правда подавал по 55 "единичек".

При взведенной галке "SWJ" последовательность отрабатывается как на нижнем логе ("для STM") всегда.
(просто для LPC забыл выставить).

Но там может и с командой ID_DAP_Transfer тоже что то не так.
Не срабатывает...

Вычитал в сети такое:
"
> + /* More than 50 TCK/SWCLK cycles with TMS/SWDIO high,
> + * putting both JTAG and SWD logic into reset state.
> + */
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
> + /* Switching sequence enables SWD and disables JTAG
> + * NOTE: bits in the DP's IDCODE may expose the need for
> + * an old/deprecated sequence (0xb6 0xed).
> + */
> + 0x9e, 0xe7,
> + /* More than 50 TCK/SWCLK cycles with TMS/SWDIO high,
> + * putting both JTAG and SWD logic into reset state.
> + */
> + 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
"

DLL-ки из Keil и из вашего архива выдают такую байду (0xb6 0xed) ...
Пускай авторы допиливают
Увы, суетиться, думаю, (пока?) нет смысла.
Возможно, что драйвер требует какие то вендорские команды для правильной настройки -
И все не так уж красиво и открыто?

Кстати, а где удалось тиснуть архивчик, если не секрет?
Что то в открытом доступе я его не нашел...

Да в открытом доступе ее нет, но новее у них ничего нет.

Да там исходники ногодрыганья не так интересны, как хидеры! Особенно которые лежат в папке RDDI.
К тому же там написано что их скоро удалят и внесут в RDDI, который не во всех вариантах доступен.
А вот DLL можно написать свою и получить отладчик даже на FTDI для DS-5

К тому же в исходниках RDDI/example лежит преобразователь RDDI-DAP в RDDI-CMSIS-DAP (в верхнем коменте в файле неверно указано, к ULINK это не имеет отношения вроде)
т.е. видно еще один вариант RDDI будет.

Не могу сказать про LPC - но я скачал файл CMSISDAP-DL-00001-r0p1-00rel0.zip
Переделал его под STM32F103, присоединил его к STM32VLDISCOVERY и по крайне мере тест проходит.

Сообщение отредактировал x893 - Sep 28 2012, 04:14