Posts Tagged ‘reverse engineering ic archive’
ATmega261PV: A Device That Is Asleep When You Connect
A battery product spends most of its life asleep. The firmware wakes on a timer or an edge, does something brief, and returns to the deepest mode the part supports. Current drops to microamps and the core stops.
That is correct behaviour and it makes bench work confusing, because a sleeping part does not execute, does not drive pins, and does not necessarily respond to anything you connect. Two measurement habits resolve the confusion, and one fuse setting explains it.
What sleep actually stops
The modes form a ladder. Each removes more of the chip:
| Mode | Core | Main oscillator | Peripherals | Typical wake source |
|---|---|---|---|---|
| Idle | stopped | running | running | any interrupt |
| Power-down | stopped | stopped | watchdog, some | external edge, watchdog |
| Power-save | stopped | stopped, timer kept | asynchronous timer | timer, external edge |
| Standby | stopped | running, fast start | most off | external edge |
The deeper the mode, the longer the wake and the fewer things that can cause it. On a firmware that measures once a minute, the part spends 99.9 percent of its time in the bottom rows.
Why this looks like a dead part
Three observations that mislead:
Supply current near zero. A part in deep sleep draws less than the leakage of a careless probe. A current measurement that reads “nothing” is consistent with both a sleeping part and a disconnected one.
No activity on any pin. Sleeping firmware leaves pins in whatever state it set before sleeping. If those states are static, a scope shows flat lines everywhere.
No response to the programmer. Entry into programming mode requires the core to respond. A part that is asleep may need the reset line asserted, and some adapters do not assert it long enough.
The distinguishing test is to measure the reset line while the programmer attempts entry, and to look for the periodic blip that a timer-driven wake produces. A device that wakes once a second is visible on a current trace even when it looks inert.
The fuse that governs the wake
The watchdog can be configured to run in the deepest sleep modes, and it is the usual wake source for a product that samples on an interval. If the watchdog is enabled unconditionally, the part will wake on its own schedule regardless of what the firmware wanted.
That is the same fuse discussed elsewhere, and here it has a second meaning: it is the mechanism that lets a deeply sleeping device do anything at all. A design that sleeps to microamps and wakes on a watchdog is a design with almost no external components, which is why the pattern is so common.
Reading the sleep structure out of the image
The power management code is compact and recognisable:
- Writes to the sleep mode selection field.
- A sleep instruction, usually inside a loop.
- The interrupt that wakes it, which must be enabled before the sleep.
- The work done after waking, which is usually short.
Finding that loop gives the product’s duty cycle: how long it sleeps, what wakes it, and how much it does per wake. On a battery product, that ratio is the design.
| Code feature | What it tells you |
|---|---|
| Sleep mode field value | How deep the part goes |
| Wake interrupt source | What the product reacts to |
| Work after wake | What it measures or transmits |
| Loop structure | Whether timing is timer-driven or event-driven |
What this means for access
A device that sleeps is not protected; it is idle. Access is a matter of holding the reset line long enough for entry, which is a procedural fix rather than a barrier.
Once in, everything proceeds normally: signature, fuses, lock byte, array. The only difference from a device that runs continuously is that the programmer may need to assert reset more firmly.
That distinction matters because “the device does not respond” and “the device is protected” are frequently confused, and the first is far more common on battery products.
Related notes
- ATmega261P and the unconditional watchdog — the fuse that makes wake possible.
- ATmega261 and differential reading — comparing two builds of a sleeping product.
- ATtiny25 and the sleep-dominant case — the same pattern in a smaller package.
FAQ
Does sleep affect the flash array? No. Sleep stops the core and clocks; memory is untouched.
Can a sleeping part be programmed? Yes, when the reset line is asserted properly. Programming mode does not need the application running.
Why does the current reading look like zero? Because the part is drawing microamps. A probe and a meter with adequate resolution will show the difference.
Does the watchdog wake the part in every sleep mode? In the modes where it is clocked, which is why it is the usual choice for interval wake.
Conclusion
Deep sleep is a design decision that produces a device which looks inert and is not. The current trace, the reset line, and the sleep loop in the image together describe the duty cycle — and on a battery product that duty cycle is the most important thing the firmware does.