Embedded Systems Engineer Interview Questions

static does different jobs depending on where it appears. At file scope it gives a function or variable internal linkage: the name is private to that translation unit. That is how a driver hides its internal state and helper functions and avoids symbol clashes at link time.

Inside a function it gives a local variable static storage duration. The variable lives for the whole program, is initialised once (to zero if there is no initialiser) and keeps its value between calls. It sits in .data or .bss, not on the stack, so it costs RAM permanently but never grows the stack.

The pitfall I mention is reentrancy. A function with a static local is not reentrant: if an ISR and a task, or two RTOS tasks, call it at the same time, they share one copy of that variable.

Likely follow-up. How would you make a function with internal state safe to call from two tasks?

No. volatile only tells the compiler that every access written in the source must really happen, and in program order relative to other volatile accesses, because something outside the program can see or change the value. It says nothing about atomicity, and nothing about the ordering of ordinary, non-volatile accesses.

Three things still go wrong. A volatile uint64_t on a 32-bit core is read in two halves and can tear. count++ on a volatile is still a load, an add and a store, so an interrupt between them loses an update. And the compiler may move ordinary writes, such as filling a buffer, past the volatile write that sets a ready flag.

For shared data I use C11 _Atomic with the right memory order, or a short critical section. With DMA or a second core I also need barriers or cache maintenance, which volatile never generates. volatile stays the right tool for memory-mapped registers.

Likely follow-up. On a single-core Cortex-M, when is a plain aligned 32-bit read already atomic?

The ones I have seen bite are signed overflow, bad shifts, out-of-bounds access, uninitialised locals and strict-aliasing violations. Undefined behaviour matters because the optimiser assumes it never happens, so the code can change meaning between -O0 and -O2.

• 1 << 31 with a 32-bit int shifts into the sign bit, which is undefined in C. Write 1u << 31. Shifting by the type width or more is also undefined.
• An overflow check written as if (x + 1 < x) on a signed type may be deleted entirely.
• On many Cortex-M parts address 0 holds the vector table, so a null dereference silently reads flash instead of faulting.

My defences: unsigned types for bit work and counters, -Wall -Wextra -Wconversion treated as errors in CI, a static analyser, and building the hardware-independent modules on the host with the undefined behaviour and address sanitisers so the unit tests catch it.

Likely follow-up. Why might a null pointer dereference not fault on your microcontroller, and how could you make it fault?

The condition is never true. Before ~ is applied, a is promoted to int, so ~a is 0xFFFFFF00 on a 32-bit target, not zero. The fix is to bring the result back to the narrow type: (uint8_t)~a == 0.

Promotion causes a family of bugs. Two uint16_t values multiplied on a 32-bit target are promoted to signed int, so 0xFFFF * 0xFFFF overflows a signed int, which is undefined. Writing (uint32_t)a * b fixes it. On an 8-bit or 16-bit MCU, where int is 16 bits, uint16_t x = 40000; x * 2 behaves differently again, which bites when code is ported between cores.

Mixing signed and unsigned in a comparison converts the signed side to unsigned, so -1 < 1u is false. I turn on -Wsign-compare and -Wconversion and keep register and protocol arithmetic in explicitly sized unsigned types.

Assemble the bytes into a uint32_t in the wire byte order with shifts, then memcpy that into a float. The compiler turns a fixed-size memcpy into a single register move, so it costs nothing.

The tempting version, *(float *)buf, has two problems. It breaks strict aliasing, because a float lvalue is reading an object whose type is a byte array, so the optimiser may reorder or drop accesses. And buf may not be 4-byte aligned, which faults on a Cortex-M0 and on any core when the compiler emits a multiple-load instruction.

In C, reading a different member of a union than the one last written is allowed and reinterprets the bytes. In C++ that is undefined; use std::bit_cast in C++20 or memcpy. Character types may alias anything, which is why byte buffers are safe to read. Some projects, the Linux kernel among them, build with -fno-strict-aliasing as a deliberate choice, but I would not rely on that in portable code.

Likely follow-up. Does the float format itself also need checking on an unusual target?

On a typical microcontroller toolchain:

• int x = 5; goes in .data. It lives in RAM, but its initial value is stored in flash and the startup code copies it across before main.
• int y;, and any static explicitly initialised to zero, goes in .bss, which the startup code zeroes. It costs RAM but no flash.
• static const uint16_t table[] = {...}; goes in .rodata, which is placed in flash and costs no RAM.
• A non-static local array lives on the current stack.
• A string literal goes in .rodata.

The trap is a large const table declared inside a function without static. The language then requires a fresh object per call, and a compiler may build it on the stack each time. I always check the map file to confirm big tables landed in flash, and I watch the .data size, because it costs both flash and RAM.

Likely follow-up. What exactly does the reset handler do before it calls main?

Four reasons. A general-purpose heap fragments over months of uptime, so an allocation can fail long after release even when total free memory looks fine. Allocation time is not bounded, which conflicts with real-time deadlines. Most heap implementations are not safe to call from an ISR, and need a lock to share between tasks. Finally, you cannot prove from the code that memory will never run out, and safety standards such as MISRA C ask you to avoid dynamic allocation for exactly that reason.

The alternatives are static allocation of everything sized at compile time, fixed-block pools for objects that come and go (O(1), no fragmentation, easy to monitor), RTOS objects created with the static-allocation APIs, and arenas that are reset as a whole at the end of a transaction.

Exceptions cost flash for unwind tables and the runtime support library, and on many toolchains throwing allocates the exception object from the heap. Throw time depends on how far the stack unwinds, so it is hard to bound. RTTI adds type information for every polymorphic class and enables dynamic_cast and typeid, which firmware rarely needs.

So teams build with -fno-exceptions -fno-rtti. The consequences: a failing new cannot throw, so either there is no heap or you use the nothrow form and check for null. Standard library functions that would throw call an abort handler instead, which you must define to put the device in a safe state. Errors travel as return codes, std::optional, or an expected-style type such as std::expected from C++23.

The trap is a third-party library or precompiled object built with exceptions enabled, which silently brings the unwinder back. I check the map file for unwind sections after integrating anything.

Likely follow-up. Would you ever keep exceptions on in an embedded product?

Free, or close to it after optimisation: classes with non-virtual member functions, references, namespaces, enum class, constexpr, static_assert, RAII destructors, std::array, std::span and std::string_view, lambdas, and std::atomic on types the core supports natively. Templates cost nothing at run time but cost flash for each instantiation.

Features with a cost: virtual functions add a vtable per class in flash, a pointer per object and an indirect call that blocks inlining, which is usually acceptable. Containers such as std::vector, std::string, std::map and often std::function allocate from the heap. iostreams pull in a very large amount of code. Exceptions and RTTI are discussed separately.

const means read-only after initialisation; the value may still be computed at run time. A constexpr variable must be initialised with a constant expression, and a constexpr function may run at compile time when its arguments are constants. consteval (C++20) forces compile-time evaluation. constinit (C++20) guarantees a static variable is initialised at compile time but leaves it writable.

constexpr std::array<uint8_t, 256> make_bitrev() {
    std::array<uint8_t, 256> t{};
    for (unsigned i = 0; i < 256; ++i) {
        unsigned r = 0;
        for (unsigned b = 0; b < 8; ++b)
            if (i & (1u << b)) r |= 0x80u >> b;
        t[i] = static_cast<uint8_t>(r);
    }
    return t;
}
constexpr auto kBitRev = make_bitrev();
static_assert(kBitRev[1] == 0x80);

The table lands in flash, there is no startup code to build it, and the static_assert documents and checks it at the same time.

Every distinct set of template arguments produces its own copy of the code. A queue template used with ten element types and five capacities can easily produce fifty near-identical functions.

The standard fix is a thin template over a type-erased core. The core is ordinary code that works on void *, an element size and a capacity passed at run time. The template only adds type-safe inline wrappers and the storage. Code that does not depend on the capacity should never be inside a class templated on it.

Other tools: explicit instantiation in one translation unit so headers do not re-instantiate everywhere, link-time optimisation, and identical code folding in the linker, which merges functions whose machine code is the same.

The reset handler sets up the stack, copies .data from flash to RAM, zeroes .bss, often calls a clock setup function, then runs the constructors listed in .init_array (with newlib this is done by __libc_init_array), and finally calls main.

Three problems follow. The order of constructors across translation units is unspecified, so a global that uses another global from a different file may see it unconstructed. A constructor that touches hardware runs before main has configured clocks or enabled the peripheral, so it faults or silently does nothing. And a custom startup file that forgets to walk .init_array means constructors never run at all.

My fixes: give classes constexpr constructors so globals are constant-initialised with no code, use constinit to make the compiler prove it, and keep hardware set-up in explicit init() calls from main. Function-local statics work too, but add guard variables, and with threads they call guard functions unless -fno-threadsafe-statics is used.

class IrqGuard {
public:
    IrqGuard() : saved_(__get_PRIMASK()) { __disable_irq(); }
    ~IrqGuard() { __set_PRIMASK(saved_); }
    IrqGuard(const IrqGuard&) = delete;
    IrqGuard& operator=(const IrqGuard&) = delete;
private:
    uint32_t saved_;
};

void push(Event e) {
    IrqGuard lock;          // released on every return path
    queue_.push(e);
}

It saves and restores PRIMASK rather than blindly re-enabling interrupts, so it nests correctly: an inner guard inside an outer one does not re-enable interrupts early, and it is safe to use in code called with interrupts already off. Deleting copy stops two objects restoring the same state.

The classic bug is writing IrqGuard{}; without a name. That creates a temporary that is destroyed at the semicolon, so nothing is protected. Some static analysers catch it. I would also keep the guarded region short, and use a BASEPRI version when the highest-priority interrupts must keep running.

Describe each register field as a type whose address, position and width are template parameters, so masks and shifts are computed at compile time and every access inlines to the same load and store a C macro would give.

template <uintptr_t Addr, unsigned Lsb, unsigned Width>
struct Field {
    static constexpr uint32_t mask = ((1u << Width) - 1u) << Lsb;
    static uint32_t read() {
        return (*reinterpret_cast<volatile uint32_t*>(Addr) & mask) >> Lsb;
    }
    static void write(uint32_t v) {
        auto r = reinterpret_cast<volatile uint32_t*>(Addr);
        *r = (*r & ~mask) | ((v << Lsb) & mask);
    }
};
using UartParity = Field<0x40011000u + 0x0C, 9, 2>;

Adding enum class values for the field contents means writing a baud setting into a parity field no longer compiles. The width must be less than 32 for this mask expression, which a static_assert can enforce.

The costs are in people, not cycles: code generators are needed to produce these types from the vendor's register description files, unoptimised debug builds get slower, and the team must be comfortable reading templates.

The NVIC marks the interrupt pending. If its priority is higher than the current execution priority and it is not masked, the core takes it. Hardware pushes eight words onto the current stack: R0 to R3, R12, LR, the return address and xPSR, and more for the floating-point registers if the FPU context is active and lazy stacking is not deferring it. In parallel it fetches the handler address from the vector table, located through VTOR. LR is loaded with a special EXC_RETURN value, the core switches to Handler mode on the main stack, and the handler starts. On a Cortex-M3 or M4 with zero wait-state memory this takes about twelve cycles.

Because hardware saves the caller-saved registers, handlers are ordinary C functions. Two optimisations matter: tail-chaining, where a pending interrupt runs straight after the current one without unstacking and restacking, and late arrival, where a higher-priority interrupt that arrives during stacking takes over the vector fetch. The handler returns by loading EXC_RETURN into the PC.

Likely follow-up. What does EXC_RETURN tell you inside a fault handler?

Latency is the time from the hardware event to the first useful instruction in the handler. Contributors: the fixed exception entry cycles, flash wait states or cache misses when fetching the vector and handler, a higher-or-equal priority handler already running, and, usually the largest, code that has disabled interrupts for a critical section. Bus contention with DMA and floating-point stacking add a little more.

To measure it, drive a GPIO from the event source if possible, toggle another GPIO at the first line of the handler, and capture both on an oscilloscope or logic analyser in persistence or histogram mode for a long run under realistic load. Inside the chip, the DWT cycle counter gives a timestamp you can record. The number that matters is the maximum, not the average.

To reduce it: shorten or narrow critical sections (BASEPRI instead of a global disable), raise the priority of the interrupt, and run the handler from RAM or tightly coupled memory if flash wait states dominate.

The read-modify-write in main is three steps: load ODR, OR in the bit, store ODR. If the interrupt fires after the load and changes its own pin, main then stores its stale copy and silently undoes the interrupt's change. It happens rarely, which is what makes it expensive to find.

The best fix is hardware support for atomic bit changes. Many GPIO blocks have set and reset registers, such as BSRR on STM32 parts, where writing a 1 changes only that pin. Cortex-M3 and M4 also offer bit-banding on some parts, which aliases each bit to its own word. Otherwise wrap the update in a short critical section, or use an LDREX and STREX retry loop.

A related bug: many status registers are write-one-to-clear. Writing SR |= FLAG reads all the set flags and writes them back as ones, clearing events you have not handled yet. For those registers you write only the bit you mean to clear: SR = FLAG.

A plain read is two 32-bit loads, so if the low word wraps between them you get a value that is off by 2^32. One option is a short critical section around the two loads. Another, which avoids masking interrupts, is to read the high word twice and retry if it changed:

static volatile uint32_t g_hi, g_lo;   /* updated only by the ISR */

uint64_t uptime_read(void)
{
    uint32_t hi1, lo, hi2;
    do {
        hi1 = g_hi;
        lo  = g_lo;
        hi2 = g_hi;
    } while (hi1 != hi2);
    return ((uint64_t)hi1 << 32) | lo;
}

This works on a single core because the ISR runs to completion relative to main, so if it wrapped the low word during our reads, the high word differs and we retry. The same pattern works for a hardware timer with an overflow counter in software, with one extra check for a pending overflow flag. On a multi-core part you need a sequence counter with proper barriers instead.

On Cortex-M a lower number means a higher priority. Each interrupt has an 8-bit priority field, but parts implement only the top few bits, often three or four, giving 8 or 16 levels. Priority grouping splits those bits into a pre-emption priority and a subpriority. Only the pre-emption priority decides whether one handler can interrupt another. The subpriority only decides which of two pending interrupts runs first.

The trap with an RTOS such as FreeRTOS: interrupts that call kernel functions must have a priority numerically equal to or greater than the kernel's configured maximum syscall priority, because the kernel masks only up to that level in its critical sections. Interrupts default to priority 0, the highest, so an ISR that calls a FromISR function without setting a priority corrupts kernel data at random. A configuration assert catches it if enabled.

I choose the narrowest mechanism that still covers every context touching the data.

• Global disable (PRIMASK): simplest, works everywhere on a single core, but adds its duration to the latency of every interrupt.
• BASEPRI masking: masks only priorities at or below a threshold, so a motor-control interrupt above it keeps running. That interrupt then must not touch the protected data or call the kernel.
• Disabling one interrupt in the NVIC: fine-grained when only one ISR shares the data.
• Scheduler lock: stops task switches but not interrupts, for task-only data.
• Mutex: task-only, can block, and gives priority inheritance, so it suits longer operations.
• Lock-free structures: a single-producer, single-consumer ring buffer with atomics needs no lock at all.

In every case the protected region should be tens of cycles and must never block. On a multi-core part, disabling local interrupts protects nothing from the other core, so you need a spinlock or a hardware semaphore as well.

DMB orders memory accesses: those before it are observed before those after it. DSB goes further and waits until earlier accesses have completed. ISB flushes the pipeline so that later instructions are fetched with the effects of an earlier system change in force.

The classic bug: an ISR clears its peripheral's interrupt flag as its very last write and returns. The write is still travelling through a write buffer or a slower peripheral bus, so the NVIC still sees the request asserted and runs the handler a second time. Clearing the flag early in the handler, or reading the register back, or a DSB before return, fixes it.

Other places: a DSB before WFI so pending writes finish before sleep; a DSB then ISB after enabling the MPU, changing VTOR or switching stacks through CONTROL; and DMB or DSB between writing a DMA descriptor or buffer and starting the transfer. On a Cortex-M7 with caches, barriers are not enough for DMA: you also need cache clean and invalidate operations or a non-cacheable buffer.

An ISR should do the minimum that cannot wait: acknowledge the source, grab data that would otherwise be overwritten (a received byte, a captured timer value), timestamp it if needed, and hand off. Everything else, such as parsing, logging and decisions, belongs in a task or the main loop.

Hand-off options, from lightest to heaviest: set an atomic flag the main loop polls; push the data into a lock-free ring buffer; give a semaphore or send a direct task notification using the ISR-safe API, then request a context switch on exit so a woken high-priority task runs immediately; or post to a queue. On embedded Linux the same idea appears as a threaded interrupt or a workqueue.

The reasons are short, predictable latency for other interrupts, no blocking calls in interrupt context, and code that can be unit-tested outside the ISR. I always add an overflow counter wherever the hand-off can fill up, so a drop is visible rather than silent.

The scheduler always runs the highest-priority ready task. When something makes a higher-priority task ready, such as a tick, an ISR giving a semaphore or a task posting to a queue, the kernel sets the PendSV exception pending. PendSV is configured as the lowest-priority exception, so it runs only after every other handler has finished. That guarantees a switch never happens in the middle of an ISR.

When the outgoing task was interrupted, hardware already pushed R0 to R3, R12, LR, PC and xPSR onto its process stack. The PendSV handler pushes the rest, R4 to R11 and the upper floating-point registers if that task used the FPU, saves the stack pointer into the task control block, picks the next task, loads its stack pointer, pops R4 to R11 and returns. The exception return unstacks the remaining registers, and the new task resumes as if it had never stopped.

Tasks of equal priority are rotated at each tick when time slicing is on.

Likely follow-up. Why do tasks run on the process stack while handlers use the main stack?

Rate-monotonic assignment gives higher priority to tasks with shorter periods. For independent periodic tasks whose deadlines equal their periods, it is optimal among fixed-priority schemes: if any fixed priority order meets every deadline, this one does. When deadlines are shorter than periods, deadline-monotonic ordering takes its place.

The quick test is the Liu and Layland utilisation bound. The task set is schedulable if total utilisation, the sum of execution time divided by period, is at most n(2^(1/n) − 1), which is about 0.78 for three tasks and approaches 0.69 for many. It is sufficient but not necessary, so a set above the bound may still be fine.

The exact test is response-time analysis: for each task, iterate R = C + B + Σ ceil(R / Tj) × Cj, summed over the higher-priority tasks j, until R stops changing, then compare with the deadline. B is blocking from lower-priority tasks. I show this in the coding section. Earliest-deadline-first can use up to 100% utilisation, but its behaviour under overload is harder to predict, which is why fixed priority dominates in practice.

Both bound priority inversion, but they act at different times. With priority inheritance, a low-priority task holding a mutex is raised to the priority of the highest task waiting for it, and only while that contention exists. It costs nothing when there is no contention and needs no configuration. But blocking can chain through several mutexes, and it does not prevent deadlock.

With the immediate ceiling protocol, every resource has a ceiling equal to the highest priority of any task that uses it. A task that takes the resource is raised to the ceiling at once. As a result a task can be blocked by at most one lower-priority critical section, and deadlock between resources is impossible. The price is that every user must be known at design time, and the boost happens even when nobody else wants the resource.

In practice: FreeRTOS mutexes use inheritance, OSEK and AUTOSAR use ceilings, and POSIX offers both through the mutex protocol attribute. For a safety-rated design where I must prove the worst-case blocking, I prefer ceilings.

Likely follow-up. How would you include blocking time in a response-time analysis?

A mutex is for mutual exclusion. It has an owner: only the task that took it may give it back, which lets the kernel apply priority inheritance and detect misuse. It cannot be used from an ISR because an ISR cannot block or own anything. Many kernels also offer a recursive mutex that the owner may take more than once.

A binary semaphore is for signalling. It has no owner: an ISR gives it when data arrives and a task takes it to wait. A counting semaphore counts events or free resources, such as free buffers in a pool or bytes queued for transmission.

The classic mistake is using a binary semaphore as a lock. It works in testing, but because there is no owner there is no priority inheritance, so the system becomes open to unbounded priority inversion. For simple ISR-to-task wake-ups, many kernels offer direct task notifications, which are faster and lighter than a semaphore.

I start from what is being passed and who owns it.

• Message queue: copies fixed-size items, decouples producer and consumer, and blocks or fails when full. For large data, queue a pointer to a pool block and transfer ownership with it.
• Stream or message buffer: an efficient byte stream between one writer and one reader, such as UART data.
• Event flags: let a task wait for any or all of several conditions, such as "link up and configuration loaded".
• Direct task notification: the lightest way to wake one known task, often with a small value attached.
• Shared memory with a mutex, or double buffering: when only the latest state matters, such as the current setpoint, and queuing old values would be wrong.

For every channel I decide what happens when it is full (block with timeout, drop newest, overwrite oldest) and count drops. An undefined overflow policy is a common source of field bugs.

Deadlock needs four conditions at once: exclusive resources, tasks holding one resource while waiting for another, no forced release, and a circular wait. The typical case is task A taking the SPI mutex then the flash mutex, while task B takes them in the opposite order.

Prevention breaks one condition. The usual tool is a global lock order that everyone follows, written down and checked in review. Others: take all needed resources in one step, never hold a lock while calling into another module or waiting on a queue, and use the priority ceiling protocol, which rules deadlock out.

Detection matters too. A deadlocked device often looks alive because interrupts and the idle task still run. A task-level watchdog, where each critical task must check in within its period before the hardware watchdog is fed, turns a silent stall into a reset with a logged reason. Taking mutexes with a timeout and logging the failure gives you evidence instead of a frozen device.

I combine analysis with measurement. GCC's -fstack-usage gives the frame size of each function, and a call-graph tool adds them along the deepest path, although function pointers and recursion need manual review. Then I measure: the kernel fills each stack with a known pattern at creation, and after a stress test that exercises every path, the high-water mark shows how much was ever used.

On Cortex-M each task stack also has to hold the exception frame that hardware pushes when an interrupt arrives while that task runs: 32 bytes, or about 100 bytes with lazy FPU state. Nested interrupts then run on the main stack, which needs its own sizing for the worst nesting.

The usual stack wreckers are printf with floating-point formats, large local arrays and buffers, and deep library calls. I keep a margin agreed with the team, enable the kernel's overflow check during development, and where the hardware allows, use an MPU guard region or the ARMv8-M stack limit registers so an overflow faults at once.

The tick sets the resolution of timeouts and delays and the rate of time-slicing. A higher rate gives finer timeouts but costs CPU time and wakes the core more often, which hurts battery life. 1 kHz is a common default. Remember that a delay of one tick can end anywhere from almost zero to one full tick later, depending on when in the tick period it started, so short precise timing belongs to a hardware timer, not the tick.

Tickless idle stops the periodic tick when nothing is ready to run. The kernel works out when the next timeout expires, programs a low-power timer for that moment, puts the core into a sleep mode, and on wake corrects its tick count by the time that passed. Any other interrupt can end the sleep early, so the correction must handle that.

A UART receiver resynchronises on the falling edge of each start bit and then samples each bit near its centre, often by oversampling at 16 times the baud rate and taking a majority vote. Timing error accumulates across the frame. For 8N1, the stop bit is sampled about 9.5 bit times after the start edge, and the sample must still fall inside that bit, so the combined mismatch between the two ends must stay below roughly 5% in theory. In practice I keep each end within about 2%, to leave room for edge distortion.

Two sources eat that budget. First, divider rounding: from a 16 MHz clock with 16 times oversampling, 115200 baud needs a divisor of 8.68, which rounds to 9 and gives 111111 baud, an error of about 3.5%. A fractional baud generator, 8 times oversampling or a different crystal fixes it. Second, an internal RC oscillator can drift by a percent or more over temperature, which is why production UARTs, and especially USB or CAN, usually run from a crystal.

CPOL sets the idle level of the clock: 0 idles low, 1 idles high. CPHA sets which edge samples data: with CPHA 0, data is sampled on the first (leading) clock edge after chip select goes active, and with CPHA 1 on the second (trailing) edge. The four combinations are modes 0 to 3; mode 0 is the most common, and many devices support both 0 and 3.

A wrong mode rarely produces obvious garbage. Typical symptoms are values shifted by one bit, so readings look doubled or halved, a register that reads back correctly most of the time, or a link that works at 1 MHz but fails at 10 MHz because the sample point lands near a transition.

I check the timing diagram in the device datasheet, not just the mode number, because vendors draw them differently, then confirm with a logic analyser. While there I check bit order, whether the device needs chip select toggled between bytes or held across a transaction, and the minimum chip-select set-up time.

Likely follow-up. Why might SPI work on the bench and fail with a 30 cm ribbon cable?

I2C lines are open-drain, so the pull-ups alone produce the rising edges. Too large a resistor, combined with bus capacitance, gives slow rise times that break the timing: the specification allows up to 1000 ns rise time in standard mode and 300 ns in fast mode. Too small a resistor exceeds the 3 mA a device must be able to sink while holding the line below 0.4 V. So the minimum is (VDD − 0.4 V) / 3 mA, about 1 kilohm at 3.3 V, and the maximum comes from the rise-time limit and the measured bus capacitance. Values of 2.2k to 4.7k are typical, but I check the rise time on a scope.

Clock stretching is a slave holding SCL low to pause the master while it prepares data. Some master controllers handle it badly, which is worth checking early. A repeated start is a START issued without a STOP in between. A register read uses it: write the register address, issue a repeated start, then read, so no other master can take the bus in the middle. When reading, the master NACKs the last byte to tell the slave to stop sending.

Every CAN node detects bit, stuff, CRC, form and acknowledgement errors. Bit stuffing inserts an opposite bit after five identical bits, which keeps receivers synchronised and makes a sixth identical bit a detectable error. A node that detects an error sends an error frame, and the frame is retransmitted automatically.

Each node keeps a transmit and a receive error counter. Errors raise them sharply and successful frames lower them slowly. Below 128 the node is error active and signals errors with dominant bits. At 128 or more it becomes error passive and signals with recessive bits so it cannot disrupt the bus. If the transmit counter exceeds 255, the node goes bus-off and stops participating. It may rejoin only after seeing 128 sequences of 11 recessive bits, and firmware should decide whether recovery is automatic and log every bus-off.

CAN FD allows payloads of up to 64 bytes and an optional faster bit rate for the data phase, with a stronger CRC. A classic controller that does not understand FD frames will flag them as errors, so FD and classic-only nodes cannot share a bus unless the classic nodes are FD-tolerant.

Likely follow-up. What would you expect to measure between CANH and CANL on an unpowered, correctly terminated bus?

Run the DMA channel in circular mode into a ring buffer and let three events wake the software: the UART idle-line interrupt, which fires when the line has been quiet for one character time after a burst, and the DMA half-transfer and transfer-complete interrupts. On any of them, compute the current write position from the DMA's remaining-count register, process the bytes between the last read position and that position, handling the wrap, and store the new read position.

This handles any message length, keeps the CPU free during reception, and bounds latency to one idle time.

Things to get right: the buffer must hold all data that can arrive during the worst-case delay before processing; overrun and framing error flags must still be checked and cleared, or reception can stop; and on a core with a data cache, such as a Cortex-M7, the buffer must be in non-cacheable memory or invalidated, cache-line aligned, before the CPU reads it. Otherwise the CPU reads stale bytes from cache that look like corrupted data.

USB is host-driven: the device never transmits on its own initiative, it answers when the host polls it. Data flows through endpoints. Endpoint 0 is the mandatory control endpoint; others are IN or OUT, always named from the host's point of view. There are four transfer types: control for set-up and commands, bulk for large reliable data with no bandwidth guarantee, interrupt for small data polled at a bounded interval, and isochronous for streaming with reserved bandwidth but no retries.

Enumeration: the host resets the device, reads the device descriptor, assigns an address, reads the configuration, interface and endpoint descriptors, selects a configuration and loads a driver by class or by vendor and product ID. Using a standard class such as CDC ACM for a virtual serial port, HID or mass storage means no custom host driver.

I work out events per second and the cost per event. Polling is simplest and deterministic, and is the right choice when the wait is shorter than interrupt overhead. An SPI byte at 20 MHz takes 400 ns, which is less than entering and leaving an ISR on many parts, so polling the flag is faster. It is also fine in a super-loop for slow inputs.

Interrupts suit sporadic, low-rate events, such as a button or a received command, because the CPU does nothing until something happens. They become expensive at high rates: a UART at 1 Mbaud produces about 100,000 byte interrupts per second, which can consume a large share of a small core.

DMA suits bulk transfers: ADC sample streams, display updates, high-rate serial data. The CPU is free during the transfer, but there is set-up cost, a limited number of channels, request mappings to plan, and cache coherence to manage on cached cores. A common mix is DMA for data and an interrupt only at the end of a block.

The timer counter runs from 0 up to an auto-reload value and wraps. A compare register sets the duty cycle: the output is high while the counter is below the compare value and low after it, or the reverse. The PWM frequency is the timer clock divided by (prescaler + 1) × (auto-reload + 1), and the resolution is the number of counter steps per period.

So frequency and resolution trade against each other. With a 72 MHz timer clock and no prescaler, 20 kHz PWM gives an auto-reload of 3599, so 3600 steps, a little under 12 bits. Doubling the frequency halves the steps.

Details interviewers listen for: enable the preload (shadow) registers so a new duty value takes effect at the period boundary and never produces a glitch; use centre-aligned mode for motor control to reduce harmonics and give a natural point to trigger the ADC; and insert dead time on complementary outputs so both switches of a half-bridge are never on together. Input capture is the mirror image: the timer latches the counter on an edge, measuring periods without interrupt jitter.

The SoC's boot ROM runs first. It reads boot-mode pins or fuses to choose a boot device and loads a small first-stage loader, often the U-Boot SPL, into on-chip SRAM, because DRAM is not working yet. That stage initialises the DRAM controller and loads the full bootloader, on many 64-bit Arm parts together with trusted firmware.

U-Boot then loads the kernel image, the device tree blob and optionally an initramfs into RAM, sets the kernel command line and jumps to the kernel. The kernel initialises its subsystems, uses the device tree to probe drivers, mounts the root file system named by the root= parameter, and starts PID 1, which is systemd, BusyBox init or a small custom init. Init starts services, and finally the application.

Likely follow-up. How would you reduce boot time to under two seconds?

Buildroot is a set of makefiles with a Kconfig menu. It builds a toolchain, kernel, bootloader and root file system image quickly, is easy to understand completely, and suits a single product with a small team. It has no package manager by default, and some configuration changes need a clean rebuild.

Yocto, through BitBake recipes and layers, has a steeper learning curve and a longer first build, but it scales better: layers separate the silicon vendor's support, your board and your product; the shared-state cache makes rebuilds incremental; it generates an SDK for application developers, package feeds and licence manifests. Most silicon vendors ship their board support as Yocto layers, which often settles the question.

My rule: Buildroot for a small, stable product or a quick prototype, Yocto for a product family or a long maintenance life with several teams. With either, I pin every source revision so a build from two years ago can be reproduced exactly when a security fix is needed.

The device tree describes hardware that cannot be discovered by probing: memory-mapped peripherals, their interrupts, clocks, GPIOs and the devices sitting on buses such as I2C and SPI. It lets one kernel binary support many boards. Source files (.dts and included .dtsi) are compiled with dtc into a blob that the bootloader passes to the kernel.

&i2c1 {
    status = "okay";
    temp-sensor@48 {
        compatible = "ti,tmp102";
        reg = <0x48>;
    };
};

Each driver lists the compatible strings it supports. When the kernel finds a node whose string matches, it calls that driver's probe function, which reads properties such as reg, interrupts and GPIO references. Overlays modify the tree at boot for add-on boards.

The bug I see most often: a peripheral node in the SoC's .dtsi is status = "disabled" and the board file never sets it to "okay", so the driver never probes and nothing logs an error.

For GPIO, use the character device interface, /dev/gpiochipN, through libgpiod. The old sysfs GPIO interface is deprecated. For I2C, open /dev/i2c-N and use the I2C_RDWR ioctl for combined transactions. For SPI, the spidev driver gives /dev/spidevB.C. For a custom memory-mapped block, UIO maps its registers into the process and delivers interrupts through a blocking read(). Mapping /dev/mem works for quick experiments but is a security hole in a product.

User-space drivers are easy to develop and debug, and a crash does not take the kernel down. I write a kernel driver when the device should appear through a standard subsystem (IIO for sensors, input, hwmon, network) so existing tools work; when interrupt latency or DMA demands it; when several processes must share the device safely; or when it must take part in suspend and resume. That is the boundary with the Device Driver Developer role.

Start with a kernel built with PREEMPT_RT, which makes most of the kernel pre-emptible and turns interrupt handlers into threads with priorities. Then the application has to cooperate:

• Run the control thread under SCHED_FIFO at a priority above other work.
• Call mlockall(MCL_CURRENT | MCL_FUTURE) and pre-fault the stack and buffers so a page fault never happens in the loop.
• Allocate everything before the loop starts and avoid blocking system calls and logging inside it.
• Sleep with clock_nanosleep on CLOCK_MONOTONIC with an absolute deadline, so jitter does not accumulate.
• Isolate a CPU for the thread, steer interrupt affinity away from it, and fix the CPU frequency and idle states.

Then measure the worst-case wake-up latency with a tool such as cyclictest while the system is under heavy CPU, memory, network and storage load, for hours rather than minutes. If the worst case does not fit the deadline, the tight loop belongs on a microcontroller or a real-time core beside Linux, with Linux handling the user interface and connectivity.

Assume power can vanish during any write. The root file system should be read-only, for example SquashFS, so it can never be corrupted. Writable data goes on a separate partition with a power-safe file system: ext4 with journalling or F2FS on eMMC, or UBIFS on top of UBI on raw NAND, where UBI also handles bad blocks and wear levelling. If software expects a writable root, an overlay file system puts a writable layer on top.

Updates use two root partitions, A and B. Write the new image to the inactive one, verify it, switch the boot target, and have the bootloader count boot attempts. If the new system does not confirm it is healthy within a few attempts, the bootloader falls back to the old one.

Files are replaced atomically: write a temporary file, fsync it, rename it over the old one, then fsync the directory. Logs go to RAM or are rate-limited, because flash wears out. And I test all of it with a rig that cuts power at random points thousands of times.

A platform driver registers itself with a table of compatible strings. When the kernel creates a platform device from a device tree node whose compatible matches, the driver core calls the driver's probe function with that device.

Probe gathers resources: maps the registers with devm_platform_ioremap_resource, requests the interrupt, gets clocks, regulators and GPIOs, enables them and registers the device with its subsystem. The devm_ helpers tie each resource to the device's lifetime, so they are released automatically if probe fails half-way or the device is removed. That removes a whole class of error-path leaks.

If a dependency such as a clock controller or a GPIO expander has not probed yet, getting it returns -EPROBE_DEFER. The driver returns that code, and the core retries probing later, after other drivers have bound. A driver that is permanently deferred usually means a missing or disabled dependency in the device tree, and the kernel's list of deferred devices in debugfs shows which one.

Names differ between vendors, but there are usually three tiers. In sleep, the CPU clock stops while peripherals keep running, any enabled interrupt wakes the core within a few cycles, and nothing is lost. In stop or deep sleep, most clocks stop, including the PLL, but RAM and registers keep their contents. Wake-up comes from external interrupts, the RTC or low-power peripherals, and takes microseconds, after which firmware usually has to restart the PLL and restore the system clock. In standby or shutdown, the core domain is powered off. RAM is lost apart from a small backup area, and wake-up looks like a reset with a flag telling you why.

The CPU enters these with WFI or WFE after the sleep configuration bits are set. Things that keep current high in practice: a peripheral clock left on, floating pins, an LED or pull-up in the wrong state, the debug interface keeping domains powered, and a 1 kHz tick waking the core a thousand times a second.

Compute the charge per cycle and divide by the period.

• Active: 20 mA × 0.05 s = 1.0 mAs.
• Radio: 30 mA × 0.01 s = 0.3 mAs.
• Sleep: 0.005 mA × 59.94 s ≈ 0.3 mAs.

Total is about 1.6 mAs per 60 s, an average of roughly 27 µA. 1000 mAh / 0.027 mA ≈ 37,000 hours, a little over four years, before derating.

The answer interviewers want continues: the active phase dominates, so the biggest gain is shortening it, for example by starting the sensor conversion earlier or using DMA and sleeping while waiting. Then derate. Real cells lose capacity to self-discharge, low temperature and high pulse currents, and the device stops at a cut-off voltage before the cell is empty, so I would plan with a substantial margin. Finally, I would measure the real profile with a current analyser that captures microamps and milliamps in one trace, because a multimeter averages away the spikes.

Likely follow-up. What changes if the radio sometimes needs three retries?

Brown-out is the supply sagging below the voltage at which the chip is guaranteed to work, without going to zero. During that window the CPU can execute instructions incorrectly, and a flash program or erase in progress can leave corrupted data. A slowly discharging battery or a sagging supply during a motor start produces exactly this.

The brown-out reset holds the MCU in reset below a threshold. I set it above the minimum operating voltage and above the voltage needed for reliable flash writes, rather than leaving it at the lowest setting. Many parts also have a programmable voltage detector that raises an interrupt earlier, giving time to finish or abort a write and enter a safe state.

In the design: check the supply before starting a long erase, size the hold-up capacitance so an in-progress page write can complete, and, most importantly, use a storage format that tolerates an interrupted write, with a CRC and sequence number per record, so the worst outcome is losing the newest update rather than all configuration.

Never erase the only valid copy. I use two flash sectors, or a log of records across several, each record carrying a header: a magic value, a format version, a sequence number, the length and a CRC over everything.

To save, write the new record to the inactive sector, read it back and check the CRC. Only then is it considered valid, and it wins because its sequence number is higher. The old copy stays intact until the next save erases its sector. At boot, scan both, discard any with a bad magic or CRC, and choose the valid one with the higher sequence, comparing sequence numbers so that wrap-around is handled. If neither is valid, load safe defaults and record the event.

For wear, append records to a sector until it is full before erasing, rather than erasing on every save, and check the endurance figure in the datasheet against the expected save rate over the product's life. The version field allows migration when the configuration structure changes in a firmware update. The test is a rig that cuts power at random points during saves, thousands of times, then checks that a valid configuration always loads.

Layer several defences, because the silent version, where the stack grows into .bss and corrupts variables, is one of the hardest bugs to trace.

• Pattern and watermark: fill stacks with a known value at start-up and check how far it has been overwritten. Cheap, good for sizing, but detects overflow only after the fact.
• Canary check: an RTOS can check the last words of a task stack at every context switch and call a hook. It catches most overflows, but not one that jumps over the canary with a large local array.
• MPU guard region: a small no-access region at the stack limit makes the overflowing access fault at once, at the exact instruction.
• Stack limit registers: ARMv8-M cores have MSPLIM and PSPLIM, which fault when the stack pointer passes a limit.

On a bare-metal system, a placement trick helps: put the main stack at the bottom of RAM, growing down towards the start of RAM, so an overflow runs into unmapped memory and faults instead of corrupting data.

Functional safety means the system stays safe when something fails, including the software. It starts with a hazard analysis, which produces safety goals and an integrity level: SIL under IEC 61508, ASIL A to D under ISO 26262 for road vehicles, with IEC 62304 for medical software and DO-178C for airborne software. The level decides how much rigour the process demands.

Day to day that means:

• a defined safe state, such as motor off or valve closed, reachable from any fault;
• diagnostics: RAM and flash tests at start-up and periodically, clock monitoring, a windowed watchdog, and program-flow monitoring that checks tasks run in the expected order;
• plausibility checks on inputs: range, rate of change and agreement between redundant sensors;
• independence where required: a second channel or a separate monitor MCU;
• traceability from each requirement to code and tests, and structural coverage, up to MC/DC at the highest levels.

Even outside certified projects, I apply the safe-state and plausibility habits to anything that moves or heats.

Write a fault handler that finds the stacked exception frame. A short assembly stub tests bit 2 of EXC_RETURN in LR to see whether the main or process stack was in use, and passes that stack pointer to a C function. From the frame, read the stacked PC, which points at or just after the faulting instruction, and the stacked LR, which shows the caller.

Then read the fault status registers. The configurable fault status register says which kind: a precise bus error with a valid bus fault address (a bad pointer), an imprecise bus error (a buffered write whose address is lost), an undefined instruction, an invalid state fault (often a call through a null or corrupt function pointer with the Thumb bit clear), an unaligned access or a divide by zero if trapping is enabled. The HardFault status register shows whether a configurable fault was escalated.

For an imprecise fault on a Cortex-M3 or M4, disabling the write buffer while debugging makes it precise. In the product, the handler saves the registers to a no-init RAM area and resets, and the next boot reports them, so field faults become a PC address I can resolve with addr2line.

JTAG is the IEEE 1149.1 interface with four or five signals, boundary scan for board testing, and daisy-chaining of several chips. SWD is Arm's two-wire debug interface for Cortex-M, with the same debug features and fewer pins. Through either, a probe can halt the core, read and write memory and registers, flash the part and set breakpoints and watchpoints.

Hardware breakpoints are limited to a handful of comparators, which matters for code in flash. Data watchpoints from the DWT unit are the best tool for "who is corrupting this variable": the core halts on the write that does it. SWO adds a single trace pin that streams printf-style output through the ITM, interrupt events and periodic PC samples. A RAM ring buffer read by the probe in the background gives fast logging without a UART.

The caution: halting the core does not halt the outside world. A motor controller stopped at a breakpoint with PWM outputs active can destroy hardware. Configure timers to freeze or force outputs safe in debug halt, and prefer non-halting tools on live machinery.

HIL testing runs the real firmware on the real board while a rig simulates the environment around it and checks the outputs, under control of a test script on a host. It sits above host-based unit tests, which check logic, and pure simulation, which checks algorithms, and catches the problems those miss: timing, peripheral configuration and integration.

For a motor controller I would include: a programmable supply that can sag and cut out, simulated encoder or Hall signals, a load or a small motor on a dynamometer, a CAN interface to send commands and inject corrupt or missing frames, and measurement of the PWM outputs and phase currents. Fault injection is where the value lies: disconnect a sensor, short a phase input, stop the command stream, and check that the controller reaches its safe state within the required time.

The rig flashes every merged build and runs a suite in CI. The hard part is keeping tests deterministic and the rig maintained, so tests check behaviour with tolerances and log enough data to diagnose a failure without rerunning.

A bug that moves when timing or code layout changes points to a short list:

• a missing volatile, so at -O2 the compiler keeps a polled flag in a register;
• undefined behaviour that the optimiser exploits only at higher levels;
• an uninitialised local whose stack contents differ with each build;
• a race between an ISR and the main loop, where printf's delay changes the interleaving;
• stack overflow, since printf and optimisation change stack depth;
• a buffer overrun that hits a different neighbour when the layout changes;
• missing barriers or cache maintenance around DMA.

The approach is to stop disturbing the system. Keep the failing build and use tools that do not change timing: a DWT watchpoint on the corrupted variable, a trace buffer in RAM, GPIO toggles on a logic analyser. In parallel, turn up warnings, run a static analyser, build the logic on the host with sanitisers, and compare map files between the good and bad builds to see what moved.

First validate the application: check a header with magic number, length and version, verify a CRC or, better, a signature, and refuse to jump to an invalid image. Then leave the hardware as close to reset state as possible: disable and clear every interrupt the bootloader enabled, stop SysTick, de-initialise peripherals and DMA it used, and restore the default clock if the application expects it.

Then the jump itself: set VTOR to the application's vector table, load the main stack pointer from the first word of that table, and branch to the reset handler address in the second word. The application must be linked at its own flash offset, and its start-up code must not reset VTOR back to the start of flash.

The common bugs: an interrupt left enabled by the bootloader fires before the application has set up its handler; the bootloader jumps from inside an ISR, so the application starts in Handler mode; and a shared RAM area for boot flags is overwritten because the two images have different memory layouts. I reserve a small no-init section at a fixed address in both linker scripts for that hand-over.

The linker script defines the memory regions, flash and RAM with their start addresses and sizes, and places each output section into them: the vector table at the start of flash, then .text and .rodata, .data in RAM with its load address in flash, then .bss, heap and stack. It also defines the symbols the start-up code uses, such as the start and end of .data and .bss and the initial stack pointer.

I edit it to put a function in RAM so it can run while flash is being erased, to create a no-init section that survives a soft reset for crash data, to place DMA buffers in a RAM bank the DMA can reach, or to align a buffer for the cache.

The map file is the linker's report: the address and size of every symbol, and which object file or library member pulled each one in. It is the first place to look when the image grows, for example when one call to printf with %f pulls in floating-point formatting code, and to confirm a buffer really landed in the intended region.

Measure before changing anything. size gives section totals, and the map file or nm --size-sort lists the largest symbols. The answer is usually a few big items, not many small ones.

Typical wins, in the order I try them:

• Check the optimisation level and link-time optimisation, and that unused sections are garbage-collected (-ffunction-sections, -fdata-sections, --gc-sections).
• Remove floating-point support from printf or use a smaller formatter.
• Replace assert messages and file-name strings with numeric codes in release builds.
• Check for accidental library code: software division on a core without a divide instruction, C++ unwind tables, iostream.
• Shrink large tables with smaller types, or compute them instead.
• Disable vendor library modules that are linked in but unused.

What I would not do is remove safety checks or error handling to make it fit. If the margin is that thin, I also raise the risk with the team, because the next feature or security fix will not fit either.

For individual code paths, the DWT cycle counter on Cortex-M3 and above is exact and cheap:

CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;
DWT->CYCCNT = 0;
DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;

uint32_t t0 = DWT->CYCCNT;
filter_step();
uint32_t cycles = DWT->CYCCNT - t0;   /* unsigned subtraction survives wrap */

On some cores the DWT lock access register must be written before it will count. For ISR durations, a GPIO set at entry and cleared at exit, viewed on a scope with persistence, shows both the typical and worst case.

For overall load, RTOS run-time statistics give the share of time in each task, and load is the complement of time in the idle task. A trace tool that records every task switch and interrupt shows where the busy periods are.

I start from requirements and work through a short list:

• Peripherals: the number and type needed, such as CAN FD channels, high-speed USB, ADC resolution and sample rate, advanced timers for motor control, and whether the pin multiplexing lets them all coexist on one package.
• Compute and memory: an estimate of cycles for the heaviest workload, plus headroom for features, and enough flash for two images if updates must be fail-safe.
• Power: current in each sleep mode with the needed peripherals running, and wake-up time.
• Environment: temperature range and qualification, such as automotive grade, and EMC behaviour.
• Security: secure boot, key storage, crypto acceleration, debug port locking.
• Supply and lifecycle: second sources, longevity commitments and current lead times.
• Ecosystem: toolchain, RTOS support, the vendor's libraries and the team's experience.

I prefer a family with pin-compatible larger and smaller members, so a memory shortfall late in the project is a part change rather than a board redesign, and I prototype the riskiest peripheral on a development board before committing.

Most loops have a screening call, a C or C++ coding round focused on bits, buffers, state machines and memory rather than complex algorithms, a fundamentals deep-dive on interrupts, concurrency, RTOS behaviour and peripherals, and a debugging or code review exercise. Senior loops add a system design round for a whole device and a discussion of past projects in technical depth. Some companies add a take-home task or a practical bring-up exercise on a development board.

Less than for general software roles, but not none. Expect arrays, ring buffers, linked lists, bit manipulation, simple sorting and searching, state machines and fixed-point arithmetic, written carefully in C with attention to memory and edge cases. Large companies with a shared interview process may still ask a standard algorithm question, so practise a set of common problems in C as well, for example on coding practice.

Prepare C thoroughly in any case, because register access, startup code and most vendor libraries are C, and fundamentals questions assume it. If the job advert mentions C++, also prepare modern C++ for constrained targets: RAII, constexpr, templates and their cost, and working without exceptions, RTTI or a heap. The C Roadmap and Modern C++ Roadmap roadmaps cover the language foundations.

It depends on the product. Many embedded roles are purely microcontroller and RTOS work, while gateway, camera and industrial controller roles are mostly embedded Linux. Strong candidates understand both well enough to choose between them and to design the boundary when a product uses both. If your background is only microcontrollers, building a small Buildroot image, writing a device tree node and talking to a sensor from user space gives you real material to discuss. The Linux Roadmap roadmap covers the basics.

The titles overlap, and companies use them inconsistently. A firmware interview, as on the Firmware Developer page, tends to go deeper into microcontroller bring-up, bootloaders and low-level peripherals. A Device Driver Developer interview focuses on kernel internals, driver models and concurrency inside an operating system. Embedded systems engineer interviews are often broader, covering hardware interaction, real-time design and system architecture, sometimes including sensor and control topics shared with the Robotics Software Engineer role.