Why Does My STM32 Keep Resetting Unexpectedly?

Detailed Explanation

STM32 parts expose a reset-cause register (RCC_CSR on F4/F1-class parts, RCC_RSR on newer G0/G4/H5 families) that latches a flag for each possible reset source and persists across the reset itself. The four most common causes in the field are:

1. Independent or window watchdog (IWDG/WWDG) timeout — firmware stalled (deadlock, infinite loop, blocking on a peripheral that never responds) and missed its watchdog refresh window.
2. Brown-out / power-on reset (BOR/POR) — the supply rail dropped below the brown-out threshold, often momentarily under load.
3. Hard fault escalating to a system reset — an unhandled fault (bad pointer, stack overflow, unaligned access, or NVIC priority misconfiguration when using FreeRTOS) that the fault handler resolves by forcing a reset rather than halting. See STM32 NVIC interrupt priority configuration for the FreeRTOS-specific priority constraints that cause hard faults when violated.
4. External NRST glitch — noise or a marginal reset-line design pulling NRST low transiently.

Reading the flag register first thing in main() (or even earlier, in SystemInit) and logging or storing it before anything else touches the register turns "it just resets sometimes" into a specific, addressable bug.

Practical Examples

A board that resets only when a Wi-Fi or BLE radio transmits is a textbook brown-out symptom: the transmit current spike sags the 3.3V rail just enough to trip BOR, especially if decoupling capacitance near the radio is thin. Reading RCC_CSR after such a reset and seeing the BOR flag set (rather than the watchdog flag) immediately rules out a firmware logic bug and points straight at power design.

Conversely, a reset that only happens after the device has been running for hours under heavy peripheral load, with the IWDG flag set, points at a deadlock or missed refresh under specific timing conditions — a firmware bug, not a hardware one.

Design Considerations

• Always enable and service a watchdog timer in production firmware — it converts an unrecoverable hang into a clean, identifiable reset rather than a frozen device.
• Verify clock configuration before assuming a firmware bug: a PLL configured with insufficient flash wait states, or an HSE that never reaches its ready flag, can cause crashes at startup that look like firmware faults. See how the STM32 clock tree works for the correct initialisation sequence.
• Decouple aggressively near high-transient loads (radios, motor drivers, relays) and verify rail droop with a scope under real load, not just a multimeter average.
• Log the reset cause to non-volatile storage (or send it over the debug/telemetry channel) on every boot in deployed products — without this, field-reported "random resets" are nearly impossible to diagnose remotely.
• Clear the reset flags explicitly (RCC_CSR |= RCC_CSR_RMVF or equivalent) after reading them, since they otherwise persist and can be misread after a subsequent unrelated reset.
• Production firmware reliability: Shipping firmware that handles watchdog timeouts, hard faults, and power-supply variations gracefully requires production-hardened patterns — Zeus Design's embedded software team builds this robustness in as a standard part of the firmware development process.

Common Mistakes

• Disabling the watchdog "temporarily" during development and forgetting to re-enable it before shipping.
• Assuming every reset is a firmware bug without first checking whether it's actually a brown-out from inadequate decoupling.
• Refreshing the watchdog from a low-priority task or interrupt that can itself be starved, which defeats the watchdog's purpose.
• Never reading the reset-cause register at all, leaving the team debugging blind on every field report.