Interrupt latency in Arm Cortex-M series microcontrollers refers to the time it takes for an interrupt request to be serviced after it is asserted. It is an important metric that impacts real-time response in embedded systems.
Interrupt Handling in Cortex-M
Arm Cortex-M microcontrollers have an interrupt-driven architecture. When an event like an external interrupt or exception occurs, the processor stops executing the main program and starts executing an Interrupt Service Routine (ISR) to handle the event. After the ISR finishes, normal program execution resumes.
The Cortex-M interrupt handling mechanism involves these key steps:
- An interrupt request is asserted by a peripheral or exception.
- The processor finishes executing the current instruction.
- The context of the main program is saved to the stack.
- The interrupt vector table is used to branch to the corresponding ISR.
- The ISR executes to handle the interrupt.
- The main program context is restored from the stack.
- Program execution resumes after the interrupted instruction.
Sources of Interrupt Latency
There are several sources of delay that contribute to the overall interrupt latency in Cortex-M:
Interrupt Detection Delay
It takes a few clock cycles from when the interrupt signal is asserted to when it is detected by the core’s interrupt controller. This depends on synchronization logic and interrupt controller design.
Instruction Completion Delay
The processor has to complete executing the current instruction before handling the interrupt. Usually Cortex-M cores have a 3-5 stage pipeline, so this could take up to 5 clock cycles for longer instructions.
Context Saving Delay
The complete context of the main program needs to be saved from processor registers to the stack when an exception occurs. This normally takes 12 clock cycles in Cortex-M as there are 12 core registers to save.
Interrupt Entry Delay
The processor needs to fetch the address of the ISR handler from the interrupt vector table. This takes a few clock cycles.
First Instruction Fetch Delay
The first instruction of the ISR needs to be fetched from memory before it can be executed. Cortex-M cores have a Von Neumann architecture with unified instruction and data buses, so this competes with data accesses.
Measuring Interrupt Latency
Interrupt latency can be measured using the following methods:
Logic Analyzer
A logic analyzer connected to the interrupt signal and processor clock can precisely measure the time from interrupt assertion to the start of ISR execution.
Oscilloscope
An oscilloscope can also measure interrupt latency from the time the interrupt signal is asserted to when the ISR changes the logic level of an GPIO pin.
Timer Capture
A free running timer can be used to capture the time when the interrupt occurs and when the ISR starts executing. Their difference gives the interrupt latency.
In-situ Measurement
Software counters can directly measure the number of cycles elapsed between the interrupt assertion and the execution of the first ISR instruction.
Factors Affecting Interrupt Latency
There are several microarchitectural factors that affect interrupt latency in Cortex-M processors:
Interrupt Priorities
Higher priority interrupts have lower latency as they can preempt lower priority ones. Nested interrupts increase latency due to additional context saving.
Processor Pipeline Depth
Deeper pipelines lead to longer instruction completion delays. Cortex-M7 has a 5-stage pipeline vs 3 in Cortex-M3/M4/M0.
Clock Frequency
Faster clock speeds reduce absolute interrupt latency in clock cycle counts, but not the number of steps involved.
Memory Architecture
The Von Neumann architecture adds latency due to instruction fetches competing with data accesses. Cortex-M7 has separate instruction and data buses.
Interrupt Vector Table Location
Locating the vector table in faster memory like TCM RAM reduces first instruction fetch delay compared to external flash.
Compiler Optimizations
Compiler optimizations like function inlining of ISRs can reduce call/return overhead and improve latency.
Typical Interrupt Latency Figures
Here are some typical interrupt latency figures for different Cortex-M cores:
- Cortex-M0 – 12 to 20 clock cycles
- Cortex-M3 – 12 to 16 clock cycles
- Cortex-M4 – 12 to 16 clock cycles
- Cortex-M7 – 14 to 20 clock cycles
Exact latencies depend on the microcontroller, clock speed, interrupts enabled, compiler optimizations etc.
Design Considerations for Low Latency
Here are some design guidelines to reduce interrupt latency in a Cortex-M based system:
- Use the simplest Cortex-M core that meets performance requirements
- Run the core at the highest clock frequency possible
- Minimize lower priority interrupts when possible
- Use RAM based vector table for fast ISR entry
- Optimize ISR code to minimize execution time
- Reduce OS overhead for hard real-time tasks
- Use compiler optimizations like function inlining
- Use latency analysis tools to identify optimization opportunities
Conclusion
Interrupt latency is a key metric that impacts responsiveness in real-time embedded systems using Arm Cortex-M cores. A combination of hardware, software and compiler techniques can help optimize interrupt latency. Typical latency ranges from 12 to 20 clock cycles for most Cortex-M variants.
