cancel
Showing results for 
Search instead for 
Did you mean: 

Debugging M4 with GDB from command line?

unicycle
Associate III

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

...

1 ACCEPTED SOLUTION

Accepted Solutions

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.

View solution in original post

6 REPLIES 6
unicycle
Associate III

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
Principal II

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
ST Employee

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
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

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

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

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.

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.