Embedded systems fundamentals

That it exists to control something physical, and that the physical thing sets the requirements. A web service can be a second late and nobody dies; a motor commutation routine that is a hundred microseconds late destroys the motor. From that follow the properties people list as characteristics: fixed and small memory, no operating system or a very thin one, a single application that owns the whole machine, and a strong preference for behaviour that is predictable over behaviour that is fast on average. The consequence for interviews is that questions about worst cases matter more than questions about throughput, because the deadline is the requirement and the average is not.

A microcontroller integrates the CPU, its memory and its peripherals on one die, and it boots straight into your code out of on-chip flash. A microprocessor is a CPU that expects external DRAM, external storage, a bootloader and usually a full operating system with virtual memory. The practical differences that matter are memory scale, from tens of kilobytes against gigabytes, and memory protection: a microcontroller commonly has no MMU, so there is one flat address space with no process isolation and a bad pointer corrupts whatever it points at. Choosing between them is really choosing whether you want Linux and its ecosystem or determinism and instant boot.

That your code is the only software on the part. There is no scheduler, so nothing preempts your main loop except interrupts you enabled. There is no memory manager, so the addresses in your pointers are physical addresses of real SRAM and real peripheral registers. There is no driver layer unless you wrote it, so configuring a UART means writing specific bits into specific registers described in a reference manual. And there is no process to kill when something goes wrong, so an infinite loop is the end of the device until something resets it. The freedom and the exposure are the same fact.

Flash and RAM hold different things for different reasons, and candidates who blur them cannot explain start-up.

region  contents                          writable   survives power   who fills it
------  --------------------------------  ---------  --------------   ----------------------
flash   .text  machine code               no*        yes              programmer or bootloader
flash   .rodata constants, lookup tables  no*        yes              programmer or bootloader
flash   init images for .data             no*        yes              programmer or bootloader
RAM     .data  initialised globals        yes        no               start-up copy from flash
RAM     .bss   zero-init globals          yes        no               start-up memset to zero
RAM     heap   if present at all          yes        no               allocator at run time
RAM     stack  call frames, ISR frames    yes        no               hardware and compiler

* erasable and rewritable in blocks, but not byte-writable at run speed

The row that explains most confusion is .data. An initialised global costs you space twice: once in flash for the initial values and once in RAM for the live copy, plus start-up time to copy between them. A const table costs only flash, which is why moving a large lookup table to const can free kilobytes of RAM without changing a line of logic.

The other row worth reading carefully is flash's write behaviour. Flash is read like memory but written like a device: you erase a whole page, then programme within it, and both operations take orders of magnitude longer than a RAM write and often stall instruction fetch from the same bank. That is why a firmware update is a scheduling problem, not just a data-transfer problem, and why a variable you want to persist cannot simply be assigned to.

Nothing in the RAM rows survives a power cycle, which is why persistent settings need flash or an external EEPROM and a plan for what happens if power is lost half-way through writing them.

A hard real-time system has deadlines where a late answer is a wrong answer, and the design must guarantee the worst case rather than optimise the average. Soft real-time means lateness degrades quality — a dropped audio sample, a stuttering display — without making the result invalid. Firm sits between: the late result is useless but not dangerous. The distinction drives everything else. A hard deadline bans unbounded constructs, so no dynamic allocation in the path, no unbounded loops, no waiting on something with no timeout, and it forces you to be able to state the worst-case execution time of the code involved.

Jitter is the variation in when a periodic thing actually happens. A control loop nominally running every millisecond that in reality runs at 0.9 and then 1.1 milliseconds has 200 microseconds of jitter, and its average is perfect. It matters more than the average because control mathematics assumes a fixed sample interval: variable timing shows up as noise in the derivative term, as distortion in sampled audio, and as commutation error in a motor drive. Its usual sources are interrupts of differing duration, code paths with data-dependent branches, and cache or flash-accelerator behaviour that varies by address.

A hardware abstraction layer wraps peripheral registers in functions so application code says "send this buffer over SPI" rather than writing bits into a control register. A board support package is the layer above it that encodes the specific board: which pin the LED is on, which I2C address the temperature sensor answers to, what the crystal frequency is, and the pin multiplexing that routes internal peripherals to physical pins. The distinction matters because a HAL is portable across boards using the same chip family and a BSP is not, and mixing board-specific constants into driver code is the usual reason a firmware port to the next revision of the hardware takes weeks.

The reset vector runs long before your code, and a surprising number of bugs live in this window.

1. reset            core loads initial stack pointer and reset vector from flash
2. clocks           switch from internal RC oscillator to crystal or PLL, set flash
                    wait states BEFORE raising the core clock
3. .data copy       memcpy initialised globals from their flash image into RAM
4. .bss clear       memset zero-init globals to zero
5. C++ ctors        run static constructors, if any, in unspecified order
6. libc init        set up whatever the C library needs, including any heap base
7. main()           your code finally gets control

Steps two and three are where the interesting failures are. Raising the core clock before increasing flash wait states makes instruction fetch unreliable, and the symptom is a part that hangs or hard-faults at a clock speed the datasheet says it supports.

Steps three and four explain why a global initialised to a non-zero value is fine but a global whose initialiser calls a function is not necessarily so: the copy and clear are bulk operations over regions, not per-variable code. They also explain why anything the start-up code itself depends on cannot live in .data.

Between reset and step four, any global you read holds whatever was in SRAM from the previous run. That is normally invisible, and it becomes visible the moment you place a variable in a .noinit section deliberately to carry a crash record across a reset — at which point the ordering above is the specification you are relying on.

The last practical point is that an interrupt arriving before step four completes will run against globals that are neither copied nor cleared. Peripherals therefore stay unconfigured and interrupts stay masked until the C environment exists, which is why enabling an interrupt in a constructor is a mistake.

.rodata is constant data living in flash and never copied. .data is a global with a non-zero initialiser, costing both flash for the image and RAM for the live copy. .bss is a global that starts at zero, costing RAM only, since zeroing is done in bulk at start-up. Caring about the distinction is how you win RAM back: a large static const table declared without const silently becomes .data and consumes RAM equal to its size, and a string literal assigned into a char array is copied where a const char * would not be. Checking section sizes after a build is a two-second habit that catches this.

Because its worst case is unbounded and its failure has nowhere to go. Repeated allocation and release of differing sizes fragments the free space into gaps that sum to plenty while no single gap fits the next request, so a device runs for days and then fails in a way that depends on the exact order of every allocation since power-on. Allocator timing also varies with the state of the free list, which a hard deadline cannot accommodate. And a null return in a control loop has no graceful handling — a server can shed load, a sensor can only reset. Firmware therefore allocates at start-up and never frees, or uses fixed-size pools that cannot fragment.

You bound it and then measure it. The bound comes from the call graph: the deepest chain of frames, plus compiler spills at each level, plus the register context hardware pushes on interrupt entry, plus every interrupt that can nest on top of that worst-case point. Recursion and unconstrained function pointers make the bound uncomputable, which is why coding standards for critical firmware ban both. The measurement comes from filling the region with a known pattern at start-up, running the heaviest load you can construct, and reading how far the pattern was overwritten. The number you defend in review is that high-water mark against the allocation, with margin.

Nothing detects it. The stack simply keeps growing past its intended bottom into whatever is below, which is typically the heap or the top of .bss, and the writes succeed. The symptom therefore appears in an unrelated module: a state variable changes on its own, a calibration constant becomes nonsense, a flag reads back false immediately after being set. Because frame sizes shift when optimisation changes, the bug appears to move or disappear with compiler flags, which sends people hunting for a compiler bug. Making it loud is the fix: an MPU region with no access placed just below the stack, or a hardware stack-limit register where the core provides one.

A peripheral register is not memory, and the compiler cannot know that.

/* Peripheral status register at a fixed address. Without volatile the
   compiler may read it once and reuse the value, so this loop never ends. */
#define UART_STATUS  (*(volatile uint32_t *)0x40004018u)
#define UART_TXDATA  (*(volatile uint32_t *)0x4000401Cu)
#define TX_EMPTY     (1u << 7)

void uart_put(uint8_t byte) {
    while (!(UART_STATUS & TX_EMPTY)) { }   /* volatile forces a fresh read */
    UART_TXDATA = byte;
}

volatile tells the compiler that every read and write in the source must appear in the output, in that order, and that the value may change outside the program's control. Without it the loop condition is loop-invariant and may be evaluated once; with it the hardware is polled each time.

What volatile does not do is anything about the memory system between the core and the peripheral. A write may sit in a write buffer after the store instruction retires, so code that writes a register and then relies on the effect having landed — clearing an interrupt flag before returning from a handler, or disabling a peripheral before reconfiguring it — needs the write forced through, either by reading the register back or by a data synchronisation barrier.

It also does not give you atomicity. A read-modify-write of a register, such as setting one bit in a control word, is three operations, and an interrupt landing in the middle that touches the same register loses one of the two updates. Peripherals that expose separate set and clear registers exist precisely so this pattern can be avoided.

Finally, the pointer needs the right width and alignment. Many peripherals only respond correctly to accesses of a specific size, so reading a 32-bit register as two 16-bit halves may return garbage or fault.

It moves data between a peripheral and memory without the CPU touching each word, which removes per-byte interrupt overhead and lets the core sleep or work during a transfer. That turns a UART stream that would cost one interrupt per byte into one interrupt per buffer. The costs are ownership and visibility. The buffer must stay alive and untouched for the whole transfer, which rules out anything on a stack frame that may return; the CPU's view of that memory may be stale if a data cache sits in between, requiring explicit clean or invalidate operations; and a transfer that half-completes on an error leaves you having to work out how much arrived.

The sequence is short but every step is somewhere a bug hides.

sequenceDiagram
    participant P as Peripheral
    participant C as Interrupt controller
    participant CPU as Core
    participant H as Handler
    P->>C: Assert interrupt line
    C->>C: Compare priority with current level
    C->>CPU: Preempt if higher priority
    CPU->>CPU: Push register context onto stack
    CPU->>H: Vector to handler address
    H->>P: Clear source flag, read data
    H-->>CPU: Return, context popped

The comparison in the second step is the whole basis of real-time behaviour: an interrupt at or below the current execution priority is left pending rather than lost, and runs when the level drops. Candidates who describe interrupts as "immediate" have skipped it.

The push in the fourth step is why interrupt nesting is part of the stack budget rather than a separate concern. Each level of nesting costs another frame on the stack of whatever was running.

The gap worth looking at is between the handler clearing the source flag and the handler returning. Clear too early and an event arriving mid-handler is correctly re-latched as a new pending interrupt; clear on the last line and the write may still be in flight when the handler returns, so the controller sees the source asserted and re-enters the handler immediately. That double-entry looks like a hardware fault and is a software ordering bug.

Block, allocate, log, or take long. It must not block because there is no context to suspend — waiting on a mutex a task holds cannot resolve, since the task cannot run to release it, so the device hangs rather than waits. It must not allocate, because allocator state is shared with whatever it interrupted and is not reentrant. It must not call formatted printing, for the same reentrancy reason plus a cost measured in milliseconds. And it must not run long, because its duration is added to the worst-case latency of every source at or below its priority, so the damage shows up in an unrelated subsystem.

It guarantees that each access in the source produces an access in the output, at that point, so the compiler cannot cache the value in a register or elide a repeated read. That is the whole guarantee. It does not make an access atomic: a 64-bit counter, a struct, or a 32-bit value on an 8-bit core is written in pieces, and an interrupt landing between the pieces lets the reader compose a value that was never written. It does not order accesses to other objects, and on a system with caches or write buffers it does not force a write to reach the device. Those need atomics, masking, or barriers respectively.

Two 32-bit halves of a timestamp, written by an interrupt handler and read by the main loop.

volatile uint32_t tick_hi, tick_lo;    /* handler advances lo, carries into hi */

uint64_t now_broken(void) {            /* wrong */
    return ((uint64_t)tick_hi << 32) | tick_lo;
}

uint64_t now(void) {                   /* right, and never masks interrupts */
    uint32_t hi, lo;
    do {
        hi = tick_hi;
        lo = tick_lo;
    } while (hi != tick_hi);           /* retry if the handler carried mid-read */
    return ((uint64_t)hi << 32) | lo;
}

The broken version fails roughly once every four billion ticks, at the instant tick_lo wraps and tick_hi increments. The reader loads the old high word, the handler runs, and the reader then loads the new low word, producing a timestamp that jumps backwards by about 2^32 ticks. Downstream arithmetic on that value yields an enormous elapsed time, so a timeout fires instantly or a rate calculation reads as zero.

The fix re-reads the high word and retries when it changed, which is the sequence-counter idea in its simplest form. It costs one extra load in the common case, never disables interrupts, and terminates because the handler cannot carry twice within a few instructions.

The alternative most people reach for is masking interrupts around the read. That is also correct and costs every interrupt source in the system a few microseconds of latency each time the main loop asks the time — which, in a loop that asks constantly, is not free. Knowing that both options exist and what each costs is the answer being looked for; reaching for volatile alone and stopping is the failure.

It is a span of code executed with interrupts masked, which is the only universally available mutual exclusion when one of the parties is an interrupt handler. The cost is paid by everyone: for the duration, no interrupt at the masked level can be serviced, so the worst-case latency of every such source grows by the length of your critical section. That makes length the entire discipline — you mask, touch the shared object, and unmask, with no loops, no function calls into code you have not audited, and certainly no waiting. Masking must also save and restore the previous state rather than unconditionally enabling, or a nested critical section unmasks early.

Because each index has exactly one writer, which removes the need for mutual exclusion entirely.

#define N 64                          /* power of two so masking replaces modulo */
static uint8_t buf[N];
static volatile uint16_t head, tail;  /* head: producer only. tail: consumer only. */

bool push(uint8_t b) {                /* called from the ISR */
    uint16_t next = (head + 1u) & (N - 1u);
    if (next == tail) return false;   /* full: drop and count it */
    buf[head] = b;                    /* write data BEFORE publishing the index */
    head = next;
    return true;
}

bool pop(uint8_t *out) {              /* called from the task */
    if (tail == head) return false;   /* empty */
    *out = buf[tail];
    tail = (tail + 1u) & (N - 1u);
    return true;
}

The invariant is that the producer only ever writes head and reads tail, and the consumer only ever writes tail and reads head. Each index is therefore updated by a single thread of control, so there is no read-modify-write race on either one, provided the index type is written atomically by the hardware.

The ordering inside push is the part that gets omitted. The byte must be stored before head advances, because advancing head is what makes the slot visible to the consumer. On a core with a store buffer or an out-of-order pipeline that ordering needs a write barrier between the two lines, not merely volatile.

Full and empty are distinguished by keeping one slot unused, which is why a buffer of 64 slots holds 63 bytes. The alternative is a separate count, which reintroduces a variable both sides write.

The operational point candidates skip: overflow here is silent. A dropped byte is indistinguishable from a byte that never arrived unless push increments a counter that something eventually reports, and the field failure it causes is a corrupt protocol frame with no explanation.

Four pieces. First, hardware recognition and vectoring, which includes pushing the register context and is fixed for a given core. Second, any time spent with the interrupt masked, whether by an explicit critical section or by a driver's own locking. Third, execution of any handler at equal or higher priority that is already running or arrives first. Fourth, on some parts, the time to finish a non-interruptible instruction or a stalled bus access. Only the first is in the datasheet. The other three are properties of your firmware, which is why the honest answer to "what is our interrupt latency" is a measurement, not a number from a manual.

Any race with one party in interrupt context, because the handler cannot block and so cannot wait for the lock. If a task holds the mutex when the interrupt fires, the handler either has to give up or hang the system. The available fixes are structural instead: mask interrupts briefly, use a data structure where each side owns its own indices, use a hardware atomic such as a load-exclusive and store-exclusive pair, or have the handler only enqueue and let all real work happen in task context where locking is legal. Choosing between those, rather than reaching for a lock, is what the question is checking.

You need one when independent activities have independent timing and one of them can block. Three sensors at different rates, a network stack that waits, and a user interface that must stay responsive are naturally three tasks, and expressing them in one loop means hand-writing a scheduler badly. You do not need one when the work is periodic and short, which a timed superloop handles with less RAM, no per-task stacks, and behaviour you can reason about by reading top to bottom. The cost of an RTOS is a stack per task, the scheduler's own footprint, and a class of bugs — priority inversion, unbounded blocking, stack overflow per task — that a superloop cannot have.

Under preemption the scheduler can take the CPU from a running task the moment a higher-priority task becomes ready, typically on a tick or on an interrupt that signals it. Under cooperation a task runs until it yields, so switches happen only at points the programmer chose. Preemption gives you responsiveness bounded by priority rather than by the longest-running task, at the price that any shared data may be interrupted mid-update and needs protection. Cooperation gives you almost free mutual exclusion between tasks and makes one badly written function able to stall the whole system. Most small systems end up preemptive because one blocking library forces it.

With utilisation arithmetic done aloud, which is what the interviewer wants to hear.

task      period    worst-case exec    utilisation
--------  --------  -----------------  -----------
control    1 ms      0.30 ms            0.300
sensor    10 ms      1.20 ms            0.120
radio     50 ms      8.00 ms            0.160
logging  100 ms      6.00 ms            0.060
                                        -----------
                                total   0.640

Rate-monotonic sufficient bound for n = 4:  4 * (2^(1/4) - 1) = 0.757
0.640 < 0.757  ->  schedulable under fixed priorities by rate

Priorities are assigned by rate, shortest period highest, which is what rate-monotonic means. The bound is Liu and Layland's, and it tends to about 0.693 as the number of tasks grows, so 69% utilisation is the pessimistic figure worth remembering.

The bound is sufficient but not necessary. Failing it does not prove the set is unschedulable; it means you need exact analysis, typically response-time analysis, which accounts for the actual periods rather than assuming the worst arrangement. A set at 0.85 utilisation with harmonic periods can be perfectly fine.

What the arithmetic assumes is where the interview goes next. It assumes the execution figures are true worst cases, that tasks are independent, and that nothing blocks. Every one of those is false in practice: interrupt handlers steal time above all tasks and are not in the table, a shared mutex introduces blocking that must be added to the higher-priority task's response time, and a worst-case execution time obtained by measuring average behaviour is not a worst case. Presenting the table and then naming its assumptions is a far stronger answer than the number alone.

A high-priority task blocks on a resource held by a low-priority task, so it waits — which is expected. The inversion is what happens next: a medium-priority task that needs nothing preempts the low-priority holder, so the high-priority task now waits behind a task it outranks, for an unbounded time. Priority inheritance fixes the basic case by temporarily raising the holder to the waiter's priority so it cannot be preempted by anything in between. The priority ceiling protocol goes further, giving each resource a ceiling equal to the highest priority that may take it, which bounds blocking to one critical section and prevents deadlock between chained locks.

A mutex protects a resource, has an owner, and is therefore the only one of the three that can implement priority inheritance — because there is a specific task to promote. A counting semaphore counts availability of interchangeable things, or signals events, and has no owner, so a task may release one it never took. A queue moves data and ownership together, which usually removes the need for shared mutable state altogether. The practical rule is that the shortest path to correct concurrency is a queue: if a task owns a resource and others send it requests, there is no lock to invert and no shared object to protect.

Because a task can be preempted mid-call, so its live call frames must persist while another task runs, and one shared stack cannot hold two interleaved call chains. The cost is that RAM is now divided into fixed per-task allocations, each sized for that task's worst-case depth plus interrupt frames, and the sum is committed whether the tasks are deep or shallow. That is the concrete reason an RTOS costs RAM: ten tasks with 1KB stacks each is 10KB gone before your buffers. Undersizing one of them produces corruption in an unrelated task, which is why per-task high-water-mark checks are standard practice.

When every activity can be expressed as work that never blocks. If each subsystem is a function that examines its state, does a bounded amount of work, and returns, then a loop calling all of them in order gives you deterministic timing, one stack, no scheduler, no locks and a trace you can read in a debugger. The technique that makes it possible is turning every wait into a state: instead of blocking for a sensor conversion, record that a conversion is in flight and return. The cost is that a genuinely long operation must be manually chunked, and code written this way is harder to read than the blocking equivalent.

Almost every board carries all three, and the choice is usually forced by the sensor.

             UART              SPI                    I2C
-----------  ----------------  ---------------------  -------------------------
wires        2 plus ground     3 plus one CS each     2, both open-drain
clock        none, async       controller drives      controller drives
speed        slow, kbaud       fastest, tens of MHz   100k / 400k / 1M typical
addressing   none, point to    one chip-select line   7-bit address on the bus
             point             per device
duplex       full              full                   half
ack          none in the       none in the protocol   per byte, in hardware
             protocol
fails as     framing errors    silent wrong data if   whole bus hangs if a
             on rate mismatch  a mode bit is wrong    device holds SDA low

Read the bottom two rows first, because they are where the debugging time goes. I2C's per-byte acknowledgement means you can tell a missing device from a misbehaving one immediately, which is why it is pleasant for slow sensors. SPI has no acknowledgement at all, so a mismatched clock polarity or phase produces plausible-looking numbers rather than an error, and the only way to find it is a scope.

The wire count row explains the ecosystem. I2C needs two lines regardless of how many devices you hang on it, so a board with eight sensors uses two pins; SPI needs an extra pin per device but goes an order of magnitude faster, so it wins for displays, flash and anything streaming.

UART's lack of addressing and clock is why it survives for point-to-point links, console output and radio modules, and why it is the wrong choice for a bus of sensors.

Because both lines are open-drain with pull-up resistors, so any device can hold a line low and every other device sees a busy bus. The classic case is a peripheral reset mid-transaction while it was driving a data bit low: it is waiting for clocks that will never come, and the controller sees the data line stuck. Recovery is to generate clock pulses manually, up to nine of them, so the stuck device finishes the byte it thinks it is transmitting and releases the line, then issue a stop condition. Firmware that talks to a bus with removable or separately powered devices needs that routine, plus a timeout on every transaction.

Chip select is the addressing mechanism: rather than sending an address on the bus, the controller pulls one device's select line low, and that device is the only one that drives the data-out line or acts on clocks. It also frames the transaction, so many devices treat a rising select as "discard whatever partial word you received". The speed difference comes from the electrical design. SPI's push-pull outputs drive edges hard, while I2C's open-drain outputs rely on a pull-up resistor to bring the line high, and that RC rise time is what caps the clock. It is also why I2C timing degrades as you add capacitance to the bus.

Because it was designed for a noisy, safety-relevant multi-node network with no single controller. Signalling is differential over a twisted pair, which rejects the common-mode noise an engine bay generates. Arbitration is non-destructive and priority-based: nodes start transmitting simultaneously, a dominant bit wins over a recessive one, and the loser backs off without the winner's message being corrupted, so the highest-priority frame always gets through with bounded latency. Messages are addressed by identifier rather than by node, so a sensor broadcasts and any number of consumers subscribe. Error detection and automatic retransmission are in the controller hardware, and a persistently faulty node takes itself off the bus.

As consistent, structured corruption rather than random noise. A receiver clocking slightly fast or slow samples bits at drifting positions, so the first character of a burst often arrives correctly and later ones do not, and you see framing errors because the stop bit is sampled while the line is still a data bit. A useful signature is that the same wrong byte appears for the same input every time. Confirming it means measuring one bit period on a scope or logic analyser and comparing with the nominal rate — a device configured for 115200 sending at 117000 is a clock or divisor calculation error, not a wiring problem.

More than direction. A pin has a function multiplexer selecting whether it belongs to your code or to a peripheral, a direction, a drive strength and slew rate on outputs, an output type of push-pull or open-drain, and an optional internal pull-up or pull-down on inputs. The pull resistor defines the level when nothing is driving the pin, which is what makes a button work: the pull holds the input high and pressing pulls it to ground. It also matters for reset behaviour, since a pin returns to input at reset and the pull decides what any external circuit sees while firmware is not yet running.

Resolution is the number of output codes — a 12-bit converter has 4096 — and it tells you the smallest change the converter can represent, not the smallest change it can correctly measure. Accuracy is how close the reported value is to the true voltage, and it is eroded by offset and gain error, integral and differential non-linearity, reference voltage tolerance and drift, and noise from the board and the supply. A 16-bit converter with a noisy reference can carry fewer trustworthy bits than a clean 12-bit one, which is why effective number of bits is the figure that matters. Reporting a 16-bit reading to five decimal places is a recognisable error.

The transaction shape is the same for almost every register-based sensor, and knowing it means you can bring up a part from its datasheet alone.

sequenceDiagram
    participant M as Controller
    participant S as Sensor
    M->>S: START plus address with write bit
    S-->>M: ACK
    M->>S: Register number to read
    S-->>M: ACK
    M->>S: REPEATED START plus address with read bit
    S-->>M: ACK then high byte
    M->>S: ACK
    S-->>M: Low byte
    M->>S: NACK then STOP

The step that carries the meaning is the repeated start. A plain stop followed by a fresh start would release the bus in between, letting another controller interleave its own transaction and leave the sensor's internal register pointer somewhere else. The repeated start keeps the bus held, so the address write and the data read are one indivisible operation.

The final NACK is the other detail people omit. The controller signals the end of a read by not acknowledging the last byte; acknowledge it instead and the sensor drives another byte, and the transaction desynchronises.

Every acknowledgement in that diagram is a place the transaction can fail, and each failure means something different. No acknowledgement to the address means nothing is at that address, so check wiring, the address pin strapping, and whether the datasheet quoted the address shifted by one bit. Acknowledgement to the address but not to the register number usually means the device is present but held in reset or unpowered on its digital side.

Almost always into the radio, and not into the processor. A node that wakes, samples, and transmits spends microamps asleep, a few milliamps computing for a millisecond, and often ten or more milliamps transmitting for several milliseconds. Multiply current by time and the transmission dominates by a wide margin. The design consequence is that optimising the firmware's execution speed barely moves the battery life, while sending half as often, or sending fewer bytes, moves it enormously. Candidates who start with clock speed and instruction counts have optimised the smallest term and will be asked why the battery life did not change.

They are a graded set of trade-offs between how much of the chip keeps its state and how quickly it can resume. A light mode typically stops the core clock while leaving RAM, peripherals and most interrupt sources live, so any interrupt resumes execution in microseconds. Deeper modes power down peripherals and clock domains, so only a few sources remain — a low-power timer, a pin change, a watchdog — and wake takes longer because clocks must restart and stabilise. The deepest modes lose RAM contents except for a small retained region, so waking is effectively a reset with a flag. The wake source list per mode is the part you read from the datasheet, and it dictates the architecture.

Suppose a coin cell with roughly 200mAh usable, a node that wakes once a minute, and these figures for one cycle.

phase        current    duration     charge per cycle
-----------  ---------  -----------  -----------------
sleep         2 uA      59.99 s      0.0333 uAh
wake + ADC    3 mA       1.0 ms      0.00083 uAh
radio TX     12 mA       4.0 ms      0.0133 uAh
                                     -----------------
                         per cycle   0.0475 uAh
                         per hour    60 cycles -> 2.85 uAh
                         per day     68.4 uAh

200 mAh / 68.4 uAh per day  =  approximately 2900 days

The figures are illustrative, but the shape of the result is the point. Sleep contributes 0.0333 of the 0.0475, so the two active phases together are less than a third of the budget even though the radio draws six thousand times the sleep current — because it is on for four milliseconds a minute.

That immediately tells you where the optimisation is. Halving the sleep current nearly halves total consumption. Halving the transmit time saves about 14%. Making the code twice as fast saves under 1%. A candidate who proposes optimising the ADC path here has read the current column and not the product.

The arithmetic also flatters reality in two ways worth naming unprompted. Coin cells have significant internal resistance that rises as they deplete, so a 12mA pulse causes a voltage droop that can trigger a brownout reset long before the nominal capacity is used — which is why such designs put a capacitor next to the radio. And self-discharge sets a ceiling on calendar life regardless of load, so a computed eight years is not eight years.

It means running at the highest clock available so the work finishes sooner and the part returns to a low-power state, on the reasoning that active energy is roughly work done rather than time spent while sleep saves the most. It is usually right on parts where leakage is small relative to dynamic power, and where wake-up overhead is significant. It becomes wrong when static leakage dominates, since finishing a task faster at a higher voltage can cost more than running slowly, and when the workload is memory-bound and the core spends its extra clocks stalled. It is also wrong if the higher clock requires a voltage step whose transition energy exceeds the saving.

A brownout is the supply sagging below the level the part needs while remaining high enough to keep it partly running. Logic then behaves unpredictably rather than stopping: flash writes complete partially, RAM bits flip, and the core may execute instructions it fetched incorrectly. That is how a settings page becomes corrupt or a bootloader becomes unbootable. The defence is a brownout detector that forces a clean reset at a defined threshold, before behaviour becomes undefined, plus writing persistent data in a way that survives interruption — two copies with a validity marker, or a journal, rather than overwriting in place.

Because a CMOS input left undriven sits at an indeterminate voltage that can hover near the switching threshold, and both transistors in the input stage then conduct at once. The pin draws current continuously, which on a device budgeted for microamps of sleep current is enough to dominate the entire budget. It also makes the input value arbitrary and noise-sensitive, so any code reading it behaves randomly. The fix is that every pin has a defined state: driven as an output, or an input with a pull enabled, or configured as analogue with the digital input stage disabled. Unused pins included.

Three techniques cover most of it. Toggle a spare GPIO high at the start of a region and low at the end, then measure with an oscilloscope or logic analyser — this costs a couple of instructions, does not perturb timing meaningfully, and gives you the distribution and the worst case rather than an average. Read a free-running cycle counter at entry and exit, accumulating minimum, maximum and count into a structure you can dump later. And for interrupt-heavy code, drive a different pin per handler so the analyser shows you the actual interleaving, which is how you discover that two handlers you assumed were independent overlap.

Access that does not depend on your firmware working. Over SWD or JTAG the probe talks to a debug unit in the silicon, so it can halt the core, read and write memory and registers, set hardware breakpoints and watchpoints on data addresses, and read the state of a part that has hard-faulted or hung — none of which requires your code to be executing correctly. It can also programme flash and reset the part into a known state. Printf, by contrast, needs a working clock, a configured peripheral, a main loop that still runs, and it perturbs the timing of the thing you are measuring.

The core stacks enough context to walk back to the faulting instruction, which turns an unexplained hang into a line number.

On exception entry an ARMv7-M core pushes eight words:

  SP+0x00  R0
  SP+0x04  R1
  SP+0x08  R2
  SP+0x0C  R3
  SP+0x10  R12
  SP+0x14  LR      return address of the interrupted function
  SP+0x18  PC   <- the instruction that faulted
  SP+0x1C  xPSR

Procedure:
  1. read the fault status registers to learn WHY  (bus fault, unaligned
     access, undefined instruction, escalated from a configurable fault)
  2. read the faulting address register if the cause was a data access
  3. take the stacked PC and look it up in the linker map or with addr2line

The stacked PC is the whole trick. A debugger stopped in the fault handler shows you the handler, which tells you nothing; the value at offset 0x18 in the stack frame the exception pushed is the address in your code, and resolving it against the map file names the function.

Which stack to read is the detail that catches people. The frame may be on the main stack or the process stack depending on what was running, and the exception return value in the link register tells you which — read the wrong one and you will chase an address that means nothing.

The two most common causes are worth memorising because they present identically. A null or wild pointer dereference gives a bus or memory-management fault with the bad address in the fault address register. A corrupted stack gives a fault at a nonsensical PC, because the return address was overwritten, and the giveaway is that the stacked PC does not correspond to any function.

Production firmware should capture this frame automatically: copy the cause, the address and the stacked PC into a region the start-up code does not clear, then reset and report it on the next boot.

It is an independently clocked counter that resets the part if firmware fails to refresh it in time, and its value comes entirely from that independence — it keeps counting through a deadlock, a wild jump or a lost PLL. Where it is refreshed decides whether it works at all. Refreshing from a periodic interrupt handler reduces it to a check that the interrupt controller still functions, since the handler keeps running while the application is wedged. The correct pattern is one refresh site that fires only after every supervised task has recorded real progress since the last check, so doing nothing is the mechanism by which a stall is caught.

Several routes, in rough order of preference. A trace pin driven by the core's instrumentation unit carries printf-style output over the debug connector you already have, costing one pin and very few cycles. Where the probe supports it, writing into a RAM buffer that the probe reads out while the target runs gives you logging with almost no target-side cost and no dedicated pin at all. Failing both, keep a wrapping log in a RAM region the start-up code does not clear and dump it over whatever link exists on the next boot, which also means a crash record survives the reset that followed it.

By what makes it move. An optimisation-sensitive bug appears or disappears with the compiler flags and is deterministic at each setting: the usual causes are a missing volatile, undefined behaviour the optimiser exploited, or reliance on a variable's incidental placement. A timing bug is non-deterministic at a fixed build and moves when you change interrupt rates, clock speed or load: the usual causes are an unprotected shared variable, a race between a handler and the main loop, or an assumption about ordering. The distinguishing experiment is to keep the binary identical and vary the load, then keep the load identical and vary the build.

That every failure leaves a device that still boots. In practice: two image slots so the new image is written to the inactive one while the running one is untouched, a signature and a checksum verified before the switch so a truncated or tampered image is never executed, an atomic commit — a single flag or pointer write — so power loss lands on one side or the other, and a rollback triggered by the new image failing to confirm itself within a few boots. The bootloader itself must be immutable or updated by a separate, much more conservative path, because a bad bootloader is a device that needs physical recovery.

Because flash can be written incompletely — a truncated transfer, a power loss mid-programme, a bad block — and executing a partially written image produces arbitrary behaviour rather than an obvious failure. A checksum verified at boot converts that into a detectable condition you can respond to by rolling back. What it does not tell you is that the image is authentic: anyone able to write flash can recompute the checksum, so integrity against accident is not integrity against an attacker. That needs a signature verified against a key the device holds and cannot be persuaded to replace, which is a different mechanism with different failure modes.

Whether you reason about worst cases and about physical constraints you cannot negotiate with. A backend round rewards throughput, scale and abstraction; an embedded round asks how much RAM that costs, how long the interrupt is masked for, what happens when the supply sags, and what the device does when the thing it talks to stops answering. It also assumes fluency in C at the level of pointers, storage classes and bit manipulation, and comfort reading a datasheet. The register shift most candidates need is from "here is a design that works" to "here is a design plus the number that proves it fits".

By reasoning from the class of device rather than bluffing a specific. Say what you would look up and why: the wake sources available in each sleep mode, whether the peripheral supports DMA, what the errata list says, whether the timer is 16 or 32 bits. Then describe how you would bring it up — get a pin toggling first to prove clocks and the toolchain, then the debug connection, then one peripheral. That answer demonstrates the actual skill, which is systematic bring-up from documentation, and it is far stronger than a half-remembered register name that turns out to belong to a different family.

Whether you know what has to be true before a pin can move. The answer is a sequence: enable the clock to that peripheral's domain, configure the pin's function multiplexer to plain output, set direction and output type, then drive the pin and delay.

/* The order matters. A register write to an unclocked peripheral is
   silently discarded on many parts, which is why the LED stays dark. */
enable_peripheral_clock(GPIO_PORT_A);   /* 1. clock first, always */
pin_set_mode(PORT_A, PIN_5, MODE_OUTPUT);
pin_set_output_type(PORT_A, PIN_5, PUSH_PULL);

for (;;) {
    pin_write(PORT_A, PIN_5, 1);
    delay_ms(500);                      /* a busy loop here is a talking point */
    pin_write(PORT_A, PIN_5, 0);
    delay_ms(500);
}

The clock line is the whole question. Writing configuration to a peripheral whose clock is off is discarded without error on most microcontroller families, and it is the single most common reason a first bring-up produces nothing.

The delay is the follow-up, and it is where a good candidate volunteers the trade. A busy loop burns the CPU and its duration depends on the compiler and the clock, so it is fine for a bring-up and wrong for a product. Saying so unprompted, and offering a hardware timer or an RTOS delay instead, moves the conversation to where the interviewer wanted it.

The third thing to volunteer is the electrical half: whether the LED is wired to sink or source current, because that decides whether a one lights it or extinguishes it, and whether the series resistor is sized for the pin's current limit.

Precisely about your boundary and honestly about the rest. Say what you owned — the driver, the protocol layer, the power state machine — and describe the hardware in terms of what it required of your firmware: the sensor needed 40 milliseconds after power-up before it would answer, the radio had to be reset explicitly because it did not restart with the MCU. That framing shows you understood the system without claiming to have designed the board. Claiming schematic work you did not do collapses immediately, because the follow-up question is always a specific one about a component choice.

The ones where the language's rules bite hardware code.

const uint8_t *p;        /* pointer to const data: *p is read-only, p can move  */
uint8_t *const q;        /* const pointer: q cannot move, *q is writable        */
volatile uint32_t *r;    /* every access to *r must actually happen             */

uint8_t a = 0xF0, b = 0x0F;
int      c = a + b;      /* both promoted to int: the sum is 0xFF, not truncated */
uint8_t  d = a << 4;     /* promoted, shifted, then truncated back: d is 0x00    */

struct { uint8_t x : 3; uint8_t y : 5; } f;
/* bitfield ordering, padding and straddling are implementation-defined,
   so this is the wrong tool for a hardware register layout */

The pointer declarations come up because register access needs volatile in exactly the right position, and volatile uint32_t * versus uint32_t * volatile mean entirely different things — the first is a normal pointer to a volatile register, which is nearly always what you want.

Integer promotion comes up because embedded code is full of narrow types and shifts. Every operand narrower than int is promoted before the operation, so intermediate results are wider than the variables suggest, and the truncation happens on assignment. That is a routine source of a mask that silently becomes zero.

Bitfields come up as a trap rather than a technique. They read beautifully as a register description and their layout is implementation-defined in bit order, alignment and whether a field may straddle a storage unit, so the same header compiled by a different toolchain describes different hardware. Explicit masks and shifts are verbose and portable, and saying that is the answer being looked for.

A strong answer starts by refusing to guess and instead making the failure observable, because the defining feature of the problem is that it is rare and remote. That means establishing what the device can tell you after the fact: is the reset counter increasing, what does the reset cause say, is there a surviving crash record with a stacked program counter in it, and does the failure correlate with anything in the environment such as temperature, radio traffic, supply activity or a particular peripheral being present. If none of that instrumentation exists, adding it is the first fix to ship, because a once-a-day fault with no telemetry cannot be debugged at all.

evidence on the next boot            what it rules in                  first probe
----------------------------------  --------------------------------  ---------------------------
watchdog reset, crash record valid  software hang or deadlock         stacked PC, check-in mask
watchdog reset, no crash record     corruption before the record ran   stack high-water mark
brownout indication                 supply droop under load pulse     scope the rail during TX
external pin reset                  wiring, connector, EMI            wiggle test, shield check
no reset, device unresponsive       wedged bus or peripheral          bus lines idle high?
no reset, device responsive but     protocol or server side, not      capture the last frame sent
data missing                        the device

Then a strong answer partitions the hypothesis space by what the evidence rules out. A watchdog reset with a valid crash record points at software: a stack overflow, a deadlock, a rare race between a handler and the main loop. A brownout indication points at the supply, and specifically at a current pulse coinciding with a depleted or cold battery. No reset at all, with the device simply unresponsive, points at a wedged peripheral or a hung bus, since the CPU never stopped. A once-a-day cadence is itself a clue worth chasing, because it suggests a counter wrapping, a scheduled task, or a daily environmental cycle rather than random corruption.

What a weak answer substitutes is a list of plausible causes with no way to discriminate between them, or a proposal to add a watchdog and move on. That last one is worse than doing nothing: it converts a visible failure into an invisible reboot, so the device appears healthy in every metric while doing its job intermittently. The specific thing an interviewer listens for is whether you treat a recovery mechanism as a way to keep the device alive while you collect evidence, or as the fix itself.