CPU Architecture

Architecture problems are hard to debug by intuition.

A program reports Exec format error, and someone suspects permissions. A file exists but execution says not found, and someone suspects the path. A program hits an illegal instruction, and the compiler is blamed. A device faults immediately after reset, and application code is changed. Much later, the actual cause turns out to be a wrong ELF machine, missing dynamic linker, floating-point ABI mismatch, unsupported ISA extension, or a PC that was never inside the expected code section.

Cross-compilation creates an easy illusion: if the program built successfully, it should run on the board.

In practice, that often fails. The executable is copied to the device and reports Exec format error. The file exists, but execution says not found. Linking succeeds, but the program crashes when calling a library function. Both targets are ARM, but changing toolchains breaks floating-point arguments. Both targets are RISC-V, but the generated program uses instructions the board does not support.

Some driver bugs feel almost random.

The CPU has written a descriptor, but the device reads old contents. The DMA completion interrupt has fired, but the driver still reads stale buffer data. Adding one log line makes the bug disappear. Changing optimization brings it back. It worked on a single-core MCU, then fails occasionally on an SoC with cache.

These bugs are often not caused by “broken DMA” or “an aggressive compiler.” They happen because several different guarantees were mixed together.

In embedded systems, the word “address” often sounds as if everyone means the same thing.

In bare-metal code, a pointer may be close to a real SRAM address. RTOS tasks may share one address space. An MCU with an MPU can catch some out-of-bounds accesses, but usually does not provide full address translation. A Linux user process sees virtual addresses, while a DMA device may see a different bus address.

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.

When a device does not start, application logs are often the first place people look.

Some failures happen much earlier: there is no serial output, main() is never reached, a HardFault fires immediately after reset, a bootloader jumps to the kernel and nothing happens, or an exception handler is never reached at the expected address. These are usually not business-logic bugs. The CPU has not yet entered a stable software execution environment.

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.