The data logger and trace (DLT) peripheral is a key element for non-intrusive data logging with tracing support in application code. This peripheral can be leveraged for both industrial and automotive applications. C29x real-time microcontrollers offer a non-intrusive way to data log critical CPU run time content and provide trace capabilities without additional CPU overhead. This application note focuses on an application use-case described within the introduction, demonstrating each of the features of the DLT along with how to use the SysConfig system configuration tool to set-up and program the DLT. There is additional material on how to setup the DLT visualization tool needed to interpret the data logging and trace contents without the use of external hardware. SysConfig is a tool that exists integrated in Code Composer Studio or as a stand alone program that allows users to generate C header and code files using a graphical user interface (GUI). This application note was done using the F29H859TU8ZEXQL device. However, the content in this application note is applicable to all devices with the DLT peripheral.
All trademarks are the property of their respective owners.
Why is data logging and trace important in real time control systems?
There are many applications that require different uses of using data log or trace features on a device. The DLT provides a way to log critical run time content, and then export out by JTAG, UART, or FSI. If there is no JTAG connection available, the DLT can still be used if there is a UART or FSI implementation to export the data. The lines of code controlling what is being logged can be kept in the application code without impact on CPU performance.
The DLT provides data logging and code flow execution through dedicated instructions provided in the C29x user guide. When using the DLT for data logging variables or adding code flow markers in the application there is additional information attached to each log. The additional information is dependent on what mode the DLT is capturing the logs. The two modes for the additional information added to each log are time stamping or program counter information. In time stamping mode, the DLT provides information of when variables or code markers are being logged. In program counter mode, the DLT provides information to know where these logs are happening.
There are dedicated instructions used to log information. The instructions have the following names DLTAG and DLREG. DLTAGs are used as the code flow markers. DLREGs are the instructions that allow users to data log variables. With the leverage of multiple instructions running in parallel using the C29x processor these instructions can run in parallel and provide non-intrusive behavior when data logging or adding code flow markers to the application code. The co-processor interface (CPI) looks for these dedicated instructions from the CPU and provides the packet information to the DLT which gets logged to a dedicated memory address region for each CPU. The CPU or DMA can read out the logs from the DLT internal memory and move the logged information as needed.
Here is a high level view from going to application code to visualizing the data being logged by the DLT on a PC.
This application note explains the steps needed to configure the DLT, data log, and add code markers using the built in compiler intrinsic. The DLT leverages the compiler and SysConfig to provide the fastest way to get started with using this peripheral.
The use-case that is discussed throughout this application report is using the DLT to record a temperature sensor sample and ADC results within ISR.
As mentioned in the abstract, this application note utilizes SysConfig to configure the DLT peripheral along with the other required components such as visualizing the DLT packets. The SysConfig GUI allows users to walk through the configurations needed to set up the DLT to be ready to start logging in the application code.
The first step to configuring the DLT is setting up the start and stop events to log information. There are two main methods of starting or stopping logged information through the code markers (DLTAGs) or using ERAD events. The third method is security focused and prevents logged information to occur based on the enabled LINK filters. The TAG or ERAD filters control when to start or stop data logging. LINK filters are used to filter out sections of code to data log based on what current LINK has access.
The TAG based filtering has a few options such as the Start Tag Reference, Start Tag Mask, and the end tag configurations. These can be used to start or stop the DLT from logging. The mask is and’ed with the code marker that is reached in the application code. If the and’ed output of the current tag value and the tag filter start mask equals the start tag reference and the tag based filtering is enabled, then the DLT starts logging. The same is true to stop the DLT from logging using the end tags. The start/end tag reference can be any 16-bit value.
Below is a flow chart diagram that explains what happens if users have both TAG based and ERAD based conditions to start or stop logging.
Configuring the start or stop end tags can be any 16-bit value. SysConfig offers a helpful GUI to configure these.
The Enable Tag based Filtering option must be selected. The configurations outlined to configure the start tag reference value and end tag reference value. The Start Tag Mask and End Tag Mask get AND'ed with the respective start or end reference values to control when the logs occur. In the above configuration, 0x5 is the start tag reference value being used and the end tag reference value of 0x20. These values are arbitrary and can be configured with any value. The code generated in SysConfig's board.c file is shown below.
There are two independent modes that can be enabled with the DLT. Each capture mode has a specific format of how the additional information with each log appears in the DLT internal memory. This internal memory acts as a FIFO and is used to store the logs of both code markers and variables. Please refer to the “Interpreting DLT logs” section to understand more about how these logs look between both capture modes.
The first mode is time capture mode where each log contains information of when the log was reached. In this mode, the source of the timers is from IPC counter and DLT’s internal counter. Code markers (DLTAGs) use the IPC as the source and data logged variables (DLREGs) use the DLT’s internal counter as the source. For code markers (DLTAGs), the timer value is called TIMER1 and is going to be sourced from the IPC counter. This time is the absolute time of when the IPC starts. For data logging variables (DLREGs), the timer value is called TIMER2 and is going to be sourced from DLT’s internal counter. This timer value is always the time reference between the previous code marker (DLTAG) that was reached. This can also be thought of relative time between the previous code marker.
The second mode is program counter mode where each log contains information of where the log was reached instead of a timer value. SysConfig provides a way to configure the DLT in either mode at initialization.
There are a few ways to read data from the DLT buffers and write the logs to another location on the device using the CPU or DMA interface. Once the data has been moved, the logs can then be transferred out using any communication peripheral on the device. The DLT has a way to trigger a CPU interrupt or DMA transfer request based on how many logs are in the buffer. Please refer to the FIFO_CONTROL.WR_CTR_TRIG_LEVEL to know what the max trigger level that can be set. The below configuration generates a DLT interrupt when the FIFO reaches 500 logged elements.
The previous sections have described setting up on how to start and end logs, what different modes there are and how to trigger a transfer of the logs to another location based on the trigger level of the DLT. How do users interpret the logs from the internal memory?
There are two terminologies, code markers and variables being data logged. Each of these have a way to interpret the logs from the nternal memory of the DLT. The code markers or DLTAGs must be interpreted slightly differently than the variables being data logged or DLREGs.
The internal memory where the logs are being stored are at the base address of the DLT_FIFO_REGS. The internal memory works like a FIFO. When reading from the FIFO_BUF_H, the next log is pushed up. Thus the order in reading from the FIFO matters. The way to read from this memory mapped register is to read the FIFO_BUF_L contents first, then read the FIFO_BUF_H contents next.
Depending on the capture mode, interpreting the log is different. When reading from the FIFO, the first item to look for is the LSB of the lower 32 bits. This provides information on whether this is a code marker (DLTAG) or a logged variable (DLREG). The rest of the information can be decoded through the tables described in the technical reference manual. For this application note, the DLT tool is used to interpret DLT information when the mode is set to capture the time values.