Astrobe Forum

With Astrobe version 9.0, the useful stack trace functionality of can show false positives, ie. list procedure calls that don't belong in the call chain leading up to the run-time error.

Consider this test code: It shows this error message and stack trace on my machine (register output omitted): It's the result of the heuristic used to detect the procedure calls in the chain searching for "feasible" link register (LR) values. In the above test case, 'Main.Init' happened to conincide with variable 'z' in procedure 'p1', and was still on the stack from the initialisation call chain. It's actually pointing out an unused local variable (the compiler warning for which I had ignored for the sake of the test). If I assign a value to 'z', the false positive 'Main.Init' disappears, as one would expect. In this sense, it's a feature. :)

Another case with false positives could be if you write code that calculates return addresses, eg. for a debugger, that are kept in local variables, ie. on the stack. I guess in such case we'll know how to interpret the stack trace. So all good.

However, I have run into a case where a procedure call in the chain was missing. Consider this test code: It shows this error message and stack trace on my machine: Clearly, the call of 'p1' in 'p0' is missing (line 14).

Module Traps catches run-time errors via handler 'SCVTrap', which is activated via checks and SVC statements inserted by the compiler into the program code. 'SCVTrap' initiates the creation of the stack trace thusly: In my understanding, the stack has this layout after the prologue of 'SVCTrap': Hence, the part of the stack that needs to be scanned for potential LR entries starts at 'SYSTEM.SP + 36'. The above test code actually places the first relevant LR value at +36, hence it gets missed by 'SVCTrap'. If I change this value from +40 to +36, I get the correct output: So, problem solved, right? No. It took me a while to figure this one out. The stack frame for the exception handler gets aligned to a double word, ie. an 8 byte boundary: The programmer's manual does say: "The stack frame is aligned to a double-word address", but I had missed this statement, even when re-reading. Ayo. Unlike for the M3, this cannot be configured (see 'Configuration and control register (SCB_CCR)', 'STKALIGN' bit: "Always reads as one, indicates 8-byte stack alignment on exception entry." This register is read-only.)

So, depending on the layout of the stack in the procedure call-chain, there can be a one word "gap" between the double-word aligned exception stack frame and the lower end of the stack before the exception. 'SYSTEM.SP + 36' will read that "gap" value, and 'SYSTEM.SP + 40' would be the correct address for the stack track in this case.

Alas, simply always starting from 'SYSTEM.SP + 36' can result in false positives too, as this test code shows: Which produces... ... because the value in the "gap" was the LR value corresponding to the call of 'p2' from 'p1' (line 11).

Unfortunately, from "inside" 'SVCTrap', I don't see any possibility to check and decide for either the +36 or the +40 offset, depending on the specific situation, since we don't know the value of SYSTEM.SP right before the exception. Maybe someone smarter than me can figure this one out. I prefer wrong call entries over missing ones, so I set the offset to +36. It's usually possible to quickly make sense of the false positives. Which, as outlined at the top, can happen even if the offset is correct. In any case, the stack trace is enourmously useful, we just need to be aware of the few caveats (and maybe setting the stack offset to +36 from +40).

And yes, the test code examples are somewhat contrived, but that's the nature of test programs. :)

Astrobe's Disassemble Application functionality has proven to be of great value for diagnosing the above issues! For this, I had adapted Traps.ShowStack and Traps.OutStackItem to print "upwards" beyond the exception stack frame to see what Traps.StackTrace scans, and without the app disassembly listing, mapping LR values on the stack to their corresponding procedure calls would have been, hm, "difficult".

Thank you for your detailed analysis. We are currently working on an improved version of Traps and your insight and test cases are very useful.

Unfortunately, from "inside" 'SVCTrap', I don't see any possibility to check and decide for either the +36 or the +40 offset, depending on the specific situation, since we don't know the value of SYSTEM.SP right before the exception. Maybe someone smarter than me can figure this one out.

If you are interested in working on this sort of code I recommend that you get a copy of Joseph Yiu's book The Definitive Guide to Arm® Cortex®-M0 and Cortex-M0+ Processors if you do not already have it

In the chapter on Exceptions and Interrupts it says:

If the position of the last pushed data could be in an address that is not double word aligned, the stacking mechanism automatically adjusts the stacking position to the next double word aligned location and sets a flag (bit 9) in the stacked xPSR to indicate that the double word stack adjustment has been made.

We'll be testing a solution based on this information ourselves.

Thanks! That's exactly the flag to test to decide for either the +36 or the +40 offset, ie. solve the "gap" problem in 'SVCTrap'. My two "gap"-related test cases now show correct results with the corresponding changes in 'SVCTrap'.

To be fair, the flag is described in the M0 programming manual (PM0215) -- in the section for the SCB_CCR (4.3.5, page 60):

On exception entry, the processor uses bit[9] of the stacked PSR to indicate the stack alignment. On return from the exception,
it uses this stacked bit to restore the correct stack alignment.

Seems I need to improve my manual reading skills.