Faster CMSIS DAP compatable boards?

[tmadness]

I've been on the search for a good low cost generic debug probe for a while now. And through trial and error I've come to really like the CMSIS DAP + pyOCD combo.
I've used a number of CMSIS DAP compatible probes like the NXP MCU Link, seeeduino xiao  etc.
Does anyone know of other good quality + higher speed DAPs?
 

[SiliconWizard]

I just received 2 nanodap-hs probes. Contrary to most cheap CMSIS DAP probes out there, they support USB HS. They are much faster.
(Can be found from MuseLab on Aliexpress.)

[ataradov]

From readily and widely available devices LPC-Link2 with CMSIS-DAP firmware is the fastest from all I tried. It is the only debugger I have that uses 1024 byte endpoints.

But yes, generally you get enough of a performance boost by switching from FS to HS, that details of the HS implementation almost do not matter. So look for USB HS devices and ignore everything that is FS. There is no reason to compare FS devices between themselves, they all will be slow.

[tmadness]

interesting  they the use ATSAM3U2C, I bought a couple, but I'm not looking forward to shipping...
LPC-Link2 uses DAP I i think, I did not realize that it may have been the fastest, makes sense though it is a dual core MCU running at 150 MHz. Mine just quit on me one day. It's probably from all the mishandling with no container to protect it   .
I just remember that the NXP MCU link at weird quirk, it would randomly reset the target every ~20 min if left idle but connected. It caused some deep consternation and frustration as I tried to debug the issue thinking it was something to do with the code I had written.
 

[SiliconWizard]

The LPC-Link2 is cheap and works well? Drawback with the nanodap-hs probes is that they only support 3.3V. No level shifting of any kind as far as I've seen. Not sure about the LPC-Link2 for this?

[ataradov]

LPC-Link2 has level shifters.

It also has 20-pin trace connector with trace pins actually going to the MCU. I'm not sure how well that works though, I suspect not well at all, given that trace is hit or miss even on dedicated trace probes.

[josip]

BTW, NXP MCU-Link (10$) is based on LPC55S69, dual core Cortex-M33 150 MHz with HS USB and level shifters.

[tmadness]

The Link2 has the LPC4370 3 cores: 1X M4, 2X M0 @ 205 MHz .
As ataradov said it has level shifters on board.
The LPC4370  is actually a really cool part, but they had to handicap it by giving 1 SPI
As far as DAP is concerned I would not be surprised if they are running on only 1 core 

[ataradov]

DAP does not need the performance, so yes, I would not expect multi-core stuff to matter.

USB HS is the critical part. FS limits the speed at 64 KByte/sec and really bad turnaround time.

[SiliconWizard]

DAP does not need the performance, so yes, I would not expect multi-core stuff to matter.

USB HS is the critical part. FS limits the speed at 64 KByte/sec and really bad turnaround time.

Yes of course. Since it's HID, yes it tops at 64 KBytes/s in FS. I don't remember in HS if there's a lower limit for HID or if you can get the full throughput, but either way, it's much faster.

And of course, you don't need a powerful MCU to handle DAP. You just need one that can be clocked fast enough so that the serial clock will be high enough.
As a quick calculation, if it uses SPI or similar for the JTAG/SWD interface, you may typically need a peripheral clocked at a multiple of the max serial rate (2, or 4 times is typical), so, for a 30MHz link, for instance, you'll need a peripheral clock of 60MHz or 120MHz. Depending on the architecture, the core clock will be required to be at least this fast as well. So, a MCU running at > 100MHz actually makes sense for a fast DAP link. Multiple cores, OTOH, are likely completely useless. Anyway, CMSIS-DAP implementation is open and usually what is used on those boards, and I don't think it supports multi-core anyway.

The Link2 probably uses this particular chip because they use it on some other dev boards as well.

[mubes]

Folks,

At the risk of necroposting you might be interested to look at https://orbcode.org/. It's a fully open source high speed debug and parallel trace interface. In the interests of full disclosure I need to declare that it's my baby, but the idea behind it is to get TRACE as prevalent as SWD and JTAG on board debuggers already are....and that needs people to help expand the ecosystem.

It will read at about 1.5MBytes/sec and supports multidrop on both SWD and JTAG interfaces. There's headroom for it to get faster. The CMSIS-DAP is implemented completely in gateware. There's a soft RISC-V in there, but it's not in use at the moment. It's a project, not a product..which sort of means it's not finished, but given the potential for different applications of this thing, I'm not sure it ever will be.

Regards
DAVE

[Doctorandus_P]

When I read the title after mubes bumped it, my first thought was the black magic probe, or  something compatible with it.
I briefly looked at the orbcode project but I'm not into FPGA's myself, but I did see the black magic probe mentioned there too.
I think (some variant of) black magic probe can be flashed into ST-Link V2 (or clone) and it may be worth a try.

[mubes]

BMP is a great piece of hardware, and relatively fast, based on a STM32F103. It speaks 'native' gdb protocol and is probably the least painful solution for CORTEX-M debug _if_ the chip you want to use is supported, and you don't need parallel TRACE. ORBTrace originates in that community...its gestation was adding SWO to BMP (which created Orbuculum), then figuring that high speed access would be desirable and re-engineering the whole thing for parallel TRACE and very high speed....which is where we are with this new device.

BMPA is the 'application' version of BMP (as opposed to the on-chip version) which interfaces with a number of existing pieces of debug hardware including ST-Link v2 and v3, J-Link and ORBTrace, in a similar way to which PyOCD and OpenOCD work. It's a very nice and low pain way to see if BMP works for you before committing to new hardware. The 'configuration hill' for BMP and BMPA is considerably lower than for any of the other approaches.

BMP has a new maintenance team in place as of a couple of months ago, and improvements are coming thick and fast now. It's certainly worth a look.

(You don't need to be an FPGA expert to use ORBTrace BTW, but it would certainly help if you wanted to extend it)

DAVE

[mubes]

Final post on this and then I'll go back under my rock. We did some testing of ORBTrace with various debug interface drivers (pyOCD, blackmagic-app and openocd) and compared them to blackmagic_native. Graph is attached. Note that reading can be faster if your interface driver caches (with corresponding risk of inconsistency) and writing to flash is limited by the speed of your flash technology (~40KBytes/sec for STM32F4 class chips). Creating this graph has uncovered a timing issue in blackmagic_native that we need to dig into, so expect that to get faster soon.

DAVE

[gmb42]

To be clear on the graphs, higher is better?

[mubes]

Yes, that's KBytes/sec of transfer...so higher is better.

Would be intrigued to know what a LPCLink2 board does. I suspect that is quite shifty. Command line to test is something like;

Code: [Select]

time ~/bin/gcc-arm-none-eabi-10-2020-q4-major/bin/arm-none-eabi-gdb --batch-silent -ex "target extended-remote localhost:3333" -ex "dump binary memory file.out 0x08000000 0x08100000" -ex "detach" -ex "quit"
...obviously that's a bit probe-specific.

Regards

DAVE