This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RDDI Trace Clock Error

Hello,

I am writing a program using the RDDI API to stream trace from a DSTREAM-ST. The problem is that whenever I start up the DSTREAM-ST and then connect using RDDI from my program, the connection works fine, but once I begin tracing, the TRC_CLK light comes on and I don't get any events. However, if I connect using DS-5 first, disconnect in DS-5, close DS-5, and try to run the program again, the TRC_CLK  light is green and everything works (I get events and trace data, etc.). I can then run my program as much as I want until I turn the DSTREAM-ST off again. I cannot figure out why this occurs, and none of the RDDI functions in the API mention a trace clock. How do I sync the trace clock? Any ideas?

- Akira

Parents
  • Hi Akira,

    My guess is that when DS-5 connects to your target it configures the RM57 CoreSight trace components to enable and route trace to the external trace connector. Hence trace works fine for DS-5 and for an RDDI-Trace program from then on. However from a target reset, without DS-5 connecting, when you run your RDDI-Trace program, the CoreSight components have not been configured and so no trace is being generated.

    The RDDI-Trace API just deals with receiving trace data from a trace capture device. In your case the trace capture device is the DSTREAM box. When DS-5 connects to the RM57 it will use the RDDI-Debug API to configure the CoreSight devices (ETM, Funnels, TPIU...) to generate the trace data and then use the RDDI-Trace API to receive the trace data.

    If my guess is correct, you have three choices:

    • Always run DS-5 prior to your own program ;-)
    • Extend your own program to use RDDI-Debug to configure the CoreSight components
    • Use a DTSL program which uses the DS-5 configuration files (and so gets the target configured) and then processes the trace data itself. Actually you have two sub-options here;
      • Write a small DTSL program which just connects/disconnects to the target (as if DS-5 had connected/disconnected) and then run your existing native RDDI-Trace program
      • Port your RDDI-Trace native program to be a DTSL (Java or Jython) program

    I realise there is quite a lot to digest here, so if you think my analysis is correct and need more specific help, just let me know.

    Regards Tony

Reply
  • Hi Akira,

    My guess is that when DS-5 connects to your target it configures the RM57 CoreSight trace components to enable and route trace to the external trace connector. Hence trace works fine for DS-5 and for an RDDI-Trace program from then on. However from a target reset, without DS-5 connecting, when you run your RDDI-Trace program, the CoreSight components have not been configured and so no trace is being generated.

    The RDDI-Trace API just deals with receiving trace data from a trace capture device. In your case the trace capture device is the DSTREAM box. When DS-5 connects to the RM57 it will use the RDDI-Debug API to configure the CoreSight devices (ETM, Funnels, TPIU...) to generate the trace data and then use the RDDI-Trace API to receive the trace data.

    If my guess is correct, you have three choices:

    • Always run DS-5 prior to your own program ;-)
    • Extend your own program to use RDDI-Debug to configure the CoreSight components
    • Use a DTSL program which uses the DS-5 configuration files (and so gets the target configured) and then processes the trace data itself. Actually you have two sub-options here;
      • Write a small DTSL program which just connects/disconnects to the target (as if DS-5 had connected/disconnected) and then run your existing native RDDI-Trace program
      • Port your RDDI-Trace native program to be a DTSL (Java or Jython) program

    I realise there is quite a lot to digest here, so if you think my analysis is correct and need more specific help, just let me know.

    Regards Tony

Children
  • Hi Akira,

    I have something extra to add in addition to Tonys' wisdom. He is right, you do indeed need to set up the trace links that route the trace from the Cortex-R5 ETM through the trace Funnel component.  It's port 0 that you need to enable. Writing 0x301 to 0x8000B000 on the debug APB (this address is the first register of the trace funnel on the RM57 HDK and its the control register) should set the funnel up.

    However, this won't enable the trace clock, because that requires an additional write to the Trace Port Interface Component (TPIU) on the target. If you have a look in the DTSL script for the target configdb entry in DS-5 all should be revealed for you.

    However, are you sure your connections via RDDI immediately after power on are actually working ?

    The reason I ask is that the TI devices typically have an 'ICEPick' device that restricts access to the JTAG scan chain unless some proprietary JTAG scans have been performed in order to expose/add the arm Debug Access Port to the JTAG scan chain.

    If you are using DS-5 then all this is done for you, but as you are not, you need to be aware of this.

    This could be another reason why your example only works after DS-5 has been used to trace the target.

    I hope this helps and we look forward to hearing how you get on.