Why Embedded Development Feels Hard and How to Fix Common Bugs

Problem Reproduction

Stable reproduction is the first step for reliable debugging. The easier a bug can be reproduced, the faster it can be isolated.

Simulate the original conditions – If the defect only appears under specific hardware states or external inputs, create a test harness that forces the system into those states. When the conditions are too complex to emulate, add a test‑only code path that directly sets the required state.

Increase the execution frequency of the suspect task – For bugs that manifest after long‑running operations, run the task more often (e.g., reduce its period or call it in a loop) to surface the failure sooner.

Scale the test sample size – Deploy multiple identical boards or simulation instances in parallel so that the same scenario runs concurrently, providing more data points and reducing the time needed to observe intermittent failures.

Problem Localization

Insert logging – Add printf /UART or SWO logs at suspected code locations to trace execution flow and variable values.

Online debugging – Use a JTAG/SWD debugger to halt the CPU when a HardFault or watchdog interrupt occurs, then inspect the call stack and core registers (PC, LR, R0‑R3, SP).

Version rollback – With Git (or another VCS), iteratively checkout earlier commits and test until the bug disappears, thereby identifying the introducing commit.

Binary bisection (二分注释) – Comment out roughly half of the unrelated code, rebuild, and test. If the bug persists, comment the other half; otherwise, continue halving the remaining region until the faulty module is isolated.

Save core register snapshot – When a Cortex‑M core enters an exception, the hardware pushes registers onto the stack. Copy this stack region to a known RAM area before reset, then read it back after reboot to determine the faulting PC/LR and examine R0‑R3 for abnormal data.

Problem Analysis & Handling

Program Continuation Issues

Array out‑of‑bounds – Writing past the end of an array corrupts adjacent memory. Use the linker map file to locate the array and add bounds checks or redesign the data structure.

Stack overflow – Excessive stack usage overwrites variables. Analyse maximum stack depth (e.g., with a stack‑usage map or runtime watermark), move large buffers to static or heap memory, increase the stack size in the linker script, and reduce ISR nesting depth.

Chip errata – Some MCUs return erroneous values under certain conditions. Filter out‑of‑spec values in software after consulting the silicon errata.

Communication timing violations – For chained devices (e.g., ISL78600 voltage‑monitor chips), ensure the master reads data within the required window; otherwise new samples overwrite the previous ones. Follow the device’s timing diagram precisely.

Conditional operator mistakes – Accidentally using assignment ( =) instead of equality ( ==) makes the condition always true and changes the variable’s value. Write the variable on the right‑hand side or enable compiler warnings for implicit assignments.

Synchronization problems – Concurrent queue operations without disabling interrupts or using mutexes can corrupt the queue. Protect critical sections with __disable_irq() / __enable_irq() or an RTOS mutex.

Optimization side‑effects – Compilers may cache a flag variable in a register, ignoring updates from an ISR. Declare such flags as volatile to force a RAM read on each access.

Program Crashes

HardFault causes

Accessing peripheral registers before enabling the peripheral clock.

Jumping to an out‑of‑range function pointer (often due to corrupted data).

Misaligned pointer dereference (e.g., treating a uint8_t address as uint16_t). Use memcpy for unaligned accesses.

ISR errors – Forgetting to clear an interrupt flag before exiting the ISR causes immediate re‑entry, producing a “pseudo‑dead” state.

Unexpected NMI activation – Pins multiplexed as NMI (e.g., SPI MISO) can trigger NMI if the external device drives the line high. Disable NMI inside its handler or re‑configure the pin before enabling the peripheral.

Reset failures

Crystal oscillator not starting.

Insufficient supply voltage.

Reset pin held low.

Regression Testing

After applying a fix, rerun the reproduction steps and the expanded test matrix to confirm the defect no longer appears and that no new regressions were introduced.

Experience Summary

Document the root cause, the corrective actions, and preventive measures (e.g., adding bounds checks, increasing stack size, using volatile, improving test coverage). Apply these lessons to future projects on the same platform.