Reset is one of the most important features in any microcontroller. It makes sure the device always starts in a known, stable state, no matter what happens during power-up, power-down, or unexpected faults.
In the STM32 microcontroller family, the RCC (Reset and Clock Control) module is responsible not only for managing clock sources but also for handling different types of resets that affect the device’s internal and peripheral states.
In this blog, we will dive into the different types of resets in STM32 microcontrollers, uncover why they happen, and see how they affect your system.
RCC reset functional description:
The RCC reset logic ensures that only the right parts of the chip are reset at the right time — whether it’s due to power failure, watchdog timeout, or a software-triggered reset.
It provides:
- Reset cause flags (in the RCC_RSR register) — this record why the last reset occurred.
- Peripheral-specific reset lines — allowing individual buses and modules to be reset independently.
- Domain-level control — including the special Backup domain, which retains critical RTC and backup data.
In STM32 devices, resets are generally categorized into three main types:
- System Reset.
- Power Reset.
- Backup Domain Reset.
Power Reset (BOR / Standby Exit):
A Power Reset is generated by the RCC when one of the following events occurs:
- A Brownout Reset (BOR) — which includes Power-On Reset (POR) and Power-Down Reset (PDR) conditions.
- When exiting from Standby mode.
These events ensure that the microcontroller starts (or restarts) cleanly with the appropriate domains reset and reinitialized.
Brownout Reset (BOR / POR / PDR):
A Brownout Reset occurs when the supply voltage drops below or rises above the defined threshold. This condition covers Power-On and Power-Down resets as well.
When a brownout reset happens:
- All registers are restored to their default reset values,
- Except those in the Backup domain (RTC, backup registers, and backup SRAM).
This ensures system-wide initialization while preserving critical low-power and RTC-related data that survive across power transitions.
Few important points:
- Ensures the device only operates once the supply voltage is stable.
- Protects the MCU from undefined states during voltage drops.
- RTC and backup registers in the Backup domain remain intact as long as a backup domain reset is not triggered and VBAT (or VDD) continues to supply power.
Reset on Standby Exit:
When an STM32 device wakes up from Standby mode, it undergoes a special form of Power Reset. This reset selectively targets the core domain, ensuring a clean restart while preserving essential low-power configurations.
In this case:
- Registers in the core domain (CPU, peripherals, buses, RCC configuration) are reset to their default state.
- Registers outside the core domain remain unchanged, including:
- RTC registers.
- Wake-up pin (WKUP) configuration.
- Independent Watchdog (IWDG).
- GPIO pull-up/pull-down settings retained during Standby
This selective reset behavior allows low-power applications to resume operation quickly without the need to reinitialize the entire device.
System Reset:
A System Reset is the most common type of reset in STM32 microcontrollers. It reinitializes nearly all components including the CPU core, peripheral registers, and clock configuration — effectively bringing the microcontroller to the same state as it would be immediately after a power-up.
Causes of System Reset”
A system reset can be triggered by several events:
- Power-On Reset (POR) / Power-Down Reset (PDR): Occurs when the supply voltage rises above or falls below the valid operating range.
- External Reset (NRST pin): Pulling the NRST pin low triggers a global system reset.
- Software Reset: Initiated by the Cortex-M core via the SYSRESETREQ bit in the AIRCR register.
- Watchdog Timeout (IWDG / WWDG): Triggered if a watchdog timer is not refreshed within its timeout period.
- Low-Power Management Reset: Happens during wake-up from specific low-power modes.
What Gets Reset:
During a system reset, the following components are reinitialized:
- CPU registers and core logic
- Most peripheral registers
- RCC (Reset and Clock Control) configuration, restoring default clock settings
- SRAM contents and Flash interface states.
What Remains Unchanged:
Some domains retain their state across a system reset:
- Backup Domain: Includes RTC and backup registers
- Debug and Trace Registers: Depending on debug configuration, some debug-related registers may remain unchanged.
Backup Domain Reset:
The Backup Domain is a specialized section of STM32 microcontrollers that remains powered by VBAT, even when the main supply voltage (VDD) is off. This domain is designed to retain critical data across power cycles, making it essential for low-power and time-sensitive applications.
What’s Included in the Backup Domain:
- RTC registers and clock configuration
- Backup registers (BKP_DRx)
- Backup SRAM (available on select STM32 devices)
This setup allows the MCU to preserve real-time clock data, calibration constants, or other persistent values even during power loss — as long as VBAT remains connected.
When Does a Backup Domain Reset Occur?
A Backup Domain Reset is triggered under the following conditions:
- When the Backup Domain Reset bit (BDRST) in the RCC_BDCR register is set by software.
- During a Power-On Reset, specifically when VBAT transitions from 0 → 1.
- If VBAT power is lost or reconnected, causing the domain to lose its retained state.
These events cause the system to lose all backup domain data, returning the RTC and related registers to their default states.
Effect of a Backup Domain Reset:
When a backup domain reset occurs, the following actions take place:
- All RTC and backup registers are cleared.
- The LSE oscillator and RTC clock configuration are reset.
- Any content in the Backup SRAM is erased.
Essentially, the entire RTC and backup subsystem reverts to its factory-reset condition.
Why Perform a Backup Domain Reset?
Although typically avoided during normal operation, firmware developers may intentionally trigger a backup domain reset when:
- Reconfiguring the RTC source (for example, switching between LSE and LSI).
- Replacing the battery (VBAT) to ensure proper reinitialization.
- Recovering from RTC or LSE oscillator faults.
This helps ensure proper synchronization and a clean RTC setup when system conditions change.
STM32 Backup Domain & VBAT – Quick Insights:
The Backup Domain acts as the MCU’s memory vault — preserving RTC and critical registers even when main power (VDD) is lost.
Power Sources:
- Normally, VDD (main supply) powers the backup domain.
- When VDD disappears, VBAT (backup battery) takes over automatically — keeping your RTC alive without interruption.
Startup Delay (tRSTTEMPO) :
- During VDD startup or right after a Power-Down Reset (PDR), there’s a brief delay called tRSTTEMPO.
- In this tiny window, the backup domain is still connected to VBAT — the battery is holding the fort!
Beware the Reverse Current:
- If VDD jumps too fast and becomes > VBAT + 0.6V, current can flow back into VBAT through an internal diode.
- Small batteries (like coin cells or supercaps) may get damaged or drained if unprotected.
The Safe Fix – Add a Diode
- A low-drop diode between your VBAT source and the MCU blocks reverse current.
- Keeps your backup domain safe while letting the RTC run normally.
What Happens on Backup Domain Reset:
- RTC and backup registers cleared
- LSE oscillator and RTC clock reset
- Backup SRAM erased
Power Priority:
- VDD present → backup domain powered by VDD
- VDD lost, VBAT present → backup domain powered by VBAT
- VBAT lost → backup domain unpowered → data lost
No Software Control:
- The VDD ↔ VBAT switch is automatic.
- Firmware cannot influence this — it’s all handled by the MCU hardware.
Detecting the Reset Cause on STM32:
After every reset, STM32 microcontrollers store the source of the reset in the Reset Status Register (RCC_RSR). Each bit corresponds to a specific type of reset:
| Flag | Meaning |
|---|---|
| PORRSTF | Power-on or Power-down reset |
| PINRSTF | External NRST reset |
| SFTRSTF | Software-triggered reset |
| IWDGRSTF | Independent watchdog reset |
| WWDGRSTF | Window watchdog reset |
| LPWRRSTF | Low-power reset |
Example Code to Detect Reset Cause
// Read the reset cause
uint32_t reset_cause = RCC->RSR;
// Check each flag
if (reset_cause & RCC_RSR_PORRSTF) {
// Handle Power-on / Power-down reset
}
if (reset_cause & RCC_RSR_PINRSTF) {
// Handle NRST external pin reset
}
if (reset_cause & RCC_RSR_SFTRSTF) {
// Handle software reset
}
if (reset_cause & RCC_RSR_IWDGRSTF) {
// Handle independent watchdog reset
}
if (reset_cause & RCC_RSR_WWDGRSTF) {
// Handle window watchdog reset
}
if (reset_cause & RCC_RSR_LPWRRSTF) {
// Handle low-power reset
}
// Clear all reset flags to prepare for the next reset
RCC->RSR |= RCC_RSR_RMVF;
Important Points:
- Read Before Clear: Always read RCC->RSR before clearing the flags; otherwise, you lose the reset source information.
- Clear All Flags: Use the RMVF bit to clear all flags at once. This ensures the next reset is detected accurately.
- Use Cases: Detecting reset causes is essential for debugging unexpected resets, managing watchdogs, or implementing safe recovery mechanisms.