Interrupts and Exception Handling Questions

Covers the principles and practical design of interrupt driven systems and exception handling in embedded and systems software. Topics include interrupt sources and controllers, interrupt vectors and vector tables, priority levels and nested interrupts, interrupt context versus thread context, and interrupt latency. Discuss how to design safe and efficient interrupt service routines including keeping handlers short, avoiding blocking operations, preserving and restoring context and registers, reentrancy considerations, and techniques for communicating with the main application safely such as deferred work, task notification, queues, and flags. Includes exception and fault handling concepts such as fault types, stack frames at exception entry, recovery and reset strategies, and debug and diagnostic approaches. Also compares polling versus interrupt driven approaches, explains hardware and software interrupt prioritization strategies, and covers integration with real time operating systems and race condition mitigation for shared data access.

HardTechnical

68 practiced

Explain how MPU (Memory Protection Unit) or MMU interacts with exception handling and faults in embedded systems. Discuss privileged vs unprivileged exceptions, how MPU faults generate handlers (MemManage/BusFault), stack protections, and how you would use MPU regions to harden a system and isolate faulty code paths.

Sample Answer

**Brief overview: MPU vs MMU and exception interaction**

MPU: light-weight, region-based access control (no paging). MMU: virtual memory, page tables. Both enforce access permissions and trigger exceptions on violations; MPU faults are synchronous and generate CPU fault handlers.

**Privileged vs unprivileged exceptions**

- Synchronous faults (memory access violations) are handled at the current privilege level but the handler typically runs privileged.- Some architectures (ARM Cortex-M) support configurable exception stacking and return to unprivileged thread mode (e.g., using CONTROL register or PendSV).- System exceptions (HardFault, MemManage, BusFault, UsageFault) are privileged handlers; unprivileged code cannot directly mask or modify fault handlers.

**How MPU faults generate handlers**

- On Cortex-M: MPU violation -> MemManage (if enabled) or escalates to HardFault if MemManage disabled. Bus faults occur for bus errors (e.g., abort). Handlers receive stacked context (R0–R3, R12, LR, PC, xPSR) so you can inspect PC/calling context to identify offending instruction.- Handler responsibilities: log faulting address (MPU fault address registers), fault status, clear flags, decide recovery or terminate thread.

**Stack protections**

- Create an MPU region for each thread stack with guard region (no-access) at one end to trap overflow/underflow as MemManage faults.- Use separate privileged-only stack for exceptions (MSP on Cortex-M) to prevent PSP-based unprivileged tasks corrupting exception stack.

**Using MPU regions to harden and isolate**

- Least privilege: mark code regions execute-only where supported; data regions RW-only; mark sensitive peripherals or MMIO as privileged-only.- Per-thread regions: create per-task data regions and revoke access on context switch (load MPU registers with per-task map).- Fault isolation: place untrusted or updateable modules in isolated regions with no write/execute mixing; if a module overruns, MPU fault confines damage and triggers handler to restart or kill the task.- Secure boot: lock down flash region permissions after boot, mark bootloader privileged-only, and protect key storage region as read-only and privileged.

**Practical tips & trade-offs**

- Keep region count minimal; region fragmentation and alignment constraints require careful layout.- Always enable MemManage and configure FAULT handlers to avoid silent escalations to HardFault.- Test fault handlers with injected violations; include safe recovery paths (restart task, reset peripheral) and secure logging for post-mortem.

HardBehavioral

76 practiced

Behavioral: Describe a time when you diagnosed and resolved a complex interrupt or exception-related bug in production (or in a large-scale test). Use the STAR format: Situation, Task, Action, Result. If you don't have a direct production example, describe the most challenging simulated incident you handled, the decisions you made, and the trade-offs considered.

HardTechnical

83 practiced

Design a unit and integration testing approach to validate ISRs and exception paths within a CI pipeline. Cover hardware-mocked tests, using QEMU or other simulators, injecting interrupts and faults, measuring time-deterministic behavior, and how to assert correctness of nested-interrupt behavior and race conditions.

Sample Answer

**Approach summary**Design a multi-layer CI testing pyramid: fast hardware-mocked unit tests (host-run), simulator integration tests (QEMU / vendor sim), and gated hardware tests on CI runners. Each layer validates ISR and exception paths with increasing fidelity.

**1) Unit tests — hardware-mocked**- Replace NVIC/CPU registers with mocked interfaces (C header with weak symbols or link-time stubs).- Exercise ISR entry/exit, context save/restore, and exception vectors.- Example assertion: after invoking isr_enter("TIMER"), verify saved LR/PSR and peripheral state.

// test helper: simulate interrupt
void simulate_irq(int irq) {
  nvic_set_pending(irq);    // mock sets pending flag
  cpu_execute_interrupts(); // triggers ISR via linker stub
}

- Use Unity/Cmock for deterministic, fast runs.

**2) Simulator integration (QEMU/vendor)**- Run firmware in QEMU with semihosting or GDB to inject interrupts, exceptions, and memory faults (bus error).- Use QEMU monitor commands or gdb scripts to poke NVIC pending bits and fault-status registers; capture console/logs for assertions.- Time-deterministic behavior: run deterministic QEMU build, freeze host scheduling (rt priority) and measure cycles via cycle counter (DWT/PMU) exposed to the test harness.

**3) Fault & timing injection**- Inject faults: stack overflow (corrupt LR), bus fault (invalid address), priority inversion (lower priority preempts), nested IRQ sequences.- Use controlled timers to trigger nested interrupts: trigger IRQ A, inside its handler trigger IRQ B via hardware or software NVIC, assert that preemption/priority matches RTOS config.

**4) Asserting correctness (nested interrupts & races)**- Check register/context: verify that saved registers on stack match expected, and that return addresses restore.- Use sequence logs (ring buffer in RAM) appended atomically at known points to assert execution order under nested scenarios.- Race detection: run randomized interrupt timing (fuzzing) and assert invariants (no lost events, locks consistent). Use poisoning of shared data to detect torn updates.

**5) CI integration & metrics**- Fast unit stage on every push; QEMU integration on PR; hardware tests nightly or gated.- Collect coverage (gcov on host-stubbed code, QEMU instrumentation) and measure timing regression via baseline metrics tracked in CI.- Fail criteria: ISR mis-restore, unhandled exceptions, timing beyond SLA, assertion invariants violated.

**Trade-offs & notes**- Mocked unit tests are fastest but miss silicon quirks; QEMU bridges many CPU behaviors; real hardware required for electrical/timing edge cases.- Ensure deterministic seeds for randomized tests and repeatable failure capture (trace dumps, core files).

HardTechnical

134 practiced

You are the senior embedded developer leading a migration from polling-based drivers to interrupt-driven drivers across a product line. Present a plan that includes coding guidelines for ISRs, review checklist items, training topics for the team, CI/testing changes, rollout phases, and metrics to measure success and regression. Include common pitfalls to watch for during migration.

Sample Answer

**Plan overview**I would lead a staged migration: pilot on a single board/module → component-by-component rollout → product-wide release with telemetry and rollback plan. Each stage has code reviews, tests, and clear exit criteria.

**ISR coding guidelines**- Keep ISRs short (≤ 200 cycles where possible): do minimal work, set flags or push to lock-free SPSC queue.- No blocking, malloc, printf, or heavy math in ISRs.- Use volatile for shared flags, atomic ops or IRQ-safe spinlocks for multi-core.- Clear and document interrupt priorities and nesting behavior; avoid priority inversion.- Use explicit memory barriers where required; annotate ISRs with attributes and stack usage estimates.- Use defer mechanisms (workqueue/tasklets/RTOS thread) for processing.

**Review checklist**- ISR length and cycle estimates present- Shared data protected using atomics/critical sections- No blocking calls or syscalls- Proper priority assignment & NVIC config verified- Stack and heap impact analyzed- Power/latency/regression tests added

**Training topics**- ISR best practices, atomic vs mutex, memory barriers- Instrumentation with cycle counters and logic analyzers- RTOS defer patterns and wake-from-ISR semantics- Debugging interrupt races and hard faults

**CI / testing changes**- Add unit tests for deferred handlers and race conditions (fake ISR triggers)- Hardware-in-the-loop regression tests for latency and throughput- Performance benchmarks (latency, jitter, CPU usage, power)- Static analysis for ISR-safety (forbidden APIs)- Nightly stress tests with fault injection

**Rollout phases**1. Pilot module with full telemetry and rollback2. Siblings/components with similar hardware3. Cross-product rollout with staged releases and beta users4. Production release and deprecation of polling paths

**Metrics**- ISR latency and jitter distribution- CPU% used vs baseline- Interrupt frequency and wakeups per second- Regression counts (CRs) attributed to migration- Power consumption delta- Mean Time Between Failures (MTBF) before/after

**Common pitfalls**- Hidden blocking APIs called indirectly from ISRs- Unbounded ISR processing causing starvation- Priority inversion between ISRs and threads- Unclear ownership of shared buffers leading to races- Insufficient stack sizing causing hard faults

I’d run weekly checkpoints, require paired reviews for first 10 PRs, and keep a migration dashboard tracking metrics and incidents.

HardSystem Design

113 practiced

Design an interrupt-driven UART receiver on a resource-constrained MCU that must handle 1 MB/s continuous data for extended periods. The MCU has limited CPU cycles. Explain how you would use DMA, double-buffering, interrupt thresholds, flow control, and buffer sizing to ensure no data loss. Describe how ISRs should behave and recovery strategies for overrun conditions.

Sample Answer

**Clarify requirements**- Continuous UART at 1 Mbaud (assume 8N1 → 10 bits/byte → ~100 KB/s? — but question says 1 MB/s data, so design for 1 MiB/s payload). Packet boundaries not guaranteed. MCU CPU cycles limited; solution must minimize ISR work.

**High-level approach**- Use peripheral DMA + double-buffer (ping-pong) with hardware flow control (RTS/CTS) or XON/XOFF as fallback.- Use threshold interrupts (half-buffer) so processing overlaps reception.

**Buffer sizing**- Choose buffer large enough to hold processing latency + DMA switch time.- Example: target worst-case processing latency 10 ms → at 1 MiB/s need 10,240 bytes. Use 16 KB per buffer (two buffers → 32 KB total).- Align buffers to cache line / DMA constraints.

**DMA + double-buffering**- Configure circular (if available) or ping-pong DMA to fill buffer A then B.- Generate DMA-complete and DMA-half-complete interrupts (or transfer-count threshold).- On half-complete: schedule processing of that half-buffer outside ISR (deferred work).

**ISR behavior**- Keep ISRs tiny: - Acknowledge DMA event, toggle buffer state, enqueue buffer pointer to a processing queue (no heavy parsing). - If using RTOS, signal worker thread; if bare-metal, set flag and record timestamp. - Update flow-control signals if buffer occupancy exceeds high-water mark.- Avoid copying in ISR; processing occurs in background context.

**Flow control**- Implement RTS driven by free buffer bytes; deassert RTS when free < low threshold to stop sender; reassert when above resume threshold.- If hardware flow control unavailable, use XON/XOFF injection from processing task (careful with race).

**Overrun & recovery**- Monitor DMA errors/overrun flags in ISR; on overrun: - Immediately stop DMA, record diagnostics (drop counts, timestamps). - Assert hardware flow-control to pause sender. - Drain and reset DMA engine: clear flags, reprogram DMA to next buffer boundary. - If data loss unacceptable, try to re-request retransmit (protocol layer) or raise error to higher layer.- Implement watchdog for stalled DMA; if worker can't keep up repeatedly, reduce baud or signal link-level backpressure.

**Metrics & testing**- Instrument: bytes received, dropped, max buffer occupancy, ISR latency.- Stress-test with worst-case CPU load and long runs; tune buffer sizes and thresholds.

This design minimizes CPU work in ISRs, uses DMA and double-buffering to sustain 1 MiB/s, and uses flow-control plus explicit recovery steps to prevent or handle overrun.

Unlock Full Question Bank

Get access to hundreds of Interrupts and Exception Handling interview questions and detailed answers.

Join thousands of developers preparing for their dream job.