STM32 OTA Firmware Update

STM32 microcontrollers offer multiple firmware update mechanisms. The most common are these two:

1. Built-in STM32 System Bootloader
2. In-Application Programming

Built-in STM32 System Bootloader

STM32 chips have a built-in bootloader stored in ROM. On reset, the chip checks the BOOT0 pin. If BOOT0 is low, it runs your app from flash. If BOOT0 is high, it jumps into the ROM bootloader instead.

In bootloader mode, the chip waits for commands over interfaces like UART or USB. An external tool can send erase and write commands to program new firmware into flash. When you reset the chip again with BOOT0 low, it runs the new firmware.

The UART protocol used by the STM32 ROM bootloader is documented in AN3155. There are many software tools that implement AN3155 and therefore can be used to burn firmware over UART, USB, or I²C/SPI. The ones worth mentioning are:

• STM32CubeProgrammer - an official tool from STMicroelectronics, and
• stm32flash - a popular command-line tool for Linux/macOS/Windows.

This diagram illustrates the process of burning firmware over UART:

The STM32 ROM bootloader is a simple and reliable mechanism, mainly used for factory flashing and recovery. It's not meant to run inside your firmware or be used for OTA updates

In-Application Programming

With IAP, your device updates itself while it's running.

How it's usually set up:

• A small custom bootloader at the start of flash, and a firmware resides in a separate flash area, OR
• A bootloader is embedded in the firmware itself

How updates work:

1. The device downloads new firmware (UART, USB, Ethernet, etc.)
2. The firmware is stored temporarily (RAM, internal flash, or external flash)
3. The bootloader erases the old app and writes the new one
4. The device resets and runs the new firmware

This is a very flexible mechanism that can be used for OTA updates. The biggest concern is that it can brick the device if power is lost during the update process.

The variation of this mechanism is called Dual-Bank updates. Some STM32 chips have two flash banks, so you can keep two firmwares, which can be mapped to flash memory area in direct or reverse order.

Therefore, one bank runs the current firmware. The other bank stores the update The bootloader switches banks after checking the new firmware. It makes updates much safer, quicker, and easy to rollback:

If the firmware is too big to fit two copies in the internal flash, then the new firmware can be stored in external flash and copied to internal flash during the update process. Then the bootloader copies the new firmware from the external flash to the internal flash, and reboots into it.

One of the simplest approaches is to put the bootloader inside the firmware itself. This means you don't need a separate bootloader image. Updates work by overwriting the existing firmware in flash, which is handy on small devices or when there's no external flash.

A common and easy way to do this is to split the flash into two equal parts:

• The first part runs the current firmware
• The second part stores the new firmware

On reboot, the bootloader code checks the second slot. If it finds a valid and newer firmware, it copies it over the first slot and restarts. The device then boots into the updated firmware - and the bootloader gets updated too.

STM32 internal flash

STM32 microcontrollers use internal flash memory to store your firmware. This is non-volatile memory, so it keeps your code even when power is off. Sounds simple - but flash has a few rules that really matter when you start doing firmware updates or OTA.

On some STM32 families (for example STM32F4, STM32F7), flash is split into sectors of different sizes - small sectors at the beginning, much larger sectors later. Other families like STM32H5, use uniform pages, which are easier to work with.

Flash has one big rule: you can't overwrite it. You must erase a whole sector first, then write new data. Erase happens per sector, while writing is done in small chunks (usually words).

This makes OTA updates harder - you can't erase the firmware that's currently running, flash layout needs careful planning, and losing power during erase or write can brick the device.

STM32 flash operations can be done using software libraries, like ST's HAL or drivers, or by talking to the flash controller registers directly, without using HAL or drivers. This gives you full control over erase and write operations, but it's easy to make mistakes. You must unlock the flash, set the right control bits, start the erase or write, wait for it to finish, check for errors, and lock the flash again.

Direct register access is fast and flexible, but it's best used when you really know the hardware - a small mistake can corrupt flash or brick the device.

Secure Boot

Secure boot makes sure an STM32 device runs only trusted firmware. Before anything starts, the chip checks the firmware and refuses to run it if it hasn’t been approved. This prevents modified, corrupted, or malicious code from ever executing.

At a high level, secure boot works by running a small, trusted bootloader first. This bootloader verifies the firmware using a cryptographic check, such as a hash or a digital signature. If the check passes, the firmware is allowed to run. If it fails, the device stays in bootloader or recovery mode instead.

What gets checked is both integrity and authenticity. Integrity ensures the firmware hasn’t been damaged or altered, while authenticity ensures it actually came from you. In practice, this is usually done with SHA-256 hashes and RSA or ECC signatures.

STM32 microcontrollers include hardware features that help with secure boot, such as read-out protection, secure key storage, and hardware crypto accelerators on many series. ST also provides a ready-made Secure Boot and Secure Firmware Update framework that handles much of the heavy lifting.

Secure boot becomes especially important when firmware updates are involved. Every update must be signed, and the bootloader verifies it before allowing the device to switch to the new firmware. Even if the update is delivered over an untrusted network, only valid firmware will ever run.

The main idea is simple: trust the bootloader, protect the keys, and never execute unverified code. Once secure boot is in place, everything else - including OTA updates - becomes much safer.