• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 600 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.

Original question:

[K2G] Memory Throughput Analysis does not work with CCSv6.1.3

CCS/66AK2G12: [K2G] Call stack for an exception?

Chuck Peplinski
Genius 5770 points

Part Number: 66AK2G12

Tool/software: Code Composer Studio

I have code that ends up in an exception after a long time running.  It's not all my code, some of it comes from TI.  I'm trying to get more information about what happens before the crash.  I'll describe what I know with my questions.  There may well be several different problems, but the questions are the same.

When either the ARM or the DSP hits an exception, I stop in the debugger.  The ROV can see that an exception has occurred.  An address causing the exception is presented.  But there is no call stack beyond that generated in the exception.  I have also tried to use the ETB to find the call stack on the DSP, but with 15000+ entries it seems only to have the exception handler.  I've tried setting breakpoints in the functions that the exception calls, but I don't hit these.  I haven't succeeded yet to get the ETB on the ARM.  (Unable to load GEL script function Enable_Funnel_For_PTM).

Can you point me at a good example or training post that covers this?  I'm thinking of installing my own exception handler next.

  • 0
    TI__Guru**** 476331 points
    Hi Chuck,
    Sounds like you are using SYS/BIOS. Hence I suspect you are running into the issue described in the thread below:
    e2e.ti.com/.../551666

    There are actually two separate issues. One was fixed, while the other remains open:
    e2e.ti.com/.../2416878

    I suspect yours is the latter, the one filed as CCBT-2200

    Does this sound about right?

    Thanks
    ki
  • 0 in reply to Ki
    Genius 5770 points
    Thanks. It's not resolved yet.
    Background: I am using CCS 6.1.2 and gcc-arm-none-eabi-4_8-2014q3 and SYS/BIOS 6.45.1.29. There are complications to changing these, but I'd consider it if any of them were likely to fix the problem.
    I was able to set a breakpoint at xdc_runtime_Error_raiseX__E, but this still doesn't show the stack from before the exception.
    I was also able to install my own exception handler with a breakpoint inside of it. I hit that first.
    But setting a breakpoint in Exception_excHandler() before it calls my handler did not work. I did not hit that breakpoint.

    So I still don't see the call stack where the exception was triggered on the ARM. I also don't see it on the DSP. But I have more work to do there. How about we confine this issue to the stack trace on the ARM and I'll open separate issues for the other cases.