
TMS320F243, TMS320F241
DSP CONTROLLERS
SPRS064D DECEMBER 1997 REVISED FEBRUARY 2006
35
POST OFFICE BOX 1443
HOUSTON, TEXAS 772511443
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 10, 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 not be re-enabled until the PIVR has
been read; otherwise, its contents can get overwritten by a subsequent interrupt.
NOTE: If an interrupt occurs during the execution of a CLRC INTM instruction, the device always completes CLRC INTM as well as the next
instruction before the pending interrupt is processed. This ensures that a return instruction that directly follows CLRC INTM will be
executed before an interrupt is processed. The return instruction will pop the previous return address off the top of the stack before the
new return address is pushed onto the stack. To allow the CPU to complete the return, interrupts are also blocked after a RET instruction
until at least one instruction at the return address is executed. Interrupts may be blocked for more than one instruction if the instruction
at the return address requires additional blocking for pipeline protection. If you want an ISR to occur within the current ISR rather than
after the current ISR, place the CLRC INTM instruction more than one instruction before the return (RET) instruction.