Google Embedded Developer (Mid-Level) Interview Preparation Guide

Approach overview

1. Treat this as a concurrency/IO race: instrument from IRQ/DMA boundaries through driver, OS, and Wi‑stack to find where buffers, lengths, or checksums are corrupted. Combine lightweight in‑target events + high‑bandwidth instruction trace to correlate causality.

Clarify assumptions & reproduce

• Reproduce with deterministic traffic (known packet patterns, sequence numbers).
• Use stress tests: high throughput, mixed RX/TX, different MTUs, interrupt coalescing on/off.

Hardware tracing

• ETM (instruction trace): record CPU execution around failure windows to see preemption points and exact ordering of handler, driver, and stack code.
• SWO / ITM: emit timestamped lightweight async events (packet RX start/finish, DMA descriptors owned bits, checksum computed, ISR enter/exit, task switch) at low overhead.
• DWT cycle counter: capture precise cycle timestamps; toggle a GPIO for oscilloscope if absolute timing needed.

Lightweight logging

• Emit compact ITM/SWO events with:
  • Event type (enum), small id (u16), 32‑bit timestamp (DWT->CYCCNT).
  • Packet sequence number and buffer pointer (truncated) to detect aliasing.
• Insert boundary checks: buffer length, canary bytes at buffer tail, per‑packet CRC of payload stored separately.
• Avoid heavy printf; batch or ring‑buffer events in RAM if SWO saturated.

Kernel/RTOS hooks

• Add trace points on context switch, task enter/exit, ISR enter/exit, and DMA completion callbacks.
• Log preemption causes: store current task id and EXC_RETURN when ISR preempts.
• Instrument locks: record lock take/release with caller PC to find priority inversion or double free.

Correlating events

• Use monotonic cycle timestamps to align ETM instruction trace with SWO events; ETM provides instruction addresses so you can see exact instruction that mutated buffer.
• Correlate DMA descriptor ownership transitions (hardware view) with CPU writes. Capture and compare descriptor contents before/after via snapshot in logging or memory trace.
• If mismatch occurs, find nearest earlier write to that memory region in ETM trace — likely race.

Deterministic replay / capture

• Record inputs (packets, IRQ timings) and SWO event stream into PC-side logfile. Replay at lower speed in simulator or instrumented board with single‑step ETM to confirm cause.
• If ETM unavailable, use high‑resolution event ring buffer plus GPIO toggles and oscilloscope to infer ordering.

Root-cause patterns to check

• DMA writing into buffer while CPU computes checksum without ownership check.
• ISR modifying shared descriptor without proper synchronization with task.
• Use-after-free or buffer pool aliasing due to insufficient refcounting.
• Non‑atomic updates of multi‑word metadata (length fields) causing transient invalid lengths.

Fix guidance

• Enforce ownership flags, memory barriers, and use atomic operations for multi‑word state.
• Move checksum calculation into DMA/HW where possible or protect with lock or IRQ masking for the critical section.
• Add buffer canaries + periodic assertion failures to catch earlier.

This systematic instrument → correlate → isolate loop using ETM+SWO+DWT plus lightweight in‑firmware events reliably exposes concurrency races in embedded network stacks.

Approach (brief)
Provide a minimal, non-blocking ISR that clears the peripheral interrupt flag, avoids heap or blocking calls, and signals the application either via a volatile lock-free flag or via FreeRTOS task notification.

Code (STM32-style register names as example)

#include <stdint.h>
#include "FreeRTOS.h"
#include "task.h"

/* Lock-free flag option */
volatile uint32_t gpio_event_flag = 0;

/* FreeRTOS task handle to notify (set by main) */
TaskHandle_t gpioTaskHandle = NULL;

/* ISR for GPIO pin 0 (example). CMSIS name used by startup vector table. */
void EXTI0_IRQHandler(void)
{
    /* 1) Clear hardware interrupt flag (write 1 to pending bit) */
    EXTI->PR = (1U << 0); /* platform-specific: clear pending for line 0 */

    /* 2a) Simple lock-free flag (no blocking, no heap) */
    gpio_event_flag = 1;

    /* 2b) OR: notify a FreeRTOS task from ISR (non-blocking) */
    BaseType_t xHigherPriorityTaskWoken = pdFALSE;
    if (gpioTaskHandle != NULL) {
        vTaskNotifyGiveFromISR(gpioTaskHandle, &xHigherPriorityTaskWoken);
        portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
    }
}

Notes:

• Use the correct peripheral register to clear the interrupt for your MCU (some require writing 1, others clearing bits).
• gpio_event_flag must be volatile to prevent compiler optimizations.
• vTaskNotifyGiveFromISR and portYIELD_FROM_ISR are ISR-safe and do not allocate heap.
• Do not call blocking APIs, printf, malloc, or mutexes inside ISR.

Approach (brief)
Pack signed 12-bit samples (two's complement) tightly: 12 bits per sample => 3 bytes for every 2 samples. Work in 32-bit words on a 32-bit MCU for speed: process pairs with bit ops, handle odd final sample. Ensure unpack sign-extends 12-bit values to int16_t.

Code (optimized, portable C)

#include <stdint.h>
#include <stddef.h>

void pack12(const int16_t *samples, size_t n, uint8_t *out) {
    size_t i = 0, o = 0;
    while (i + 1 < n) {
        uint32_t a = (uint16_t)samples[i] & 0x0FFF;     // lower 12 bits
        uint32_t b = (uint16_t)samples[i+1] & 0x0FFF;
        uint32_t w = (a) | (b << 12);                   // 24 bits: sample0 | sample1<<12
        out[o++] = (uint8_t)(w & 0xFF);
        out[o++] = (uint8_t)((w >> 8) & 0xFF);
        out[o++] = (uint8_t)((w >> 16) & 0xFF);
        i += 2;
    }
    if (i < n) { // odd sample left
        uint32_t a = (uint16_t)samples[i] & 0x0FFF;
        out[o++] = (uint8_t)(a & 0xFF);
        out[o++] = (uint8_t)((a >> 8) & 0xFF);
    }
}

void unpack12(const uint8_t *in, size_t n, int16_t *samples) {
    size_t i = 0, o = 0;
    while (o + 1 < n) {
        uint32_t w = (uint32_t)in[i] | ((uint32_t)in[i+1] << 8) | ((uint32_t)in[i+2] << 16);
        uint16_t a = w & 0x0FFF;
        uint16_t b = (w >> 12) & 0x0FFF;
        // sign-extend 12-bit to 16-bit
        samples[o]   = (int16_t)((a ^ 0x0800) - 0x0800);
        samples[o+1] = (int16_t)((b ^ 0x0800) - 0x0800);
        i += 3; o += 2;
    }
    if (o < n) { // last single sample
        uint16_t a = (uint16_t)in[i] | ((uint16_t)in[i+1] << 8);
        a &= 0x0FFF;
        samples[o] = (int16_t)((a ^ 0x0800) - 0x0800);
    }
}

Key points

• Use masking 0x0FFF to keep 12 bits.
• Sign-extension trick: (x ^ 0x0800) - 0x0800 converts 12-bit two's-complement to signed 16-bit efficiently without branching.
• Processes pairs to reduce loop overhead; minimal temporaries; works for odd count.

Complexity

• Time O(n), space O(1) extra. Fast on 32-bit MCU due to 32-bit ops and sequential memory access.

Edge cases

• Ensure out buffer size = ceil(n*12/8). Handle unaligned buffers, endianness assumed little-endian byte order for stream; document if big-endian required.

Alternative

• Use compiler intrinsics or unaligned 32-bit writes for slightly faster throughput if MCU supports.

Situation & immediate goal
I want to capture the CPU state at the moment of HardFault so I can identify the instruction and reason (memory fault, bus fault, usage fault) and map it back to source even when optimizations are enabled.

Steps to capture the fault context with JTAG/SWD

• Halt on fault: configure the debugger to stop on exception entry (e.g., "Stop on HardFault" or enable vector catch / fault halt). If it runs past, set a breakpoint at HardFault_Handler.
• Locate stacked registers: read EXC_RETURN in LR and the current SP (MSP on exception entry for handlers). The 8 pushed registers are at SP on entry:
  • r0, r1, r2, r3, r12, lr, pc, xPSR (lowest address = SP)
  • Use the debugger’s memory/read registers command to dump 32-bit words at SP and label them.
• Inspect fault status registers (SCB):
  • Read SCB->CFSR (Usage/Bus/MemoryFault subfields), SCB->HFSR, SCB->MMFAR, SCB->BFAR
  • Interpret bits: e.g., CFSR MemManage Fault Status bits indicate instruction vs data access, MMFAR holds faulting address if valid.
• Map PC to source with optimizations:
  • Extract faulting PC from stacked PC. Mask Thumb bit (PC & ~1).
  • Use objdump/addr2line with the linked ELF and the exact address: addr2line -e firmware.elf 0xADDRESS
  • If inlined/optimized, also use objdump -d to see surrounding function and compiler map file; enable debug-symbol-rich builds (-g) and keep link map to correlate section offsets.
• Reproduce without masking timing:
  • Avoid heavy logging or debug I/O that changes timing.
  • Use non-invasive trace: enable hardware break-on-fault or SWV/ITM for lightweight logs, or ETM/trace if available.
  • Add conditional breakpoints/watchpoints on the suspected fault address or memory region (use hardware watchpoints).
  • Create stress test that exercises same code paths with same interrupts and timing (use timers/NMI to mimic).
  • If race suspected, use reduced optimization or instrumented builds with minimal impact (cycle-accurate toggles, GPIO toggles) to capture timing without altering it too much.
  • Repeat with increased monitoring (watchpoints) until captured.

Notes / best practices

• Remember to clear SCB fault status bits after reading to avoid stale info.
• When reading stacked PC, remember Thumb LSB and pipeline offset; disassemble from (pc - 4) to see the likely faulting instruction.
• Keep a copy of the exact firmware ELF and map file used on the device for reliable addr2line mapping.

Why volatile is not a synchronization primitive

• volatile only prevents the compiler from optimizing away accesses and forces reads/writes to memory. It does NOT provide ordering guarantees across CPUs, nor atomicity for read-modify-write, nor visibility across caches on multicore. For ISRs/interrupt contexts on a single core it helps avoid compiler reordering but doesn't replace memory barriers or atomics.

Contrast: volatile vs memory barriers vs atomics

• volatile: compiler-level; no inter-thread/memory-order semantics.
• memory barriers (fence): CPU-level instructions ensuring ordering and visibility (e.g., DMB/DSB on ARM).
• atomic operations (C11 stdatomic): provide atomicity + well-defined memory_order semantics (seq_cst, acquire/release, relaxed).

Bad example — race between ISR and main using volatile

volatile uint8_t flag = 0; // set by ISR

void ISR(void) { flag = 1; }

int main(void) {
  while (!flag) {
    // busy-wait
  }
  // race: read-modify-write later would be non-atomic
}

This may work on simple microcontrollers, but if flag were wider than CPU word or if compiler reordered accesses, it can fail.

Correct using C11 atomics

#include <stdatomic.h>
atomic_uint_fast8_t flag = ATOMIC_VAR_INIT(0);

void ISR(void) { atomic_store_explicit(&flag, 1, memory_order_release); }

int main(void) {
  while (atomic_load_explicit(&flag, memory_order_acquire) == 0) { }
  // safe: acquire/release pairs ensure visibility and ordering
}

Alternate: explicit barrier (ARM example)

• In ISR after write: asm volatile ("dmb ish" ::: "memory");
• In main before read: asm volatile ("dmb ish" ::: "memory");

Use C11 atomics where available; otherwise pair CSR/CPU barriers with volatile for safe ISR synchronization.

SPI fundamentals (brief)
SPI is a synchronous serial bus with a single master and one or more slaves. Master generates SCK (clock) and selects a slave via CS/SS (chip/slave select). Data is exchanged on MOSI (master out, slave in) and MISO (master in, slave out).

Signals & roles

• SCK: clock from master.
• MOSI: master → slave data.
• MISO: slave → master data.
• CS/SS: active-low select per slave; when asserted the selected slave drives MISO.

CPOL/CPHA and modes

• CPOL = clock idle polarity (0 = low, 1 = high).
• CPHA = clock phase: whether sampling occurs on first or second edge after CS.
  Modes:
• Mode 0: CPOL=0, CPHA=0 (sample rising edge).
• Mode 1: CPOL=0, CPHA=1.
• Mode 2: CPOL=1, CPHA=0.
• Mode 3: CPOL=1, CPHA=1.

Choose mode to match device datasheet; mismatch causes bit shifts or jitter.

Full- vs half-duplex

• Full-duplex: MOSI and MISO simultaneous (standard SPI).
• Half-duplex: single data line toggled direction or tri-stated (used to reduce pins).

Bus topology & multiple slaves

• Use one CS per slave; keep CS asserted only for active transfer. Avoid shared MISO driving—use pull-ups and tri-state or buffers. Consider series resistors for signal integrity and matched trace lengths for high speed.

CS timing

• Observe device setup/hold in datasheet: ensure CS asserted before first clock by tCSS, maintain after last clock for tCSH, and observe required inter-transfer delay. Violating these causes corrupted frames or device misinterpretation. In firmware, assert CS, wait tCSS, clock N bits, wait tCSH, deassert CS.

Approach (brief)
On 8-bit AVR a 16-bit variable is not atomic; an ISR can interrupt a multi-byte access. Safest simple method is to disable interrupts around the read/write or use AVR-provided atomic macros.

Example — disable/restore interrupts (cli()/sei())

#include <avr/io.h>
#include <avr/interrupt.h>

volatile uint16_t shared = 0;

uint16_t read_shared(void) {
    uint16_t val;
    uint8_t sreg = SREG;   // save global interrupt flag
    cli();                 // disable interrupts
    val = shared;          // atomic read of 16-bit
    SREG = sreg;           // restore interrupts (restores I-bit)
    return val;
}

void write_shared(uint16_t v) {
    uint8_t sreg = SREG;
    cli();
    shared = v;
    SREG = sreg;
}

Example — using <util/atomic.h>

#include <util/atomic.h>

uint16_t read_shared2(void) {
    uint16_t val;
    ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
        val = shared;
    }
    return val;
}

Pros/Cons

• Disabling interrupts: simple, minimal code, deterministic. Con: increases interrupt latency; avoid long critical sections.
• Atomic macros: safer (handles SREG), clearer intent.
• Alternatives: use double-buffering + version counters or message queues/flags to avoid long disable periods; use minimal critical sections or task-level synchronization in RTOS. Those reduce latency but add complexity and possibly more memory.

Approach

• Use a small ring buffer protected by a mutex for reader/writer.
• ISR signals a worker via a semaphore/queue to do non-ISR work.
• Expose open/close/read/write with proper locking and sleep/wakeup when empty/full.

Pseudo-C skeleton

// pseudo-C for RTOS (posix-like primitives)
#include <rtos.h>

#define BUF_SIZE 256

static uint8_t buf[BUF_SIZE];
static size_t head=0, tail=0;
static mutex_t buf_lock;
static sem_t data_sem;      // signalled by ISR; worker waits
static cond_t read_wait;    // readers wait when buffer empty
static bool open_count=false;
static thread_t worker_thread;

static inline size_t buf_used() { return (head - tail) % BUF_SIZE; }
static inline size_t buf_free() { return BUF_SIZE - buf_used() - 1; }

void isr_data_ready(void)
{
    // minimal ISR: acknowledge hardware
    hw_ack_interrupt();
    // notify worker (use ISR-safe API)
    sem_give_from_isr(&data_sem);
}

static void worker(void *arg)
{
    while (1) {
        sem_take(&data_sem, WAIT_FOREVER);
        // do deferred processing
        mutex_lock(&buf_lock);
        while (hw_has_data() && buf_free()) {
            buf[head] = hw_read_byte();
            head = (head + 1) % BUF_SIZE;
        }
        mutex_unlock(&buf_lock);
        cond_broadcast(&read_wait); // wake readers
    }
}

int dev_open(void)
{
    if (!open_count) {
        open_count = true;
        mutex_init(&buf_lock);
        sem_init(&data_sem, 0);
        cond_init(&read_wait);
        worker_thread = thread_create(worker, NULL);
    }
    return 0;
}

int dev_close(void) { open_count = false; return 0; }

ssize_t dev_read(uint8_t *dst, size_t len)
{
    size_t copied=0;
    mutex_lock(&buf_lock);
    while (buf_used()==0) {
        mutex_unlock(&buf_lock);
        cond_wait(&read_wait, &buf_lock); // atomically unlock and wait
        mutex_lock(&buf_lock);
    }
    while (copied < len && buf_used()) {
        dst[copied++] = buf[tail];
        tail = (tail + 1) % BUF_SIZE;
    }
    mutex_unlock(&buf_lock);
    return copied;
}

ssize_t dev_write(const uint8_t *src, size_t len)
{
    size_t written=0;
    mutex_lock(&buf_lock);
    while (written < len && buf_free()) {
        buf[head] = src[written++];
        head = (head + 1) % BUF_SIZE;
    }
    mutex_unlock(&buf_lock);
    // optionally notify hardware to send data
    return written;
}

Key points

• ISR does minimal work and uses ISR-safe sem give.
• Worker performs slow operations and moves data to buffer.
• Mutex + condition variable protect and coordinate access.
• Ring buffer avoids copies and supports concurrent readers/writers safely.

Direct answer (difference)

• Hardware interrupt: asynchronous event from external/peripheral source (GPIO, timer, UART) handled by NVIC on Cortex-M. Occurs independent of current instruction flow.
• Exception/fault: synchronous event caused by program execution or core condition (instruction fault, undefined instruction, divide-by-zero, SVC). Deterministic response to instruction or internal error.

Examples

• Exceptions: Reset, NMI, HardFault, MemManage (MPU), BusFault (data access), UsageFault (undefined instruction, divide-by-zero), SVC, PendSV, SysTick.
• Hardware interrupts: external IRQn from timers (TIM), USART RX, external pin (EXTI).

Semantics & handling differences

• Triggering: exceptions are synchronous to the instruction (precise) or to internal detection; interrupts are asynchronous.
• Stacking/entry: both push core registers and jump to vector, but exceptions (faults) often have fixed priorities (HardFault > other faults) and can escalate (e.g., MemManage → BusFault → HardFault). NVIC arbitrates peripheral IRQ priorities for interrupts.
• Return: use special EXC_RETURN value; synchronous faults may leave PC at faulting instruction (or next) so debugger can analyze; interrupt return resumes interrupted context.
• Masking/control: faults often cannot be masked (NMI/HardFault), while interrupts can be masked via PRIMASK/BASEPRI or NVIC settings.
• Diagnostics: faults populate fault status registers (CFSR, HFSR, BFAR, MMFAR) for root-cause; external IRQs usually have peripheral status flags.

Why it matters for embedded developers

• Use faults for detecting bugs/safety violations and inspect fault registers to debug; design ISRs vs. fault handlers with different recovery expectations and priority considerations.

Approach summary
List practical compiler/linker techniques and explain trade-offs with runtime, debugability, and performance — from an embedded developer perspective.

Techniques & flags

• -Os — optimize for size: reduces code size by avoiding inlining and heavy optimizations; may slightly reduce performance. Use when flash is tight.
• -ffunction-sections / -fdata-sections — emit each function/data in its own section (.text.func, .data.var). Enables fine-grained removal.
• --gc-sections (linker) — garbage-collect unreachable sections at link time. Requires the above flags and correct visibility (no unintended weak refs).
• -flto / -flto=thin (Link Time Optimization) — enables cross-module inlining and dead-code elimination across translation units; thin LTO reduces memory/compile-time cost. Can further reduce size but increases link time and toolchain complexity.
• Strip symbols (strip, -s) and use -g split-debug or debug info separated to preserve source-level debug without inflating flash.
• Disable exceptions and RTTI in C++ (e.g., -fno-exceptions, -fno-rtti) — removes exception handling tables and typeinfo; significant savings if exceptions not used. Must design error paths via return codes/optional.
• Use compiler options to reduce startup/runtime (no standard library, -ffreestanding, provide minimal crt) and avoid heavy C++ features (virtual tables, iostreams, locale).
• Linker script tuning — place seldom-used code in non-critical regions, control section alignment, remove unused startup code, and reduce .bss via smaller statics.
• Use smaller libc variants (newlib-nano, musl, or a custom minimal HAL) and avoid printf or use minimal printf variants.

Runtime & debugging trade-offs

• Removing exceptions/RTTI and aggressive inlining control: smaller binary but harder to use higher-level C++ patterns and catch bugs without stack unwinding.
• LTO and -Os: better size but longer build/link times; LTO can obscure call stacks in debugging and requires consistent toolchain flags across build.
• --gc-sections: can accidentally remove code reachable by reflection, linker script, or via assembly — need to mark used symbols with KEEP() or used attribute.
• Stripping symbols reduces post-mortem debug; split-debug preserves symbols externally.
• Testing: enable size-reduction flags early in CI; run functional and stress tests and hardware-in-the-loop to catch behavior changes.

Practical checklist

• Build with -Os + -ffunction-sections/-fdata-sections + --gc-sections
• Try thin LTO if toolchain/resources allow
• Remove exceptions/RTTI only after ensuring error strategy
• Use minimal libc and custom allocators
• Separate debug info; run full tests with size flags enabled

This combination gives predictable, verifiable reductions while balancing debugability and runtime needs for constrained flash devices.