Filter
Top Products
99
1745D–ATARM–04-Nov-05
AT91M55800A
The same mechanism of Spurious Interrupt occurs if the ARM7TDMI reads the IVR (applica-
tion software or ICE) when there is no interrupt pending. This mechanism is also valid for the
FIQ interrupts.
Once the AIC enters the Spurious Interrupt management, it asserts neither the NIRQ nor the
NFIQ lines to the ARM7TDMI as long as the Spurious Interrupt is not acknowledged. There-
fore, it is mandatory for the Spurious Interrupt Service Routine to acknowledge the “Spurious”
behavior by writing to the AIC_EOICR (End of Interrupt) before returning to the interrupted
software. It also can perform other operation(s), e.g. trace possible undesirable behavior.
15.9 Protect Mode
The Protect Mode permits reading of the Interrupt Vector Register without performing the
associated automatic operations. This is necessary when working with a debug system.
When a Debug Monitor or an ICE reads the AIC User Interface, the IVR could be read. This
would have the following consequences in normal mode:
• If an enabled interrupt with a higher priority than the current one is pending, it would be
stacked.
• If there is no enabled pending interrupt, the spurious vector would be returned.
In either case, an End of Interrupt Command would be necessary to acknowledge and to
restore the context of the AIC. This operation is generally not performed by the debug system.
Hence the debug system would become strongly intrusive, and could cause the application to
enter an undesired state.
This is avoided by using Protect Mode.
The Protect Mode is enabled by setting the AIC bit in the SF Protect Mode Register.
When Protect Mode is enabled, the AIC performs interrupt stacking only when a write access
is performed on the AIC_IVR. Therefore, the Interrupt Service Routines must write (arbitrary
data) to the AIC_IVR just after reading it.
The new context of the AIC, including the value of the Interrupt Status Register (AIC_ISR), is
updated with the current interrupt only when IVR is written.
An AIC_IVR read on its own (e.g. by a debugger), modifies neither the AIC context nor the
AIC_ISR.
Extra AIC_IVR reads performed in between the read and the write can cause unpredictable
results. Therefore, it is strongly recommended not to set a breakpoint between these 2
actions, nor to stop the software.
The debug system must not write to the AIC_IVR as this would cause undesirable effects.