unbricking: document the full chip erase - #558
Draft
MUSTARDTIGERFPV wants to merge 1 commit into
Draft
Conversation
Closes ExpressLRS#335. There is no coverage of a full chip erase anywhere on the site. The only mention of esptool is in the toolchain setup page, and searching for "erase" returns nothing relevant, so a user whose device still misbehaves after a clean reflash has no documented next step. The Unbricking page is the right home, since it is already the central recovery guide and already explains that the factory bootloader cannot be damaged. Details are taken from the Configurator and the flashing tooling: - The option is labelled "Erase before flash" and sits under Flashing Options. - eraseSupported allows it for UART, for EdgeTX Passthrough, and for Betaflight Passthrough only when the platform is esp8285. It is never offered for WiFi. - In the firmware tooling, --erase adds --erase-all to the esptool write_flash call for the same set of methods. The warning is the important part. An erase discards the binding phrase, the model and output settings, and a customised Hardware Layout, so the text tells the user to export from the Import/Export tab first while the device still starts.
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
1 participant
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.
Closes #335.
A full chip erase is not documented anywhere on the site. The only
esptoolmention is in the toolchain setup page, and there is no "erase" content at all, so a user whose device still misbehaves after a clean reflash has no documented next step.The Unbricking page is the natural home. It is already the central recovery guide, and it already explains that the factory bootloader cannot be damaged, which is exactly the reassurance needed before telling somebody to wipe their flash.
Verified against the Configurator and the flashing tooling
Erase before flash, underFlashing Optionsmessages.json,"EraseBeforeFlash": "Erase before flash", rendered in theFlashingOptionslisteraseSupportedinConfiguratorView/index.tsxflashingMethod === BetaflightPassthrough && device.platform === 'esp8285'eraseSupportedreturns false for everything else--eraseinbinary_configurator.pyappends--erase-allto the esptoolwrite_flashcall inbinary_flash.py, for the ESP8266 UART, ESP8266 Betaflight passthrough, ESP32 UART and ESP32 EdgeTX passthrough pathsThe warning
This is the part that matters. An erase discards the binding phrase, the model and output configuration, and any customised Hardware Layout, and none of it can be recovered. The text tells the user to export from the Import/Export tab first, while the device still starts far enough to reach the Web UI.
There is also a note that a chip erase cannot brick the device, since the factory bootloader is not in the erasable flash. That is consistent with what the top of the same page already says, and it is the reason this is safe to recommend as a last resort.
Scope note
I deliberately did not consolidate the Repartitioner boilerplate in this PR. That text is duplicated across roughly 30 device pages and deduplicating it is a large refactor with its own review burden, separate from the missing chip erase content that #335 actually asks for.