Stack Analysis

What is Stack Depth Analysis?

Calling a function or handling an interrupt requires allocation of memory from the stack memory region. If the stack memory region is not large enough to hold the stack, RAM is corrupted, leading to difficult, non-deterministic node failure. For obvious reasons these failures cannot be replicated in TOSSIM.

In a TinyOS application (as in any embedded system lacking virtual memory) the size of the stack is determined statically and it is important that the size be chosen appropriately. The stack region must not be too small. If it is too large the system will operate correctly, but RAM that could have been put to good use is wasted.

TinyOS (without TOSThreads) has a single stack. When a heap is not in use, the size of the stack memory region is simply:

(RAM size) - (data segment size) - (BSS segment size)

The only question is: Is this region large enough? The most common way to answer this question is by running the system. If it crashes in a non-deterministic way, one of the things a developer will try is to reduce the size of the data or BSS segments.

Stack depth analysis offers a more principled alternative: static analysis of the compiled application in order to predict its worst case stack memory usage.

For applications that use a heap and/or threads, the situation is more complicated.

Stack Depth Analysis for TinyOS

A stack depth checking tool is available from the TinyOS CVS repository (and will be available in the next release following TinyOS 2.1). You can get this tool either by checking out the entire repository or by using this direct link into the CVS repository. The remainder of this tutorial will assume that tos-ramsize is in your path (because, for example, you ran "make install" in tinyos-2.x/tools).

Running tos-ramsize Directly

Given an application for one of the AVR platforms, you can run a command like this:

[regehr@babel BaseStation]$ tos-ramsize micaz ./build/micaz/main.exe 

The result should be something like:

BSS segment size is 1708, data segment size is 16
The upper bound on stack size is 538
The upper bound on RAM usage is 2262
There are 1834 unused bytes of RAM

Here the tool is telling us that for the BaseStation application on the MicaZ platform, approximately 1.8 KB of RAM is free and could have been allocated for packet buffers or some other purpose.

Running tos-ramsize from the Build System

Run a command like this:

[regehr@babel MultihopOscilloscope]$ make micaz stack-check

The result should be something like:

[regehr@babel MultihopOscilloscope]$ make micaz stack-check
mkdir -p build/micaz
    compiling MultihopOscilloscopeAppC to a micaz binary
ncc -o build/micaz/main.exe  -Os -fnesc-separator=__ -Wall -Wshadow -Wnesc-all -target=micaz -fnesc-cfile=build/micaz/app.c -board=micasb -DDEFINED_TOS_AM_GROUP=0x22 --param max-inline-insns-single=100000 -I/home/regehr/z/tinyos-2.x/tos/lib/net/ -I/home/regehr/z/tinyos-2.x/tos/lib/net/ctp  -I/home/regehr/z/tinyos-2.x/tos/lib/net/4bitle -DIDENT_APPNAME=\"MultihopOscillo\" -DIDENT_USERNAME=\"regehr\" -DIDENT_HOSTNAME=\"babel\" -DIDENT_USERHASH=0xaa57ee96L -DIDENT_TIMESTAMP=0x49e3a884L -DIDENT_UIDHASH=0xb4560dc8L -fnesc-dump=wiring -fnesc-dump='interfaces(!abstract())' -fnesc-dump='referenced(interfacedefs, components)' -fnesc-dumpfile=build/micaz/wiring-check.xml MultihopOscilloscopeAppC.nc -lm 
/home/regehr/z/tinyos-2.x/tos/chips/cc2420/lpl/DummyLplC.nc:39:2: warning: #warning "*** LOW POWER COMMUNICATIONS DISABLED ***"

BSS segment size is 3421, data segment size is 24
The upper bound on stack size is 578
The upper bound on RAM usage is 4023
There are 73 unused bytes of RAM

    compiled MultihopOscilloscopeAppC to build/micaz/main.exe
           25458 bytes in ROM
            3445 bytes in RAM
avr-objcopy --output-target=srec build/micaz/main.exe build/micaz/main.srec
avr-objcopy --output-target=ihex build/micaz/main.exe build/micaz/main.ihex
    writing TOS image

Here, tos-ramsize is telling us that only 73 bytes of memory are available.

Assumptions

The correctness of tos-ramsize's results are predicated on some important assumptions.

No Reentrant Interrupts

A reentrant interrupt is one that may have multiple instances on the stack at the same time. For example, consider the following scenario where your application requests high-frequency timer interrupts. First, the timer device requests an interrupt, causing your handler to run. Second, your handler re-enables interrupts. Third, either your handler runs for longer than expected or else a second interrupt handler preempts the timer handler. Finally, the timer device requests its next interrupt, causing the timer handler to be reentered.

tos-ramsize assumes that this scenario never happens. There are three ways to avoid reentrant interrupts:

1. Make all interrupt handlers atomic, meaning that they do not run with interrupts enabled
2. For every non-atomic interrupt handler in your application, ensure that it returns-from-interrupt before the same interrupt source becomes pending again. In other words, prove that the maximum execution time of the interrupt handler -- including the maximum execution time of all interrupts that may preempt it -- is smaller than the minimum interarrival time of that interrupt.
3. Use a platform that supports prioritized interrupts in a reasonable fashion (AVR is not one of them)

Control Flow Integrity

Basically, every function must return control to the instruction that follows the call that invoked it. This is normally the case. Control flow integrity is violated when the compiler or application is buggy. In the most common scenario, a pointer or array bug in the application permits a return address on the stack to be accidentally or deliberatively overwritten. See Safe TinyOS.

No Hidden Stack Pointer Updates

tos-ramsize cannot predict worst-case stack depth unless it can correctly interpret all manipulation of the stack pointer. On the AVR architecture, indirect stores can be used to change the SP. You should not write code that does this.

Interrupts Are Correctly Classified

tos-ramsize attempts to classify interrupts as atomic or non-atomic. As previously mentioned, an interrupt is non-atomic if it may run with interrupts enabled. tos-ramsize marks an interrupt handler as non-atomic if the sei instruction is executed in any function reachable from that interrupt handler. Stores to SREG, on the other hand, are assumed to be part of nesc_atomic_end() calls-- which only enable interrupts if they were previously enabled.

Limitations

write me

Internals

write me