cancel
Showing results for 
Search instead for 
Did you mean: 

CPU freezing when inserting or removing a breakpoint

dave2012
Associate III

Hi,

I've come across an issue whereby inserting or removing a breakpoint anywhere in my code when the processor is running causes execution to pause for ~180ms. I thought manipulation of breakpoint registers was independent of processsor execution state.

Is this delay to be expected ?

I'm using a STM32F7, ST-Linkv3 and OpenOCD with STM32CubeIDE v1.2.

Thanks

Dave

3 REPLIES 3
mattias norlander
ST Employee

Yes it is expected. gdb halts the core to set or unset a breakpoint and then resumes the program execution,: All-in-all this takes about ~180ms.

Other toolchains can do it without visibly affecting the target.

OTOH, I'm also working with toolchains which are unable to set breakpoints when running.

dave2012
Associate III

Thanks for confirming Mattias, at least I'm not going mad. It's a real problem as it causes comms link timeouts.

I've tried setting a breakpoint in OpenOCD via Telnet and this works fine without halting the CPU. However, when I try to remove the breakpoint it complains that the target is not halted and the breakpoint remains set.

I've tried selecting JLink as the debug adapter (different GDB server) and this also results in halting the CPU when setting a breakpoint. Maybe you'd expect this too?

It would be really helpful to get a workaround for this if possible. As @Ozone​ says, there are tools that don't halt the CPU (I never came across this issue with Keil uVision for example).

Dave