Dual-bank flash versus external SPI flash for zero-downtime updates on 256KB STM32

Answer

For a 256KB Arduino-compatible STM32, dual-bank gives true zero-downtime staging only if your application fits in one bank ~128KB and the part actually supports dual-bank. External SPI flash preserves the full 256KB for the application but adds BOM cost and a bootloader copy step.

Option-byte bank swap atomicity

Confirmed: bank selection is controlled by option bytes, typically nSWAP_BANK / BFB2. The write to option bytes is performed by the flash peripheral and is intended to be atomic at the hardware level on families that support dual-bank. A power loss during the option byte programming sequence generally leaves the device in the previous boot bank or in system memory boot, not in an undefined half-swapped state.

Likely explanation: exact atomicity guarantees and recovery behavior are family-specific. The Reference Manual for the specific STM32 series must be consulted for the option byte programming flow and power-loss behavior. Not all 256KB parts support dual-bank.

Arduino_STM32 DualBankFlash rollback

Confirmed: the Arduino_STM32 DualBankFlash library provides APIs to erase/write the inactive bank and to trigger a bank swap via option bytes. It does not provide a documented automatic failed-boot detection and revert mechanism without application code.

Likely explanation: rollback must be implemented in application logic. Common pattern is a commit flag in backup registers or RTC backup domain. New image boots, runs health checks, then clears a boot-attempt counter and sets a committed flag. On boot failure or watchdog reset, a minimal bootloader or early init code checks the counter and toggles the option byte back to the previous bank.

Protected bootloader size with CRC

Confirmed: a minimal protected bootloader that validates CRC and copies from external SPI to internal flash can fit in 4-16KB. With 256KB total, reserving 8-16KB leaves ~240KB for the application, more than the 128KB limit imposed by dual-banking.

Likely explanation: power loss during the SPI-to-internal copy can corrupt the active image. Safety requires a two-phase copy with a staging marker and final commit, plus CRC validation before activation.

Steps for this case

• Verify MCU dual-bank support in the datasheet and Reference Manual Option Bytes section.
• If dual-bank is supported and app < 128KB: configure linker to one bank, stage to inactive bank, swap via option bytes, implement commit flag + backup register boot counter for rollback.
• If app > 128KB or dual-bank unsupported: reserve 8-16KB at flash start for bootloader, keep application at higher address, stage image in external SPI, validate CRC in bootloader before copying.

Verification:

arm-none-eabi-size app.elf

Check linker script regions do not overlap bootloader and application.

Missing diagnostic detail needed to finalize recommendation: exact STM32 part number and current application binary size. Dual-bank support and bank size vary by family, which changes the recommendation.