AnsweredAssumed Answered

Problem with Single Step STMF7

Question asked by bauch.aaron.001 on Dec 7, 2016
Latest reply on Oct 15, 2017 by Clive One

There is a problem with IDE debuggers for STMF7, and as I understand, all ARM M7 core based processors.  With other CORTEX controllers, when a debbuger pauses or hits a breakpoint, the debugger stops interrupt processing so that, even if interrupts are running in the system, when you single step, you go to the next line in the software module you are debugging.  With the F7 debuggers, like GDB which is used by Eclipse, SW4STM32, Keil and other toolsets, when you hit a breakpoint and then try to single step, if any interrupts are running in the system, you step into an ISR, or the same instruction, not your next instruction and will keep doing this forever.  The "workaraound" is apparently to put your cursor on another line and tell the debugger to "Run to Cursor".  But even this does not work until you disable the breakpoint where you stopped, because the interrupt return keeps taking you back to the breakpoint rather than going on.

 

Does anyone know if this is being fixed?  Or if there is a workaround?  Or if any toolsets have fixed it?  I have been working on a complex application on the F746 Discovery board that uses FreeRTOS, STemWin, A/D's running interrupts etc. etc. and this bug makes it really painful to just operate.  I am Using SW4STM32 but I assume this also affects the big money toochains that also use the basic GDB debugger as its main debug engine.

 

Help?

Outcomes