|
|
|
|
|
by sigill
3532 days ago
|
|
Yes. And these software breakpoints are written into flash. This is why they're very slow - and why they wear down your flash. The situation is kinda OK when you don't often change breakpoints and your CPU has an instruction register writable by the debug probe via JTAG/SWD/etc. Upon stepping or continuing from a breakpoint, the debugger will write the actual instruction at the breakpoint into the instruction register and tell the CPU "run again, but don't load the instruction from memory as I have already loaded it into your instruction register.". Another option is to emulate the effects of the instruction in the debugger and write the results back into registers/RAM/I/O. This is not always possible. If you don't have the options above, your flash will wear down quickly, as stepping away or continuing from a breakpoint entails writing the actual instruction back, stepping, then writing the breakpoint again. |
|
> And these software breakpoints are written into flash.
The GP is referring to the eight FPB hardware breakpoints, which do not need to be written to flash. Most Cortex-M have an additional four hardware breakpoints from the DWT. You can get a lot done with 12 breakpoints before you need to start writing things to flash.
More generally, as long as the debug interface allows you to run with interrupts disabled and has at least one HWBP, you can single-step without writing SWBP to memory.