Running a debugger

profezzorn · April 29, 2021, 6:39am

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

get an ST-link V2
hook SWDIO, SWDCLK and GND to the corresponding pads on the proffieboard
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

Compile and upload ProffieOS (or some other program) to your Proffieboard
In the compilation output, find the generated elf file, also make sure to remember your source dirctory.
Run gdb-multiarch

gdb-multiarch -d  /path/to/ProffieOS /tmp/arduino_build_250572/ProffieOS.ino.elf -ex 'target remote localhost:3333'

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.

Bobby_Susenbach · August 19, 2021, 3:13am

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

profezzorn · August 19, 2021, 8:47am

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.

NoSloppy · August 19, 2021, 3:22pm

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.

profezzorn · August 19, 2021, 4:15pm

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

NoSloppy · August 21, 2021, 7:12am

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
http://openocd.org/doc/doxygen/bugs.html
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'

profezzorn · August 21, 2021, 8:09am

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

Bobby_Susenbach · August 28, 2021, 12:18am

Thank you. Makes sense.

profezzorn · August 28, 2021, 11:07pm

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
	http://openocd.org/doc/doxygen/bugs.html
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:

BUILD=/var/folders/j2/4n85ntms6pgdm7r218lxgl38000kmj/T/arduino_build_771137

(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:

GDB=$HOME/Library/Arduino15/packages/proffieboard_beta/tools/arm-none-eabi-gcc/9-2020-q2-update/bin/arm-none-eabi-gdb

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)

NoSloppy · September 17, 2021, 12:57am

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?

profezzorn · September 17, 2021, 1:00am

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

profezzorn · September 17, 2021, 1:02am

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

NoSloppy · September 17, 2021, 2:34am

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.

profezzorn · September 17, 2021, 2:41am

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.

NoSloppy · September 17, 2021, 2:57am

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.

profezzorn · September 17, 2021, 2:59am

Did you put the $ in $GDB?

NoSloppy · September 17, 2021, 2:59am

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.