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_STATSflag (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_sizeandminimal-printf(optimal size, no debugs) profiles and-DMBED_HEAP_STATSflag (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:
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:
