Firmware memory use analyzed per symbol on small riscv microcontroller
Where the SRAM Goes: Per-Symbol Attribution of Static Memory in FreeRTOS-C and Embassy-Rust IoT Firmware on a 64 KB RISC-V Microcontroller
Operating SystemsHardware ArchitectureSoftware Engineering
Summary
Choosing firmware for tiny computers with little memory is tricky because usual size reports only say total memory used, not where it’s going. The authors created a way to see exactly which parts of the firmware use memory by looking at individual symbols and their categories like stacks or buffers. They tested this on two firmware types running on the same chip and showed differences in memory use, such as one stack type growing linearly with tasks and another growing with complexity. Their tools and example firmware are publicly available.
What this means in practice
- •For embedded firmware engineers: Identify exactly where static memory is used in resource-limited firmware to optimize memory allocation and reduce resource waste.
- •For iot system developers: Compare memory costs of different networking stacks in IoT firmware to select efficient implementations for constrained devices.
Authors
Romi Fadli, Jan Everhard Riwurohi, Wahyu Ramadani Putri Utami, Zulfa Malika Amana
Abstract
Selecting a firmware stack for a memory-constrained microcontroller is usually guided by aggregate binary sizes, which report how much SRAM a build consumes but not where it goes or why. We address that gap with a per-symbol attribution method that decomposes static RAM into architectural categories - scheduler heap, network buffers and pools, task stacks, and linker-reserved regions - by bounding sized ELF symbols to the .data, .bss and .stack section ranges. The method is validated by reconciling every category sum exactly against the size-based totals for all sixteen builds. We apply it to eight cumulative firmware milestones, from a bare task scaffold to a full MQTT-over-Ethernet client, implemented twice, in FreeRTOS-C and in Embassy-Rust, on the CH32V203RBT6, a RISC-V microcontroller with 64 KB SRAM and an on-chip Ethernet MAC and PHY, with functional parity verified on hardware at every milestone. The decomposition shows that both stacks spend a nearly identical share of their RAM on networking (63.8% versus 63.9%), yet the absolute cost differs by 4.4 times: 40,719 bytes for lwIP against 9,316 bytes for smoltcp. FreeRTOS task stacks grow linearly at roughly 1 KB per task while Embassy async state grows with state-machine complexity. We also report that lwIP could not be integrated under an all-static discipline on this platform, requiring a 20 KB arena that smoltcp does not. The measurement harness, the attribution tool, and the sixteen firmware implementations are released as artefacts.