What Is the Purpose of a Reset Circuit in an Embedded System

What is the purpose of a reset circuit in an embedded system

I remember debugging a board that would occasionally boot into a completely broken state — peripherals misconfigured, variables holding leftover garbage from who-knows-where. It turned out the reset circuit wasn’t holding the reset line low long enough during power-up, so the microcontroller started executing code before its supply voltage had fully stabilized. That experience taught me that a reset circuit isn’t just “the thing that restarts the chip” — it’s a critical piece of ensuring a system always starts from a clean, known, predictable state. Let’s go through why that matters and how it actually works.

What Is a Reset Circuit?

A reset circuit is the hardware (and sometimes firmware-assisted) mechanism responsible for putting a microcontroller into a known initial state — clearing registers, resetting the program counter to the start of the boot code, and re-initializing internal peripherals — whenever the system powers up, a fault condition is detected, or a manual reset is triggered.

flowchart TB
    A[Power-On] --> B{Reset Circuit}
    C[Manual Reset Button] --> B
    D[Watchdog Timeout] --> B
    E[Brown-Out Detection] --> B
    F[Software Reset Command] --> B
    B --> G[Reset Line Asserted<br/>NRST Pin Low]
    G --> H[CPU Registers Cleared]
    H --> I[Program Counter -> Reset Vector]
    I --> J[Boot Sequence Begins]

Why a Reset Circuit Is Essential

1. Guaranteeing a Known Starting State

Digital circuits, including microcontrollers, do not necessarily power up in a predictable state. Flip-flops and registers can start in random states depending on manufacturing variance, temperature, and how quickly the supply voltage ramps. Without a proper reset, some registers might power up as 0, others as 1, unpredictably — a serious problem if, say, a motor control output pin powers up in the “on” state.

A reset circuit ensures that regardless of these unpredictable starting conditions, the CPU always begins execution from a defined reset vector with core registers cleared to known values.

2. Handling Power-On Conditions Correctly

When power is first applied, the supply voltage doesn’t jump instantly from 0V to 3.3V — it ramps up over some period of time (microseconds to milliseconds depending on the regulator). If the CPU starts trying to execute instructions while the voltage is still below the minimum operating threshold, its behavior is undefined — it might fetch corrupted instructions or behave erratically.

sequenceDiagram
    participant PSU as Power Supply
    participant RC as Reset Circuit
    participant MCU as Microcontroller
    PSU->>RC: VDD begins ramping
    RC->>MCU: Hold NRST LOW (reset asserted)
    PSU->>RC: VDD reaches stable level
    Note over RC: Wait additional delay (t_RSTL)
    RC->>MCU: Release NRST (reset de-asserted)
    MCU->>MCU: Begin boot sequence

This is exactly what a Power-On Reset (POR) circuit does — it holds the reset line active until the supply voltage has been stable above the minimum threshold for a specified delay time, guaranteeing the CPU only starts once conditions are safe.

3. Recovering from Fault Conditions

Reset circuits aren’t only for power-up — they also provide a recovery mechanism when something goes wrong during normal operation:

  • Brown-Out Reset (BOR): triggers if supply voltage dips below a safe operating threshold during runtime, preventing the CPU from continuing to execute in an unreliable voltage condition.
  • Watchdog Timer Reset: if firmware hangs or gets stuck in an infinite loop and fails to periodically “feed” (reset) the watchdog timer, the watchdog forces a system reset, allowing the device to recover automatically without human intervention.
  • Software Reset: firmware can deliberately trigger a reset — useful after applying a firmware update, or as a defensive recovery action when an unrecoverable error state is detected.
  • External/Manual Reset: a physical reset button or an external supervisor IC pulling the NRST pin low, often used during development and debugging.
flowchart LR
    A[Reset Sources] --> B[Power-On Reset<br/>POR]
    A --> C[Brown-Out Reset<br/>BOR]
    A --> D[Watchdog Timeout<br/>WDT]
    A --> E[External Pin Reset<br/>NRST]
    A --> F[Software Reset<br/>SYSRESETREQ]
    B --> G[Reset Controller]
    C --> G
    D --> G
    E --> G
    F --> G
    G --> H[CPU Core Reset]

Types of Reset Circuits

Basic RC Reset Circuit

The simplest reset circuit is a resistor-capacitor network connected to the reset pin, which holds the pin low briefly after power is applied while the capacitor charges, then releases it once the capacitor reaches the logic-high threshold.

flowchart LR
    VDD[VDD] --> R[Resistor]
    R --> NRST[NRST Pin]
    NRST --> C[Capacitor]
    C --> GND[GND]

While simple and cheap, a basic RC reset circuit has a real weakness: it doesn’t reliably detect brown-out conditions during runtime, and its timing can vary significantly with capacitor tolerance and temperature. Most modern designs instead use a dedicated supervisor IC.

Dedicated Reset/Supervisor IC

A supervisor IC (like the STM32’s internal POR/PDR circuit, or external chips like the MAX809/MAX6316) actively monitors the supply voltage and asserts reset whenever voltage falls outside a defined window, with precise, guaranteed timing — far more reliable than a passive RC network.

// STM32 example: Configuring the internal Programmable Voltage Detector (PVD)
// to trigger an interrupt (and optionally a controlled shutdown) if VDD drops
void pvd_init(void) {
    PWR_PVDTypeDef sConfigPVD = {0};
    sConfigPVD.PVDLevel = PWR_PVDLEVEL_5;   // ~2.8V threshold
    sConfigPVD.Mode = PWR_PVD_MODE_IT_RISING_FALLING;
    HAL_PWR_ConfigPVD(&sConfigPVD);
    HAL_PWR_EnablePVD();
}

void PVD_IRQHandler(void) {
    HAL_PWR_PVD_IRQHandler();
}

void HAL_PWR_PVDCallback(void) {
    // Save critical state to non-volatile memory before power loss
    save_critical_state_to_flash();
}

Watchdog Timer as a Reset Mechanism

The watchdog timer deserves special mention because it’s arguably the single most important reset mechanism for long-term reliability in unattended embedded systems.

// STM32 HAL example: Independent Watchdog (IWDG) configuration
IWDG_HandleTypeDef hiwdg;

void watchdog_init(void) {
    hiwdg.Instance = IWDG;
    hiwdg.Init.Prescaler = IWDG_PRESCALER_64;
    hiwdg.Init.Reload = 1250;   // ~2 second timeout with 32kHz LSI / 64 prescaler
    HAL_IWDG_Init(&hiwdg);
}

void watchdog_feed(void) {
    HAL_IWDG_Refresh(&hiwdg);
}

int main(void) {
    system_init();
    watchdog_init();

    while (1) {
        do_main_application_work();
        watchdog_feed();   // Must be called regularly or the MCU resets
    }
}

If do_main_application_work() ever hangs — due to a bug, a stuck sensor, a corrupted pointer — the watchdog stops being fed, times out, and forces a reset, automatically recovering the system. This is why almost every commercial embedded product enables a watchdog timer; it’s a critical safety net against unforeseen firmware bugs occurring in the field, where there’s no developer around to power-cycle the device manually.

The Boot Sequence After Reset

Once the reset line is released, the microcontroller follows a well-defined boot sequence:

flowchart TB
    A[Reset Released] --> B[Load Initial Stack Pointer<br/>from Vector Table]
    B --> C[Load Reset Vector<br/>Program Counter]
    C --> D[Execute Startup Code<br/>Clear .bss, Init .data]
    D --> E[System Clock Configuration<br/>SystemInit]
    E --> F[Call main]
    F --> G[Application Initialization]
    G --> H[Enter Main Loop]
// Simplified example of what happens in the reset handler (startup file)
void Reset_Handler(void) {
    // Copy initialized data from flash to RAM
    extern uint32_t _sidata, _sdata, _edata;
    uint32_t *src = &_sidata;
    uint32_t *dst = &_sdata;
    while (dst < &_edata) {
        *dst++ = *src++;
    }

    // Zero-initialize .bss section
    extern uint32_t _sbss, _ebss;
    dst = &_sbss;
    while (dst < &_ebss) {
        *dst++ = 0;
    }

    SystemInit();   // Configure clocks
    main();         // Jump to application entry point
}

Real-World Example: Reset Strategy for a Remote IoT Node

For a remote IoT sensor node deployed somewhere without easy physical access, I typically layer several reset mechanisms together:

  1. Power-on reset ensures the device always starts clean when power is first applied or restored after an outage.
  2. Brown-out reset protects against a weak/failing battery causing erratic behavior rather than a clean shutdown.
  3. Independent watchdog timer, fed only after confirming the main application loop, network stack, and sensor read are all functioning correctly — not just fed blindly at a fixed interval, since that would defeat its purpose.
  4. Software-triggered reset issued deliberately after a successful over-the-air firmware update, ensuring the new firmware boots from a completely clean state.

This layered strategy means the device can recover autonomously from almost any fault condition without needing a technician to visit the site.

Performance, Reliability, and Security Considerations

  • Performance: Reset timing matters — a reset circuit with too short a delay might release the CPU before the clock oscillator has stabilized, causing early instruction fetch errors; too long a delay unnecessarily increases boot time for time-sensitive applications.
  • Reliability: Never disable the watchdog timer in production firmware “to make debugging easier” and forget to re-enable it — this is a common and costly mistake that removes the system’s only automatic recovery mechanism from unexpected hangs.
  • Security: Some embedded systems intentionally clear sensitive data (encryption keys, credentials) from RAM during the reset sequence to prevent them from being recovered through cold-boot memory analysis attacks after a reset event.

Frequently Asked Questions

Q: What’s the difference between a power-on reset and a brown-out reset? Power-on reset handles the initial power-up transient, ensuring the CPU doesn’t start before voltage stabilizes. Brown-out reset monitors voltage continuously during runtime and resets the system if voltage drops below a safe threshold at any point, not just at startup.

Q: Why does my board need a reset button if it already has power-on reset? A manual reset button lets you restart the system without cycling power, useful during development and for user-triggered recovery (like a “reset to factory settings” button) without disconnecting the battery or power source.

Q: Should I feed the watchdog timer inside an interrupt or the main loop? Feed it in the main loop, ideally only after confirming key application tasks completed successfully — feeding it unconditionally inside a periodic interrupt defeats its purpose, since the main application could be hung while the interrupt keeps firing normally.

Q: What happens to RAM contents after a reset? This depends on the reset type — a power-on reset typically clears RAM since power was interrupted, but a watchdog or software reset (with power still applied) may leave RAM contents intact, which is why some designs use a small “no-init” RAM section to preserve diagnostic data across a watchdog reset for debugging.

Summary

The reset circuit is what guarantees an embedded system always starts, and recovers, from a known and predictable state — whether that’s the initial power-up moment, a brown-out condition from a sagging battery, or an unexpected firmware hang caught by a watchdog timer. Far from being a trivial support circuit, it’s one of the most important reliability features in any embedded product, especially those deployed remotely or unattended. Understanding the different reset sources, how they interact with the boot sequence, and how to design a layered reset strategy is essential for building embedded systems that can survive real-world conditions without needing a human to intervene every time something goes wrong.

References

Total
4
Shares

Leave a Reply

Previous Post
How is error handling implemented in an embedded system

How Is Error Handling Implemented in an Embedded System

Next Post
How does an embedded system handle low-level hardware interfaces

How Does an Embedded System Handle Low-Level Hardware Interfaces

Related Posts