Hi all.
I tried to develop OTA on ESP32 with a remote server and it works.
Is it possible to have an incremental OTA?
Is it possible to upgrade only a part of my firmware?
Thanks in advance.
Incremental OTA
-
RandomInternetGuy
- Posts: 52
- Joined: Fri Aug 11, 2023 4:56 am
Re: Incremental OTA
It can be done, but it's tricky. Of course, if the decode isn't quite right and the firmware image running isn't what you actually shipped, your customer's device is now a brick, and that's usually considered to be bad.
The problems you have to deal with include the compression that's commonly used, blocking off what's actually "different." You can disable compression, but that's often a net loss.
The other thing you have to be aware of is that the storage you're writing to is flash memory, which wants to deal in sectors and not bytes. If you change "ab" to "cd", you'll have to read the entire current sector, mask out those bytes, store the new values in, and write the new secotors. Oh, there happened to be a page boundary between those two bytes? Now you have to read two pages and do the same. Your update was actually an insertion, but there's code all over the place that contains relative links to the code after this? Now you have to be prepared to update and replace THOSE affected bytes.
At one level, this is all well understood, computer-science-y stuff that we (the industry) have known how to deal with for decades.
At another level, the cost of RMA'ing devices or dispatching field service to unbrick devices by re-flashing them when they're atop poles or inside submarines or something generally rewards doing the simplest, most deterministic thing possible, which isn't an incremental flash update.
It's not that the idea doesn't have merit. It's that it's Really Hard to get right...and really expensive if it's not.
The problems you have to deal with include the compression that's commonly used, blocking off what's actually "different." You can disable compression, but that's often a net loss.
The other thing you have to be aware of is that the storage you're writing to is flash memory, which wants to deal in sectors and not bytes. If you change "ab" to "cd", you'll have to read the entire current sector, mask out those bytes, store the new values in, and write the new secotors. Oh, there happened to be a page boundary between those two bytes? Now you have to read two pages and do the same. Your update was actually an insertion, but there's code all over the place that contains relative links to the code after this? Now you have to be prepared to update and replace THOSE affected bytes.
At one level, this is all well understood, computer-science-y stuff that we (the industry) have known how to deal with for decades.
At another level, the cost of RMA'ing devices or dispatching field service to unbrick devices by re-flashing them when they're atop poles or inside submarines or something generally rewards doing the simplest, most deterministic thing possible, which isn't an incremental flash update.
It's not that the idea doesn't have merit. It's that it's Really Hard to get right...and really expensive if it's not.
Re: Incremental OTA
Hi RandomInternetGuy,
thanks for your reply.
thanks for your reply.
-
ESP_Sprite
- Posts: 9668
- Joined: Thu Nov 26, 2015 4:08 am
Re: Incremental OTA
Hi ESP_Sprite,
thanks a lot!
thanks a lot!
Who is online
Users browsing this forum: Baidu [Spider] and 68 guests