Using breakpoints is central part of debugging. I’m usually debugging my applications in flash memory. Because nearly all the microcontrollers I use have on-chip flash memory, and have more flash than RAM. With debugging in flash I limited by the number of hardware breakpoints. And here is the advantage with debugging code in RAM: availability of ‘unlimited’ software breakpoints. But how does this all works, and how to make efficient usage of hardware breakpoints?

Software Breakpoints

With software breakpoints, the debugger replaces an instructions with an illegal instruction or with a dedicated breakpoint instruction supported by the instruction set of the microcontroller. To illustrate this, below is some code in RAM starting at address 0x100. The LDA load instruction from the address 0x80 is encoded as 0x3788:

I want to set a breakpoint on the multiply MULA instruction at address 0x102. Assuming that this (hypothetical) architecture has a breakpoint instruction encoded as 0xffff, the debugger simply can replace the opcode at address 0x102 with the 0xffff BKPT opcode:

If the processor runs the code at address 0x102, it will trigger the debug module as defined in the microcontroller architecture.

I can take advantage of this as well in my application code. For example the ARM Cortex architecture supports the BKPT instruction. I can use this to have present in an interrupt routine to stop my target: The processor will cause an ‘illegal instruction’ exception which the debugger can catch.

void __attribute__((interrupt)) ISR_Unhandled(void) {
  asm("BKPT 255"); /* sofware breakpoint */
}

As a user, I do see that replaced instruction: the debugger does the replacement just as part of restarting the processor. And the debugger will restore the original content after the processor has stopped. The debugger maintains a list of places where it has replaced the memory with the breakpoint instructions:

If the debugger fails to restore the original instruction, then the software breakpoints remains and causes a target halt when it reaches that instruction. The debugger might report “illegal breakpoint” or something similar depending on the debugger. The problem might be caused by a board or hardware problem. Then the debugger breakpoint list might be corrupted too, and in this case it is best to reload the application to the target.

The good thing with software breakpoint is that it provides a almost unlimited number of breakpoints. And because changing instructions in RAM is easy for the debugger, software breakpoints are used for applications in RAM.

Some debuggers even apply software breakpoints on code running in flash memory. But this usually will make setting and removing breakpoints a time-consuming thing: The debugger has to erase and re-program the flash to set and remove the breakpoints. Other architectures implement a ‘patch list’, similar what is shown above with the debugger breakpoint list: with this it is possible to set software breakpoints with hardware. Which leads us to ‘real’ hardware breakpoints.

Hardware Breakpoints

To make debugging in flash memory easier, silicon vendors have added hardware breakpoint capabilities to their cores. Typical hardware breakpoints watch an internal bus or the program counter, and if it matches a certain condition, it will stop the processor, or will do whatever the hardware implements for that condition.

With this hardware capability, the debugger needs to know that particular device Hardware Debug Trigger module to set the flags. However, the number of hardware debug triggers is limited. The ARM Cortex-M0+ which is on my Freedom board is no exception to this: ARM has implement hardware debug support in the CoreSight module. The ARM Cortex-M0+ CoreSight can have 1, 2, 3 or 4 hardware breakpoints implemented. So I have software and hardware breakpoints, but do I have any control over what is used by the debugger?

Choosing Breakpoint Type

In the CodeWarrior debugger it is possible to affect the choice of debugger: the context menu in the ‘blue’ annotation area on the left side of the source let me select what kind of breakpoint is used:

This especially useful if I’m running an application with parts in RAM and parts in FLASH, or if I want to use hardware breakpoints for code in RAM.

Hardware Breakpoints in Eclipse

In Eclipse it is the Breakpoints View which manages the list of breakpoints:

What happens if I have only 2 hardware breakpoints, but I’m going to set 4. In the example below I set a breakpoint on line 41, then 42, then 43 and finally on line 40:

Only two breakpoints will have the check mark set:

This is shown in the Breakpoints view too:

Obviously the debugger is using Hardware breakpoints, according to the ‘Type’ column, and only two are set successfully. Having too many breakpoints set will have some impact on debugging.

Note: I pay close attention to the Breakpoints View and if my breakpoints have the check mark set or not. Because debugging a problem with a breakpoint not set I was thinking only I had set it is not very productive. And it allows me to closely monitor how many hardware breakpoints are used.

Running out of Hardware Breakpoints

If I launch my debug sessions with too many breakpoints, then the debugger is telling me about this:

As a counter measure, I can disable breakpoints from the Breakpoints view:

With all available my hardware breakpoints set, I still can do normal stepping. Well, not for all stepping cases, as I very likely will run into this one:

It means that the debugger was not able to set a breakpoint. What happened?

If I do a ‘step out’, the debugger needs an extra hardware breakpoint to stop the target if I step outside of the current function. But it if all my hardware breakpoints are already used, then the debugger cannot set that extra one.

A solution to this situation is to disable my hardware breakpoints in the Breakpoints view while stepping. But there is a small trick which can make my life easier :-).

Skipping Breakpoints Trick

This tipp does not solve all use cases, but helps. Usually the CodeWarrior debugger keeps the hardware breakpoints installed during stepping: that way if you ‘step over’ a function which has a breakpoint set, it will trigger inside that function. But if I’m OK to use my hardware breakpoints for the stepping operation, I can tell the CodeWarrior debugger to skip breakpoints (Window > Preferences > Run/Debug):

What it does is to disable all my set breakpoints when I do a ‘Run to Line’ stepping. This can be done with selecting a source line in the Source view and select the ‘Run to Line’:

An even easier view is to place the cursor in the Source view, and using the Ctrl+R shortcut. With this I do not need to disable my hardware breakpoints in the Breakpoints view, and still can do full debugger stepping. And as a side effect, I’m not running into my otherwise set breakpoints.

Happy Breakpointing 🙂