Firmware Engineer Interview Questions and Strong Answers

What causes priority inversion in an RTOS, and how is it solved?

A low-priority task holds a resource that a high-priority task needs, while a medium-priority task preempts the low-priority one and blocks progress indefinitely. Priority inheritance temporarily raises the holder to the waiter priority; priority ceiling assigns each resource a ceiling priority. Both bound the inversion time.

How would you debug a boot failure?

Walk the chain in order: power rails, reset release, clock sources, boot ROM, bootloader, peripheral and memory initialization, and image load and validation. Confirm each stage on hardware with a scope or debug log before moving on, so you find the first stage that diverges instead of guessing.

Why is DMA useful, and what makes it tricky?

DMA moves data between memory and peripherals without CPU intervention, cutting latency and freeing cycles. The tricky parts are cache coherency (see /topics/computer-architecture), buffer ownership between CPU and DMA engine, alignment, and completion synchronization. Getting the handshake or cache maintenance wrong causes intermittent data corruption that is hard to reproduce.

How do you safely share data between an ISR and a task?

Keep ISRs short and defer work to a task. Protect shared state with a mechanism appropriate to the context: disabling the relevant interrupt briefly, a lock-free ring buffer, or an RTOS primitive that is ISR-safe. Mark hardware registers volatile; for shared state, volatile only covers simple bare-metal ISR flags — between RTOS tasks use atomics, critical sections, queues, or ISR-safe primitives, and account for atomicity on the target architecture.

What is the difference between a semaphore and a mutex?

A mutex provides mutual exclusion with a clear owner and usually supports priority inheritance, so it is the right tool for protecting a shared resource. A semaphore is a counting signal used for synchronization or producer-consumer flow and has no ownership. Using a semaphore where a mutex is needed loses priority-inheritance protection.

How do interrupt latency and interrupt priority affect real-time behavior?

Interrupt latency is the delay from event to handler execution; it grows when interrupts are disabled or a higher-priority handler is running. Priority decides which pending interrupt runs first. Long critical sections or chatty low-priority ISRs can starve time-critical work, so real-time firmware keeps handlers short and bounded.

How would you diagnose a hard fault or watchdog reset in the field?

Capture the fault context: stacked registers, fault status registers, and the program counter at the fault. Use a crash log or a debugger to map the address back to code, check for stack overflow, null or unaligned access, and bad peripheral state. For watchdog resets, find which task or ISR stopped servicing the watchdog and why.

When would you choose polling over interrupts?

Polling is appropriate for very short, predictable, high-rate transfers where interrupt overhead would dominate, or in tightly bounded critical sections where determinism matters more than CPU efficiency. Interrupts win when events are infrequent or latency-sensitive and the CPU has other useful work to do meanwhile.

What does the linker script control, and what breaks when it is wrong?

The linker script places sections in memory: code (.text) and constants in flash, initialized data (.data) with a load address in flash and a run address in RAM, zero-initialized data (.bss) in RAM, plus stack and heap regions. Startup code copies .data from flash to RAM and zeroes .bss before main runs. Classic failures map to those mechanics: globals that hold garbage mean the .data copy or .bss zeroing did not run or the addresses are wrong; code that crashes only after a firmware-size increase means a section overflowed into another region; and an interrupt vector table placed at the wrong address can fault or branch into garbage on the first interrupt that uses it.

When is volatile not enough for hardware or shared memory?

volatile only forces the compiler to perform each access; it does not make accesses atomic and it does not stop the hardware from reordering them. It is not enough whenever ordering or atomicity matters: a DMA descriptor must be visible to the DMA engine before the doorbell register starts it, which on ARM means cache maintenance for cacheable buffers plus a barrier (DMB, or DSB where completion must be guaranteed) — otherwise the doorbell can reach the peripheral before the descriptor writes do; a 32-bit counter shared with an ISR on an 8- or 16-bit MCU tears without an atomic or a critical section. The working rule: volatile for "the value can change underneath me," barriers for "these writes must land in this order," atomics or critical sections for "this update must be indivisible."

How does a firmware update work safely in the field?

The design target is that power loss or a corrupt candidate image never bricks the device. A common shape: a small, trusted bootloader that validates images by CRC and cryptographic signature, dual (A/B) application slots so the new image is written while the old one still runs, switchover metadata written last in a power-fail-safe way (redundant copies, sequence counters, CRC-protected valid/pending/confirmed states), and automatic rollback if the new image fails to mark itself healthy within a watchdog-supervised trial boot. Interview follow-ups usually probe the corners: where the version and health flags live, how the watchdog stays serviced during a long flash write, and why the bootloader is rarely field-updated unless a staged recovery path exists.