Background-Debug Mode (BDM)
MOTOROLA
Debug Support
19-7
19.3.1
CPU HALT
Although many BDM operations can occur in parallel with CPU operation, unrestricted BDM operation
requires the CPU to be halted. A number of sources can cause the CPU to halt, including the following as
shown in order of priority:
1. The occurrence of the catastrophic fault-on-fault condition automatically halts the processor.
2. The occurrence of a hardware breakpoint can be configured to generate a pending halt condition in
a manner similar to the assertion of the BKPT signal. In all cases, the assertion of this type of halt is
first made pending in the processor. Next, the processor samples for pending halt and interrupt
conditions once per instruction. Once the pending condition is asserted, the processor halts
3. The execution of the HALT ColdFire instruction immediately suspends execution. By default this is
a supervisor instruction and attempted execution while in user mode generates a privilege violation
exception. A User Halt Enable (UHE) control bit is provided in the Configuration/Status Register
4. The assertion of the
BKPT input pin is treated as a pseudo-interrupt. For example, the halt
condition is made pending until the processor core samples for halts/interrupts. The processor
samples for these conditions once during the execution of each instruction. If there is a pending
halt condition at the sample time, the processor suspends execution and enters the halted state.
After the system reset signal is negated, the processor waits for 16 clock cycles before beginning reset
exception processing. If the
BKPT input pin is asserted within the first eight cycles after RSTI is negated,
the processor enters the halt state, signaling that halt status, ($F), on the PST outputs. While in this state,
all resources accessible through the debug module can be referenced. This is the only opportunity to force
the ColdFire processor into emulation mode using the EMU bit in the configuration/status register (CSR).
Once the system initialization is complete, the processor response to a BDM GO command is dependent
on the set of BDM commands performed while breakpointed. Specifically, if the processor’s
was loaded, then the GO command simply causes the processor to exit the halted state and pass control
to the instruction address contained in the PC.
Note: In this case, the normal reset exception processing is bypassed. Conversely, if the
PC register was not loaded, then the GO command causes the processor to exit
the halted state and continue with reset exception processing.
ColdFire also handles a special case of the assertion of BKPT while the processor is stopped by execution
of the STOP instruction. For this case, the processor exits the stopped mode and enters the halted state.
Once halted, all BDM commands may be exercised. When the processor is restarted, it continues with the
execution of the next sequential instruction. For example, the instruction following the STOP opcode.
The halt source is indicated in
CSR[27:24]. For simultaneous halt conditions, the highest priority source is
indicated.
19.3.2
BDM SERIAL INTERFACE
Once the CPU is halted and the halt status reflected on the PST outputs, the development system may
send unrestricted commands to the debug module. The debug module implements a synchronous protocol
using a three-pin interface: development serial clock (DSCLK), development serial input (DSI), and
development serial output (DSO). The development system serves as the serial communication channel
F
re
e
sc
a
le
S
e
m
ic
o
n
d
u
c
to
r,
I
Freescale Semiconductor, Inc.
For More Information On This Product,
Go to: www.freescale.com
n
c
..
.