Bootloader Size Calculator

This tool calculates the exact flash memory layout for STM32 microcontrollers implementing Over-The-Air (OTA) firmware updates. It determines bootloader start address, vector table offset, application partition boundaries, scratch area alignment, and verifies whether all segments fit within the specified flash size while respecting sector erase boundaries.

A properly sized bootloader ensures safe firmware swapping without overwriting itself or corrupting the vector table. Too small a bootloader may lack essential features (e.g., crypto verification, DFU support); too large wastes flash and reduces available app space. This tool helps balance security, functionality, and memory efficiency.

“Flash Start” is the base address (in KB) where bootable code begins — typically 0x08000000 = 0 KB. “Bootloader Size” is the flash footprint reserved exclusively for bootloader code and configuration. “Scratch Area” is a temporary buffer used during OTA updates to stage new firmware before atomic swap — must be aligned to flash sector boundaries.

STM32 flash is erased in sectors, so bootloader, app, and scratch regions must align to sector boundaries (e.g., 16 KB). Misalignment can cause failed writes or erase operations. The calculator validates alignment and warns if any segment straddles a sector boundary or overlaps another region.

Minimal bare-metal bootloaders start at ~8–16 KB; production-grade secure bootloaders with TLS, signature verification, and dual-bank support range from 32–64 KB. Values like 32 KB (as default) accommodate robust features while preserving >80% of flash for application code on mid-size MCUs (e.g., STM32F4/F7/G0/G4 series).

While optimized for STM32 flash architecture (sector-based erase, vector table relocation, NVIC constraints), the core principles apply to other ARM Cortex-M MCUs. However, users must manually adjust for vendor-specific requirements — e.g., NXP Kinetis uses different reset vector placement, and ESP32 uses partition tables instead of fixed offsets.

Total flash size validates whether the configured bootloader + app + scratch area fits physically. Sector size ensures proper alignment: the bootloader must end on a sector boundary, and the app must begin at the next aligned address — critical for reliable firmware update and recovery operations.

The calculator highlights overflow with visual warnings (e.g., red borders or error text) and identifies which segment(s) exceed limits. Common fixes include reducing app or scratch size, increasing sector-aligned bootloader padding, or selecting a larger MCU variant — always verify against your device’s reference manual.

It computes the offset as Bootloader Size × 1024 bytes from Flash Start, then ensures it’s aligned to a 512-byte boundary (required by ARM Cortex-M for VTOR register). If misaligned, it suggests adjusting bootloader size upward to the next valid sector-aligned boundary.

Yes — scratch area should be ≥ the largest firmware image block transferred per OTA packet (often 1–4 KB), but practically ≥16 KB ensures compatibility with encrypted payloads and metadata overhead. For dual-bank OTA, scratch may be omitted entirely — this tool supports both single- and dual-bank configurations via input tuning.

The output provides precise memory region addresses (e.g., FLASH_BOOT (rx) : ORIGIN = 0x08000000, LENGTH = 32K) usable directly in STM32CubeIDE or GNU ld scripts. Correct alignment and non-overlapping regions prevent link-time errors and runtime crashes due to vector table corruption.

No — those settings reside outside main flash and are configured separately via ST-Link or HAL. However, the calculator assumes standard flash mapping; enabling ROP or PCROP may restrict bootloader access to certain sectors, so always cross-check protected regions against your final memory map.