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.

Debugging ti.sysbios.family.c64p.Exception assertions failure: no stack trace

Other Parts Discussed in Thread: SYSBIOS

I have a C66x DSP application built with Compiler 7.3.4, XDC tools 3.24.5.48, SYS BIOS 6.32.5.54.

It crashes occasionally with ti.sysbios.family.c64p.Exception: line 248. I do not get a stack trace enough to trace the problem to the offending code in my application. 

I found that it is not possible to get the trace to the application _after_ the assertion is raised due to compiler optimizations and design of XDC Error module:

http://e2e.ti.com/support/embedded/tirtos/f/355/p/111568/397997

 I also found an article about how to address the issue about the missing trace :

http://processors.wiki.ti.com/index.php/GateMutex_Assert

This article is only applicable if the assertion is of GateMutex type, because the solutions relies on checking the BIOS threadThreadType to be a SWI or HWI before the assertion is raised from the GateMutex code.

The CPU core that crashes in my application never runs a SWI or HWI. In my case, the assertion is not GateMutex, but some other c64pException (mentioned above). in this case, where do I set a breakpoint to halt the CPU before the assertion to get a trace back to the application? 

thanks

  • If you add this to your .cfg file:

    var Exception = xdc.useModule('ti.sysbios.family.c64p.Exception');
    Exception.enablePrint = true;

    a complete exception register context should be dumped to the console in addition to the Error raised by the exception handler when an exception occurs.

    If you set a breakpoint at "ti_sysbios_family_c64p_Hwi_int1", this is the function vectored to on all exceptions. No exception processing will have been performed at this point. Using CCS' register dump, you can see the complete state of the processor. The NRP register should contain the PC at the time the exception occurred.

    Alan