ESP32 Survives Every Forced OTA Interruption, Even a Hard Power Cut
We broke an Over-The-Air update on the ESP32 on purpose
OTA updates are critical for connected products, but what happens when they're interrupted? We deliberately broke an ESP32-C6's over-the-air update in three ways—software reset, hardware reset, and pulling the power—and measured recovery. Across 18 trials, the device always rolled back to the old firmware and completed a fresh update, with recovery times ranging from 99.6 seconds after a power cut to 165.7 seconds after a software reset.
They interrupt before we reach the point where the bootloader would switch the boot pointer, so the device that reboots is still running the old firmware, with the same rollback mechanism ready to walk it through a fresh attempt.
- leoedin
What an empty article. Testing an OTA update can survive a power interruption during the downloading is such a basic test. It doesn't need an article that long. I guess AI wrote it from a few sentence prompt?
They didn't do any interesting tests. What about brownouts, voltage ripples, timing the reset signal to see if there's any critical moments in the update process, corrupted update files, high EMC environment etc etc. That would be interesting.
I think the article is an advert for a testing platform that enables automating this sort of test. But weirdly they don't show how their platform does the automating, so it just looks like they're really pleased with themselves for doing really basic engineering.
- rurban
You need just enough flash ram for 2 firmwares and a proper bootloader, which knows which partition is active/verified. Simple as that. Biggest problem is getting enough flash.
writing the bootloader is trivial.
- mikewarot
Personal anecdote: It was circa 1985 that I encountered a similar problem. I hand a hand held barcode scanner that had to upload the collected data via a proprietary serial protocol, for eventual reporting, to a PC.
The customer asked "what happens if I disconnect this right now?" during the upload. It was a corner case I hadn't considered. It only took a few days to make it bulletproof.
---
The authors don't seem to consider the case of very slow or intermittent Internet.
I'd be worried about corruption in the download, and check for that. I'd also make very sure the watchdog hardware was on and the code respected it.
It seems to me you need 3 buffers for the OTA code, not 2. There should be a way to keep the last version that runs for X seconds in addition to any new updates, where X is quite large, perhaps a whole day.