Does anyone have experience debugging CMSIS-DAP firmware itself?

[technix]

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.

[ataradov]

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.

[technix]

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.

[thinkfat]

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.

[ataradov]

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.

[technix]

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

[ataradov]

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.

[technix]

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.

[ataradov]

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.

[technix]

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?

[technix]

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?

[ataradov]

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.

[technix]

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.

[ataradov]

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.

[technix]

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.

[technix]

So here is what I get:

Code: [Select]

$ ./edbg -lr
Attached debuggers:
  63C8AF92 - SushiBits Innovative SushiBits One with CMSIS-DAP

[ataradov]

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.

[ataradov]

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:

Debugger: Alex Taradov Generic CMSIS-DAP Adapter F4F56A90 v0.5 (SJ)
Clock frequency: 16.0 MHz
ID = 0x10016438
--- done ---

[ataradov]

I've implemented enough of JTAG support to make OpenOCD work:

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:

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.

[technix]

All I got is this:

Code: [Select]

$ ./edbg -b -t samv71 -r -f temp.bin
Error: invalid response received

[technix]

Speaking of software for testing, SEGGER J-Link version 7 can work with CMSIS-DAP. Also there is Keil MDK.

[ataradov]

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.

[thinkfat]

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.

[technix]

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

[Harjit]

In addition to @ataradov's cool project, another couple of projects for SWD debugging:

https://cortexprog.com/
https://github.com/blacksphere/blackmagic