Firmware Developer Interview Questions

Firmware Developer Interview Questions and Answers

Questions

61 with model answers

Coding

10 exercises with solutions

Scenarios

5 design and debugging rounds

Roadmap

Firmware Developer roadmap and interview guide

How to use this page

1. Answer each question aloud before reading the model answer, in under two minutes, then compare structure as well as content: direct answer first, then reasoning, then the pitfall.
2. Write every coding exercise by hand in a plain editor, compile it with warnings on, and write your own small test harness before looking at the solution.
3. For each scenario, sketch a block diagram and a list of failure modes on paper, then read the walk-through and note what you missed.
4. Keep the datasheet and reference manual of one microcontroller family you know open while you study, and check every register claim against it.
5. Run the mock interview plan at least twice with a friend or a timer, and practise talking through code with the coding practice and AI code review round tools.

C for firmware: the language as the hardware sees it

Every firmware loop starts here: interviewers check that you know what the compiler is allowed to do with your code and how that meets real registers.

static inline void bit_set(volatile uint32_t *r, unsigned n)    { *r |=  (1u << n); }
static inline void bit_clear(volatile uint32_t *r, unsigned n)  { *r &= ~(1u << n); }
static inline void bit_toggle(volatile uint32_t *r, unsigned n) { *r ^=  (1u << n); }

uint8_t cmd = 0x0F;
if (~cmd == 0xF0) { /* never true */ }

Startup code, linker scripts and the memory map

Interviewers ask what happens between power-on and main because it shows whether you can bring up a new board and debug a part that never reaches your code.

.data : {
    _sdata = .;  *(.data*)  _edata = .;
} > RAM AT > FLASH
_sidata = LOADADDR(.data);

void jump_to_app(uint32_t base) {
    uint32_t sp = *(const uint32_t *)base;
    uint32_t pc = *(const uint32_t *)(base + 4u);
    __disable_irq();
    SysTick->CTRL = 0;                       /* stop the tick */
    for (int i = 0; i < 8; i++) {            /* disable and clear all IRQs */
        NVIC->ICER[i] = 0xFFFFFFFFu;
        NVIC->ICPR[i] = 0xFFFFFFFFu;
    }
    SCB->VTOR = base;
    __DSB(); __ISB();
    __set_MSP(sp);
    ((void (*)(void))pc)();                  /* never returns */
}

Interrupts, the NVIC and concurrency

Most field bugs in firmware are races between an interrupt and the code it interrupts, so this section gets the hardest follow-up questions.

uint32_t primask = __get_PRIMASK();
__disable_irq();
snapshot = shared;          /* copy, do not process, inside */
__set_PRIMASK(primask);

do {
    old = __LDREXW(&counter);
} while (__STREXW(old + 1u, &counter) != 0u);

Peripherals and register-level drivers

Expect to explain the wire-level behaviour of the buses you list on your CV, and how your driver copes when the other side misbehaves.

RTOS, scheduling and firmware architecture

Interviewers want to hear when an RTOS earns its cost, how you avoid the classic scheduling bugs, and how you structure firmware so it stays testable.

Bootloaders, OTA updates, secure boot and flash

A device that cannot be updated safely is a recall waiting to happen, so senior rounds spend a lot of time on update paths, power loss and the chain of trust.

Low power, watchdogs and fault handling

These questions test whether your devices last years on a battery and recover on their own when something goes wrong in the field.

Debugging, bring-up and testing

Panels want proof that you can bring up a board you have never seen and that your firmware is tested before it ships, not after it fails.

Fixed-point maths, data integrity and protocols

Firmware turns raw counts into physical values and bytes into messages, so interviewers check your numerical care and your framing and integrity choices.

static inline uint32_t get_be32(const uint8_t *p) {
    return ((uint32_t)p[0] << 24) | ((uint32_t)p[1] << 16) |
           ((uint32_t)p[2] << 8)  |  (uint32_t)p[3];
}

Coding exercises

Set a timer for 30 minutes per exercise. Write the code in an editor, compile it, and test the edge cases before you open the solution.

1. Read-modify-write a register bit fieldEasy · C

   Write reg_write_field(reg, pos, width, value) that sets a bit field of a 32-bit memory-mapped register without disturbing the other bits, and reg_read_field to read one back. Reject invalid positions and widths, and reject a value that does not fit in the field rather than silently truncating it. The register is volatile, and the function should perform exactly one read and one write.

   Hints

   1. Build the mask from the width first, and handle width 32 separately because shifting by 32 is undefined.
   2. Check whether the shifted value has any bits outside the mask.
   Solution and explanation

   #include <stdint.h>
   
   /* Mask of 'width' ones starting at bit 'pos'. width is 1..32. */
   static inline uint32_t field_mask(unsigned pos, unsigned width)
   {
       uint32_t ones = (width >= 32u) ? 0xFFFFFFFFu : ((1u << width) - 1u);
       return ones << pos;
   }
   
   /* Read-modify-write one bit field of a memory-mapped register.
      Returns 0 on success, -1 if the arguments are invalid. */
   int reg_write_field(volatile uint32_t *reg, unsigned pos, unsigned width,
                       uint32_t value)
   {
       if (width == 0u || width > 32u || pos > 31u || pos + width > 32u)
           return -1;
       uint32_t mask = field_mask(pos, width);
       if ((value << pos) & ~mask)      /* value does not fit in the field */
           return -1;
       if (width == 32u) {              /* whole register: plain write */
           *reg = value;
           return 0;
       }
       uint32_t v = *reg;               /* exactly one read ... */
       v = (v & ~mask) | ((value << pos) & mask);
       *reg = v;                        /* ... and exactly one write */
       return 0;
   }
   
   uint32_t reg_read_field(const volatile uint32_t *reg, unsigned pos,
                           unsigned width)
   {
       return (*reg & field_mask(pos, width)) >> pos;
   }

   The mask is width ones shifted to the field position. Width 32 is a special case because 1u << 32 is undefined behaviour in C, and interviewers often check that you know it. The function validates arguments first, then checks that the value fits; silently truncating a too-large value is a classic source of misconfigured peripherals.

   The body reads the register once into a local, modifies the local and writes it once. That matters because each access to a volatile object is observable: writing *reg &= ~mask; *reg |= value; creates an intermediate state in the hardware where the field is zero, which for a clock divider or a mode field can briefly put the peripheral into a wrong mode. Follow-ups to expect: this is still not atomic against an interrupt that writes the same register, so either mask interrupts around it or use hardware set and clear registers; and some registers contain write-one-to-clear flags, where any read-modify-write is dangerous.

2. Debounce a push buttonEasy · C

   A push button is sampled every millisecond from a timer tick. The contact bounces for up to about 10 ms on press and release. Write a debouncer that produces a clean state and a single press event per physical press. It must use no delays, no dynamic memory and constant time per tick, and it should work for several buttons by having one state struct each.

   Hints

   1. Think of a counter that integrates the raw input and saturates at both ends.
   2. Change the output state only at the ends of the counter range, which gives hysteresis.
   Solution and explanation

   #include <stdint.h>
   #include <stdbool.h>
   
   #define DEBOUNCE_MS 20u   /* input must be stable this long */
   
   typedef struct {
       uint8_t count;        /* integrator, 0..DEBOUNCE_MS */
       bool    state;        /* debounced output */
       bool    pressed_evt;  /* set on a clean released->pressed edge */
   } debounce_t;
   
   /* Call every 1 ms from a timer tick with the raw pin level
      (true = pressed). Integrator: count up while pressed, down while
      released, and only change state at the end stops. */
   void debounce_tick(debounce_t *d, bool raw)
   {
       if (raw) {
           if (d->count < DEBOUNCE_MS)
               d->count++;
       } else if (d->count > 0u) {
           d->count--;
       }
   
       if (d->count == DEBOUNCE_MS && !d->state) {
           d->state = true;
           d->pressed_evt = true;
       } else if (d->count == 0u && d->state) {
           d->state = false;
       }
   }
   
   /* Consume the press event; returns true once per press. */
   bool debounce_take_press(debounce_t *d)
   {
       bool e = d->pressed_evt;
       d->pressed_evt = false;
       return e;
   }

   This is an integrator debouncer. The counter moves up by one for each pressed sample and down by one for each released sample, saturating at 0 and at the threshold. The output changes to pressed only when the counter reaches the top and to released only when it reaches the bottom, so bounces in the middle move the counter back and forth without changing the state. That built-in hysteresis is what makes it reject noise.

   The press event is a latched flag set on the clean released-to-pressed edge and consumed by the application, so a slow main loop never misses a press and never sees two. Memory is two bytes and a flag per button, and each tick is constant time. Interviewers sometimes ask about using an edge interrupt instead; the answer is that edge interrupts on a bouncing contact fire many times, so you either disable the interrupt and confirm with a timer, or just sample as here.

3. CRC-16/CCITT for frame checkingEasy · C

   Implement CRC-16/CCITT-FALSE (polynomial 0x1021, initial value 0xFFFF, no reflection, no final XOR) for a byte buffer. The function must support streaming, so a frame can be checked in several chunks as it arrives. Then add a table-driven version and say when you would choose each. The check value for the ASCII string "123456789" is 0x29B1.

   Hints

   1. Feed each byte into the top of the 16-bit register, then shift eight times.
   2. The table entry for a byte is the CRC of that single byte with an initial value of zero.
   Solution and explanation

   #include <stdint.h>
   #include <stddef.h>
   
   /* CRC-16/CCITT-FALSE: poly 0x1021, init 0xFFFF, no reflection,
      no final XOR. Check value for "123456789" is 0x29B1. */
   uint16_t crc16_ccitt(uint16_t crc, const uint8_t *data, size_t len)
   {
       while (len--) {
           crc ^= (uint16_t)((unsigned)*data++ << 8);
           for (int bit = 0; bit < 8; bit++) {
               if (crc & 0x8000u)
                   crc = (uint16_t)(((unsigned)crc << 1) ^ 0x1021u);
               else
                   crc = (uint16_t)((unsigned)crc << 1);
           }
       }
       return crc;
   }
   
   /* Table-driven variant: 512 bytes of flash, one lookup per byte. */
   static uint16_t crc_table[256];
   
   void crc16_table_init(void)
   {
       for (unsigned i = 0; i < 256u; i++) {
           uint8_t b = (uint8_t)i;
           crc_table[i] = crc16_ccitt(0, &b, 1);
       }
   }
   
   uint16_t crc16_ccitt_fast(uint16_t crc, const uint8_t *data, size_t len)
   {
       while (len--)
           crc = (uint16_t)(((unsigned)crc << 8) ^
                            crc_table[(uint8_t)((crc >> 8) ^ *data++)]);
       return crc;
   }

   The bitwise version XORs each byte into the high byte of the CRC register, then for each of eight bits shifts left and XORs the polynomial whenever a 1 falls out of the top. Streaming works because the running CRC is the only state: pass the previous return value as the starting crc.

   The table version precomputes the effect of all eight shifts for each possible top byte, so each input byte costs one lookup, one shift and two XORs instead of a loop of eight. It costs 512 bytes, which can live in flash if generated offline as a const array. I choose bitwise when flash is very tight or throughput is low, the table for bulk data, and the hardware CRC unit when the part has one and it supports the right polynomial. Interviewers listen for knowing that "CRC-16" is not one algorithm: initial value, reflection and final XOR all vary, so the check value for "123456789" is how you confirm you match the other end.

4. Lock-free UART receive ring bufferMedium · C

   Write a single-producer, single-consumer byte ring buffer for UART reception. The receive interrupt calls rb_put; the main loop calls rb_get. Neither side may disable interrupts or block. When the buffer is full, the ISR drops the byte and counts an overrun. Use the whole buffer capacity, not capacity minus one, and explain why your code is safe on a Cortex-M.

   Hints

   1. Use free-running 32-bit head and tail counters and mask them only when indexing.
   2. The producer must make the byte visible before it publishes the new head.
   Solution and explanation

   #include <stdint.h>
   #include <stdbool.h>
   #include <stdatomic.h>
   
   #define RB_SIZE 256u                       /* must be a power of two */
   _Static_assert((RB_SIZE & (RB_SIZE - 1u)) == 0u, "RB_SIZE power of two");
   
   typedef struct {
       uint8_t buf[RB_SIZE];
       _Atomic uint32_t head;                 /* written only by producer (ISR) */
       _Atomic uint32_t tail;                 /* written only by consumer (main) */
       uint32_t overruns;                     /* producer-only statistic */
   } ringbuf_t;
   
   /* Producer side: called from the UART RX interrupt. Never blocks. */
   bool rb_put(ringbuf_t *rb, uint8_t byte)
   {
       uint32_t head = atomic_load_explicit(&rb->head, memory_order_relaxed);
       uint32_t tail = atomic_load_explicit(&rb->tail, memory_order_acquire);
       if (head - tail == RB_SIZE) {          /* full: drop and count */
           rb->overruns++;
           return false;
       }
       rb->buf[head & (RB_SIZE - 1u)] = byte;
       /* release: the byte is visible before the new head */
       atomic_store_explicit(&rb->head, head + 1u, memory_order_release);
       return true;
   }
   
   /* Consumer side: called from the main loop or a task. */
   bool rb_get(ringbuf_t *rb, uint8_t *out)
   {
       uint32_t tail = atomic_load_explicit(&rb->tail, memory_order_relaxed);
       uint32_t head = atomic_load_explicit(&rb->head, memory_order_acquire);
       if (head == tail)
           return false;                      /* empty */
       *out = rb->buf[tail & (RB_SIZE - 1u)];
       atomic_store_explicit(&rb->tail, tail + 1u, memory_order_release);
       return true;
   }
   
   uint32_t rb_count(ringbuf_t *rb)
   {
       return atomic_load_explicit(&rb->head, memory_order_acquire) -
              atomic_load_explicit(&rb->tail, memory_order_acquire);
   }

   Head and tail are free-running counters, and the slot index is the counter masked by size minus one, which is why the size must be a power of two. The number of bytes stored is head - tail in unsigned arithmetic, which stays correct across 32-bit wrap, and that lets the buffer use every slot: full is a difference equal to the size, empty is a difference of zero, with no wasted slot.

   Safety comes from ownership: only the ISR writes head and only main writes tail, so there is no read-modify-write race on either. The ordering is the subtle part. The producer stores the byte, then publishes head with release ordering; the consumer reads head with acquire ordering, then reads the byte. On a single-core Cortex-M the hardware already keeps program order for normal memory, so the important effect is on the compiler, which otherwise may reorder the plain buffer store after the index store. C11 atomics express this portably and compile to plain loads and stores, plus DMB barriers where needed. Overruns are counted, not hidden, so you can see the buffer is too small or the consumer too slow.

5. Q15 arithmetic and a fixed-point low-pass filterMedium · C

   On a Cortex-M0+ with no FPU, implement saturating Q15 addition and rounded Q15 multiplication, then an exponential moving average filter y += alpha * (x - y) in fixed point. The filter must reach the input value exactly for a constant input even when alpha is very small, and must not overflow for any Q15 input, including a step from -1 to just under 1.

   Hints

   1. The only Q15 product that overflows is -1 multiplied by -1.
   2. Keep the filter state with more fractional bits than the output, or small steps round to zero and the output sticks.
   Solution and explanation

   #include <stdint.h>
   
   typedef int16_t q15_t;                 /* value = raw / 32768, range [-1, 1) */
   
   static inline q15_t sat_q15(int32_t x)
   {
       if (x > INT16_MAX) return INT16_MAX;
       if (x < INT16_MIN) return INT16_MIN;
       return (q15_t)x;
   }
   
   /* Saturating Q15 add. */
   q15_t q15_add(q15_t a, q15_t b)
   {
       return sat_q15((int32_t)a + (int32_t)b);
   }
   
   /* Q15 x Q15 -> Q15 with round-to-nearest. Only -1 * -1 overflows. */
   q15_t q15_mul(q15_t a, q15_t b)
   {
       int32_t p = (int32_t)a * (int32_t)b;     /* Q30 */
       p += 1 << 14;                            /* round half up */
       return sat_q15(p >> 15);                 /* arithmetic shift on gcc/clang */
   }
   
   /* First-order IIR low-pass (exponential moving average):
      y += alpha * (x - y). The state is kept in Q31-ish 32 bits so
      small steps are not lost to truncation when alpha is tiny. */
   typedef struct {
       int32_t acc;                             /* y in Q15 << 16 */
       q15_t   alpha;                           /* 0 < alpha < 1 in Q15 */
   } ema_t;
   
   q15_t ema_step(ema_t *f, q15_t x)
   {
       int32_t y   = f->acc >> 16;              /* current output, Q15 */
       int32_t err = (int32_t)x - y;            /* fits in 17 bits */
       /* err * alpha is Q30; * 2 gives the Q15 << 16 scale of acc.
          Do it in 64 bits: with alpha near 1 the step exceeds int32,
          but the new value lies between y and x, so it fits again. */
       int64_t next = (int64_t)f->acc + (int64_t)err * f->alpha * 2;
       f->acc = (int32_t)next;
       return sat_q15(f->acc >> 16);
   }

   Addition widens to 32 bits and clamps, so overflow sticks at the limit instead of wrapping to the opposite sign. Multiplication forms the 32-bit Q30 product, adds half of the last bit for round-to-nearest, shifts right by 15 and saturates; the only overflowing case is -1 times -1, which would give +1, one step outside the range.

   The filter is where candidates usually go wrong. If the state is kept in Q15, then with a small alpha the term alpha * (x - y) rounds to zero once the error is small, and the output stops short of the input forever. Keeping the state with 16 extra fractional bits removes that dead band. The error x - y needs 17 bits, and the product with alpha times two can exceed 32 bits when alpha is close to 1, so the update is done in 64 bits. The result fits back in 32 bits because the new value always lies between the old output and the input.

6. Software timers with wrap-safe deadlinesMedium · C

   Implement software timers driven by a 32-bit millisecond tick. Users can start one-shot or periodic timers, stop them, and restart them from inside a callback. timer_poll(now) is called from the main loop and must fire every expired timer in deadline order. Periodic timers must not drift, and everything must keep working when the tick wraps after about 49.7 days. No dynamic memory: the caller owns each timer struct.

   Hints

   1. Keep an intrusive linked list sorted by deadline, so polling only looks at the head.
   2. Compare ticks with a signed difference, never with a plain greater-than.
   Solution and explanation

   #include <stdint.h>
   #include <stddef.h>
   #include <stdbool.h>
   
   typedef void (*timer_cb)(void *arg);
   
   typedef struct soft_timer {
       struct soft_timer *next;
       uint32_t deadline;          /* absolute tick */
       uint32_t period;            /* 0 = one-shot */
       timer_cb cb;
       void    *arg;
       bool     active;
   } soft_timer_t;
   
   static soft_timer_t *active_list;   /* sorted by deadline, soonest first */
   
   /* True if tick a is at or after tick b, correct across 32-bit wrap
      as long as the two are less than 2^31 ticks apart. */
   static inline bool tick_reached(uint32_t a, uint32_t b)
   {
       return (int32_t)(a - b) >= 0;
   }
   
   static void insert_sorted(soft_timer_t *t)
   {
       soft_timer_t **pp = &active_list;
       while (*pp && tick_reached(t->deadline, (*pp)->deadline))
           pp = &(*pp)->next;          /* equal deadlines keep FIFO order */
       t->next = *pp;
       *pp = t;
       t->active = true;
   }
   
   void timer_stop(soft_timer_t *t)
   {
       for (soft_timer_t **pp = &active_list; *pp; pp = &(*pp)->next) {
           if (*pp == t) {
               *pp = t->next;
               break;
           }
       }
       t->active = false;
   }
   
   void timer_start(soft_timer_t *t, uint32_t now, uint32_t delay,
                    uint32_t period, timer_cb cb, void *arg)
   {
       if (t->active)
           timer_stop(t);
       t->deadline = now + delay;
       t->period = period;
       t->cb = cb;
       t->arg = arg;
       insert_sorted(t);
   }
   
   /* Call from the main loop (not the ISR) with the current tick. */
   void timer_poll(uint32_t now)
   {
       while (active_list && tick_reached(now, active_list->deadline)) {
           soft_timer_t *t = active_list;
           active_list = t->next;
           t->active = false;
           if (t->period) {            /* re-arm from the old deadline: no drift */
               t->deadline += t->period;
               insert_sorted(t);
           }
           t->cb(t->arg);              /* callback may stop or restart timers */
       }
   }

   The timers form an intrusive singly linked list sorted by deadline, so timer_poll only examines the head and stops at the first unexpired timer. Insertion walks the list with a pointer to the previous next field, which avoids special cases for the head and keeps equal deadlines in FIFO order. Insertion is linear in the number of active timers, which is fine for the tens of timers typical on an MCU; a timer wheel or heap is the answer if the interviewer asks for thousands.

   All comparisons use (int32_t)(a - b) >= 0, which is correct across wrap as long as deadlines are within about 24.8 days of now. Periodic timers re-arm from their previous deadline rather than from the current tick, so a late poll does not accumulate drift, and a very late poll fires the missed periods in a burst, which the interviewer may want you to discuss: some systems prefer to skip missed periods instead. The timer is removed from the list before its callback runs, so callbacks can stop or restart any timer, including themselves, without corrupting the list.

7. COBS framing for a serial linkMedium · C

   Implement Consistent Overhead Byte Stuffing encode and decode so that frames on a UART can be delimited with a 0x00 byte. Encoding must never produce a zero byte, the output size must be bounded, and the decoder must reject malformed frames safely, without reading or writing out of bounds, because it receives bytes from the outside world.

   Hints

   1. Each block starts with a code byte that says how far it is to the next zero, up to 254 data bytes.
   2. A code of 0xFF means a full block with no implied zero after it.
   Solution and explanation

   #include <stdint.h>
   #include <stddef.h>
   
   /* COBS: removes every 0x00 from a packet so 0x00 can mark frame ends.
      Encoded size is at most len + len/254 + 1. Returns bytes written. */
   size_t cobs_encode(const uint8_t *in, size_t len, uint8_t *out)
   {
       size_t code_pos = 0, o = 1;
       uint8_t code = 1;
       for (size_t i = 0; i < len; i++) {
           if (in[i] == 0) {
               out[code_pos] = code;           /* close the current block */
               code_pos = o++;
               code = 1;
           } else {
               out[o++] = in[i];
               if (++code == 0xFF) {           /* 254 data bytes: full block */
                   out[code_pos] = code;
                   code_pos = o++;
                   code = 1;
               }
           }
       }
       out[code_pos] = code;
       return o;                               /* caller appends the 0x00 */
   }
   
   /* Decode one frame (without its 0x00 delimiter).
      Returns decoded length, or 0 with *ok = 0 if the frame is malformed. */
   size_t cobs_decode(const uint8_t *in, size_t len, uint8_t *out, int *ok)
   {
       size_t i = 0, o = 0;
       *ok = 0;
       while (i < len) {
           uint8_t code = in[i++];
           if (code == 0 || i + code - 1u > len)
               return 0;                       /* zero inside frame or overrun */
           for (uint8_t k = 1; k < code; k++) {
               if (in[i] == 0)
                   return 0;
               out[o++] = in[i++];
           }
           if (code != 0xFF && i < len)        /* implicit zero between blocks */
               out[o++] = 0;
       }
       *ok = 1;
       return o;
   }

   COBS splits the data at each zero. Each block becomes a code byte equal to one plus the number of non-zero bytes that follow, and the zero itself is implied at the end of the block. A block can hold at most 254 data bytes; a code of 0xFF means a full block with no implied zero, so long runs without zeros still encode. The overhead is at most one byte per 254, plus one, which bounds the output buffer size at compile time, unlike SLIP-style escaping, which can double the size in the worst case.

   The encoder keeps the position of the current code byte, fills in data, and writes the code when it meets a zero, reaches 254 bytes or ends. The decoder is the security-relevant half: it checks that a code is non-zero, that the block it announces fits within the received length, and that no zero appears inside a block, and it returns failure for anything else. It inserts the implied zero only between blocks, never after the last one. The test harness round-trips random data with many zeros and every length around the 254 boundary, which is where hand-written COBS code usually fails, and feeds malformed frames to the decoder.

8. Decode a HardFault into a readable reportMedium · C

   Your HardFault handler has already captured the stacked exception frame, EXC_RETURN and the fault status registers (CFSR, HFSR, MMFAR, BFAR) into a struct. Write the function that turns them into a short human-readable report for the crash log: the PC, LR and stack in use, the fault causes, and the faulting address only when it is valid. It must never overflow the output buffer.

   Hints

   1. CFSR combines three registers: MemManage in bits 0–7, BusFault in 8–15 and UsageFault in 16–31.
   2. MMFAR and BFAR only hold a meaningful address when MMARVALID (bit 7) or BFARVALID (bit 15) is set.
   Solution and explanation

   #include <stdint.h>
   #include <stdio.h>
   #include <string.h>
   
   typedef struct {          /* captured by the HardFault handler */
       uint32_t r0, r1, r2, r3, r12, lr, pc, xpsr;   /* hardware-stacked frame */
       uint32_t exc_return, cfsr, hfsr, mmfar, bfar;
   } fault_info_t;
   
   static const struct { uint32_t bit; const char *name; } cfsr_bits[] = {
       {1u << 0,  "IACCVIOL: MPU fault on instruction fetch"},
       {1u << 1,  "DACCVIOL: MPU fault on data access"},
       {1u << 3,  "MUNSTKERR: MPU fault while unstacking"},
       {1u << 4,  "MSTKERR: MPU fault while stacking (stack overflow?)"},
       {1u << 8,  "IBUSERR: bus fault on instruction fetch"},
       {1u << 9,  "PRECISERR: precise data bus fault"},
       {1u << 10, "IMPRECISERR: imprecise data bus fault (PC is not exact)"},
       {1u << 11, "UNSTKERR: bus fault while unstacking"},
       {1u << 12, "STKERR: bus fault while stacking (stack overflow?)"},
       {1u << 16, "UNDEFINSTR: undefined instruction"},
       {1u << 17, "INVSTATE: Thumb bit clear (bad function pointer?)"},
       {1u << 18, "INVPC: bad EXC_RETURN value"},
       {1u << 19, "NOCP: coprocessor/FPU used while disabled"},
       {1u << 24, "UNALIGNED: unaligned access trapped"},
       {1u << 25, "DIVBYZERO: integer divide by zero trapped"},
   };
   
   /* Writes a human-readable report into buf. Returns length written. */
   size_t fault_decode(const fault_info_t *f, char *buf, size_t n)
   {
       size_t len = 0;
       if (n == 0u)
           return 0;
       buf[0] = '\0';
   #define OUT(...) do { if (len + 1u < n) {                                   \
           int w_ = snprintf(buf + len, n - len, __VA_ARGS__);                 \
           if (w_ > 0) len += (size_t)w_;                                      \
           if (len >= n) len = n - 1u; } } while (0)   /* truncated */
       OUT("PC=0x%08lX LR=0x%08lX xPSR=0x%08lX stack=%s\n",
           (unsigned long)f->pc, (unsigned long)f->lr, (unsigned long)f->xpsr,
           (f->exc_return & 4u) ? "PSP" : "MSP");
       if (f->hfsr & (1u << 30))
           OUT("HFSR.FORCED: escalated from a configurable fault\n");
       if (f->hfsr & (1u << 1))
           OUT("HFSR.VECTTBL: bus fault reading the vector table\n");
       for (size_t i = 0; i < sizeof cfsr_bits / sizeof cfsr_bits[0]; i++)
           if (f->cfsr & cfsr_bits[i].bit)
               OUT("%s\n", cfsr_bits[i].name);
       if ((f->cfsr & (1u << 7)) != 0u)                 /* MMARVALID */
           OUT("MMFAR=0x%08lX (faulting address)\n", (unsigned long)f->mmfar);
       if ((f->cfsr & (1u << 15)) != 0u)                /* BFARVALID */
           OUT("BFAR=0x%08lX (faulting address)\n", (unsigned long)f->bfar);
       if ((f->xpsr & (1u << 24)) == 0u)                /* T bit */
           OUT("xPSR.T clear: branched to an even address\n");
   #undef OUT
       return len;
   }

   The decoder is table-driven, so adding a bit is a one-line change and the logic is easy to review. It prints the stacked PC and LR first, because with the matching ELF they locate the faulting instruction and its caller, and it uses bit 2 of EXC_RETURN to say whether the fault happened on the main stack or a task stack. HFSR.FORCED means a configurable fault escalated because its own handler was disabled or could not run, so the real cause is in CFSR. The fault address registers are printed only when their valid bits are set; otherwise they hold stale values that send you looking in the wrong place.

   Buffer safety is handled by the output macro: it never writes when the buffer is full and clamps the length after a truncated snprintf, so the result is always terminated and the return value equals the string length. In a real handler I would avoid snprintf and just store the raw words in no-init RAM, decoding them after reset or on the host, because the fault may have been caused by a corrupted heap or stack. The first-stage handler is a few lines of assembly:

   HardFault_Handler:
       tst   lr, #4
       ite   eq
       mrseq r0, msp
       mrsne r0, psp
       b     hardfault_capture   @ r0 = stacked frame

9. A/B slot selection with trial boot and rollbackHard · C

   Write the decision logic of a bootloader with two application slots. Each slot has a header (magic, version, size, CRC-32) and a state in persistent metadata: empty, pending, confirmed or bad. A newly installed image is pending with a number of trial boots. The application confirms itself after a successful self-test. Choose which slot to boot, roll back after the trials run out, refuse corrupted images and refuse any image below a minimum security version. Return -1 if nothing is bootable.

   Hints

   1. Handle a pending image first; count the trial before jumping, not after.
   2. Re-validate the confirmed image on every boot, since flash can be corrupted after it was confirmed.
   Solution and explanation

   #include <stdint.h>
   #include <stddef.h>
   #include <stdbool.h>
   
   #define IMG_MAGIC 0x464D5721u
   typedef enum { ST_EMPTY, ST_PENDING, ST_CONFIRMED, ST_BAD } slot_state_t;
   typedef struct { uint32_t magic, version, size, crc; } img_hdr_t;
   typedef struct {
       const img_hdr_t *hdr;      /* header at the start of the slot */
       const uint8_t   *body;     /* image body that follows it */
       slot_state_t     state;    /* from the boot metadata sector */
       uint8_t          tries_left;
   } slot_t;
   
   /* Hook that writes the metadata sector; must complete before we jump. */
   void meta_persist(const slot_t slots[2]);
   
   static uint32_t crc32(const uint8_t *p, size_t n)
   {
       uint32_t c = 0xFFFFFFFFu;
       while (n--) {
           c ^= *p++;
           for (int k = 0; k < 8; k++)
               c = (c >> 1) ^ (0xEDB88320u & (0u - (c & 1u)));
       }
       return ~c;
   }
   
   static bool image_valid(const slot_t *s, uint32_t min_version, size_t cap)
   {
       const img_hdr_t *h = s->hdr;
       return h->magic == IMG_MAGIC && h->size <= cap &&
              h->version >= min_version &&          /* anti-rollback counter */
              crc32(s->body, h->size) == h->crc;
   }
   
   /* Returns the slot to boot, or -1 to stay in the bootloader (DFU mode). */
   int boot_select(slot_t s[2], uint32_t min_version, size_t cap)
   {
       for (int i = 0; i < 2; i++) {               /* 1. trial of a new image */
           if (s[i].state != ST_PENDING)
               continue;
           if (s[i].tries_left == 0 || !image_valid(&s[i], min_version, cap)) {
               s[i].state = ST_BAD;                /* roll back */
               meta_persist(s);
               continue;
           }
           s[i].tries_left--;                      /* count the attempt first */
           meta_persist(s);
           return i;
       }
       int best = -1;                              /* 2. newest good image */
       for (int i = 0; i < 2; i++) {
           if (s[i].state == ST_CONFIRMED && image_valid(&s[i], min_version, cap) &&
               (best < 0 || s[i].hdr->version > s[best].hdr->version))
               best = i;
       }
       return best;
   }
   
   /* Called by the application once its self-test passes. */
   void boot_confirm(slot_t s[2], int running)
   {
       if (s[running].state == ST_PENDING) {
           s[running].state = ST_CONFIRMED;
           meta_persist(s);
       }
   }

   The logic has two phases. A pending image gets priority, because it is the update being tried. Its trial counter is decremented and the metadata persisted before the jump, so if the new image hangs or crashes before confirming, the watchdog reset brings us back here with one fewer try, and after the last one the image is marked bad and we fall through. A pending image that fails validation is marked bad at once.

   The second phase boots the newest confirmed image that still validates. Validation checks the magic, that the size fits the slot before hashing, so a corrupted length cannot read off the end of flash, the anti-rollback version, and the CRC. Re-checking on every boot catches flash corruption after confirmation and falls back to the other slot.

   What a strong answer adds: in production the CRC is replaced by a signature check over the header and image; the metadata write must itself be power-safe, using a sequence-numbered, checksummed record; and the minimum version should be raised only after an image is confirmed, otherwise a failed update could leave no bootable image. The application must also confirm only after it has proved the things that matter, such as connecting to the update server, so a broken update can still be replaced.

10. Power-safe key-value store on NOR flashHard · C

    Implement a small settings store on two flash sectors of 256 bytes each. Flash has NOR semantics: programming can only clear bits and erase sets a whole sector to 0xFF. Provide kv_mount, kv_get and kv_set for 16-bit keys and 32-bit values. Writes must spread wear, and a power cut at any byte of any write or erase must leave every key with either its old or its new value. The board layer provides flash_program and flash_erase.

    Hints

    1. Append records; never rewrite one. The newest valid record for a key wins.
    2. Write each record data first and a commit field last, and switch sectors with a header written after the copy is complete.
    3. Protect the sector header against a torn erase by storing a value together with its complement.
    Solution and explanation

    #include <stdint.h>
    #include <stdbool.h>
    #include <string.h>
    
    #define SECT_SIZE 256u
    #define HDR_SIZE  8u                     /* seq, ~seq: a torn erase fails the check */
    #define NREC      ((SECT_SIZE - HDR_SIZE) / 8u)
    typedef struct { uint16_t key, commit; uint32_t value; } rec_t;   /* 8 bytes */
    
    /* Board layer: NOR semantics, program can only clear bits, erase sets 0xFF. */
    extern uint8_t flash[2][SECT_SIZE];
    void flash_program(unsigned sect, unsigned off, const void *src, unsigned len);
    void flash_erase(unsigned sect);
    
    static unsigned active, next_rec;
    static uint32_t seq_of(unsigned s)       /* 0 means "not a valid sector" */
    {
        uint32_t h[2];
        memcpy(h, flash[s], sizeof h);
        return (h[0] != 0xFFFFFFFFu && h[0] == ~h[1]) ? h[0] : 0u;
    }
    static rec_t rec(unsigned s, unsigned i)
    {
        rec_t r; memcpy(&r, flash[s] + HDR_SIZE + i * 8u, sizeof r); return r;
    }
    static bool rec_ok(rec_t r) { return r.key != 0xFFFFu && r.commit == 0u; }
    static void write_hdr(unsigned s, uint32_t seq)
    {
        uint32_t h[2] = { seq, ~seq };
        flash_program(s, 0, h, HDR_SIZE);
    }
    void kv_mount(void)
    {
        if (seq_of(0) == 0u && seq_of(1) == 0u) {        /* blank or both torn */
            flash_erase(0); write_hdr(0, 1);
        }
        active = (seq_of(1) > seq_of(0)) ? 1u : 0u;
        next_rec = 0;
        for (unsigned i = 0; i < NREC; i++)
            if (rec(active, i).key != 0xFFFFu)
                next_rec = i + 1u;                       /* skip torn records too */
    }
    bool kv_get(uint16_t key, uint32_t *out)
    {
        bool found = false;
        for (unsigned i = 0; i < next_rec; i++) {
            rec_t r = rec(active, i);
            if (rec_ok(r) && r.key == key) { *out = r.value; found = true; }  /* newest wins */
        }
        return found;
    }
    static void append(unsigned s, unsigned i, uint16_t key, uint32_t value)
    {
        rec_t r = { key, 0xFFFFu, value };
        uint16_t done = 0;
        flash_program(s, HDR_SIZE + i * 8u, &r, sizeof r);        /* data first */
        flash_program(s, HDR_SIZE + i * 8u + 2u, &done, 2);       /* commit last */
    }
    bool kv_set(uint16_t key, uint32_t value)
    {
        if (key == 0xFFFFu) return false;                /* reserved: erased */
        if (next_rec == NREC) {                          /* compact into the other sector */
            unsigned dst = active ^ 1u, n = 0;
            flash_erase(dst);
            for (unsigned i = 0; i < NREC; i++) {
                rec_t r = rec(active, i);
                bool newest = rec_ok(r);
                for (unsigned j = i + 1u; newest && j < NREC; j++)
                    if (rec_ok(rec(active, j)) && rec(active, j).key == r.key)
                        newest = false;
                if (newest)
                    append(dst, n++, r.key, r.value);
            }
            write_hdr(dst, seq_of(active) + 1u);         /* header last: the switch-over */
            active = dst; next_rec = n;
            if (n == NREC) return false;                 /* too many live keys */
        }
        append(active, next_rec++, key, value);
        return true;
    }

    The store is a log. Each kv_set appends an 8-byte record to the active sector: the key and value are programmed first with the commit halfword still erased, then the commit halfword is programmed to zero. A record whose commit is still 0xFFFF was torn by a power cut and is ignored, and mount skips past it so the next write uses a fresh location rather than programming over partly written bits. Reads scan the sector and keep the last committed match.

    When the sector fills, compaction erases the other sector, copies the newest record of each live key into it, and only then writes the new header with a sequence number one higher. The header is the single commit point for the switch: if power fails before it is complete, mount still selects the old sector, which is untouched. Storing the sequence with its complement means a header damaged by an interrupted erase, where bits may be in any state, fails the check instead of looking like a valid newer sector.

    The harness injects a power cut at every possible byte position thousands of times and checks every key afterwards. Things to mention: real flash programs in units such as 64 bits with ECC, which changes the record layout, and the erase count per sector should be tracked to estimate lifetime.

Design and debugging scenarios

Talk through each one out loud for 15–20 minutes, then compare your answer with the model walk-through.

1. Design the firmware update path for a battery-powered sensorSystem design

   A fleet of 50,000 battery-powered environmental sensors uses a Cortex-M4 with 1 MB of internal flash and 256 kB of RAM, plus a low-power radio with a link of a few kilobytes per second. Devices are installed in hard-to-reach places for ten years. Design the over-the-air update system on the device: memory layout, download, verification, switch-over and recovery.

   Model walk-through

   Requirements first. The device must never become unrecoverable, updates must not drain the battery noticeably, only signed firmware may run, old vulnerable images must not be installable, and a failed update must roll back without anyone touching the device.

   Memory layout. With 1 MB I use A/B slots: a small immutable bootloader of about 32 kB, two application slots of around 448 kB each, and two small sectors for boot metadata and settings. A/B gives instant rollback and means the running image is never touched during download.

   Download. The image is transferred in chunks with a chunk index, so a download can resume after the radio drops or the device sleeps; progress is stored in flash. Each chunk is written straight to the inactive slot. To protect the battery, downloads run only when the battery voltage is above a threshold, are spread over several wake windows, and the server staggers rollout across the fleet.

   Verification and switch-over. After the last chunk, the device hashes the whole slot with SHA-256 reading back from flash, and the bootloader verifies an ECDSA signature over the header and hash with a public key in protected flash. The header includes a security counter checked against a monotonic counter. Only then is the metadata record for that slot set to pending with three trial boots, using a power-safe, sequence-numbered record.

   Trial and confirmation. The bootloader decrements the trial count before jumping, and the watchdog is running. The new application confirms itself only after it has initialised its sensors and completed a round-trip with the server, which proves it can receive the next update. If trials run out, the bootloader marks the image bad and boots the old one, which then reports the failure.

   Failure modes and tests. Power cut at every stage, corrupted chunk, wrong-board image, downgrade attempt, image that crashes at start-up, image that runs but cannot connect, flash wear from repeated failed downloads. I would test each on a HIL rig with a power relay and a scripted server, and do a staged rollout to a small percentage of the fleet first, watching telemetry for confirmation rates before widening.

2. Intermittent HardFault after adding a new featureDebugging

   After a feature that adds BLE notifications was merged, a product that ran for months without issues now hits a HardFault roughly once a day in the test lab. It never happens with the debugger attached. The fault log shows a stacked PC inside memcpy, CFSR shows PRECISERR with BFARVALID, and BFAR is an address just past the end of RAM. How do you proceed?

   Model walk-through

   Read the evidence. A precise bus fault with a valid BFAR means a specific load or store tried to access an address that does not exist, and the address is just past the end of RAM. The faulting instruction is inside memcpy, so the caller passed a bad pointer or a bad length. Since memcpy is a leaf, the stacked LR points to the caller, which I find with addr2line on the exact ELF of that build.

   Form hypotheses. There are three likely ones. First, a length that underflowed: an unsigned subtraction such as received - header_len where received is occasionally shorter than the header, producing a huge length that runs off the end of RAM. Second, a buffer pointer computed from corrupted data, for example a ring buffer index that is torn because the new BLE callback writes it from an interrupt while main reads it. Third, a stack overflow in the task that runs the new feature, corrupting a neighbouring structure that holds the pointer.

   Narrow it down. I extend the fault capture to save R0 to R3 from the stacked frame, which for memcpy are the destination, source and length. If the length is enormous, hypothesis one is confirmed. I check the stack high-water mark of each task, since the feature added work to some task, and enable the MPU guard regions or the kernel overflow check. I review every shared variable the new code touches for missing critical sections and check its interrupt priority against the RTOS limit, because a BLE stack callback calling a non-FromISR API from an interrupt above the syscall priority corrupts kernel lists.

   Reproduce faster. I increase the notification rate and add random delays in the suspect paths on a test build to make the race window bigger, and run a fuzzer on the host build of the message parser with short and malformed packets.

   Fix and prove. The fix depends on the cause: validate lengths before subtraction, protect the shared index, or resize the stack. Then I add a regression test, such as a host test with a short packet or a stress test on the HIL rig, and run it for many times the original failure interval.

3. Review a UART interrupt handlerCode review

   A colleague submits this receive interrupt for review. What problems do you raise, and how would you rewrite it?

   volatile char line[64];
   volatile int  len;
   volatile int  line_ready;
   
   void USART2_IRQHandler(void) {
       char c = USART2->DR;
       if (c == '\n') {
           line[len] = 0;
           line_ready = 1;
           printf("got line %s\n", line);
           len = 0;
       } else {
           line[len++] = c;
       }
   }

   Model walk-through

   Memory safety. There is no bounds check: a line of 64 characters or more without a newline writes past the end of the array, and with the terminator added at line[len] even 64 characters is one too many. Input comes from outside the device, so this is a real vulnerability, not a theoretical one. Overlong lines need to be discarded or truncated with an error count.

   Blocking work in the ISR. printf inside a handler is a serious problem. It is slow, often takes milliseconds over a blocking UART, so further characters overrun; it may not be re-entrant; and if it is retargeted to the same UART or uses a lock, it can deadlock. Logging belongs in the main loop.

   Race with the consumer. When a line is ready, the ISR resets len and keeps writing into the same buffer while main may still be reading the previous line, so main sees a mix of two lines. A single buffer with a flag cannot work unless reception stops. I would use a byte ring buffer filled by the ISR and parse lines in main, or double-buffer lines and swap them.

   Error handling. The handler does not check overrun, framing or noise flags. On many STM32 parts an overrun leaves the interrupt asserted until the flag is cleared in the right sequence, which can lock the system in the handler.

   Types and style. len as signed int invites negative indexing; use an unsigned size type. char may be signed, so bytes above 0x7F sign-extend. The data register access should use the field width the reference manual defines. Volatile on the whole buffer is a symptom of the design, not a fix.

   Rewrite. The handler reads the status register, handles and clears error flags with a counter for each, reads the data register, and pushes the byte into a single-producer ring buffer, counting overruns if it is full. Main pulls bytes, assembles lines in its own buffer with a length limit, and processes complete lines. The handler is then a few dozen cycles, cannot overflow, and the line logic is testable on the host.

4. Bring up a new board where the MCU will not run your codeDebugging

   The first prototype of a new board has arrived. The debug probe connects and can program flash, but after a reset the code never reaches main: the LED you toggle first never changes. With the debugger you can halt the core, and it is sitting in a HardFault handler or at a strange address. Describe your approach.

   Model walk-through

   Start with what the core sees. I halt and read PC, SP, LR and xPSR, and dump the first words of flash at the boot address. Word 0 must be a plausible stack pointer within RAM, and word 1 the reset handler address with bit 0 set. A mismatch points to a wrong linker script for this part, an image linked for an offset meant for a bootloader that is not present, or wrong boot pins selecting another memory. I check the boot configuration on the schematic and the option bytes.

   Step through the reset handler. I set a breakpoint on the reset handler and step. If it faults immediately, I read CFSR. A fault while writing .data or zeroing .bss often means the linker script declares more RAM than this part variant has, which is common when a board uses a smaller memory option of the same family. A fault on the first floating-point instruction means the FPU was not enabled in SystemInit before use. A hang in SystemInit usually means waiting for an external crystal or PLL that never becomes ready.

   Check clocks and power. If it hangs waiting for the crystal, I scope the oscillator pins with a low-capacitance probe, check the load capacitor values against the crystal specification and the layout, and try running from the internal oscillator to separate the problem. I also check the core supply and decoupling, and the VCAP pins on parts with an internal regulator, which need a specific capacitor; a missing one causes erratic behaviour that looks like a software bug.

   Reduce to a minimum. I build the smallest possible image: vector table, reset handler that toggles the LED pin with direct register writes, no clock changes, no C library. If that runs, I add the original start-up steps back one at a time. If the LED still does not toggle, I check the pin on the schematic and the port clock enable.

5. Choose between bare metal, FreeRTOS and Zephyr for a new productResearch

   Your team is starting a new connected product on a Cortex-M33 with TrustZone, BLE, a sensor hub and OTA updates. The previous product was a bare-metal super-loop. The lead asks you to recommend a software foundation and justify it in a short investigation. How do you approach this and what would you recommend?

   Model walk-through

   Frame the decision. I write down the requirements that actually differentiate the options: the BLE stack and how it expects to be scheduled, the update and secure boot path, TrustZone partitioning, low-power targets, certification needs, team experience, licensing, and long-term maintenance over the product life. Then I define how I will evaluate each option against them in a fixed time, for example two weeks.

   Bare metal. It gives full control, the smallest footprint and the team knows it. But a vendor BLE stack usually comes with its own scheduler or assumes an RTOS, OTA with a secure bootloader must be built and maintained in-house, and several concurrent activities with different deadlines would mean hand-written state machines for everything. I would only keep it if the vendor SDK supplies most of the stack in bare-metal form.

   FreeRTOS. A small, well-understood kernel with a permissive licence and wide vendor support. It is a scheduler, not a platform: drivers, the BLE integration, the update agent and the bootloader come from the vendor SDK or from us. That suits a team that wants a small, transparent core and is happy to own integration. TrustZone is supported with secure and non-secure ports.

   Zephyr. A full platform: kernel, devicetree-based drivers, a BLE host and controller, MCUboot integration for signed updates, power management and Trusted Firmware-M for the secure side. That covers much of the list, but the build system, Kconfig and devicetree have a learning curve, the footprint is larger, and upgrades between releases need planning.

   Evaluate with a prototype. I build the same spike on the two strongest candidates: BLE connection, a sensor read on a timer, deep sleep between events, and a signed OTA with rollback.

   Recommendation. For this product, with BLE, OTA, TrustZone and a team ready to invest, I would expect Zephyr to win on total effort because so much of the security and update path already exists and is maintained upstream. FreeRTOS is the right choice if the vendor SDK is built around it and the team prefers to keep the platform small. I present the measurements, the risks such as learning curve and footprint, and a mitigation plan such as training and pinning a long-term support release.

Run a mock interview

Ask a friend to play the interviewer, or record yourself. Pick questions and an exercise you have not opened yet.

Cheat sheet

Facts worth having at your fingertips on the day.

Vector table

Word 0 is the initial MSP, word 1 the reset handler address with bit 0 set for Thumb state.

Exception numbers

Reset 1, NMI 2, HardFault 3, MemManage 4, BusFault 5, UsageFault 6, SVCall 11, PendSV 14, SysTick 15, external IRQs from 16.

Exception frame

Hardware stacks R0–R3, R12, LR, PC and xPSR: 8 words, or 26 words with the FPU context.

EXC_RETURN

0xFFFFFFF1 returns to Handler mode, 0xFFFFFFF9 to Thread mode on MSP, 0xFFFFFFFD to Thread mode on PSP; bit 4 clear means an FPU frame.

NVIC priority

Lower number means more urgent; only the top implemented bits of the 8-bit field count.

BASEPRI

Masks interrupts with priority value at or above the setting; not available on ARMv6-M (M0 and M0+), which only have PRIMASK.

Fault status registers

CFSR at 0xE000ED28, HFSR at 0xE000ED2C, MMFAR at 0xE000ED34, BFAR at 0xE000ED38.

CFSR layout

MemManage status in bits 0–7, BusFault in bits 8–15, UsageFault in bits 16–31.

Startup order

Set clocks and FPU, copy .data from flash, zero .bss, run constructors, call main.

.data and .bss

.data costs flash and RAM, .bss costs only RAM, const data costs only flash.

Tick wrap

A 32-bit 1 ms counter wraps after about 49.7 days; compare with (int32_t)(now - deadline) >= 0.

SPI modes

Mode 0: CPOL 0, CPHA 0; mode 1: 0, 1; mode 2: 1, 0; mode 3: 1, 1.

I2C recovery

Clock SCL up to nine times until SDA is released, then send a STOP.

CAN error states

Error-passive above 127 on either counter, bus-off above 255 on the transmit counter.

CAN arbitration

Dominant 0 beats recessive 1, so the lowest identifier wins without corrupting the frame.

Flash

Programming clears bits, erase sets a whole sector to 1s; endurance is often around 10,000 cycles for internal flash.

Q15

Signed 16-bit, value = raw / 32768; multiply into 32 bits and shift right by 15.

Oversampling

Four times oversampling and averaging gains about one bit of resolution if the noise is random.

CRC-16/CCITT-FALSE

Polynomial 0x1021, initial value 0xFFFF; check value for "123456789" is 0x29B1.

CRC-32

Reflected polynomial 0xEDB88320, initial value and final XOR 0xFFFFFFFF; check value 0xCBF43926.

Cache and DMA

Clean the cache before a DMA transmit, invalidate after a DMA receive; align buffers to 32-byte lines on M7.

Mutex versus semaphore

A mutex has an owner and priority inheritance; a semaphore is for signalling and can be given from an ISR.

FreeRTOS ISR rule

Only FromISR APIs in handlers, and only from interrupts at or below configMAX_SYSCALL_INTERRUPT_PRIORITY urgency.

Low power

WFI with SLEEPDEEP clear is sleep, with SLEEPDEEP set is the vendor deep sleep; unused pins go to analog mode.

Watchdog

Feed only from a supervisor that has confirmed every monitored task made progress.

Secure boot

Immutable root, public key hash in OTP, signature over header and image, monotonic security counter, debug port locked.

Red flags that sink candidates

• Saying volatile makes a variable thread-safe or atomic. Explain that it only forces the compiler to perform each access, and name the critical section or atomic you would add.
• Calling printf, malloc or a blocking API inside an interrupt handler in a coding answer. Keep handlers to reading data, clearing flags and signalling, and say so before the interviewer asks.
• Designing an update path with no rollback or no answer to "what if power fails now". Walk through each step and state what the bootloader sees if power is cut there.
• Feeding the watchdog from a timer interrupt. Describe a supervisor that checks every task before the kick.
• Debugging by guesswork: changing code until the symptom moves. Describe the evidence you would collect first, such as fault registers, a scope trace or a minimal reproduction.
• Comparing tick counters with a plain greater-than, or ignoring wrap in ring buffer indices. Use unsigned differences and say how long the interval may be.
• Claiming experience with a bus or RTOS but being unable to describe its failure modes, such as a stuck I2C bus, CAN bus-off or priority inversion. Only list what you can defend in depth.
• Ignoring the hardware: never mentioning the reference manual, errata, the scope or the schematic. Firmware developers are expected to read all four and to talk to the hardware team in its own terms.
• Writing code with no tests and no plan to test it. Mention how you would test the function on the host and what you would check on the target.

FAQ