• Resolved

CCS 3.30 - debug: Using "call stack window" for post mortem analysis?


A customer is trying to use "call stack" for post mortem analysis to analyze a system that crashed. Description on what he does is below in blue.

Q: Does the "call stack window" only relying on the system stack or are there information recorded by CCS during execution to keep track of the fct calls (like recording B3 register at every fct call)?
In fact we are trying to understand if it can realy be used for post mortem analysis.

Information from customer:
I'm currently working with DSP 6488 & CCS After collecting post-mortem dumps from the board, I'm loading them under CCS. I've a GEL file which allows to restore core registers from the post-mortem data. Then I use the call task feature under CCS and the result is not the expected one. Instead of getting the names of the calling functions, I see some addresses in hexadecimal or names of data varaible.
We do the following:
- memory dump from the board
- load data under CCS
- restore core registers
- use call task feature

Thanks and best regards,


  • Anthony,

    The call stack requires stack memory, some of the core registers, and symbolic data. The current function is looked up based on the program counter.  The symbolic info for that function will indicate what register is the frame pointer (it's typically always the same register, but optimization sometimes changes it), and where the previous program counter and frame pointer are stored on the stack.  Those values are read and then the whole process repeats with those new values.

    If all you're seeing are hex addresses or names of data variables, that leads me to think that the saved PC value is inaccurate.  If the "crash" is due to the processor taking an invalid branch, then the PC will be corrupted already (you'd need the PC just before the invalid branch).  There is no symbol information indicating where the previous frame is for the invalid code.


  • In reply to Darian Sale:

    Thanks a lot Dorian:)

  • In reply to Darian Sale:


    If you (or anyone else with a similar issue) are still intested, CCS 5.1 has a feature that can analyze call frames in the presense of data corruptions.  As such, you should be able to use it even if the PC is inaccurate (or is accurate, but an invalid branch was taken meaning there's no information in the symbols on how to unwind from that invalid location back to valid memory) as appeared to be the case in your example.

    The feature is described here:http://processors.wiki.ti.com/index.php/Crash_Dump_Analysis#Advanced_Stack_Analysis_in_DSS  Just scroll down to the "Advanced Stack Analysis" section.