ARM

When debugging interrupts, it is easy to call everything “the interrupt.”

A peripheral status bit was not cleared: interrupt problem. The interrupt controller was not enabled: interrupt problem. The CPU never entered exception entry: interrupt problem. The ISR ran but the task did not wake: also interrupt problem. Everyone is debugging “interrupts,” but not the same layer.

The safer first model is this: an interrupt is a cross-layer path. A peripheral creates an event, the SoC routes that event to an interrupt controller, the controller selects, masks, prioritizes, and delivers it, the CPU receives it through exception entry, and the OS maps it to an ISR, bottom half, thread, or task wakeup.

An application calling read() looks like a normal function call. Illegal instructions, page faults, interrupts, and system calls can also look like “the CPU jumped to another handler.”

But these paths are not normal function calls.

A normal function call stays in the same privilege level and address space. The caller knows the callee address, passes arguments according to the ABI, and returns when the callee finishes. Exceptions and system calls are different: current code cannot freely choose a high-privilege entry. The CPU must switch state according to architectural rules, transfer execution to a controlled entry, and allow the kernel, firmware, or exception handler to decide what happens next.

Embedded platform discussions often use different words as if they meant the same thing.

“This project uses ARM.” “This chip is RISC-V.” “This core supports Linux.” “This board has an MMU.” “Interrupts are different on this architecture.” “This toolchain is incompatible.” Some of these statements are true, and some are only half true. The problem is that they often collapse ISA, CPU core, privileged architecture, SoC, board, and software platform into one layer.

Embedded software often fails in places that do not look architecture-related at first.

A firmware image is flashed but never reaches main(). An exception handler is never entered. A Linux program reports Exec format error. A driver gives a buffer to DMA and then reads stale data. Unaligned access works on one chip and becomes a hard fault on another. The same assembly startup code fails completely on a different profile.