Watchdog vs Brown-Out Reset: Understanding Microcontroller Reset Mechanisms

1. What Is a Watchdog Timer in a Microcontroller?

A Watchdog Timer is a hardware timer designed to detect certain failures in software execution. It monitors whether firmware services the timer within a specified period.

If the firmware fails to refresh the watchdog before its timeout expires, the watchdog can generate a microcontroller reset, depending on its configuration.

Think of a watchdog timer as a supervisor that expects the application to report that it is operating correctly.

For example, consider an embedded temperature monitoring system. The firmware reads a temperature sensor, processes the data, updates a display, and transmits the result over UART.

If a software bug causes the application to enter an infinite loop, the system may stop updating the display. A correctly configured watchdog can detect the missing refresh and restart the microcontroller.

How does a watchdog timer work?

A typical watchdog implementation follows this sequence:

1. The microcontroller starts and initializes its peripherals.
2. The firmware configures and starts the watchdog timer.
3. The application performs its normal operations.
4. The firmware refreshes the watchdog after completing the required tasks.
5. The watchdog continues operating as long as it is serviced within its permitted timing limits.
6. If the firmware stops servicing the watchdog, the timer expires.
7. If reset-on-timeout is enabled, the watchdog resets the microcontroller.
8. After a watchdog reset, the processor follows its reset sequence and executes the startup code again.

However, a watchdog does not understand whether the application is logically correct. It only checks the conditions defined by its hardware and firmware configuration. If a faulty program continues refreshing the watchdog, the timer may never detect the underlying problem.

Why is a watchdog timer important?

A microcontroller may experience software failures for several reasons:

• An infinite loop caused by a programming error.
• A deadlock between two tasks.
• A communication task waiting indefinitely for a response.
• An unexpected execution path that prevents normal task completion.
• A peripheral operation that blocks the application.
• A real-time task that fails to execute within its required interval.

A watchdog provides a mechanism for recovering from some of these failures without requiring a person to press a reset button.

It is especially useful in embedded devices that operate unattended, such as remote sensor nodes, industrial controllers, smart meters, and monitoring equipment.

2. Types of Watchdog Timers: IWDG vs WWDG

Many STM32 microcontrollers provide two watchdog types: the Independent Watchdog and the Window Watchdog. Their availability and implementation depend on the specific STM32 family.

Independent Watchdog (IWDG)

The Independent Watchdog generally uses a dedicated low-speed clock source, commonly the low-speed internal oscillator (LSI) on STM32 devices.

Because it operates independently of the main application clock, it can provide protection against certain clock-related failures as well as firmware execution failures.

Important characteristics include:

• It uses a prescaler and reload value to determine its timeout.
• Firmware must refresh the counter before it expires.
• It is often suitable for applications requiring straightforward timeout-based supervision.
• On many STM32 devices, once started, it cannot be stopped by normal software until a reset occurs.

The exact clock source, configuration options, and ability to stop the watchdog must be verified in the relevant device reference manual.

Window Watchdog (WWDG)

A Window Watchdog checks whether firmware refreshes the watchdog within a permitted time window.

This means refreshing the watchdog too late can cause a reset, but refreshing it too early can also cause a reset.

For example, suppose a watchdog refresh is permitted only between 10 ms and 30 ms after a previous refresh. A refresh at 5 ms would be too early, while a refresh at 35 ms would be too late.

This behavior can help detect certain timing errors in software.

The WWDG typically relies on a clock derived from the peripheral clock, so clock configuration and prescaling affect its timing.

IWDG vs WWDG

For students, the key concept is that an IWDG checks whether the application refreshes the watchdog before timeout, while a WWDG can also check whether the refresh occurs at an appropriate time.

3. What Is Brown-Out Reset in a Microcontroller?

A Brown-Out Reset is a reset mechanism that responds when the microcontroller’s supply voltage falls below a specified threshold.

Microcontrollers operate correctly only within their specified electrical limits. If the supply voltage becomes too low, the processor may no longer execute instructions reliably. Flash access, peripheral operation, communication interfaces, and GPIO behavior may also be affected, depending on the device and operating conditions.

A brown-out detection circuit monitors the supply voltage and asserts or maintains a reset when the voltage falls below its configured threshold.

Unlike a watchdog timer, a brown-out reset does not depend on firmware periodically refreshing a timer. It responds to the voltage condition detected by the hardware.

How does Brown-Out Reset work?

A typical brown-out sequence is as follows:

1. The microcontroller receives power from a battery, regulator, or other supply.
2. The voltage-monitoring circuitry monitors the relevant supply rail.
3. The supply voltage drops below the configured brown-out threshold.
4. The brown-out mechanism initiates or maintains a reset according to the device design.
5. The voltage recovers to an acceptable level.
6. The microcontroller is released from reset when the required recovery conditions are satisfied.
7. Firmware starts again and initializes the system.

The precise behavior depends on the microcontroller. Some devices provide selectable voltage thresholds, while others have fixed or differently configurable monitoring levels.

What causes a brown-out condition?

A voltage drop can occur because of several hardware-related issues.

1. Battery voltage decreases — As a battery discharges, its voltage may fall. Under heavy load, internal resistance can cause an additional temporary voltage drop.

2. Motor startup current — A motor may draw a high starting current. If the power supply or wiring cannot support that current, the voltage supplied to the microcontroller may drop.

3. Poor power supply design — An undersized regulator, inadequate decoupling, or excessive wiring resistance can create voltage instability.

4. Sudden load changes — When a high-current peripheral switches on, the supply voltage may temporarily decrease because the power source cannot respond quickly enough.

5. Unstable external power — A faulty adapter, damaged connector, or intermittent power connection can cause the voltage to fluctuate.

Why is Brown-Out Reset important?

Suppose an embedded controller operates at a supply voltage that falls below the range required for reliable operation.

Without suitable voltage monitoring, the processor may continue executing while its behavior is no longer guaranteed. It could produce incorrect outputs or enter an unexpected state.

Brown-out protection helps prevent normal execution during an unsafe voltage condition by keeping the microcontroller in reset when required.

It is particularly useful in battery-powered products, industrial controllers, automotive electronics, and IoT devices.

4. Watchdog vs Brown-Out Reset: Key Differences

Both mechanisms can cause a microcontroller to restart, but they monitor different conditions.

The most important distinction is simple:

Neither mechanism replaces the other because their triggering conditions are different.

5. Watchdog Timeout Calculation: A Practical Example

Understanding watchdog configuration is important when working with embedded C and microcontrollers.

If the watchdog timeout is too short, normal application operations may trigger unwanted resets. If it is too long, the system may remain unresponsive for longer than the application can tolerate.

For a typical down-counting STM32 Independent Watchdog, the nominal timeout can be calculated using:

The actual implementation and counter details should be verified for the selected device.

Example calculation

Suppose a microcontroller has the following illustrative watchdog settings:

• Watchdog clock frequency: 32,000 Hz
• Prescaler: 32
• Reload value: 999

The timeout is:

The nominal watchdog timeout is therefore approximately one second.

This means the firmware must refresh the watchdog before the timeout expires.

In practice, the watchdog clock may vary because of oscillator tolerance and operating conditions. Engineers should allow a suitable timing margin and verify the actual clock characteristics specified by the manufacturer.

What happens if the timeout is too short?

Suppose an application occasionally performs a flash operation or processes a large sensor dataset. If that operation takes longer than the watchdog timeout and no valid refresh occurs, the microcontroller may reset even though the software is behaving as designed.

To avoid this problem:

• Measure worst-case execution times.
• Account for interrupt latency and scheduling delays.
• Avoid blocking operations that exceed the watchdog budget.
• Choose a timeout that supports the application’s recovery requirements.
• Prefer task-level health checks when multiple software tasks must be supervised.

What happens if the timeout is too long?

A long timeout may allow a failed application to remain unresponsive for several seconds.

For a display device, that might be acceptable. For a controller that must respond to faults quickly, the delay could be unacceptable.

The timeout should therefore be based on the application’s maximum acceptable recovery time rather than an arbitrary value.

6. Embedded C Example: Configuring a Watchdog Timer on STM32

The following example demonstrates the basic use of an Independent Watchdog with STM32 HAL.

The exact initialization code, supported prescalers, reload range, and clock configuration depend on the STM32 family. The example assumes the required HAL headers and project initialization are already in place.

#include "main.h"

IWDG_HandleTypeDef hiwdg;

static void Watchdog_Init(void)
{
    hiwdg.Instance = IWDG;
    hiwdg.Init.Prescaler = IWDG_PRESCALER_32;
    hiwdg.Init.Reload = 999;

    if (HAL_IWDG_Init(&hiwdg) != HAL_OK)
    {
        Error_Handler();
    }
}

int main(void)
{
    HAL_Init();
    SystemClock_Config();
    MX_GPIO_Init();

    Watchdog_Init();

    while (1)
    {
        Read_Sensor();
        Process_Sensor_Data();
        Update_Output();

        /*
         * Refresh only after required operations
         * have completed successfully.
         */
        if (Application_Health_Check())
        {
            HAL_IWDG_Refresh(&hiwdg);
        }
    }
}

The functions Read_Sensor(), Process_Sensor_Data(), Update_Output(), and Application_Health_Check() represent application-specific functions that must be implemented separately.

Understanding the code

Step 1: Initialize the watchdog handle

hiwdg.Instance = IWDG;

This selects the Independent Watchdog peripheral for the HAL configuration.

Step 2: Configure the prescaler

hiwdg.Init.Prescaler = IWDG_PRESCALER_32;

The prescaler divides the watchdog clock, affecting how quickly the counter progresses.

Step 3: Configure the reload value

hiwdg.Init.Reload = 999;

The reload value determines the watchdog timeout together with the prescaler and clock frequency.

Step 4: Start the watchdog

HAL_IWDG_Init(&hiwdg);

This initializes the watchdog using the configured settings. On many STM32 devices, starting the IWDG makes it continue running until a reset.

Step 5: Refresh the watchdog after successful operations

HAL_IWDG_Refresh(&hiwdg);

This reloads the watchdog counter so that it does not expire.

However, a production application should not rely on a superficial health-check function that always returns true. It should verify that critical operations and tasks are actually making progress.

For a multitasking system, a dedicated supervision mechanism can collect health indicators from each critical task and refresh the watchdog only when the required conditions are satisfied.

7. How to Detect and Debug a Watchdog Reset

When a microcontroller restarts unexpectedly, the next step is to identify the reset source.

A restart alone does not prove that the watchdog caused the problem. Reset status flags can help distinguish watchdog resets from brown-out events, power-on resets, software resets, and external resets.

Step 1: Inspect the reset-cause flags

Many STM32 families expose reset status flags through the Reset and Clock Control (RCC) peripheral.

Depending on the family, these may include flags associated with:

• Independent Watchdog Reset
• Window Watchdog Reset
• Brown-Out or Power-Down Reset
• Power-On Reset
• External Pin Reset
• Software Reset

The available flags and their names differ between STM32 families.

Step 2: Capture the flags early during startup

Reset-cause information should be captured before clearing the flags or executing code that might change them.

A family-dependent example using STM32 HAL-style macros is shown below:

uint32_t reset_status;

void Capture_Reset_Cause(void)
{
    reset_status = RCC->CSR;

    /*
     * Interpret reset_status using the
     * definitions for the selected STM32.
     *
     * Clear reset flags only after recording
     * the information needed for debugging.
     */
}

This is an illustrative pattern, not portable code for all STM32 devices. Some families use different registers or flag-clearing procedures. Check the relevant reference manual and startup code.

Step 3: Log the reset reason

For debugging, save the captured reset status in a suitable diagnostic record.

Depending on the application, the record may include:

• Reset source flags
• Firmware version
• Last successfully completed task
• Error code
• Relevant sensor or power measurements

If the information must survive a microcontroller reset, use an appropriate retention mechanism, backup register, or nonvolatile storage method supported by the device. Ordinary RAM may not retain its contents after a reset.

Step 4: Reproduce the failure

Try to reproduce the issue under controlled conditions.

For a watchdog reset, investigate long execution paths, deadlocks, communication timeouts, and tasks that fail to make progress.

For a brown-out reset, monitor the supply voltage using suitable laboratory equipment and check for voltage drops during load changes.

A reset-cause flag helps narrow the investigation, but it does not necessarily identify the underlying root cause.

8. Brown-Out Reset vs Power-On Reset vs External Reset

Watchdog and brown-out resets are not the only reset mechanisms in a microcontroller.

Understanding the other reset sources helps students diagnose startup and reliability problems.

Power-On Reset (POR)

A Power-On Reset initializes the microcontroller when power is applied and rises through the required startup conditions.

It ensures that the processor does not begin normal execution before the relevant power-on reset requirements are satisfied.

Brown-Out Reset (BOR)

A Brown-Out Reset responds when the monitored supply voltage becomes too low during startup or normal operation, according to the device’s implementation.

It helps prevent normal operation while the supply is outside the conditions required for reliable operation.

External Reset

An external reset allows a reset pin or external reset circuit to restart the microcontroller.

A reset button, supervisor IC, or another circuit may control this input.

Software Reset

Some microcontrollers allow firmware to request a system reset through a software-controlled reset mechanism.

This can be useful when the application intentionally needs to restart the processor.

Comparison table

The precise reset behavior and reset-cause flags depend on the microcontroller family.

9. Real-World Applications of Watchdog and Brown-Out Reset

Application 1: Automotive Embedded Systems

Automotive electronic control units process sensor inputs and control systems such as lighting, monitoring, and other vehicle functions.

A firmware execution failure may prevent the controller from responding correctly. A watchdog can help detect certain failures and initiate a reset.

At the same time, supply-voltage monitoring is important because automotive electrical systems can experience substantial voltage variations and transients.

A watchdog and brown-out mechanism may be part of a broader reliability design, but safety-critical applications also require appropriate fault handling, diagnostics, and compliance with relevant safety requirements.

Application 2: IoT Sensor Nodes

Consider a remote environmental monitoring device that measures temperature and humidity and transmits readings over a wireless network.

Because the device may operate unattended for months, a software hang can prevent new readings from reaching the server.

A watchdog can help recover from certain software failures. Brown-out protection can help the device respond appropriately when battery voltage falls below the required level.

The firmware should also record reset reasons and avoid repeatedly rebooting without identifying persistent faults.

Application 3: Industrial Motor Controllers

An industrial motor controller may use a microcontroller to read encoder signals, process commands, and control motor operation.

Motor startup and sudden load changes can affect the power supply. Proper power design and voltage monitoring can help handle these conditions.

A watchdog may also detect software failures that stop expected control tasks from making progress.

However, a reset is not automatically a safe response for every motor-control fault. The system must place outputs in an appropriate safe state and use additional protection mechanisms where required.

Application 4: Battery-Powered Consumer Devices

Portable electronic devices may operate from batteries whose voltage decreases over time.

A brown-out mechanism helps prevent unreliable execution when the supply becomes too low. The firmware may also monitor the battery and shut down gracefully before a reset becomes necessary.

A watchdog can provide an additional recovery mechanism if the application becomes unresponsive.

These examples show why power supervision and software supervision should be considered separately during embedded system design.

10. Common Mistakes When Using Watchdog and Brown-Out Reset

11. Best Practices for Designing Reliable Microcontroller Systems

A reliable embedded system needs a combination of software and hardware protection.

Follow these practices when designing your application:

• Configure the watchdog correctly. Select a timeout that meets the application’s recovery requirements.
• Supervise critical tasks. Make sure watchdog servicing reflects actual application progress.
• Monitor the power supply. Select suitable brown-out settings where supported and appropriate.
• Design the power circuit carefully. Check the regulator, decoupling, wiring, load current, and battery characteristics.
• Capture reset causes. Record reset flags early to help diagnose unexpected restarts.
• Test failure scenarios. Investigate software hangs, communication failures, startup behavior, and realistic supply disturbances.
• Plan safe recovery. Ensure that restarting the processor does not automatically produce an unsafe output or state.
• Check device-specific documentation. Verify clock sources, thresholds, register behavior, and watchdog configuration.
• Investigate repeated resets. A watchdog or brown-out reset is an indication that an event occurred, not proof that the root cause has been resolved.
• Use layered protection. Depending on the application, combine watchdog supervision, voltage monitoring, error detection, safe-state handling, and independent hardware protection.

These practices are useful for students progressing from basic microcontroller programming to professional embedded firmware development.

Conclusion

Understanding their differences helps embedded systems students configure microcontrollers correctly, investigate unexpected resets, calculate watchdog timeouts, and design applications that recover more safely from faults.

For practical experience, students can configure an STM32 watchdog, introduce a controlled software hang, inspect reset-cause flags, and study how supply-voltage monitoring works. These exercises build useful skills in Embedded C, debugging, firmware development, and hardware-software integration.

At the Indian Institute of Embedded Systems (IIES), students can strengthen their embedded systems knowledge through practical training, microcontroller programming, debugging exercises, and project-based learning.