Version 1 ColdFire Debug (CF1_DEBUG)
MCF51CN128 Reference Manual, Rev. 6
Freescale Semiconductor
20-53
20.4.1.7
Hardware Handshake Abort Procedure
The abort procedure is based on the SYNC command. To abort a command that has not responded with an
ACK pulse, the host controller generates a sync request (by driving BKGD low for at least 128 serial clock
cycles and then driving it high for one serial clock cycle as a speedup pulse). By detecting this long low
pulse on the BKGD pin, the target executes the sync protocol (see
), and
assumes that the pending command and therefore the related ACK pulse, are being aborted. Therefore,
after the sync protocol completes, the host is free to issue new BDC commands.
Because the host knows the target BDC clock frequency, the SYNC command does not need to consider
the lowest possible target frequency. In this case, the host could issue a SYNC close to the 128 serial clock
cycles length, providing a small overhead on the pulse length to assure the sync pulse is not misinterpreted
by the target.
It is important to notice that any issued BDC command that requires CPU execution is scheduled for
execution by the pipeline based on the dynamic state of the machine, provided the processor does not enter
any of the stop modes. If the host aborts a command by sending the sync pulse, it should then read
XCSR[CSTAT] after the sync response is issued by the target, checking for CSTAT cleared, before
attempting to send any new command that requires CPU execution. This prevents the new command from
being discarded at the debug/CPU interface, due to the pending command being executed by the CPU. Any
new command should be issued only after XCSR[CSTAT] is cleared.
There are multiple reasons that could cause a command to take too long to execute, measured in terms of
the serial communication rate: The BDC clock frequency could be much faster than the CPU clock
frequency, or the CPU could be accessing a slow memory, which would cause pipeline stall cycles to occur.
All commands referencing the CPU registers or memory require access to the processor’s local bus to
complete. If the processor is executing a tight loop contained within a single aligned longword, the
processor may never successfully grant the internal bus to the debug command. For example:
align
4
label1: nop
bra.b
label1
or
align
4
label2: bra.w
label2
These two examples of tight loops exhibit the BDM lockout behavior. If the loop spans across two
longwords, there are no issues, so the recommended construct is:
align
4
label3: bra.l
label3
The hardware handshake protocol is appropriate for these situations, but the host could also decide to use
the software handshake protocol instead. In this case, if XCSR[CSTAT] is 001, there is a BDC command
pending at the debug/CPU interface. The host controller should monitor XCSR[CSTAT] and wait until it
is 000 to be able to issue a new command that requires CPU execution. However, if the XCSR[CSTAT] is
1
xx
, the host should assume the last command failed to execute. To recover from this condition, the
following sequence is suggested:
1. Issue a SYNC command to reset the BDC communication channel.
2. The host issues a BDM NOP command.
