search

ExpressLRS / Docs

https://www.expresslrs.org/
GNU General Public License v3.0
46 stars 94 forks source link

document/configurator full chip erase methods as final troubleshooting step? #335

Open pitts-mo opened 2 years ago

pitts-mo commented 2 years ago

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.

pitts-mo commented 2 years ago

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 :-/.

HazardCreative commented 2 years ago

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.

maybenikhil commented 7 months ago

@deadbytefpv do you want to document this?