Types of exception
The exception model for the ARMv8-M architecture provides various types of exception. Each exception is handled in turn before returning to the original application. When multiple exceptions occur simultaneously, they are handled in a fixed order of priority.
The following types of exception exist:
Reset is invoked on power-up or a Warm reset. The ARMv8-M exception model treats reset as a special form of exception. It is permanently enabled. When reset occurs, the operation of the processor stops. This could be at any point in instruction execution. When the processor restarts, execution restarts from the address that is provided by the reset entry in the vector table. Execution restarts as privileged execution in Thread mode.
A Non-maskable Interrupt (NMI) is signaled by a peripheral or triggered by software. This is the highest priority exception other than reset. It is permanently enabled. NMIs cannot be:
- Masked or prevented from activation by any other exception.
- Preempted by any exception other than Reset.
A HardFault is an exception that occurs because of an error during exception processing, or because an exception cannot be managed by any other exception mechanism.
In the ARMv8-M architecture a Security violation in a Non-secure NMI handler would trigger and be preempted by a Secure HardFault exception.
A MemManage fault is an exception that occurs because of a memory protection-related fault. The MPU or the fixed memory protection constraints determines this fault, for both instruction and data memory transactions. This fault is always used to abort instruction accesses to Execute Never (XN) memory regions.
A BusFault is an exception that occurs because of a memory-related fault for an instruction or data memory transaction. This might be from an error that is detected on a bus in the memory system.
A UsageFault is an exception that occurs because of a fault that is related to instruction execution. This includes:
- An UNDEFINED instruction.
- An illegal unaligned access.
- Invalid state on instruction execution.
- An error on exception return.
The following can cause a UsageFault when the core is configured to report them:
- An unaligned address on word and halfword memory access.
- Division by zero.
A Supervisor Call (
SVC) is an exception that is triggered by the
SVC instruction. In an OS environment, applications can use
SVC instructions to access OS kernel functions and device drivers.
PendSV is an interrupt-driven request for system-level service. In an OS environment, use PendSV for context switching when no other exception is active.
The SVCall and PendSV exceptions are banked between Secure and Non-secure states. When the SVC instruction is executed:
- If the processor is in Secure state, the
SVCexception handling sequence fetches the exception vector from the Secure vector table and executes the SVCall handler in Secure state.
- If the processor is in Non-secure state, the
SVCexception handling sequence fetches the exception vector from the Non-secure vector table and executes the SVCall handler in Non-secure state.
Similarly, the PendSVSet and PendSVClr bit in the Interrupt Control and State Register
(ICSR) is banked. Secure software can also trigger a Non-secure PendSV using the
Non-secure alias of ICSR (
The priority level registers for SVC and PendSV are also banked between Secure and Non-secure states.
A SysTick exception is an exception the system timer generates when it reaches zero. Software can also generate a SysTick exception. In an OS environment, the processor can use this exception as system tick.
SysTick can exist in neither, either or both (banked) Security states.
An interrupt request, or IRQ, is an exception signaled by a peripheral, or generated by a software request. All interrupts are asynchronous to instruction execution. In the system, peripherals use interrupts to communicate with the processor.
Interrupts default to Secure state but can be retargeted to Non-secure state by Secure software.
For ARMv8-M architecture with Main Extension the architecture defines an extra SecureFault exception. This exception is triggered by the various security checks that are performed. It is triggered, for example, when jumping from Non-secure code to an address in Secure code that is not marked as a valid entry point. Most systems choose to treat a SecureFault as a terminal condition that either halts or restarts the system. Any other handling of the SecureFault must be checked carefully to make sure that it does not inadvertently introduce a security vulnerability.
SecureFaults always target the Secure state.