mcf51ac256a Freescale Semiconductor, Inc, mcf51ac256a Datasheet - Page 547

no-image

mcf51ac256a

Manufacturer Part Number
mcf51ac256a
Description
Mcf51ac Flexis
Manufacturer
Freescale Semiconductor, Inc
Datasheet

Available stocks

Company
Part Number
Manufacturer
Quantity
Price
Part Number:
mcf51ac256aCFGE
Manufacturer:
FREESCALE
Quantity:
2 400
Part Number:
mcf51ac256aCFGE
Manufacturer:
FREESCALE
Quantity:
2 400
Part Number:
mcf51ac256aCFUE
Manufacturer:
Freescale Semiconductor
Quantity:
10 000
Part Number:
mcf51ac256aCLKE
Manufacturer:
FREESCALE
Quantity:
1 500
Part Number:
mcf51ac256aCLKE
Manufacturer:
Freescale Semiconductor
Quantity:
10 000
Part Number:
mcf51ac256aCPUE
Manufacturer:
MURATA
Quantity:
1 000
22.4.1.7
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
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:
label1: nop
or
label2: bra.w
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:
label3: bra.l
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
1xx, the host should assume the last command failed to execute. To recover from this condition, the
following sequence is suggested:
Freescale Semiconductor
1. Issue a SYNC command to reset the BDC communication channel.
2. The host issues a BDM NOP command.
align
bra.b
align
align
Hardware Handshake Abort Procedure
MCF51AC256 ColdFire Integrated Microcontroller Reference Manual, Rev. 5
4
label1
4
label2
4
label3
Section 22.4.1.5.1,
Version 1 ColdFire Debug (CF1_DEBUG)
“SYNC”), and
22-55

Related parts for mcf51ac256a