The Cortex-M3 processor has advanced interrupt handling and wake-up features that allow it to efficiently manage events and minimize power consumption. This article provides an in-depth explanation of these capabilities.
Introduction to Interrupts
An interrupt is a signal to the processor that an event has occurred that requires immediate attention. When the Cortex-M3 receives an interrupt, it pauses normal program execution, handles the event, and then resumes execution. This allows the processor to efficiently respond to many types of events.
Some examples of sources that can generate interrupts include:
- Hardware peripherals like timers, UARTs, ADCs
- External input pins
- Software interrupts triggered by code
Without interrupts, the processor would have to continuously poll hardware to check if events have occurred. This would be inefficient.
Cortex-M3 Interrupt Controllers
The Cortex-M3 has two interrupt controllers that manage interrupts from on-chip peripherals and off-chip sources:
- Nested Vectored Interrupt Controller (NVIC) – handles exceptions and interrupts from on-chip peripherals
- System Control Space (SCS) – handles NMI, faults, and interrupts from external sources
Nested Vectored Interrupt Controller
The NVIC manages interrupts from up to 240 on-chip peripheral sources. It supports nested interrupts, meaning interrupts can preempt lower priority interrupts. This allows higher priority events to be serviced quickly.
Key features of the NVIC include:
- Nested interrupt support
- Up to 240 interrupt sources
- 16 programmable priority levels for interrupts
- Programmable interrupt vectors
System Control Space
The SCS handles exceptions not managed by the NVIC, including:
- NMI (Non Maskable Interrupt) – highest priority interrupt
- Hard faults – from execution errors
- SVCall – supervisor call interrupts
- PendSV – pends interrupt handling to next lowest priority
- SYSTICK – from system timer
- External interrupts – from off-chip sources
By splitting interrupt management across two controllers, the Cortex-M3 achieves low latency exception handling.
Cortex-M3 Interrupt Handling Process
Here are the steps involved when an interrupt occurs on the Cortex-M3:
- An peripheral event or external interrupt signal is received
- The appropriate interrupt controller (NVIC or SCS) receives the request
- Interrupt controller checks if higher priority interrupts are active
- Interrupt controller signals to processor core that interrupt is pending
- At next instruction boundary, core stores state and jumps to the interrupt vector
- Interrupt service routine (ISR) executes to handle event
- ISR signals completion with special return instruction
- Core restores state and resumes normal execution
This optimized sequence minimizes interrupt latency while keeping context switching efficient. The controllers handle prioritization, while the core rapidly executes handlers.
Cortex-M3 Interrupt Latency
Interrupt latency is the time from an event occurring to its interrupt handler starting. The Cortex-M3 achieves extremely low interrupt latency of 15 clock cycles. Here’s a breakdown:
- 3 cycles to recognize interrupt and freeze pipeline
- 2 cycles to store stacked registers on interrupt entry
- 6 cycles to fetch the vector and jump to handler
- 4 cycles to stack return address and registers on handler entry
This nanosecond-scale latency allows rapid real-time response to events. Prioritized exception handling also minimizes latency by preventing lower priority interrupts from delaying critical ones.
Configuring Interrupt Priority Levels
A key strength of the Cortex-M3’s NVIC is support for assigning priority levels to interrupts. There are 16 priority levels, with 0 being highest priority.
Higher priority interrupts can preempt lower priority ones. This helps critical interrupts meet their real-time requirements by preventing long delays.
Priority configuration is done through NVIC registers. Bits 7:4 of the Interrupt Priority Register (IPR) sets the priority level of the associated interrupt. Lower number values correspond to higher priorities.
Interrupt Vector Table
The interrupt vector table contains the addresses of the interrupt service routines that handle each type of interrupt. When an interrupt occurs, the processor uses the table to find and jump to the associated handler routine.
For the Cortex-M3, the interrupt vector table resides in code memory and contains up to 240 entries. The NVIC controller accesses it to direct execution to the right ISR.
By default, the vector table starts at memory address 0x00000000. But it can be relocated by programming the Vector Table Offset Register (VTOR) in the SCS.
Writing Interrupt Service Routines
Interrupt service routines (ISRs) are software functions that handle interrupts. When writing ISRs for the Cortex-M3, developers should follow these guidelines:
- Save context by pushing registers and CPU status to stack
- Keep ISR code short, fast, and atomic
- Clear pending interrupt at peripheral before exiting
- Restore context before returning from ISR
- Return using special interrupt return instructions
Keeping ISRs lean and restoring state properly allows rapid resumption of main program execution after interrupt handling completes.
Wake-up interrupts play a special role on the Cortex-M3. They can trigger the processor to wake up from low power sleep modes.
When the Cortex-M3 enters sleep, it disables interrupts globally. But wake-up interrupts remain active to transition the system back to active mode when key events occur.
Examples of sources used for wake-up interrupts include:
- External GPIO pins
- Real-time clock alarms
- Watchdog timers
By using wake-up interrupts appropriately, Cortex-M3 based systems can achieve ultra low power sleep while still being able to respond to important events.
Reducing Power with Wait For Interrupt Instruction
The Cortex-M3 provides a “Wait For Interrupt” (WFI) instruction to put the processor into a low power idle state until the next interrupt occurs.
In this mode, the core clock is disabled but peripherals remain active. Once an interrupt happens, execution resumes.
By strategically using WFI when the processor is idle, significant power savings can be achieved. WFI combined with disabling unused peripherals can maximize efficiency.
Cortex-M3 Interrupt Debugging
Debugging interrupt issues on Cortex-M3 systems requires tools that provide visibility into:
- Interrupt state – enabled/pending
- Interrupt vector reads
- Stack unwinding to identify ISR caller
- Processor state at time of interrupt
Tool options include debug probes, logic analyzers, and oscilloscopes with trace buffers. This aids in tracking down problems like interruptSources, vestigial interrupts, and overly long ISRs.
Optimizing Interrupt Performance
Here are some tips for optimizing interrupt performance on Cortex-M3 designs:
- Prioritize interrupts appropriately – critical first
- Minimize ISR length and don’t call long subroutines
- Avoid processing in ISRs that can be handled later
- Use WFI instruction when idle waiting for interrupts
- Disable unused peripherals to reduce power
- Place vector table in fast tightly coupled memory
Properly managing priorities, minimizing ISR overhead, and using wait modes can help achieve responsive and efficient embedded designs.
The Cortex-M3 interrupt architecture with NVIC and SCS controllers enables rapid handling of peripheral, system, and external events with minimal latency. Configurable priorities, vector table flexibility, and wake-up support allow for powerful applications. Using WFI and disabling unused peripherals further optimizes power efficiency. With strong interrupt capabilities, the Cortex-M3 delivers the real-time responsiveness needed in many embedded systems.
Please reach out with any other questions! We have a large repository of tutorials and guides on ARM Cortex-M topics.