MCF548x Reference Manual, Rev. 3
8-52 Freescale Semiconductor
BDM instructions use the appropriate registers to load and configure breakpoints. As the system operates,
a breakpoint trigger generates the response defined in TDR.
PC breakpoints are treated in a precise manner: exception recognition and processing are initiated before
the excepting instruction is executed. All other breakpoint events are recognized on the processors local
bus, but are made pending to the processor and sampled like other interrupt conditions. As a result, these
interrupts are said to be imprecise.
In systems that tolerate the processor being halted, a BDM-entry can be used. With TDR[TRC] =01, a
breakpoint trigger causes the core to halt (PST = 0xF).
If the processor core cannot be halted, the debug interrupt can be used. With this configuration,
TDR[TRC] = 10, the breakpoint trigger becomes a debug interrupt to the processor, which is treated higher
than the nonmaskable level-7 interrupt request. As with all interrupts, it is made pending until the
processor reaches a sample point, which occurs once per instruction. Again, the hardware forces the PC
breakpoint to occur before the targeted instruction executes and is precise. This is possible because the PC
breakpoint is enabled when interrupt sampling occurs. For address and data breakpoints, reporting is
considered imprecise because several instructions may execute after the triggering address or data is
detected.
As soon as the debug interrupt is recognized, the processor aborts execution and initiates exception
processing. This event is signaled externally by the assertion of a unique PST value (PST = 0xD) for
multiple cycles. The core enters emulator mode when exception processing begins. After the standard
8-byte exception stack is created, the processor fetches a unique exception vector from the vector table.
Table 8-29 describes the two unique entries that distinguish PC breakpoints from other trigger events.
(Refer to the ColdFire Programmers Reference Manual.)
In the case of a two-level trigger, the last breakpoint event determines the exception vector; however, if
the second-level trigger is PC || Address {&& Data} (as shown in the last condition in the code example
in Section 8.4.11.1, “Resulting Set of Possible Trigger Combinations”), the vector taken is determined by
the first condition that occurs after the first-level trigger: vector 13 if PC occurs first or vector 12 if Address
{&& Data} occurs first. If both occur simultaneously, the non-PC-breakpoint debug interrupt is taken
(vector number 12).
Execution continues at the instruction address in the vector corresponding to the breakpoint triggered. The
debug interrupt handler can use supervisor instructions to save the necessary context such as the state of
all program-visible registers into a reserved memory area.
During a debug interrupt service routine, all normal interrupt requests are evaluated and sampled once per
instruction. If any exception occurs, the processor responds as follows:
1. It saves a copy of the current value of the emulator mode state bit and then exits emulator mode by
clearing the actual state.
2. Bit 1 of the fault status field (FS1) in the next exception stack frame is set to indicate the
processor was in emulator mode when the interrupt occurred. This corresponds to bit 17 of the
longword at the top of the system stack. See Section 3.8.1, “Exception Stack Frame Definition.”
3. It passes control to the appropriate exception handler.
Table 8-29. Exception Vector Assignments
Vector Number Vector Offset (Hex) Stacked Program Counter Assignment
12 0x030 Next Non-PC-breakpoint debug interrupt
13 0x034 Next PC-breakpoint debug interrupt