Running a debugger

This is how you do it on Linux, I will try to figure out how to do it on other Mac and Windows later:

  1. get an ST-link V2
  2. hook SWDIO, SWDCLK and GND to the corresponding pads on the proffieboard
  3. Start openocd, which is a bridge server between gdb and the st-link.
cd $HOME/.arduino15/packages/proffieboard/hardware/stm32l4/*.*.*/
sudo ./tools/linux/openocd/bin/openocd -s tools/share/openocd/scripts/ -f  ./variants/STM32L433CC-Proffieboard/openocd_scripts/stm32l433cc_butterfly.cfg 
  1. Compile and upload ProffieOS (or some other program) to your Proffieboard
  2. In the compilation output, find the generated elf file, also make sure to remember your source dirctory.
  3. Run gdb-multiarch
gdb-multiarch -d  /path/to/ProffieOS /tmp/arduino_build_250572/ProffieOS.ino.elf -ex 'target remote localhost:3333' 
  1. When you first connect, the state will be kind of weird and the program will still be running. Type cont and then press ctrl-c to stop the program. Now you can inspect variables and generally use gdb as you would normally.

One day this might all become easier, but right now, not a lot of people actually use this, so it’s not been a high priority for me.

1 Like

Will someone please explain, in lay terminology, what debugging does in this environment? Why/ when would you/developers debug? Thx in advance

A debugger lets you inspect the memory of the proffieboard CPU. It also lets you start/stop the program and analyze the stack trace. This lets me as a programmer find out what happened when something went wrong.

For proffieboards, debuggers are the most useful when a crash occurs (1000hz squee-of-death) A debugger will let me (or someone else) figure out exactly where in the code the crash occured, which is usually enough to figure out how to fix it.


Vague comments from memory the day after playing with this on MacOS:
I get a couple of speed warning with my ST link, (wanted 500, only 480)
Then a failed to open error.
Then something about ‘init’.
Obviously I can clarify this when I get back in front of my computer but on the train now and figured I’d chime in.

1 Like

What method did you use to install openocd & gdb-multiarch on your mac?

1 Like
cd /Users/bconner/Library/Arduino15/packages/proffieboard/hardware/stm32l4/*.*.*/
sudo ./tools/macosx/openocd/bin/openocd -s tools/share/openocd/scripts/ -f  ./variants/STM32L433CC-Proffieboard/openocd_scripts/stm32l433cc_butterfly.cfg

and here’s the output:

Open On-Chip Debugger 0.10.0-dev-00272-gf17dc4a (2016-10-10-09:57)
Licensed under GNU GPL v2
For bug reports, read
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 500 kHz
adapter_nsrst_delay: 100
none separate
none separate
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : clock speed 480 kHz
Error: open failed
in procedure 'init'
in procedure 'ocd_bouncer'
1 Like

Is swdio, swdclk & gnd hooked up between the stink and the proffieboard when you run that?

Thank you. Makes sense.

Ok, I think I’ve figured out how to run a debugger on a mac.

Prerequisites: Install openocd from homebrew or some other similar environment.

brew install openocd

The openocd that comes with the arduino-proffieboard plugin doesn’t seem to work.

Step #1: Start OpenOCD
Open up a terminal window and find your arduino-proffieboard pluggin directory. In my case it was $HOME/Library/Arduino15/packages/proffieboard_beta/hardware/stm32l4/3.4.0
To start openocd, run it as:

opencd -f $HOME/Library/Arduino15/packages/proffieboard_beta/hardware/stm32l4/3.4.0/variants/STM32L433CC-Proffieboard/openocd_scripts/stm32l433cc_butterfly.cfg 

Instead of loading it from the plugin dir, you could also check out the config file from github.

When you run openocd, you should see this:

Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
none separate

Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 500 kHz
Info : STLINK V2J17S4 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.246123
Info : STM32L433.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for STM32L433.cpu on 3333
Info : Listening on port 3333 for gdb connections

Step #2, run gdb
Before we can start GDB, we need to find where arduino keeps it’s temporary files.
Go into arduino preferences and make compilation verbose so you can find the compilation directory. When you compile something, a bunch of temporary files are saved somewhere that are important for debugging. In my case they were in /var/folders/j2/4n85ntms6pgdm7r218lxgl38000kmj/T/arduino_build_771137. Since that’s a pain in the butt to type every time, I set a variable:


(Do this in the terminal that you want to run GDB in, not the same one as used for openocd…)

Gdb is also in the arduino plugin directory, but in the tools sub-section, so in my case, I found it in: $HOME/Library/Arduino15/packages/proffieboard_beta/tools/arm-none-eabi-gcc/9-2020-q2-update/bin/arm-none-eabi-gdb

Again, let’s use a variable:


Now we can start gdb like so:

$GDB -d  ~/ProffieOS/ $BUILD/ProffieOS.ino.elf -ex 'target remote localhost:3333'

(This assumes that your ProffieOS source directory is ~/ProffieOS)


Working finally. USB Extension cable is not my friend today.
Now…GDB commands number in the millions it seems. What should I look for / catch?

The most important are:

  • cont - continue executing
  • ctrl-c - stop executing
  • bt - backtrace
  • up/down - go up/down in the backtrace
  • p/print - print values

Oh, and “list” to show a bit of the code at whatever place you are at right now.

1 Like

That just gives “No symbol table is loaded. Use the “file” command.”
If I have stopped it, then do cont, I’ts busy “Continuing” and doesn’t accept commands.

Hmm, it’s supposed to get the symbols from the elf file. Did you give it the right path for the build directory when starting gdb? I must admit that I didn’t try it very much, so I don’t know how well it works.

It’s normal for gdb to not accept commands while the program is running.

defining BUILD seems to work, but GDB seems like it didn’t like it because
-bash: GDB: command not found
I just dragged the arm-none-eabi-gdb file into Terminal to get the path, added -d and path to ProffieOS folder and that runs it.

Did you put the $ in $GDB?

Oh. No, I took that to be your prompt.

Anyway, the idea was to have this display issue act up and try to catch something to report, but it’s almost like the ST-Link is keeping the sticking from happening. I can’t get it to fail.