The exception types are:
- Reset: The exception model treats reset as a special form of exception.
When reset is asserted, the operation of the processor stops, potentially at any
point in an instruction. When either power-on or warm reset is de-asserted,
execution restarts from the address provided by the reset entry in the ROM
vector table. Execution restarts as privileged execution in Secure state in
Thread mode. This exception is not banked between security states.
- NMI: A Non-Maskable
Interrupt (NMI) can be signaled by a peripheral or triggered by software. It is
permanently enabled and has a fixed priority of -2. NMI can only be preempted by
reset and, when it is Non-secure, by a Secure HardFault. If SCB.AIRCR[13]
BFHFNMINS = 0, then the NMI is Secure. If SCB.AIRCR[13] BFHFNMINS = 1, then NMI
is Non-secure.
- HardFault: A HardFault is
an exception that occurs because of an error during normal or exception
processing. HardFaults have a fixed priority of at least -1, meaning they have
higher priority than any exception with configurable priority. This exception is
not banked between security states
If SCB.AIRCR[13] BFHFNMINS =
0, HardFault handles all faults that are unable to preempt the current
execution. The HardFault handler is always Secure.
If SCB.AIRCR[13] BFHFNMINS =
1, HardFault handles faults that target Non-secure state that are unable to
preempt the current execution.
HardFaults that specifically
target the Secure state when SCB.AIRCR[13] BFHFNMINS is set to 1 have a
priority of -3 to ensure they can preempt any execution. A Secure HardFault
at priority -3 is only enabled when SCB.AIRCR[13] BFHFNMINS is set to 1.
Secure HardFault handles Secure faults that are unable to preempt current
execution.
- MemManage: A MemManage fault is an exception that occurs because of a
memory protection violation, compared to the MPU or the fixed memory protection
constraints, for both instruction and data memory transactions. This fault is
always used to abort instruction accesses to Execute Never (XN) memory regions.
This exception is banked between security states.
- BusFault: A BusFault is an
exception that occurs because of a memory-related violation for an instruction
or data memory transaction. This might be from an error that is detected on a
bus in the memory system. This exception is not banked between security states.
If SCB.AIRCR[13] BFHFNMINS
= 0, BusFaults target the Secure state.
If SCB.AIRCR[13] BFHFNMINS =
1, BusFaults target the Non-secure state.
- SecureFault: 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 Secure fault 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.
- SVCall: 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. This exception is banked between
security states.
- DebugMonitor: A DebugMonitor exception. If halting debug is disabled and
the debug monitor is enabled, a debug event causes a debug monitor exception
when the group priority of the debug monitor exception is greater than the
current execution priority.
- PendSV: PendSV is an asynchronous request for system-level service. In an
OS environment, use PendSV for context switching when no other exception is
active. This exception is banked between Security states.
- SysTick: 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 a system tick. This
exception is banked between Security states.
- Interrupt (IRQ): An interrupt, 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. This exception is not banked between security
states. Secure code can assign each interrupt to Secure or Non-secure state. By
default, all interrupts are assigned to Secure state.
For an asynchronous exception, other than reset, the processor can execute extra
instructions between the moment the exception is triggered and the moment the
processor enters the exception handler. Privileged software can disable the
exceptions that have configurable priority, as shown in the table above. An
exception that targets Secure state cannot be disabled by Non-secure code.
Table 5-1 Exception
Types
| Exception Number |
IRQ Number |
Exception Type |
Priority |
Vector Address |
Activation |
| 1 |
- |
Reset |
-4, the highest |
0x00000004 |
Asynchronous |
| 2 |
-14 |
NMI |
-2 |
0x00000008 |
Asynchronous |
| 3 |
-13 |
Secure HardFault when SCB:AIRCR.BF HFNMINS is
1 |
-3 |
0x0000000C |
Synchronous |
| Secure HardFault when SCB:AIRCR.BF HFNMINS is
0 |
-1 |
| HardFault |
-1 |
| 4 |
-12 |
MemManage |
Configurable |
0x00000010 |
Synchronous |
| 5 |
-11 |
BusFault |
Configurable |
0x00000014 |
Synchronous |
| 6 |
-10 |
UsageFault |
Configurable |
0x00000018 |
Synchronous |
| 7 |
-9 |
SecureFault |
Configurable |
0x0000001C |
Synchronous |
| 8-10 |
- |
Reserved |
- |
- |
- |
| 11 |
-5 |
SVCall |
Configurable |
0x0000002C |
Synchronous |
| 12 |
-4 |
DebugMonitor |
Configurable |
0x00000030 |
Synchronous |
| 13 |
- |
Reserved |
- |
- |
- |
| 14 |
-2 |
PendSV |
Configurable |
0x00000038 |
Asynchronous |
| 15 |
-1 |
SysTick |
Configurable |
0x0000003C |
Asynchronous |
| 16 and above |
0 and above |
Interrupt (IRQ) |
Configurable |
0x00000040 and above (increasing in steps of
4) |
Asynchronous |
Note: To simplify the software layer, the CMSIS only uses IRQ
numbers. It uses negative values for exceptions other than interrupts. The IPSR
returns the Exception number.