English
Language : 

MC68331 Datasheet, PDF (41/84 Pages) Motorola, Inc – User’s Manual
Freescale Semiconductor, Inc.
3.8.2 Interrupt Processing Summary
A summary of the interrupt processing sequence follows. When the sequence begins, a valid interrupt
service request has been detected and is pending.
A. The CPU finishes higher priority exception processing or reaches an instruction boundary.
B. Processor state is stacked. The contents of the status register and program counter are saved.
C. The interrupt acknowledge cycle begins:
1. FC[2:0] are driven to %111 (CPU space) encoding.
2. The address bus is driven as follows. ADDR[23:20] = %1111; ADDR[19:16] = %1111,
which indicates that the cycle is an interrupt acknowledge CPU space cycle; ADDR[15:4]
= %111111111111; ADDR[3:1] = the level of the interrupt request being acknowledged;
and ADDR0 = %1.
3. Request priority level is latched into the IP field in the status register from the address bus.
D. Modules or external peripherals that have requested interrupt service decode the request level
in ADDR[3:1]. If the request level of at least one interrupting module or device is the same as
the value in ADDR[3:1], interrupt arbitration contention takes place. When there is no conten-
tion, the spurious interrupt monitor asserts BERR, and a spurious interrupt exception is pro-
cessed.
E. After arbitration, the interrupt acknowledge cycle can be completed in one of three ways:
1. The dominant interrupt source supplies a vector number and DSACK signals appropriate
to the access. The CPU32 acquires the vector number.
2. The AVEC signal is asserted (the signal can be asserted by the dominant interrupt source
or the pin can be tied low), and the CPU32 generates an autovector number corresponding
to interrupt priority.
3. The bus monitor asserts BERR and the CPU32 generates the spurious interrupt vector
number.
F. The vector number is converted to a vector address.
G. The content of the vector address is loaded into the PC, and the processor transfers control to
the exception handler routine.
3.9 Factory Test Block
The test submodule supports scan-based testing of the various MCU modules. It is integrated into the
SIM to support production testing.
Test submodule registers are intended for Motorola use. Register names and addresses are provided
to indicate that these addresses are occupied.
SIMTR — System Integration Module Test Register
$YFFA02
SIMTRE — System Integration Module Test Register (E Clock)
$YFFA08
TSTMSRA — Master Shift Register A
$YFFA30
TSTMSRB — Master Shift Register B
$YFFA32
TSTSC — Test Module Shift Count
$YFFA34
TSTRC — Test Module Repetition Count
$YFFA36
CREG — Test Module Control Register
$YFFA38
DREG — Test Module Distributed Register
$YFFA3A
MC68331TS/D
For More Information On This Product,
41
Go to: www.freescale.com