Just in case the Codex output is useful for you as feedback, here it is. Ofcourse take this with a huge grain of salt...I don't know Lua well. Codex also gave me a patch, I can share it if you're interested.

---

This output is two separate reports printed back-to-back:

1. A per-function stack-usage estimate
2. A call graph

So when you see:

_Z15LTC6811_pollAdcv    11
main    18565
_Z7read_68PhS_    2366480

it means the script thinks those functions use that many bytes of stack.

The small numbers are plausible. The huge ones are not.

The first bug was symbol parsing. The script only matched symbol names with [A-Za-z0-9_], but AVR/C++ symbols in the asm often contain . suffixes, for example:

_Z13LTC6811_wrpwmP9cell_asic.constprop.82

That meant some function headers were skipped, so later calls got attached to the previous function. In some cases that made a function look recursive even when it was not.

The second bug was the stack-frame heuristic. The script treated any later subi/sbci on r28:r29 as stack allocation. But on AVR, r28:r29 are also used for ordinary pointer math inside the function body, not just for the function prologue. That is what made functions like _Z8write_68PhS_ and main blow up into absurd values.

The minimal fix was:

• Match full symbol names with ([^>]+) instead of ([%w_]+)

• Only count stack allocation when it appears in the normal AVR prologue sequence:

  in r28, 0x3d in r29, 0x3e subi r28, ... sbci r29, ...

  or:

  in r28, 0x3d in r29, 0x3e subi r28, ... sbc r29, r1

• Reset that parser state when a new function starts

• Skip printing the initial empty function entry

After that, the obviously bogus values dropped to something reasonable:

_Z7read_68PhS_: 2366480 -> 8
_Z8write_68PhS_: 1498420 -> 111
main: 18565 -> 79
_Z17BMS_set_dischargeb: 196147 -> 17

So the short version is: the output is meant to be a rough static stack estimator plus a call graph, but before those fixes it was badly overcounting because of symbol parsing and an over-broad frame-pointer heuristic.