mcf51jf128 Freescale Semiconductor, Inc, mcf51jf128 Datasheet - Page 1313

• Manufacturer Part Number: mcf51jf128
• Description: Mcf51jf128 Reference Manual
• Manufacturer: Freescale Semiconductor, Inc

Chapter 50 Debug
The ACK handshake protocol does not support nested ACK pulses. If a BDC command
is not acknowledged by an ACK pulse, the host first needs to abort the pending command
before issuing a new BDC command. When the CPU enters a stop mode at about the
same time the host issues a command that requires CPU execution, the target discards the
incoming command. Therefore, the command is not acknowledged by the target, meaning
that the ACK pulse is not issued in this case. After a certain time, the host could decide to
abort the ACK protocol to allow a new command. Therefore, the protocol provides a
mechanism where a command (a pending ACK) could be aborted. Unlike a regular BDC
command, the ACK pulse does not provide a timeout. In the case of a STOP instruction
where the ACK is prevented from being issued, it would remain pending indefinitely if
not aborted. See the handshake abort procedure described in
Hardware Handshake Abort
Procedure.
50.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 SYNC), 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
MCF51JF128 Reference Manual, Rev. 2, 03/2011
Preliminary
Freescale Semiconductor, Inc.
1313