Freescale Semiconductor MPC5565, Reference Manual

Page: 405 / 1153

Interrupt Controller (INTC)
MPC5565 Microcontroller Reference Manual, Rev. 1.0
10-32 Freescale Semiconductor
10.5.5 Priority Ceiling Protocol
10.5.5.1 Elevating Priority
The PRI field in INTC current priority register (INTC_CPR) is elevated in the OSEK PCP to the ceiling
of all of the priorities of the ISRs that share a resource. This protocol therefore allows coherent accesses
of the ISRs to that shared resource.
For example, ISR1 has a priority of 1, ISR2 has a priority of 2, and ISR3 has a priority of 3. They all share
the same resource. Before ISR1 or ISR2 can access that resource, they must raise the PRI value in
INTC_CPR to 3, the ceiling of all of the ISR priorities. After they release the resource, the PRI value in
INTC_CPR can be lowered. If they do not raise their priority, then ISR2 can preempt ISR1, and ISR3 can
preempt ISR1 or ISR2, possibly corrupting the shared resource. Another possible failure mechanism is
deadlock if the higher priority ISR needs the lower priority ISR to release the resource before it can
continue, but the lower priority ISR can not release the resource until the higher priority ISR completes
and execution returns to the lower priority ISR.
Using the PCP instead of disabling processor recognition of all interrupts eliminates the time when
accessing a shared resource that all higher priority interrupts are blocked. For example, while ISR3 cannot
preempt ISR1 while it is accessing the shared resource, all of the ISRs with a priority higher than 3 can
preempt ISR1.
10.5.5.2 Ensuring Coherency
A scenario can exist that can cause non-coherent accesses to the shared resource. As an example, ISR1 and
ISR2 both share a resource. ISR1 has a lower priority than ISR2. ISR1 is executing, and it writes to the
INTC_CPR. The instruction following this store is a store to a value in a shared coherent data block. Either
just before or at the same time as the first store, the INTC asserts the interrupt request to the processor
because the peripheral interrupt request for ISR2 has asserted. As the processor is responding to the
interrupt request from the INTC, and as it is aborting transactions and flushing its pipeline, it is possible
that both of these stores are executed. ISR2 thereby thinks that it can access the data block coherently, but
the data block has been corrupted.
10 ISR308 completes. Interrupt exception
handler writes to INTC_EOIR. X 1
11 ISR108 completes. Interrupt exception
handler writes to INTC_EOIR. X 0
12 RTOS continues execution. X 0
1
ISR108 executes for peripheral interrupt request 100 because the first eight ISRs are for software settable interrupt
requests.
Table 10-10. Order of ISR Execution Example (continued)
Step Step Description
Code Executing At End of Step
PRI in
INTC_CPR
at End of
Step
RTOS ISR108
1
ISR208 ISR308 ISR408
Interrupt
Exception
Handler