Software Breakpoints

Software breakpoints are triggered by a special processor instruction. Once the instruction is executed, the processor halts. The software breakpoints are meant to be inserted into the code at run time at arbitrary places to replace other instructions. This duplicates functionality of hardware breakpoints. NSDSP Interface library uses a different approach.

NSDSP supports software breakpoints only with assisted debugging. The software breakpoints are placed in the code of the program being debugged before it is compiled using the NSDSP_DBG_BP macro, for example:

  NSDSP_DBG_BP(3);
  for (i = 0; i < n; i++) {
    if (data[i] == 0) {
      NSDSP_DBG_BP(4);
      break;
    }
    process(data[i]);
    NSDSP_DBG_BP(5);
  }
  NSDSP_DBG_BP(6);

This fragment of code contains 4 breakpoints. The number in parentheses is the id of the breakpoint. Breakpoint 3 is placed before the loop, so that you can halt at it and then step through the loop. Breakpoint 4 is placed to be halted when a certain condition occurs. Breakpoint 5 is placed at the end of the loop and let you stop at every iteration. Breakpoint 6 is positioned after the loop where you can verify the end result of the loop. Depending on your needs, you can enable any of these breakpoints individually.

The breakpoint ids start from 0. The maximum id depends on the processor. In 8-bit processors, there are 8 breakpoints, so the highest id is 7. On 16-bit CPUs, there are 16 breakpoints - 0 to 15. On 32-bit processors, there are 32 breakpoints - 0 to 31.

The NSDSP_DBG_BP macro checks if the correspond breakpoint is enabled. If it is, the break instruction is executed. If the breakpoint is disabled, the macro simply jumps over the break instruction causing no effects.

At the beginning of the program execution, all the breakpoints are disabled. Therefore, if you do not use the debugger, or if you do not enable breakpoints in the course of debugging, none of them will cause halts. Therefore, if you want to enable any breakpoints, you should do it immediately after the first halt. Then you can enable and disable breakpoints as needed.

The Debug Session object provides functions to enable and disable software breakpoints as needed. Some of the target devices allow enabling and disabling software breakpoints at run time, others only when halted. You can use the MCU object to look up debugging capabilities.

You can have several breakpoints with the same id. For example, you can give the same id to all the emergency breakpoints. In this case, they all will be enabled and disabled simultaneously.

After the halt, you can obtain the id of software breakpoint having triggered the halt. In some cases, the target can halt at a software breakpoint even though the halt was not caused by the breakpoint. These cases are indistinguishable.