Breakpoint Types and Resources

The breakpoint types and the resources required are listed in the following table.

 

Hardware (Debug Register) Breakpoints

Hardware breakpoints rely on processor-specific registers to recognize events, such as instruction execution or data reads/writes at a memory or I/O address. Hardware breakpoints cause the processor to stop immediately; there is little or no "slide" for non-execution breaks (i.e., breaks occurring on Data Access, Data Write, and I/O Access break on types). Pre-fetched but unexecuted instructions do not cause the processor to stop. The code location of an execution breakpoint can be in ROM. Each processor has a maximum of four hardware breakpoints. Data values are not part of a breakpoint condition.

Hardware breakpoints can be set in the Add Breakpoint or Edit Breakpoint dialog boxes or, for execution breaks (only), from the Code window.

Note: Hardware breakpoints do not accept physical addresses.

Software Breakpoints

Software breakpoints are implemented by placing a special instruction (such as a software interrupt) in memory. Software breakpoints cause the processor to stop immediately (there is no "slide"). Software breakpoints do not stop the processor on unexecuted pre-fetches.

Software breakpoints are limited to execution breaks. The location of the instruction to be executed must be writable (i.e., located in RAM). Code at the breakpoint location cannot be loaded or modified on the fly. Care must be taken to insure breakpoints are set at the first byte of an instruction.

After the Go command is issued, the instruction at the breakpoint location is replaced with a special instruction. When the processor stops, the original instruction is written back to the breakpoint location.

Note: If the processor writes a different (new) value to the breakpoint location before executing there, the breakpoint is ineffective until the processor is stopped and restarted with another Go command.

Emulator Breakpoints

The Reset breakpoint uses a signal on the debug port to detect entry and exit from the reset state. When the exit from reset state is detected the emulator will halt the target.

The Init breakpoint stops the target when the processor encounters an Init event.

The BKPT IN breakpoint utilizes an input signal on the emulator itself to allow stopping the target via an external trigger signal. There may be a delay, or “slide”, from the BKPT IN signal edge to the time the target is stopped by the emulator.

Processor Breakpoints

SMM Entry and SMM Exit breakpoints stop the target when the processor is entering or exiting System Management Mode, respectively.

The Power Cycle breakpoint stops the target when it detects the target has gone from the power off state to the power on state.

The Machine Check breakpoint stops the target when a Machine Check exception occurs on the target.