MediumTechnical

31 practiced

Write a C function to compute CRC16-CCITT for firmware integrity checks. Provide an API `uint16_t crc16_ccitt(const uint8_t *data, size_t len)` and discuss how to speed it up using a 256-entry lookup table versus bitwise calculation. Also mention when using hardware CRC is preferable.

Sample Answer

**Approach (brief)** Implement standard CRC-16-CCITT (poly 0x1021), initial 0xFFFF, no final XOR. Show simple bitwise implementation then a 256-entry lookup (byte-wise) for speed. Discuss trade-offs and hardware use.

**Bitwise implementation (simple, small code)**

c

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

uint16_t crc16_ccitt_bitwise(const uint8_t *data, size_t len) {
    uint16_t crc = 0xFFFF;            // common init value
    while (len--) {
        crc ^= (uint16_t)(*data++) << 8;
        for (int i = 0; i < 8; ++i) {
            if (crc & 0x8000)
                crc = (crc << 1) ^ 0x1021;
            else
                crc <<= 1;
        }
    }
    return crc;
}

**256-entry lookup-table implementation (faster)**

c

static const uint16_t crc16_tab[256] = {
    /* precomputed 256 entries for poly 0x1021 */
    /* ... fill with standard table ... */
};

uint16_t crc16_ccitt(const uint8_t *data, size_t len) {
    uint16_t crc = 0xFFFF;
    while (len--) {
        crc = (uint16_t)((crc << 8) ^ crc16_tab[((crc >> 8) ^ *data++) & 0xFF]);
    }
    return crc;
}

**Why the table is faster** - Bitwise processes 8 iterations per byte (branching, shifts, XORs) — O(8·n) ops. - Table replaces inner loop with one table lookup and a couple ops — reduces CPU cycles significantly, ideal for high-throughput or large buffers.

**Trade-offs** - Table uses 512 bytes (256 * 2) of ROM; bitwise uses minimal memory. Choose table when flash/ROM budget and speed matter; choose bitwise for tiny ROMs.

**Hardware CRC** Prefer hardware CRC when available: offloads CPU, lower power, much higher throughput, often supports DMA. Use hardware if integrity checks are frequent or done on large images; verify polynomial/initial/final settings match algorithm.

**Edge cases & testing** - Validate against known vectors (empty buffer, "123456789" => 0x29B1 for CCITT-FALSE with init 0xFFFF). - Consider endianness only for how you transmit/store CRC.

MediumTechnical

27 practiced

After a firmware update, boards begin to blink an error LED during initialization. Outline an investigation sequence to determine whether this is caused by a CRC mismatch, vector table offset, peripheral initialization order, or bootloader-application interface mismatch. Include diagnostic instrumentation you would add temporarily to isolate the issue.

Sample Answer

**Quick goal:** narrow cause to one of CRC, vector table offset, peripheral init order, or bootloader-app interface mismatch by isolating bootloader vs application behavior with targeted instrumentation.

1) Reproduce & baseline- Reproduce failure on a known board and note LED blink pattern.- Try older firmware to ensure hardware unchanged.

2) Isolate bootloader vs application- Force bootloader to stay after update (hold pin or set debug flag). Observe if bootloader reports CRC/pass via UART or status LEDs.- Temporary instrumentation: add UART/USB log prints in bootloader for CRC result, image size, start address, and jump address.

3) Check CRC/image integrity- In bootloader, log computed CRC and expected CRC before jump.- Dump flash bytes (via SWD or bootloader comms) and run local CRC tool to confirm mismatch.- Instrumentation: expose CRC register or toggle a GPIO when CRC passes/fails.

4) Verify vector table & jump target- Log the application reset handler and initial SP read from vector table (read first two words). Confirm jump address equals app start + 4.- Use SWD to read the vector table in flash; check for linker script changes (offsets) and correct relocation.- Instrumentation: temporary early-app code that blinks a different LED immediately on entry to prove entry reached.

5) Test bootloader-application interface (C runtime / hardware state)- Check whether bootloader cleans up clocks, NVIC, MPU, FPU, and peripheral states expected by app.- Modify bootloader to perform a system reset after programming (clean slate) or to call application's reset handler with minimal state changes; compare behavior.- Instrumentation: add GPIO toggles at bootloader exit and app entry to measure timing and handoff.

6) Peripheral initialization order- If app reaches entry but fails later, enable early semihosted printf or UART to log initialization steps.- Stagger peripheral init (bring up clocks and critical peripherals first), or mock peripherals (disable drivers) to see if failure moves.- Instrumentation: assert/deassert peripheral power pins, and toggle GPIOs around each init block.

7) Use SWD debugger for final confirmation- Set a breakpoint at application reset handler, single-step early instructions, inspect MSP, PC, stack, and vector table contents.- Check for hardfault handlers and capture fault registers (HFSR, CFSR, BFAR, MMFAR).

8) Conclusion & fix path- If CRC mismatch: fix image generation/linker or bootloader CRC region; add CRC verification in CI.- If vector offset: fix linker script or bootloader jump offset.- If bootloader-app interface: standardize cleanup steps or perform system reset before app start.- If peripheral order: reorder init or make drivers tolerant of pre-configured hardware.

Keep temporary UART logs, GPIO toggles, and SWD traces until root cause proven; remove before release.

HardTechnical

25 practiced

Discuss pros and cons of using modern C++ (for example C++17) versus plain C for embedded firmware. Cover language features such as RAII, exceptions, templates, runtime overhead, static constructors, and how to manage features like dynamic memory and exceptions when targeting deeply constrained devices. Provide guidelines for a mixed-language codebase.

Sample Answer

**Situation & summary**As an embedded developer I've used both plain C and modern C++ (C++17). Choice depends on constraints: C minimizes runtime surprises and binary size; modern C++ improves safety and expressiveness when used deliberately.

**Pros of modern C++**- RAII: deterministic resource management (scoped hardware handles, mutexes) reduces leaks and simplifies cleanup.- Strong type system, constexpr, and templates: zero-cost abstractions (compile-time computation, type-safe wrappers) that can eliminate runtime overhead.- std::array, std::optional, span-like patterns: safer alternatives to raw pointers.

**Cons / pitfalls**- Exceptions: default handlers pull in runtime support and increase code size; enable only with careful toolchain support or disable and use error codes/expected.- Static constructors: global/static initialization can run before hardware is ready and bloat startup; prefer function-local statics or explicit init sequences.- Dynamic memory: heap use is risky on constrained devices (fragmentation, nondeterminism); avoid new/delete in production or provide a custom allocator with bounded behavior.- Templates misuse can blow up code size via instantiation; watch for implicit copies and heavy STL containers.

**Practical guidelines**- Disable exceptions and RTTI in constrained builds; use static analysis and error-return patterns.- Use RAII for stack-scoped resources only; avoid heap-backed RAII unless allocator is deterministic.- Prefer constexpr, inline functions, and templates that produce no runtime cost.- Enforce coding standards: banned APIs (std::vector with default allocator), allowed subset of std:: (array, tuple, algorithm).- Control static constructors: mark globals as POD or require explicit init() called from main/startup.- Measure: link map, size, and worst-case stack usage for each build.

**Mixed-language codebase**- Define clear boundaries: C for hardware drivers/startup and very low-level ISRs; C++ for higher-level subsystems and algorithms.- Use extern "C" API layers with simple, well-documented contracts and allocation ownership.- Provide a shared error model (error codes or expected-like wrappers) and a memory policy document.- CI: build both C and C++ configurations, run size and runtime regression tests, and require code-review for template/code-size impact.

Result: Use C++17 selectively—leverage compile-time features and RAII where they reduce bugs without adding runtime cost; keep low-level, deterministic code in C or tightly controlled C++ subset.

HardTechnical

31 practiced

Design a custom memory allocator suitable for an embedded system with tight RAM and long uptime. Describe an allocator API, how you would implement fixed-size block pools for small objects, strategies for variable-size allocation with low fragmentation such as TLSF or segregated free lists, and explain how you would detect and recover from memory exhaustion.

Sample Answer

**Overview / goals**Design must minimize RAM, predictable latency, low fragmentation, and safe long uptime. Use mix: fixed-size block pools for small objects (fast, no fragmentation) + segregated variable-size allocator (TLSF-like) for larger blocks. Provide diagnostics and recovery for exhaustion.

**Allocator API (C)**

c

void allocator_init(void *heap, size_t heap_size);
void *alloc(size_t size);
void *zalloc(size_t size); // zeroed
void dealloc(void *ptr);
size_t allocator_free_bytes(void);
void allocator_dump_stats(void);

**Fixed-size block pools**- Create multiple pools for power-of-two or common sizes (16,32,64,128).- Each pool: contiguous region split into fixed blocks, single-linked free list stored in-block (first word).- Allocation: choose smallest pool >= size, pop head (O(1)).- Free: push back. No metadata outside pool; stores magic/tag in header for debugging.

Code sketch:

c

// each block: next ptr stored in first bytes
typedef struct { void *next; } free_block_t;

**Variable-size strategy**- Use TLSF-inspired segregated free lists: two-level indexing (size class, sub-index) for O(1) worst-case.- Keep block headers with size and free/used bit; boundary tags for coalescing.- Maintain bitmap for non-empty lists for fast find.- For simplicity on tiny systems, implement segregated free lists by size ranges (power-of-two buckets) with first-fit in bucket.

**Fragmentation controls**- Coalesce on free using boundary tags.- Split larger blocks when allocating to reduce waste, enforce minimum split size.- Use placement policy favoring exact fit or small-split to avoid external fragmentation.

**Detecting & recovering from exhaustion**- allocator_free_bytes() + statistics track low-watermark and fragmentation ratio.- On alloc failure: - Attempt to run garbage: coalesce entire heap and retry. - If RTOS: notify task, return NULL and optional OOM callback: void (*oom_handler)(size_t requested); - Provide reserve pool: a small emergency fixed-size pool (e.g., for critical logging and safe shutdown). - Optionally trigger watchdog-safe reboot if system-critical.

**Debugging & safety**- Add canaries, checksums, allocation timestamps for leak detection.- Periodic background heap defragmentation where permitted.- Unit tests: stress with long-running allocation/free patterns to validate long uptime safety.

Trade-offs: TLSF gives O(1) and low fragmentation but more code/metadata; segregated simple lists save code size. Choose based on CPU/flash limits.

EasyTechnical

25 practiced

Explain the purpose of a bootloader in embedded devices. Describe common bootloader features such as UART/USB/DFU update, integrity checks, and fallback images, and explain how a bootloader is used in over-the-air updates for constrained devices. Include a simple partition layout for dual-bank OTA.

Embedded Systems Background Questions

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Sample Answer

Unlock Full Question Bank