Peripheral interrupt exceptions and system exceptions temporarily pause the
processor's normal execution flow so that the processor can be used to handle an
event.
The following can cause interruption of normal execution flow:
- Reset: The exception
model treats reset as a special form of exception. When either power-on or
warm reset is asserted, the operation of the processor stops, potentially at
any point in an instruction. When reset is deasserted, execution restarts
from the address provided by the reset entry in the vector table. Execution
restarts as privileged execution in Thread mode.
- Non-Maskable Interrupt
(NMI): A Non-Maskable Interrupt (NMI) can be signaled by a
peripheral or triggered by software. This is the highest priority exception
other than reset. It is permanently enabled and has a fixed priority of -2.
NMIs cannot be masked or preempted by any exception other than Reset.
- HardFault: 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. HardFaults have a fixed priority of -1,
meaning they have higher priority than any exception with configurable
priority.
- 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.
- BusFault: 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.
- UsageFault: A UsageFault is an exception that occurs because of a
fault related to instruction execution. This includes: an undefined
instruction, an illegal unaligned access, invalid state on instruction
execution, or an error on exception return. Software can configure the core
to report a UsageFault when: there is an unaligned address on word and
halfword memory access or division by zero.
- SVCall: A Supervisor Call (SVC) is an exception that is triggered by
the
SVC instruction.
- DebugMonitor: A DebugMonitor exception. If halting debug is disabled
and the debug monitor is enabled, a debug event causes a DebugMonitor
exception when the group priority of the DebugMonitor exception is greater
than the current execution priority.
- PendSV: PendSV is an asynchronous request for system-level
service.
- SysTick: A SysTick
exception is an exception the system timer generates when it reaches zero.
Software can also be configured to generate a SysTick exception.
- 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.
Properties of the different exception
types are detailed in Table 4-4.
Exception States
Each
exception source to the processor will be in one of the below states at any given point
in time:
- Inactive (not active, not
pending)
- Pending (waiting to be
serviced by the processor)
- Active (actively being
serviced by the processor but has not completed)
- Active and pending
(actively being serviced by the processor and there is a pending exception from
the same source)
Exception Prioritization, Entry, and Exit
Exceptions are prioritized by the
processor together with the Nested Vectored Interrupt Controller (NVIC).
Each exception has either a fixed priority (Reset, NMI,
HardFault) or a configurable priority (MemManage, BusFault, UsageFault,
DebugMonitor, SVCall, PendSV, SysTick,
peripheral IRQs). Exceptions with configurable priority can be disabled by
application software running in privileged mode. Exceptions with fixed priority
cannot be disabled.
The processor exception model supports preemption, tail-chaining, and late-arrival features to boost exception handling performance:
- In the preemption case, if an exception of higher priority is pending when an exception of lower priority is executing, the higher priority exception will preempt the ongoing handler
servicing the lower priority exception.
- In the tail-chaining case, if a valid-for-entry exception is pending at the time of completion of an exception handler, then the application context is not restored from the stack
and control is given immediately to the pending exception.
- In the late-arriving case, if a higher priority exception occurs during entry to a lower priority exception, the higher priority exception will be serviced first after the processor
state is saved to the stack. Once the higher priority exception handling is complete, the lower priority exception (which is still pending) is serviced based on the tail-chaining procedure.
An exception entry is issued if and when all of the following are true:
- An exception is in a pending state
- The priority of the pending exception is higher than the limit set by the exception mask register (PRIMASK)
- The processor is currently in either thread mode (not servicing an exception) or the newly pending exception is higher priority than the exception which is currently being serviced
(resulting in a preemption)
Processor exceptions are vectored. When an exception occurs, the current processor state is pushed onto the stack which was active at the time of the event, and execution is vectored to the
entry point address in the vector table corresponding to the exception which is to be processed.
If the exception is tail-chained to a previous handler which has completed, then there is no need to push any state to the stack and the interrupt service routine can be vectored to immediately.
Likewise, if the exception is higher priority than a previous exception which started entry but did not complete entry, then there is no need to save the context again (late arrival).
Upon completion of an exception handler, if there is no exception pending which needs to be handled then the processor will pop the state from the stack and restore the processor to the previous
state which it was in when the exception occurred.