Changing Clock Rate of Trace Analyzer to Match Target Board Frequency XDS560v2 Pro Trace

Judy,

The device frequency does not necessarily need to match the trace export frequency (in your case the 36.85MHz). I can test on Monday, but I believe the trace viewer might be calculating time using the export frequency instead of the CPU frequency. If that is the case, you would need to use the cycles column for accurate timing.

As a side note, the export frequency is typically determined by gel files that are device specific.

Thanks,
Mark

Hey Mark, 

I have been calculating the run time using the cycles column and my device frequency of 300MHz which yields better results. However, I am also concerned that the slow trace frequency will miss lines of the code that are executed during the trace. 

For example, when I run a trace analysis, there will be a message " INFO: Trace data contains 3105 gaps or data errors" . The specific number differs each execution but this message is consistent with all traces run.

With an increased number of pins the number of data errors is decreased but not eliminated. 

Judy,

The decreased amount of gaps with increased pins makes sense.  I'm assuming you are running the standard PC trace from Tools->Hardware Trace Analyzer->PC Trace. Just in case, if you are using Custom PC Trace, enabling data trace would increase the bandwidth required for trace (setting is under Hardware Configuration->Type->What to Trace).  You may also try setting the "Stall CPU to prevent data loss" option under Receiver->Receiver Settings->Advanced Options, however, this may be too intrusive.

It doesn't look like there are any gel files to support changing the export clock (specifically the TPIU export).  From your original post, the export is low compared to the CPU clock (300 MHz CPU / 36.8516MHz trace).  In testing a similar device, I'm seeing 39MHz CPU and 79MHz trace.

It might be worthwhile to look into what the clock source for the TPIU is (see section 5.22.8.1 of http://www.ti.com/lit/ds/spns195a/spns195a.pdf). In the meantime, I can ask around to see if anyone has gels to easily configure the TPIU for this device.

Thanks,

Mark

Hey!

I am confirm that I am running PC trace and not Custom Trace.

I've checked the clock source for TPIU link. If I debug using ProTrace, then the value of the EXTCTKOUT[1:0] is '01' -> it means that the ETM clock source is VCLK, which in our case is 75MHz.

Hope that helps

Hey Mark,

Is it possible to eliminate all the gaps in the PC trace? We are trying to make sure the trace is not missing any instructions.
Thanks,

Judy,

Since the increased pin count reduces the amount of gaps in the data, I'm inclined to think the issue is that the device is not exporting data fast enough to the pro trace.  Can you attach the output of a trace log (http://processors.wiki.ti.com/index.php/Emulation_FAQ#How_can_I_turn_on_Logging_for_Trace_for_TI_support.3F) here?

Also, it would be helpful if you could provide a .tdf file (you can generate by clicking the save icon in the Trace Viewer) and an object file in which the gaps are observed.  Having the .tdf and object file will help determine the cause of the gaps in case the issue is not bandwidth related.

Thanks,

Mark

Hey Mark, 

I generated the log files and csv instead of tdf with the 19-pin option. I deleted the function names for confidential purposes but it should still be pretty clear. 

The information in CCS says, that there are 608 gaps - in the csv file there are 608 'FIFO overflow' messages in 'Trace Status' column. So it seems that FIFO overflow is the reason.

Thanks! TraceProblems.zip

Judy,

It is pretty clear that the issue here is bandwidth.  Apart from using a different trace export clock, I don't think there will be a way to remove all gaps for cycle accurate trace for your device.  Another option might be to disable cycle accurate trace in the receiver settings shown below.  This will make all timing information useless but should give enough bandwidth to get a sequence of PC data without any gaps. Hope this helps.

Thanks,

Mark

Also, just to correct/clarify a previous comment, the device I'm testing with is the RM48L952 launchpad which is an R4 core but is similar enough to test trace functionality. For this device, the pro trace calibrates around 39MHz for me (not 79MHz as previously stated). I was unable to get any gaps using 19 pin trace but can see gaps by using only 8 pins. Some other factors that might affect whether gaps show up are software complexity and board layout.

Thanks,
Mark

Hey Mark,

Thanks for your response! Unfortunately, our program is both complex and safety critical. Cycle accurate trace is also important in our current stage of testing. You mentioned that you did not have the gel files to change trace export clock.. Are there other ways to change the trace export clock or are there other sources form which I can find the gel files?

Thanks,

Judy

Judy,

It looks like the only way to change the export clock for this device would be to change VCLK or to use an external clock (ETMTRACECLKIN). I understand both of these may not be possible given that your system is already built. There are no gels readily available to do the programming.

On another note, I do have a test case now in which I can get gaps with 19 pins. I'm going to verify the trace programming and will let you know if I find anything that looks incorrect.

Thanks,
Mark

Hey Mark!

Any luck with finding a way to reduce the gaps with 19 pins?

-Judy

Hi Judy,

I ran some fairly extensive testing with several applications and receiver settings and was unable to find anything incorrect with the ETM programming.  The gaps that I had observed in my previous test case were due to data trace being enabled.  With data trace disabled, I see no gaps at 19 pins for the RM48L592.  Unfortunately, I think this leaves the bandwidth limitation as the culprit in your case.

Thanks,

Mark

Mark,

I'm struggling with the same problem and wonder if changing ETM clock from VCLK to ETMTRACECLKIN will help. However, to change clock source I have to unlock TPIU via the CoreSight key (as described in SPNU563). Could you explain how to unlock TPIU via the CoreSight key?

Thank you,
Piotr

Piotr,

If you are using CCS, you shouldn't have to worry about unlocking or programming the TPIU in this case. The TPIU is programmed by the CCS software before the pro trace calibration routine. The default setting for the TPIU's EXTCTL setting is determined by the value of DEV_CHAR_TPIU_EXTCTL_OUT in the trace device xml (in this case, the corresponding xml file for this device is /ccs_base/emulation/analysis/xmldb/trace_config/devices/device_conqueror.xml). Changing this value to 2 and restarting your debug session should allow to change the clock source. As a side note, I don't have a setup to test the external clock source for this device so I was not able to test.

Thanks,
Mark