Microcontroller Clock, Reset, Power & Watchdog

Clock, reset, power monitoring, sleep, and watchdog logic form one lifecycle system: they decide when state may advance, which state survives, how startup becomes valid, and whether a stalled program can recover into a known condition.

A microcontroller does not begin executing merely because voltage is nonzero. The supply must cross valid thresholds, the selected clock must start and stabilize, reset must remain asserted long enough, configuration must select a legal path, and the core must reach an instruction-fetch state. The same system also governs sleep, brown-out behavior, watchdog recovery, and clock failure.

Supply validPOR / brown-out Clock readysource / divider / lock Reset releasableexternal + internal sources Startup gate all required conditions true configuration selects legal path Execute fetch · initialize · serve record reset cause Watchdog: progress failed request controlled reset transition
Execution becomes valid only after power, clock, reset, and configuration conditions agree; the watchdog returns the system to the reset path rather than repairing arbitrary state.

Four distinct mechanisms #

  • Power-on reset holds or initializes the device while supply rises.
  • Brown-out detection asserts reset or another response when supply falls through a configured threshold.
  • External and internal reset sources force defined architectural state for pins, core, and selected peripherals.
  • Watchdog detects failure to demonstrate progress within a clocked interval.

They solve different failures. A watchdog does not prove supply integrity. Brown-out detection does not prove firmware progress. Reset does not necessarily erase RAM, EEPROM, peripheral flags, or the recorded reset cause.

Clock trees create domains #

A clock source may be an internal oscillator, external crystal/resonator, external clock input, low-frequency oscillator, PLL, or derived peripheral clock. Prescalers and gates create domains with different rates and sleep behavior.

For any peripheral, trace:

  1. selected source and nominal range;
  2. startup/lock requirement;
  3. system prescaler or clock divider;
  4. peripheral gate and local prescaler;
  5. whether the clock continues in the chosen sleep mode;
  6. whether switching is synchronized or requires a protected sequence.

f_CPU in build configuration is not measurement. If firmware assumes a rate different from silicon, baud rates, timer periods, delay loops, ADC clocks, and watchdog service all drift together.

Reset is selective initialization #

The reset chapter must be read as a table of domains, not a sentence saying “registers return to defaults.” Determine:

  • which reset source occurred and how its flag is cleared;
  • which registers and memories reset;
  • which pins become inputs, high impedance, pulled, or driven;
  • whether a peripheral continues during reset;
  • how long reset remains active after the source disappears;
  • where execution begins and what startup code changes before main.

Persistent reset-cause flags are diagnostic evidence. Clear them only after recording them somewhere the next failure cannot immediately destroy.

Brown-out is about invalid execution, not just data loss #

Below the guaranteed operating region, a CPU may fetch or write incorrectly before it simply stops. Brown-out detection keeps the system from executing across that uncertain region. The configured threshold must be compatible with frequency, flash write limits, external devices, and regulator behavior.

Hysteresis prevents rapid reset chatter near the threshold, but a slow or noisy rail still needs power-integrity analysis. A reset waveform can be a symptom of supply collapse caused by output current, radio transmission, motor startup, or flash programming.

Watchdog is a progress contract #

The safe question is not “does the loop run often enough to pet the dog?” It is “what evidence proves the whole required service chain completed?” A watchdog refresh placed in a timer ISR can keep running after the main state machine deadlocks. A refresh placed after validated acquisition, control, communication, and output stages demonstrates more useful progress.

A sound watchdog design specifies:

  • independent or shared clock source and tolerance;
  • minimum and maximum service window, if windowed;
  • state that must be made safe before reset;
  • whether reset is the response or an interrupt precedes it;
  • retained reset cause and crash evidence;
  • boot-loop policy when the same fault repeats.

Sleep and wake are clock transitions #

Sleep modes selectively stop the core, buses, oscillators, or peripherals. A wake source must remain clocked or asynchronously detectable. Wake latency includes synchronization, oscillator startup, PLL lock, regulator settling, and interrupt entry.

Before sleep, firmware should establish who owns each output and pending transaction. After wake, it should verify clock and peripheral readiness before assuming continuity. A timer based on a stopped clock did not measure the sleep interval.

Diagnostic sequence #

Symptom Evidence boundary
No instruction fetch supply rails, reset pin/cause, oscillator waveform, fuse/config source
Runs at wrong speed clock source, divider registers, calibration, build-time frequency assumption
Random resets under load reset-cause flags, rail droop, brown-out threshold, watchdog path, EMI
Cannot wake wake-source clock, mask/flag state, sleep mode, oscillator startup latency
Repeated watchdog reset last-progress marker, stack/state integrity, reset-cause persistence, boot-loop path

Treat clock, reset, power, and watchdog as a single state-transition graph. Debugging one register in isolation usually misses the condition that prevented the transition.

Sources

  1. docsATmega8A Data Sheetpdfnotes
  2. docsATmega128A Data Sheetpdfnotes
  3. docsEFM8BB51 Reference Manualpdfnotes

Searches titles, aliases, headings, summaries, and full text.↑↓ move ↵ open esc close