[FOTA with Update Space] — Is It a Good Idea for Safe Firmware Updates and Rollback?
Hello everyone,
I'm currently working on a FOTA (Firmware Over-The-Air) system for my STM32-based project, and I’d love to get your insights or validation from the community regarding the architecture I'm considering.
My Goal:
To ensure safe firmware updates and enable a rollback mechanism in case something goes wrong during or after the update (e.g., power failure, invalid firmware, etc.).
My Current Design:
I’ve divided the Flash memory into three main sections:
| Bootloader | Located at 0x08000000 — always runs first. Handles firmware updates and boot decision logic. |
| Update Space | A dedicated Flash section (e.g., at 0x08020000) where the new firmware is written and validated before execution. |
| Application | The main app firmware runs from here (e.g., 0x08080000). |
Update Workflow I'm Considering:
-
The new firmware is received via UART/Wi-Fi and written directly to the update space in Flash.
-
Once fully received, I compute the CRC on the update space content (not the RAM buffer).
-
If CRC passes, I:
-
Option A: Boot directly from the update space (simpler, but may have limitations).
-
Option B: Copy the firmware to the app section, then reboot from there.
-
-
The new firmware sets a "BOOT_OK" flag if it starts successfully.
-
If this flag is not seen on the next reboot (e.g., crash), the bootloader assumes the update failed and reverts to the existing firmware or waits for a new update.
My Question:
Do you think using an update space like this is a good design choice for FOTA with rollback?
-
Is it overkill for basic STM32 projects?
-
Are there simpler alternatives that still offer safety?
-
Should I instead consider writing directly to the application area after validating the firmware in RAM?
-
Any known drawbacks or caveats when booting directly from update space?
Thank you so much!