• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 55 subscribers
  • Views 1156 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCSv4 Debug view displays incorrect call stack?

David Kelly
Intellectual 485 points

Other Parts Discussed in Thread: SYSBIOS

In CCS v4.1.1.00014, I was attempting to debug what looked like stack corruption because the Debug thread view was showing a garbage stack. Turns out it's a problem with the viewer, not so much the stack.

It appears that when most functions make a call, they place the return address in register B3 and at the current SP value before incrementing SP for the new function's allocation.

The Debug View seems to parse this to generate the stack call list.

Some functions, however, place the return address two words higher which makes the call stack in the Debug view corrupted below those functions. Some examples are:

PSP Drivers v02_00_01:

ti_psp_mcasp_Mcasp_localEdmaChanPaRAMsetup__I

ti_psp_mcasp_Mcasp_localSubmitIoctl__I

 

Maybe it's the way that the ...__I calls work? It is a little unnerving, especially when 16 bit values are packed in memory, but the stack increases enough to hold them all as 32 bit.

Any insight on how to resolve this would be great.

 

Thanks

David Kelly

  • 0
    TI__Prodigy 185 points

    David,

    I'm Chris Kelly from the Debugger Team.  I'm one of the developers in charge of interpreting the symbolic information in programs for things like the callstack so I think I should be able to help decipher what's going on here.  To get a good look at the problem would I be able to get a bit more information on how to replicate the problem on my side. 

    First, would you be able to tell me the hardware target and the binaries you were using on the target when you saw the issue?

    For the callstack, are you finding that this is a general issue (i.e. the callstack always seems to function this way) or a specific issue (i.e. only when debugging the scenario you previously described)?  Can you reliably get the binary in a state to reproduce this behaviour?  If so, what are those steps?

    Best regards,

    Chris

  • 0 in reply to Chris_Kelly
    Intellectual 485 points

    Hello Chris:

    Hardware target (from .ccxml):

       Connection: Spectrum Digital DSK-EVM PLUS onboard USB Emulator

       Board or Device: DA830/DA828

       I've disabled the ARM core so that it looks like a C6747

     

    I'm able to reliably reproduce the issue just using the examples from the PSP driver release:

    pspdrivers_02_00_01\packages\ti\psp\examples\evmDA830\mcaspDit

    The binary is 1.5 MB. If you'd like, I could email it to you.

     

    I put a break point at the first call to Stream_issue() at line 453 of the file:

    pspdrivers_02_00_01\packages\ti\psp\examples\evmDA830\mcaspDit\sample\src\audioSample.c

     

    I run the application until it breaks and then step down through the code. You'll probably have to specify Stream.c at:

    ipc_1_00_05_60\packages\ti\sdo\io\Stream.c

     

    One step after the call to Mcasp_localUpdtDtPktToLnkPrms() at the call stack below, the stack will break. Below is the call stack before the call with the arguments removed for clarity.

    Thread [main] (Suspended)
    0 mcaspSubmitReq() at mcasp.c:3008 0xc306da84   
    1 ti_psp_mcasp_Mcasp_submit__F() at mcasp.c:1247 0xc308bd64   
    2 ti_psp_mcasp_Mcasp_submit__E() at mcaspDitSample_x674.c:17166 0xc3095de0   
    3 ti_sdo_io_IDriver_submit() at IDriver.h:142 0xc3095fa8   
    4 ti_sdo_io_converters_DriverAdapter_issue__F() at DriverAdapter.c:138 0xc3094c44   
    5 ti_sdo_io_converters_DriverAdapter_issue__E() at mcaspDitSample_x674.c:17318 0xc30962dc   
    6 ti_sdo_io_IConverter_issue() at IConverter.h:150 0xc3095ea4   
    7 ti_sdo_io_Stream_issueX__I() at Stream.c:298 0xc30890e0   
    8 ti_sdo_io_Stream_issue__F() at Stream.c:254 0xc30933d8   
    9 prime() at audioSample.c:455 0xc30724e4   
    10 Audio_echo_Task() at audioSample.c:391 0xc3072324   
    11 ti_sysbios_knl_Task_exit__F() at Task.c:325 0xc308a820   
    12 mcaspSubmitReq() at mcasp.c:2942 0xc306d8ce   
    13 <symbol is not available> 0xbebebebe   

    I'm not certain what the items 11-13 are either.

    Below is the call stack after one step into the call to Mcasp_localUpdtDtPktToLnkPrms():

    Thread [main] (Suspended)   
    0 ti_psp_mcasp_Mcasp_localUpdtDtPktToLnkPrms__I(struct ti_psp_mcasp_Mcasp_ChannelObj *, struct ti_sdo_io_DriverTypes_Packet *, struct xdc_runtime_Error_Block *) at mcasp_edma.c:997 0xc3072616   
    1 <symbol is not available> 0x14000102

     

    Below is the stack dump after the call:

    0xC309E4B8    01844000  // Current SP
    0xC309E4BC    C3060EF0  // chanHandle
    0xC309E4C0    C30A2350  // ioPacket
    0xC309E4C4    C309E614  // eb
    0xC309E4C8    14000103  // instHandle
    0xC309E4CC    C303FC00  // pramPtr.opt
    0xC309E4D0    C30968B0  // pramPtr.scrAdd
    0xC309E4D4    14000102  // pramPtr.aCnt & pramPtr.bCnt
    0xC309E4D8    00006300      // pramPtr.destAddr
    0xC309E4DC    14000102  // pramPtr.srcBIdx & pramPtr.destBIdx
    0xC309E4E0    C30986F4  // pramPtr.linkAddr & pramPtr.bCntReload
    0xC309E4E4    C3061898  // pramPtr.srcCIdx & pramPtr.destCIdx
    0xC309E4E8    14000102  // pramPtr.cCnt
    0xC309E4EC    0001FFFF  // falsewhile
    0xC309E4F0    C3097A98  // payload
    0xC309E4F4    C3061898  // status
    0xC309E4F8    14000102  // syncType
    0xC309E4FC    C3061898  // Padding due to 16 bit items?
    0xC309E500    00000000      // Padding due to 16 bit items?
    0xC309E504    C30611D8  // Padding due to 16 bit items?
    0xC309E508    C306DA8E  // Return address (according to register B3)
    0xC309E50C    14000102  // Interpreted RA?
    0xC309E510    00000000  // Expected location of RA on previous SP?
    0xC309E514    C3060EF0      // Previous call's first argument

     

    Complete Call stack before corruption:

    Thread [main] (Suspended)   
    0 mcaspSubmitReq(struct ti_psp_mcasp_Mcasp_ChannelObj *, struct ti_sdo_io_DriverTypes_Packet *, struct xdc_runtime_Error_Block *) at mcasp.c:3008 0xc306da84   
    1 ti_psp_mcasp_Mcasp_submit__F(struct ti_psp_mcasp_Mcasp_Object *, void *, struct ti_sdo_io_DriverTypes_Packet *, struct xdc_runtime_Error_Block *) at mcasp.c:1247 0xc308bd64   
    2 ti_psp_mcasp_Mcasp_submit__E(struct ti_psp_mcasp_Mcasp_Object *, void *, struct ti_sdo_io_DriverTypes_Packet *, struct xdc_runtime_Error_Block *) at mcaspDitSample_x674.c:17166 0xc3095de0   
    3 ti_sdo_io_IDriver_submit(struct ti_sdo_io_IDriver___Object *, void *, struct ti_sdo_io_DriverTypes_Packet *, struct xdc_runtime_Error_Block *) at IDriver.h:142 0xc3095fa8   
    4 ti_sdo_io_converters_DriverAdapter_issue__F(struct ti_sdo_io_converters_DriverAdapter_Object *, struct ti_sdo_io_DriverTypes_Packet *, struct xdc_runtime_Error_Block *) at DriverAdapter.c:138 0xc3094c44   
    5 ti_sdo_io_converters_DriverAdapter_issue__E(struct ti_sdo_io_converters_DriverAdapter_Object *, struct ti_sdo_io_DriverTypes_Packet *, struct xdc_runtime_Error_Block *) at mcaspDitSample_x674.c:17318 0xc30962dc   
    6 ti_sdo_io_IConverter_issue(struct ti_sdo_io_IConverter___Object *, struct ti_sdo_io_DriverTypes_Packet *, struct xdc_runtime_Error_Block *) at IConverter.h:150 0xc3095ea4   
    7 ti_sdo_io_Stream_issueX__I(struct ti_sdo_io_Stream_Object *, void *, unsigned int, unsigned int, unsigned int, struct xdc_runtime_Error_Block *) at Stream.c:298 0xc30890e0   
    8 ti_sdo_io_Stream_issue__F(struct ti_sdo_io_Stream_Object *, void *, unsigned int, unsigned int, struct xdc_runtime_Error_Block *) at Stream.c:254 0xc30933d8   
    9 prime() at audioSample.c:455 0xc30724e4   
    10 Audio_echo_Task() at audioSample.c:391 0xc3072324   
    11 ti_sysbios_knl_Task_exit__F() at Task.c:325 0xc308a820   
    12 mcaspSubmitReq(struct ti_psp_mcasp_Mcasp_ChannelObj *, struct ti_sdo_io_DriverTypes_Packet *, struct xdc_runtime_Error_Block *) at mcasp.c:2942 0xc306d8ce   
    13 <symbol is not available> 0xbebebebe   

  • 0 in reply to David Kelly
    TI__Prodigy 185 points

    Thanks for your reply, David. 

    Could you email me the binary?  I should be in a good position to reproduce the issue at that point.

    Chris

  • 0 in reply to Chris_Kelly
    Intellectual 485 points

    What is your email address?

  • 0 in reply to David Kelly
    TI__Prodigy 185 points

    David,

    I've been looking into the callstack issue.  It doesn't look like anything is corrupted on the target, per se, but there may be some inconsistencies in the call stack debugging information for your program, or the interpretation of it: I'm not sure yet.

    I'm continuing my investigation and will post more specifics when I have them.

    Chris

  • 0 in reply to Chris_Kelly
    TI__Prodigy 185 points

    David,

    After some additional analysis, I believe that the issue is a result of the call frame debug information that is found in the example program.  I've filed a defect against our compiler team to track the issue.  The defect number is SDSCM00035528 which can be tracked it on the TI External Bug Tracking site.

    The problem appeared to be specific to the mcasp library that is part of the PSP driver package.  From what I can tell, the code still functions properly, it's just that the call frame information is not being displayed correctly.

    Best regards,

    Chris

  • 0 in reply to Chris_Kelly
    Prodigy 80 points

    Hi Chris,

    i have same problem , at the time of Debug it shows me 0<symbol is not available>0x3ff4fa   so plz give me solution . is there any file missing at linking ...

    thanks in advance