![](http://datasheet.mmic.net.cn/260000/TMS320C242FNA_datasheet_15975173/TMS320C242FNA_21.png)
TMS320C242
DSP CONTROLLER
SPRS063B – DECEMBER 1997 – REVISED DECEMBER 1999
21
POST OFFICE BOX 1443
HOUSTON, TEXAS 77251–1443
interrupt vectors (continued)
phantom interrupt vector
The phantom interrupt vector is an interrupt system integrity feature. If the CPU’s interrupt acknowledge is
asserted, but there is no associated peripheral interrupt request asserted, the phantom vector is used so that
this fault is handled in a controlled manner. One way the phantom interrupt vector could be required is if the CPU
executes a software interrupt instruction with an argument corresponding to a peripheral interrupt (usually
INT1–INT6). The other way would be if a peripheral made an interrupt request, but its interrupt request flag was
cleared by software before the CPU acknowledged the request. In this case, there may be no peripheral
interrupt request asserted to the interrupt controller, so the controller would not know which peripheral interrupt
vector to load into the PIVR. In these situations, the phantom interrupt vector is loaded into the PIVR in lieu of
a peripheral interrupt vector.
nonmaskable interrupts
The PIE controller does not support expansion of nonmaskable interrupts. This is because an ISR must read
the peripheral interrupt vector from the PIVR before interrupts are re-enabled. All interrupts (INT1 – INT6) are
automatically disabled when the CPU branches to each of the respective vectors. If the PIVR is not read before
interrupts are re-enabled (INTM = 0), another interrupt would be acknowledged and a new peripheral interrupt
vector would be loaded into the PIVR, causing permanent loss of the original peripheral interrupt vector. Since,
by their very nature, nonmaskable interrupts cannot be masked, they cannot be included in the interrupt
expansion controller because they could cause the loss of peripheral interrupt vectors.
interrupt operation sequence
1.
An interrupt-generating event occurs in a peripheral. The interrupt flag (IF) bit corresponding to that event
is set in a register in the peripheral. If the appropriate interrupt enable (IE) bit is set, the peripheral generates
an interrupt request to the PIE controller by asserting its PIRQ. If the interrupt is not enabled in the peripheral
register, the IF remains set until cleared by software. If the interrupt is enabled at a later time, and the
interrupt flag is still set, the PIRQ will immediately be asserted. The interrupt flag (IF) in the peripheral
register should be cleared by software only. If the IF bit is not cleared after the respective interrupt service,
future interrupts will not be recognized.
2.
If no unacknowledged CPU interrupt request of the same priority level has previously been sent, the
peripheral interrupt request, PIRQ, causes the PIE controller to generate a CPU interrupt request pulse.
This pulse is active low for 2 CPU clock cycles.
3.
The interrupt request to the CPU sets the corresponding flag in the CPU’s interrupt flag register, IFR. If the
CPU interrupt has been enabled (by setting the appropriate bit in the CPU’s Interrupt Mask Register, IMR),
the CPU stops what it is doing. It then masks all other maskable interrupts by setting the INTM bit, saves
some context, clears the respective IFR bit, and starts executing the General Interrupt Service Routine
(GISR) for that interrupt priority level. The CPU generates an interrupt acknowledge automatically, which
is accompanied by a value on the Program Address Bus (PAB) that corresponds to the interrupt priority level
being responded to. These values are shown in Table 5, column 3.
4.
The PIE controller decodes the PAB value and generates an internal peripheral interrupt acknowledge to
load the PIV into the PIVR. The appropriate peripheral interrupt vector (or the phantom interrupt vector),
is referenced from the table stored in the PIE controller.
5.
When the GISR has completed any necessary context saves, it reads the PIVR and uses the interrupt vector
as a target (or to generate a target) for a branch to the Event-Specific Interrupt Service Routine (SISR) for
the interrupt event which occurred in the peripheral. Interrupts must notbe re-enabled until the PIVR has
been read; otherwise, its contents can get overwritten by a subsequent interrupt.
A