Micro self updating firmware architecture question

[e100]

Do all reasonably modern micros have an architecture that enables them to autonomously download a new firmware image in the background, and then reboot to that new image?
Presumably the flash memory has to be partitioned in some special way that allows the new firmware to be saved without overwriting the current image just in case the download fails half way through.

Was there a particular point in time when this became possible, or has it always been possible?

[hamster_nz]

Using Flash for program storage makes this very easy to do using a bootloader. For example, you can verify the new image (stored in a different block of memory) then copy it to the location of the live code.

You also need data connectivity to download the new firmware, so Bluetooth, WiFi or cellular data is also needed unless you want wires and cables.

Hardware support to write protect  the pages where the bootloader lives is helpful to prevent brickimg the device.

[viperidae]

You'd need twice as much flash as a single images, but you can download a new image to the spare half. Perhaps you could have the bootloader pick the image with the latest version, and the watchdog timer could try the opposite one of it fails to boot. Generally there is ram that is preserved between wdt resets. You can store the version that was booted in there so the other can be tried.

That gives you download capability and failure recovery.

[krho]

You can also use an external qspi NOR memory.. they are really really cheap. e.g 1€/1000pcs for 16MiB

[MosherIV]

Do all reasonably modern micros have an architecture that enables them to autonomously download a new firmware image in the background, and then reboot to that new image?

Nope. Not that I am aware of.
As the others have said, there techniques that are used to do it.

Embedded microcontrollers are limited in resource: RAM, flash and processing power
They are ver low power (mW to microWatt).
With such limited resource, you have to do all the hard work to acheive seemless firmware upgrade.


The world of embedded is seperating into 2:
The small embedded microcontrollers (ARM Cortex M series)
Embedded Application processors (ARM Cortex A series and other similar processors) - often use Linux

The embedded application world has much more resource to acheive seemless upgrade.
Generally, they have some kind of HDD (solid state) so the application lives as a binary on the HDD which can just be over written and then started.

[westfw]

Sigh.
“An architecture that permits” - yes, I guess that’s pretty common.
“Download”, “Autonomously” and “in the background” ?   Not so much.


The “architecture” part is “self programming flash” - that is, software running on the microcontroller can write the flash memory in the same microcontroller.  Usually one “page” of flash at a time.
“Download” implies a communications protocol, “background” implies an operating system (or at least a runtime environment with the concept of  “background”, and “replace” implies that you need “storage” of some kind equal in size to your program, to hold the downloaded new code while the old code is still running.  Doing all that require software written by ... someone.  Not very “autonomous” at all...

[mac.6]

On BLE it's called OTA (Over The Air update). Pretty much common. Some 4G chipset also support that.
Some parts have hardware flash swapping, ie swapping two block of flash with just a config (ie boot from one, download update to other block, then when everything is checked, swap blocks and reboot).

[SiliconWizard]

Quite a few that embed an USB controller have an USB DFU bootloader as well.

[Jeroen3]

This is not specifically a feature of the hardware. Almost all chips can program their own flash. Sometimes not when they are running from it, but then they might run from RAM. If you have space to keep a copy of the image somewhere. Either some other part of flash, or external memory. Then you can tell the bootstrapper to copy the new program to flash. You have to make sure the bootstrapper doesn't brick the device. So either also keep the old image to return to, or offer a recovery method via serial for example.

So, to answer:

Do all reasonably modern micros have an architecture that enables them to autonomously download a new firmware image in the background, and then reboot to that new image?

Yes, if enough non-volatile memory is present.

An example of this is how Particle deals with this. There is a Flash chip on the board to store factory/normal/update firmware images.

Getting the right, untampered, firmware image to the device is the tricky part.

[David Hess]

You'd need twice as much flash as a single images, but you can download a new image to the spare half.

Exactly, some microcontrollers have provisions to support multiple images but more commonly, the update is stored in RAM before being burned to Flash.  If execution out of Flash is not possible while burning, then the microcontroller might execute out of RAM during the burn process.

Note that operating out of RAM is hardly unusual.  Faster microcontrollers routinely do this for performance reasons and during boot, the program is copied from Flash to RAM making the Flash available for burning anyway.

[westfw]

Also, you want to distinguish between "self updating" and "running a bootloader."
Arduino, for example, usually utilizes a bootloader, which is an "extra small" piece of program memory with the ability to update the larger "application" part of program memory.  With a bootloader, you only have to have "application_size + bootloader_size" worth of memory, instead of "2 * application_size", but it's not "background" or "autonomous" - to load the new version of the application, you have to stop the old version and explicitly run the bootloader somehow...  Usually the bootloader is protected an cannot replace itself (nor be replaced by the application.)

You can get ... complicated.Certain internet routers, back in the days before cheap flash, would normally copy (uncompress, actually) a complete ROM image into RAM, occupying ~70% of RAM.  But sometimes you'd want to download a newer image to run, using one of the many supported network interfaces.  So the main image would download an "incomplete" "secondary bootstrap" that only used 20% of RAM (by leaving out big features irrelevant to downloading, like non-IP prototocols), and then run the secondary bootstrap to download the image that you actually wanted to run.  Fun Times!

[Psi]

This might be useful