Exceptions and Interrupts Control
110
SPRUHE8E – October 2012 – Revised November 2019
Copyright © 2012–2019, Texas Instruments Incorporated
System Control and Interrupts
4. If both conditions in 3a and 3b are true, then an interrupt request is sent to the CPU and the
acknowledge bit is again set (PIEACKx = 1). The PIEACKx bit will remain set until you clear it to
indicate that additional interrupts from the group can be sent from the PIE to the CPU.
5. The CPU interrupt flag bit is set (CPU IFRx = 1) to indicate a pending interrupt x at the CPU level.
6. If the CPU interrupt is enabled (CPU IER bit x = 1, or DBGIER bit x = 1) AND the global interrupt mask
is clear (INTM = 0) then the CPU will service the INTx.
7. The CPU recognizes the interrupt and performs the automatic context save, clears the IER bit, sets
INTM, and clears EALLOW. All of the steps that the CPU takes in order to prepare to service the
interrupt are documented in the
TMS320C28x DSP CPU and Instruction Set Reference Guide
(literature number
).
8. The CPU will then request the appropriate vector from the PIE.
9. For multiplexed interrupts, the PIE module uses the current value in the PIEIERx and PIEIFRx
registers to decode which vector address should be used. There are two possible cases:
a. The vector for the highest priority interrupt within the group that is both enabled in the PIEIERx
register and flagged as pending in the PIEIFRx is fetched and used as the branch address. In this
manner if an even higher priority enabled interrupt was flagged after Step 7, it will be serviced first.
b. If no flagged interrupts within the group are enabled, then the PIE will respond with the vector for
the highest priority interrupt within that group. That is the branch address used for INTx.1. This
behavior corresponds to the 28x TRAP or INT instructions.
NOTE:
Because the PIEIERx register is used to determine which vector will be used for the branch,
you must take care when clearing bits within the PIEIERx register. The proper procedure for
clearing bits within a PIEIERx register is described and failure to follow these steps can
result in changes occurring to the PIEIERx register after an interrupt has been passed to the
CPU. In this case, the PIE will respond as if a TRAP or INT instruction was executed unless
there are other interrupts both pending and enabled.
At this point, the PIEIFRx.y bit is cleared and the CPU branches to the vector of the interrupt fetched from
the PIE
1.5.4.3.4 The PIE Vector Table
consists of a 256 x 16 SARAM block that can also be used as RAM (in data space only) if the
PIE block is not in use. The PIE vector table contents are undefined on reset. The CPU fixes interrupt
priority for INT1 to INT12. The PIE controls priority for each group of eight interrupts. For example, if
INT1.1 should occur simultaneously with INT8.1, both interrupts are presented to the CPU simultaneously
by the PIE block, and the CPU services INT1.1 first. If INT1.1 should occur simultaneously with INT1.8,
then INT1.1 is sent to the CPU first and then INT1.8 follows. Interrupt prioritization is performed during the
vector fetch portion of the interrupt processing.
When the PIE is enabled, a TRAP #1 through TRAP #12 or an INTR INT1 to INTR INT12 instruction
transfers program control to the interrupt service routine corresponding to the first vector within the PIE
group. For example: TRAP #1 fetches the vector from INT1.1, TRAP #2 fetches the vector from INT2.1
and so forth. Similarly an OR IFR, #16-bit operation causes the vector to be fetched from INTR1.1 to
INTR12.1 locations, if the respective interrupt flag is set. All other TRAP, INTR, OR IFR,#16-bit operations
fetch the vector from the respective table location. The vector table is EALLOW protected.
Out of the 96 possible MUXed interrupts in
, 66 interrupts are currently used. The remaining
interrupts are reserved for future devices. These reserved interrupts can be used as software interrupts if
they are enabled at the PIEIFRx level, provided none of the interrupts within the group is being used by a
peripheral. Otherwise, interrupts coming from peripherals may be lost by accidentally clearing their flags
when modifying the PIEIFR.
To summarize, there are two safe cases when the reserved interrupts can be used as software interrupts:
•
No peripheral within the group is asserting interrupts.
•
No peripheral interrupts are assigned to the group. For example, PIE group 11 and 12 do not have any
peripherals attached to them.