Which SWD debugger is you favorite?

[sequoia]

I have been using PicoProbe (turning one Raspberry Pi Pico to USB to SWD adapter) to develop software for Pico (RP2040).
It seems to work fine, but wiring can be a mess...


Seems like there are quite a few options for SWD debugger/programmer.  I'd be interested in knowing what others are using and why....


Looks like there are free PCB designs for making a "standalone" PicoProbe, which seem potentially a good option:

https://github.com/Fabien-Chouteau/picoprobe-pcb
https://github.com/tjko/tiny-picoprobe

[ataradov]

I'm using my own - https://github.com/ataradov/free-dap . You can see pictures of the ones I use here https://www.tindie.com/products/ataradov/cmsis-dap-compliant-swd-debugger/ I don't recommend you buy it from me if you have ability to make your own.

They are tiny and just work as an extension of a USB cable. It is very convenient and so much better than having bulky hardware that gets in a way. They are also very cheap, so I often leave the debugger connected to the target and just disconnect the USB cable when switching between the projects.

It is also just a standard CMSIS-DAP, which works with a ton of tools, not just OpenOCD.

[DiTBho]

I haven't yet found anything that works with MIPS ejtag and POWERPC 4xx jtag

[newbrain]

I have been using PicoProbe (turning one Raspberry Pi Pico to USB to SWD adapter) to develop software for Pico (RP2040).
It seems to work fine, but wiring can be a mess...

I have contributed a little to picoprobe and added support for it to pyocd.

Picoprobe is a very, very, basic probe: it has exactly zero intelligence, and it's just a bit banged SWD interface over USB.
The debug server and PP driver needs to build the bit sequences and transfer them through USB instead of issuing higher level commands such as reading or writing an AP.

This has some advantage in flexibility, e.g. to support the brain dead way DPs (yes, plural ) are implemented in the RP2040, at the cost of a very slow speed because to fully respect the SWD protocol several back and forth are needed for acknowledge bits.

While it might be useful, I tend to use either CMSIS-DAP probes (I'll try ataradov's pico based one, thanks!), or, more often, a J-Link EDU Mini (no commercial use - but I'm here for fun so that's OK).

[ataradov]

CMSIS-DAP does not do anything special either. It is also just a gateway to perform SWD transfers over USB. CMSIS-DAP is reasonably well designed though. It allows for multiple SWD transfers in the same request, masked polling for some bits, multiple pending requests. I have not looked at the picoprobe, no idea how it is different from CMSIS-DAP.

CMSIS-DAP is not perfect, but it is not bad and has the advantage of being a true standard.

[SiliconWizard]

The downside of CMSIS-DAP when implemented using USB HID FS is that it's pretty "slow". You can get higher throughput using HID HS though, but I don't think the probe you have on Tindie is HS?

[ataradov]

No, it is not HS. HS capable MCUs are somewhat expensive (~$5 the cheapest one I could find) and they also require a lot of support components, so overall board size and cost are high.

But CMSIS-DAP v2 uses bulk endpoints (in addition to HID), and I'm slowly preparing to implement that in the firmware. But support for v2 is still spotty, especially in the commercial tools. As far as I know both pyOCD and OpenOCD support it.

MCU Link is a good cheap (same price s mine essentially) debugger that does HS. The official firmware is v1 though, and I'm not sure if v2 firmware even exists. But with HS it is fast enough with HID.

The downside of v2 and raw endpoints is annoyance with Win drivers. It is not as bad with Win 8 and up, but still makes you add all sorts of proprietary garbage into the USB stack.

CMSIS-DAP v2 on USB FS with proper host software (which does not really exists) is fast enough, and I'll be focusing on that. I personally value small board size and simplicity over ultimate speed.

[cgroen]

For me its Segger's J-Trace. Lightning fast (USB-3 and Ethernet).
Also gives me ETM on various processors (1, 2 or 4 bit data)

[newbrain]

It allows for multiple SWD transfers in the same request, masked polling for some bits, multiple pending requests. I have not looked at the picoprobe, no idea how it is different from CMSIS-DAP.

CMSIS DAP commands are much higher level than the PP ones, as you say, the DAP_Transfer command can read or write a number of registers in APs and DPs, the interface can be configured with the number of retries etc. etc.
The pico probe command set is:
- Write the following n bits to SWD.
- Read n bits.
- Set SWD frequency to f.
  Don't push it, though, signal integrity is meh, and the DS for RP2040 does not even tell us what the expected rise and fall times are.

There is no notion in the probe of APs, DPs, and registers.
As said: the debug server/driver just bitbangs the SWD using USB as a transport.

A single write transaction command (with USB direction):

• Write the command word (OUT)
• Read 5 bits: 1 turnaround, ACK, 1 turnaround (OUT)
• Wait to receive the 5 bits (IN)
• If ACK was OK, Write 32 bits data + 1 bit parity (OUT)
• If ACK was not OK, handle the fault

Slow, as the host needs to wait for the ACK bits before sending the data*.
And if it gets confused it will hang indefinitely.

* I cheat in pyocd, and just assume unicorns and rainbows. I provided an option to be a good boy, but it's painfully slow.

[ataradov]

Oh yes, this is going to be slow. I guess it works in the whole RP2040 approach. It sort of demonstrates how to do things in a simple and somewhat naive, but workable way.

[ataradov]

A: CMSIS-DAP has no applicability to acquisition of tracing data on ARM-M?
B: CMSIS-DAP has no applicability to acquisition of SWO data on ARM-M?

There is a protocol support (optional) for getting SWO trace.

ETM is far too fast for that. Typically you can use CMSIS-DAP for regular debug, but carry ETM data in whatever way works. There is no standard for this.

C: CMSIS-DAP has no extension such that it can be made workable over anything OTHER than USB?  e.g. no tunnel mode over USB-ethernet or non-USB interfaces etc.?

There is nothing standard. The protocol itself is agnostic, you send the buffer, the library gives you a buffer to send back. For now the only two standard ways to do this are USB HID or USB raw bulk endpoints.  And standard tools only support USB, of course.

[josip]

For me having fast UART bridge (4 Mbps) for log included together with voltage translator on connection to target is must, so I am using best-buy in this category, 10$ MCU-Link. It is CMSIS-DAP probe that is working fine with OpenOCD.

[kevinateev]

The good ol' j-link works just fine with PICO/RP2040.

https://github.com/kpishere/pico_experiments

[Sal Ammoniac]

My favorite is the Segger J-Link. I have several of these and they just work.