How long does an interrupt take on an ESP32-S3?

Charlie Napier · October 2026

At 240 MHz, 217 cycles (904 ns) from the interrupt firing to the handler's first instruction, 99.85% of the time. The worst I measured was 45.0 ms.

20,000,000 interrupts across 23 configurations, each the baseline with one change. Dot: median. Ticks: 99th and 99.9th percentile. Ring: worst observed. Log scale.

Findings

  1. A flash write stalls handlers stored in flash, on both cores. Worst 45.0 ms; the same handler in RAM: 6.5 µs.
  2. Same priority waits, higher priority doesn't. Beside a 10 µs handler, the 99th percentile is 11 µs at level 1 and 1.2 µs at level 3.
  3. Wi-Fi's interrupt lives on core 0. Worst 52 µs on core 0, 3.1 µs on core 1 (3.1 µs without Wi-Fi).
  4. A handler in flash is free until it's evicted from cache. Then it typically costs 1.9 µs to 3.9 µs more.

Method

The core's compare timer fires at a cycle count the firmware chooses, and the handler's first instruction reads the cycle counter. The difference is the latency in CPU cycles, with no external equipment. Interrupts arrive at random 20–60 µs intervals, 1,000,000 per configuration.

A load that masks interrupts for known windows predicts the delays it should add; 20 of 20 checks match within 95% intervals.

Limits

One board, one ESP-IDF version. "Worst" is worst observed, not a guaranteed bound. Percentiles count interrupts, which understates long stalls. The fixed delay between the timer match and the interrupt is not measured.