I have a project on and was thinking about failsafe options. Essentially in the event that I upload a new firmware to the ESP8266 nodemcu and update the system and for some reason the system crashes resulting in a dead node on the network I was wondering if it would be possible to add a backup Arduino with an eprom that held a stable/tested version of the firmware for the ESP.
The Arduino would wake up ever so often from a deep sleep and check that the ESP was running, if for some reason it had failed then it would upload the original firmware and restart the ESP.
The reason for this was that I have a number of nodes in the project that are going to be installed in some locations that will be impossible to get to.
I remember years ago running a commercial radio network and the radio's had an awesome feature that if a firmware failed they would reboot in a kind of failsafe mode with the last working settings. Admittedly it was rare for the firmware to fail but it did happen once in a while and I experienced this first hand. Having this feature saved me a 4 hour drive in the middle of the night.
I was wondering if it would be better to loop the USB ports for this or if there was another way to do this.
Any ideas?
Although i like your idea, i do not believe it is feasible.
Once the ESP.... is dead, is cannot be flashed unless you have physical access to it.
I have not seen a method to use a fail safe minimal program to keep the node reachable.
if the ESP.... is installed in a hard to get to location, at install time run an USB cable to a reachable location would be my suggestion. And that does not work on ESP32, as it required a button pushed to(re-) flash it.
But i am hoping someone has a better answer.....
Rob_Muller:
Although i like your idea, i do not believe it is feasible.
Once the ESP.... is dead, is cannot be flashed unless you have physical access to it.
I have not seen a method to use a fail safe minimal program to keep the node reachable.
if the ESP.... is installed in a hard to get to location, at install time run an USB cable to a reachable location would be my suggestion. And that does not work on ESP32, as it required a button pushed to(re-) flash it.
But i am hoping someone has a better answer.....
The ESP is located on a volcanic mountain on another continent 
the closest research base is about 30Km away.
I was thinking more along the lines of a corrupt firmware upload or a firmware that ends up putting the thing in to some weird loop. The backup arduino could be set up to fire a reset to the ESP.
Aaaah, i see, said the blind man...
I agree that would make it difficult to run a cable, i was more thinking of the device above the ceiling.
Again proof that to assume.....
having thought about that, it could be possible to setup a second device to monitor a heartbeat, and on absence of the heartbeat re flash the device.
that would require a device that can take input from the arduino, and output data to a USB port using a flasher program (esptool.py?). thinking raspberry pi here, but that has different power requirements, and if you are going to use that, why not start with it.
anyway, there's my $.02
regards,
Rob
I'd take into consideration the amount of flash EEPROM available vs the amount of flash memory available on an ESP. I believe I get, with the default configuration 1.3 something or another Mb of program storage space on an ESP32 using the default configuration and more program storage space by knocking out OTA and other ESP32 features.
Not sure how often the ESP32 is expected to lose its flashed program memory, might be a question for these guys: https://esp32.com/
Also, what happens if the Nano or Mini decides it's corrupt storage is the right program to load into the ESP?
It might work better with 3 ESP32's one to run the program, one in standby, and one to check the operational ESP32 (control unit) integrity. The control unit could be a ESP32 WROVER with extra ram to hold the working ESP's program to try to restore the offline ESP..
Idahowalker:
I'd take into consideration the amount of flash EEPROM available vs the amount of flash memory available on an ESP. I believe I get, with the default configuration 1.3 something or another Mb of program storage space on an ESP32 using the default configuration and more program storage space by knocking out OTA and other ESP32 features.
Adding more memory oe even a CF would solve the storage issues.
Idahowalker:
Not sure how often the ESP32 is expected to lose its flashed program memory, might be a question for these guys: https://esp32.com/
Also, what happens if the Nano or Mini decides it's corrupt storage is the right program to load into the ESP?
It might work better with 3 ESP32's one to run the program, one in standby, and one to check the operational ESP32 (control unit) integrity. The control unit could be a ESP32 WROVER with extra ram to hold the working ESP's program to try to restore the offline ESP..
This is more a backup for the system when its in the field. The first situation is if on an update the system looses power or or for some reason given the enviroment something strange happens suring an upgrade.
or if there is a bug in the firmware that is not seen until the firmware has been running for a while and for some reason the communication drops out to the node when it is running.
Yes the Nano or Mini could have the same issue however they will never be flashed. they are there only to make sure the main systems are running.