Mistake on this page? Email us

RAM and flash requirements and examples

Client RAM and flash consumption are impacted by:

  • The board itself - board target code and network driver sizes vary.
    • Bootloader sizes for the board vary from 26KiB to 58KiB. A custom bootloader with required functionality under 10KiB is possible, but a standard free offering is larger.
    • Network stacks vary in size from tens of kilobytes (AT parser-based solutions) to megabytes (some Wi-Fi and cellular stacks).
  • Compiler - GCC_ARM, Arm Compiler and IAR all behave differently and produce binaries with different sizes.
  • Compiler settings - optimizations for speed or size have an impact on the generated code.
  • C/C++ language features and libraries used in an application - Client does not use the C++ Standard Library (STL), as it adds 15KiB of ROM consumption.
  • Feature selections:
    • Adding a filesystem, for example for SD card or external flash, adds tens of kilobytes of code and kilobytes of RAM.
    • Enabling traces can almost double flash consumption.
    • Additional drivers or application logic:
      • Bluetooth stack takes 80-150KiB.
      • A complex sensor driver can take several tens of kilobytes of flash.

Example configurations

  • Device Management Client example setup:
    • Arm 6.14 compiler.
    • Compiled with release (drops debug info and traces) profile and -DMEMORY_TESTS_HEAP -DMBED_HEAP_STATS flag (to enable Mbed OS memory APIs and application printouts for memory tracing).
  • Izuma Client Lite example setup:
    • GNU Tools for Arm Embedded Processors, version 9.2.1 compiler.
    • Compiled with pico_lte_size and minimal-printf (optimal size, no debugs) profiles and -DMBED_HEAP_STATS flag (to enable memory measurements and printouts).
  • Memory figures in the table include all memory usage (Mbed OS, Client example application, Mbed TLS, networking stack).
  • Firmware update capability is included.
Item Client minimum config Client maximum config Client Lite Client Lite Bare-metal TLS
Board NXP K64F NXP K66F NRF52840_DK K64F
Connectivity ESP8266 (Wi-Fi) Ethernet (lwIP) BG96 (LTE) ESP8266 (Wi-Fi)
Client version 4.8.0 4.8.0 1.3.0-lite 1.3.0-lite
Mbed OS version 6.8.0 6.8.0 5.15.3 5.15.3
Storage KVstore (TDBStore (internal)) KVstore (TDBStore (internal)) KVstore (TDBStore (internal)) KVstore (TDBStore (internal))
Features All optional disabled All enabled All optional disabled All optional disabled
Config file wifi_esp8266_minimal.json mbed_app.json mbed_app.json mbed_app_baremetal_tls.json

Note The Client Lite feature set differs greatly from the Client feature set, and is therefore not comparable to Client.

The minimal configuration drops all non-essential Client features, such as:

  • First-to-claim.
  • Device-generated certificates.
  • Blink patterns from the example application.
  • Custom resources created by the application for demo purposes.

Example memory figures

Memory consumption figures measured using the Client (or Client Lite) example application:

RAM consumption (KiB) Client min config Client max config Client Lite Client Lite Bare-metal TLS
RAM, static 21 55 9 10
RAM, dynamic 27 44 19 15
RAM, total (static + dynamic) ~47 ~99 ~28 ~25

RAM peak dynamic consumption is mostly driven by the TLS handshake.

ROM consumption (flash, KiB) Client min config Client max config Client Lite Client Lite Bare-metal TLS
Bootloader size 32 32 32 32
KVStore allocation 32 96 32 32
Application and Mbed OS size 268 333 200 167
Firmware update download area 268 333 200 167
Total 600 794 464 398

Note: You must always align the allocations in internal flash to the flash erase sector size. Even if the bootloader size is only 29KiB, the erase sector size may force you to allocate 32KiB for it. Erase sector sizes are chipset-specific, so check your chipset specification. This also applies to the application size and firmware download area. Image sizes reported are based on the size of the file on a filesystem.

KVStore size is just a rough estimate for a typical device. You need to ensure the KVStore size matches your device requirements and estimated write count. Internal flash typically tolerates 10000 erase cycles before it gets damaged. The size of the KVStore area must be large enough to cover the estimated writes of the whole device lifetime without exceeding the estimated erase cycle count.

We provide multiple bootloaders. Configurations using SPI flash or SD card as firmware download storage are approximately 10KiB larger as they have to include block device and SD driver. We can also provide a custom optimized bootloader that fits into 10 kilobytes. Contact us for the optimizations.

Example flash memory layout - internal flash only

Typically, the most optimal solution is an internal-flash-only layout. You can optimize the bootloader and OS, as there is no need for SPI/QSPI drivers.

A high-level example of an internal-flash-only layout:

Internal-flash-only memory map illustration

Note: Dual-bank flash is mandatory.

Due to the nature of flash memory, the erase cycle prevents simultaneous reads from the same bank. This has a notable impact on application execution. Network stacks with high latency requirements can quickly get out of sync during an erase operation if internal KVStore is located in the same bank as the application. Memory map data and code regions must also be aligned to flash banks because executing code from a bank being written or erased leads to undefined behavior. Please refer to the hardware reference manual of the chipset you are using.

Example flash memory layout - internal flash and SPI flash

If the application is large or you need to store large amounts of application data, this solution can be the most cost-effective. However, this increases the size of the bootloader and OS, as you need storage drivers, and possibly a filesystem. The firmware download area can be located in the SPI flash, which decreases the size of the internal flash significantly. (Q)SPI flash memories are also usually rated to 100 000 erase cycles so flash wearing is not an issue.

A high-level example of internal flash and SPI flash layout:

Internal flash and SPI flash memory map illustration