TMS320F243FN datasheet(32/116 Pages) TI

32 / 116 page

TMS320F243, TMS320F241

DSP CONTROLLERS

SPRS064B – DECEMBER 1997 – REVISED FEBRUARY 1999

POST OFFICE BOX 1443

• HOUSTON, TEXAS 77251–1443

interrupt vectors (continued)

The peripheral interrupt vectors (PIVs) are stored in a table in the peripheral interrupt expansion controller. They

can either be hard-coded (potentially ROM), or register locations (RAM), which are programmed by the reset

service routine. The PIVs are all implemented as hard-coded values on the ’F243/’F241 devices, according to

Table 10, column 5.

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.

software hierarchy

There are two levels of interrupt service routine hierarchy: the General Interrupt Service Routine (GISR), and

the Event-Specific Interrupt Service Routine (SISR). There is one GISR for each maskable prioritized request

(INT) to the CPU. This can perform necessary context saves before it fetches the PIV from the PIVR. This PIV

value is used to generate a branch to the SISR. There is one SISR for every interrupt request from a peripheral

to the interrupt controller. The SISR performs the actions required in response to the peripheral interrupt

request.

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 are automatically

disabled when any of the INT1 – INT6 interrupts are serviced. If the PIVR is not read before interrupts are

re-enabled, 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

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

interrupt flag is still set, the PIRQ will immediately be asserted. The interrupt flag (IF) in the peripheral

future interrupts will not be recognized.

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.

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.

TMS320F243FN Datasheet(PDF) 32 Page - Texas Instruments

TMS320F243FN Datasheet(HTML) 32 Page - Texas Instruments

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 ...More

Datasheet Download

Link URL