document/configurator full chip erase methods as final troubleshooting step?
pitts-mo opened this issue · 3 comments
I believe it may be helpful to document full chip erase methods or add full chip erase option to configurator as a final step prior to making the determination a hardware problem is likely cause of an ELRS failure.
Current Behavior
Example 1:
A friends new JHEMCU-ELRS-2G4-P was failing to enter wifi mode with RX LED repeating a quick triple flash, followed by a fourth flash, brief pause, then flash pattern repeats. (https://usa.banggood.com/JHEMCU-ELRS-2G4-P-2_4GHz-ExpressLRS-ELRS-5-PWM-Output-Long-Range-Mini-RC-Receiver-for-RC-Drone-p-1931268.html?cur_warehouse=CN&rmmds=search)
Example 2:
I have observed other odd issues booting and binding some of my other esp8285 based ELRS devices after I had flashed experimental builds of INAVRadar firmware. (https://github.com/OlivierC-FR/ESP32-INAV-Radar).
Steps to Reproduce
Unknown.
Please save a flash dump prior to erase attempt and add a comment if you have observed:
-a new JHEMCU-ELRS-2G4-P that fails to properly initiate wifi mode
-other instances where an ELRS device hit an unknown failure mode
Possible Solution (Not obligatory)
Suspect the flash contents may contain data incompatible with ELRS firmware?
-add full chip erase methods as final troubleshooting step.
-add full chip erase option to configurator?
-I do not think it is practical or necessary to identify flash problems and code firmware fail gracefully.
Details
So far I have only observed similar issues on ESP8285 based devices. In all my instances I have not had an actual hardware failure. A simple flash erase was able to bypass the odd behavior and allow ELRS firmware to function again.
my fix example:
./esptool -p /dev/ttyUSB0 erase_flash
esptool.py v3.3.1
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP8266
Chip is ESP8285H16
Features: WiFi, Embedded Flash
Crystal is 26MHz
MAC: XX:XX:XX:XX:XX:XX
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 2.3s
Hard resetting via RTS pin...
Your Environment
lubuntu 22.04
I currently believe this issue to be confined to bad/invalid data in device flash and unrelated to other details of environment.
Just add option to format flash for uart/passthrough flash of ESP8285 targets?
more info:
I kept hitting web gui failure message when attempting to perform WiFi update from 2.2.0 to 2.5.0 (then 2.5.0 to 2.5.0) on one of my two DIY_2400_TX_ESP32_SX1280_E28 but the same web update on my other module reported successful.
In troubleshooting I noticed DIY_2400_TX_ESP32_SX1280_E28_via_UART was performing an erase which did appear to resolve my WiFi update failures messages on future WiFi update attempts. However, in hind sight I forgot to save a dump :-/.
This would have helped me.
I had not one but two BetaFPV Lite RX v1.1 which would not function when flashed with the HDZero backpack FW. Flashing to RX5808 Backpack worked fine, but once the HDZero FW went back on it, the RX would not function at all. (LED quick blink about 1/s, no WiFi after timeout, not responding to commands.)
After looking for support, deadbyte suggested a full chip erase with esptool, so I did that. The next flash was to HDZero backpack, in the same way I had flashed before—and the Rx was fully functional.
@deadbytefpv do you want to document this?