These days microcontrollers with trace port data rates in excess of 300 Mbit/s are no longer unusual. The time window for sampling the valid data is thus becoming ever narrower. Consequently, small run time differences between the trace channels or other minor faults in the target hardware can easily become a source of errors for the trace recording. As a result, fine tuning of the sampling instant is becoming an increasingly important factor. This is even more crucial, if the application that is supposed to be traced is constantly changing the CPU frequency during the trace capture, as it is commonly done in mobile applications.
Changing the CPU clock frequency will automatically change the clock frequeny of the trace port. Usually changing the trace port frequency will modify the shape of the clock signal, resulting in small changes of the setup and hold times of the trace port. Preprocessors with AUTOFOCUS can take these frequency and timing changes into consideration.
Simply execute the hardware configuration for your highest trace port data rate.
Next reduce the CPU frequency and use the "/ACCUMULATE" option in order to overlay the data eye information from previous hardware configurations with the information obtained from the current run. By doing so the sampling points will be adjusted, all other parameters such as termination and reference voltage remain unchanged.
Repeat these steps for all relevant frequencies. If there is a solution to the problem, in other words sampling points that are valid for all frequencies, the Preprocessor with AUTOFOCUS will find them.
Above is an example for an 8-bit ETMv1.3 trace port with data rates ranging from 200 to 240 Mbit/s in FullRate (data on rising edge only).
Typically mobile applications might change CPU frequencies anywhere from 300+MHz down to the kHz range. Usually the low frequencies are not the problem, but the example shows that this is not true for higher frequencies (usually above 100 MHz)
Introduction
