Debugging M4 with GDB from command line?

Question

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

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

...

unicycle · Accepted Answer

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.

unicycle · Answer

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.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded