In this article, we will examine some of the more popular Cortex-M hardware debug pods (also called debug probes), which are hardware devices necessary for debugging firmware on a Cortex-M based MCU.
Overview of Debugging
In the “good old days”, debugging an embedded system often meant the judicious use of printf to output debugging messages to a terminal. Fortunately, modern MCUs now come with hardware debug support that makes it easy to implement the core debugging features such as instruction breakpoints, and memory access. In the Cortex-M core specification, ARM Inc. includes a Coresight Debug Access Port (DAP) for just such purposes. As the DAP is present in all the Cortex-M base MCUs, this means that they all can provide debug support.
The DAP is accessed through either a JTAG or SWD hardware interface, which defines the signals and protocol used for communication. JTAG is the older protocol, and is also used for other applications besides debugging. SWD (Serial Wire Debug) is a single wire (+ clock) interface solely intended for debugging. For cost and resource considerations, some Cortex-M cores (e.g. M0/M0+) only support SWD.
Debugging, then, requires a software UI program, commonly known as a debugger, that communicates to the Cortex-M MCU DAP through a hardware device known as a debug pod. A debug pod contains hardware that interfaces with the PC (usually via USB) and the target MCU (using either the JTAG or SWD interface). The debug pod firmware implements low level API functions that a software debugger can call in order to implement the debugging functionality.
The debug pod API is usually supplied by the debug pod manufacturers, although ARM Inc. has also defined CMSIS-DAP, a software standard for implementing the host USB interface protocol and the low level API to access the DAP. While CMSIS-DAP sounds good in theory, it has not in practice been widely embraced by the development community.
DAP only provides low-level access to the CPU core. Therefore, a software debugger must have additional information, such as the memory map, instruction set, peripheral I/O register locations, and definitions of the target device to provide a full software debugging experience.
To program the embedded flash in the MCU, it is necessary to use a flash programming algorithm specific to the flash implementation. Proprietary pods usually include their own flash programming algorithms, whereas open source debug pods usually rely on open source projects such as OpenOCD to manage the flash programming.
Segger JLINK Basic
Segger JLINK is the de facto standard debug pod that others compare to. In addition to supporting most if not all known Cortex-M MCUs, it also supports just about any common and some not-so-common flash-based MCUs. It is robust and operates very fast. The vendor, Segger, is proactive in providing updates, and they supply even more capable models (e.g.: models that support trace), at a higher price.
At about $400 per unit, indeed the biggest problem with the JLINK is its high price. It’s also bulky in comparison to other debug pods.
Some silicon manufacturers rebadge JLINK into their own “xLINK” units, possibly crippling some of its capabilities, e.g. by removing support for other vendors’ MCUs. Some development boards include a “JLINK on a chip” that adds minimal cost to the boards, and allows debugging without an external debug pod.
Low-level API is provided through Segger’s JLinkARM.DLL. Optionally, Segger also provides a JLINK GDB Server.
Segger JLINK Edu
The JLINK Edu unit is the same as the regular JLINK except that it can only be used by students. It costs significantly less at around $60 per unit.
Black Magic Probe (BMP)
BMP is an open source JTAG/SWD debug pod. Its unique feature over other pods is that it contains a GDB server in its firmware, making it simpler to set up and use with less chance of misconfiguration. BMP was created through a successful crowdsourcing project.
BMP has flash programming support for a lot (but not all) of the popular Cortex-M MCUs. As the project is open source, the community is adding support for other MCUs regularly. The current list of supported devices is here: https://github.com/blacksphere/blackmagic/wiki/Frequently-Asked-Questions
The official hardware reference design is created by 1 Bit Squared and is considered a “developer” board as it does not come with a case, although a 3D-printed case can be made from a provided file.
At $60, the BMP is a viable alternative to the Segger JLINK if it supports your target device. If your device is not supported, you must use other methods to flash the firmware (e.g. using a bootloader) before you can debug it using BMP.
Wireless Debug Probe (WDBP)
A recent exciting development is the new Wireless Debug Probe (WDBP), basically a BMP with Wi-Fi wireless capabilities. This means one less cable to attach to the PC and less desk clutter – I don’t know about you, but I have an 8-port USB expander, and I still find myself running out of ports! WDBP retains the full features of the BMP, and thus can also be used with a USB cable instead of Wi-Fi. The WDBP may be powered from the target under test, or from a Lipo battery, or through the USB to the PC.
The WDBP is currently under development by Sid Price. The prototype is already finished, and Sid is looking to crowdsource the project soon. Contact email@example.com for information.
STM Electronics makes the ST-LINK debug pod, which only works with their STM32 series of Cortex-M MCUs. It supports all STM32 devices, has reasonable speeds, and is a lot more compact than the JLINK. Best of all, it is priced very reasonably at under $25. It only supports the SWD interface (not JTAG), but that’s not an issue with the STM32 devices.
STM also includes an embedded ST-LINK in their ST-Nucleo and Discovery development boards. At as little as $13 a board (that is, it includes a development board with Arduino compatible headers AND an embedded ST-LINK), with versions for all major variations of the STM32 devices, the ST-Nucleo and Discovery are my current favorite prototyping platforms.
You can even use the embedded ST-LINK on an ST-Nucleo as a stand-alone ST-LINK debug pod to debug other STM32 based boards. Effectively, this way you are getting an ST-LINK for as little as $13.
Low-level API access is provided through ST’s API library, or through ST’s GDB server.
If you are adventurous, there are at least two ways to modify an embedded ST-LINK to work with non-ST devices (quick note: these options do not seem to work with the stand-alone ST-LINK debug pods). Both require minor but reversible hardware modifications to the embedded ST-LINK. The first is by using a JLINK firmware image provided by Segger which turns the embedded ST-LINK into a JLINK-compatible pod. The modified firmware will “nag” you in some fashion when you use the pod (after all, you ARE getting a JLINK equivalent pod for $13). Second, you can also download a Black Magic Probe-provided firmware image onto an embedded ST-LINK which turns it into a BMP-compatible unit. As BMP is an open source project, this functions fully as a BMP pod with no nagging.
CMSIS-DAP Debug Pod
I have used all of the above pods extensively, and can handily recommend any of them. However, despite initial promises, there do not seem to be many CMSIS-DAP based debug pods available, and I have not tried any. For completeness of this article, I checked, and so please note that Adafruit carries at least one CMSIS-DAP debug pod.
At $30, the price is right, but configure it correctly maybe more involved, as it relies on OpenOCD for flash programming, which is an “evolving” open source project that is somewhat difficult to set up. If you have any experience with this pod, please feel free to comment on this post.
It is no secret that one can purchase cheap clones of most of the above at AliExpress or similar sites. Besides violating copyright, these clones are often badly made. I purchased a ST-LINK clone simply for the purposes of testing, and while it was very inexpensive ($8 or so), it did not work for me. Although a few other people have reported somewhat better experiences, I would call these “not recommended at all”.
For STM32-based designs, especially when prototyping with the ST-Nucleo with the built-in ST-LINK, the ST-LINK is an obvious choice. Otherwise, I recommend the BMP and WDBP for their built-in GDB server and reasonable prices. If $60 is too much money, then you can even turn an embedded ST-LINK into a BMP for just $13. The Segger JLINK is solid, but at many times the price of the BMP, it’s not a choice that can be made easily, unless one qualifies for the JLINK Edu version.
JumpStart C++ for Cortex Integration
With the exception of CMSIS-DAP debug pods, all of the above-mentioned pods are supported by ImageCraft’s JumpStart C++ for Cortex development tools