HOWTO: Start Trace with S32 Debugger and S32 Debug Probe on S32G2xx
Trace functionality is supported in the S32 Debugger for A53 as well as M7 cores on the S32G, RAM-target builds. With Trace, you can record some execution data on an application project and then review it to determine the actions and data surrounding an event of interest.
This document outlines the method to begin using Trace on the S32G2xx device. We start by creating a project on which to execute the trace, however, you may start at step 2, if you are starting with an existing project. Please note, you will need to have debug configurations for the S32 Debugger setup for each core which you intend to capture trace. If you do not already have such configurations, you may copy them from another project and adapt them to the new project as shown in HOWTO: Add a new debugger configuration to an existing project.
Create a new application project, selecting the 'S32G274A_Rev2 Cortex-A53', or the M7 variant. For this example, we are using the A53 screenshots and 'S32 Debugger' options.
There should now be 4 new application projects in your workspace. One for each A53 core. The first core of the S32G274A, A53_0_0, is also a possible boot core, so this project will have build configurations for RAM and FLASH. The other A53 cores (0_1, 1_0, 1_1) will not. Build all projects for Debug_RAM and check that they build clean before proceeding. Building the A53_0_0 project will build all projects and the resulting ELF file will contain the output of all 4.
Open 'Debug Configurations...' and select the 'Debug_RAM' configuration for the first core (A53_0_0_Debug_RAM_S32Debug). Switch the initialization from the default s32g2xx_generic_bareboard.py script to s32g2xx_generic_bareboard_all_cores.py in order to make the trace modules accessible. Select the 'Debugger' tab. Enter the Debug Probe Connection settings as appropriate for your hardware setup. Click Apply.
Now select the Launch Group configuration for 'Debug_RAM'. It is important to use the launch group to start the debug for each core, not just because it makes it easier, but also because it is necessary to allow for some delay after the first A53 core is started before bringing the other A53 cores from reset to debug state. Press Debug
Once the code is loaded to the target and the debugger has started each core and executed to the first line within main(), then it is ready to perform any of the standard debug functions including Trace. Trace does not start automatically, it must be turned on before it will start logging data. To do this, it is necessary to add the view 'Trace Commander'. It can be found by either Window -> Show View -> Other, then search for 'Trace Commander' or enter 'Trace Commander' in the Quick Access field of the toolbar and select Trace Commander from the list.
The Trace Commander view will show in the panel with the Console, Problems, etc. Double-click on the tab to enlarge it. From the dropdown with the XML configuration files, select one matching your debug project name. A configuration is generated if none is present for your debug launch the first time you open it in the debug configuration view.
Click on the configure button to change settings.
Click on the Advanced Trace Generators configuration button
For each core to be logged, set the associated ELF file. Select the core, click Add, then '...', and select the elf file for that core. It is recommended to disable all cores that are not required to be traced, as they may funnel in the same buffer, occupying the limited memory.
Select Data Streams. Now it is possible to change how the data is captured. Since the buffers have finite memory, they can be set to collect data until full, or to overwrite. If set to One buffer, the data will be collected until the buffer is full, then data collection stops. It is useful to gather data when starting logging from a breakpoint to gather data during execution of a specific section of code. If set to Overwrite, the data collection continues and starts overwriting itself once the buffer is full. This is useful when trying to gather data prior to a breakpoint triggered by a condition.
To turn on the Trace logging, click on the 'Close this trace stream' button.
The Trace is now enabled. To collect trace data, the cores must be executing. First double-click the Trace Commander tab to return to the normal Debug Perspective view. Then, one by one, select the main() thread on each core and press Resume to start them all. If collecting from a breakpoint, start the code first with Trace disabled, wait for the breakpoint to be reached, then enable the Trace.
Allow the cores to run for a period of time to gather the data, then press Suspend on each one until they are all suspended.
Look to the Trace Commander tab to see that the data icon is no longer shaded and click on it to upload the trace data.
A new tab, Analysis Results, has appeared. Double-click this tab to see it better. Click on the arrow next to ETF 0 to show the data collected in the trace buffer.
Notice there are 5 separate views on the captured data: Trace (raw data), Timeline, Code Coverage, Performance, and Call Tree.
Trace - this is the fully decoded trace data log
Timeline - displays the functions that are executed in the application and the number of cycles each function takes, separate tabs for each core
Code Coverage - displays the summarized data of a function in a tabular form, separate tabs for each core
Performance - displays the function performance data in the upper summary table and the call pair data for the selected function and it's calling function
Call Tree - shows the call tree for identification of the depth of stack utilization
See the S32DS Software Analysis Documentation for more details on settings, ways to store the logged data, etc.
View full article
