A watchdog exists to recover a device from a firmware hang: a timer runs independently, and if the firmware does not reset it in time, the part restarts. Normally the firmware decides whether to enable it.

One fuse removes that decision. With it programmed, the watchdog is on from reset and cannot be turned off in software. That is a sensible choice for a product that must never hang, and an awkward one for anyone trying to work with the device on a bench.

What it changes at the socket

The part resets itself at a fixed interval, which begins at power-on and cannot be disabled. Every operation the programmer performs has to complete inside that window, or be resilient to being interrupted by a reset.

Two observable consequences:

A read that takes longer than the timeout never completes. The interface returns an error, or returns data that stops partway. Retrying produces the same result, because the timeout is deterministic.

Entering programming mode can fail outright. Some programmers assume the device stays in reset while they take control; a watchdog that fires during that interval restarts the core and drops the connection.

Both look like hardware faults and both are configuration facts.

The window and how to work inside it

Three strategies, in order of preference:

Read in short passes. Break the array read into page groups that complete inside the timeout. Each pass restarts from a known address, so an interruption costs one pass rather than the whole read.

Hold the part in reset externally. If the programming adapter can keep the reset line asserted except during the transfer, the watchdog does not get a chance to fire. This is the cleanest solution and depends on the adapter.

Use the mode that disables the watchdog on entry. Programming mode usually disables it, which is why the failure is intermittent rather than constant — some entry sequences succeed and then the timer restarts.

The third point explains a confusing symptom: a device that works on one programmer and fails on another, with the same fuse setting. The difference is how each tool enters programming mode and whether it does so before the watchdog has had time to fire.

Why the fuse is set

Three reasons, all legitimate:

A product that must never hang — an appliance controller, a safety interlock — enables it deliberately and documents it.

A product that hangs in the field and had the fuse set as a field fix, without a firmware change.

A production line that enables it by default because the template did.

The third is the most common and the least considered, and it produces devices whose behaviour surprises the people who built them.

Reading the fuse byte answers it first

Before any attempt to explain an unstable read, read the fuse byte. The watchdog fuse is one bit, and it is either set or not.

If it is set, the instability has an explanation and the fix is procedural. If it is not set, the instability is electrical or a contact problem, and that is a different investigation with different tools.

This is the same principle that applies to every fuse on the part: the byte describes the configuration, and the configuration explains the behaviour. Reading it first avoids diagnosing a device as faulty when it is doing exactly what it was told.

What the P suffix contributes

The picoPower die lowers current consumption across the board, including in the watchdog oscillator, which on this family runs independently so the watchdog can operate in the deepest sleep modes.

That matters for a battery product and it does not change the mechanism: the fuse still decides whether the watchdog is unconditional, and the timer still runs whether the core is awake or not. A deeply sleeping device with an unconditional watchdog wakes periodically, resets, and sleeps again — visible on a supply current measurement as a periodic blip.

Related notes

• ATmega261 and differential reading — comparing builds of the same product.
• ATmega261A and small images — reading a two-kilobyte program.
• ATmega8A and fuse dependence — the same byte, a different set of bits.

FAQ

Can the watchdog fuse be cleared in software? No. It is a fuse, and the point of the setting is that firmware cannot override it.

Does the watchdog run in sleep mode? Yes. That is what makes it useful for recovering a sleeping device.

Why does one programmer work and another fail? Because entry sequences differ, and the window is short.

Does a watchdog reset erase anything? No. It restarts the core; memory is untouched.

Conclusion

An unconditional watchdog is a configuration, not a fault, and it produces symptoms that look like both. Reading the fuse byte before diagnosing turns a mysterious intermittent failure into a procedural constraint — and explains why the same device can behave differently on two programmers that do the same job.

Comments are closed.