2020-02-17 07:11 AM
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
2020-02-21 01:54 AM
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.
2020-02-21 02:23 AM
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.
2020-02-21 03:27 AM
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