A Choice You Make Once and Pay For Forever

Memory size is one of the few product decisions that is nearly irreversible after layout. Pin-compatible parts in a family often let you move up one step, but a jump from 64 KB to 512 KB of flash frequently means a different package, a different footprint, and a board respin costing four to eight weeks.

It is also a direct unit-cost lever. Within a typical Cortex-M family, doubling flash costs roughly $0.30 to $0.80 per unit and doubling RAM often costs more. At 50,000 units a year, one unnecessary step up is $15,000 to $40,000 annually. Running out, on the other hand, costs a respin, requalification, and a schedule slip.

What Consumes Flash

Flash holds everything that must survive power loss, and the application code is often not the biggest part.

  • Application code. Your logic, drivers, and startup. For a modest sensor product, typically 20 to 60 KB compiled.
  • Protocol stacks. This is where budgets die. A BLE stack with peripheral role runs 80 to 150 KB. A Wi-Fi stack with TLS runs 300 to 600 KB. LwIP with TCP and DHCP runs 60 to 100 KB. A Matter implementation runs well over 600 KB. See BLE firmware development for what the radio side brings with it.
  • RTOS kernel. Small: 6 to 20 KB for FreeRTOS, more for a full Zephyr configuration with subsystems enabled.
  • Cryptography. mbedTLS with a useful cipher set is 60 to 150 KB. Hardware crypto accelerators shrink this substantially and are worth selecting for.
  • The C library. Full printf with floating-point formatting alone can be 10 to 20 KB.
  • Constant data. Fonts, bitmaps, lookup tables, language strings, calibration curves. A single modest UI font is 8 to 30 KB, and a color icon set can exceed all your code.
  • Bootloader. 8 to 32 KB, more with signature verification and a decompressor, as described in bootloaders in embedded products.
  • Non-volatile settings. Flash-based key-value storage needs whole erase sectors and wear leveling, commonly 8 to 32 KB reserved.

What Consumes RAM

RAM is the tighter constraint on most connected products, and it is harder to measure because peak usage is transient.

Static data and initialized globals are visible in the map file. Stacks are not: with an RTOS, every task has its own, and four tasks at 1 KB each is 4 KB gone before any application data. Interrupt handlers use the main stack, and nesting deepens it. Heap, if you use one, needs headroom for fragmentation.

The large consumers are buffers. A single TLS session needs 16 to 40 KB of RAM for record buffers and certificate parsing, which is why so many parts that can hold a Wi-Fi stack in flash cannot actually complete an HTTPS connection. Network stacks want packet buffer pools. A display framebuffer at 240 by 240 pixels in 16-bit color is 115 KB by itself. DMA buffers for audio or ADC streaming are double-buffered by definition.

The Factor Everyone Forgets: Firmware Updates

The most common sizing mistake is budgeting for the application and then discovering that remote updates need a second copy of it. Any product with OTA firmware updates and a safe rollback path needs somewhere to stage the incoming image while the running one keeps working.

Three approaches, with very different costs. Dual-bank, where flash is split into active and staging slots, is the safest and effectively doubles your application flash requirement. External serial flash, a $0.30 to $0.80 QSPI part holding the staging image, keeps internal flash small and is usually right for anything with a radio. Compressed delta updates reduce transfer size but still need a scratch region and add decompression code.

Plan this at the start. Retrofitting OTA onto a part chosen with 8 KB of headroom is how products end up shipping with no update path, which is a security problem as much as a feature gap.

A Practical Estimation Method

Do this before committing to a part, and do it with real artifacts rather than intuition.

  • Build the vendor example that is closest to your product. Take the silicon vendor's SDK sample with your radio stack and your RTOS, compile it with your optimization settings, and read the map file. That is your floor, and it is usually higher than people expect.
  • Add your application estimate. A reasonable heuristic is 1 KB of flash per 100 lines of moderately dense C at -Os. Count the features in your requirements document, not the ones in the first release.
  • Add data assets explicitly. Fonts, images, tables, strings, all measured, not guessed.
  • Add the update scheme. Dual-bank doubles the application region. External flash moves it off-chip.
  • Apply headroom. Target no more than 60 to 70 percent utilization of both flash and RAM at first production release. Firmware grows over a product's life, and the last 20 percent of a memory map is where every schedule dies.

Rough Orders of Magnitude

As a first orientation, before your own analysis: a simple sensor or accessory with no radio fits in 32 KB flash and 8 KB RAM. A BLE peripheral with sensor logging typically needs 256 KB flash and 32 to 64 KB RAM. A Wi-Fi product with TLS and cloud connectivity realistically wants 1 MB flash and 256 KB RAM, or an SoC with integrated PSRAM. A device with a color display and a graphics library needs 1 to 2 MB flash and 256 KB or more RAM, often with external memory. Anything running TinyML inference on a microcontroller adds the model itself in flash plus a tensor arena in RAM, commonly 20 to 200 KB each.

Family choice interacts with all of this. The tradeoffs between integrated-radio SoCs and general-purpose parts are laid out in ESP32 vs STM32, and the wider selection criteria in how to choose a microcontroller.

When You Run Out Anyway

Before ordering a respin, work the reclamation list. Compile with size optimization and link-time optimization, and enable function and data sections with garbage collection at link time, which alone often recovers 10 to 25 percent. Replace full printf with a minimal integer-only variant. Move constant tables to flash with const. Cut unused protocol features from the stack configuration. Reduce over-allocated task stacks after measuring high-water marks. Add an external QSPI flash for assets and OTA staging, far cheaper than a new MCU.

If none of that is enough, the honest conclusion may be that the workload belongs on a different class of compute entirely, a decision framed in microcontroller vs embedded Linux. Deciding that before layout costs a week; deciding it after costs a quarter.

Size It Before You Lay Out the Board

Projects House builds memory budgets from real compiled artifacts and your actual feature list, including the update scheme, so the part you commit to still fits in three years. Send your feature requirements and connectivity plan through our contact form.