STM32 Flash Size Calculator

This tool calculates total flash memory consumption across key firmware sections—bootloader, application code (.text), read-only and initialized data (.rodata + .data), and EEPROM emulation—and compares it against the device’s total flash capacity. It then computes available space for future updates or additional features, factoring in a configurable safety margin. The result helps engineers verify flash budget compliance before deployment.

The safety margin accounts for unforeseen growth in firmware size due to compiler optimizations, library updates, debug symbols, or linker script changes. A typical value of 5–15% ensures headroom for minor version increments without risking flash overflow during field updates or certification testing.

Extract these from your compiled ELF or HEX file using standard ARM GCC tools: run arm-none-eabi-size -A your_app.elf to see section breakdowns. Alternatively, check the map file generated by your build system—look for .text, .rodata, and .data sections under the FLASH/RAM memory regions.

Minimal UART-based bootloaders range from 16–32 KB; USB or dual-bank OTA-capable bootloaders typically consume 48–96 KB. ST’s official STM32CubeProgrammer-compatible bootloaders (e.g., for STM32F4/F7/H7) often occupy 32–64 KB. Always confirm with your bootloader’s linker script or binary size output.

Yes—but exercise caution: STM32L0/L1 devices use different flash architectures (e.g., 2 KB sectors, write/erase constraints) and may allocate flash differently for EEPROM emulation or option bytes. Verify that your EEPROM emulation library (e.g., ST’s X-CUBE-EEPROM) aligns with the configured flash reservation.

The tool flags over-allocation with a visual warning (e.g., red highlight or “FLASH OVERFLOW” message). This signals that either firmware must be optimized (e.g., disable unused peripherals, enable link-time optimization), flash partitioning revised, or hardware upgraded to a larger-flash variant (e.g., moving from STM32F407VG to VGT).

EEPROM emulation reserves contiguous flash sectors for wear-leveling and data persistence. It consumes flash permanently—even when no data is stored—and reduces available space for code. Each emulated byte may require multiple flash writes over time, so sizing should reflect both storage needs and endurance requirements (typically ≥10K cycles).

No—this tool focuses exclusively on *flash* (program memory) allocation. RAM usage (for .bss, stack, heap) is separate and must be evaluated via arm-none-eabi-size or your IDE’s memory analysis tools. Overlapping flash and RAM misconfigurations can cause runtime crashes but are outside this calculator’s scope.

Yes—with adjustments: for dual-bank operation, treat each bank as half the total flash (e.g., 512 KB → two 256 KB banks), then input the *larger* of your active app + bootloader size per bank. Account for any shared metadata or swap area reserved by your OTA framework (e.g., MCUBoot uses ~1–2 KB extra).

.rodata (read-only data) resides entirely in flash and includes constants, string literals, and lookup tables. .data is initialized at startup: its *values* are stored in flash (as part of the image), then copied to RAM at reset—so it consumes flash space even though it executes from RAM. Both contribute to total flash footprint.