Question

In the past, I have been debugging executables loaded in the internal SRAM of my Cortex M3 (STM32F2) without problems. I have recently been loading my executable to Flash (because of size issues).

Ever since, debugging with GDB has not been working. As I understand, when the executable is in Flash, only hardware breakpoint can be used (as opposed to software breakpoints), and I have six hardware breakpoints. However, when setting just one hardware breakpoint GDB yields an error message:

(gdb) break main
Breakpoint 1 at 0x800019a: file src/main.c, line 88.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) Warning:
Cannot insert hardware breakpoint 1.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

What could be going wrong? Have my hardware breakpoints be taken in the background?

Note: I used OpenOCD to load the executable through JTAG.

Answer 1

So, there’s basically two ways (plus one really bad way) that breakpoints can be implemented on any given debugger/platform combination:

1. Use some hardware capabilities (“hardware breakpoints”) to cause the processor to trap when it hits a particular address. This is typically restricted to just a couple of breakpoints, if it’s available at all.

2. For each breakpoint that’s being set, replace the instruction at the breakpoint with a “trap” instruction of some variety (i.e, an instruction that will break into the debugger). When one of the breakpoints is hit, swap the original instruction back in and single-step once to make it run.

3. Single-step through the whole program. This one doesn’t really count, because it’s horrifically slow.

It sounds as though your debugger is only using method #2 (“software breakpoints”). The gotcha with this method is that it requires the program to be writable — and flash memory isn’t writable one instruction at a time, so this technique won’t work.