Development System Serial Logic - Motorola CPU32 Reference Manual

Hide thumbs Also See for CPU32:
Table of Contents

Advertisement

A user can use the state change on DSO to signal hardware that the next serial trans-
fer may begin. A time-out of sufficient length to trap error conditions that do not change
the state of DSO should also be incorporated into the design. Hardware interlocks in
the CPU prevent result data from corrupting serial transfers in progress.

7.2.7.2 Development System Serial Logic

The development system, as the master of the serial data link, must supply the serial
clock. However, normal and BDM operations could interact if the clock generator is not
properly designed.
Breakpoint requests are made by asserting BKPT to the low state in either of two
ways. The primary method is to assert BKPT during a single bus cycle for which an
exception is desired. Another method is to assert BKPT, then continue to assert it until
the CPU32 responds by asserting FREEZE. This method is useful for forcing a transi-
tion into BDM when the bus is not being monitored. Each of these methods requires a
slightly different serial logic design to avoid spurious serial clocks.
Figure 7-7 represents the timing required for asserting BKPT during a single bus cy-
cle.
SHIFT_CLK
FORCE_BGND
BKPT_TAG
BKPT
FREEZE
Figure 7-8 depicts the timing of the BKPT/FREEZE method. In both cases, the serial
clock is left high after the final shift of each transfer. This technique eliminates the pos-
sibility of accidentally tagging the prefetch initiated at the conclusion of a BDM session.
As mentioned previously, all timing within the CPU is derived from the rising edge of
the clock; the falling edge is effectively ignored.
SHIFT_CLK
FORCE_BGND
BKPT_TAG
BKPT
FREEZE
MOTOROLA
7-10
Figure 7-7 BKPT Timing for Single Bus Cycle
Figure 7-8 BKPT Timing for Forcing BDM
DEVELOPMENT SUPPORT
CPU32
REFERENCE MANUAL

Advertisement

Table of Contents
loading

Table of Contents