Interrupt Latency

Interrupt latency is the time between a hardware or peripheral interrupt request becoming pending and the processor starting the intended interrupt service response. It is a timing property of the whole execution environment, not only a processor datasheet number.

Interrupt latency matters in microcontrollers, real-time operating systems, motor drives, protection relays, robotics, medical devices, aircraft equipment and industrial interlocks. A device can have fast average execution and still fail if a critical interrupt waits behind masked interrupts, a long instruction sequence, a higher-priority ISR, bus stalls or scheduler-disabled sections.

Measurement Boundary

The start event should be stated explicitly. It may be a physical pin transition, peripheral flag, synchronized edge, bus message, timer compare or fault comparator output. Let that start time be:

and the first useful ISR action occur at:

The measured interrupt latency is:

If the measurement starts at a software timestamp after the interrupt has already been accepted, it may exclude the most important delay.

Latency Components

A useful first budget is:

where T_sync is input synchronization or peripheral flag delay, T_mask is time spent while interrupts are disabled, T_prio is delay from higher-priority handlers, T_entry is exception entry and context save, and T_stall covers memory, bus or pipeline stalls.

For a microcontroller without an operating system, masked-interrupt time is often the largest controllable term. For an RTOS, scheduler locks, critical sections, nested interrupt policy and driver behavior can dominate the observed latency.

Fault Response Budget

Interrupt latency is usually only the first part of a response path. If an interrupt must drive a fault output safe, the end-to-end response can be screened as:

where C_ISR is interrupt-service execution time, T_driver is output update time, T_actuator is hardware propagation time and T_allow is measurement or uncertainty allowance.

For deadline:

the margin is:

The fault response passes only when:

with values measured or bounded under representative stressed conditions.

Jitter and Worst Case

Interrupt latency is not a single stable number. Its variation contributes timing jitter:

For protection and control functions, the maximum or justified bound usually matters more than the mean:

This inequality is a reminder, not a statistical proof. A high percentile is still only evidence from the sampled conditions. Worst-case claims need hardware state, interrupt nesting, disabled regions, bus contention, cache behavior and code paths controlled.

Worked Example

A fault input must place an interlock output in the safe state within:

Stressed measurements give:

and allowance:

The response is:

The margin is:

The screen passes. If a future driver change increases masked-interrupt time by:

then:

and:

The response now fails even though the ISR code itself did not change.

Validation Evidence

Useful evidence includes logic-analyzer traces, GPIO timestamp pins, cycle counters, interrupt-disable duration logs, ISR entry and exit traces, nested interrupt records, priority configuration, bus-load stress, DMA activity, cache state, flash wait states, compiler options, clock configuration and firmware version.

The validation case should force representative worst conditions: communication bursts, background diagnostics, flash writes, critical sections, high-priority interrupts, power-state transitions and watchdog recovery paths. A clean bench test with no competing activity is not enough for a release claim.

Relationship To Neighbor Terms

Latency is the broad delay between two events. Interrupt latency is the specific delay from interrupt request to ISR response. Jitter is variation in that delay. Timestamp uncertainty may include interrupt latency when software timestamps are taken after handler entry. Data age can include interrupt latency when a sampled value waits before processing. Priority inversion, task starvation and lock convoys can indirectly increase interrupt response if they extend critical sections or mask preemption.

Watchdog timers detect missed progress after the fact. They do not prove interrupt-latency bounds unless the watchdog test is tied to the same timing path and safe-state requirement.

Common Mistakes

The most common mistake is quoting the best-case exception-entry time from a processor manual as the system interrupt latency. Another is measuring only average latency. A third is ignoring the longest interrupt-disabled interval introduced by drivers, logging, flash programming or communication stacks. A fourth is placing the timestamp inside the ISR and calling it input latency.

A strong interrupt-latency review states the start event, stop event, clock source, stress condition, priority policy, masked intervals, maximum observed or bounded value, response margin and regression gate.