Interrupt Controller (INTC)
MPC5510 Microcontroller Family Reference Manual, Rev. 1
9-4
Freescale Semiconductor
Preliminary
9.1.3
Modes of Operation
9.1.3.1
Normal Mode
In normal mode, the INTC has two handshaking modes with the processor: software vector mode and
hardware vector mode.
9.1.3.1.1
Software Vector Mode
In software vector mode, the interrupt exception handler software must read a register in the INTC to
obtain the vector associated with the interrupt request to the processor. The INTC will use software vector
mode for a given processor when its associated HVEN_PRC0 or HVEN_PRC1 bit in INTC_MCR is
negated. The hardware vector enable signal to processor 0 or processor 1 is driven as negated when its
associated HVEN_PRC
n
bit is negated. The vector is read from INC_IACKR_PRC0 or
INTC_IACKR_PRC1. Reading the INTC_IACKR_PRC
n
negates the interrupt request to the associated
processor. Even if a higher priority interrupt request arrived while waiting for this interrupt acknowledge,
the interrupt request to the processor will negate for at least one clock. The reading also pushes the PRI
value in INTC_CPR_PRC0 or INTC_CPR_PRC1 onto the associated LIFO and updates PRI in the
associated INTC_CPR_PRC
n
with the new priority.
Furthermore, the interrupt vector to the processor is driven as all 0s. The interrupt acknowledge signal
from the associated processor is ignored.
9.1.3.1.2
Hardware Vector Mode
In hardware vector mode, the hardware signals the interrupt vector from the INTC in conjunction with a
processor that can use that vector. This hardware causes the first instruction to be executed in handling the
interrupt request to the processor to be specific to that vector. Therefore, the interrupt exception handler is
specific to a peripheral or software settable interrupt request rather than being common to all of them. The
INTC uses hardware vector mode for a given processor when the associated HVEN_PRC0 or
HVEN_PRC1 bit in the INTC_MCR is asserted. The hardware vector enable signal to the associated
processor is driven as asserted. When the interrupt request to the associated processor asserts, the interrupt
vector signal is updated. The value of that interrupt vector is the unique vector associated with the
preempting peripheral or software settable interrupt request. The vector value matches the value of the
INTVEC_PRC0 field in the INTC_IACKR_PRC0 or the INTVEC_PRC1 field in the
INTC_IACKR_PRC1, depending on which processor was assigned to handle a given interrupt source.
The processor negates the interrupt request to the processor driven by the INTC by asserting the interrupt
acknowledge signal for one clock. Even if a higher priority interrupt request arrived while waiting for the
interrupt acknowledge, the interrupt request to the processor will negate for at least one clock.
The assertion of the interrupt acknowledge signal for a given processor pushes the associated PRI value in
the associated INTC_CPR_PRC
n
register onto the associated LIFO and updates the associated PRI in the
associated INTC_CPR_PRC
n
register with the new priority. This pushing of the PRI value onto the
associated LIFO and updating PRI in the associated INTC_CPR_PRC
n
does not occur when the associated
interrupt acknowledge signal asserts and INTC_SSCIR0_3–INTC_SSCIR4_7 is written at a time such that
the PRI value in the associated INTC_CPR_PRC
n
register would need to be pushed and the previously