mbed: Debugging ST Nucleo_STM32F746ZG

[Chris]

Hello,

 

I just tried to debug a ST Nucleo_STM3F746ZG development-Board programmed with a simple program based on ARM mbed.

I already did the same with several other Nucleo-Boards and never had any unexpected problems, but ith this Board utilizing an ARMv7 regardless of what I do (simplest Blinky to complexer codes) the debugge hangs when Stepping (F10,F11) through the code.

Only way to somewhat debug the code is to set a breakpoint, press F5 and then wait till the debugger hits ssaid breakpoint. Pressing F5 again results in again hitting the same breakpoint (weird?), to step past this breakpoint it’s necessairy to remove that breapoint and then again press F5 to hit another breakpoint.

 

Using F10 / F11 to step through the code results usualy ending up in ‘void timer_irq_handler(void)’ located in ‘hal_tick_32b.c’.

 

I’d like to know if someone could replicate this behaviour on an STM32F746ZG or any other ARMv7 processor, since as already stated, I never experienced this behaviour with other mbed enabled boards and am somewhat … confused.

 

Thanks in advance,

Chris

[Chris]

Another very prominent place where the debugger seems to hang is ‘static void uart_irq(int id)’ located in ‘serial_api.c’.

This place othen is involved, when the debugger seems to take forever to reach the next code-line. The moment one presses “pause” the debugger often stops somewhere within ‘static void uart_irq(int id)’.

[support]

Hi,

This happens because once you hit ‘Step over’ or ‘Step in’, an interrupt occurs and OpenOCD is trying to step over the interrupt handler to get back to your code.

You could try disabling this behavior by temporary setting the ‘$PRIMASK’ register to 1 via the Watch window and then stepping. However this will delay the interrupt handler until you set PRIMASK back to 0, so some buffer overruns/underruns may occur.

[Chris]

Thanks, I will try that.

[Author]

Posts