Debugging Cortex-M33 application started by Linux remoteproc on STM32MP257

[Hs26]

Hi ST team,

I am working with an STM32MP257 where Linux runs on the Cortex-A35 and a FreeRTOS application runs on the Cortex-M33. The M33 firmware is loaded and started by Linux using remoteproc.

The application is running correctly, but I would like to understand the recommended workflow for debugging the M33 application.

I have read the "Debug support" section of RM0457 and understand that the M33 can be accessed through the shared SWD/JTAG interface by selecting the appropriate Access Port. However, I'm still not clear on the recommended debug workflow when the M33 is managed by remoteproc.

My questions are:

• Can STM32CubeIDE/ST-LINK attach to an already running M33 started by remoteproc, or should the M33 be stopped first?
• If Linux has already loaded the firmware, should the debugger load only the ELF symbols instead of downloading the application again?
• Is there any special OpenOCD/ST-LINK or CubeIDE configuration required for this use case?
• Is there an ST application note or example demonstrating the recommended workflow?

My goal is to debug the M33 application with breakpoints, single-stepping, and variable inspection, similar to debugging a standalone STM32 MCU, while Linux continues to run on the A35.

Any guidance would be appreciated.

Thank you.

[Olivier GALLIEN]

Hi ​@Hs26,

I guess you can start by looking at Develop on Arm® Cortex®-M33 - stm32mpu it will drive you to initial step setting up debug on CM33

Hope it help 

Olivier 

[Hs26]

Hi ​@Olivier GALLIEN ,

Thank you for the response! Actually, I did try that earlier and I was able to do following 

• Pausing / Resuming Code via user buttons
• Watching Expression / Live expression, SFRs etc..
• Break Point Facility is not working  (which was my main objective for this post!)

Here is my console log when I start debug session

Open On-Chip Debugger 0.12.0+dev-00635-gddb0d32b4 (2025-11-07-10:06) [https://github.com/STMicroelectronics/OpenOCD]
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain connect_deassert_srst
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : STLINK V3J16M9B5S1 (API v3) VID:PID 0483:3753
Info : Target voltage: 3.287060
Info : Unable to match requested speed 5000 kHz, using 3300 kHz
Info : Unable to match requested speed 5000 kHz, using 3300 kHz
Info : clock speed 3300 kHz
Info : stlink_dap_op_connect(connect)
Info : SWD DPIDR 0x6ba02477
Info : [STM32MP257FAIx.ap0] Examination succeed
Info : [STM32MP257FAIx.m33] Cortex-M33 r1p0 processor detected
Info : [STM32MP257FAIx.m33] target has 8 breakpoints, 4 watchpoints
Info : [STM32MP257FAIx.axi] Examination succeed
Info : gdb port disabled
Info : starting gdb server for STM32MP257FAIx.axi on 3334
Info : Listening on port 3334 for gdb connections
Info : gdb port disabled
Info : gdb port disabled
Info : gdb port disabled
Info : gdb port disabled
Info : starting gdb server for STM32MP257FAIx.m33 on 3333
Info : Listening on port 3333 for gdb connections
Info : gdb port disabled
Info : accepting 'gdb' connection on tcp/3333
[STM32MP257FAIx.m33] halted due to debug-request, current mode: Thread
xPSR: 0x89000000 pc: 0x80101ab8 msp: 0x80dfffc0
Info : New GDB Connection: 1, Target STM32MP257FAIx.m33, state: halted
Info : accepting 'gdb' connection on tcp/3333
Info : New GDB Connection: 2, Target STM32MP257FAIx.m33, state: halted
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1799 ms). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1889 ms). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1221 ms). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1007 ms). Workaround: increase "set remotetimeout" in GDB
Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1197 ms). Workaround: increase "set remotetimeout" in GDB

Am I missing something? or doing something wrong?