Interrupt Latency Calculator

This tool estimates the total time elapsed between the assertion of an interrupt request (IRQ) and the execution of the first instruction in the corresponding ISR. It accounts for hardware synchronization delays, stack push overhead, pipeline flushes, NVIC latency, and nested interrupt handling — delivering a worst-case cycle-accurate latency value in nanoseconds and microseconds.

Use it during early architecture selection and ISR optimization—especially for real-time systems like motor control, sensor fusion, or communication stacks (e.g., CAN, USB). It helps validate whether your chosen MCU and ISR implementation meet hard timing deadlines before hardware prototyping or firmware development begins.

This represents the number of CPU registers automatically saved by hardware upon interrupt entry (e.g., Cortex-M saves R0–R3, R12, LR, PC, xPSR = 8 registers). Consult your MCU’s ARM Architecture Reference Manual or vendor datasheet; values typically range from 6–12 depending on core variant and configuration (e.g., FPU context adds more).

“ISR Entry Cycles” covers fixed overhead after vector fetch: pipeline stall, register save, and branch to ISR (often 10–16 cycles on Cortex-M). “NVIC Sync Cycles” models the asynchronous synchronization delay between the peripheral’s interrupt signal and the NVIC’s clock domain—typically 2–3 cycles for most ARM-based MCUs, per ARM documentation.

Each nested interrupt adds full entry/exit overhead (stack push, vector fetch, sync delays) before resuming the lower-priority ISR. Nesting occurs when a higher-priority interrupt arrives while an ISR is executing. Set “Nesting Levels” to the maximum depth expected in your priority scheme—e.g., 2 for a system with three priority tiers.

While ISR body execution doesn’t affect *initial* latency, it impacts *subsequent* interrupt response times—especially for lower-priority interrupts blocked by ongoing high-priority ISRs. Typical values range from 0.5 µs (GPIO toggle) to >50 µs (SPI DMA setup); include worst-case measured or simulated duration for accurate preemption analysis.

Verify CPU clock scaling (e.g., running at 72 MHz vs. 4 MHz), confirm actual NVIC synchronization behavior in your chip’s errata, and double-check whether your compiler uses tail-chaining or lazy stacking (which reduce effective latency). Also ensure “Stack Push (regs)” matches your core’s actual auto-saved registers—not debug or FPU registers unless explicitly enabled.

Not directly—the underlying assumptions (e.g., NVIC sync, auto-register push count, vector table layout) are ARM Cortex-M specific. However, the conceptual breakdown (sync + fetch + save + branch) applies broadly. For other architectures, manually adjust parameters using vendor reference manuals—but results won’t be cycle-accurate without architecture-specific modeling.

Higher clock frequencies reduce *time per cycle*, so latency in nanoseconds often improves—but absolute cycle counts (e.g., NVIC sync, stack pushes) remain constant. However, some operations (e.g., flash wait states, bus contention) may add variable cycles at high clocks, potentially increasing *effective* latency. Always validate with real measurements.

Yes—interrupt latency is a critical input to WCET analysis for real-time scheduling. A high interrupt latency can delay task preemption or increase jitter in time-triggered systems. Use this calculator alongside static WCET tools to bound end-to-end response times, especially in safety-critical applications compliant with ISO 26262 or IEC 61508.