• Locked Locked
  • Replies 8 replies
  • Subscribers 98 subscribers
  • Views 872 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.

CTools use wrong AET event

Fabian Lindner
Intellectual 880 points
Other Parts Discussed in Thread: SYSBIOS

Hi,

I am using the latest version of the Ctools UClib on a C6678 device. I wanted to use the case: PC Trace - ETB drain via CPU during Exception as described in the documentation.

First it looks all fine. It starting and draining work correctly. But the Tracing is not stopped when an exception is caused, but only when the buffer is drained, which is in general no big problem, since the buffer is usually drained at the begin of the exception handler.

But when I use SYSBIOS exception module with "Exception.enablePrint = true;" there is too much code executed before my custom exception hook (in which the buffer is drained) is called. Thus all I see in the trace data is what happened inside the exception handler, which is in general not so interesting. But the really interesting part of how it has come to that exception is missing. But at least you the CTools UClib provide a great method in debugging the SYSBIOS exception module.

I did some debugging on that and found out that the stop event number was wrong. I changed the following line in ctools_uclib_pct.c:

       PCT_INST->excEndParams.eventNumber[0] = AET_EVT_MISC_EXC;

to        PCT_INST->excEndParams.eventNumber[0] = AET_GEM_EVT_EXCEP;

Now it works. (using AET_EVT_MISC_EXCEP does not work neither)

I still do not understand the problem. Where is the difference between these events? I would appreciate getting some help on this topic.

Regards Fabian

  • TI__Intellectual 2415 points

    Hi Fabian,

    AET_EVT_MISC_EXC - DSP CPU exception acknowledge signal. This signal is asserted whenever the CPU starts handling an exception.

    AET_EVT_MISC_EXCEP - exception signal input to the DSP CPU. This signal will not be asserted for internal CPU exceptions, only external exceptions will be captured.

    The main reason for using AET_EVT_MISC_EXC instead AET_EVT_MISC_EXCEP is to capture both internal CPU and external exceptions. In keystone devices, there are 4 possible type of exceptions:

    1) Nonmaskable Interrupt (NMI)
    2) Exception (EXCEP) - external exception
    3) Internal Exceptions
    4) SW generated exceptions
    For more details, please, refer to TMS320C66x DSP CPU and Instruction Set Users guide (SPRUGH7, Chapter 7: CPU exceptions): http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sprugh7&fileType=pdf
    It would be very helpful, if you can elaborate more about the failure you are reporting. What kind of exception is being generated here? Please, share the details printed on the console by the BIOS exception handler? Please, provide the .tdf (generated from the .bin file captured inside exception handler) used to get the decoded DSP trace data?
    Thanks,
    Karthik.
  • in reply to Karthik Ramana Sankar
    Intellectual 880 points

    Hi thanks for the answer.

    Karthik Ramana Sankar said:
    The main reason for using AET_EVT_MISC_EXC instead AET_EVT_MISC_EXCEP is to capture both internal CPU and external exceptions. In keystone devices, there are 4 possible type of exceptions:

    Ah ok that's right with the _EXCEP setting, the logging does not stop at internal exceptions. OK so far I understand you.

    But I have a different problem. When I use:

    • AET_EVT_MISC_EXC (which works on internal exceptions too) respectively AET_EVT_MISC_EXCEP (which works only on external exceptions)
      • the tracing is not stop (neither on internal nor on external exceptions)
    • AET_GEM_EACK (which works on internal exceptions too) respectively AET_GEM_EVT_EXCEP (which works only on external exceptions)
      • the tracing is stopped correctly

    I tried this with all kinds of exceptions:

    • external: memory Protection e.g. invalid read access: int test = *(volatile int*)0x00000000;
    • internal: instruction fetch exception: e.g. "MVC 0, A4 ;   B     A4"

    The only thing I don't understand:

    Why does it work with AET_GEM_EVT_EXCEP and not with AET_EVT_MISC_EXCEP ?

    Why does it work with AET_GEM_EACK and not with AET_EVT_MISC_EXC ?

    Where is the difference between these?

    Regards Fabian

  • in reply to Fabian Lindner
    TI__Intellectual 2415 points

    Fabian,

    Both AET_GEM_EVT_EXCEP and AET_EVT_MISC_EXCEP are the same.

    AET_EVT_MISC_EXC comes from the CPU and indicates that an exception is currently processing.

    AET_EVT_MISC_EACK is derived from INUM and IACK signals that either EXCEP or an NMI interrupt has been acknowledged by the CPU.

    For stopping trace immediately on the occurrence of an exception, one could use either AET_EVT_MISC_EACK or  AET_EVT_MISC_EXC.

    In my examples, I have no issues with using AET_EVT_MISC_EXC event for stopping trace exactly on the occurrence of the exception. I am too using SYSBIOS exception handler.

    Which keystone device are you working with? In your case with AET_EVT_MISC_EXC, where the trace is not stopped correctly, do see the code executing the BIOS exception handler? Is exception handling enabled (TSR GEE bit set to 1)?

    Thanks,

    Karthik.

  • in reply to Karthik Ramana Sankar
    Intellectual 880 points

    Thanks for the quick reply.

    I'm working on C6678.

    Yes the exceptions are enabled and I see the BIOS exceptions handler being executed in both cases. TSR GEE bit is set. The exception is totally correctly processed.

    Just with AET_GEM_EACK Tracing is stopped

    But with AET_EVT_MISC_EXC Tracint is not stopped

    If both events are basically the same I don't understand why it's not working with the original one. Do I need to explicitly enable MISC events somehow?

    Regards Fabian

  • in reply to Fabian Lindner
    TI__Intellectual 2415 points

    Fabian,

    I don't think we need to explicitly enable MISC events. They should be enabled by default.

    For the AET_EVT_MISC_EXC case, can you put a break point at ti_sysbios_family_c64p_Hwi1 (exception handler) and check if the TSR.EXC bit is set to '1'. You can find Task State Register (TSR) in Registers --> Control Registers.

    Thanks,

    Karthik.

  • in reply to Karthik Ramana Sankar
    Intellectual 880 points

    Yes the TSR.EXC bit ist set to '1'. I've just verified this.

    I think otherwise the AET_GEM_EAC event wouldn't be triggered. It's just that the GEM events work and the MISC events don't.

    Regards Fabian

  • in reply to Fabian Lindner
    TI__Intellectual 2415 points

    Fabian,

    I am not able to reproduce this strange behavior on my C6678 EVM. It would be very helpful to debug this issue, if it is possible for you to share the CCS project (or) application code which is consistently showing the trace not to stop on MISC events.

    As AET_GEM_EACK event works well in your case, I assume this issue is not blocking your progress. Please, let me know if otherwise?

    Thanks,

    Karthik.

  • in reply to Karthik Ramana Sankar
    Intellectual 880 points

    Karthik Ramana Sankar said:
    As AET_GEM_EACK event works well in your case, I assume this issue is not blocking your progress. Please, let me know if otherwise?

    That's right. With this workaround the issue is not blocking at the moment.

    Karthik Ramana Sankar said:
    I am not able to reproduce this strange behavior on my C6678 EVM. It would be very helpful to debug this issue, if it is possible for you to share the CCS project (or) application code which is consistently showing the trace not to stop on MISC events.

    I'll cannot provide you my whole application code, but I can try to make you a reduced project to reproduce the error. I just need some time for this.

    Regards Fabian