Why You Should Never Call Delay in ISR
ISR runs at high priority.
Delay holds the CPU at highest priority.
1. Key Reasons
Blocks lower priority execution
Increases worst-case interrupt latency
Can deadlock the system
Breaks real-time guarantees
- Other interrupts and main code are entirely paused.
Increases worst-case interrupt latency
- Time-critical events (like motor control or high-speed data) may be permanently missed.
Can deadlock the system
- A delay cannot complete if its time base (e.g., a timer interrupt) is blocked by the very ISR that called it.
Breaks real-time guarantees
- An ISR must be bounded and predictable; adding an arbitrary delay makes its execution time unbounded.
2. Real Failure Example
A delay called inside a high-priority ISR can invisibly block UART handling on a lower
priority.
If the UART hardware FIFO fills up while the CPU is stuck in the delay loop, it causes an RX overrun.
The result? Lost data, dropped packets, and broken communication protocols—even though the localized logic appears superficially correct.
If the UART hardware FIFO fills up while the CPU is stuck in the delay loop, it causes an RX overrun.
The result? Lost data, dropped packets, and broken communication protocols—even though the localized logic appears superficially correct.
3. Correct Pattern
Inside the ISR:
Do all waiting outside. The main loop (or an RTOS task) should handle the delay asynchronously.
- clear the interrupt flag
- capture minimal state (read a register, set a boolean flag)
- signal the main context to process the event
Do all waiting outside. The main loop (or an RTOS task) should handle the delay asynchronously.