Interrupt Latency Calculator — worst-case response time

Worst-case interrupt response from clock speed, cycle counts and priority nesting.

Example: Worst-case interrupt latency is 7.278 µs — 524 cycles at 72 MHz, mostly higher-priority interrupts.

Inputs

Core clock(Hz)

Core

Longest critical section(cycles)

The longest run with interrupts masked, anywhere in your code or a library.

Higher-priority interrupts

How many could fire and run before yours.

Cycles each(cycles)

Deadline (optional)(s)

The latest your handler can start and still meet its requirement.

Result

Worst-case latency

7.278 µs

Total cycles: 524
Hardware entry: 166.7 ns
Critical section: 2.778 µs
Higher-priority ISRs: 4.333 µs
Best case: 166.7 ns

higher-priority interrupts dominate the worst case. Either shorten those handlers or reconsider the priority assignment; a long high-priority ISR delays everything below it.
Hardware entry on Cortex-M3/M4 is 12 cycles, and tail-chaining between back-to-back interrupts costs 6. Those are fixed; everything else in this figure is under your control.
This is a worst case, not a typical one. Measure it too — toggle a GPIO at the interrupt source and again at the top of the handler, then look at the widest gap on a scope over a long run.

Where the time goes

Contributor	Cycles	Time	Share
Hardware entry	12	166.7 ns	2.3%
Critical section	200	2.778 µs	38.2%
Higher-priority ISRs	312	4.333 µs	59.5%

Check it against real silicon

Chiprun runs your firmware on an emulated microcontroller and hands back the UART output, so you can confirm these numbers rather than trusting them.

Chiprun docs

Formula

latency = entry + longest critical section + higher-priority ISR time

Worked example

Worst-case interrupt latency is 7.278 µs — 524 cycles at 72 MHz, mostly higher-priority interrupts.

entry latency (fixed by the core)
12 cycles on Cortex-M3/M4
166.7 ns
blocking = critical section + n × (ISR + tail-chain)
200 + 2 × (150 + 6)
512 cycles
latency = (entry + blocking) / f_clk
524 / 72 MHz
7.278 µs

Frequently asked questions

What actually determines interrupt latency?

Rarely the core. Hardware entry is 12 cycles on a Cortex-M3 — well under a microsecond at any sensible clock. What dominates is blocking: the longest region with interrupts disabled, plus any higher-priority handler that runs first.

How do I reduce interrupt latency?

Find and shorten the longest critical section. It is often inside a library — a malloc implementation, a driver, an RTOS call — rather than your own code. After that, shorten high-priority handlers, deferring work to a task or a lower-priority interrupt.

What is tail-chaining?

When one interrupt is pending as another finishes, Cortex-M cores skip the stack pop and push and go straight to the next handler. It saves roughly half the entry cost, which is why back-to-back interrupts are cheaper than two isolated ones.

Why is my measured latency worse than this calculation?

On cached cores, usually a cache miss — the vector table or handler code not being resident adds cycles that no static calculation captures. Flash wait states and bus contention with DMA do the same. Measure with a GPIO toggle and a scope over a long run.

Related tools

Timer & Prescaler Calculator

Every valid prescaler and reload pair for a target frequency on AVR, STM32, PIC and RP2040 — ranked by error, with C you can paste.

Firmware

Stack Size Estimator

Estimate worst-case stack depth from call nesting, locals and interrupt frames.

Firmware

Watchdog Timeout Calculator

Prescaler and reload values for a target watchdog period, with the achievable timeout range.

Firmware

Clock Tree & PLL Configurator

Solve PLL M/N/P/Q dividers for a target system clock from your crystal, respecting each stage's legal range.

Firmware

Hex, Binary & Decimal Converter

Convert between hex, binary, decimal, octal and ASCII, with width-aware bit grids and endianness swapping.

Firmware

Bitwise Operation Calculator

AND, OR, XOR, NOT and shifts with a live bit grid so you can see exactly which bits moved.

Firmware