Repository navigation
fix: flash current ESP32-C5s (rev v1.2) by vendoring esp-web-tools on esptool-js 0.7.0 - #14
Merged
Merged
Conversation
…C5s flash The flasher failed on every ESP32-C5 revision v1.2 with "Failed to initialize", before reaching any of our code (issue #13). esp-web-tools 10.4.0, the newest release and what unpkg served for @10, bundles esptool-js 0.6, whose C5 chip magic list lacks 0x30e1706f. Rev v1.2 is what every current C5 devkit ships as. Upstream fixed it in esptool-js 0.7.0 (espressif/esptool-js#262), but no esp-web-tools release carries that yet. So the page now loads a copy of esp-web-tools 10.4.0 rebuilt against esptool-js 0.7.0, served from this site. The esptool-js pin is the only change from upstream; rebuild.sh reproduces it and refuses a build without the fix. 0.7.0 also identifies chips by GET_SECURITY_INFO chip id (C5 = 23), so the next silicon revision should not need another magic value. It also stops an upstream release from changing the flasher under us, which is the same class of silent drift behind issue #10. test_manifest.py now fails if the page goes back to a CDN copy or the bundle loses the C5 v1.2 magic. flasher.yml ships web/vendor and redeploys when it changes.
Closed
Yverr0y
pushed a commit
to Yverr0y/simulacra
that referenced
this pull request
Oct 7, 2026
…ent fixes - Jump-to: the Architecture link pointed at #architecture--the-nodes; the heading's dash became a hyphen, so the anchor is #architecture---the-nodes. Add the "What it doesn't do" section, which had no link. - Recent updates claimed Wi-Fi probe shape is learned at runtime. It isn't: probe_frame.c ships a fixed table of five capture-derived archetypes. Only BLE AD structure is learned. Say what actually happened to each. - Recent updates and CHANGELOG had nothing on Em3ritus#12, Em3ritus#14 or Em3ritus#15 (the flasher key block, C5 rev v1.2 flashing, C6 enrollment), the fixes users hit. - Name the surveillance signatures (Flock, Axon) the detector carries. - Reflow the follower bullet from Em3ritus#16. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #13.
The bug. On an ESP32-C5 revision v1.2, which is what every current C5 devkit ships as, the flasher failed with "Failed to initialize" before reaching any of our code. The page loaded
esp-web-tools@10from unpkg, which resolves to 10.4.0, the newest release. That bundles esptool-js 0.6, whose C5 chip-magic list is[0x1101406f, 0x63e1406f, 0x5fd1406f]. Rev v1.2 answers0x30e1706f, so chip detection throws and esp-web-tools reports it as a generic init failure. Upstream: espressif/esptool-js#262, fixed in esptool-js 0.7.0 (2026-09-21). No esp-web-tools release includes that yet.The fix.
web/vendor/esp-web-tools/is esp-web-tools 10.4.0 rebuilt with esptool-js pinned to 0.7.0, served from our own site. The pin is the only change from upstream.rebuild.shreproduces the bundle and refuses to install a build without the fix.Compatibility, checked rather than assumed:
ESPLoader,TransportandHardReset. It type-checks clean against 0.7.0.detectFlashSize()can returnundefined) is never called by esp-web-tools.writeFlashdata that isn't aUint8Array. esp-web-tools already passesUint8Array, withflashSize: "keep".Also in 0.7.0: chips are identified via
GET_SECURITY_INFOchip id (C5 = 23, which is what the v1.2 unit in #262 reports), so the next silicon revision should not need another magic value. Flash-ID reads on C5/C6 are also fixed.Serving our own copy also means an upstream release can no longer change the flasher under us, which is the same kind of silent drift behind #10.
Guards.
test_manifest.pyfails if the page goes back to a CDN copy, if the bundle's LICENSE (Apache-2.0) is missing, or if the bundle loses the0x30e1706fmagic.flasher.ymlnow copiesweb/vendorinto the site and redeploys when it changes.Verified locally:
esp-web-install-buttonasinstall-supportedin headless Edge.0x30e1706fis in the bundle'sESP32C5ROMmagic list and in its detection switch.Not yet verified: a hardware flash through the new bundle. Regression flashes on our older C5, C6 and CYD are still to do. A rev v1.2 C5 needs the reporter or a new devkit; none of ours are that revision.