ESP8266 Community Forum

- Sat Apr 04, 2015 1:36 pm #13485 I thought I would kick off some discussion on the different methods people are looking at for OTA flashing. The code I published uses a method similar to what xpressif use for their OTA updates (so I could leverage their API calls and bootloader). I am interested to hear other ideas about how we might be able to do this better.

The keys will be:
1. Survivability of bad flash
2. Ability to update program code seperate from website
3. Ideally ability to not have to reflash the webcode if updateing the app (mine currently requires it, though it is "automated")
4. User interface for doing flashing. (I currently use raw posts, but there was talk of having a proper multi-part form to POST the binaries)

- Sun Apr 05, 2015 3:51 am #13519 As I said before, I would suggest whipping up some kind of container format which embeds the various flash regions that can be flashed. For debugging, you could e.g. leave out the html bit and only reflash the main code; for firmware updates that go to an end user, you make sure to include both the code and html partition. Esphttpd can do fallbacks, that is, if the official flash page as defined by the programmer in the espfs isn't there, we can define a static html page that gets served instead; I think we should have a pretty good protection against half-flashes that way.

I've never looked at how the switching of regions thing Espressif uses in their OTA downloader works exactly, so I may be overlooking some things there. Worst case, we could make our own which chooses a valid flash bit based on a number that increments with every flash plus a CRC. Invalid CRC = invalid firmware = boot the older version.

- Sun Apr 05, 2015 2:47 pm #13592 Well, that's along the lines of what I did.

The way xpressif does their updates is by flashing the new userbin to a second, nearly identical, half of the flash. They then set a flag for the bootloader that upon reboot should attempt to boot from partition #2 (this is bootloader 1.1 and 1.2, btw). If successful, if changes the bit in the bootloader memory so subsequent boot will use that partition. If it fails, it boots from the original partition, since it is untouched during the flashing operation.

The method I am using polls the device for the active partition then flashes the other partition. When done, the device has to reboot (so we know the flash was successful). If it succeeds, the HTML is flashed over the original userapp in whichever partition it was in.

I intend on eventually offering a forms-based flashing method (much more user friendly). In fact, a good start to it is in my code just not currently exposed. The idea is just as you said, have a static page that will allow you to flash with nothing else, but that page could be overridden by the author to whatever they want (should remain some form of flashing form, though)

- Tue Apr 07, 2015 2:52 am #13723 How about just adding both images in the uploaded file, and letting the ESP decide which one to actually flash? Doing it that way would make it easy for end users to just whack an update file at it and make it go. Developers could always poll the device and generate a file with just one of the two images in it.

Ah, we'll also need something like an 'application identifier', so you can't flash a random device with a random image, I'd think.