| Scenario | Total flash | Mode | Bootloader final | App slot | Scratch | Headroom |
|---|---|---|---|---|---|---|
| Mid-range MCU | 512 KB | Dual-slot (A/B) | ~54 KB | 192 KB | 16 KB | ~54 KB |
| Small footprint | 256 KB | Single-slot | ~32 KB | 200 KB | 0 KB | ~24 KB |
- Boot raw (KB) = sum of selected boot components + metadata + vector table.
- Boot with overhead = Boot raw × (1 + overhead%/100).
- Aligned boot (bytes) = align_up(boot_with_overhead_bytes, alignment_bytes).
- Boot final (bytes) = align_up(aligned_boot_bytes × (1 + margin%/100), alignment_bytes).
- App reserved (KB) = slot_kb (single-slot) or 2×slot_kb (A/B).
- Total required = boot_final + app_reserved + scratch + reserved_nvm + reserved_misc.
- Headroom = total_flash − total_required.
- Enter your device flash size and base address if known.
- Choose update mode and set a realistic planned app slot size.
- Fill bootloader feature sizes based on your build map.
- Set alignment to your erase page or required boundary.
- Apply overhead and growth margin to avoid future rework.
- Click Calculate, then export results to CSV or PDF.
Sizing Inputs That Matter
Boot space starts with total flash, erase page size, and the alignment boundary. Many MCUs use 2 KB or 4 KB erase pages, so a 22.6 KB boot image often becomes 24 KB or 28 KB after rounding. Include metadata and vector relocation: 1–3 KB for headers and hashes plus 0.5–2 KB for vector tables is common. If your base address is known, the map helps catch overlaps during integration.
Overhead, Alignment, and Real Flash Cost
The calculator applies an overhead factor to represent linker padding, section ordering, and toolchain differences. Teams often see 2–8% overhead between “map file size” and “reserved partition size.” After overhead, bytes are aligned upward to the boundary you choose; aligning to the erase page reduces partial-page waste and simplifies wear leveling. A growth margin, typically 10–25%, protects against crypto updates, extra transports, or debugging hooks.
Single-Slot vs A/B Update Trade-offs
Single-slot layouts reserve one application slot, so the maximum slot is roughly flash minus boot, scratch, and other reserved areas. A/B mode reserves two equal slots, which halves the maximum per-slot size but enables safer rollback. As a rule of thumb, if your image is above 70% of the planned slot, A/B may require a larger flash part or code-size reductions such as LTO and removing unused drivers.
Risk Controls and Validation Checks
Use image utilization to spot tight fits: keep sustained utilization under 85% so emergency patches still build. Treat scratch as a real requirement when using delta updates, compression staging, or encrypted streaming; 8–64 KB is typical, but some schemes need more. Reserve NVM for configuration and monotonic counters; even 4–16 KB can prevent redesign when you add audit logs or key rotation.
Interpreting Headroom and Planning Next Steps
Headroom is your remaining safety buffer after all reservations. If headroom is negative, reduce features, lower margins only with evidence, or increase flash. If headroom is small, raise alignment awareness: a few misaligned regions can waste multiple pages. Export CSV for design reviews and PDF for release notes, then keep inputs alongside your linker map to stay consistent across every release.
It rounds each region up to a fixed byte boundary, usually the erase page. This avoids partial-page erases and makes partitions easier to protect. Larger alignment improves simplicity but can waste more space.
Start with 2–8% overhead if you see linker padding in map files. Use 10–25% growth margin when features may expand, security libraries change, or debug hooks are still active.
Choose A/B when rollback safety matters: remote updates, critical devices, or field fleets. It reserves two app slots, so verify the per-slot maximum still meets your image size plus future growth.
Negative headroom often comes from alignment rounding, added safety margins, or enabling A/B which doubles app reservation. Also check scratch and NVM reservations, because small values add up quickly.
You can, but it is risky. Aim to keep utilization under 85% so hotfixes and small feature additions still fit. If you must run tighter, validate with repeated builds and maps.
Store the CSV or PDF alongside your linker map, partition table, and release tag. That package lets reviewers reproduce sizes, verify offsets, and track how boot features changed over time.