EasyManua.ls Logo

ST SPC560P34 - Priority Ceiling Protocol

ST SPC560P34
936 pages
To Next Page IconTo Next Page
To Next Page IconTo Next Page
To Previous Page IconTo Previous Page
To Previous Page IconTo Previous Page
Loading...
Interrupt Controller (INTC) RM0046
236/936 Doc ID 16912 Rev 5
9.7.5 Priority ceiling protocol
Elevating priority
The PRI field in 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 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 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, 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 cannot 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.
Ensuring coherency
A scenario can cause non-coherent accesses to the shared resource. For example, ISR1
and ISR2 are both running on the same core and both share a resource. ISR1 has a lower
priority than ISR2. ISR1 is executing and writes to the INTC_CPR. The instruction following
this store is a store to a value in a shared coherent data block. Either immediately 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 stores will be 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.
X1
11
ISR108 completes. Interrupt
exception handler writes to
INTC_EOIR.
X0
12 RTOS continues execution. X 0
1. ISR108 executes for peripheral interrupt request 100 because the first eight ISRs are for software configurable interrupt
requests.
Table 76. 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)
ISR20
8
ISR30
8
ISR40
8
Interrupt
Exception
Handler

Table of Contents

Related product manuals