the firmware update path (bootloader)

A washing machine, a thermostat, or a car already in customers' homes will eventually need a software fix or a new feature — but you cannot recall every device to the factory. So embedded products are built with a way to replace the program in flash AFTER the device is deployed. That mechanism is the firmware update path, and at its heart is a small, trusted program called the bootloader.

Here is the basic structure. The flash is split into (at least) two regions: a small BOOTLOADER that lives at the reset vector and runs first on every power-up, and the larger APPLICATION that holds your actual product code. When the device powers on, the bootloader runs first and decides: is there a valid application to jump to, or is someone asking to install a new one? In normal operation it verifies the application (often by checking a stored checksum or, better, a cryptographic signature) and then jumps to it. In update mode — entered by a button held at boot, a special command, or a flag in memory — the bootloader instead RECEIVES a new firmware image over some channel (USB DFU, a serial port, or wirelessly for an over-the-air, OTA, update), writes it into the application region of flash, verifies it, and reboots into it. Because the application cannot easily rewrite the very flash it is running from, the bootloader (running independently) is what performs the actual flash erase-and-program. The bootloader is normally NOT updated in the field (it is the part you must always trust), so it is kept tiny and rock-solid.

It matters because nearly every modern connected device relies on field updates to fix security holes and bugs over a product's lifetime — a device with no update path is frozen forever with whatever bugs it shipped with. The honest, safety-critical cautions: an interrupted update (power lost mid-write) can leave a device 'bricked' with a half-written, unbootable application, so robust designs use either a fail-safe bootloader that can always re-enter update mode, or A/B dual-bank flash where the new image is written to a spare bank and you only switch over after it verifies, allowing rollback. You should VERIFY images before running them — ideally with a cryptographic signature, because an unverified update path is a wide-open door for an attacker to install malicious firmware. And the update must survive a reset at any instant; designing for 'what if the power dies right HERE' at every step is the core discipline.