HardFault_Handler Showing the Nested Stack Calls

lpcware · ‎06-15-2016

Content originally posted in LPCWare by kralux on Thu Aug 23 17:08:47 MST 2012
I am looking for code that would give me the list of all nested jumps after an exception occurs. This is similar to what the Red Suite debugger does.
This is to be used during run-time operation to give more information on the cause of the error.
I am familiar with the .axf disassembler to match instructions and memory location.
I am also familiar with this page http://support.code-red-tech.com/CodeRedWiki/DebugHardFault
Unfortunately that code does not seem to give the nested list of method calls. It also strangely shows PC as being the address of the faulty instruction which caused the exception. Is that correct? (would have thought it should have been in LR).

My platform is an M3 LPC1788.

Here is a list of the type of debug info I would like to have (info needed is in red):
6 HardFault_HandlerAsm() cr_startup_lpc178x.c:450 0x0000ddc8
5 <signal handler called>() 0xfffffff9
4 takeAction() model.c:925 [COLOR=Red]0x000119a4[/COLOR]
3 processController() controller.c:49 [COLOR=red]0x0000dd5c[/COLOR]
2 main() main.c:207 [COLOR=red]0x0000f2ec[/COLOR]
1 ResetISR() cr_startup_lpc178x.c:345 [COLOR=red]0x00000194[/COLOR]

(of course, the debug text would not be there but just having the lines of the call would be useful).

Right now it seems the best thing I can do is to look on the stack and get addresses that way with an interval of 6 words for each address. (interval of 11 words to get to the first one though).

Here is the snippet:

uint32_t i;
for (i = 0; i < 10; i++) {
if ((uint32_t)&hardfault_args[17 + i * 6] < 0x1000FFFF) {
stacked_next = ((uint32_t)hardfault_args[17 + i * 6]) ;
}
}

It seems like this may solve my need.

Let me know your thoughts or if you have a better idea.

Thank you.

Alex

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Fri Aug 24 13:04:38 MST 2012
Sorry for not being clearer. I was responding to this

Quote:

But how to unwind the stack at run-time, in C?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Brutte on Fri Aug 24 12:18:23 MST 2012

Quote:
I don't think you understood.

Quote:
I am looking for code that would give me the list of all nested jumps after an exception occurs. This is similar to what the Red Suite debugger does.
This is to be used during run-time operation to give more information on the cause of the error.

What I think about it is that OP needs to get to the information of what, where and when crashed. Some kind of an assert, with extended functionality. Am I right?

Do you think dumping the stack and a piece of paper will not let OP to get to the call stack eventually? Or that connecting a dongle to a crashed and halted target will not allow Eclipse to dig into the truth?

I do not get why do you think misinterpreted OP's aims..

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Fri Aug 24 08:40:00 MST 2012
I don't think you understood.

'unwinding' the stack means showing the call stack, and this is not possible without the debug tables. As you do not know the stack usage of the function that called you, you cannot find what called that, etc. In other words, you cannot find all of the LRs, as they are on the stack, but you do not know where.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Brutte on Fri Aug 24 04:30:14 MST 2012
That is a very interesting functionality.
The reports I use are asserts that present errors verified at compile-time or run-time. I did not need to know the call stack, usually the __FILE__ __LINE__ would do. But I agree - unwinding could be very useful.

For unwinding the stack it would require a lot of debugging information. Function names, arguments, files, lines... :eek:

But how to unwind the stack at run-time, in C? Perhaps you could printf not only lr, but the whole stack and then to paste it to some Eclipse Plug-In so that it showed you what went wrong? A kind of BSOD full of hexes!
Alternatively, halt the core in the HardFaultHandler, blink error led, and gently connect it to the dongle without resetting application!

Quote:
if you use C++ exceptions, then the compiler can place this necessary information into unwind tables built into the executable, for use by the exception handler(s) to unwind the stack. However this significantly increases the size of the image.

That is the third path. I do not think the size is a problem, because this looks like for DEBUG purposes. Neither is speed - the application will eventually run slower, it will be bigger but when it crashes, you will know exactly what went wrong in no time.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Fri Aug 24 00:37:58 MST 2012
It is not possible to unwind the stack without access to the debug tables stored within the AXF file. That is, you cannot do this in target-resident code (unless that code has access to the complete AXF file)

Why?

Many reasons, but for an example, consider the stack. Each function uses a different amount of stack, depending on the number of parameters, and the number/size of local variables. This information is only known by the compiler and is placed in the debug tables in the AXF file - it is not available anywhere within the target image.

[As an aside, if you use C++ exceptions, then the compiler can place this necessary information into unwind tables built into the executable, for use by the exception handler(s) to unwind the stack. However this significantly increases the size of the image.]