Unable to erase AE29F2008 #62

Activity

1. henols commented on Sep 12, 2026

   

   henols

   on Sep 12, 2026

   Owner

   More actions

   Hi @dim20 — you're right, on both halves at once. The AE29F2008 classification as algorithm 5 is correct, and you're also correct that this silicon can be chip-erased. Those two things aren't in tension: the 0x05 firmware path simply doesn't implement the chip-erase this part's silicon actually supports, so both statements are true simultaneously.

   Your --force erase was real, not a no-op. Running erase under the SST39SF020 identity dispatched into a real hardware erase-execute path for a full-chip erase — the same class of operation any chip-erase performs, not a silently faked success.

   It used the exact software chip-erase sequence the W29C020C datasheet documents for this silicon — a six-cycle unlock-and-erase command sequence, cycle for cycle identical to that datasheet's own "Command Codes for Software Chip Erase" table. The datasheet's own internal erase time (50 ms), plus the serial round-trips involved in issuing it, is consistent with the 0.14 s you measured.

   It was safe on your board only because AE29F2008 and SST39SF020 happen to share a pinout and a voltage class, and because that particular erase path never energizes a programming-voltage rail. That's a property of this specific chip pair, not a property of --force in general. Forcing a different identity onto a different real part could route a mismatched bus configuration, or energize a rail that part doesn't expect — so this isn't a safe general-purpose workaround for a missing capability, even though it happened to be harmless here.

   What changed: the refusal you hit now names the specific part instead of printing a bare Not supported message — in the released version 3.0.0b39 (pip install --pre -U firestarter). It doesn't unlock the erase itself.

   What you actually want — a software chip-erase for the 0x05 family — is real, undelivered work. The datasheet documents the command sequence your --force run happened to trigger, so it is buildable, and it's tracked as backlog item 999.63. It is not scheduled, and I'm not going to promise a version for it. One caveat any implementation of it will have to handle: the same datasheet documents that "once the boot block programming lockout feature is activated, the chip erase function will be disabled" — so a correct 0x05 chip-erase needs to account for the part's boot blocks, not merely replay the six-cycle command.

   Related, and worth knowing about: #68 — partial or unaligned writes on protocol 0x05 parts (including AE29F2008) silently erase the rest of the touched page and still report success. That's a separate, already-filed defect on the same protocol family; it does not cover the page-size issue tracked separately in #67.

   Also worth noting from your own earlier report (#61): read, write and blank-check all pass on your AE29F2008 — only the standalone erase command is refused, and that refusal is correct given what's actually implemented today.

   The full evidence trace — the exact command sequence, the datasheet cross-reference, and why the benignity here doesn't generalize — is here: https://github.com/henols/firestarter_prom/blob/ebd80b53b06b49678e41f12d31136f5b9d3edd26/.planning/notes/ae29f2008-classification-verdict.md#why-the-reporters---force-erase-worked-and-why-that-is-not-a-licence

   Keeping this open. The refusal is correct, but the capability you actually want isn't built yet, so closing this would file "we refuse, correctly" as the end of the story. I'm adding the cause:firmware label to reflect that this is a real, tracked capability gap rather than a bug in the refusal.

   One more thing, since you filed several reports the same day: #65 and #66 are still open, each with a maintainer datasheet cross-check on them as of 2026-09-10. No timeline to promise there either, but they haven't been dropped.
2. henols

   added

   cause:firmwareDefect in the Arduino firmwareDefect in the Arduino firmware

   on Sep 12, 2026