EEVblog Electronics Community Forum

Electronics => Microcontrollers => Topic started by: technix on May 05, 2021, 03:58:29 am

Title: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 05, 2021, 03:58:29 am
I am not talking about debugging with a CMSIS-DAP, I am talking about debugging the debugger itself.

The project is about putting a full JTAG + SWD debugger into a STM32F042F4 chip. The existing DAP42 project by Devan Lai only supports SWD, not full JTAG, and it is too large for my 16kB chip.

Currently I have the following fails when coupled to OpenOCD:

* The JTAG to SWD dance doesn't work.
* While I can scan the JTAG chain, access to the TAP is not fully working.

Can someone give me some pointers at what I should look at?
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 05, 2021, 04:12:54 am
I have this https://github.com/ataradov/free-dap . It is SWD-only as well, but it will fit into 16 kB chip easily.

As far as JTAG goes, the whole thing  boils down to one function (dap_jtag_sequence() in my case). So if you have something working at all, it all should be working.

And you can have a look at the  official ARM firmware. Again, you don't need the whole thing, just this function.

What specifically fails in your case?

I did not implement JTAG since I did not have any targets on hand to test it. I don't think I've ever seen  JTAG work over CMSIS-DAP.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 05, 2021, 04:18:43 am
I have this https://github.com/ataradov/free-dap . It is SWD-only as well, but it will fit into 16 kB chip easily.
Thanks to the link and I will look into it.

As far as JTAG goes, the whole thing  boils down to one function (dap_jtag_sequence() in my case). So if you have something working at all, it all should be working.

And you can have a look at the  official ARM firmware. Again, you don't need the whole thing, just this function.
Can I just transplant code from official ARM code to this?

What specifically fails in your case?
I have no idea how to read openocd -d3 output. I will post a console dump later for checking.

I did not implement JTAG since I did not have any targets on hand to test it. I don't think I've ever seen  JTAG work over CMSIS-DAP.
I have a board that paired that CMSIS-DAP to an LPC2103, so JTAG is a must have. Also for my boards I do tend to prefer full JTAG over SWD for it being full duplex can allow for some fast debugging actions.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 05, 2021, 04:31:21 am
Can I just transplant code from official ARM code to this?
Yes, with obvious corrections for the pin manipulation function names. The function just takes raw payload of the frame sent over USB and expects to produce the response payload. So parsing of that data would be very similar. I have not looked at the official code in great details, but it does something very similar.

I have no idea how to read openocd -d3 output. I will post a console dump later for checking.
I have not used OpenOCD. But it may be a source of errors too, I don't know how much testing JTAG over CMSIS-DAP is tested.

Also for my boards I do tend to prefer full JTAG over SWD for it being full duplex can allow for some fast debugging actions.
With the same clock frequency SWD has higher throughput. It is a well designed interface.

Bidirectional nature of the JTAG does not help, since you are still clocking in dummy cycles to get your data back. There cases where data is sent and received at the same time are extremely rare, and usually it is just a few status bits.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 05, 2021, 05:30:01 am
With the same clock frequency SWD has higher throughput. It is a well designed interface.

Bidirectional nature of the JTAG does not help, since you are still clocking in dummy cycles to get your data back. There cases where data is sent and received at the same time are extremely rare, and usually it is just a few status bits.
There are some other features of JTAG I use:

* JTAG is, in a sense, multi-drop. I can have multiple chips hooked to the same JTAG chain regardless of vendor, for example STM32F103 + XC2C32A. Ever since I start using this cross-vendor multi-drop feature of JTAG, I have standardized my JTAG connector on all designs into the ARM CoreSight Debug 10-pin interface and built adapters that converts all kinds of other pinouts into that.
* I can do boundary scan over JTAG as well, not just debugging. That would be useful for testing, and especially for writing to external memory devices as I would be able to bit bang the memory bus without software support. Even my planned retro projects will have JTAG-enabled bus transceivers so I can use surface-mount Flash ROM.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 05, 2021, 05:40:42 am
JTAG does have some advantages, for sure. For ARM-only devices SWD in theory has multi-drop as well, but I've never seen it used in practice.

As far as boundary scan and memories go, it depends. If you are using standard tools, then they are would likely to be made for plain JTAG and its boundary scan mode.

But if you are doing custom tools, then SWD lets you do the same thing and even better. You can actually initialize the related peripheral (SPI for example) and just use that to access your memories. Just like you would from the running application. Or even bit bang through the normal port controller.

Bit-banging SPI protocol over extest on a device with a long scan chain is not the fastest enterprise.

I did not realize that at least some STM parts support JTAG for actual system access, not just for boundary scan. I'll see if I can use one of them as a test target and finally implement JTAG too.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 05, 2021, 06:17:17 am
JTAG does have some advantages, for sure. For ARM-only devices SWD in theory has multi-drop as well, but I've never seen it used in practice.
AFAIK even with multiple ARM chips you have to use JTAG mode if you want to chain them in multi-drop. Multi-drop SWD requires chip support, but AFAIK nobody bothered to implement it, at least not on chips with only one core in it.

As far as boundary scan and memories go, it depends. If you are using standard tools, then they are would likely to be made for plain JTAG and its boundary scan mode.

But if you are doing custom tools, then SWD lets you do the same thing and even better. You can actually initialize the related peripheral (SPI for example) and just use that to access your memories. Just like you would from the running application. Or even bit bang through the normal port controller.
Standard tools means I can use this with other chips, not just ARM Cortex ones. Legacy ARM7 and ARM9 never supported SWD. There are FPGAs and CPLDs. Ann there are also JTAG-enabled bus transceivers.

Bit-banging SPI protocol over extest on a device with a long scan chain is not the fastest enterprise.
Sometimes you just have to do it. However usually the most I need to do is write a bootloader like U-Boot, then it is all running over high speed comms like USB and Ethernet.

I did not realize that at least some STM parts support JTAG for actual system access, not just for boundary scan. I'll see if I can use one of them as a test target and finally implement JTAG too.
AFAIK All STM32 except the Cortex-M0(+) parts have full JTAG. STM32L4's JTAG is bugged though as you can not run 4-wire JTAG with nJTRST pin released for GPIO.

I have a ready-made board design for you if you want - a STM32F042F4 and a STM32F103C8 on the same board, with the STM32F042 have access to STM32F103's JTAG, RESET and BOOT0 pins. (It also have Arduino Zero pinout, battery holder for RTC and a built-in USB hub as a clutter reducer.)
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 05, 2021, 06:22:35 am
AFAIK All STM32 except the Cortex-M0(+) parts have full JTAG. STM32L4's JTAG is bugged though as you can not run 4-wire JTAG with nJTRST pin released for GPIO.
I found a random STM32F334 Nucleo board that I have around. I'll play with JTAG on it.

I wanted to implement JTAG for quite some time, just could not figure out the test target. Now I have a target.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 05, 2021, 06:46:20 am
I found a random STM32F334 Nucleo board that I have around. I'll play with JTAG on it.
Make sure you erase that chip beforehand, as STM32 do allow applications to release JTAG pins to use them for GPIO.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 05, 2021, 06:49:27 am
Also saying, for the STM32F042 CMSIS-DAP devices I use as embedded debuggers, they always have a USB CDC in the composite, and that CDC port usually also comes with DTR-controlled reset pulses and 1200 baud activated bootloader entry.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 05, 2021, 07:12:06 am
Make sure you erase that chip beforehand, as STM32 do allow applications to release JTAG pins to use them for GPIO.
It has the default blinky firmware in it, I doubt it does anything with the JTAG.

I've got this board many years ago when it was first released. I think ST ran some promotion where the board was $10 and shipping was free or something like that. I never needed the board for anything until now, apparently.

But also, how would you erase the device without access to JTAG? There is no dedicated erase pin. Other ST devices let you hold the RESET while establishing the connection and resetting the core internally through DHCSR. This prevents the firmware from running, so it never has a chance to do anything with the debug pins.

Anyway, I'm not too interested in supporting that chip in any of my tools. So I'll implement JTAG in the free-dap, and see if I can make it work with OpenOCD. Or just hack up my tool to have basic support, just enough for testing.

Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 05, 2021, 07:18:18 am
It has the default blinky firmware in it, I doubt it does anything with the JTAG.
I doubt it either. You can just try though, and if the program did disable JTAG, you will have to erase it, probably over SWD.

But also, how would you erase the device without access to JTAG? There is no dedicated erase pin. Other ST devices let you hold the RESET while establishing the connection and resetting the core internally through DHCSR. This prevents the firmware from running, so it never has a chance to do anything with the debug pins.
SWD. Or you can use the on-chip bootloader.

Anyway, I'm not too interested in supporting that chip in any of my tools. So I'll implement JTAG in the free-dap, and see if I can make it work with OpenOCD. Or just hack up my tool to have basic support, just enough for testing.
What chips do your tool to support? What do you mean by tools too?
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 05, 2021, 07:36:41 am
SWD pins can be disabled too. But that is not a problem, the reset pin will let you recover from any state.

I'm talking about this tool https://github.com/ataradov/edbg

I generally support only MCUs I use personally. But this one may be a good candidate to support over both SWD and JTAG.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 05, 2021, 12:32:59 pm
Here is my current code making an attempt at a STM32F103 over JTAG:

Code: [Select]
$ openocd -d3 -f interface/cmsis-dap.cfg -c "transport select jtag" -c "adapter_khz 1000" -f target/stm32f1x.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
[url]http://openocd.org/doc/doxygen/bugs.html[/url]
User : 13 6 options.c:63 configuration_output_handler(): debug_level: 3
User : 14 6 options.c:63 configuration_output_handler():
Debug: 15 6 options.c:244 add_default_dirs(): bindir=/usr/local/Cellar/open-ocd/0.11.0/bin
Debug: 16 6 options.c:245 add_default_dirs(): pkgdatadir=/usr/local/Cellar/open-ocd/0.11.0/share/openocd
Debug: 17 6 options.c:246 add_default_dirs(): exepath=/usr/local/Cellar/open-ocd/0.11.0/bin
Debug: 18 6 options.c:247 add_default_dirs(): bin2data=../share/openocd
Debug: 19 6 configuration.c:42 add_script_search_dir(): adding /Users/user/Library/Preferences/org.openocd
Debug: 20 6 configuration.c:42 add_script_search_dir(): adding /Users/user/.config/openocd
Debug: 21 6 configuration.c:42 add_script_search_dir(): adding /Users/user/.openocd
Debug: 22 6 configuration.c:42 add_script_search_dir(): adding /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/site
Debug: 23 6 configuration.c:42 add_script_search_dir(): adding /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts
Debug: 24 7 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/interface/cmsis-dap.cfg
Debug: 25 7 command.c:146 script_debug(): command - adapter driver cmsis-dap
Debug: 27 8 command.c:146 script_debug(): command - transport select jtag
User : 28 8 options.c:63 configuration_output_handler(): jtagUser : 29 8 options.c:63 configuration_output_handler():
Debug: 30 8 command.c:146 script_debug(): command - echo DEPRECATED! use 'adapter speed' not 'adapter_khz'
User : 32 8 command.c:769 jim_echo(): DEPRECATED! use 'adapter speed' not 'adapter_khz'
Debug: 33 8 command.c:146 script_debug(): command - adapter speed 1000
Debug: 35 8 core.c:1822 jtag_config_khz(): handle jtag khz
Debug: 36 8 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 37 8 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
User : 38 8 options.c:63 configuration_output_handler(): adapter speed: 1000 kHz
User : 39 8 options.c:63 configuration_output_handler():
Debug: 40 9 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/target/stm32f1x.cfg
Debug: 41 10 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/target/swj-dp.tcl
Debug: 42 10 command.c:146 script_debug(): command - transport select
Debug: 43 10 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/mem_helper.tcl
Debug: 44 11 command.c:146 script_debug(): command - add_usage_text mrw address
Debug: 46 11 command.c:1115 help_add_command(): added 'mrw' help text
Debug: 47 11 command.c:146 script_debug(): command - add_help_text mrw Returns value of word in memory.
Debug: 49 11 command.c:1128 help_add_command(): added 'mrw' help text
Debug: 50 11 command.c:146 script_debug(): command - add_usage_text mrh address
Debug: 52 11 command.c:1115 help_add_command(): added 'mrh' help text
Debug: 53 11 command.c:146 script_debug(): command - add_help_text mrh Returns value of halfword in memory.
Debug: 55 11 command.c:1128 help_add_command(): added 'mrh' help text
Debug: 56 11 command.c:146 script_debug(): command - add_usage_text mrb address
Debug: 58 11 command.c:1115 help_add_command(): added 'mrb' help text
Debug: 59 11 command.c:146 script_debug(): command - add_help_text mrb Returns value of byte in memory.
Debug: 61 11 command.c:1128 help_add_command(): added 'mrb' help text
Debug: 62 11 command.c:146 script_debug(): command - add_usage_text mmw address setbits clearbits
Debug: 64 11 command.c:1115 help_add_command(): added 'mmw' help text
Debug: 65 11 command.c:146 script_debug(): command - add_help_text mmw Modify word in memory. new_val = (old_val & ~clearbits) | setbits;
Debug: 67 11 command.c:1128 help_add_command(): added 'mmw' help text
Debug: 68 11 command.c:146 script_debug(): command - transport select
Debug: 69 11 command.c:146 script_debug(): command - transport select
Debug: 70 11 command.c:146 script_debug(): command - transport select
Debug: 71 11 command.c:146 script_debug(): command - jtag newtap stm32f1x cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3ba00477
Debug: 72 11 tcl.c:572 jim_newtap_cmd(): Creating New Tap, Chip: stm32f1x, Tap: cpu, Dotted: stm32f1x.cpu, 8 params
Debug: 73 11 tcl.c:596 jim_newtap_cmd(): Processing option: -irlen
Debug: 74 11 tcl.c:596 jim_newtap_cmd(): Processing option: -ircapture
Debug: 75 11 tcl.c:596 jim_newtap_cmd(): Processing option: -irmask
Debug: 76 11 tcl.c:596 jim_newtap_cmd(): Processing option: -expected-id
Debug: 77 11 core.c:1488 jtag_tap_init(): Created Tap: stm32f1x.cpu @ abs position 0, irlen 4, capture: 0x1 mask: 0xf
Debug: 78 11 command.c:146 script_debug(): command - dap create stm32f1x.dap -chain-position stm32f1x.cpu
Debug: 79 11 command.c:146 script_debug(): command - transport select
Debug: 80 11 command.c:146 script_debug(): command - jtag newtap stm32f1x bs -irlen 5
Debug: 81 11 tcl.c:572 jim_newtap_cmd(): Creating New Tap, Chip: stm32f1x, Tap: bs, Dotted: stm32f1x.bs, 2 params
Debug: 82 11 tcl.c:596 jim_newtap_cmd(): Processing option: -irlen
Debug: 83 11 core.c:1488 jtag_tap_init(): Created Tap: stm32f1x.bs @ abs position 1, irlen 5, capture: 0x1 mask: 0x3
Debug: 84 11 command.c:146 script_debug(): command - target create stm32f1x.cpu cortex_m -endian little -dap stm32f1x.dap
Debug: 85 12 command.c:376 register_command(): command 'rtt' is already registered in '<global>' context
Debug: 86 12 command.c:146 script_debug(): command - stm32f1x.cpu configure -work-area-phys 0x20000000 -work-area-size 0x1000 -work-area-backup 0
Debug: 87 12 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 88 12 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 89 12 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 90 12 command.c:146 script_debug(): command - flash bank stm32f1x.flash stm32f1x 0x08000000 0 0 0 stm32f1x.cpu
Debug: 92 13 tcl.c:1319 handle_flash_bank_command(): 'stm32f1x' driver usage field missing
Debug: 93 13 command.c:146 script_debug(): command - adapter speed 1000
Debug: 95 13 core.c:1822 jtag_config_khz(): handle jtag khz
Debug: 96 13 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 97 13 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 98 13 command.c:146 script_debug(): command - adapter srst delay 100
Debug: 100 13 command.c:146 script_debug(): command - transport select
Debug: 101 13 command.c:146 script_debug(): command - jtag_ntrst_delay 100
Debug: 103 13 command.c:146 script_debug(): command - reset_config srst_nogate
Debug: 105 13 command.c:146 script_debug(): command - transport select
Debug: 106 13 command.c:146 script_debug(): command - cortex_m reset_config sysresetreq
Debug: 108 13 command.c:146 script_debug(): command - stm32f1x.cpu configure -event examine-end
# DBGMCU_CR |= DBG_WWDG_STOP | DBG_IWDG_STOP |
#              DBG_STANDBY | DBG_STOP | DBG_SLEEP
mmw 0xE0042004 0x00000307 0

Debug: 109 13 command.c:146 script_debug(): command - stm32f1x.cpu configure -event trace-config
# Set TRACE_IOEN; TRACE_MODE is set to async; when using sync
# change this value accordingly to configure trace pins
# assignment
mmw 0xE0042004 0x00000020 0

Info : 110 13 server.c:312 add_service(): Listening on port 6666 for tcl connections
Info : 111 13 server.c:312 add_service(): Listening on port 4444 for telnet connections
Debug: 112 13 command.c:146 script_debug(): command - init
Debug: 114 13 command.c:146 script_debug(): command - target init
Debug: 116 13 command.c:146 script_debug(): command - target names
Debug: 117 13 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-flash-erase-start
Debug: 118 13 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-flash-erase-start reset init
Debug: 119 13 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-flash-write-end
Debug: 120 14 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-flash-write-end reset halt
Debug: 121 14 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-attach
Debug: 122 14 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-attach halt 1000
Debug: 123 14 target.c:1639 handle_target_init_command(): Initializing targets...
Debug: 124 14 semihosting_common.c:99 semihosting_common_init():
Debug: 125 2492 cmsis_dap_usb_bulk.c:157 cmsis_dap_usb_open(): found product string of 0x0002:0xda42 'SushiBits One with CMSIS-DAP'
Debug: 126 2492 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0002:0xda42
Debug: 127 2492 cmsis_dap_usb_bulk.c:237 cmsis_dap_usb_open(): skipping interface 0, has only 1 endpoints
Debug: 128 2492 cmsis_dap_usb_bulk.c:285 cmsis_dap_usb_open(): skipping interface 1, class 10 subclass 0 protocol 0
Debug: 129 2492 cmsis_dap_usb_bulk.c:224 cmsis_dap_usb_open(): found interface 2 string 'SushiBits One Embedded CMSIS-DAP'
Debug: 130 2492 cmsis_dap_usb_bulk.c:244 cmsis_dap_usb_open(): skipping interface 2, endpoint[0] is not bulk out
Debug: 131 2658 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a40:0x0101
Debug: 132 2660 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0002:0x2812
Debug: 133 2660 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x03eb:0x2104
Debug: 134 2660 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x046d:0xc52b
Debug: 135 2661 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x03f0:0x052a
Debug: 136 2662 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x04d8:0x9012
Debug: 137 2662 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1366:0x0101
Debug: 138 2836 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0002:0xf003
Debug: 139 3007 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0451:0x8140
Debug: 140 3186 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1050:0x0407
Debug: 141 3366 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x2109:0x2812
Debug: 142 3547 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x2109:0x2812
Debug: 143 3547 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x046d:0x085c
Debug: 144 3719 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0451:0x8142
Debug: 145 3720 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a86:0x752d
Debug: 146 3886 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a40:0x0101
Info : 147 3896 cmsis_dap.c:788 cmsis_dap_get_caps_info(): CMSIS-DAP: SWD  Supported
Info : 148 3896 cmsis_dap.c:790 cmsis_dap_get_caps_info(): CMSIS-DAP: JTAG Supported
Info : 149 3898 cmsis_dap.c:768 cmsis_dap_get_version_info(): CMSIS-DAP: FW Version = 1.0
Info : 150 3902 cmsis_dap.c:921 cmsis_dap_init(): CMSIS-DAP: Interface Initialised (JTAG)
Debug: 151 3903 cmsis_dap.c:953 cmsis_dap_init(): CMSIS-DAP: Packet Size = 64
Debug: 152 3905 cmsis_dap.c:966 cmsis_dap_init(): CMSIS-DAP: Packet Count = 8
Debug: 153 3905 cmsis_dap.c:969 cmsis_dap_init(): Allocating FIFO for 3 pending packets
Info : 154 3907 cmsis_dap.c:809 cmsis_dap_get_status(): SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 1 nRESET = 1
Info : 155 3915 cmsis_dap.c:1023 cmsis_dap_init(): CMSIS-DAP: Interface ready
Debug: 156 3915 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 157 3915 core.c:1789 adapter_khz_to_speed(): have interface set up
Debug: 158 3917 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 159 3917 core.c:1789 adapter_khz_to_speed(): have interface set up
Info : 160 3917 core.c:1565 adapter_init(): clock speed 1000 kHz
Debug: 161 3917 openocd.c:143 handle_init_command(): Debug Adapter init complete
Debug: 162 3917 command.c:146 script_debug(): command - transport init
Debug: 163 3917 log.c:428 gdb_timeout_warning(): keep_alive() was not invoked in the 1000 ms timelimit (3917 ms). This may cause trouble with GDB connections.
Debug: 166 3917 transport.c:229 handle_transport_init(): handle_transport_init
Debug: 167 3919 core.c:830 jtag_add_reset(): SRST line released
Debug: 168 3919 core.c:855 jtag_add_reset(): TRST line released
Debug: 169 3919 core.c:327 jtag_call_event_callbacks(): jtag event: TAP reset
Debug: 170 4137 command.c:146 script_debug(): command - jtag arp_init
Debug: 171 4137 core.c:1578 jtag_init_inner(): Init JTAG chain
Debug: 172 4137 core.c:327 jtag_call_event_callbacks(): jtag event: TAP reset
Info : 173 4137 cmsis_dap.c:1076 cmsis_dap_execute_tlr_reset(): cmsis-dap JTAG TLR_RESET
Debug: 174 4171 core.c:1243 jtag_examine_chain(): DR scan interrogation for IDCODE/BYPASS
Debug: 175 4171 core.c:327 jtag_call_event_callbacks(): jtag event: TAP reset
Info : 176 4178 cmsis_dap.c:1076 cmsis_dap_execute_tlr_reset(): cmsis-dap JTAG TLR_RESET
Info : 177 4181 core.c:1142 jtag_examine_chain_display(): JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x3)
Info : 178 4181 core.c:1142 jtag_examine_chain_display(): JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020 (STMicroelectronics), part: 0x6410, ver: 0x1)
Debug: 179 4181 core.c:1374 jtag_validate_ircapture(): IR capture validation scan
Debug: 180 4184 core.c:1432 jtag_validate_ircapture(): stm32f1x.cpu: IR capture 0x01
Debug: 181 4184 core.c:1432 jtag_validate_ircapture(): stm32f1x.bs: IR capture 0x01
Debug: 182 4184 command.c:146 script_debug(): command - dap init
Debug: 184 4184 arm_dap.c:106 dap_init_all(): Initializing all DAPs ...
Debug: 185 4184 arm_adi_v5.c:653 dap_dp_init(): stm32f1x.dap
Debug: 186 4184 arm_adi_v5.c:685 dap_dp_init(): DAP: wait CDBGPWRUPACK
Debug: 187 4184 arm_adi_v5.h:507 dap_dp_poll_register(): DAP: poll 4, mask 0x20000000, value 0x20000000
Error: 188 4194 adi_v5_jtag.c:425 jtagdp_overrun_check(): Invalid ACK (4) in DAP response
Debug: 189 4196 command.c:629 run_command(): Command 'dap init' failed with error code -107
User : 190 4196 command.c:694 command_run_line():
Debug: 191 4196 command.c:629 run_command(): Command 'init' failed with error code -4
User : 192 4196 command.c:694 command_run_line():
Debug: 193 4197 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 05, 2021, 12:36:29 pm
This is STM32F103 over SWD:

Code: [Select]
$ openocd -d3 -f interface/cmsis-dap.cfg -c "transport select swd" -c "adapter speed 1000" -f target/stm32f1x.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
[url]http://openocd.org/doc/doxygen/bugs.html[/url]
User : 13 1 options.c:63 configuration_output_handler(): debug_level: 3
User : 14 1 options.c:63 configuration_output_handler():
Debug: 15 1 options.c:244 add_default_dirs(): bindir=/usr/local/Cellar/open-ocd/0.11.0/bin
Debug: 16 1 options.c:245 add_default_dirs(): pkgdatadir=/usr/local/Cellar/open-ocd/0.11.0/share/openocd
Debug: 17 1 options.c:246 add_default_dirs(): exepath=/usr/local/Cellar/open-ocd/0.11.0/bin
Debug: 18 1 options.c:247 add_default_dirs(): bin2data=../share/openocd
Debug: 19 1 configuration.c:42 add_script_search_dir(): adding /Users/user/Library/Preferences/org.openocd
Debug: 20 1 configuration.c:42 add_script_search_dir(): adding /Users/user/.config/openocd
Debug: 21 1 configuration.c:42 add_script_search_dir(): adding /Users/user/.openocd
Debug: 22 1 configuration.c:42 add_script_search_dir(): adding /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/site
Debug: 23 1 configuration.c:42 add_script_search_dir(): adding /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts
Debug: 24 1 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/interface/cmsis-dap.cfg
Debug: 25 1 command.c:146 script_debug(): command - adapter driver cmsis-dap
Debug: 27 1 command.c:146 script_debug(): command - transport select swd
User : 28 1 options.c:63 configuration_output_handler(): swdUser : 29 1 options.c:63 configuration_output_handler():
Debug: 30 1 command.c:146 script_debug(): command - adapter speed 1000
Debug: 32 1 core.c:1822 jtag_config_khz(): handle jtag khz
Debug: 33 1 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 34 1 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
User : 35 1 options.c:63 configuration_output_handler(): adapter speed: 1000 kHz
User : 36 1 options.c:63 configuration_output_handler():
Debug: 37 1 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/target/stm32f1x.cfg
Debug: 38 1 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/target/swj-dp.tcl
Debug: 39 1 command.c:146 script_debug(): command - transport select
Debug: 40 1 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/mem_helper.tcl
Debug: 41 1 command.c:146 script_debug(): command - add_usage_text mrw address
Debug: 43 1 command.c:1115 help_add_command(): added 'mrw' help text
Debug: 44 1 command.c:146 script_debug(): command - add_help_text mrw Returns value of word in memory.
Debug: 46 1 command.c:1128 help_add_command(): added 'mrw' help text
Debug: 47 1 command.c:146 script_debug(): command - add_usage_text mrh address
Debug: 49 1 command.c:1115 help_add_command(): added 'mrh' help text
Debug: 50 1 command.c:146 script_debug(): command - add_help_text mrh Returns value of halfword in memory.
Debug: 52 1 command.c:1128 help_add_command(): added 'mrh' help text
Debug: 53 1 command.c:146 script_debug(): command - add_usage_text mrb address
Debug: 55 1 command.c:1115 help_add_command(): added 'mrb' help text
Debug: 56 1 command.c:146 script_debug(): command - add_help_text mrb Returns value of byte in memory.
Debug: 58 1 command.c:1128 help_add_command(): added 'mrb' help text
Debug: 59 1 command.c:146 script_debug(): command - add_usage_text mmw address setbits clearbits
Debug: 61 1 command.c:1115 help_add_command(): added 'mmw' help text
Debug: 62 1 command.c:146 script_debug(): command - add_help_text mmw Modify word in memory. new_val = (old_val & ~clearbits) | setbits;
Debug: 64 1 command.c:1128 help_add_command(): added 'mmw' help text
Debug: 65 2 command.c:146 script_debug(): command - transport select
Debug: 66 2 command.c:146 script_debug(): command - transport select
Debug: 67 2 command.c:146 script_debug(): command - transport select
Debug: 68 2 command.c:146 script_debug(): command - swd newdap stm32f1x cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x1ba01477
Debug: 69 2 tcl.c:572 jim_newtap_cmd(): Creating New Tap, Chip: stm32f1x, Tap: cpu, Dotted: stm32f1x.cpu, 8 params
Debug: 70 2 core.c:1488 jtag_tap_init(): Created Tap: stm32f1x.cpu @ abs position 0, irlen 0, capture: 0x0 mask: 0x0
Debug: 71 2 command.c:146 script_debug(): command - dap create stm32f1x.dap -chain-position stm32f1x.cpu
Debug: 72 2 command.c:146 script_debug(): command - transport select
Debug: 73 2 command.c:146 script_debug(): command - target create stm32f1x.cpu cortex_m -endian little -dap stm32f1x.dap
Debug: 74 2 command.c:376 register_command(): command 'rtt' is already registered in '<global>' context
Debug: 75 2 command.c:146 script_debug(): command - stm32f1x.cpu configure -work-area-phys 0x20000000 -work-area-size 0x1000 -work-area-backup 0
Debug: 76 2 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 77 2 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 78 2 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 79 2 command.c:146 script_debug(): command - flash bank stm32f1x.flash stm32f1x 0x08000000 0 0 0 stm32f1x.cpu
Debug: 81 2 tcl.c:1319 handle_flash_bank_command(): 'stm32f1x' driver usage field missing
Debug: 82 2 command.c:146 script_debug(): command - adapter speed 1000
Debug: 84 2 core.c:1822 jtag_config_khz(): handle jtag khz
Debug: 85 2 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 86 2 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 87 2 command.c:146 script_debug(): command - adapter srst delay 100
Debug: 89 2 command.c:146 script_debug(): command - transport select
Debug: 90 2 command.c:146 script_debug(): command - reset_config srst_nogate
Debug: 92 2 command.c:146 script_debug(): command - transport select
Debug: 93 2 command.c:146 script_debug(): command - cortex_m reset_config sysresetreq
Debug: 95 2 command.c:146 script_debug(): command - stm32f1x.cpu configure -event examine-end
# DBGMCU_CR |= DBG_WWDG_STOP | DBG_IWDG_STOP |
#              DBG_STANDBY | DBG_STOP | DBG_SLEEP
mmw 0xE0042004 0x00000307 0

Debug: 96 2 command.c:146 script_debug(): command - stm32f1x.cpu configure -event trace-config
# Set TRACE_IOEN; TRACE_MODE is set to async; when using sync
# change this value accordingly to configure trace pins
# assignment
mmw 0xE0042004 0x00000020 0

Info : 97 2 server.c:312 add_service(): Listening on port 6666 for tcl connections
Info : 98 2 server.c:312 add_service(): Listening on port 4444 for telnet connections
Debug: 99 2 command.c:146 script_debug(): command - init
Debug: 101 2 command.c:146 script_debug(): command - target init
Debug: 103 2 command.c:146 script_debug(): command - target names
Debug: 104 2 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-flash-erase-start
Debug: 105 2 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-flash-erase-start reset init
Debug: 106 2 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-flash-write-end
Debug: 107 2 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-flash-write-end reset halt
Debug: 108 2 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-attach
Debug: 109 2 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-attach halt 1000
Debug: 110 2 target.c:1639 handle_target_init_command(): Initializing targets...
Debug: 111 2 semihosting_common.c:99 semihosting_common_init():
Debug: 112 2478 cmsis_dap_usb_bulk.c:157 cmsis_dap_usb_open(): found product string of 0x0002:0xda42 'SushiBits One with CMSIS-DAP'
Debug: 113 2478 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0002:0xda42
Debug: 114 2478 cmsis_dap_usb_bulk.c:237 cmsis_dap_usb_open(): skipping interface 0, has only 1 endpoints
Debug: 115 2478 cmsis_dap_usb_bulk.c:285 cmsis_dap_usb_open(): skipping interface 1, class 10 subclass 0 protocol 0
Debug: 116 2479 cmsis_dap_usb_bulk.c:224 cmsis_dap_usb_open(): found interface 2 string 'SushiBits One Embedded CMSIS-DAP'
Debug: 117 2479 cmsis_dap_usb_bulk.c:244 cmsis_dap_usb_open(): skipping interface 2, endpoint[0] is not bulk out
Debug: 118 2644 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a40:0x0101
Debug: 119 2646 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0002:0x2812
Debug: 120 2647 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x03eb:0x2104
Debug: 121 2647 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x046d:0xc52b
Debug: 122 2647 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x03f0:0x052a
Debug: 123 2648 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x04d8:0x9012
Debug: 124 2649 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1366:0x0101
Debug: 125 2822 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0002:0xf003
Debug: 126 2993 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0451:0x8140
Debug: 127 3172 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1050:0x0407
Debug: 128 3352 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x2109:0x2812
Debug: 129 3533 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x2109:0x2812
Debug: 130 3534 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x046d:0x085c
Debug: 131 3706 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0451:0x8142
Debug: 132 3706 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a86:0x752d
Debug: 133 3872 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a40:0x0101
Info : 134 3881 cmsis_dap.c:788 cmsis_dap_get_caps_info(): CMSIS-DAP: SWD  Supported
Info : 135 3881 cmsis_dap.c:790 cmsis_dap_get_caps_info(): CMSIS-DAP: JTAG Supported
Info : 136 3882 cmsis_dap.c:768 cmsis_dap_get_version_info(): CMSIS-DAP: FW Version = 1.0
Info : 137 3886 cmsis_dap.c:881 cmsis_dap_swd_open(): CMSIS-DAP: Interface Initialised (SWD)
Debug: 138 3888 cmsis_dap.c:953 cmsis_dap_init(): CMSIS-DAP: Packet Size = 64
Debug: 139 3890 cmsis_dap.c:966 cmsis_dap_init(): CMSIS-DAP: Packet Count = 8
Debug: 140 3890 cmsis_dap.c:969 cmsis_dap_init(): Allocating FIFO for 3 pending packets
Info : 141 3892 cmsis_dap.c:809 cmsis_dap_get_status(): SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 1 nRESET = 1
Info : 142 3902 cmsis_dap.c:1023 cmsis_dap_init(): CMSIS-DAP: Interface ready
Debug: 143 3902 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 144 3902 core.c:1789 adapter_khz_to_speed(): have interface set up
Debug: 145 3904 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 146 3904 core.c:1789 adapter_khz_to_speed(): have interface set up
Info : 147 3904 core.c:1565 adapter_init(): clock speed 1000 kHz
Debug: 148 3904 openocd.c:143 handle_init_command(): Debug Adapter init complete
Debug: 149 3904 command.c:146 script_debug(): command - transport init
Debug: 150 3904 log.c:428 gdb_timeout_warning(): keep_alive() was not invoked in the 1000 ms timelimit (3904 ms). This may cause trouble with GDB connections.
Debug: 153 3904 transport.c:229 handle_transport_init(): handle_transport_init
Debug: 154 3904 command.c:146 script_debug(): command - dap init
Debug: 156 3904 arm_dap.c:106 dap_init_all(): Initializing all DAPs ...
Debug: 157 3908 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 158 3916 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 159 3922 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 160 3931 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 161 3937 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 162 3944 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 163 3950 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 164 3958 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 165 3963 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 166 3971 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 167 3976 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 168 3985 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 169 3991 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 170 3999 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 171 4004 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 172 4012 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 173 4019 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 174 4027 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 175 4034 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 176 4045 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 177 4052 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 178 4063 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 179 4069 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 180 4079 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 181 4084 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 182 4095 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 183 4103 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 184 4113 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 185 4120 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 186 4131 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 187 4138 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 188 4149 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 189 4155 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 190 4165 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 191 4171 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 192 4182 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 193 4188 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 194 4199 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 195 4205 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 196 4216 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 197 4223 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 198 4233 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 199 4239 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 200 4249 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 201 4255 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 202 4265 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 203 4272 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 204 4283 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 205 4290 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 206 4301 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 207 4307 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 208 4318 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 209 4325 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 210 4335 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 211 4342 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 212 4353 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 213 4360 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 214 4372 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 215 4378 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 216 4389 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 217 4395 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 218 4405 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Error: 220 4407 adi_v5_swd.c:144 swd_connect(): Error connecting DP: cannot read IDR
Debug: 221 4407 command.c:629 run_command(): Command 'dap init' failed with error code -4
User : 222 4407 command.c:694 command_run_line():
Debug: 223 4407 command.c:629 run_command(): Command 'init' failed with error code -4
User : 224 4407 command.c:694 command_run_line():
Debug: 225 4407 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 226 4412 cmsis_dap.c:848 cmsis_dap_swd_switch_seq(): SWD-to-JTAG

This dumped from macOS Big Sur amd64 running the version of OpenOCD that comes from Homebrew.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: SiliconWizard on May 05, 2021, 04:03:27 pm
Sorry for chiming in with a related question... but does anybody know of any off-the-shelf probe implementing CMSIS-DAP v2 (USB HS)? The DAP v1 probes are everywhere, but I can't seem to find any decent v2 one. (I have just found ONE on Aliexpress but with questionable quality IMO and a USB male connector, I literally HATE that.)

Or, any off-the-shelf board that can be successfully programmed with a working DAP v2 firmware would also do.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 05, 2021, 04:09:43 pm
V1 can work over USB HS too.
V2 adds ability to use bulk endpoints, therefore increasing throughput on USB FS considerably. It will not be any better than V1 on USB HS. At that point you start to be limited by the SWD interface mostly.

It is easy to adapt existing firmware to V2. The reason for slow adoption is that V2 starts to need drivers on Windows, which sucks.

And, no I'm not aware of any off the shelf hardware that supports V2. Again, for me the speed issue is mostly solved by using V1 with USB HS hardware.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 05, 2021, 04:21:04 pm
V1 can work over USB HS too.
V2 adds ability to use bulk endpoints, therefore increasing throughput on USB FS considerably. It will not be any better than V1 on USB HS. At that point you start to be limited by the SWD interface mostly.

It is easy to adapt existing firmware to V2. The reason for slow adoption is that V2 starts to need drivers on Windows, which sucks.

And, no I'm not aware of any off the shelf hardware that supports V2. Again, for me the speed issue is mostly solved by using V1 with USB HS hardware.
I happen to also have a board with STM32F446 and a USB HS ULPI PHY...
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 05, 2021, 04:29:15 pm
For a "real" debugger, you definitely want to use USB HS. USB FS + HIDs limits you to 64 KBytes/second. This is ok for basic stuff, but if you really want to get the fast debugging, you need to run it over USB HS.

There are also a lot of optimizations in the protocol that are rarely taken advantage of by generic tools supporting multiple debugger types. They usually abstract things into simple commands, which are executed one by one. But there is not much you can do about that.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: thinkfat on May 05, 2021, 06:04:16 pm
This is STM32F103 over SWD:

Code: [Select]
$ openocd -d3 -f interface/cmsis-dap.cfg -c "transport select swd" -c "adapter speed 1000" -f target/stm32f1x.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
[url]http://openocd.org/doc/doxygen/bugs.html[/url]
User : 13 1 options.c:63 configuration_output_handler(): debug_level: 3
User : 14 1 options.c:63 configuration_output_handler():
Debug: 15 1 options.c:244 add_default_dirs(): bindir=/usr/local/Cellar/open-ocd/0.11.0/bin
Debug: 16 1 options.c:245 add_default_dirs(): pkgdatadir=/usr/local/Cellar/open-ocd/0.11.0/share/openocd
Debug: 17 1 options.c:246 add_default_dirs(): exepath=/usr/local/Cellar/open-ocd/0.11.0/bin
Debug: 18 1 options.c:247 add_default_dirs(): bin2data=../share/openocd
Debug: 19 1 configuration.c:42 add_script_search_dir(): adding /Users/user/Library/Preferences/org.openocd
Debug: 20 1 configuration.c:42 add_script_search_dir(): adding /Users/user/.config/openocd
Debug: 21 1 configuration.c:42 add_script_search_dir(): adding /Users/user/.openocd
Debug: 22 1 configuration.c:42 add_script_search_dir(): adding /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/site
Debug: 23 1 configuration.c:42 add_script_search_dir(): adding /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts
Debug: 24 1 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/interface/cmsis-dap.cfg
Debug: 25 1 command.c:146 script_debug(): command - adapter driver cmsis-dap
Debug: 27 1 command.c:146 script_debug(): command - transport select swd
User : 28 1 options.c:63 configuration_output_handler(): swdUser : 29 1 options.c:63 configuration_output_handler():
Debug: 30 1 command.c:146 script_debug(): command - adapter speed 1000
Debug: 32 1 core.c:1822 jtag_config_khz(): handle jtag khz
Debug: 33 1 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 34 1 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
User : 35 1 options.c:63 configuration_output_handler(): adapter speed: 1000 kHz
User : 36 1 options.c:63 configuration_output_handler():
Debug: 37 1 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/target/stm32f1x.cfg
Debug: 38 1 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/target/swj-dp.tcl
Debug: 39 1 command.c:146 script_debug(): command - transport select
Debug: 40 1 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/mem_helper.tcl
Debug: 41 1 command.c:146 script_debug(): command - add_usage_text mrw address
Debug: 43 1 command.c:1115 help_add_command(): added 'mrw' help text
Debug: 44 1 command.c:146 script_debug(): command - add_help_text mrw Returns value of word in memory.
Debug: 46 1 command.c:1128 help_add_command(): added 'mrw' help text
Debug: 47 1 command.c:146 script_debug(): command - add_usage_text mrh address
Debug: 49 1 command.c:1115 help_add_command(): added 'mrh' help text
Debug: 50 1 command.c:146 script_debug(): command - add_help_text mrh Returns value of halfword in memory.
Debug: 52 1 command.c:1128 help_add_command(): added 'mrh' help text
Debug: 53 1 command.c:146 script_debug(): command - add_usage_text mrb address
Debug: 55 1 command.c:1115 help_add_command(): added 'mrb' help text
Debug: 56 1 command.c:146 script_debug(): command - add_help_text mrb Returns value of byte in memory.
Debug: 58 1 command.c:1128 help_add_command(): added 'mrb' help text
Debug: 59 1 command.c:146 script_debug(): command - add_usage_text mmw address setbits clearbits
Debug: 61 1 command.c:1115 help_add_command(): added 'mmw' help text
Debug: 62 1 command.c:146 script_debug(): command - add_help_text mmw Modify word in memory. new_val = (old_val & ~clearbits) | setbits;
Debug: 64 1 command.c:1128 help_add_command(): added 'mmw' help text
Debug: 65 2 command.c:146 script_debug(): command - transport select
Debug: 66 2 command.c:146 script_debug(): command - transport select
Debug: 67 2 command.c:146 script_debug(): command - transport select
Debug: 68 2 command.c:146 script_debug(): command - swd newdap stm32f1x cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x1ba01477
Debug: 69 2 tcl.c:572 jim_newtap_cmd(): Creating New Tap, Chip: stm32f1x, Tap: cpu, Dotted: stm32f1x.cpu, 8 params
Debug: 70 2 core.c:1488 jtag_tap_init(): Created Tap: stm32f1x.cpu @ abs position 0, irlen 0, capture: 0x0 mask: 0x0
Debug: 71 2 command.c:146 script_debug(): command - dap create stm32f1x.dap -chain-position stm32f1x.cpu
Debug: 72 2 command.c:146 script_debug(): command - transport select
Debug: 73 2 command.c:146 script_debug(): command - target create stm32f1x.cpu cortex_m -endian little -dap stm32f1x.dap
Debug: 74 2 command.c:376 register_command(): command 'rtt' is already registered in '<global>' context
Debug: 75 2 command.c:146 script_debug(): command - stm32f1x.cpu configure -work-area-phys 0x20000000 -work-area-size 0x1000 -work-area-backup 0
Debug: 76 2 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 77 2 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 78 2 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 79 2 command.c:146 script_debug(): command - flash bank stm32f1x.flash stm32f1x 0x08000000 0 0 0 stm32f1x.cpu
Debug: 81 2 tcl.c:1319 handle_flash_bank_command(): 'stm32f1x' driver usage field missing
Debug: 82 2 command.c:146 script_debug(): command - adapter speed 1000
Debug: 84 2 core.c:1822 jtag_config_khz(): handle jtag khz
Debug: 85 2 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 86 2 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 87 2 command.c:146 script_debug(): command - adapter srst delay 100
Debug: 89 2 command.c:146 script_debug(): command - transport select
Debug: 90 2 command.c:146 script_debug(): command - reset_config srst_nogate
Debug: 92 2 command.c:146 script_debug(): command - transport select
Debug: 93 2 command.c:146 script_debug(): command - cortex_m reset_config sysresetreq
Debug: 95 2 command.c:146 script_debug(): command - stm32f1x.cpu configure -event examine-end
# DBGMCU_CR |= DBG_WWDG_STOP | DBG_IWDG_STOP |
#              DBG_STANDBY | DBG_STOP | DBG_SLEEP
mmw 0xE0042004 0x00000307 0

Debug: 96 2 command.c:146 script_debug(): command - stm32f1x.cpu configure -event trace-config
# Set TRACE_IOEN; TRACE_MODE is set to async; when using sync
# change this value accordingly to configure trace pins
# assignment
mmw 0xE0042004 0x00000020 0

Info : 97 2 server.c:312 add_service(): Listening on port 6666 for tcl connections
Info : 98 2 server.c:312 add_service(): Listening on port 4444 for telnet connections
Debug: 99 2 command.c:146 script_debug(): command - init
Debug: 101 2 command.c:146 script_debug(): command - target init
Debug: 103 2 command.c:146 script_debug(): command - target names
Debug: 104 2 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-flash-erase-start
Debug: 105 2 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-flash-erase-start reset init
Debug: 106 2 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-flash-write-end
Debug: 107 2 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-flash-write-end reset halt
Debug: 108 2 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-attach
Debug: 109 2 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-attach halt 1000
Debug: 110 2 target.c:1639 handle_target_init_command(): Initializing targets...
Debug: 111 2 semihosting_common.c:99 semihosting_common_init():
Debug: 112 2478 cmsis_dap_usb_bulk.c:157 cmsis_dap_usb_open(): found product string of 0x0002:0xda42 'SushiBits One with CMSIS-DAP'
Debug: 113 2478 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0002:0xda42
Debug: 114 2478 cmsis_dap_usb_bulk.c:237 cmsis_dap_usb_open(): skipping interface 0, has only 1 endpoints
Debug: 115 2478 cmsis_dap_usb_bulk.c:285 cmsis_dap_usb_open(): skipping interface 1, class 10 subclass 0 protocol 0
Debug: 116 2479 cmsis_dap_usb_bulk.c:224 cmsis_dap_usb_open(): found interface 2 string 'SushiBits One Embedded CMSIS-DAP'
Debug: 117 2479 cmsis_dap_usb_bulk.c:244 cmsis_dap_usb_open(): skipping interface 2, endpoint[0] is not bulk out
Debug: 118 2644 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a40:0x0101
Debug: 119 2646 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0002:0x2812
Debug: 120 2647 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x03eb:0x2104
Debug: 121 2647 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x046d:0xc52b
Debug: 122 2647 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x03f0:0x052a
Debug: 123 2648 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x04d8:0x9012
Debug: 124 2649 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1366:0x0101
Debug: 125 2822 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0002:0xf003
Debug: 126 2993 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0451:0x8140
Debug: 127 3172 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1050:0x0407
Debug: 128 3352 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x2109:0x2812
Debug: 129 3533 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x2109:0x2812
Debug: 130 3534 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x046d:0x085c
Debug: 131 3706 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0451:0x8142
Debug: 132 3706 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a86:0x752d
Debug: 133 3872 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a40:0x0101
Info : 134 3881 cmsis_dap.c:788 cmsis_dap_get_caps_info(): CMSIS-DAP: SWD  Supported
Info : 135 3881 cmsis_dap.c:790 cmsis_dap_get_caps_info(): CMSIS-DAP: JTAG Supported
Info : 136 3882 cmsis_dap.c:768 cmsis_dap_get_version_info(): CMSIS-DAP: FW Version = 1.0
Info : 137 3886 cmsis_dap.c:881 cmsis_dap_swd_open(): CMSIS-DAP: Interface Initialised (SWD)
Debug: 138 3888 cmsis_dap.c:953 cmsis_dap_init(): CMSIS-DAP: Packet Size = 64
Debug: 139 3890 cmsis_dap.c:966 cmsis_dap_init(): CMSIS-DAP: Packet Count = 8
Debug: 140 3890 cmsis_dap.c:969 cmsis_dap_init(): Allocating FIFO for 3 pending packets
Info : 141 3892 cmsis_dap.c:809 cmsis_dap_get_status(): SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 1 nRESET = 1
Info : 142 3902 cmsis_dap.c:1023 cmsis_dap_init(): CMSIS-DAP: Interface ready
Debug: 143 3902 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 144 3902 core.c:1789 adapter_khz_to_speed(): have interface set up
Debug: 145 3904 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 146 3904 core.c:1789 adapter_khz_to_speed(): have interface set up
Info : 147 3904 core.c:1565 adapter_init(): clock speed 1000 kHz
Debug: 148 3904 openocd.c:143 handle_init_command(): Debug Adapter init complete
Debug: 149 3904 command.c:146 script_debug(): command - transport init
Debug: 150 3904 log.c:428 gdb_timeout_warning(): keep_alive() was not invoked in the 1000 ms timelimit (3904 ms). This may cause trouble with GDB connections.
Debug: 153 3904 transport.c:229 handle_transport_init(): handle_transport_init
Debug: 154 3904 command.c:146 script_debug(): command - dap init
Debug: 156 3904 arm_dap.c:106 dap_init_all(): Initializing all DAPs ...
Debug: 157 3908 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 158 3916 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 159 3922 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 160 3931 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 161 3937 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 162 3944 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 163 3950 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 164 3958 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 165 3963 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 166 3971 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 167 3976 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 168 3985 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 169 3991 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 170 3999 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 171 4004 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 172 4012 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 173 4019 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 174 4027 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 175 4034 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 176 4045 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 177 4052 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 178 4063 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 179 4069 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 180 4079 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 181 4084 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 182 4095 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 183 4103 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 184 4113 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 185 4120 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 186 4131 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 187 4138 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 188 4149 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 189 4155 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 190 4165 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 191 4171 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 192 4182 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 193 4188 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 194 4199 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 195 4205 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 196 4216 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 197 4223 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 198 4233 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 199 4239 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 200 4249 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 201 4255 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 202 4265 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 203 4272 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 204 4283 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 205 4290 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 206 4301 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 207 4307 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 208 4318 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 209 4325 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 210 4335 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 211 4342 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 212 4353 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 213 4360 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 214 4372 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 215 4378 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 216 4389 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 217 4395 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Debug: 218 4405 cmsis_dap.c:647 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Error: 220 4407 adi_v5_swd.c:144 swd_connect(): Error connecting DP: cannot read IDR
Debug: 221 4407 command.c:629 run_command(): Command 'dap init' failed with error code -4
User : 222 4407 command.c:694 command_run_line():
Debug: 223 4407 command.c:629 run_command(): Command 'init' failed with error code -4
User : 224 4407 command.c:694 command_run_line():
Debug: 225 4407 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 226 4412 cmsis_dap.c:848 cmsis_dap_swd_switch_seq(): SWD-to-JTAG

This dumped from macOS Big Sur amd64 running the version of OpenOCD that comes from Homebrew.

I guess your best option is to show up on #openocd on irc.freenode.net, or write an email to openocd-devel@lists.sourceforge.net.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 05, 2021, 11:03:29 pm
I had a look at how JTAG is implemented in the CMSIS-DAP. I doubt how useful it would be outside of ARM stuff. It uses ARM specific registers for transfers, which obviously would not be present on other targets.

There are commands to just bit bang JTAG pins, but I'm not sure how well (if at all) software supports that in practice.

So far, I would assume that CMSIS-DAP is practically useful only for ARM targets.

I'll still look though it to see if it makes sense for me to even support it. I feel like it would be just poorly tested dead code.

I also rigged up a quick test, and I can access JTAG on the STM32 I have. Now it is a matter of implementing the actual commands in the debugger.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: SiliconWizard on May 05, 2021, 11:11:07 pm
So far, I would assume that CMSIS-DAP is practically useful only for ARM targets.

Well, as far as I know, openocd supports CMSIS-DAP as a JTAG interface and this can be used with any target that is supportd by OpenOCD. I don't know how efficient it is for targets other than ARM, but it seems much faster than if it were just bit-banged.

Similarly, I'm actually using a CMSIS-DAP adapter on some Lattice ECP5 dev board, and someone wrote an pretty handy utility for using CMSIS-DAP probes with ECP5 FPGAs: https://github.com/adamgreig/ecpdap
It works quite well. The tool is written in Rust, and I haven't taken a deep look at it, so not sure hjow they use the DAP protocol here exactly.


Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 05, 2021, 11:24:58 pm
The project you linked does use JTAG Sequence command. I assume OpenOCD does the same. This is bit banging. It is not inefficient, as CMSIS-DAP is a generally well designed protocol. This still sends the raw bits.

JTAG Transfer requests are way more efficient, but only work for ARM-based APs.

It is good that there is support from tools for that though.

Also, Rust is unreadable garbage. I don't understand why people find it so attractive.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: SiliconWizard on May 05, 2021, 11:33:16 pm
The project you linked does use JTAG Sequence command. I assume OpenOCD does the same. This is bit banging. It is not inefficient, as CMSIS-DAP is a generally well designed protocol. This still sends the raw bits.

JTAG Transfer requests are way more efficient, but only work for ARM-based APs.

It is good that there is support from tools for that though.

Also, Rust is unreadable garbage. I don't understand why people find it so attractive.

Well, that's another topic. ;D
But it's actually kind of annoying here. I'd like to port his project for using FTDI-based probes, but I don't get Rust (or really want to use it) enough to do that...
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 06, 2021, 01:51:52 am
Oh, wow, this is stupid. So there are two devices on the same JTAG port. One is ARM-compatible with IR length of 4. This is the one that has ARM-specific access registers, but has no standard test registers. And then there is another one that is the actual device with IR length of 5.

By default the 5 one is selected and total IR length is 5 bits. And when you bypass that one, the 4 bit one is activated and total IR length becomes 9.

This is the stupidest hack I've seen in quite some time. ARM really screwed up JTAG.

So if you want to do boundary scan, then device behaves as you would expect, and as described by the BSDL file. But if you want to debug or even just program, it all becomes custom real fast.

Correction: IR length is actually always 9. And the 4-bit TAP is just bypassed by default, so it causes one bit delay. This also means that BSDL file for this device is a complete nonsense, since it lists it as one device with IR length = 5. But if you try to access it like one device, everything would be shifted by one bit (which is exactly what I get when reading ID code). You can't simply ignore that second device in the chain.

On a positive note, this will let me test multiple chained devices.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 06, 2021, 03:17:25 am
Oh, wow, this is stupid. So there are two devices on the same JTAG port. One is ARM-compatible with IR length of 4. This is the one that has ARM-specific access registers, but has no standard test registers. And then there is another one that is the actual device with IR length of 5.
The IR length 4 one is the actual ARM core, and the IR length 5 one is the boundary scan of the chip itself implemented in the GPIO controllers.

On a positive note, this will let me test multiple chained devices.
I have a project board with two physical chips chained and 3 JTAG TAPs due to physical limits.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 06, 2021, 03:29:50 am
The IR length 4 one is the actual ARM core, and the IR length 5 one is the boundary scan of the chip itself implemented in the GPIO controllers.
I understand that. It just makes no sense to me. And having that 9 bit IR will further slow down everything. JTAG loses on speed here big time.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 06, 2021, 04:00:12 am
The IR length 4 one is the actual ARM core, and the IR length 5 one is the boundary scan of the chip itself implemented in the GPIO controllers.
I understand that. It just makes no sense to me. And having that 9 bit IR will further slow down everything. JTAG loses on speed here big time.
Try something with IR of 17 bits long then. That is the STM32F1 (4-bit ARM + 5-bit STM32 boundary scan) + XC2C32A (8-bit) chain.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: thinkfat on May 06, 2021, 07:07:56 am
It's not unusual to have more than one tap on the same JTAG port. I'd even say it's the norm once you're looking into complex SoCs. If I remember it right, the i.MX6 has three JTAG taps, and most TI SoCs feature a JTAG router that can modify the chain, taking taps completely out of the chain, and it's runtime configurable.

For example, the AM335x or AM5xxx SoCs have a tap for each of the internal processors, but only the tap for the main application core is in the chain by default, so you need to first talk to the JTAG router (which has it's own, always visible IR) to insert the others into the chain, then reconfigure the chain at runtime so that you can actually start debugging.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 06, 2021, 07:15:21 am
This dynamic reconfiguration would make a lot of sense to me. There is almost no scenario when I want to access boundary scan. Yet I want to debug and program the device a lot.

I was just looking in details at how JTAG AP/DP are implemented in the ARM part. And it also sucks. I'm not entirely sure why they did it that way, but a lot of debug accesses would require IR modification. For some reason they kept DAP register address and read/write bit as part of the DR access. But AP/DP bit is implemented as separate IR instructions.

I'm also not clear why they needed 5 bit IR for 4 instructions. And why ARM needed 4 bit IR for 4 registers.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 06, 2021, 07:44:17 am
This dynamic reconfiguration would make a lot of sense to me. There is almost no scenario when I want to access boundary scan. Yet I want to debug and program the device a lot.

I was just looking in details at how JTAG AP/DP are implemented in the ARM part. And it also sucks. I'm not entirely sure why they did it that way, but a lot of debug accesses would require IR modification. For some reason they kept DAP register address and read/write bit as part of the DR access. But AP/DP bit is implemented as separate IR instructions.

I'm also not clear why they needed 5 bit IR for 4 instructions. And why ARM needed 4 bit IR for 4 registers.
I think ARM JTAG interface on Cortex-M parts have historic and sibling baggages. It is inherited all the way from ARM7TDMI, and it have to support advanced parts all the way up to a Cortex-A73
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 06, 2021, 10:34:05 pm
I just setup OpenOCD for the first time to test the JTAG implementation. I'm now a bit better familiar with the output.

In your case the error is basically the first real communication over SWD that is failing. The reason for this may depend on the debugger firmware itself. It does not return correct status code for simplest pin toggles. Those failures you see is OpenOCD is trying to send JTAG to SWD switch sequence, followed by reading of the IDCODE register. All of those things fail. And there is no real reason for the first part to fail at all. You need to have a closer look at the implementation of the dap_swj_sequence (0x12) command.

I don't think it is OpenOCD issue. Something wrong with the debugger itself.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 07, 2021, 01:21:38 am
I just setup OpenOCD for the first time to test the JTAG implementation. I'm now a bit better familiar with the output.

In your case the error is basically the first real communication over SWD that is failing. The reason for this may depend on the debugger firmware itself. It does not return correct status code for simplest pin toggles. Those failures you see is OpenOCD is trying to send JTAG to SWD switch sequence, followed by reading of the IDCODE register. All of those things fail. And there is no real reason for the first part to fail at all. You need to have a closer look at the implementation of the dap_swj_sequence (0x12) command.

I don't think it is OpenOCD issue. Something wrong with the debugger itself.
I see… Weird though as my CMSIS-DAP protocol code is taken from IBDAP project, which itself is derived from official ARM code.

I’m going to give your protocol implementation a try, using my own cmsis-platform startup code, libusb_stm32 USB protocol, no RTOS and direct register access for other tasks.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 07, 2021, 05:40:23 am
I would try my tool with your hardware https://github.com/ataradov/edbg. It does not matter what MCU you actually select, even if your MCU is not supported, just select any MCU and see if the tool can read information about the debugger and do basic initialization.

I suspect you have some sort of integration issue. And from the OpenOCD logs, it does not even look like it reads any information about the debugger, it just jumps right into the business.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 07, 2021, 05:47:48 am
I would try my tool with your hardware https://github.com/ataradov/edbg. It does not matter what MCU you actually select, even if your MCU is not supported, just select any MCU and see if the tool can read information about the debugger and do basic initialization.

I suspect you have some sort of integration issue. And from the OpenOCD logs, it does not even look like it reads any information about the debugger, it just jumps right into the business.
Currently I have an 8-slot ring buffer for the incoming requests. The USB interrupt would cause the request be copied over into the ring buffer, then the main loop now release from WFI would go in and execute things, finally another USB interrupt cause the results to be picked up. Maybe I need to get rid of this ring buffer and just respond to things in the USB interrupt? Or at least not rely on the ring buffer and USB interrupt for outgoing data?
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 07, 2021, 05:59:37 am
For a "real" debugger, you definitely want to use USB HS. USB FS + HIDs limits you to 64 KBytes/second. This is ok for basic stuff, but if you really want to get the fast debugging, you need to run it over USB HS.
I wonder if using USB HS/SS + CMSIS-DAP v2 Bulk mode + FPGA with hard MCU cores + implement dap_swd_transfer and dap_jtag_transfer using HDL = some really REALLY fast JTAG and SWD action?
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 07, 2021, 07:14:02 am
Currently I have an 8-slot ring buffer for the incoming requests. The USB interrupt would cause the request be copied over into the ring buffer, then the main loop now release from WFI would go in and execute things, finally another USB interrupt cause the results to be picked up. Maybe I need to get rid of this ring buffer and just respond to things in the USB interrupt? Or at least not rely on the ring buffer and USB interrupt for outgoing data?
CMSIS-DAP is a request-response protocol. There will be nothing in the buffer after the first packet before you respond to it. CMSIS-DAP has capability to buffer multiple requests, but you need to advertise that capability explicitly through DAP_INFO_PACKET_COUNT response.

Most of the time tools just send one request and wait for the response, since this is the most compatible configuration.

It is hard to tell what may be wrong without debugging the code. Sometimes APIs require the input buffer to remove the first byte (command ID), sometimes they need to keep it. So this one thing to check.

Again, run my tool and see if it can at least identify your debugger and print information about it, since OpenOCD does not seem to do that.

I wonder if using USB HS/SS + CMSIS-DAP v2 Bulk mode + FPGA with hard MCU cores + implement dap_swd_transfer and dap_jtag_transfer using HDL = some really REALLY fast JTAG and SWD action?
Not really. In practice SWD ports on many parts are limited to some pretty low clock, like 16 MHz or so. And this you can pretty well bit-bang from a fast MCU without FPGA.

SS is definitely overkill. HS does improve things a lot, mostly due to ability to send 512 or 1024 byte packets.

Also, there are MCUs with hardware SWD/JTAG drivers, although they are not well documented. Nuvoton M480 series devices have USB HS and SWD peripheral. But nuvoton does not publish any documents about it. But I'm sure it is possible to figure it out with some effort. I never really cared to do that, since optimized bit-banging is plenty fast.

Significant optimization should come from the tools. CMSIS-DAP protocol lets you pack multiple transfers into the same packet. But tools rarely take advantage of this, since they all just use generic abstractions that do one packet per transfer.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 07, 2021, 08:12:09 am
CMSIS-DAP is a request-response protocol. There will be nothing in the buffer after the first packet before you respond to it. CMSIS-DAP has capability to buffer multiple requests, but you need to advertise that capability explicitly through DAP_INFO_PACKET_COUNT response.

Most of the time tools just send one request and wait for the response, since this is the most compatible configuration.

It is hard to tell what may be wrong without debugging the code. Sometimes APIs require the input buffer to remove the first byte (command ID), sometimes they need to keep it. So this one thing to check.
Got it.

Again, run my tool and see if it can at least identify your debugger and print information about it, since OpenOCD does not seem to do that.
I will do it after I went home.

Not really. In practice SWD ports on many parts are limited to some pretty low clock, like 16 MHz or so. And this you can pretty well bit-bang from a fast MCU without FPGA.
The built-in speed limit is a bummer... I wonder if an advanced MCU/MPU can allow fast SWD/JTAG at ~100MHz speed after the main core itself is clocked up.

SS is definitely overkill. HS does improve things a lot, mostly due to ability to send 512 or 1024 byte packets.
I'm gonna try this once I figure out how to do CMSIS-DAP on STM32F042. I have a STM32F446 + HS ULPI PHY board ready for this.

Also, there are MCUs with hardware SWD/JTAG drivers, although they are not well documented. Nuvoton M480 series devices have USB HS and SWD peripheral. But nuvoton does not publish any documents about it. But I'm sure it is possible to figure it out with some effort. I never really cared to do that, since optimized bit-banging is plenty fast.
I think Nuvoton used that chip in their Nu-Link debug pods. Thus IMO that hardware is pretty much internal use only and the only reason they kept it in the publicly available chips undocumented is just so they don't have to create new masks.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 07, 2021, 08:23:57 am
The built-in speed limit is a bummer... I wonder if an advanced MCU/MPU can allow fast SWD/JTAG at ~100MHz speed after the main core itself is clocked up.
I don't actually know if the limit is related to the core clock. I think DAP is pretty independent. On MCUs that limit is often defined by the pad bandwidth and signal integrity.

I just checked and SAM D21, for example, allows 50 MHz SWD clock in theory. This specification makes no sense, since pad bandwidth is around the same 16 MHz. You can push it a bit higher, but not to 50 MHz. So I guess specification is essentially "no upper limit". Strangely enough there is a 1 kHz lower limit. No idea where that comes from.

Faster MCUs/CPUs will probably have higher limit on the clock. At the same time, actual debug session does not consume a lot of bandwidth. As long as you are not dumping massive arrays of data, the debugging part is pretty efficient.

I think Nuvoton used that chip in their Nu-Link debug pods. Thus IMO that hardware is pretty much internal use only and the only reason they kept it in the publicly available chips undocumented is just so they don't have to create new masks.
Yes, that is the reason. I asked and they confirmed.

One thing that is irritating - why did they mention SWD host in the pin multiplexing table? But that's just a general documentation issue. Their documentation leaves a lot to be desired.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 07, 2021, 08:37:52 am
Faster MCUs/CPUs will probably have higher limit on the clock. At the same time, actual debug session does not consume a lot of bandwidth. As long as you are not dumping massive arrays of data, the debugging part is pretty efficient.
For a high speed AP SoC board that is freshly out off the oven and bootstrapping, one may want to initialize the DRAM and and then write a whole kernel and initramfs into that DRAM for first boot. This would mean dumping a few tens of MB of data into the chip over JTAG or SWD.

One thing that is irritating - why did they mention SWD host in the pin multiplexing table? But that's just a general documentation issue. Their documentation leaves a lot to be desired.
Nuvoton, either remove the mention, or just document that SWD host for people implementing CMSIS-DAP on that chip.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 07, 2021, 01:08:23 pm
So here is what I get:
Code: [Select]
$ ./edbg -lr
Attached debuggers:
  63C8AF92 - SushiBits Innovative SushiBits One with CMSIS-DAP
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 07, 2021, 04:25:09 pm
This part only identifies the debugger based on the USB descriptor strings. At this point there were no communication with the actual DAP payload.

Try "./edbg -b -t samd11 -r -f temp.bin". This would tell it to try to read your device as if it was SAM D11. This will fail, of course, but at least it will give it a chance to establish connection with the  DAP firmware. "-b" would make it print debugger information as read from the DAP implementation, not just USB strings.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 07, 2021, 04:30:12 pm
And if you want to further test the communication, modify target_select() in the target_atmel_cm7.c:
Code: [Select]
static void target_select(target_options_t *options)
{
  uint32_t chip_id, chip_exid;

  dap_reset_target_hw(1);
  dap_reset_link();

  // Stop the core
  dap_write_word(DHCSR, DHCSR_DBGKEY | DHCSR_DEBUGEN | DHCSR_HALT);
  dap_write_word(DEMCR, DEMCR_VC_CORERESET);
  dap_write_word(AIRCR, AIRCR_VECTKEY | AIRCR_SYSRESETREQ);

  uint32_t id = dap_read_word(0xe0042000);

  verbose("ID = 0x%08x\n", id);

  verbose("--- done ---\n");

  exit(1);
}

Run it as  "./edbg -b -t samv71 -r -f temp.bin", so it uses this select function.

If everything works, it should print the ID code as described in the section 31.6.1 "MCU device ID code" of the user manual.

If that does not work, post a complete output and we'll see where it gets stuck.

In case of my device and debugger it prints:

Quote
Debugger: Alex Taradov Generic CMSIS-DAP Adapter F4F56A90 v0.5 (SJ)
Clock frequency: 16.0 MHz
ID = 0x10016438
--- done ---
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 07, 2021, 08:53:52 pm
I've implemented enough of JTAG support to make OpenOCD work:
Quote
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: JTAG Supported
Info : CMSIS-DAP: FW Version = v0.5
Info : CMSIS-DAP: Serial# = F4F56A90
Info : CMSIS-DAP: Interface Initialised (JTAG)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : cmsis-dap JTAG TLR_RESET
Info : cmsis-dap JTAG TLR_RESET
Info : JTAG tap: stm32f3x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f3x.bs tap/device found: 0x06438041 (mfg: 0x020 (STMicroelectronics), part: 0x6438, ver: 0x0)
Info : stm32f3x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f3x.cpu on 3333
Info : Listening on port 3333 for gdb connections
{name stm32f1x base 0 size 0 bus_width 0 chip_width 0}
0xe0042000: 10016438

Unfortunately, OpenOCD just uses JTAG_SEQENCE for everything, including ARM specific stuff. So implementing the code for the JTAG transfers would be hard, as there is no software to test it.

Also, after looking closer, I see that OpenOCD does read the debugger information. In this case "FW Version = v0.5" and "Serial# = F4F56A90" here are strings read out of the debugger over HID.

And in your case corresponding information is here:
Quote
Info : 134 3881 cmsis_dap.c:788 cmsis_dap_get_caps_info(): CMSIS-DAP: SWD  Supported
Info : 135 3881 cmsis_dap.c:790 cmsis_dap_get_caps_info(): CMSIS-DAP: JTAG Supported
Info : 136 3882 cmsis_dap.c:768 cmsis_dap_get_version_info(): CMSIS-DAP: FW Version = 1.0
Info : 137 3886 cmsis_dap.c:881 cmsis_dap_swd_open(): CMSIS-DAP: Interface Initialised (SWD)
Debug: 138 3888 cmsis_dap.c:953 cmsis_dap_init(): CMSIS-DAP: Packet Size = 64
Debug: 139 3890 cmsis_dap.c:966 cmsis_dap_init(): CMSIS-DAP: Packet Count = 8
Debug: 140 3890 cmsis_dap.c:969 cmsis_dap_init(): Allocating FIFO for 3 pending packets
Info : 141 3892 cmsis_dap.c:809 cmsis_dap_get_status(): SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 1 nRESET = 1
Info : 142 3902 cmsis_dap.c:1023 cmsis_dap_init(): CMSIS-DAP: Interface ready

Also "CMSIS-DAP: Packet Count = 8" means that your debugger supports up to 8 pending requests. And "Allocating FIFO for 3 pending packets" means that OpenOCD actually takes advantage of that. Not sure why they went with 3, but it is better than 1.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 08, 2021, 01:26:50 am
All I got is this:
Code: [Select]
$ ./edbg -b -t samv71 -r -f temp.bin
Error: invalid response received
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 08, 2021, 01:28:14 am
Speaking of software for testing, SEGGER J-Link version 7 can work with CMSIS-DAP. Also there is Keil MDK.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 08, 2021, 01:41:02 am
Error: invalid response received

Ok, so something is strange with the device responses.

Modify this functions in dbg_lin.c to print out some debug info:

Code: [Select]
int dbg_dap_cmd(uint8_t *data, int resp_size, int req_size)
{
  uint8_t cmd = data[0];
  int res;

  verbose("---\n");
  for (int i = 0; i < 16; i++)
    verbose("0x%02x ", data[i]);
  verbose("\n");

  memset(hid_buffer, 0xff, report_size + 1);

  hid_buffer[0] = 0x00; // Report ID
  memcpy(&hid_buffer[1], data, req_size);

  res = write(debugger_fd, hid_buffer, report_size + 1);
  if (res < 0)
    perror_exit("debugger write()");

  res = read(debugger_fd, hid_buffer, report_size + 1);
  if (res < 0)
    perror_exit("debugger read()");

  check(res, "empty response received");

  for (int i = 0; i < 16; i++)
    verbose("0x%02x ", hid_buffer[i]);
  verbose("\n");

  check(hid_buffer[0] == cmd, "invalid response received");

  res--;
  memcpy(data, &hid_buffer[1], (resp_size < res) ? resp_size : res);

  return res;
}

Provide the complete output and we'll see what exactly fails, since it seems to work at least somewhat.

I know all those tools support CMSIS-DAP. That's how I originally testes SWD stuff. The issue here is have a tool that issues those ARM-specific  commands. I think the best I can do is implement them the best I can, and hope they either work, or nobody ever uses them. Or someone uses and they don't work, and they report the issue.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: thinkfat on May 08, 2021, 08:03:18 am
Unfortunately, OpenOCD just uses JTAG_SEQENCE for everything, including ARM specific stuff. So implementing the code for the JTAG transfers would be hard, as there is no software to test it.

That's likely because the code dealing with the actual target uses the internal DAP layer, which sits on top of the JTAG or SWD interface layer. I guess it would be possible to tread CMSIS-DAP as a "high-level adapter", like J-Link, but probably nobody bothered enough to do it.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 08, 2021, 01:21:54 pm
Provide the complete output and we'll see what exactly fails, since it seems to work at least somewhat.
I have to modify those for macOS, but anyway...
Code: [Select]
$ ./edbg -b -t samv71 -r -f temp.bin
---
0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0xf0 0x4f 0x00 0xe9 0xa4 0x7f 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x00 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x01 0x00 0x00 0xf0 0x09 0xb7 0xeb 0xfe 0x7f 0x00 0x00 0xb1 0x16 0x09 0x04 0x01
0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x03 0xf0 0x09 0xb7 0xeb 0xfe 0x7f 0x00 0x00 0xb6 0x16 0x09 0x04 0x01 0x00 0x00
0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Error: invalid response received
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: Harjit on May 08, 2021, 02:54:00 pm
In addition to @ataradov's cool project, another couple of projects for SWD debugging:

https://cortexprog.com/
https://github.com/blacksphere/blackmagic
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 08, 2021, 05:21:08 pm
I can't make sense of that log. The first communication that happens with the debugger is a series of ID_DAP_INFO (0x00) commands. The second byte of the command is the requested information type. The first 4 requested strings are DAP_INFO_VENDOR (0x01), DAP_INFO_PRODUCT (0x02), DAP_INFO_SER_NUM (0x03), DAP_INFO_FW_VER (0x04).

The first command makes sense. It starts with 0x00 0x01. This is ID_DAP_INFO / DAP_INFO_VENDOR. The response logically also makes sense, the first byte is the command, it must mirror data[0]. The second byte is the length of the response. It is 0 in this case, which is just means that there is no vendor string.

The second command is already strange. The command itself is fine, it is ID_DAP_INFO / DAP_INFO_PRODUCT. But the response starts with 0xff, which is not the copy of the command. This is the point where check(hid_buffer[0] == cmd, "invalid response received") should have failed, since cmd would be 0x00 and hid_buffer[0] is 0xff.

I don't understand why it continued from there. First of all, double check your modifications and that you are printing things in the correct place. And also add this right before the check(...):
Code: [Select]
verbose("buf = 0x%02x, cmd = 0x%02x\n", hid_buffer[0], cmd);
Those values must match what is printed by the loops, and if they do not match each other, then the check should fail.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 09, 2021, 12:59:45 pm
I have found out that my specific USB library likes to spit FF FF bytes at me when reading from the USB endpoint and there is nothing there yet, so I implemented a filter to remove all of those junk frames and filed a bug to the upstream. (https://github.com/dmitrystu/libusb_stm32/issues/91) Now it is progressing a little, even with the 8-slot buffer reinstated:

Code: [Select]
$ ./edbg -b -t samv71 -r -f temp.bin
---
0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x70 0x4f 0x00 0x39 0xa2 0x7f 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x00 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x00 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x04 0x31 0x2e 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x00 0xf0 0x2e 0x30 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x01 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Debugger: SushiBits Innovative SushiBits One with CMSIS-DAP 63C8AF92 1.0 (SJ)
Clock frequency: 16.0 MHz
---
0x03 0x80 0xc2 0xbb 0xe3 0xfe 0x7f 0x00 0x00 0x8f 0x70 0x04 0x0c 0x01 0x00 0x00
0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x02 0x01 0x80 0xc2 0xbb 0xe3 0xfe 0x7f 0x00 0x00 0x94 0x70 0x04 0x0c 0x01 0x00
0x02 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x04 0x00 0x00 0x80 0x80 0x00 0x80 0xc2 0xbb 0xe3 0xfe 0x7f 0x00 0x00 0xa5 0x70
0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x13 0x00 0x80 0xc2 0xbb 0xe3 0xfe 0x7f 0x00 0x00 0xac 0x70 0x04 0x0c 0x01 0x00
0x13 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x11 0x00 0x24 0xf4 0x00 0x80 0xc2 0xbb 0xe3 0xfe 0x7f 0x00 0x00 0xb7 0x70 0x04
0x11 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x01 0x00 0x01 0x80 0xc2 0xbb 0xe3 0xfe 0x7f 0x00 0x00 0xc3 0x70 0x04 0x0c 0x01
0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x10 0x03 0x83 0x00 0x00 0x00 0x00 0x50 0xbf 0xbb 0xe3 0xfe 0x7f 0x00 0x00 0xa0
0x10 0x2f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x10 0x83 0x83 0x00 0x00 0x00 0x00 0x50 0xbf 0xbb 0xe3 0xfe 0x7f 0x00 0x00 0xa0
0x10 0xaf 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x12 0x88 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
0x12 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x05 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x05 0x00 0x07 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff 0xff
---
0x01 0x00 0x00 0x50 0xba 0xbb 0xe3 0xfe 0x7f 0x00 0x00 0xa4 0x67 0x04 0x0c 0x01
0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
---
0x03 0x50 0xba 0xbb 0xe3 0xfe 0x7f 0x00 0x00 0xa9 0x67 0x04 0x0c 0x01 0x00 0x00
0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Error: invalid response during transfer (count = 0/1, status = 7)

I don't understand why it continued from there. First of all, double check your modifications and that you are printing things in the correct place. And also add this right before the check(...):
Code: [Select]
verbose("buf = 0x%02x, cmd = 0x%02x\n", hid_buffer[0], cmd);
Those values must match what is printed by the loops, and if they do not match each other, then the check should fail.
I think the continuing commands are just a teardown sequence with ID_DAP_LED and ID_DAP_DISCONNECT.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 09, 2021, 01:28:40 pm
Further getting rid of some memcpy's and memset's:

Code: [Select]
$ ./edbg -b -c 1000 -t samv71 -r -f temp.bin
---
0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x03 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x04 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x04 0x31 0x2e 0x30 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0xf0 0x2e 0x30 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x01 0x03 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Debugger: SushiBits Innovative SushiBits One with CMSIS-DAP 63C8AF92 1.0 (SJ)
Clock frequency: 1.0 MHz
---
0x03 0x70 0xe2 0x75 0xe2 0xfe 0x7f 0x00 0x00 0x8f 0x50 0x4a 0x0d 0x01 0x00 0x00
0x03 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x02 0x01 0x70 0xe2 0x75 0xe2 0xfe 0x7f 0x00 0x00 0x94 0x50 0x4a 0x0d 0x01 0x00
0x02 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x04 0x00 0x00 0x80 0x80 0x00 0x70 0xe2 0x75 0xe2 0xfe 0x7f 0x00 0x00 0xa5 0x50
0x04 0x00 0x00 0x80 0x80 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x13 0x00 0x70 0xe2 0x75 0xe2 0xfe 0x7f 0x00 0x00 0xac 0x50 0x4a 0x0d 0x01 0x00
0x13 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x11 0x40 0x42 0x0f 0x00 0x70 0xe2 0x75 0xe2 0xfe 0x7f 0x00 0x00 0xb7 0x50 0x4a
0x11 0x00 0x42 0x0f 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x01 0x00 0x01 0x70 0xe2 0x75 0xe2 0xfe 0x7f 0x00 0x00 0xc3 0x50 0x4a 0x0d 0x01
0x01 0x00 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x03 0x83 0x00 0x00 0x00 0x00 0x40 0xdf 0x75 0xe2 0xfe 0x7f 0x00 0x00 0xa0
0x10 0x2f 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x83 0x83 0x00 0x00 0x00 0x00 0x40 0xdf 0x75 0xe2 0xfe 0x7f 0x00 0x00 0xa0
0x10 0xaf 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x12 0x88 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
0x12 0x88 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
---
0x01 0x00 0x00 0xb0 0xda 0x75 0xe2 0xfe 0x7f 0x00 0x00 0xb1 0x46 0x4a 0x0d 0x01
0x01 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x03 0xb0 0xda 0x75 0xe2 0xfe 0x7f 0x00 0x00 0xb6 0x46 0x4a 0x0d 0x01 0x00 0x00
0x03 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Error: SWJ_SEQUENCE failed
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 09, 2021, 04:53:59 pm
Ye, teardown sequence makes sense. It was a later addition, and I forget that it is there.

What memcpy()s did you get rid of? It made more progress with the first log. In the last log the issue is that command "0x12 0x88 0xff ...." got a response that is just a copy of the request "0x12 0x88 0xff 0xff .....".

In your first log you see a correct response "0x12 0x00 0x00 0x00......". The only part that matter is first two bytes. And the second byte should be 0x00 (DAP_OK). There is no way SWJ_SEQUENCE can fail, it just blindly toggles the pins, so there is something wrong.

In your case "invalid response during transfer (count = 0/1, status = 7)" means that debugger attempted to perform a transfer, but status=7 means that the target did not respond, and the 3-bit ACK code was all 1s.

The transfer that fails is dap_read_idcode() following ID_DAP_SWJ_SEQUENCE in the dap_reset_link(). Reading the ID code is part of the switching to SWD mode.

So in your last log ID_DAP_SWJ_SEQUENCE of that function is broken. In the previous log, everything seems to work as expected, but it seems like the target is not connected properly or pins are not toggling correctly.

Get back to the status=7 situation and capture SWDIO/SWCLK pins on the scope. See that they are doing anything. You are very close.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 09, 2021, 06:06:20 pm
What memcpy()s did you get rid of? It made more progress with the first log. In the last log the issue is that command "0x12 0x88 0xff ...." got a response that is just a copy of the request "0x12 0x88 0xff 0xff .....".
I used atomic-ish operations by always writing the DAP protocol core's response into a zeroed temporary buffer, then copied things into the 8-slot buffer array. That means a lot of 64-byte copies, although it does means operations are largely atomic.

So in your last log ID_DAP_SWJ_SEQUENCE of that function is broken. In the previous log, everything seems to work as expected, but it seems like the target is not connected properly or pins are not toggling correctly.
I know for the fact that my target is working and connected as I can use a J-Link to talk to the exact same target chip (while CMSIS-DAP has been disconnected.)

Get back to the status=7 situation and capture SWDIO/SWCLK pins on the scope. See that they are doing anything. You are very close.
Do I need to do two-channel capture? That would require me to create a rig.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 09, 2021, 06:57:37 pm
Do I need to do two-channel capture? That would require me to create a rig.
For a first pass single channel should be fine. Just to see if pins are toggling at all.

It may also be an issue with readback or switching SWDIO to input. Try to disconnect SWDIO from the target and pull it down on the debugger. Check that you get status = 0.

Obviously figure out how to get back to the state with status = 7 first.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 10, 2021, 02:33:05 am
Obviously figure out how to get back to the state with status = 7 first.
That's a software bug in the implementation of the triple-pointer ring buffer, which has been fixed.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 12, 2021, 02:56:25 pm
Now I got this:

Code: [Select]
$ ./edbg -b -c 1000 -t samv71 -r -f temp.bin
---
0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x03 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x04 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x04 0x31 0x2e 0x30 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0xf0 0x2e 0x30 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x01 0x03 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Debugger: SushiBits Innovative SushiBits One with CMSIS-DAP 63C8AF92 1.0 (SJ)
Clock frequency: 1.0 MHz
---
0x03 0x70 0x82 0xac 0xea 0xfe 0x7f 0x00 0x00 0x8f 0xb0 0x13 0x05 0x01 0x00 0x00
0x03 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x02 0x01 0x70 0x82 0xac 0xea 0xfe 0x7f 0x00 0x00 0x94 0xb0 0x13 0x05 0x01 0x00
0x02 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x04 0x00 0x00 0x80 0x80 0x00 0x70 0x82 0xac 0xea 0xfe 0x7f 0x00 0x00 0xa5 0xb0
0x04 0x00 0x00 0x80 0x80 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x13 0x00 0x70 0x82 0xac 0xea 0xfe 0x7f 0x00 0x00 0xac 0xb0 0x13 0x05 0x01 0x00
0x13 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x11 0x40 0x42 0x0f 0x00 0x70 0x82 0xac 0xea 0xfe 0x7f 0x00 0x00 0xb7 0xb0 0x13
0x11 0x00 0x42 0x0f 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x01 0x00 0x01 0x70 0x82 0xac 0xea 0xfe 0x7f 0x00 0x00 0xc3 0xb0 0x13 0x05 0x01
0x01 0x00 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x03 0x83 0x00 0x00 0x00 0x00 0x40 0x7f 0xac 0xea 0xfe 0x7f 0x00 0x00 0xa0
0x10 0x27 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x83 0x83 0x00 0x00 0x00 0x00 0x40 0x7f 0xac 0xea 0xfe 0x7f 0x00 0x00 0xa0
0x10 0xa7 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x12 0x88 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
0x12 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x05 0x01 0x01 0x77 0x14 0xa0 0x1b 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x03 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
0x05 0x03 0x01 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
---
0x05 0x00 0x03 0x01 0x12 0x00 0x00 0xff 0x05 0xf0 0xed 0x00 0xe0 0x0d 0x03 0x00
0x05 0x03 0x01 0x01 0x12 0x00 0x00 0xff 0x05 0xf0 0xed 0x00 0xe0 0x0d 0x03 0x00
---
0x05 0x00 0x03 0x01 0x12 0x00 0x00 0xff 0x05 0xfc 0xed 0x00 0xe0 0x0d 0x01 0x00
0x05 0x03 0x01 0x01 0x12 0x00 0x00 0xff 0x05 0xfc 0xed 0x00 0xe0 0x0d 0x01 0x00
---
0x05 0x00 0x03 0x01 0x12 0x00 0x00 0xff 0x05 0x0c 0xed 0x00 0xe0 0x0d 0x04 0x00
0x05 0x03 0x01 0x01 0x12 0x00 0x00 0xff 0x05 0x0c 0xed 0x00 0xe0 0x0d 0x04 0x00
---
0x05 0x00 0x03 0x01 0x12 0x00 0x00 0xff 0x05 0x00 0x20 0x04 0xe0 0x0f 0x00 0xfa
0x05 0x03 0x01 0x10 0x64 0x03 0x20 0xff 0x05 0x00 0x20 0x04 0xe0 0x0f 0xff 0xff
ID = 0x20036410
--- done ---

So is it working then?
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 12, 2021, 03:01:05 pm
And in OpenOCD I now have this when talking SWD:

Code: [Select]
$ openocd -d3 -f interface/cmsis-dap.cfg -c "transport select swd" -c "adapter speed 1000" -f target/stm32f1x.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
[url]http://openocd.org/doc/doxygen/bugs.html[/url]
User : 13 1 options.c:63 configuration_output_handler(): debug_level: 3
User : 14 1 options.c:63 configuration_output_handler():
Debug: 15 1 options.c:244 add_default_dirs(): bindir=/usr/local/Cellar/open-ocd/0.11.0/bin
Debug: 16 1 options.c:245 add_default_dirs(): pkgdatadir=/usr/local/Cellar/open-ocd/0.11.0/share/openocd
Debug: 17 1 options.c:246 add_default_dirs(): exepath=/usr/local/Cellar/open-ocd/0.11.0/bin
Debug: 18 1 options.c:247 add_default_dirs(): bin2data=../share/openocd
Debug: 19 1 configuration.c:42 add_script_search_dir(): adding /Users/technix/Library/Preferences/org.openocd
Debug: 20 1 configuration.c:42 add_script_search_dir(): adding /Users/technix/.config/openocd
Debug: 21 1 configuration.c:42 add_script_search_dir(): adding /Users/technix/.openocd
Debug: 22 1 configuration.c:42 add_script_search_dir(): adding /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/site
Debug: 23 1 configuration.c:42 add_script_search_dir(): adding /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts
Debug: 24 1 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/interface/cmsis-dap.cfg
Debug: 25 2 command.c:146 script_debug(): command - adapter driver cmsis-dap
Debug: 27 2 command.c:146 script_debug(): command - transport select swd
User : 28 2 options.c:63 configuration_output_handler(): swdUser : 29 2 options.c:63 configuration_output_handler():
Debug: 30 2 command.c:146 script_debug(): command - adapter speed 1000
Debug: 32 2 core.c:1822 jtag_config_khz(): handle jtag khz
Debug: 33 2 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 34 2 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
User : 35 2 options.c:63 configuration_output_handler(): adapter speed: 1000 kHz
User : 36 2 options.c:63 configuration_output_handler():
Debug: 37 2 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/target/stm32f1x.cfg
Debug: 38 2 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/target/swj-dp.tcl
Debug: 39 2 command.c:146 script_debug(): command - transport select
Debug: 40 3 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/mem_helper.tcl
Debug: 41 3 command.c:146 script_debug(): command - add_usage_text mrw address
Debug: 43 3 command.c:1115 help_add_command(): added 'mrw' help text
Debug: 44 3 command.c:146 script_debug(): command - add_help_text mrw Returns value of word in memory.
Debug: 46 3 command.c:1128 help_add_command(): added 'mrw' help text
Debug: 47 3 command.c:146 script_debug(): command - add_usage_text mrh address
Debug: 49 3 command.c:1115 help_add_command(): added 'mrh' help text
Debug: 50 3 command.c:146 script_debug(): command - add_help_text mrh Returns value of halfword in memory.
Debug: 52 3 command.c:1128 help_add_command(): added 'mrh' help text
Debug: 53 3 command.c:146 script_debug(): command - add_usage_text mrb address
Debug: 55 3 command.c:1115 help_add_command(): added 'mrb' help text
Debug: 56 3 command.c:146 script_debug(): command - add_help_text mrb Returns value of byte in memory.
Debug: 58 3 command.c:1128 help_add_command(): added 'mrb' help text
Debug: 59 3 command.c:146 script_debug(): command - add_usage_text mmw address setbits clearbits
Debug: 61 3 command.c:1115 help_add_command(): added 'mmw' help text
Debug: 62 3 command.c:146 script_debug(): command - add_help_text mmw Modify word in memory. new_val = (old_val & ~clearbits) | setbits;
Debug: 64 3 command.c:1128 help_add_command(): added 'mmw' help text
Debug: 65 3 command.c:146 script_debug(): command - transport select
Debug: 66 3 command.c:146 script_debug(): command - transport select
Debug: 67 3 command.c:146 script_debug(): command - transport select
Debug: 68 3 command.c:146 script_debug(): command - swd newdap stm32f1x cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x1ba01477
Debug: 69 3 tcl.c:572 jim_newtap_cmd(): Creating New Tap, Chip: stm32f1x, Tap: cpu, Dotted: stm32f1x.cpu, 8 params
Debug: 70 3 core.c:1488 jtag_tap_init(): Created Tap: stm32f1x.cpu @ abs position 0, irlen 0, capture: 0x0 mask: 0x0
Debug: 71 3 command.c:146 script_debug(): command - dap create stm32f1x.dap -chain-position stm32f1x.cpu
Debug: 72 3 command.c:146 script_debug(): command - transport select
Debug: 73 3 command.c:146 script_debug(): command - target create stm32f1x.cpu cortex_m -endian little -dap stm32f1x.dap
Debug: 74 3 command.c:376 register_command(): command 'rtt' is already registered in '<global>' context
Debug: 75 3 command.c:146 script_debug(): command - stm32f1x.cpu configure -work-area-phys 0x20000000 -work-area-size 0x1000 -work-area-backup 0
Debug: 76 3 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 77 3 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 78 3 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 79 3 command.c:146 script_debug(): command - flash bank stm32f1x.flash stm32f1x 0x08000000 0 0 0 stm32f1x.cpu
Debug: 81 3 tcl.c:1319 handle_flash_bank_command(): 'stm32f1x' driver usage field missing
Debug: 82 3 command.c:146 script_debug(): command - adapter speed 1000
Debug: 84 3 core.c:1822 jtag_config_khz(): handle jtag khz
Debug: 85 3 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 86 3 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 87 3 command.c:146 script_debug(): command - adapter srst delay 100
Debug: 89 3 command.c:146 script_debug(): command - transport select
Debug: 90 3 command.c:146 script_debug(): command - reset_config srst_nogate
Debug: 92 3 command.c:146 script_debug(): command - transport select
Debug: 93 3 command.c:146 script_debug(): command - cortex_m reset_config sysresetreq
Debug: 95 3 command.c:146 script_debug(): command - stm32f1x.cpu configure -event examine-end
# DBGMCU_CR |= DBG_WWDG_STOP | DBG_IWDG_STOP |
#              DBG_STANDBY | DBG_STOP | DBG_SLEEP
mmw 0xE0042004 0x00000307 0

Debug: 96 3 command.c:146 script_debug(): command - stm32f1x.cpu configure -event trace-config
# Set TRACE_IOEN; TRACE_MODE is set to async; when using sync
# change this value accordingly to configure trace pins
# assignment
mmw 0xE0042004 0x00000020 0

Info : 97 3 server.c:312 add_service(): Listening on port 6666 for tcl connections
Info : 98 3 server.c:312 add_service(): Listening on port 4444 for telnet connections
Debug: 99 3 command.c:146 script_debug(): command - init
Debug: 101 3 command.c:146 script_debug(): command - target init
Debug: 103 3 command.c:146 script_debug(): command - target names
Debug: 104 3 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-flash-erase-start
Debug: 105 3 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-flash-erase-start reset init
Debug: 106 3 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-flash-write-end
Debug: 107 3 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-flash-write-end reset halt
Debug: 108 3 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-attach
Debug: 109 3 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-attach halt 1000
Debug: 110 3 target.c:1639 handle_target_init_command(): Initializing targets...
Debug: 111 3 semihosting_common.c:99 semihosting_common_init():
Debug: 112 17 cmsis_dap_usb_bulk.c:157 cmsis_dap_usb_open(): found product string of 0x0002:0xda42 'SushiBits One with CMSIS-DAP'
Debug: 113 17 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0002:0xda42
Debug: 114 17 cmsis_dap_usb_bulk.c:237 cmsis_dap_usb_open(): skipping interface 0, has only 1 endpoints
Debug: 115 17 cmsis_dap_usb_bulk.c:285 cmsis_dap_usb_open(): skipping interface 1, class 10 subclass 0 protocol 0
Debug: 116 17 cmsis_dap_usb_bulk.c:224 cmsis_dap_usb_open(): found interface 2 string 'SushiBits One Embedded CMSIS-DAP'
Debug: 117 17 cmsis_dap_usb_bulk.c:244 cmsis_dap_usb_open(): skipping interface 2, endpoint[0] is not bulk out
Debug: 118 18 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a40:0x0101
Debug: 119 18 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1366:0x0101
Debug: 120 19 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x046d:0xc52b
Debug: 121 19 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x03f0:0x052a
Debug: 122 20 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x04d8:0x9012
Debug: 123 20 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x03eb:0x2104
Debug: 124 20 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0002:0xf003
Debug: 125 21 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0451:0x8140
Debug: 126 21 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1050:0x0407
Debug: 127 21 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x2109:0x2812
Debug: 128 22 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x046d:0x085c
Debug: 129 22 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x2109:0x2812
Debug: 130 22 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a86:0x752d
Debug: 131 22 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0451:0x8142
Debug: 132 23 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a40:0x0101
Info : 133 32 cmsis_dap.c:788 cmsis_dap_get_caps_info(): CMSIS-DAP: SWD  Supported
Info : 134 32 cmsis_dap.c:790 cmsis_dap_get_caps_info(): CMSIS-DAP: JTAG Supported
Info : 135 34 cmsis_dap.c:768 cmsis_dap_get_version_info(): CMSIS-DAP: FW Version = 1.0
Info : 136 38 cmsis_dap.c:881 cmsis_dap_swd_open(): CMSIS-DAP: Interface Initialised (SWD)
Debug: 137 40 cmsis_dap.c:953 cmsis_dap_init(): CMSIS-DAP: Packet Size = 64
Debug: 138 42 cmsis_dap.c:966 cmsis_dap_init(): CMSIS-DAP: Packet Count = 8
Debug: 139 42 cmsis_dap.c:969 cmsis_dap_init(): Allocating FIFO for 3 pending packets
Info : 140 44 cmsis_dap.c:809 cmsis_dap_get_status(): SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 1 nRESET = 1
Info : 141 54 cmsis_dap.c:1023 cmsis_dap_init(): CMSIS-DAP: Interface ready
Debug: 142 54 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 143 54 core.c:1789 adapter_khz_to_speed(): have interface set up
Debug: 144 56 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 145 56 core.c:1789 adapter_khz_to_speed(): have interface set up
Info : 146 56 core.c:1565 adapter_init(): clock speed 1000 kHz
Debug: 147 56 openocd.c:143 handle_init_command(): Debug Adapter init complete
Debug: 148 56 command.c:146 script_debug(): command - transport init
Debug: 150 56 transport.c:229 handle_transport_init(): handle_transport_init
Debug: 151 56 command.c:146 script_debug(): command - dap init
Debug: 153 56 arm_dap.c:106 dap_init_all(): Initializing all DAPs ...
Debug: 154 60 cmsis_dap.c:843 cmsis_dap_swd_switch_seq(): JTAG-to-SWD
Info : 155 68 adi_v5_swd.c:148 swd_connect(): SWD DPIDR 0x1ba01477
Debug: 156 71 arm_adi_v5.c:653 dap_dp_init(): stm32f1x.dap
Debug: 157 71 arm_adi_v5.c:685 dap_dp_init(): DAP: wait CDBGPWRUPACK
Debug: 158 71 arm_adi_v5.h:507 dap_dp_poll_register(): DAP: poll 4, mask 0x20000000, value 0x20000000
Debug: 159 74 arm_adi_v5.c:693 dap_dp_init(): DAP: wait CSYSPWRUPACK
Debug: 160 74 arm_adi_v5.h:507 dap_dp_poll_register(): DAP: poll 4, mask 0x80000000, value 0x80000000
Debug: 161 77 cmsis_dap.c:587 cmsis_dap_swd_write_from_queue(): refusing to enable sticky overrun detection
Debug: 162 80 openocd.c:160 handle_init_command(): Examining targets...
Debug: 163 80 target.c:1827 target_call_event_callbacks(): target event 19 (examine-start) for core stm32f1x.cpu
Debug: 164 83 arm_adi_v5.c:904 dap_find_ap(): Found AHB3-AP at AP index: 0 (IDR=0x14770011)
Debug: 165 87 arm_adi_v5.c:793 mem_ap_init(): MEM_AP Packed Transfers: enabled
Debug: 166 87 arm_adi_v5.c:804 mem_ap_init(): MEM_AP CFG: large data 0, long address 0, big-endian 0
Debug: 167 90 target.c:2589 target_read_u32(): address: 0xe000ed00, value: 0x411fc231
Debug: 168 90 cortex_m.c:2001 cortex_m_examine(): Cortex-M3 r1p1 processor detected
Debug: 169 90 cortex_m.c:2012 cortex_m_examine(): cpuid: 0x411fc231
Debug: 170 93 target.c:2589 target_read_u32(): address: 0xe000edf0, value: 0x00030003
Debug: 171 93 target.c:2677 target_write_u32(): address: 0xe000edfc, value: 0x01000000
Debug: 172 99 target.c:2589 target_read_u32(): address: 0xe0002000, value: 0x00000260
Debug: 173 99 target.c:2677 target_write_u32(): address: 0xe0002008, value: 0x00000000
Debug: 174 102 target.c:2677 target_write_u32(): address: 0xe000200c, value: 0x00000000
Debug: 175 105 target.c:2677 target_write_u32(): address: 0xe0002010, value: 0x00000000
Debug: 176 108 target.c:2677 target_write_u32(): address: 0xe0002014, value: 0x00000000
Debug: 177 111 target.c:2677 target_write_u32(): address: 0xe0002018, value: 0x00000000
Debug: 178 114 target.c:2677 target_write_u32(): address: 0xe000201c, value: 0x00000000
Debug: 179 117 target.c:2677 target_write_u32(): address: 0xe0002020, value: 0x00000000
Debug: 180 120 target.c:2677 target_write_u32(): address: 0xe0002024, value: 0x00000000
Debug: 181 123 cortex_m.c:2116 cortex_m_examine(): FPB fpcr 0x260, numcode 6, numlit 2
Debug: 182 126 target.c:2589 target_read_u32(): address: 0xe0001000, value: 0x40000000
Debug: 183 126 cortex_m.c:1830 cortex_m_dwt_setup(): DWT_CTRL: 0x40000000
Debug: 184 129 target.c:2589 target_read_u32(): address: 0xe0001fbc, value: 0x00000000
Debug: 185 129 cortex_m.c:1837 cortex_m_dwt_setup(): DWT_DEVARCH: 0x0
Debug: 186 129 target.c:2677 target_write_u32(): address: 0xe0001028, value: 0x00000000
Debug: 187 132 target.c:2677 target_write_u32(): address: 0xe0001038, value: 0x00000000
Debug: 188 135 target.c:2677 target_write_u32(): address: 0xe0001048, value: 0x00000000
Debug: 189 138 target.c:2677 target_write_u32(): address: 0xe0001058, value: 0x00000000
Debug: 190 141 cortex_m.c:1886 cortex_m_dwt_setup(): DWT dwtcr 0x40000000, comp 4, watch/trigger
Info : 191 141 cortex_m.c:2126 cortex_m_examine(): stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Debug: 192 141 target.c:1827 target_call_event_callbacks(): target event 21 (examine-end) for core stm32f1x.cpu
Debug: 193 141 target.c:4779 target_handle_event(): target(0): stm32f1x.cpu (cortex_m) event: 21 (examine-end) action:
# DBGMCU_CR |= DBG_WWDG_STOP | DBG_IWDG_STOP |
#              DBG_STANDBY | DBG_STOP | DBG_SLEEP
mmw 0xE0042004 0x00000307 0

Debug: 194 144 command.c:146 script_debug(): command - mww 0xE0042004 775
Debug: 196 150 command.c:146 script_debug(): command - flash init
Debug: 198 153 tcl.c:1385 handle_flash_init_command(): Initializing flash devices...
Debug: 199 153 command.c:146 script_debug(): command - nand init
Debug: 201 156 tcl.c:498 handle_nand_init_command(): Initializing NAND devices...
Debug: 202 156 command.c:146 script_debug(): command - pld init
Debug: 204 159 pld.c:206 handle_pld_init_command(): Initializing PLDs...
Info : 205 159 gdb_server.c:3503 gdb_target_start(): starting gdb server for stm32f1x.cpu on 3333
Info : 206 159 server.c:312 add_service(): Listening on port 3333 for gdb connections
^CDebug: 207 7042 server.c:609 sig_handler(): Terminating on Signal 2
Debug: 208 7042 command.c:146 script_debug(): command - shutdown
User : 210 7045 server.c:755 handle_shutdown_command(): shutdown command invoked
Debug: 211 7045 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 212 7049 cmsis_dap.c:848 cmsis_dap_swd_switch_seq(): SWD-to-JTAG

(Notice that ^C, that is when I exited OpenOCD.)

Things still does not work when talking JTAG though:
Code: [Select]
$ openocd -d3 -f interface/cmsis-dap.cfg -c "transport select jtag" -c "adapter speed 4000" -f target/stm32f1x.cfg
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
[url]http://openocd.org/doc/doxygen/bugs.html[/url]
User : 13 1 options.c:63 configuration_output_handler(): debug_level: 3
User : 14 1 options.c:63 configuration_output_handler():
Debug: 15 1 options.c:244 add_default_dirs(): bindir=/usr/local/Cellar/open-ocd/0.11.0/bin
Debug: 16 1 options.c:245 add_default_dirs(): pkgdatadir=/usr/local/Cellar/open-ocd/0.11.0/share/openocd
Debug: 17 1 options.c:246 add_default_dirs(): exepath=/usr/local/Cellar/open-ocd/0.11.0/bin
Debug: 18 1 options.c:247 add_default_dirs(): bin2data=../share/openocd
Debug: 19 1 configuration.c:42 add_script_search_dir(): adding /Users/technix/Library/Preferences/org.openocd
Debug: 20 1 configuration.c:42 add_script_search_dir(): adding /Users/technix/.config/openocd
Debug: 21 1 configuration.c:42 add_script_search_dir(): adding /Users/technix/.openocd
Debug: 22 1 configuration.c:42 add_script_search_dir(): adding /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/site
Debug: 23 1 configuration.c:42 add_script_search_dir(): adding /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts
Debug: 24 1 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/interface/cmsis-dap.cfg
Debug: 25 1 command.c:146 script_debug(): command - adapter driver cmsis-dap
Debug: 27 1 command.c:146 script_debug(): command - transport select jtag
User : 28 1 options.c:63 configuration_output_handler(): jtagUser : 29 1 options.c:63 configuration_output_handler():
Debug: 30 1 command.c:146 script_debug(): command - adapter speed 4000
Debug: 32 1 core.c:1822 jtag_config_khz(): handle jtag khz
Debug: 33 1 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 34 1 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
User : 35 1 options.c:63 configuration_output_handler(): adapter speed: 4000 kHz
User : 36 1 options.c:63 configuration_output_handler():
Debug: 37 2 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/target/stm32f1x.cfg
Debug: 38 2 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/target/swj-dp.tcl
Debug: 39 2 command.c:146 script_debug(): command - transport select
Debug: 40 2 configuration.c:97 find_file(): found /usr/local/Cellar/open-ocd/0.11.0/bin/../share/openocd/scripts/mem_helper.tcl
Debug: 41 3 command.c:146 script_debug(): command - add_usage_text mrw address
Debug: 43 3 command.c:1115 help_add_command(): added 'mrw' help text
Debug: 44 3 command.c:146 script_debug(): command - add_help_text mrw Returns value of word in memory.
Debug: 46 3 command.c:1128 help_add_command(): added 'mrw' help text
Debug: 47 3 command.c:146 script_debug(): command - add_usage_text mrh address
Debug: 49 3 command.c:1115 help_add_command(): added 'mrh' help text
Debug: 50 3 command.c:146 script_debug(): command - add_help_text mrh Returns value of halfword in memory.
Debug: 52 3 command.c:1128 help_add_command(): added 'mrh' help text
Debug: 53 3 command.c:146 script_debug(): command - add_usage_text mrb address
Debug: 55 3 command.c:1115 help_add_command(): added 'mrb' help text
Debug: 56 3 command.c:146 script_debug(): command - add_help_text mrb Returns value of byte in memory.
Debug: 58 3 command.c:1128 help_add_command(): added 'mrb' help text
Debug: 59 3 command.c:146 script_debug(): command - add_usage_text mmw address setbits clearbits
Debug: 61 3 command.c:1115 help_add_command(): added 'mmw' help text
Debug: 62 3 command.c:146 script_debug(): command - add_help_text mmw Modify word in memory. new_val = (old_val & ~clearbits) | setbits;
Debug: 64 3 command.c:1128 help_add_command(): added 'mmw' help text
Debug: 65 3 command.c:146 script_debug(): command - transport select
Debug: 66 3 command.c:146 script_debug(): command - transport select
Debug: 67 3 command.c:146 script_debug(): command - transport select
Debug: 68 3 command.c:146 script_debug(): command - jtag newtap stm32f1x cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3ba00477
Debug: 69 3 tcl.c:572 jim_newtap_cmd(): Creating New Tap, Chip: stm32f1x, Tap: cpu, Dotted: stm32f1x.cpu, 8 params
Debug: 70 3 tcl.c:596 jim_newtap_cmd(): Processing option: -irlen
Debug: 71 3 tcl.c:596 jim_newtap_cmd(): Processing option: -ircapture
Debug: 72 3 tcl.c:596 jim_newtap_cmd(): Processing option: -irmask
Debug: 73 3 tcl.c:596 jim_newtap_cmd(): Processing option: -expected-id
Debug: 74 3 core.c:1488 jtag_tap_init(): Created Tap: stm32f1x.cpu @ abs position 0, irlen 4, capture: 0x1 mask: 0xf
Debug: 75 3 command.c:146 script_debug(): command - dap create stm32f1x.dap -chain-position stm32f1x.cpu
Debug: 76 3 command.c:146 script_debug(): command - transport select
Debug: 77 3 command.c:146 script_debug(): command - jtag newtap stm32f1x bs -irlen 5
Debug: 78 3 tcl.c:572 jim_newtap_cmd(): Creating New Tap, Chip: stm32f1x, Tap: bs, Dotted: stm32f1x.bs, 2 params
Debug: 79 3 tcl.c:596 jim_newtap_cmd(): Processing option: -irlen
Debug: 80 3 core.c:1488 jtag_tap_init(): Created Tap: stm32f1x.bs @ abs position 1, irlen 5, capture: 0x1 mask: 0x3
Debug: 81 3 command.c:146 script_debug(): command - target create stm32f1x.cpu cortex_m -endian little -dap stm32f1x.dap
Debug: 82 3 command.c:376 register_command(): command 'rtt' is already registered in '<global>' context
Debug: 83 3 command.c:146 script_debug(): command - stm32f1x.cpu configure -work-area-phys 0x20000000 -work-area-size 0x1000 -work-area-backup 0
Debug: 84 3 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 85 3 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 86 3 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Debug: 87 3 command.c:146 script_debug(): command - flash bank stm32f1x.flash stm32f1x 0x08000000 0 0 0 stm32f1x.cpu
Debug: 89 3 tcl.c:1319 handle_flash_bank_command(): 'stm32f1x' driver usage field missing
Debug: 90 3 command.c:146 script_debug(): command - adapter speed 1000
Debug: 92 3 core.c:1822 jtag_config_khz(): handle jtag khz
Debug: 93 3 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 94 3 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 95 3 command.c:146 script_debug(): command - adapter srst delay 100
Debug: 97 3 command.c:146 script_debug(): command - transport select
Debug: 98 3 command.c:146 script_debug(): command - jtag_ntrst_delay 100
Debug: 100 3 command.c:146 script_debug(): command - reset_config srst_nogate
Debug: 102 3 command.c:146 script_debug(): command - transport select
Debug: 103 3 command.c:146 script_debug(): command - cortex_m reset_config sysresetreq
Debug: 105 3 command.c:146 script_debug(): command - stm32f1x.cpu configure -event examine-end
# DBGMCU_CR |= DBG_WWDG_STOP | DBG_IWDG_STOP |
#              DBG_STANDBY | DBG_STOP | DBG_SLEEP
mmw 0xE0042004 0x00000307 0

Debug: 106 3 command.c:146 script_debug(): command - stm32f1x.cpu configure -event trace-config
# Set TRACE_IOEN; TRACE_MODE is set to async; when using sync
# change this value accordingly to configure trace pins
# assignment
mmw 0xE0042004 0x00000020 0

Info : 107 3 server.c:312 add_service(): Listening on port 6666 for tcl connections
Info : 108 3 server.c:312 add_service(): Listening on port 4444 for telnet connections
Debug: 109 3 command.c:146 script_debug(): command - init
Debug: 111 3 command.c:146 script_debug(): command - target init
Debug: 113 3 command.c:146 script_debug(): command - target names
Debug: 114 3 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-flash-erase-start
Debug: 115 3 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-flash-erase-start reset init
Debug: 116 3 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-flash-write-end
Debug: 117 3 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-flash-write-end reset halt
Debug: 118 3 command.c:146 script_debug(): command - stm32f1x.cpu cget -event gdb-attach
Debug: 119 3 command.c:146 script_debug(): command - stm32f1x.cpu configure -event gdb-attach halt 1000
Debug: 120 3 target.c:1639 handle_target_init_command(): Initializing targets...
Debug: 121 3 semihosting_common.c:99 semihosting_common_init():
Debug: 122 16 cmsis_dap_usb_bulk.c:157 cmsis_dap_usb_open(): found product string of 0x0002:0xda42 'SushiBits One with CMSIS-DAP'
Debug: 123 16 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0002:0xda42
Debug: 124 16 cmsis_dap_usb_bulk.c:237 cmsis_dap_usb_open(): skipping interface 0, has only 1 endpoints
Debug: 125 16 cmsis_dap_usb_bulk.c:285 cmsis_dap_usb_open(): skipping interface 1, class 10 subclass 0 protocol 0
Debug: 126 16 cmsis_dap_usb_bulk.c:224 cmsis_dap_usb_open(): found interface 2 string 'SushiBits One Embedded CMSIS-DAP'
Debug: 127 16 cmsis_dap_usb_bulk.c:244 cmsis_dap_usb_open(): skipping interface 2, endpoint[0] is not bulk out
Debug: 128 16 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a40:0x0101
Debug: 129 17 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1366:0x0101
Debug: 130 17 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x046d:0xc52b
Debug: 131 17 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x03f0:0x052a
Debug: 132 18 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x04d8:0x9012
Debug: 133 19 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x03eb:0x2104
Debug: 134 19 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0002:0xf003
Debug: 135 19 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0451:0x8140
Debug: 136 19 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1050:0x0407
Debug: 137 19 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x2109:0x2812
Debug: 138 20 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x046d:0x085c
Debug: 139 20 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x2109:0x2812
Debug: 140 24 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a86:0x752d
Debug: 141 24 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x0451:0x8142
Debug: 142 24 cmsis_dap_usb_bulk.c:177 cmsis_dap_usb_open(): enumerating interfaces of 0x1a40:0x0101
Info : 143 34 cmsis_dap.c:788 cmsis_dap_get_caps_info(): CMSIS-DAP: SWD  Supported
Info : 144 34 cmsis_dap.c:790 cmsis_dap_get_caps_info(): CMSIS-DAP: JTAG Supported
Info : 145 35 cmsis_dap.c:768 cmsis_dap_get_version_info(): CMSIS-DAP: FW Version = 1.0
Info : 146 39 cmsis_dap.c:921 cmsis_dap_init(): CMSIS-DAP: Interface Initialised (JTAG)
Debug: 147 41 cmsis_dap.c:953 cmsis_dap_init(): CMSIS-DAP: Packet Size = 64
Debug: 148 43 cmsis_dap.c:966 cmsis_dap_init(): CMSIS-DAP: Packet Count = 8
Debug: 149 43 cmsis_dap.c:969 cmsis_dap_init(): Allocating FIFO for 3 pending packets
Info : 150 45 cmsis_dap.c:809 cmsis_dap_get_status(): SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 1 nRESET = 1
Info : 151 53 cmsis_dap.c:1023 cmsis_dap_init(): CMSIS-DAP: Interface ready
Debug: 152 53 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 153 53 core.c:1789 adapter_khz_to_speed(): have interface set up
Debug: 154 55 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value
Debug: 155 55 core.c:1789 adapter_khz_to_speed(): have interface set up
Info : 156 55 core.c:1565 adapter_init(): clock speed 1000 kHz
Debug: 157 55 openocd.c:143 handle_init_command(): Debug Adapter init complete
Debug: 158 55 command.c:146 script_debug(): command - transport init
Debug: 160 55 transport.c:229 handle_transport_init(): handle_transport_init
Debug: 161 57 core.c:830 jtag_add_reset(): SRST line released
Debug: 162 57 core.c:855 jtag_add_reset(): TRST line released
Debug: 163 57 core.c:327 jtag_call_event_callbacks(): jtag event: TAP reset
Debug: 164 286 command.c:146 script_debug(): command - jtag arp_init
Debug: 165 286 core.c:1578 jtag_init_inner(): Init JTAG chain
Debug: 166 286 core.c:327 jtag_call_event_callbacks(): jtag event: TAP reset
Info : 167 286 cmsis_dap.c:1076 cmsis_dap_execute_tlr_reset(): cmsis-dap JTAG TLR_RESET
Debug: 168 288 core.c:1243 jtag_examine_chain(): DR scan interrogation for IDCODE/BYPASS
Debug: 169 288 core.c:327 jtag_call_event_callbacks(): jtag event: TAP reset
Info : 170 292 cmsis_dap.c:1076 cmsis_dap_execute_tlr_reset(): cmsis-dap JTAG TLR_RESET
Info : 171 294 core.c:1142 jtag_examine_chain_display(): JTAG tap: stm32f1x.cpu tap/device found: 0x00410041 (mfg: 0x020 (STMicroelectronics), part: 0x0410, ver: 0x0)
Warn : 172 294 core.c:1142 jtag_examine_chain_display(): JTAG tap: stm32f1x.cpu       UNEXPECTED: 0x00410041 (mfg: 0x020 (STMicroelectronics), part: 0x0410, ver: 0x0)
Error: 173 294 core.c:1142 jtag_examine_chain_display(): JTAG tap: stm32f1x.cpu  expected 1 of 1: 0x3ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x3)
Info : 174 294 core.c:1142 jtag_examine_chain_display(): JTAG tap: stm32f1x.bs tap/device found: 0x00010041 (mfg: 0x020 (STMicroelectronics), part: 0x0010, ver: 0x0)
Debug: 175 294 core.c:1488 jtag_tap_init(): Created Tap: auto0.tap @ abs position 2, irlen 0, capture: 0x1 mask: 0x3
Info : 176 294 core.c:1142 jtag_examine_chain_display(): JTAG tap: auto0.tap tap/device found: 0x00010041 (mfg: 0x020 (STMicroelectronics), part: 0x0010, ver: 0x0)
Debug: 177 294 core.c:1488 jtag_tap_init(): Created Tap: auto1.tap @ abs position 3, irlen 0, capture: 0x1 mask: 0x3
Debug: 178 294 jep106.c:33 jep106_manufacturer(): BUG: Caller passed out-of-range JEP106 ID!
Info : 179 294 core.c:1142 jtag_examine_chain_display(): JTAG tap: auto1.tap tap/device found: 0xff800001 (mfg: 0x000 (<invalid>), part: 0xf800, ver: 0xf)
Warn : 180 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 160 0x80ffffff
Warn : 181 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 256 0xffffff80
Warn : 182 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 320 0xffffff80
Warn : 183 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 384 0xffff80ff
Warn : 184 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 448 0xff80ffff
Warn : 185 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 512 0x80ffffff
Warn : 186 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 608 0xffffff80
Error: 187 294 core.c:1319 jtag_examine_chain(): double-check your JTAG setup (interface, speed, ...)
Error: 188 294 core.c:1623 jtag_init_inner(): Trying to use configured scan chain anyway...
Debug: 189 295 core.c:1374 jtag_validate_ircapture(): IR capture validation scan
Debug: 190 296 core.c:1432 jtag_validate_ircapture(): stm32f1x.cpu: IR capture 0x01
Error: 191 296 core.c:1426 jtag_validate_ircapture(): stm32f1x.bs: IR capture error; saw 0x04 not 0x01
Debug: 192 296 core.c:327 jtag_call_event_callbacks(): jtag event: TAP reset
Info : 193 296 cmsis_dap.c:1076 cmsis_dap_execute_tlr_reset(): cmsis-dap JTAG TLR_RESET
Warn : 194 298 core.c:1646 jtag_init_inner(): Bypassing JTAG setup events due to errors
Debug: 195 298 command.c:146 script_debug(): command - dap init
Debug: 197 298 arm_dap.c:106 dap_init_all(): Initializing all DAPs ...
Debug: 198 298 arm_adi_v5.c:653 dap_dp_init(): stm32f1x.dap
Debug: 199 298 arm_adi_v5.c:685 dap_dp_init(): DAP: wait CDBGPWRUPACK
Debug: 200 298 arm_adi_v5.h:507 dap_dp_poll_register(): DAP: poll 4, mask 0x20000000, value 0x20000000
Debug: 201 298 cmsis_dap.c:1323 cmsis_dap_execute_scan(): discarding trailing empty field
Debug: 202 298 cmsis_dap.c:1323 cmsis_dap_execute_scan(): discarding trailing empty field
Info : 203 304 adi_v5_jtag.c:535 jtagdp_overrun_check(): DAP transaction stalled (WAIT) - slowing down
Error: 204 1306 adi_v5_jtag.c:581 jtagdp_overrun_check(): Timeout during WAIT recovery
Debug: 205 1306 cmsis_dap.c:1323 cmsis_dap_execute_scan(): discarding trailing empty field
Debug: 206 1306 cmsis_dap.c:1323 cmsis_dap_execute_scan(): discarding trailing empty field
Debug: 207 1308 cmsis_dap.c:1323 cmsis_dap_execute_scan(): discarding trailing empty field
Debug: 208 1308 cmsis_dap.c:1323 cmsis_dap_execute_scan(): discarding trailing empty field
Debug: 209 1312 command.c:629 run_command(): Command 'dap init' failed with error code -107
User : 210 1312 command.c:694 command_run_line():
Debug: 211 1312 command.c:629 run_command(): Command 'init' failed with error code -4
User : 212 1312 command.c:694 command_run_line():
Debug: 213 1312 target.c:2172 target_free_all_working_areas_restore(): freeing all working areas
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 12, 2021, 03:05:22 pm
Yep. It just read the value from the register. I would double check with the documentation that it is the correct value, but it looks good.

BTW, JTAG implementation in my firmware is coming along well. I will try to finish it this weekend. That is unless a second dose of the Moderna on Friday knocks me out.

I'm also making some improvements that I wanted to make for some time.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 12, 2021, 03:07:48 pm
I will read though your JTAG log in more details a bit later to see if I can figure out what may be wrong.

Is this just the device by itself in the chain? Or there are other devices?
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 12, 2021, 03:26:29 pm
Yep. It just read the value from the register. I would double check with the documentation that it is the correct value, but it looks good.
Awesome.

BTW, JTAG implementation in my firmware is coming along well. I will try to finish it this weekend. That is unless a second dose of the Moderna on Friday knocks me out.
I am still struggling with ARM's code. The problem I a getting is because ARM decided to pass in a whole 32-bit integer when only the lowest bit is supposed to be used, and not documenting that behavior. I had assumed that those uint32_t's are just bool's but apparantly they are not and I have to bulk replace "bit" with "(bit & 0b1)".

Also I am getting a second dose of Sinopharm Beijing Biotech's BBIBP-CorV this Friday.

I'm also making some improvements that I wanted to make for some time.
More awesome.

I will read though your JTAG log in more details a bit later to see if I can figure out what may be wrong.
On the surface one of the bytes in the ID is lost for whatever reason. Maybe I am having memory collision?

Is this just the device by itself in the chain? Or there are other devices?
It is STM32F103. Two TAPs in one chip.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 12, 2021, 09:16:53 pm
Is it possible that that specific device or revision is somehow not supported? It seems to be very close, you are getting meaningful values, but the overall output makes no sense.

Here is how relevant part looks in my case:
Quote
Info : 285 240 cmsis_dap_usb.c:1158 cmsis_dap_execute_tlr_reset(): cmsis-dap JTAG TLR_RESET
Info : 286 242 core.c:1142 jtag_examine_chain_display(): JTAG tap: stm32f3x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Info : 287 242 core.c:1142 jtag_examine_chain_display(): JTAG tap: stm32f3x.bs tap/device found: 0x06438041 (mfg: 0x020 (STMicroelectronics), part: 0x6438, ver: 0x0)
Debug: 288 242 core.c:1374 jtag_validate_ircapture(): IR capture validation scan
Debug: 289 245 core.c:1431 jtag_validate_ircapture(): stm32f3x.cpu: IR capture 0x01
Debug: 290 245 core.c:1431 jtag_validate_ircapture(): stm32f3x.bs: IR capture 0x01
As you can see it just cleanly detects two devices.

In your case the phrase "UNEXPECTED: 0x00410041" is interesting. It looks like a correct value, just not recognized.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 12, 2021, 09:23:29 pm
Although your ID is not listed in the section 31.6.2 "Boundary scan TAP" of the reference manual.

They are generally similar, but none are the same: 0x06412041, 0x06410041, 0x16410041, 0x06414041, 0x06430041, 0x06418041. Their naming scheme with specifying "density" instead of the actual part numbers is stupid, so I have no idea which one corresponds to your device.

F103 is faked a lot, check that you don't have some really bad fake.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 12, 2021, 11:55:45 pm
Although your ID is not listed in the section 31.6.2 "Boundary scan TAP" of the reference manual.

They are generally similar, but none are the same: 0x06412041, 0x06410041, 0x16410041, 0x06414041, 0x06430041, 0x06418041. Their naming scheme with specifying "density" instead of the actual part numbers is stupid, so I have no idea which one corresponds to your device.

F103 is faked a lot, check that you don't have some really bad fake.
It is not a fake, as scanning the chain using J-Link reports the correct ID's.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 13, 2021, 05:17:56 am
In that case I really don't know what may be wrong or how to debug that with OpenOCD. It looks like it mostly works, and it also does not look like a signal integrity issue either.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 13, 2021, 05:35:41 am
In that case I really don't know what may be wrong or how to debug that with OpenOCD. It looks like it mostly works, and it also does not look like a signal integrity issue either.
Code: [Select]
Warn : 180 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 160 0x80ffffff
Warn : 181 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 256 0xffffff80
Warn : 182 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 320 0xffffff80
Warn : 183 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 384 0xffff80ff
Warn : 184 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 448 0xff80ffff
Warn : 185 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 512 0x80ffffff
Warn : 186 294 core.c:1180 jtag_examine_chain_end(): Unexpected idcode after end of chain: 608 0xffffff80
Those are too periodic to be just random noise...
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 13, 2021, 05:37:13 am
That's just some random stuff it tries to do after mistakenly detecting the wrong devices. I would not look at anything past the mis-detected chain. Until that works, everything else is useless.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 13, 2021, 09:00:23 am
Well if it turns into hell supporting ARM's official code, I would rebase. Also once I got STM32F042 up and running I would be porting it to STM32F446 + USB HS with ULPI PHY. However I still don't have much idea on why that is not working...

(However with the current progress, my ATSAML11D16 module, also with a STM32F042-based CMSIS-DAP onboard debug probe and squeezed into a wide DIP-24 footprint, would be fully working.)
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 14, 2021, 02:41:27 am
JTAG support was now added - https://github.com/ataradov/free-dap

It was tested with ARM-specific commands (the handling between them and SWD was actually collapsed into a single function) and with simple bit-banging commands.

I can't guarantee that there are no errors, especially in edge cases, but generally it should work.

OpenOCD log attached for reference. It just does "mdw 0xe0042000" command as a test. This is the location of the device ID.

The size of the binary with JTAG support is 8296 bytes. Just SWD is 6824.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 14, 2021, 03:21:34 am
JTAG support was now added - https://github.com/ataradov/free-dap

It was tested with ARM-specific commands (the handling between them and SWD was actually collapsed into a single function) and with simple bit-banging commands.

I can't guarantee that there are no errors, especially in edge cases, but generally it should work.

OpenOCD log attached for reference. It just does "mdw 0xe0042000" command as a test. This is the location of the device ID.

The size of the binary with JTAG support is 8296 bytes. Just SWD is 6824.
Great!

On the other hand, I am having problems having edbg to talk to a ATSAML11D16 chip...
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 14, 2021, 03:33:40 am
What sort of problems? There was an issue with L11 a few days ago, so make sure you are on the latest code base or binaries.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 14, 2021, 03:39:31 am
What sort of problems? There was an issue with L11 a few days ago, so make sure you are on the latest code base or binaries.
Error connecting SWD. Somehow OpenOCD claim to have connected correctly, but not edbg.

I'll rebase first anyway, since it seem to me that your code is smaller than ARM's official code.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 14, 2021, 03:48:05 am
I would need to see exact error message and how it was called to tell what may be wrong.

The issue was in an infinite loop when programming, but the part identification worked fine.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 14, 2021, 04:46:28 am
I would need to see exact error message and how it was called to tell what may be wrong.
I think it was "Error: invalid response during transfer (count = 2/2, status = 3)" or something.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 14, 2021, 04:59:24 am
status 3 is illegal, but I get the drift. This is an actual communication error with the target. Hard to tell what exactly is wrong without investigating the place that fails.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 14, 2021, 05:00:42 am
status 3 is illegal, but I get the drift. This is an actual communication error with the target. Hard to tell what exactly is wrong without investigating the place that fails.
I'll put a more complete log here once I can. ATSAML11 don't have JTAG anyway.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 14, 2021, 11:26:10 am
Here is what I got:
Code: [Select]
$ ./edbg -b -c 1000 -t saml11 -r -f temp.bin
---
0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0xb0 0x4f 0xf0 0xe0 0x9b 0x7f 0x00 0x00
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x02 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x03 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x04 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x04 0x31 0x2e 0x30 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0xf0 0x2e 0x30 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x01 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Debugger: SushiBits Innovative SushiBits One with CMSIS-DAP 2ACC2DF0 1.0 (S)
Clock frequency: 1.0 MHz
---
0x03 0x10 0x92 0x35 0xea 0xfe 0x7f 0x00 0x00 0x8f 0xa0 0x8a 0x05 0x01 0x00 0x00
0x03 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x02 0x01 0x10 0x92 0x35 0xea 0xfe 0x7f 0x00 0x00 0x94 0xa0 0x8a 0x05 0x01 0x00
0x02 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x04 0x00 0x00 0x80 0x80 0x00 0x10 0x92 0x35 0xea 0xfe 0x7f 0x00 0x00 0xa5 0xa0
0x04 0x00 0x00 0x80 0x80 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x13 0x00 0x10 0x92 0x35 0xea 0xfe 0x7f 0x00 0x00 0xac 0xa0 0x8a 0x05 0x01 0x00
0x13 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x11 0x40 0x42 0x0f 0x00 0x10 0x92 0x35 0xea 0xfe 0x7f 0x00 0x00 0xb7 0xa0 0x8a
0x11 0x00 0x42 0x0f 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x01 0x00 0x01 0x10 0x92 0x35 0xea 0xfe 0x7f 0x00 0x00 0xc3 0xa0 0x8a 0x05 0x01
0x01 0x00 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x00 0x83 0x00 0x00 0x00 0x00 0xe0 0x8e 0x35 0xea 0xfe 0x7f 0x00 0x00 0xf8
0x10 0x2c 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x80 0x83 0x00 0x00 0x00 0x00 0xe0 0x8e 0x35 0xea 0xfe 0x7f 0x00 0x00 0xf8
0x10 0xac 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x12 0x88 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
0x12 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x05 0x01 0x01 0x77 0x14 0xf1 0x0b 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x03 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
0x05 0x03 0x01 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
---
0x05 0x00 0x03 0x01 0x10 0x00 0x00 0xff 0x05 0x01 0x21 0x00 0x41 0x0d 0x00 0x02
0x05 0x03 0x01 0x01 0x10 0x00 0x00 0xff 0x05 0x01 0x21 0x00 0x41 0x0d 0x00 0x02
---
0x05 0x00 0x03 0x01 0x12 0x00 0x00 0xff 0x05 0x18 0x21 0x00 0x41 0x0f 0x02 0x00
0x05 0x03 0x01 0x03 0x01 0x83 0x20 0xff 0x05 0x18 0x21 0x00 0x41 0x0f 0xff 0xff
---
0x01 0x00 0x00 0x00 0x8b 0x35 0xea 0xfe 0x7f 0x00 0x00 0xa4 0x97 0x8a 0x05 0x01
0x01 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x03 0x00 0x8b 0x35 0xea 0xfe 0x7f 0x00 0x00 0xa9 0x97 0x8a 0x05 0x01 0x00 0x00
0x03 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Error: unknown target device (DSU_DID = 0x20830103)
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 14, 2021, 04:09:34 pm
This is good. This device is just not on the list. Add the following line to the target_mchp_cm23.c (devices array):
Code: [Select]
  { 0x20830003, "saml11", "SAM L11D16A",  64*1024, true  },

At this point you can also remove the hex printouts, they served their purpose.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 15, 2021, 12:25:58 am
This is good. This device is just not on the list. Add the following line to the target_mchp_cm23.c (devices array):
Code: [Select]
  { 0x20830003, "saml11", "SAM L11D16A",  64*1024, true  },


At this point you can also remove the hex printouts, they served their purpose.
Code: [Select]
$ ./edbg -b -c 1000 -t saml11 -r -f temp.bin
---
0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x30 0x4f 0x90 0xf6 0xae 0x7f 0x00 0x00
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x02 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x03 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0x04 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x04 0x31 0x2e 0x30 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x00 0xf0 0x2e 0x30 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x00 0x01 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Debugger: SushiBits Innovative SushiBits One with CMSIS-DAP 2ACC2DF0 1.0 (S)
Clock frequency: 1.0 MHz
---
0x03 0x10 0xe2 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x5f 0x50 0x90 0x05 0x01 0x00 0x00
0x03 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x02 0x01 0x10 0xe2 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x64 0x50 0x90 0x05 0x01 0x00
0x02 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x04 0x00 0x00 0x80 0x80 0x00 0x10 0xe2 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x75 0x50
0x04 0x00 0x00 0x80 0x80 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x13 0x00 0x10 0xe2 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x7c 0x50 0x90 0x05 0x01 0x00
0x13 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x11 0x40 0x42 0x0f 0x00 0x10 0xe2 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x87 0x50 0x90
0x11 0x00 0x42 0x0f 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x01 0x00 0x01 0x10 0xe2 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x93 0x50 0x90 0x05 0x01
0x01 0x00 0x01 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x00 0x83 0x00 0x00 0x00 0x00 0xe0 0xde 0x2f 0xea 0xfe 0x7f 0x00 0x00 0xf8
0x10 0x2c 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x80 0x83 0x00 0x00 0x00 0x00 0xe0 0xde 0x2f 0xea 0xfe 0x7f 0x00 0x00 0xf8
0x10 0xac 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x12 0x88 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
0x12 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x05 0x01 0x01 0x77 0x14 0xf1 0x0b 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x03 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
0x05 0x03 0x01 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
---
0x05 0x00 0x03 0x01 0x10 0x00 0x00 0xff 0x05 0x01 0x21 0x00 0x41 0x0d 0x00 0x02
0x05 0x03 0x01 0x01 0x10 0x00 0x00 0xff 0x05 0x01 0x21 0x00 0x41 0x0d 0x00 0x02
---
0x05 0x00 0x03 0x01 0x12 0x00 0x00 0xff 0x05 0x18 0x21 0x00 0x41 0x0f 0x02 0x00
0x05 0x03 0x01 0x03 0x01 0x83 0x20 0xff 0x05 0x18 0x21 0x00 0x41 0x0f 0xff 0xff
Target: SAM L11D16A (Rev B)
Reading...---
0x10 0x00 0x83 0x00 0x00 0x00 0x00 0xe0 0xde 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x68
0x10 0x2c 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x10 0x80 0x83 0x00 0x00 0x00 0x00 0xe0 0xde 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x68
0x10 0xac 0x83 0x00 0x00 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x12 0x88 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
0x12 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x9e 0xe7 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x01 0x02 0x83 0x20 0xff 0x05 0x18 0x21 0x00 0x41 0x0f 0xff 0xff 0xff
0x05 0x01 0x01 0x77 0x14 0xf1 0x0b 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x05 0x00 0x03 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
0x05 0x03 0x01 0x00 0x16 0x00 0x00 0x00 0x08 0x00 0x00 0x00 0x00 0x04 0x00 0x0f
---
0x05 0x00 0x03 0x01 0x10 0x00 0x00 0xff 0x05 0x01 0x21 0x00 0x41 0x0d 0x00 0x02
0x05 0x03 0x01 0x01 0x10 0x00 0x00 0xff 0x05 0x01 0x21 0x00 0x41 0x0d 0x00 0x02
---
0x05 0x00 0x03 0x01 0x12 0x00 0x00 0xff 0x05 0x20 0x21 0x00 0x41 0x0d 0xaa 0x47
0x05 0x03 0x01 0x01 0x12 0x00 0x00 0xff 0x05 0x20 0x21 0x00 0x41 0x0d 0xaa 0x47
---
0x05 0x00 0x03 0x01 0x10 0x00 0x00 0xff 0x05 0x02 0x21 0x00 0x41 0x0f 0x47 0x42
0x05 0x03 0x01 0x00 0x20 0x8e 0x18 0xff 0x05 0x02 0x21 0x00 0x41 0x0f 0xff 0xff
---
0x05 0x00 0x03 0x01 0x10 0x00 0x00 0xff 0x05 0x02 0x21 0x00 0x41 0x0f 0xff 0xff
0x05 0x03 0x01 0x00 0x20 0x8e 0x18 0xff 0x05 0x02 0x21 0x00 0x41 0x0f 0xff 0xff
---
0x05 0x00 0x03 0x01 0x12 0x00 0x00 0xff 0x05 0x24 0x21 0x00 0x41 0x0f 0xff 0xff
0x05 0x03 0x01 0x39 0x00 0x00 0xec 0xff 0x05 0x24 0x21 0x00 0x41 0x0f 0xff 0xff
---
0x05 0x00 0x03 0x01 0x10 0x00 0x00 0xff 0x05 0x02 0x21 0x00 0x41 0x0f 0xff 0xff
0x05 0x03 0x01 0x00 0x20 0x0e 0x18 0xff 0x05 0x02 0x21 0x00 0x41 0x0f 0xff 0xff
---
0x05 0x00 0x42 0x01 0x12 0x00 0x00 0xff 0x05 0x00 0x00 0x00 0x00 0x0f 0x0f 0x0f
0x05 0x03 0x04 0x01 0x12 0x00 0x00 0xff 0x05 0x00 0x00 0x00 0x00 0x0f 0x0f 0x0f
---
0x01 0x00 0x00 0x30 0xda 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x74 0x47 0x90 0x05 0x01
0xff 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0x0f 0xff 0xff 0xff
---
0x01 0x00 0x00 0xe0 0xd8 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x81 0x46 0x90 0x05 0x01
0x01 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
---
0x03 0xe0 0xd8 0x2f 0xea 0xfe 0x7f 0x00 0x00 0x86 0x46 0x90 0x05 0x01 0x00 0x00
0x01 0x00 0x00 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
Error: invalid response received
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 15, 2021, 12:46:27 am
I don't understand how that is possible.

0x05 is a transfer command. So it reads the memory successfully for some time.

The last 0x01 and 0x03 are from the check(). [BTW, remove them for now so they don't confuse the output]. And it looks like the answer to 0x03 (Disconnect) is also screwed up.

But the 0x01/0xff pair, which caused the error, I don't understand. It clearly has not read the whole image, so it would not intentionally disable the led. But even if it does, why the response 0xff?

You would need to add verbose("") prints around target_mchp_cm23.c in the reading part to try to narrow down what causes that request.

Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 15, 2021, 12:53:42 am
Ok, I know what is the problem. MAC port is not complete. It has "static int report_size = 512;" hardcoded. For a full speed device you need to change that to 64.

I don't have any apple hardware to maintain that port, so it is half baked. I have no idea how to get proper endpoint size on a mac.

For now there is no way to make this automatic. I refuse to give apple my money, so unless someone contributes the code, it will remain this way.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 15, 2021, 03:09:30 am
Ok, I know what is the problem. MAC port is not complete. It has "static int report_size = 512;" hardcoded. For a full speed device you need to change that to 64.

I don't have any apple hardware to maintain that port, so it is half baked. I have no idea how to get proper endpoint size on a mac.

For now there is no way to make this automatic. I refuse to give apple my money, so unless someone contributes the code, it will remain this way.
Well you can hackintosh. Or use a modified copy of VMware.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 15, 2021, 03:13:41 am
Why would I support a closed and hostile to developers platform while simultaneously pirating their software?  What do I stand to gain? The easiest course of action here for me is to delete mac support entirely. It is there for now because someone contributed it, but as things improve in other parts, it may be left behind.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 15, 2021, 04:49:42 am
Why would I support a closed and hostile to developers platform while simultaneously pirating their software?  What do I stand to gain?
macOS is close and hostile only if you used Apple's high level libraries, most of which requires Objective-C and Swift languages. Otherwise the underlying XNU kernel is a fully open source UNIX distribution.

The easiest course of action here for me is to delete mac support entirely. It is there for now because someone contributed it, but as things improve in other parts, it may be left behind.
From what I see you should be able to test that macOS code under Linux. dbg_mac.c file has zero reference to Apple-specific headers and libhidapi are cross platform.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 15, 2021, 05:14:15 am
I can't push the code that I (or someone else) have not tested. Also, I want to get rid of that stupid libhidapi. I hate that it is there and that it is a dependency. So there is no chance I will do anything with it. If I ever do anything with MAC, I figure out how to access HID stuff directly.

Anyway, for me doing anything with MAC is not worth my time. There is no return there. I mostly maintain that tool for my own personal use. If it happens to be useful for others - great.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 15, 2021, 06:03:36 am
I can't push the code that I (or someone else) have not tested. Also, I want to get rid of that stupid libhidapi. I hate that it is there and that it is a dependency. So there is no chance I will do anything with it. If I ever do anything with MAC, I figure out how to access HID stuff directly.

Anyway, for me doing anything with MAC is not worth my time. There is no return there. I mostly maintain that tool for my own personal use. If it happens to be useful for others - great.
I may take over maintaining that if I have enough spare time for it. I do PCB design and embedded development on a Hackintosh (Windows and Linux just don't agree with my 24-inch 4K monitor.)
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 16, 2021, 08:52:20 am
Migrating to freedap failed for me, so I am sticking to official ARM code (and migrated to their CMSIS-DAP v2 code).

Now it is actually trying to debug something with my own firmware.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 17, 2021, 10:55:25 am
Well I am getting errors from OpenOCD once GDB connects. I am not sure whether it is a SAML11 problem or a firmware problem though.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 17, 2021, 03:47:45 pm
What kind of errors? It very well may be SAM L11. Those TrustZone devices are extremely annoying to work with for no real benefit, IMO.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 17, 2021, 04:09:10 pm
What kind of errors? It very well may be SAM L11. Those TrustZone devices are extremely annoying to work with for no real benefit, IMO.
Somehow OpenOCD thinks it is out of sync and tries to re-establish connection with the MCU, performing multiple JTAG-to-SWD sequences. I'm going to put that board on hold for now until I can get samples for ATSAML10D16 (which is supposed to be pin-compatible with the TrustZone-enabled ATSAML11 parts) and focus on something else for now.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 17, 2021, 04:21:17 pm
L10 is not much better. They both have this annoying BootROM that tools have to interact with instead of normal debug stuff.

If you don't need all those security features, go with SAM D10/D11.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 17, 2021, 04:32:27 pm
L10 is not much better. They both have this annoying BootROM that tools have to interact with instead of normal debug stuff.

If you don't need all those security features, go with SAM D10/D11.
I want a Cortex-M23/M33 core to play with. If it is not L10/L11, I would have to go to STM32L5 or GD32E2/E3.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 17, 2021, 04:38:45 pm
If you want the core specifically, then sure go for it. I'm not sure the device makes a difference. I think it is the core that is annoying. There are too many deviations for the worse from typical Corte-Mx cores, IMO. ARM kind of lost the thread there. I'm guessing marketing took precedence over engineering that time.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 18, 2021, 01:50:17 am
If you want the core specifically, then sure go for it. I'm not sure the device makes a difference. I think it is the core that is annoying. There are too many deviations for the worse from typical Corte-Mx cores, IMO. ARM kind of lost the thread there. I'm guessing marketing took precedence over engineering that time.
For me I just need to know if it is any different to support from a C-only environment with CMSIS and bare minimum device headers. For day to day projects I am still sticking to Cortex-M4 and Cortex-M0 products. (IMO Cortex-M3 r2p0 and above are really Cortex-M4 backports.)

STM32L5 is unobtanium here in China currently, and GD32E3/E3/E5 has terrible peripheral support.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 18, 2021, 02:44:41 am
Non-TZ stuff is virtually the same. Anyone familiar with regular Cortex-Mx devices would find it easy to use.

TZ is nuts. It wrecks all the standard C compatibility that they worked hard to achieve. I guess technically you still code in C, but now they just forced compilers to support their garbage instead of adapting to the existing compilers. This makes the whole thing painful and awkward to use. With no real (non-marketing) benefits.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 18, 2021, 03:43:40 am
TZ is nuts. It wrecks all the standard C compatibility that they worked hard to achieve. I guess technically you still code in C, but now they just forced compilers to support their garbage instead of adapting to the existing compilers. This makes the whole thing painful and awkward to use. With no real (non-marketing) benefits.
Hmm I need more details on this...
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: ataradov on May 18, 2021, 04:09:25 am
Read about "-mcmse" flag and relevant linker flags. With TZ you need to separate your program into secure and non-secure parts. And then half your functions becomes littered with attributes like "__attribute__((cmse_nonsecure_entry))".

Here is a random article that shows a summary of what is going on - https://www.lobaro.com/using-the-armv8-m-trustzone-with-gcc/ (https://www.lobaro.com/using-the-armv8-m-trustzone-with-gcc/)

Here is a sample code from there:
Code: [Select]
// some c file of secure firmware project defining veneer gateway functions
// must compiled with -mcmse gcc flag (!)
#include "arm_cmse.h"
typedef void (*funcptr_ns) (void) __attribute__((cmse_nonsecure_call));
void ControlCriticalIO(funcptr_ns callback_fn) __attribute__((cmse_nonsecure_entry)){
 funcptr_ns cb = callback_fn; // save volatile pointer from non-secure code
 
 // check if given pointer to non-secure memory is actually non-secure as expected
 cb = cmse_check_address_range(cb, sizeof(cb), CMSE_NONSECURE);
 
 if (cb != 0) {
    /* do some critical things e.g. use other secure functions */
    cb(); // invoke non-secure call back function
 }else {
   // do nothing if pointer is incorrect
 }
}

If anyone for a seconds thinks this is "C", they are as nuts as people that engineered that.

And interestingly, STM made an implementation of the same exact thing using external wrapper to the standard core. It is way cleaner and easier to use than this BS. ARM lost the plot here.

And yes, you generally build your program from two completely different binaries - secure and non-secure. Debugging this mess is tricky to put it mildly.
Title: Re: Does anyone have experience debugging CMSIS-DAP firmware itself?
Post by: technix on May 18, 2021, 04:55:49 am
Read about "-mcmse" flag and relevant linker flags. With TZ you need to separate your program into secure and non-secure parts. And then half your functions becomes littered with attributes like "__attribute__((cmse_nonsecure_entry))".

[snip]

If anyone for a seconds thinks this is "C", they are as nuts as people that engineered that.

And interestingly, STM made an implementation of the same exact thing using external wrapper to the standard core. It is way cleaner and easier to use than this BS. ARM lost the plot here.

And yes, you generally build your program from two completely different binaries - secure and non-secure. Debugging this mess is tricky to put it mildly.
Understood. If this is the case I think I will be putting SAML11 on infinite hold until ARM can get their sh!t together.