78
6174B–ATARM–07-Nov-05
AT91FR40162S Preliminary
The same mechanism of spurious interrupt occurs if the ARM7TDMI reads the IVR (application
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. Therefore,
it is mandatory for the Spurious Interrupt Service Routine to acknowledge the “spurious” behav-
ior 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.
13.10 Protect Mode
The Protect Mode permits reading of the Interrupt Vector Register without performing the associ-
ated 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 (see
16. ”SF: Special Function Registers”, on page 111
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 two
actions, nor to stop the software.
The debug system must not write to the AIC_IVR as this would cause undesirable effects.
The following table shows the main steps of an interrupt and the order in which they are per-
formed according to the mode:
