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.
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 184.108.40.206. 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,
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.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Darian Sale:
Thanks a lot Dorian:)
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.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.