2025-07-21 8:23 AM - edited 2025-07-21 8:24 AM
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.
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.).
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). |
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.
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!