Debugger for Embedded — How to Choose the Right Debugger

At Jumper we’re developing tools that increase the happiness levels of embedded software developers. Our main tool to date is the Jumper Emulator. As a part of the development process we’re required to use embedded debuggers to verify that our emulator is on par with the actual hardware. Our focus is on ARM Cortex M devices. The MCUs we’re debugging are the nRF52, STM32F4 and LPC1768.

An Embedded software debugging session can get quite frustrating. After testing several options, we’re happy to provide a summary of what we learned. Let us know if we missed something! (feedback@jumper.io).

Update: thanks for all the feedback: https://www.reddit.com/r/embedded/comments/6sk7ly/i_tried_5_different_debugger_ides_for_nrf52_and/. As a result, I decided to add an analysis of the SEGGER Ozone debugger. Thanks Jimmie Johansson from Svep Design for calling it out.

TL;DR

VisualStudio + VisualGDB is the best value for money offering we’ve found ($45/month Visual Studio + 90$ a year for VisualGDB. There’s also a free community version of Visual Studio meant for students and individuals — kudos Microsoft).

Longer version

Eclipse

We started off with Eclipse CDT with the GNU ARM Eclipse addon (here’s a tutorial link that we tested and found working https://devzone.nordicsemi.com/tutorials/7/). It’s the cheapest choice and it’s really feature reach. You get register views, memory view with memory access breakpoints, disassembly window and instruction mode to help navigate assembly (often very useful). Where it falls short on is stability. Long debug sessions tend to freeze or crash. I recently updated all the GNU ARM Eclipse, CDT and eclipse add-ons and stability improved dramatically, but eventually it’ll crash (once every 3–4 hours, and always when you’re just about to get to the interesting bit).

Pros

• Free
• Feature full
• Large community

Cons

• A bit unstable

Visual Studio Code

Still trying to keep cost down, we went on to try and use Visual Studio Code, the relatively new, free open source IDE from Microsoft. A bunch of us are using it as their main IDE. It’s plugin ecosystem is rather extensive and it’s sleek design makes it fun to use. For VS Code to work with embedded debugging you’ll need to download a native debugger extension and fire up the JLink or STLink server yourself (We used this link and it worked for us https://www.youknowwhatreallygrindsmygears.com/index.php/2016/06/18/arm-gdb-debugging-with-visual-studio-code/).

We found it to be quite stable and fun to use. It is missing some pretty useful features though: registers view, memory view and disassembly view. You can get around those by using objdump and GDB commands to get memory and register data. Having a nice UI to get you the data is really helpful, and unfortunately that’s missing here.

Pros

• Free
• Growing community
• Stable

Cons

• Missing features: memory and registers view

IAR

We then decided to turn to IAR. Known as one of the best, if not the best IDE for embedded development, it has it all. The debugger has the most extensive feature set that includes everything we already described, including power analysis tools, and even RTOS middleware analysis. The middleware analysis supports FreeRTOS and displays the tasks configured to run in FreeRTOS — super useful. The only downside is that IAR is a bit pricy. We think it’s totally worth the quality as it’s super stable and performs very well. But we’re definitely not a fan of the Windows only approach. Linux support is a given now days.

Pros

• Stable
• Awesome performance
• Most feature full

Cons

• A bit expensive
• Only supports Microsoft Windows

Visual Studio with VisualGDB

Another non-free option, but with a more reasonable price, is using Visual Studio and VisualGDB. It doesn’t have all the fanciness of IAR like Power Analysis, but it does provide everything provided in eclipse, alongside some cool features like hardware registers view.

We found the following tutorial works perfectly. https://visualgdb.com/tutorials/arm/nrf51/nrf52/. I do recommend to use the MSBuild option instead of GNU Make as it took less setup time, but GNU Make should also work.

Pros

• Stable
• Awesome performance
• Has all the features you need and perhaps a little more

Cons

• A bit expensive

Atom with Platform IO

We also found this options to be quite useful. Platform IO provides a GDB debugger that plugs into Atom or Visual Studio Code. The thing that’s bugging us down is the lack of register view. It could also improve on stability. In general, we like what the guys at PlatformIO are up to and we’ll be keeping an eye open on this project.

Pros

• Free
• Growing community

Cons

• Stability can improve
• Some functionality is missing

SEGGER Ozone

Another cross platform ( option is provided by a the physical debugger company, SEGGER. It’s a debugging only tool, not an IDE, but that doesn’t really matter. I was highly impressed by the stability and performance. This thing is fast! I used it for a day with no glitches. It’s also quite feature full and almost up to par with IAR. The one drawback is that I couldn’t find a way to purchase it separately from the SEGGER Plus debugger. And it’ll cost you roughly $480 to get that.

Pros

• Feature full
• Fast as he
• Cross Platform

Cons

• Price is a bit of an issue

Summary

Using a variety of tools is useful when it comes to handling different types of bugs. If you’re using a tool that’s missing here, kindly let us know! We’d be happy to test it and add to the list. Feel free to comment here or send us feedback on feedback@jumper.io or comment on this post. If you find this interesting — signup to get updates from Jumper and join our closed beta.