Unable to skip Mbed framework from interrupting debugging

Advanced Solutions
, , ,
1

Hello,

I am encountering two issues when debugging my STM32F7 nucleo board with STLink v2 using the Mbed OS framework.

The first issue is that whenever I try to continue the execution flow of a breakpoint, I get stuck on the same code line. I have to disable the breakpoint to continue the execution.

The second issue is that when I use the step over function, I continuously get redirected by an interrupt IRQHandler in the Mbed framework. I have already tried setting “skip -file or skip -gfi” command in platformio debug_load_cmds, but it did not solve the problem.

Has anyone else encountered similar problems while debugging a platformio and stm32? Is there a way to ignore the GDB path from stopping execution?

Thank you for your time and assistance.

2

Is Topic: Debugging impossible when timer interrupts are enabled | Sysprogs still valid? So per docs one could just say

debug_extra_cmds = mon cortex_m maskisr on

However, a different method would be to make OpenOCD mbed-os / Keil RTX5 aware. That’s just adding -rtos auto in some openocd configuration file.

Can you post your exact platformio.ini?

3

Thanks for your reply. I’ve tried your hint but I still got interrupted. On your first link it says that it should not work with STLink.

With your second solution, where should I define rtos auto in platformio config?

My platformio.ini now looks like:

[env:nucleo_f746zg]
platform = ststm32
board = nucleo_f746zg
framework = mbed
monitor_speed = 115200

build_flags = -U_printf_float
debug_extra_cmds = mon cortex_m maskisr on

Thx

4

The used OpenOCD config files are per

so find C:\User\<user>\.platformio\packages\tool-openocd\scripts\target\stm32f7x.cfg, specifically line 48 with

$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0

and add -rtos auto at the end of it.

When you start debugging again, does OpenOCD recognize the different RTX5 threads? They should be visible when the target is halted as different collapsable threads in the call stack view.

5

In my debugger console I have this log: Warn : No RTOS could be auto-detected!
When I stop in my main I have no other threads in the call stack.

6

Well that’s disappointing. Looks like I need to make my own tests on my stm32 hardware.