I am creating a project that uses an ESP8266 in a situation where I can never access it again (will be given to someone else) once completed. I am adding in OTA firmware upload methods (based on the HTTPWebUpdateServer examples) that will allow this user to upload firmware updates I can email to them.

In the event that I bodge some part of the firmware, where the device boots up but then gets stuck, can someone point me to a way where I can store and recall a previous or initial firmware image to load to fix the buggy one? (Aside from the implementation details, I have hardware pushbuttons that could be used to start this process, but if there's a foolproof automatic one that might be nicer)

My initial thought was to use SPIFFS, and upload the data to it at the same time as I send it to the Update class, but I'm not sure how to get the data back out. The bootloader does not speak SPIFFS, but I could pipe the data out of SPIFFS to the Update class to initiate an "OTA" flash from the onboard data (though I'm not sure how to do this in practice, so advice would be nice).

My device is a NodeMCU with 4M of flash, so space is not an issue here.

Of course, this does not actually help, since it would backup the image being uploaded, not the previous. Then I'm just stuck with two buggy images. How might I back up the executing flash from the SPI chip to SPIFFS instead? If that's not possible, how do I get versioning working so that it keeps the n-1th upgrade and not the most recent?

I also recently saw this page (https://www.esp32.com/viewtopic.php?t=3645) which mentions a "factory" partition. If that works how it sounds, how do I:

  1. create a custom partition layout?
  2. get the "original" firmware placed there?
  3. trigger a restore of the firmware from it?
  • 1
    where the device boots up but then gets stuck then it's stuck and can only be flashed using physical connection. Simple fix: test your firmware thoroughly before deploying - note: that link refers to an ESP32 so is irrelevant to ESP8266 – Jaromanda X Apr 21 at 0:11
  • Right. Oops. If there's a way to start a generic Update process from any data source, it's possible though. My program has a lot of steps in the bootup sequence, so if anything gets past my testing (thus it's likely to be an issue with a later section, or conditional), I can probably halt that sequence by making sure the update check runs first. I agree it's not foolproof, but it would help. I found recently that there was such a bug that somehow got past me for several weeks, so I don't want it happening again when it's out of my hands. – RDragonrydr Apr 21 at 18:03
  • 1
    OK - esp8266.com/viewtopic.php?p=53130#p53130 apparently updates firmware from SPIFFS (apparently) - at least that's half the problem solved. I guess you could have a minimal fallback firmware in SPIFFS that can at least get you out of trouble - but how to trigger loading it. If, as you say, the new firmware "gets stuck", then nothing can help. If it triggers a watchdog reset, then as your code could determine if reset was caused by watchdog, say, 3 times in a row, and trigger flashing from SPIFFS if that happens – Jaromanda X Apr 22 at 2:36
  • @JaromandaX a button could also trigger "restore mode" instead of a counter, might be more reliable, depending on how it crashes... – dandavis Apr 22 at 17:16
  • Can never access it again. Yeah. A button :-) – Jaromanda X Apr 22 at 22:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.