• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 2547 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

AnBer
Mastermind 28890 points

Team,

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 3.3.82.13. 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

  • 0
    TI__Expert 5905 points

    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.

    Darian

  • 0 in reply to Darian Sale
    TI__Mastermind 28890 points

    Thanks a lot Dorian:)

  • 0 in reply to Darian Sale
    TI__Expert 5905 points

    Anthony,

    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.

    Darian