• Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 2517 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.

Call stack gets lost

Richard Adams
Prodigy 30 points


Has anyone seen an issue with the call stack display in the debug window? What I'm seeing is that when I step into a function The issue appears to be a problem with the call stack logic in Code Composer, there is no real stack corruption.

The displayed call stack is OK at the beginning of function LimeCalibration (LimeCal-514-1.png) but as the first few instruction are executed (LimeCal-514-2.png & LimeCal?-515.png) Code Composer lost track of the call stack before the call to LimeCalibration. During the execution of LimeCalibration (NS_getc-55.png, LimeCal-535.png) the displayed stack is correct for all calls made during LimeCalibration but the display is missing the calls before the call to LimeCalibration. Then I singled stepped through the return from LimeCalibration (LimeCal-547.png) to rf_verify_main (rf_ver-286.png) to the return to main (main-320.png). This verified that the actual stack frame if functioning fine, it's just a Code Composer call stack display issue. Attached files

(Code Composer screen shots of the sequence):

-- LimeCal-514-1.png

 LimeCal-514-2.png

-- LimeCal-515.png

 -- LimeCal-535.png

-- LimeCal-547.png 

 -- LimeCal-547-2.png

-- NS_getc_55.png

-- rf_ver-286.png

--  main-320.png 

  • Prodigy 30 points

    The issue was originally discovered running Version: 5.2.1.00018 on Linux and verified the same results are seen with the latest release on Windows, Version: 5.3.0.00090 

  • in reply to Richard Adams
    TI__Guru**** 173310 points

    Richard,

    Was this code you are debugging compiled with the TI compiler or a Linux gcc compiler? As you said, it does look like the execution and functionality itself is correct, it is just the CCS call stack display information that is sometimes a bit off. This could be due to incorrect call frame debug information generated by the compiler, or due to the debugger misinterpreting the debug information.

    To debug this further though we would need a simple reproducible test case. I'm not sure if its feasible for you to share such a project, but if you can, we could try to get some further analysis done.

  • in reply to AartiG
    Prodigy 30 points

    The ARM code was compiled with the GNU compiler and the DSP code was compiled with the TI compiler (with the gcc option).

    DSP: TI_CGT_6000_7.3.7     --gcc

    ARM: gcc 4.3.3