January, 2005

What is the Difference between Software and Hardware Breakpoints?

As the names might indicate, a hardware breakpoint is implemented in hardware and a software breakpoint is implemented in software. But what does that mean to the user? When should they use a hardware breakpoint? A software breakpoint? What are the advantages and disadvantages of each?

Software breakpoints

When a software breakpoint is set, the emulation driver reads the instruction at that location, removes the first byte of the instruction, and replaces it with a software breakpoint opcode. This software breakpoint opcode is what tells the CPU to halt at this instruction. The byte that was removed from the instruction is then placed into a breakpoint table where it is associated with the address that it was removed from. The driver will then read back the instruction to be sure that the breakpoint has been set properly.

When RUN is issued from CCStudio, the CPU starts running. Periodically, CCStudio polls the target for status to see if it has halted. As long as the CPU continues to run, CCStudio does nothing except continue polling. If CCStudio determines that the CPU has halted, it first queries the CPU to see why it halted (i.e. software breakpoint, hardware breakpoint, embedded breakpoint, user halt). If the CPU returns a status of "Halted by Software Breakpoint", the driver reads the PC, looks up the breakpoint in the breakpoint table, and replaces the breakpoint opcode with the byte from the actual instruction (the user should never see the breakpoint opcode in the disassembly window). If the breakpoint remains enabled after the instruction has been executed by either a run or a step, the first byte of the instruction gets replaced again by the software breakpoint opcode.

Since software breakpoints are implemented in software, their number is virtually unlimited. So as long as there is memory on the host to store the breakpoint information, a software breakpoint can be implemented. However, software breakpoints can only be used in RAM. If the target memory cannot be written to, then the breakpoint opcode cannot be inserted. If it’s necessary to set a breakpoint in ROM, hardware breakpoints should be used.

Hardware breakpoints

As noted earlier, hardware breakpoints are implemented in hardware. This means that there are physical hardware units located on the chip to enable hardware breakpoints. The breakpoint portion of these analysis units is basically a set of address comparators. The user can program the comparators to watch for a specific address on the Program Address bus. When that address appears on the bus, the breakpoint triggers and halts the CPU.

While the CPU is running, CCStudio simply continues to poll the target for status until it sees a HALT. If a hardware breakpoint is encountered, CCStudio first checks why the target is halted. A hardware break status tells CCStudio that it has to do nothing in the way of checking the breakpoint table.

The advantage of hardware breakpoints is that they can be used in any type of memory. A hardware breakpoint works as well in RAM as in ROM. However, the limitation of hardware breakpoints is that there are a very small number of them. Typical TI targets usually only have 2 or 4 hardware breakpoints on a device.

Embedded breakpoints

An embedded breakpoint is a breakpoint that is implemented in target code. However, not all targets necessarily have embedded breakpoints. On the TMS320C55x™ DSP, the embedded breakpoint is implemented with the estop_1() assembly instruction. Embedded breakpoints are really software breakpoints, but they are implemented in the target application, and the debugger doesn’t have to do anything with the breakpoint table.

Embedded breakpoints only work if an emulator and debugger are connected to an application. This keeps code in the field from inadvertently halting if an embedded breakpoint has been implemented in code. If a debugger is not connected, the embedded breakpoint is handled as a nop.

** CCStudio will automatically take care of deciding between a hardware and a software breakpoint if the memory is mapped correctly. If no memory map is used, CCStudio will only try to set a software breakpoint. If the memory is not RAM, the breakpoint set will fail.

Click here for more information on using breakpoints, watchpoints, counters and event detectors for advanced capabilities like advanced event triggering.