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.

CCS/RM57L843: Pro Trace Code Coverage Buffer Full

Part Number: RM57L843

Tool/software: Code Composer Studio

Hi,

We're using the XDS560v2 Pro Trace on the RM57L843 in CCS 9.1.0 to obtain code coverage statistics. We can run the trace successfully and obtain some code coverage stats; however, some of our tests are longer and the buffer gets full before the test completes. Thus we lose some of the code coverage stats. We've tried the circular and stop on full buffer modes, but neither help to extend the length of the trace. The circular buffer mode stores the latest trace data and the stop on full mode stores the start of test trace. We've also maxed the buffer size to 1GB. Are there other settings that would allow the Pro Trace to capture a larger trace or to stream the trace or code coverage info in real time or this is too much data?

Also is there any way to automate the Trace execution? I looked at and tested the DSS API a little but couldn't get the trace working, only the debugger. From looking at the forums, it looks like the trace could be automated using the DVT and DSS APIs in CCS 6.2.0, but was then depreciated. Is there another API that we can use to automate the trace code coverage collection? Or is there a way to use a script within CCS to do this?

Thanks,

Titus

  • Titus,

    Titus Appel said:
    Are there other settings that would allow the Pro Trace to capture a larger trace or to stream the trace or code coverage info in real time or this is too much data?

    No. The settings you are using cover all your options for coverage, and I recall that years ago I was unable to go beyond 2GB of Trace buffer data - even still, using this amount of buffer was quite slow to decode and display all this information and I had to close most (if not all) applications other than CCS to avoid any memory exhaustion and consequent lock up. But that could easily be improved nowadays with a larger physical memory. 

    Titus Appel said:
    Also is there any way to automate the Trace execution?

    As you noticed, unfortunately the DSS API set that controlled the DVT interface was deprecated a long time ago and nothing was brought to replace it. I know that some automation is done internally for testing, but it was never released to the public. Sorry.

    From the scripting console and/or DSS, you could potentially set Trace start/stop actions during the execution progress of the code by setting breakpoints that would cause the tool to offload data to the host at given time or execution intervals - unfortunately with the drawbacks that inserting a breakpoint would cause to the normal execution of the program. 

    I will try to think about additional scenarios where you could enhance the data capture and report back in case I find anything relevant. 

    Regards,

    Rafael