|ARM Technical Support Knowledge Articles|
When multiple exceptions are valid at the same time (i.e. more than one exception occurs during execution of an instruction), they are handled by the core (after completing the execution of the current instruction) according to the following priority scheme.
The Undefined Instruction and SWI cannot occur at the same time because they are both caused by an instruction entering the execution stage of the ARM instruction pipeline, so are mutually exclusive and thus they have the same priority.
Please note the difference between prioritization of exceptions (when multiple exceptions are valid at the same time), and the actual exception handler code. Exception handlers are themselves liable to interruption by exceptions, and so you must be careful that your exception handlers do not cause further exceptions. If they do, then you must take steps to avoid infinite "exception loops" whereby the link register gets corrupted and points to the entry point of the exception handler, thus giving you no way back to your application code.
The following describes each exception individually.
This is the highest priority interrupt and will be taken whenever it is signalled. The reset handler should initialize the system, and so there is no need to worry about state preservation etc. When reset is entered, IRQ and FIQ are disabled, and should not be enabled until all interrupt sources have been initialized to avoid spurious interrupts.
Reset is handled in Supervisor (SVC) mode. One of the very first things that a reset handler should do is to set up the stack pointers for all the other modes, in case of an exception occurring. Note that an exception is not likely to occur in the first few instructions of the reset handler, and indeed no code should be here to provoke such an event. It would be uncommon to have a SWI, an Undefined instruction, or a memory access occur when in the reset handler. It is reasonable to assume that your reset handler has been hand crafted to map on to your system exactly so as to avoid any exceptions taking place during the handling of reset.
The Data Abort has a higher priority than FIQ so that if both occur simultaneously the Data Abort mode is entered first, before immediately processing the FIQ exception. When the FIQ handler returns, it will return to the Data abort vector to handle the data abort.
A Data Abort exception disables IRQ, and so the data abort handler can not be interrupted by an IRQ unless IRQs have been specifically re-enabled.
Again, it is unlikely that a SWI or an Undef instruction will be executed as part of your handler (though it is possible, and the ARM will enter the relevant mode and deal with that exception, before returning to the abort handler). If you have a prefetch abort, caused by a read error in your abort handler (e.g. the handler was placed in an area of memory that is not currently paged in by the memory controller), then the abort handler will be re-entered. Thus your abort handler should not cause further aborts.
With the exception of Reset, this is the highest priority interrupt in terms of being handled. The FIQ exception will disable all IRQs and FIQs and the handler should be hand crafted to execute as quickly as possible. The same arguments as above apply to Aborts, SWIs etc interrupting the handler.
Similarly, when an FIQ is detected, the ARM core automatically disables further FIQs and IRQs (the F and I bits in the CPSR are set for the duration of the FIQ handler). This means that an FIQ handler will not be interrupted by another FIQ or an IRQ, unless you specifically re-enable FIQ or IRQ.
For IRQ and FIQ, the default behaviour of the ARM core is to avoid nested (reentrant) interrupts.
When an IRQ occurs, it will be dealt with provided an FIQ or data abort has not been raised at the same time. IRQs are disabled (and should only be re-enabled after this current source has been cleared*), and are dealt with in the usual manner. As above, the handler code execution is prone to exceptions as per any other code.
*Please note that you must be very careful when re-enabling IRQs inside your IRQ handler. See ADS Developer Guide (3MB PDF),"Handling Processor Exceptions" chapter or SDT 2.50 User Guide (7MB PDF), section 9.5.2 for information.
When an IRQ is detected, the ARM core automatically disables further IRQs (the I bit in the CPSR is set for the duration of the IRQ handler). This means that an IRQ handler will *not* be interrupted by another IRQ, unless you specifically re-enable IRQ.
If the instruction being executed was read in error, then it is flagged as causing a Prefetch Abort, but this exception is only taken if the instruction reaches the execution stage of the pipeline, and if none of the above exceptions have gone off at this point. IRQs will be disabled, but other exception sources are enabled, and can be taken during the exception handler if necessary.
If the instruction has been fetched (and decoded) successfully, and none of the other exceptions have been flagged, and this instruction is a SWI instruction, then the ARM will enter SVC mode, and go into the SWI handler code. If the SWI calls another SWI, then the LR must be stacked away before the "child" SWI is branched to. This can be done in C code in SDT 2.50 by compiling with the -fz option. See section 9.4.3 of the SDT 2.50 User Guide (7MB PDF) for information. In ADS, -fz is the default behaviour.
If the instruction has been fetched (and decoded) successfully, and none of the other exceptions have been flagged, and this instruction is an undefined instruction, then the ARM will enter Undef mode, and go into the undefined instruction handler code. The undefined instruction handler will generally either offer the instruction to any co-processors in the system, or flag an error in the system if none are present. SWI and Undefined Instruction have the same level of priority, as they cannot occur at the same time. The instruction being executed cannot be both a SWI and an Undefined instruction.
Article last edited on: 2008-09-09 15:47:36
Did you find this article helpful? Yes No
How can we improve this article?