Interrupt Controller (INTC)
MPC5510 Microcontroller Family Reference Manual, Rev. 1
9-24
Freescale Semiconductor
Preliminary
value in INTC_CPR_PRC
n
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.
9.5.5.2
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_PRC
n
. 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.
OSEK uses the GetResource and ReleaseResource system services to manage access to a shared resource.
To prevent corruption of a coherent data block, modifications to PRI in INTC_CPR_PRC
n
can be made
by those system services with the following code sequences. Processor recognition of interrupts must be
enabled before executing the GetResource code sequence.
GetResource:
raise PRI
mbar
isync
ReleaseResource:
mbar
lower PRI
9.5.6
Selecting Priorities According to Request Rates and Deadlines
The selection of the priorities for the ISRs can be made using rate monotonic scheduling (RMS) or a
superset of it, deadline monotonic scheduling (DMS). In RMS, the ISRs which have higher request rates
have higher priorities. In DMS, if the deadline is before the next time the ISR is requested, then the ISR is
assigned a priority according to the time from the request for the ISR to the deadline, not from the time of
the request for the ISR to the next request for it.
For example, ISR1 executes every 100
μ
s, ISR2 executes every 200
μ
s, and ISR3 executes every 300
μ
s.
ISR1 has a higher priority than ISR2 which has a higher priority than ISR3; however, if ISR3 has a
deadline of 150
μ
s, then it has a higher priority than ISR2.
The INTC has 16 priorities, which may be less than the number of ISRs. In this case, the ISRs should be
grouped with other ISRs that have similar deadlines. For example, a priority could be allocated for every
