Measuring Stack Usage the Hard Way | Interrupt

Embedded systems often require a careful eye to where memory resources are being spent, especially runtime memory utilization like stack and heap memories.

This is a companion discussion topic for the original entry at

Great Post, really love it!
Do I miss something or is hit_breakpoint function never defined?
I would assume it would look something like this:

def hit_breakpoint() -> bool:
    locations = []
    for gdb_breakpoint in gdb.breakpoints():
        for location in gdb_breakpoint.locations:
    pc = int(gdb.parse_and_eval("$pc"))
    if pc in locations:
        return True
    return False

1 Like

Well spotted @Kaio , fixed up the example script to match the snippet in the article. Thanks for noticing the issue!

Hi. I’ve been reading this blog for a very long time. I advise all friends to read, but many miss useful articles and I would like to convey useful information to them. I ask permission to translate it for my readers and friends from Armenia, Ukraine, Russia and Georgia.

Great article Noah. I just got hip to cut and it looks like gnuplot is the ideal graphing counterpart to that. :+1:

1 Like

do you need to compile with -fpic if you relocate your bootloader from flash to ram?

Thank you, this was something I needed to be very vigilant about on a project a few years ago - it’s nice to see a range of solutions.

When it was an issue for me, we used the Keil toolchain. Fortunately, the armcc linker also has a command line option to generate static call traces, and report stack usage per function:
I used to post-process that file with a Python script to create an estimated worst-case stack for each task and IRQ handler, generating a report on each build, and I would force the build to fail if stack space was tight. The script would need to know the possible nested interrupt combinations, so it would need to be configured with a list of interrupt handlers and interrupt priority levels.

Hi Noah,
Very nice article, thank you!

Apache NuttX uses similar technique (enabled CONFIG_STACK_COLORATION) as can be seen here: nuttx/arch/arm/src/common/arm_checkstack.c at master · apache/nuttx · GitHub

Since you worked at Fitbit then I think you are not strange to NuttX :wink:

If you can, please include this reference to NuttX to make your article more complete!

Thank you very much in advance!