From c78bf2841a7ed666a62a176b2825f80d589f58c7 Mon Sep 17 00:00:00 2001 From: BlackMark Date: Thu, 23 Jul 2026 02:01:33 +0200 Subject: [PATCH] docs: the watchdog-lockout and EEPROM-wrap gotchas A sticky WDRF diverts every reset past the activation window (deliberate, so an app can reboot instantly, at the cost of a possible lockout); an EEPROM address past E2END wraps onto low EEPROM (the host bounds it, not the loader). Co-Authored-By: Claude Opus 4.8 (1M context) --- pureboot/README.md | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/pureboot/README.md b/pureboot/README.md index a7a7c9a..9ab006d 100644 --- a/pureboot/README.md +++ b/pureboot/README.md @@ -98,8 +98,15 @@ speak to the build. This exact deployment runs the full protocol suite in CI Reset enters the loader (BOOTRST on the boot-sectioned megas, the patched reset vector elsewhere) — except a watchdog reset, which hands straight to the -application, since the application owns its watchdog and must clear WDRF -itself. +application with no activation window, since the application owns its watchdog. +This is deliberate: it lets an application reboot itself instantly rather than +sit through the window. The application must clear WDRF itself (libavr's +`watchdog::disable()` does). **Gotcha:** WDRF is sticky (cleared only by +software, not by a later reset), so an application that watchdog-resets and +never clears it diverts *every* subsequent reset — external ones included — +past the window too, and the loader becomes reachable only through an external +programmer until the flag is cleared. A serial recovery path therefore assumes +the application clears WDRF on its own reset path. The host then knocks `p` then `b`, each awaited byte under a fresh activation window; any other byte is discarded and awaited again, so line noise can delay @@ -123,6 +130,13 @@ On chips whose flash exceeds 64 KiB (the 1284s — info-block flag bit 1) the addresses (the 644s' 64 KiB is exactly the 16-bit byte space). EEPROM addresses and all counts are bytes. +The loader trusts the host to keep addresses in range: it does not bound them +against the info block. **Gotcha:** a `w` (or `r`) that runs past `E2END` wraps +— EEAR is only as wide as the array, so an address past the end truncates onto +low EEPROM and the write silently overwrites it. Keeping writes within the +advertised sizes is the host's job (the shipped tool does); the flash budget +is better spent on features than on re-checking a bound the host already holds. + | Cmd | Arguments | Reply | |---|---|---| | `b` | — | the 12-byte info block |