Debugging M4 with GDB from command line?

[unicycle]

I would like to understand what the Eclipse IDE is doing to start the debugger, so that I can move away from using it. I much prefer CMake and other tools. I'd be grateful for any assistance. The wiki section for this is TBD.

I'm not too familiar with OpenOCD, but have run the command:

$OECORE_NATIVE_SYSROOT/usr/bin/openocd -s $OECORE_NATIVE_SYSROOT/usr/share/scripts -f board/stm32mp15x_dk2.cfg

This seems to work so, moving on to GDB:

$OECORE_NATIVE_SYSROOT/usr/bin/arm-openstlinux_weston-linux-gnueabi/arm-openstlinux_weston-linux-gnueabi-gdb firmware.elf

And this is where I come unstuck. I've used GDB a bit, but don't know the magic incantations to install an image into the M4 on this platform.

(gdb) target remote localhost:3333

Remote debugging using localhost:3333

0x00000000 in g_pfnVectors ()

I get a "target not yet examined" error which I don't understand. The vector table is all zeroes, so nothing has yet been placed in the RAM yet.

(gdb) load

Loading section .isr_vector, size 0x298 lma 0x0

Loading section .text, size 0x1688 lma 0x10000000

Load failed

Open On-Chip Debugger 0.10.0+dev-00546-g1afec4f-dirty (2019-02-01-13:33)

Licensed under GNU GPL v2

For bug reports, read

  http://openocd.org/doc/doxygen/bugs.html

debug_level: 1

cortex_a interrupt mask on

cortex_a interrupt mask on

cortex_a domain access control fixup on

cortex_a domain access control fixup on

3333

none separate

adapter speed: 5000 kHz

adapter_nsrst_assert_width: 200

adapter_nsrst_delay: 200

none srst_pulls_trst

srst_only srst_pulls_trst srst_gates_jtag srst_open_drain connect_deassert_srst

srst_only srst_pulls_trst srst_gates_jtag srst_open_drain connect_deassert_srst

Error: Could not find MEM-AP to control the core

embedded:startup.tcl:24: Error:

in procedure 'stm32mp15x.cpu2'

in procedure 'ocd_bouncer'

at file "embedded:startup.tcl", line 24

undefined debug reason 7 - target needs reset

Error: Target not examined yet

Error: Target not examined yet

Error: Target not examined yet

...

[unicycle]

Hmm... OK. Made some progress. I can start the program via SysFS on the Linux side, and then connect to it from gdb through openocd. Still don't know how to reset the firmware. I must be missing something for it to be this much effort.

[Uwe Bonnes]

You can also have a look at the Bl*ckm*g*c" Debug Probe https://github.com/blacksphere/blackm*g*c/wiki , compiled for the pc-stlinkv2 Platform (make PROBE_HOST=pc-stlinkv2). For compiling, GNU tools are needed. You start the PC hosted executable and in gdb you connect to that tool wilt "target ext :2000).

Replace * by fitting vocals, as writing the names explicit gets the message rejected.

[Olivier GALLIEN]

Hi @Community member​ 

Copy past here interesting part of an answer you can find in following post :

https://community.st.com/s/question/0D50X0000B5HO3HSQW/stm32cubeprog-does-not-recognize-the-stlink-for-stm32mp157dk1

You can avoid using a IDE by using directly OpenOCD and GDB provided in openSTlinux Developer Package SDK

https://wiki.st.com/stm32mpu/wiki/Which_STM32MPU_Embedded_Software_Package_better_suits_your_needs#Developer_Package

or even using only the OpenOCD from SDK together with any GDB for ARM already available in your PC.

The wiki page below is specific for debugging the Cortex-A core, but many information on how to run OpenOCD with GDB are similar for the Cortex-M case. Please note that the OpenOCD port to connect GDB to Cortex-M is the 3333, while it is 3334 for Cortex-A.

https://wiki.st.com/stm32mpu/wiki/GDB

If you need to rebuild OpenOCD, the code is available inside the yocto recipe in

https://github.com/STMicroelectronics/meta-st-stm32mp/tree/thud/recipes-devtools/openocd

Hope it help

Olivier

[Olivier GALLIEN]

Hi @Community member​ 

Reading again your post, maybe also missing piece for you may be this page :

https://wiki.st.com/stm32mpu/wiki/Linux_remoteproc_framework_overview

Where you can find how to load and start firmware from Linux Sysfs

Olivier

[unicycle · Accepted solution]

Thank you for your comments.

I did get there in the end. I was just lacking a little GDB knowledge (I much prefer graphical debuggers). The process is a bit laborious, but I can work out how to script it later (this is presumably what Eclipse is doing). For the benefit of others who might want to do this:

• build firmware.elf on PC - I'm using CMake with the GCU ARM toolchain in the SDK.
• scp firmware.elf to /lib/firmware on the board
• ssh onto the board and restart the firmware: echo stop >/sys/class/remoteproc/remoteproc0/state, and then echo start ...
• start openocd: $OECORE_NATIVE_SYSROOT/usr/bin/openocd -s $OECORE_NATIVE_SYSROOT/usr/share/scripts -f board/stm32mp15x_dk2.cfg
• start gdb: $OECORE_NATIVE_SYSROOT/usr/bin/arm-openstlinux_weston-linux-gnueabi/arm-openstlinux_weston-linux-gnueabi-gdb firmware.elf
• (gdb) target remote localhost:3333

GDB halts at wherever your firmware is currently executing. To reset the firmware:

• (gdb) monitor soft_reset_halt
• (gdb) step - you are at the entry point of Reset_Handler

I'm sure this is not the only way to debug firmware running in production mode, and perhaps I could do it more efficiently. It's been interesting getting here: I wanted to understand what is going on with this hardware (compared to my usual domain, it's not Kansas any more). But now I wonder if I can have my cake and eat it. I don't love Eclipse for project management, and prefer text-based build systems such as CMake. On the other hand, SW4STM32 was doing a decent job of being a graphical debugger for the examples.

[Alan Chambers]

Further progress....

Using a graphical debugger is far more convenient and productive than using GDB (YMMV). After much fruitless faffing about with VSCode's launcher, I installed QtCreator and followed the instructions here: https://electronics.stackexchange.com/questions/212018/debugging-an-arm-stm32-microcontroller-using-qt-creator, with some mods for GDB startup commands. I still have to manually copy and start the firmware via Linux, and start openocd as before, but I then launch the firmware in the IDE and much is right with the world. I should have tried this sooner.

I still need to sort out the SVD or whatever to view peripheral registers, but not sure if QtCreator supports this. Maybe there's a plugin...

The IDE also understands my CMake files and executes the build exactly as Ninja does from the command line. Deep joy.