Embedded Systems Background and Motivation Questions

Describe why embedded systems and hardware software integration interest you, citing specific domains such as IoT, real time control, or firmware development. Highlight relevant coursework, projects, toolchains, microcontroller or hardware platforms, and problems you solved such as low level optimization, power management, or device interfacing. Explain how your background prepared you to work on constrained systems and why the role and company match your technical interests and career goals. Include examples that show practical impact and cross disciplinary collaboration with electrical engineering or manufacturing.

EasyTechnical

42 practiced

You're bringing up a new board but it does not print any logs and appears not to reach the main application. Describe a systematic hardware-software debug checklist you would follow to find the cause. Include voltage and clock checks, reset and boot configuration pins, JTAG/SWD attach strategies, minimal test firmware, and how to isolate hardware from software issues.

Sample Answer

**Brief approach**I follow a systematic hardware→software narrowing process so I can isolate whether the board, peripherals, or firmware is at fault.

**1) Visual & basic sanity checks**- Inspect solder joints, orientation of ICs, connectors, decoupling caps, and boot strapping resistors.- Confirm power connector polarity and no visible shorts.

**2) Power & clock**- Measure rails with multimeter at the MCU VDD, VSSA, VDDA: expect within datasheet tolerance under idle.- Use scope to check ripple and transient during power-up.- Verify external oscillator(s) or crystal startup: probe clock pin; check PLL lock if applicable.

**3) Reset & boot pins**- Probe RESET (active low) waveform at power-up — should release cleanly.- Check BOOT/BOOT0, strapping pins, and pull-ups/pull-downs match intended boot mode.

**4) JTAG/SWD attach strategy**- Try attach with SWD at target voltage; use external pull resistors disabled/enabled as required.- If attach fails, try connecting with reset-hold or connect-under-reset mode.- Verify TCK/TMS/TDI/TDO or SWCLK/SWDIO levels and no pin mux conflicts.

**5) Minimal test firmware**- Flash a simple LED blink or UART early-init app that toggles a pin and continuously outputs a known banner at low baud (e.g., 9600) before enabling clocks/peripherals.- Add early fault hooks: toggle debug pin on entry to main(), and in reset/HardFault handlers toggle different patterns.

**6) Isolate hardware vs software**- If JTAG attaches and core halts, inspect vector table and stack pointer values; single-step to see if code enters reset handler.- If UART/LED test not running but JTAG attached: likely software (wrong flash, incorrect linker ORIGIN) or vector/clock config.- If no JTAG and no power/clock: likely hardware. Swap to a known-good MCU on same board or move CPU to reference board if possible.- Remove nonessential peripherals (sensors, power-hungry loads, external memories) to eliminate bus contention.

**7) Additional tactics**- Use current-limited bench supply to detect abnormal consumption.- Use logic analyzer to observe boot pin states and SWD signals.- Check alternate boot sources (serial bootloader) if available.

Result: this ordered checklist quickly narrows root cause; document findings and iterate with hardware engineer if a board-level fix is required.

HardTechnical

43 practiced

Design a DMA-based audio streaming pipeline on an embedded MCU to move ADC samples to a DAC with minimal CPU involvement and low latency. Explain buffer management (double or triple buffering), DMA descriptors, handling buffer underruns and overruns, sample format conversion (e.g., 16-bit to 24-bit), synchronization between audio clock domains, and how to test for and mitigate jitter.

Sample Answer

**Clarify requirements**- Target MCU, ADC→DAC path, sample rate (e.g., 48 kHz), sample widths (16→24-bit), latency target (<1 ms), CPU budget minimal.

**High-level approach**- Use peripheral-to-peripheral DMA where available, otherwise DMA from ADC FIFO to SRAM buffer and DMA from SRAM buffer to DAC.- Use triple buffering by default for low-latency & resilience: one buffer filling, one ready-to-play, one being consumed.

**Buffer management**- Buffers sized as N frames (frame = channels * sample_size). Choose N so DMA transfer time << buffer refill window (e.g., 128–512 frames).- Triple buffering state machine: EMPTY / FILLING / READY / PLAYING. Atomic pointer swaps via DMA completion IRQ or hardware semaphores to avoid races.- Double buffering acceptable if memory constrained but increases underrun risk.

**DMA descriptors**- Use linked-list descriptors (scatter-gather) so MCU programs a chain once. Each descriptor: source addr, dest addr, length, control flags, next pointer.- Set terminal count interrupts per-buffer to signal buffer ready/consumed; minimize work in ISR—just post semaphore or set index.

**Underrun/Overrun handling**- Detect via DMA error flags and buffer state mismatches. On underrun: output silence for affected buffers, log timestamp, attempt to re-sync by resetting DMA descriptor chain only when safe.- On overrun: drop oldest filled buffer(s) or signal backpressure to ADC (if supported), adjust producer rate.- Implement watchdog that counts consecutive underruns; after threshold, perform controlled resync (stop DMA, flush FIFOs, reset indices).

**Sample format conversion**- Prefer hardware sample converters (I2S/codec) if available. Otherwise use DMA with on-the-fly conversion via: - Peripheral DMA + simple MCU-accelerated inline conversion in ISR or via a lightweight DMA-channel-to-channel scatter-gather that applies conversion in intermediate SRAM. - For 16→24 bit: left-shift 16-bit to upper bits or sign-extend; for endianness, use byte-swap descriptor flags if supported.- Offload conversion using a small SIMD/parallel loop in a low-priority task if CPU can spare; ensure conversion completes before DAC DMA consumes buffer.

**Clock domain synchronization**- Use hardware sync: run ADC and DAC from same PLL or use master clock. If impossible, implement asynchronous FIFOs with sample-rate conversion (SRC) or a frame-dropping/insertion algorithm controlled by PLL trimming.- Use PTP/timestamping of buffers: measure ADC and DAC clocks drift and apply fractional sample rate adjustment (resampling) or jitter buffer resizing.

**Jitter testing & mitigation**- Test: inject known waveform, capture DAC output with logic analyzer or high-sample oscilloscope; measure sample-to-sample timing, use histogram of inter-sample intervals and phase noise analysis.- Mitigate: use low-jitter source clocks/PLL, enable peripheral clock gating to avoid glitches, prioritize DMA interrupts, use continuous DMA descriptors (no CPU reprogramming), and minimize ISR work.- Add jitter smoothing: small hardware FIFO, apply fractional delay filters in SRC, or use a PLL-based digital resampler.

**Trade-offs & verification**- Triple buffer uses more RAM but reduces underruns. Linked DMA descriptors reduce CPU load but are more complex.- Verify with long-run tests, stress tests (CPU load, interrupts, power modes), and measure latency and underrun rates; iterate buffer sizes and resampler parameters.

EasyTechnical

48 practiced

Describe the technical differences between I2C and SPI and give guidance for choosing between them when integrating sensors on a PCB. Discuss wiring, addressing, maximum data rate, clocking issues (clock stretching), bus topology, error detection, and typical hardware-level debugging steps.

Sample Answer

**Brief summary / when to use which**I2C: two-wire, multi-master/multi‑slave, good for short PCB runs with many low-speed sensors. SPI: four+ wires, full-duplex, higher throughput and deterministic timing — choose for high-rate sensors or when low latency is required.

**Wiring & topology**- I2C: SDA (data) + SCL (clock) with pull‑ups. Shared bus, star or daisy; keep traces short and matched where possible.- SPI: SCLK, MOSI, MISO, plus one CS per slave (or decoded CS). Point-to-point lines per device; can be routed in parallel or star but CS adds wiring.

**Addressing**- I2C: 7- or 10-bit addresses; avoid collisions, check configurable address pins.- SPI: no addresses — chip-select selects device.

**Maximum data rate**- I2C: standard 100 kbps, fast 400 kbps, fast-plus 1 Mbps, high-speed 3.4 Mbps (practical lower on long PCB traces).- SPI: often tens to hundreds of Mbps depending on MCU and sensor — check device timing.

**Clocking & clock stretching**- I2C: slaves may clock-stretch (hold SCL low) — firmware must handle waits/timeouts. Multi-master adds arbitration complexity.- SPI: master generates clock; slaves cannot stretch. Ensure clock idle polarity/phase (CPOL/CPHA) match.

**Error detection**- I2C: ACK/NACK after every byte; optional higher-layer CRC.- SPI: no built-in ACK — implement protocol-level checks (CRC, parity, status registers).

**Hardware-level debugging steps**- Inspect pull‑up values and presence on I2C; check CS lines and tri-state behavior on SPI.- Use logic analyzer/oscilloscope to view SDA/SCL or MOSI/MISO/SCLK/CS; verify levels, timing, setup/hold, CPOL/CPHA.- Check addresses, device IDs and who drives lines (bus contention). Probe for clock stretching by measuring SCL being held low.- Isolate devices (remove/tri-state CS or lift SDA) to localize faults.- Verify driver configs (I2C speed, SPI mode, bit order) and use short test firmware toggling pins.

Choose I2C for simplicity and many slow sensors; choose SPI when you need speed, robustness, or more deterministic timing.

MediumTechnical

49 practiced

Write an efficient function in C to compute CRC-16 (CRC-16-CCITT, polynomial 0x1021, initial value 0xFFFF) over a data buffer. The implementation should be suitable for a memory-constrained bootloader; discuss trade-offs between table-driven and bitwise implementations and provide the chosen implementation code or pseudocode.

Sample Answer

**Approach (brief)** For a bootloader memory-constrained environment, prefer a small, fast footprint. Two common options: a 256-entry table-driven CRC (fast, ~512 bytes ROM for table) or a bitwise/bytewise algorithm with no table (smallest ROM, slower). I choose a compact bytewise implementation using a 16-entry nibble table trade-off (reduces table size vs full 256 table) — good balance of speed and ROM.

**Trade-offs**- Full 256-table: fastest per byte, costs ~512 bytes ROM (uint16_t[256]).- Bitwise: minimal ROM, computationally expensive (per-bit loops).- Nibble table (chosen): ~32 bytes ROM, ~4x faster than bitwise, small code size.

**Code (C)**

#include <stdint.h>
/* 4-bit (nibble) table for CRC-16-CCITT (poly 0x1021) */
static const uint16_t crc16_nibble_table[16] = {
    0x0000,0x1021,0x2042,0x3063,0x4084,0x50A5,0x60C6,0x70E7,
    0x8108,0x9129,0xA14A,0xB16B,0xC18C,0xD1AD,0xE1CE,0xF1EF
};

/* Compute CRC-16-CCITT with init 0xFFFF, no final XOR */
uint16_t crc16_ccitt_nibble(const uint8_t *data, uint32_t len)
{
    uint16_t crc = 0xFFFF;
    while (len--) {
        uint8_t byte = *data++;
        /* process high nibble */
        uint8_t idx = (uint8_t)((crc >> 12) ^ (byte >> 4)) & 0x0F;
        crc = (uint16_t)((crc << 4) ^ crc16_nibble_table[idx]);
        /* process low nibble */
        idx = (uint8_t)((crc >> 12) ^ (byte & 0x0F)) & 0x0F;
        crc = (uint16_t)((crc << 4) ^ crc16_nibble_table[idx]);
    }
    return crc;
}

**Complexity & Notes**- Time: O(n) per byte with few ops; faster than bitwise, slower than 256-table.- Memory: ~32 bytes table + small code.- Edge cases: handle null pointer/len checks in caller if necessary; ensure consistent endianness when comparing CRCs.

MediumTechnical

62 practiced

What is a Board Support Package (BSP) in embedded development? Describe the typical components (startup code, vector table, peripheral initialization, HAL wrappers, device tree or board-specific config), the responsibilities for testing the BSP, and how BSP boundaries should be organized to enable portability across similar boards.

Unlock Full Question Bank

Get access to hundreds of Embedded Systems Background and Motivation interview questions and detailed answers.

Join thousands of developers preparing for their dream job.