Measure stuff in embedded platforms

1 Measuring Memory Usage
- 1.1 Flash and RAM (Compile Time)
- 1.2 Stack and heap (RAM at Runtime)
2 Measuring Execution Time
3 Measuring Energy Consumption
- 3.1 Correlating Execution Time and Energy Consumption
4 Advanced Measurements for Energy and Time
- 4.1 Step-by-step Granular Time and Energy Consumption
- 4.2 PPI (Programmable Peripheral Interconnect) / EXTI (External Interrupt) Mapping
5 Measuring Message Sizes
6 drafts
- 6.1 nm (actually not recommended)

The reader will build the following competences in this tutorial:

To assess Flash and static RAM usage at compile time, by analysing memory map files.
To measure Heap and Stack usage at runtime using the technique of memory painting.
To measure execution time using internal and external tools (hardware timers and logic analysers).
To measure energy consumption using osciloscopes and power profilers.
To correlate execution time and energy consumption data in a granular and step-by-step way, allowing the identification of performance bottlenecks.
To measure message sizes of IoT protocols deployed in embedded systems, using techniques such as logging and packet sniffing.

Overview of the setup and workflow:

Measuring Memory Usage

Flash and RAM (Compile Time)

analyse compiled binary with GNU size and objdump
inspect memory map files

To measure memory at compile time, one can analyse the resulting binary and associated metadata, such as memory map files. Analysis at compile time allows assessing full Flash usage and partial RAM usage. It can be performed with more or less granularity, depending on the tool used. Available tools include GNU objdump, size, and nm ; the memory map file generated by the linker can also be used for manual inspection or automated parsing.

For global granularity, use the GNU size command on your binary. The text and data sections represent memory used for code and initialized variables, respectively, and they will use space in the Flash. So in the example below, Flash usage is 15840 + 56 = 15896 bytes. The bss section (which for historical reasons stands for Block Started by Symbol) stores uninitialized variables, and therefore it does not occupy space in the Flash. Since the variables in bss and data will need to be manipulate during runtime, these occupy space in RAM, thus in this example the static RAM usage amounts to 1032 + 56 = 1088 bytes.

$ size target/thumbv7em-none-eabihf/debug/lakers-no_std
   text    data     bss     dec     hex filename
  15840      56    1032   16928    4220 target/thumbv7em-none-eabihf/debug/lakers-no_std

We can see a slightly more detailed table with the objdump -h <binary file> command, which will print all the section headers and their attributes. For example, the text section contains code, while sections .vector_table, .rodata, and .data contain data.

$ objdump -h target/thumbv7em-none-eabihf/release/lakers-no_std
Idx Name          Size      VMA       LMA       File off  Algn
  0 .vector_table 00000400  00000000  00000000  00010000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         0000ceec  00000400  00000400  00010400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .rodata       000038d0  0000d2f0  0000d2f0  0001d2f0  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .data         00000038  20000000  00010bc0  00030000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
(...)

Sometimes, we want to measure only the sizes for certain parts of our code. For example, in lakers, we normally want to measure how much memory is needed by the library itself, but want to discard things like the cryptographic backend, since it changes across platforms.

One way to do that is by analysing the memory map file generated by the linker (one might need to enable it by passing a flag such as -Clink-args=-Map=/tmp/lakers.map to the linker). Different linkers generate slightly different memory map files, but all map files will show exactly what symbols are placed in each section of the memory, as well as their address and size. In the example below, the Flash section begins at address 0x400 (__stext). The first symbol is a reset handler introduced by the cortex-m-rt crate, and the next symbol is the prepare_message_1 function, which starts at address 0x459 and uses 0x13c bytes. Using a script to parse this file and selecting only the target libraries or functions will give a very granular insight into Flash usage by the program. Similarly, sections such as .data, .bss, and .rodata can be analysed to obtain static RAM usage.

$ cat /tmp/lakers_no-std.map | grep " .text" -A 8
     400      400    15a4c     4 .text
     400      400        0     1         __stext = .
     400      400       58     4         /home/gfedrech/Developer/inria/dev/lakers-FORK/target/thumbv7em-none-eabihf/debug/deps/libcortex_m_rt-ab9dabb33bc95171.rlib(cortex_m_rt-ab9dabb33bc95171.cortex_m_rt.bd536e3d6951dd08-cgu.0.rcgu.o):(.Reset)
     400      400        0     1                 $t.1
     401      401       3e     1                 Reset
     440      440        0     1                 $d.12
     458      458      13c     2         /home/gfedrech/Developer/inria/dev/lakers-FORK/target/thumbv7em-none-eabihf/debug/deps/lakers_no_std-3f752946f41f98ae.08piolvegulzp6fpuoijkvkau.rcgu.o:(.text._ZN6lakers28EdhocInitiator$LT$Crypto$GT$17prepare_message_117h45bd752ef830d0b1E)
     458      458        0     1                 $t.0
     459      459      13c     1                 lakers::EdhocInitiator$LT$Crypto$GT$::prepare_message_1::h45bd752ef830d0b1

Stack and heap (RAM at Runtime)

Stack and heap: memory painting, probe-rs

Measuring RAM at runtime in embedded systems can be challenging due to the lack of an operating system that keeps track of memory usage. A way of circunventing this consists in employing the technique of “memory painting”. It consists in filling the RAM with a known pattern (e.g. 0DEAD_BEEF) before the program executes, then let it run, and finally count how many bytes are still intact.

To fill the memory, we can use a simple loop that writes the pattern to the memory. We need, however, to find what should be the start and stop addresses. There are a few ways to do that:

Look at the target datasheet. For example, in the nRF52840, the RAM goes from 0x2000000 to 0x4000000.
Look at or configure the GNU linker script. For example, our application sets RAM : ORIGIN = 0x20000000, LENGTH = 64K, meaning that the RAM begins at 0x2000000 (as per the datasheet) and has a total size of 64 kiB.
Look at the generated memory map file, and find where are the symbols _stack_start and __sheap. Since the stack grows from top to bottom (e.g. from 0x2000000 to 0x2000000 + 64 kiB), and the heap grows from the bottom, _stack_start - __sheap is the total size of our allocatable RAM. Note that this discards sections such as .bss, .data, .uninit, which we do not want to paint!

We now know that we want to paint the memory from __sheap up to _stack_start.

Before continuing, remember that we want to write in the RAM before our code starts executing, otherwise we risk overwriting the stack that is already in use. One way of doing that is writing the loop in assembly (using only registers), and another way is doing it in the reset handler or in some pre-initialisation code in your platform. The cortex-m-rt crate provides a pre_init hook that runs before main, which is ideal to put the stack painting code. In the code below, we first obtain the address where the heap starts using the symbol defined by the linker. Next, since our code is already executing, we do not want to overwrite already allocated stack memory, so we get the current value of the stack pointer (offset by a constant, since we are using the stack while painting it). Finally, we run the loop that writes the pattern to the memory.

Next, we flash and run the program, and after it finishes, we can use a debugger to inspect the memory and learn how much of our pattern was erased. We can use the command probe-rs read <WIDTH> <ADDRESS> <WORDS> and parse it’s output. For example, when reading the first 2 words after __sheap we can see our pattern.

Assuming our RAM size is set to 4096 = 0x1000 bytes (as per the memory.x file), we can compute the runtime memory usage as follows:

Measuring Execution Time

timers, gpio's connected to logic analyzers

There are two main approaches to measuring execution time. In one of them, let’s call it internal, we rely on some timer already available in our board, and use it to keep track of certain interesting events that we want to measure. While this approach is simple, it has the downsides of consuming some energy and an additional peripheral, as well as some extra added code (e.g. a RTC driver). The second approach is the external, where an instrument such as a logical analyser is connected to one or more GPIOs in the board. Then, we want to log an event, we toggle those GPIOs on or off, and have them logged over time by the external instrument software.

Measuring Energy Consumption

multimeters, oscilloscopes, power profilers

To measure energy consumption we connect the device to an external instrument, such as a multimeter, an oscilloscope or a power profiler, that can measure current draw.

Multimeters can be used to read the current consumption at a given point in time, but do not allow automating measurements or taking them over time.

TODO: how to set up the hardware part of measuring with an osciloscope?

A more sophisticated and accurate way of measuring energy consumption consists in using a power profiler, such as the nRF Power Profiler Kit or the Otii Arc Pro. For this tutorial we selected the latter, since it is designed to be board-agnostic and also allow interacting with GPIO pins.

Correlating Execution Time and Energy Consumption

Syncing execution time and energy consumption: power profiler (otii arc) with gpio

Advanced Measurements for Energy and Time

Step-by-step Granular Time and Energy Consumption

Obtaining step-by-step time and energy consumption: merging results from power profiler and logic analyser

PPI (Programmable Peripheral Interconnect) / EXTI (External Interrupt) Mapping

Often it is necessary to link an input GPIO directly to an output GPIO at the hardware level, bypassing software delays. This type of operation is available on certain microcontrollers and systems to reduce latency. In some scenarios peripheral devices are attached to a MCU and we want to measure the energy consumption during the peripheral interaction. Instead of raising a GPIO in SW that is connected to the measurement kit (e.g. PPK), one can use the PPI/ EXTI functionality of the MCU.
Examples:
A button press connected to an input GPIO immediately toggles an LED on an output GPIO.
A sensor’s input signal on GPIO triggers another peripheral or an output pin change via an interrupt.
HW-Platforms:
Nordic Semiconductor (nRF Series) – PPI (Programmable Peripheral Interconnect): PPI allows one hardware event (e.g., a GPIO input change) to directly trigger another (e.g., GPIO output) without CPU intervention.
STM32 Microcontrollers – EXTI (External Interrupt) with Direct GPIO Mapping: GPIOs can be mapped to trigger interrupts or interact with timers, enabling fast response without CPU control.
Texas Instruments (TI) – PRU (Programmable Real-Time Unit): On TI microcontrollers, real-time units handle direct GPIO linking and control, ensuring minimal latency between input and output operations.

Measuring Message Sizes

logging, hardware packet sniffing, packet analysis tools (wireshark)

Logging: can be performed on the mote or on the gateway, easier on the latter.

Packet sniffing: there are two main situations.

If the constrained devices talks to a computer or gateway, just run Wireshark on the computer.
If two devices talk between each other, you need a third device that understand the protocol to sniff the conversation. Some IoT platforms offer facilities to save the conversation as a .cap file, which can be later analyzed on Wireshark.

drafts

nm (actually not recommended)

One way to do that is by using the nm (name list) utility. By default it returns all the symbol names and respective Flash addresses. To also get the symbol size, we set the -S flag. In the example below, we filter out the crypto backend and get the the symbol belonging to the lakers library (EdhocBuffer (...) Default ), which occupies 0x22 bytes.

Sum all relevant symbols with awk and we get the Flash usage for our application.