Interrupt latency calculator
Result
Worst-case latency-
Worst-case round trip (entry + exit)-
Best case (tail-chained)-
Worst-case latency (cycles)-
Interrupt Latency Calculator
Estimate worst-case and best-case interrupt response time from your clock speed, exception entry/exit cycle counts, extra ISR overhead, and any interrupt-disable time elsewhere in your system.
ARM Cortex-M reference figures
These figures come from the Armv7-M architecture documentation and apply to Cortex-M3, M4, and M7 cores accessing zero wait-state memory. Real systems often add flash wait states at higher clock speeds, which increases actual latency beyond these baseline numbers.
| Core | Exception entry | Tail-chaining | Exception exit |
|---|---|---|---|
| Cortex-M3 / M4 / M7 (ARMv7-M) | 12 cycles | 6 cycles | 10 cycles |
Tail-chaining applies when a new pending interrupt is serviced immediately after an ISR returns, skipping the stack push since it is already in place. Late-arriving higher-priority interrupts are serviced during the entry phase of a lower-priority one and then tail-chain into it, keeping worst-case latency bounded.
What interrupt latency actually measures
Interrupt latency is the time from an interrupt being asserted to the first instruction of its handler executing. On Cortex-M cores this is dominated by a fixed number of cycles to automatically stack registers and fetch the vector, which is why ARM documents it as a small, deterministic cycle count rather than a variable software delay.
Why worst case matters more than typical case
A real-time system has to meet its deadline every time, not on average, so the number that matters is the worst case: the longest any critical section elsewhere in the code might disable interrupts, plus any extra software overhead your ISR or RTOS adds before your handler's first line of application code actually runs.
Flash wait states and other real-world additions
The Armv7-M entry/exit cycle counts assume zero wait-state memory access. Many microcontrollers insert flash wait states above a certain clock speed, and code running from flash rather than RAM can add further delay. If your device's datasheet specifies wait states at your target clock, fold that time into the interrupt-disable field to get a more realistic worst case.
FAQ
Is 12 cycles the interrupt latency for every ARM Cortex-M chip?
No. 12 cycles is the Armv7-M architectural figure for Cortex-M3, M4, and M7 cores with zero wait-state memory. Actual silicon can add cycles for flash wait states, bus fabric, or cache behavior, so treat it as a baseline to build a realistic budget from, not a guarantee for any specific chip.
What is tail-chaining and why does it lower latency?
Tail-chaining happens when another interrupt is already pending as the current ISR returns. The processor skips the exception return and re-entry stacking since the registers are already in the right place, cutting the cost from around 12 cycles down to about 6.
What should I put in the interrupt-disable time field?
The longest duration anywhere in your codebase that interrupts are masked, such as inside a critical section protecting a shared buffer. This is usually the biggest contributor to worst-case latency in real applications, far more than the fixed hardware entry cost.
Does a higher clock speed always reduce interrupt latency in real time?
For the fixed-cycle hardware entry cost, yes, a faster clock reduces the equivalent time. But total worst-case latency also includes disable time and software overhead, which may be specified in microseconds rather than cycles and might not shrink proportionally.
Does this calculator model a specific microcontroller?
No. It computes latency from cycle counts and clock speed that you provide, with the ARMv7-M architectural figures pre-filled as a starting point. Enter your own measured or datasheet values for an accurate result on your specific hardware.