Debugging STM32 Inside VSCode

Last updated: Oct. 24, 2022, 8:47 p.m.

In my current series on building my own handheld games console I've been developing for the STM32 inside VSCode. It's a reasonably comfortable IDE that works well on Linux and there's the STM32-for-VSCode extension.

That extension aims to automate everything for you but as usual with embedded development not everything is quite that joined up...

I'm working on a fairly clean install of Kubuntu 22.04. I'm using Wayland because it works better with the touch features and high DPI display on my Microsoft Surface, to make VSCode not look fuzzy I'm passing some extra options to Electron (the framework that VSCode and many other apps are built on):

code --enable-features=UseOzonePlatform --ozone-platform=wayland

The STM32 plugin offers to install the tools for you, but it's just a VSCode plugin, so it's just "installing" them in a folder in your home directory. That probably works okay for the compiler but for OpenOCD that means it doesn't set up the permissions files for JTAG/SWD probes. I installed OpenOCD from Apt:

sudo apt install openocd

If you do that before running the extension it should be detected and used for flashing. If it wasn't installed before you might need to go into the Settings (File->Preferences->Settings) and search for OpenOCD.

The current generation of GCC for ARM does not include GDB any more. The tools are still looking for arm-none-eabi-gdb. I installed the current "Multiarch" release:

sudo apt install gdb-multiarch

To use that with Cortex Debug which STM32-for-VSCode wants you to use you'll have to go rummaging in the settings again and set the GDB path. But, I've never got on with Cortex Debug and I tried it again when looking for my SDRAM issues a few days ago and failed again. While I could run and stop the code it immediately crashed when I tried inspecting variables.

I followed this gist for the general form of the configuration to use OpenOCD with cppdbg which seems to be a much more robust setup. That setup uses the old arm-none-eabi-gdb and has lots of target specific stuff, my solution is in the Git repo with the NoodleGame project.



Posting comments is not currently possible. If you want to discuss this article you can reach me on twitter or via email.


Email: nathan@nathandumont.com

Mastodon: @hairymnstr@mastodon.social