Stack Size Estimator — worst-case depth

Estimate worst-case stack depth from call nesting, locals and interrupt frames.

Example: A worst case of about 832 bytes suggests allocating 1248 bytes of stack at a 1.5× margin.

Inputs

Deepest call depth

Average frame size(bytes)

Typically 32–64 bytes for ordinary functions on Cortex-M.

Largest stack buffer(bytes)

A single char buf[512] dominates everything else.

Max nested interrupts

With one priority level, this is 1. With preemption, as deep as your priorities allow.

Stack per interrupt(bytes)

32 bytes for the Cortex-M hardware frame, plus whatever the handler uses. 104 with an FPU frame.

Safety factor

Total RAM (optional)(bytes)

Result

Recommended stack

1248 bytes

Estimated worst case: 832 bytes
Call tree: 640 bytes
Interrupt frames: 192 bytes
Share of RAM: 6.1%

A stack overflow rarely announces itself. It quietly corrupts whatever sits below the stack — often a global variable — and the symptom appears somewhere unrelated, long after. Fill the stack region with a known pattern at boot and check the high-water mark, or enable an MPU guard region.
This is an estimate. For a real figure, use the compiler's stack-usage output (-fstack-usage on GCC) with a static analyser that walks the call graph — this tool is for sizing before that data exists.

Sensitivity to call depth

Call depth	Call tree	Total	Recommended
4	448	640	960
8	640	832	1248
12	832	1024	1536
16	1024	1216	1824
24	1408	1600	2400

Check it against real silicon

Chiprun runs your firmware on an emulated microcontroller and hands back the UART output, so you can confirm these numbers rather than trusting them.

Chiprun docs

Formula

stack = deepest call chain + interrupt frames + margin

Worked example

A worst case of about 832 bytes suggests allocating 1248 bytes of stack at a 1.5× margin.

call tree = depth × frame + largest buffer
8 × 48 + 256
640 bytes
interrupts = nesting × frame
2 × 96
192 bytes
Interrupts stack on top of the deepest point of the call tree, not beside it.
recommended = (call tree + interrupts) × margin
832 × 1.5
1248 bytes

Frequently asked questions

How much stack does an embedded application need?

It depends entirely on the deepest call chain and the largest local buffers in it. A simple bare-metal loop might need 512 bytes; anything using printf, a filesystem or a network stack can need several kilobytes. Estimate first, then measure.

Why do interrupt frames matter so much?

Because an interrupt can arrive at the deepest point of your call tree, and its frame stacks on top. Nested interrupts add more. Sizing for the call tree alone works on the bench and overflows in the field, when an interrupt happens to land at the wrong moment.

How do I measure actual stack usage?

Fill the stack region with a known pattern at boot, run the firmware through its heaviest workload, then look for the highest address still holding the pattern. That high-water mark is your real peak. GCC's -fstack-usage plus a call-graph analyser gives a static bound too.

What happens when the stack overflows?

Usually nothing obvious at first. It writes past its allocated region into whatever is next in RAM — commonly globals — and the corruption surfaces later somewhere unrelated. That is why an MPU guard region or a stack canary is worth the setup cost.

Related tools

C Struct Padding Calculator

Paste a C struct to see member offsets, inserted padding and total size for 32-bit and 64-bit targets — and how to reorder it smaller.

Firmware

Interrupt Latency Calculator

Worst-case interrupt response from clock speed, cycle counts and priority nesting.

Firmware

Flash & EEPROM Endurance Calculator

How long your flash survives at a given write rate, and how much wear levelling buys you.

Firmware

Hex, Binary & Decimal Converter

Convert between hex, binary, decimal, octal and ASCII, with width-aware bit grids and endianness swapping.

Firmware

Bitwise Operation Calculator

AND, OR, XOR, NOT and shifts with a live bit grid so you can see exactly which bits moved.

Firmware

CRC Calculator

CRC-8, CRC-16 (CCITT, Modbus, XMODEM) and CRC-32 over hex or ASCII input, with the polynomial and shift steps explained.

Firmware