You copied the Doc URL to your clipboard.

AArch64 Exception and Interrupt Handling

Exceptions are conditions or system events that require some action by privileged software (an exception handler) to ensure smooth functioning of the system. They cause an interruption in the flow of execution.


The term interrupt is sometimes used as a synonym for exception. In ARM terminology, certain types of asynchronous exceptions are referred to as interrupts.

One way to distinguish between the two is that an exception is an event (other than branch or jump instructions) that causes the normal sequential execution of instructions to be modified. An interrupt is an exception that is not caused directly by program execution. Usually, hardware external to the processor core signals an interrupt, such as a button being pressed.

There is an exception handler that is associated with each exception type. When the exception has been handled, privileged software prepares the core to resume whatever it was doing before taking the exception.

Commonly, interrupt is used to mean interrupt signal. On ARM A-profile processors, that means an IRQ or FIQ interrupt signal. The ARM architecture splits exceptions into two groups, synchronous and asynchronous. The synchronous exception types can have many causes but they are handled in a similar way. The asynchronous exception type is subdivided into three interrupt types, IRQ, FIQ, and SError (System Error).

The following types of action can cause an exception:


Aborts can be generated either on failed instruction fetches (Instruction Aborts) or failed data accesses (Data Aborts). They can come from the external memory system giving an error response on a memory access (indicating perhaps that the specified address does not correspond to real memory in the system).

Alternatively, the Memory Management Unit (MMU) of the core generates the abort. An OS can use MMU aborts to allocate memory to applications dynamically.

An instruction that cannot be fetched causes an abort. The Instruction Abort exception is taken only if the core then tries to execute it. A Data Abort exception is caused by a load or store instruction and happens after the data read or write has been attempted.

An abort is described as being synchronous if it is generated by direct execution of instructions and the return address indicates the instruction which caused it.

Otherwise, an abort is described as asynchronous.

In AArch64, synchronous aborts cause a Synchronous exception. Asynchronous aborts cause an SError interrupt exception.


Reset is treated as a special case because it has its own vector that always targets the highest implemented Exception level. This vector uses an IMPLEMENTATION DEFINED address which is typically set by configuration input signals.

The address can be read from the Reset Vector Base Address Register RVBAR_ELn, where n is the number of the highest implemented Exception level.

All cores have a reset input and take the reset exception after they have been reset. It is the highest priority exception and cannot be masked. This exception is used to execute code on the core to initialize it, after the system has powered up.

Exception generating instructions

Execution of these instructions can generate exceptions. They are typically executed to request a service from software that runs at a higher privilege level:

The Supervisor Call (SVC) instruction enables User mode programs to request an OS service.

The Hypervisor Call (HVC) instruction enables the guest OS to request hypervisor services.

The Secure monitor Call (SMC) instruction enables the Normal world to request Secure world services.


There are three types of interrupts, IRQ, FIQ and SError. IRQ and FIQ are general purpose compared to SError, which is associated specifically with external asynchronous Data Aborts. So typically, the term 'interrupts' refers only to IRQ and FIQ.

FIQ is higher priority than IRQ. Both of these interrupts are typically associated with individual input pins for each core. External hardware asserts an interrupt request line and the corresponding exception type is raised when the current instruction finishes executing (although some instructions, those that can load multiple values, can be interrupted), assuming that the interrupt is not disabled.

On almost all systems, various interrupt sources are connected using an interrupt controller. The interrupt controller arbitrates and prioritizes interrupts, and in turn, provides a serialized single signal that is then connected to the FIQ or IRQ signal of the core.

Because IRQ and FIQ interrupts are not directly related to the software running on the core at any given time, they are classified as asynchronous exceptions.

Was this page helpful? Yes No