Testing Raspberry Pi's New Debug Probe

As far as professional debuggers...

Those typically have much larger buffers, much larger transfer speed, port voltage threshold can be set higher than 5 V and even under 1 V, data and instruction trace (and often code coverage), the ability to debug multi-core (synchronous or async), recording performance monitor counters, an interface that is easier to use than gdb, built-in workarounds for unconventional attach sequences (and info sharing with manufacturers so the latest chip is supported at or before its unveiling), instruction set simulation, support for virtual targets, task/OS awareness, "unlimited" on-chip/flash breakpoints, add-ons for recording/protocol decoding/triggering based on external signals (aka scope probes), more port options e.g. Aurora, a scripting language and modularity that lets you take debugging expertise from one architecture to an entirely new one e.g. PowerPC to RISC-V, support contracts so that their customers aren't "on their own" when something isn't working with the debugger or target...

There is a huge price disparity, but for the companies with a vision to get their product to mass market with the latest chip IP, it really does not make sense to give them only JTAG wigglers and OpenOCD. If you know your domain is something straightforward from the previous generation of popular Cortex-M, a cheap probe just makes sense. A company on a budget can get away with one professional debugger and a whole collection of slower probes that you can get working with CLion or Eclipse---a bit like having a wood shop full of basic power tools plus one fancy CNC machine.

In software terms, the difference (to me) is a bit like Mathworks vs Octave, AutoDesk/SolidWorks vs FreeCAD/OpenSCAD, Adobe vs GIMP/Inkscape/Darktable. I use the cheap stuff at home, but things are often three-click trivial in the paid software that would take an hour or more to figure out on the low- or no-cost front.

-----

What to look for:

* before anything else, check if you need something that is not found on the onboard debugger, if one exists

* ease-of-use (works with your IDE, loads symbols from your toolchain, easy to manipulate memory/list instructions/watch variables/navigate stack/set complex or conditional breakpoints)

* target voltage

* port data rate

* onboard buffer size, unless your probe can stream data as fast as it reads. (The pro debuggers will use Ethernet or USB 3.0+ but still have between 0.5 and 8 GB, often)

* trace capability (speed, max port width, buffer size, supported protocols), if the chip/port supports it

* supports internal and (if needed) external flash input/output/breakpoints

* if needed, works with multicore (SMP, AMP, heterogeneous AMP)

* data disassembly, instruction set simulation

* lets you do energy profiling or performance monitoring, if important

* advanced hardware techniques, like adjusting the exact timing and voltage of each debug and trace pin independently so you can still trace on a board with less-than-optimal EM design (mismatched trace lengths, weird pin impedances)

* software techniques for speeding up data transfer (computing checksums to skip unneeded flash I/O when a target has this info available)

* existence of (and conformance to) any license restrictions

-----

You'll find the cheapest USB things just use USB 1.2 (1.5 MB/s), 3.3 or 5 volts which is fine for a lot of popular targets, can still read SWO, might be able to read an onboard trace buffer, let you connect via a gdb server to your preferred IDE, can do the basic JTAG/SWD communication. You either get jumpers or the right ribbon cable for your target, which would usually be MIPI-10 or maybe ARM-20 (so you basically need one cable plus an adapter PCB if you plan to debug many different board types and not do extensive tracing)

I don't know enough about the free scene, but I suspect that scripts are what determine whether a Cortex-M is supported in 90 percent of cases. If you need to do a weird JTAG sequence on a second access port, a script will almost always open that door. If you need to hold the clock line high while communicating serially via TDO and TDI? That's a case that might not be supported by a 20 dollar debugger.