Breakpoints, Stepping, and Watchpoints

The classic breakpoint replaces the instruction at the chosen address with a special trap instruction (BKPT on Arm). When the core executes it, it halts and the debugger takes over; before resuming, the debugger puts the original instruction back, steps over it and re-inserts the trap. There is no limit on how many you can set.

The catch is the word replace. It works only where the debugger can write the code with an ordinary memory write: RAM. Code in flash cannot be patched that way (some commercial debug servers do it anyway by erasing and reprogramming a flash sector, which is slow and wears the flash).

For code in flash, the core provides a few comparators that watch the instruction fetch address (on Cortex-M, the Flash Patch and Breakpoint unit) and a few that watch data accesses (the Data Watchpoint and Trace unit, DWT). Each hardware breakpoint or watchpoint occupies one comparator, and the counts are small and chip-specific; debuggers read them from FP_CTRL and DWT_CTRL when they connect.

↑ This step uses the figure at the top of the page.

GDB chooses automatically from the target’s memory map: software breakpoints in RAM, hardware ones in read-only memory. When the comparators run out, the extra breakpoints or watchpoints cannot be inserted, and GDB may only report it when you resume. There are two hidden users of comparators to remember:

• next and finish work by setting temporary breakpoints (after the call, at the return address). In flash code they need a free comparator too.
• An older Flash Patch unit (revision 1) can only place hardware breakpoints below address 0x2000_0000, in the code region.

watch counter stops when counter changes, rwatch when it is read and awatch on any access. A hardware watchpoint stops right at the write, which is the whole point: the debugger shows the offending code, not a symptom later (on Cortex-M the core halts just after the store completes, possibly an instruction or two later). With a remote debug server GDB does not know how many comparators exist: it accepts every watch as a hardware watchpoint and reports “Could not insert watchpoint” when you resume. Only if you tell it the limit (set remote hardware-watchpoint-limit 2) does it fall back to a software watchpoint instead: it single-steps the program and compares the value after each step, hundreds of times slower, and reports only at the next source line. rwatch and awatch have no software fallback at all.

A comparator also watches a limited shape: on Cortex-M a region whose size is a power of two and whose address is aligned to that size (the hardware allows masks up to 32 KiB). A 12-byte structure, or an 8-byte value aligned only to 4 bytes, needs a larger covering region or several comparators.

A flag ready at 0x2000_0418 turns to 0 unexpectedly. The chip has 4 breakpoint and 2 watchpoint comparators, and two breakpoints are already set in flash.

1. watch ready takes one DWT comparator. Two breakpoint comparators remain free for next and finish.
2. The program stops just after the store that changed it, with GDB reporting the old and new value; bt shows the call chain that led to it (lesson 3).
3. The culprit is a memset of a neighbouring 16-byte buffer with length 20: bytes 0x2000_0408 to 0x2000_041B, four bytes past the buffer’s end at 0x2000_0417, into ready.

$$\text{last byte written} = 0x2000\_0408 + 20 - 1 = 0x2000\_041B \geq 0x2000\_0418 = \&\text{ready}$$

Without the watchpoint, the only symptom was a flag that was sometimes wrong.