cortex-m0+ SWD debugging on the cheap

STM32 Discovery Board connected to an LPC812 on a breadboard

STM32 Discovery Board connected to an LPC812 on a breadboard

I’m fairly confident you aren’t likely to find out how to use an STM32F0-Discovery board to upload and debug an LPC812 chip from either the ST or the NXP forum websites. However, if you read this post I will walk you though the steps.

So what is this post all about?  SWD stands for Serial Wire Debugging.  It is a debugging technology built into the arm cortex-m0+ cores. Using just two wires, it allows true hardware debugging of the LPC812 chip.  Hardware debugging lets you step line by line through your program as it executes on the chip. Memory can be examined along with registers and variables in the debugger to help you figure out what is going one when your program isn’t doing exactly what you expected. Setting breakpoints lets you stop at specific lines of code allowing you to wait for a specific condition to be executed.  You can also check for things like stack overflow and memory out of bounds access. Once you get used to hardware debugging, you will wonder how you got along without it.

So let’s step back a bit and review at how one goes about getting a compiled program bits into the flash of an ARM chip.  The LPC812 has a couple of methods. First up is the built-in bootloader. It can take your intel hex files and write them to flash. This is handled over a UART connection, usually with a USB to UART dongle.  Two popular programs that use the bootloader protocol are flashmagic and lpc21isp.  The downside of using a bootloader is that it just loads files, it doesn’t offer any debugging features.

The second method is to use a hardware JTAG debugger. Using a JTAG device, we can both load the flash memory and then debug it.  A popular option for the NXP chips is the NXP LPCXpresso with its LPCLink debug hardware. The downside with the LPCXpresso boards is mainly the price, they are somewhat expensive. However another option is to use the STLink-V2 SWD programmer built in to the STM32 discovery boards which can be had for about $10.  We are cheap so we are going to figure out how to use the STLink-V2 with the openocd software.

Openocd expects you to provide configuration files (ending in .cfg) that describe your debugging interface hardware and the target chip you are using.  I’ve created some openocd configuration files for the stlink-v2 interface working with an nxp lpc812 target chip. When setting up a chip, you describe the flash and ram resources available on the chip and which openocd flash write routines are used.  In this post, I’m not going to go into details of all the configuration settings.  However, you can find the lpc812 with stlink-v2 openocd .cfg files here on my gist:

Clone that repository and copy the .cfg files to the directory your lpc812 source code.  Compile your program and then use the instructions below to load openocd and then gdb to load the code.  I’m testing with a simple blink program.

Here I launch two windows, one running the openocd server and the other running the arm-none-eabi-gdb client that connects to openocd. In the first window we launch openocd and provide the debug812.cfg file:


In the second window, I launch the arm gdb client and connect to the openocd gdb server on localhost using port 3333.  The next step is to load your code into flash using the gdb ‘load’ command. In my case, my program is .bin/template.elf. You should replace that filename with your own lpc812 specific firmware. In the session below you can see me using gdb commands to reset, start running the program, setting breakpoints and then continuing:


Leave a Comment