Source Level Hardware Debugging for STM32 Projects - RC Groups
Shop our Airplanes Products Drone Products Sales
Thread Tools
Nov 05, 2016, 06:05 PM
Registered User
MGeo's Avatar

Source Level Hardware Debugging for STM32 Projects

This thread is meant to capture how-to information on hardware debugging of STM32 based ARM projects.


Way back in the 80s (dating myself) I got myself into programming on DOS based PCs. I started off with the GW-BASIC that came with DOS, writing simple utilities to help me automate some of the more tedious work tasks at work. I'm a mechanical engineer by background, life was full of spring stress calculations, simulations, etc. These little utility programs were simple. Debugging meant lots of print statements buried in the code, iterating until things eventually worked properly. I got things done, life was good.

Then someone at work introduced QuickBASIC. QuickBASIC was one of the early IDEs built on top of the instant gratification interpreted BASIC language. It felt like a giant leap forward as my projects were getting more complex. There was a proper integrated debugger with breakpoints, watch variables and more. Multiple modules and libraries. I quickly understood the value of proper debugging tools. Life got better.

Eventually my interest and work moved to embedded systems. At work live and breath motion control. Embedded software is part of life. I decided BASIC wasn't going to work out. I moved over to C. First on on 8 bit AVRs to learn . Eventually Arduino came on the scene making experimentation and sharing cheap, quick and easy. But I was stuck in the 'print statement' debug penalty box with the Arduino IDE

As Arduino started its migration to 32 bits I decided something better had to be out there. These new to me little ARM processors had way more oomph than that early 8 bit 8088 powering my first IBM XT, but I was still using @#$&% print statements for debugging. Enough...

Flash Forward to Today

8 bit AVRs and Arduino are great platforms for learning. I think a big part of their success were the open source C based tools that were readily available. But the hardware debugging features were lacking. What was available was proprietary.

Then along comes ARM and ST with their low cost STM32 family. STM32 32 bit ARM family is incredibly powerful and cost effective. The power of these processors leads to wonderfully capable and complex projects such as PX4 and Cleanflight flight controller projects that have changed the hobby. And most important here they support JTAG/SWD/SWO hardware based debugging. Proper hardware debugging enters the scene.

And, hardware debug tools become available. First come expensive proprietary solutions. The comes low cost education oriented variants and now the never ending open source march has made very low cost options available. Open source and free debug software IDE tools are now available on multiple platforms (Windows, Linux, Mac).

With all this now readily available, time to start putting it to use. I'm going to explore these tools here below, and try putting them to use on some hobby projects. I captured some of the steps in this thread here, but the focus there was on a specific hardware project, and I've since learned some new things so a new thread seems appropriate.

I'm going to capture the steps here as I go to remember them, and to make them available to others if they choose to duplicate them.
Last edited by MGeo; Dec 01, 2016 at 05:03 AM.
Sign up now
to remove ads between posts
Nov 05, 2016, 06:06 PM
Registered User
MGeo's Avatar

Windows, Linux, Mac?

Ok, truth be known since that early experience in the late 80s I've been a bit of a computer geek. And I've dragged by family along with me. At home we have a collection of Win desktop and laptop PCs, 3 Linux laptops, a Macbook, a Hackintosh desktop, as well assorted iPads and iPhones. At work we are Win exclusive so I gravitate toward Windows but have a solid appreciation for Linux. For the home PCs, I updated them all to Win 10 over the past year when the upgrades were free. Good call on Microsoft's part, I would not have updated them if I had to pay for it.

Babies learn by imitating there caregivers. I think of imitation as a fundamental means of learning and taking first steps. For learning to code, the internet and Github have given us a wonderful resource for e-learning. For learning open-source projects, I've found it easiest to stick to the platform and toolchain as used by the original project devs. For the most part this has been either Win or Linux. So I bounce back and forth between the two, continuing to work on my command line Linux-fu. Makefiles still a bit of a mystery to me. Some day soon...

Some of the vendor tools only run on Windows (ST's tools), or have better support for one platform over the other (Segger's tools). So Windows development platform is a requirement for me. But many of the open source projects are Linux first. What to do. I guess I could install a VM box and load up Ubuntu.

But there is now another option evolving (still considered beta at this point). In just the past few months Microsoft has done something that seem a bit remarkable for them, they have released something called “Windows Subsystem for Linux” in collaboration with Canonical. WSL for short. It is a full Ubuntu 14.04 implementation mapped into Win 10 kernel calls. My guess is MS must have realized it was losing the younger Github dev generation to Linux and figured if you can't beat them, join them. Who knows, but if it helps my cause I'm willing to give it a try.

The file systems between the two are not identical so it has some weird restrictions on file sharing between the two systems (careful if you try to edit a file created in one file system in the other file system). Also USB access is not there, so flashing using USB tools will not work from the WSL file system side. But things like apt-get, git and make work just fine. I'm able to build makefile based Linux Github projects just fine (as best I can tell so far).

So for at least some of the trials below I've elected to give “Windows Subsystem for Linux” a try. I followed instructions here for installation. My Win laptop can now bounce back and forth from Win tools to Linux based tools without switching machines. I've used virtual machines in the past on both Linux and Win platforms, this seems easier and less resource intensive. We shall see. At any rate I plan to continue to work multiple platforms going forward. Linux is still the heart and sole of the open source world, and Windows will dominate on the work desktop for some time to come.
Last edited by MGeo; Nov 06, 2016 at 07:38 AM.
Nov 05, 2016, 06:07 PM
Registered User
MGeo's Avatar

Hardware Debug Probes, Low Cost Options

These various debug probes can be used for flashing and debugging STM32 hardware, some also have an auxiliary USB-UART port for serial console as well.

1.) Debug Protocols and Interfaces

There are two different relevant interfaces for flashing and debugging for STM32:
Note: Some STM32 MCUs can also be flashed via Serial and or USB DFU! But ony SWD and JTAG provide hardware debugging capabilities.

ARM Serial Wire Debug (SWD) is a program and debug protocol for ARM processors. It's a low pin count and high-performance alternative to JTAG.

JTAG is an industry standard on-chip debugging protocol. It can be used for one or more chips (daisy chained), for interfacing with the chip as well as flashing software.

IDE Interfaces
OpenOCD: This is a piece of software that can be used for interfacing with many of the hardware debug probes, and serve as a bridge for them with the Eclipse IDE (ST Link in particular). Segger makes a number of tools for J-Link available for free on their website

Black Magic Probe (BMP): One of the first debuggers to support SWD was a thing called Black Magic Probe. It has both custom open STM32 based hardware and an open source firmware component.

One of its best feature is that it presents itself as a serial device that talks the GDB Remote Serial Protocol device. This means you don't need OpenOCD or the texanne stlink stuff to talk to it. Even better is that it is just a CDC_ACM device so you don't need special OS drivers to interface to it. It shows up as a COMx on Windows or a /dev/ttyACMx on Linux. Using arm-none-eabi-gdb -ex 'target remote /dev/ttyACM0" blink.elf and you can load and debug your STM32 programs. This also makes it easier to have a consistent debugger / programmer interface across different OS platforms. Finally it is not propriety and therefore tied only to STM32. Once you climb the learning curve you are free to move across the various ARM manufacturer platforms beyond ST. More about it here:

2.) Hardware Options

Clone 1

J-Link EDU

Black Magic Probe
Last edited by MGeo; Nov 06, 2016 at 07:17 AM.
Nov 05, 2016, 06:53 PM
Registered User
MGeo's Avatar

Making use of integrated on-board NUCLEO harware debugger

ST NUCLEO boards ( all come with a new and improved on-board V2.1 ST Link flasher/debugger.

You are not limited to the on-board processor as a debug target, you can use the integrated NUCLEO debugger to debug off-board targets as well You can use the ST Windows based tools like ST Link to flash those targets. You can use OpenOCD to interface to Eclipse IDE to debug your software running on those targets.

And...Segger has gone and done something remarkable, they have made J-Link available as an install for the Nucleo boards You can convert your NUCLEO ST-LINK on-board into a J-Link on-board. And if you decide you don't like it, you can reverse it and go back to ST-Link. Being Segger it does have a list of un-user friendly licensing restrictions written by lawyers ("In order to make use of this firmware, the following Terms Of Use must be accepted"). But still very cool and quite useful.

In my preliminary tests, the Segger software tools like Ozone debugger appear to run very well on Windows, and fairly well on Linux (I had to upgrade to Ubuntu 16.04, it gave shared library errors on 14.04 and would not run). As compiled native binaries, I am finding Ozone faster and more responsive than Java based Eclipse IDE when doing things like stepping through code.

So looking across options for a source level hardware debug workflow, you could:
  • Use your favorite text editor as IDE (Sublime Text, or maybe Atom), together with Segger Ozone for flashing and source level hardware debugging with J-Link.
  • You could use Eclipse as IDE, using the Arm Eclipse Segger J-Link debug plug-in to set up source level hardware debugging on J-Link.
  • You could use Eclipse as IDE, using the Arm Eclipse OpenOCD debug plug-in to set up source level hardware debugging on ST-Link.
  • You could use Eclipse as IDE, using the GDB debug plug-in to set up source level hardware debugging using a BMP interface.
  • You could go bare bones and use a command line interface to BMP for source level hardware debugging.

So many options. I'm sure there are more. I will try some of them out here below.
Last edited by MGeo; Nov 06, 2016 at 08:09 AM.
Nov 05, 2016, 11:22 PM
Registered User
MGeo's Avatar

Build Environment Install on Windows

I am installing Eclipse IDE, the ARM Eclipse plug-ins, and the ARM GCC toolchain. There are thorough installation details covered here, I've outlined them here below:

Make sure you have Java installed on your machine before you get started with Eclipse. Eclipse is based on Java. Be aware that there are 32 bit and 64 bit versions of Java. My Win 10 install is 64 bit, as is my Java install. Watch out for the slimy Oracle installer for Java, which will slip yahoo as your default browser search engine if you do not un-check the check box during install (, no respect for Oracle on that one).

Install the Eclipse IDE version for C/C++ developers using the Eclipse Windows installer for your system (32 or 64 bit). The latest version is Neon, I'm sticking with Mars 2 for now Be sure to use the "Eclipse IDE for C/C++ Developers" package.

I've created a folder in my root directory C:\STM32Toolchain. and a projects folder within C:\STM32Toolchain to get C:\STM32Toolchain\projects. I then have selected this as my default workspace folder when I started Eclipse for the first time.

Eclipse CDT Plug-In
An Eclipse plug-in is a software module that extends Eclipse. Eclipse has a built in mechanism to manage plug-in installation. Install the C/C++ Development Tools SDK, aka Eclipse CDT. To install CDT go to Help->Install new software and activate the CDT checkbox. Once CDT is made visible, you can select it and install the plug-in.

GNU ARM plug-ins for Eclipse
This plug-in adds features to Eclipse CDT to interface and integrate a GCC ARM tool-chain. Also included are the key plug-ins to integrate OpenOCD, Segger J-Link and GDB debuggers into Eclipse. Follow the instructions found here

Install GCC Toolchain
From here, following the instructions here

Build tools for Windows
Using Windows means you have to bring your own build tools and worry about properly integrating them into Eclipse so they can be found properly. I initially tried Cygwin and it worked well. But I've also tried these instructions and find that they also work well, and are simpler:

OpenOCD or Segger debug
Depending on your debugger / loader hardware, install OpenOCD or Segger per

Eclipse ARM Packs Manager
You can install the Pack Manager package for the ST Microelectronics (I've installed the F0, F1, F3 and F4 packs for the other boards I've been working with) by following instructions here

With all the above installed, we should be ready to go try our hand at source level hardware debugging.
Last edited by MGeo; Nov 06, 2016 at 09:01 AM.
Nov 05, 2016, 11:25 PM
Registered User
MGeo's Avatar

Building a Linux Makefile Project in WSL on Win 10

I need a target project and hardware to test out the source level hardware debugging. In this example I am going to use fishpepper's awesome and very well documented OpenGround project here, here and here

I first have to start with opening a WSL Bash window, and installing the essential tools for a project.

Install latest up to date gcc-arm-embedded, git, build essentials:
sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa
sudo apt-get update
sudo apt-get install gcc-arm-embedded
sudo apt-get install git
sudo apt-get install build-essential
Create a working folder (I'm using 'src').
Use Git to fetch the OpenGround project from GitHub.
I will start with the part1_led_toggle example from here
mkdir src
cd src
git clone
cd OpenGround
git checkout part1_led_toggle
Last edited by MGeo; Nov 06, 2016 at 07:20 PM.
Nov 06, 2016, 07:39 AM
Registered User
MGeo's Avatar

Flash and Debug with J-Link and Ozone on Win 10

Next, I connected my J-Link probe to my FS-i6s.

I connected the J Link probe as follows:
violet = SWDIO --> J Link pin 4
grey = SWDCLK --> J Link pin 3
blk = GND --> J Link pin 2

Open up Ozone and load the openground.elf file that was created above in post #6.

There is some file weirdness with the WSL build. Ozone gets an incorrect path to the source files as we built the .elf file on the WSL side, but are accessing the files in Ozone on the Win file system side. I had to open the files manually in the 'Source Files' window within Ozone. But that works as expected. A little digging in the Ozone manual revealed that you can modify a project's root directory in an Ozone .cdebug project config file to get everything to line up properly. So I had to add a line like so:
void OnProjectLoad (void) {

  Project.SetDevice ("STM32F072VB");
  Project.SetHostIF ("USB", "");
  Project.SetTargetIF ("SWD");
  Project.SetTIFSpeed ("1 MHz");
  Project.AddSvdFile ("Cortex-M0.svd");
  File.Open ("C:/Users/geosm/AppData/Local/lxss/home/geo/src/OpenGround/openground.elf");

Stepping through the code with F10 initializes the target and toggles the backlight LED on and off as expected!

From this experiment I consider WSL command line compile, combined with J-Link and Ozone on windows to be a valid solution. I suspect this work well on my Linux 16.04 laptop running Ozone as well, but I have not tested that configuration as of yet.
Last edited by MGeo; Nov 12, 2016 at 07:31 AM.
Nov 06, 2016, 09:04 AM
Registered User
MGeo's Avatar

Building a Linux Makefile Project on Linux Ubuntu 16.04

For Linux I have followed the ARM Eclipse directions for installing arm-no-eabi-gcc (in /usr/local) found here

The advantage is that I can control what version of gcc I am using (4_9-2015q3 in this case), and can install multiple versions on one machine, switching back and forth as needed. The disadvantage is that the toolchain is not in my default PATH.

In Linux we can add gcc to PATH by adding the following line to .profile, a hidden file in home directory:
export PATH=/usr/local/gcc-arm-none-eabi-4_9-2015q3/bin:/opt/gnuarmeclipse/openocd/0.10.0-201601101000-dev/bin:$PATH
The example project I am working with here assumes a toolchain installation location of /usr/bin by default (the relevant lines are located in Makefile.board).

You can override the default assumption by passing the TOOLROOT path at the make command line. For my install this looks like the following:
make TOOLROOT=/usr/local/gcc-arm-none-eabi-4_9-2015q3/bin
With this the code builds correctly, generating the openground.elf file we need for source debugging (see pic).
Last edited by MGeo; Nov 23, 2016 at 05:49 PM.
Nov 06, 2016, 09:14 AM
Registered User
MGeo's Avatar

Flash and Debug with J-Link and Ozone on Linux Ubuntu 16.04

Same connection to my FS-i6s via J-Link as used in Win 10 post #7 above.

I had trouble getting Ozone to work on my Linux standard Ubuntu 14.04, it complained about shared library version issues. I upgraded my laptop (old reliable Dell D630 upgraded to 6GB ram, 250GB SDD) to Ubuntu 16.04. Seems to work well and Ozone ran without complaint.

I powered up the i6s, plugged in J-Link and ran Ozone for the command line,

Single stepping through the code works well, Ozone is responsive. There is no extra work to do with Ozone project file as there was on Win 10 above, just load and go.

Nice. Score one for Linux here for a project set up for native Linux makefile build.

I have to admit, I am becoming a Segger fan. I feel pretty good about my $60 purchase of my J-Link-EDU for hobby use. J-Link OB on the $10 Nucleo boards is very nice as well. Thumbs up to Segger.
Last edited by MGeo; Nov 12, 2016 at 10:02 PM.
Nov 06, 2016, 10:35 AM
Registered User
MGeo's Avatar

Building a Makefile Project in Eclipse

Above I compiled a Linux Makefile (fishpepper's OpenGround) based project using Win 10's Bash on Ubuntu on Windows service. It works pretty much like familiar Ubuntu command line, but the file system it uses is separated from the native Windows NTFS file system and there is no graphical file manager in the Ubuntu side. You can see and access the Ubuntu file system within Windows File Manager, but moving files back and forth creates some weird side effects that then need work-around.

So I though it would be a good experiment to attempt to build the project under Eclipse (Mars.2) on Windows 10.
  • Use git to git clone the OpenGround project. I cloned mine into C:\src\OpenGround.
  • Fire up Eclipse and Import the project (File->Import->Existing Code and Makefile Project.
  • Right click on the project in Project Explorer, and select Properties->C/C++ Build
  • In the Builder Settings tab, deselect "Use default build command" and enter "make" in "Build command" text box
  • Under "Behavior" tab, Change "Build (incremental build)" from the default "all" to short filename version where my toolchain bin folder is located, overriding the default TOOLROOT. In my case this was "TOOLROOT=C:/PROGRA~2/GNUTOO~1/4195F~1.920/bin"

Now build the project by selecting "Project->Build Project". If everything was set up correctly, you are rewarded with an openground.elf file, you can find it over on the left side in the "Project Explorer" window.

Now fire up Ozone and load openground.elf, make sure to load STM32F072x.svd as peripheral file if you wish to interrogate the peripheral registers. Power up the target (i6s transmitter), plug in J-Link and F5 to connect. And everything just works! You can now start single stepping through the code in Ozone.
Last edited by MGeo; Nov 13, 2016 at 08:21 PM.
Nov 06, 2016, 08:56 PM
Registered User
MGeo's Avatar

Simpler Demo Project on STM32F103 mini dev board

I'm thinking it would be a good idea to have a smaller, simpler and cheaper demo project and target to use for climbing the STM32 programming and debug learning curve.

I've come across this minimal example project, which I will adapt to run on my $2.44 Ebay STM32F103 mini development board (aka blue pill, here

Makefile build on Linux, Ozone debug

Back to Linux for easy Makefile build. I modified main.c to toggle PC13 on the mini dev board. I've attached a zip of the files here. I've loaded the resulting .elf file into Ozone and am able to single step through the LED blink demo.

Makefile build on Windows Eclipse, native debug

On Windows, I imported a new Makefile project. I had to set the toolpath in Properties-> C/C++ Build/Tool Paths. I then set up a new Debug configuration under Run->Debug Configurations using the Segger plug-in that came with GNU ARM Eclipse. I could then launch the debug session and single step debug within Eclipse.
Last edited by MGeo; Nov 14, 2016 at 06:01 AM.
Nov 06, 2016, 10:49 PM
Professional amature
Mind blown!!

It is gonna take me a whole month to process all this info and figure out if I can use any of this and for God knows what.

Don't take this the wrong way - I love seeing this stuff and will read it with great interest!


Subscribed (at post #2!)
Nov 07, 2016, 05:12 AM
Registered User
MGeo's Avatar
Hi vastsky,

Yes I should apologize for the fast data dump here. I've been collecting these pieces up here and there for the past few months and decided it was a good time to collect it up in one place.

For me it has been useful to learn how some of the great DIY hardware/software packages actually work, and to do some troubleshooting and customization for my own use. I like the DIY stuff, and I'm finding that the projects that interest me all involve software in one way or another. So I need a good debug solution.

I think the bottom line when I get done is that if you want to work with embedded software for your projects, you can move beyond print statement type debug and do source code level hardware debugging with a few dollars worth of ebay hardware and some free software tools you can get online.

Last edited by MGeo; Nov 07, 2016 at 05:17 AM.
Nov 11, 2016, 02:37 PM
Professional amature
Hey George,

This is great stuff! Thanks for sharing!!
Nov 13, 2016, 07:16 PM
Registered User
MGeo's Avatar

How About DIY Black Magic Probe?

So I am very impressed with the Segger tools as shown above.

Beyond Segger J-Link, there is a great project here, working to turn $2.44 STM32F103 mini development boards (aka blue pill into cheap and cheerful BMP clones. This is the exact same board I am using above for demo work here, so I will have one dev board as target, and a second acting as BMP debug tool. The whole thing cost me $5 for the whole setup..

Some info found here turning an ST Link clone into a Black Magic Probe

Here we will build BMP from source and load onto a generic ebay blue pill.

Open up your WSL Bash window. Download and build the awesome Black Magic Probe project for the ST Link hardware project.

git clone
cd blackmagic
git submodule init
git submodule update
cd src
make clean
make PROBE_HOST=stlink
Last edited by MGeo; Nov 13, 2016 at 10:26 PM.

Thread Tools