A breakpoint is an intentional stopping place during an execution of a program. It is a powerful debugging feature allowing us to suspend the execution of the program at a certain point and examine the current values of variables and memory locations. The program can then be resumed from the exact point it was suspended. Adding or removing breakpoints does not change the source code of the actual program we are developing. There are two types of breakpoints: hardware breakpoints and software breakpoints.

Hardware Breakpoints

Hardware breakpoint is implemented by the use of a dedicated hardware (usually comparators) that is used for detecting a particular event. That event is usually a value of the micoprocessor’s program counter. Once the event is detected it will cause the processor to halt.

Advantages:

  • Can be set on both volatile (RAM) and non volatile memory (e.g ROM, Flash etc.)

Disadvantages:

  • Limited number of hardware breakpoints (2 to 8 depending on the CPU architecture)

Software Breakpoints

Software breakpoint is implemented by replacing the instruction at the breakpoint location with a breakpoint instruction (if such is supported by the microprocessor) or “illegal” instruction  (e.g divide by zero  causing an exception) that halts the CPU when executed. When a breakpoint is encountered, the microprocessor halts and the debugger tool replaces the breakpoint instruction with the original instruction.

Advantages:

  • Unlimited number of software breakpoints

Disadvantages:

  • Software breakpoints can be placed almost exclusively in volatile memory (RAM). There are debuggers that can set breakpoints even in non-volatile memory (e.g Flash) in cases when the program is run directly from there but such operations are time-consuming.