winIDEA Help

In this topic:

•Step 1: Setup OS and RTE

•Step 2: Generate instrumentation and Profiler XML

•Step 3: Allocate SWAT buffer

•Step 4: Integrate and rebuild code

•Step 5: Configure winIDEA

•Synchronized trace

•Recording between arbitrary points

 

 

Introduction

This section guides you through the configuration steps necessary to use SWAT.

 

For introduction details, refer to Software Trace Tool (SWAT).

 

 

Step 1: Setup OS and RTE

This step depends on the OS and RTE vendor. Depending on your application, follow the sections in Profile Vector MICROSAR how-to guide to record:

•Vector MICROSAR Tasks and ISRs - Enable ORTI and OS Timing Hooks in DaVinci Configurator.

•Runnables using the Vector RTE - Enable the VFB Trace Hooks in DaVinci Configurator.

 

Once you have reached the section where iTCHi is used, return to this how-to guide.

 

 

Step 2: Generate instrumentation and Profiler XML

Follow the steps below for iTCHi to generate:

•Instrumentation code for Threads, Runnables, and Signals

•Configuration file swat_config.h  for the SWAT

•Configuration file profiler.xml configuration file for winIDEA to decode data

 

 

Point ORTI file location to your ORTI file.

 

•Vector MICROSAR Tasks and ISRs - Enable Task/ISR (Thread) Tracing and select task_state_swat_microsar.

•Runnables using the Vector RTE - Enable Runnable Tracing and select runnable_swat.

•Signals (arbitrary data events) - Enable Signals and select signals_swat.

 

 

Depending on the commands you have selected, one or more of the following sections is available:

•swat

•task_state_inst_microsar

•runnable_instrumentation

•signals_swat

 

swat

This section includes Software Tracing specific configuration options. Keep the default values.

•swat_config_h - Use this attribute to generate the swat_config.h header file directly into the include directory of your application. Do not to change the name of the file, only the directory may be adapted.

•time_address - Configure for synchronized tracing, i.e. tracing of SWAT in combination with other trace sources such as mDIO or hardware trace on a second ECU. It should match the memory mapped counter address used by the SWAT_STORE_TIMESTAMP macro.

 

The other sections must be updated depending on your OS and RTE vendor.

 

 

task_state_inst_microsar

•vector_os_timing_hooks_h - Confirm that is set to record Vector MICROSAR Tasks and ISRs. This file is generated and implements the Vector OS Timing Hooks so that they call the SWAT observer API. This file must be included in the include directory of your Vector MICROSAR project. You can:

oUpdate this path to directly generate the header file into the directory.

oGenerate it in a different location and copy it later manually.

•vector_os_timing_hooks_c - This file is not essential for software tracing, and it is not necessary to integrate it into the project.

 

All other options in this section can be left as they are (The attribute instrumentation_type is implicitly set to swat).

 

runnable_instrumentation

•rte_hook_h - Point to the Rte_Hook.h file (generated by the DaVinci Configurator) to record Runnables using the Vector RTE.

•impl_vfb_hooks_c - Specify the directory and name of the C file that implements the RTE Runnable hooks. This file must be included and built by the project. You can:

oGenerate this file directly into the source directory of your Vector MICROSAR project.

oGenerate it in a different location and copy it later manually.

 

All other options in this section can be left as they are.

 

signals_swat

signals - Add the name of the signals (arbitrary data events) and their type in order to record them. The name is used to display the signal in the timeline. The support types are currently u8 and u32.

 

In contrast to Threads and Runnables, iTCHi cannot automatically generate the observer points for these custom signals. Refer to swat_config.h to see how you can manually add the observer calls to the code. For example, for the signal g_dwCounter, you would add the following snippets to the locations in your code where you want to log its value:

 

 

This generates the required files after adapting all required attributes. For example, for Vector MICROSAR Thread and Runnable tracing, it will generate the following files:

•Os_TimingHooks_winidea.h - Header file that implements the Vector Timing Hooks.

•swat_config.h - File that contains the encoding masks for your project.

•rte_vfb_impl.c - Source file that implements the Runnable instrumentation.

•profiler.xml - Configuration file used by winIDEA to decode the data.

 

Here is an example output of a successful iTCHi SWAT run:

 

 

Step 3: Allocate SWAT buffer

SWAT uses a single global structure called SWAT_ring to maintain its internal state and to reference the buffer that stores the trace messages. Special care has to be taken:

1.That the structure is allocated in memory that is read- and writable by the application and the debugger

2.That the structure is allocated in uncached memory

3.That an active MPU is configured in a way that permits access to the structure from all relevant contexts

 

The correct memory for SWAT_ring depends on the SoC architecture, and the correct way to allocate it to that memory depends on the build system in use. For Infineon AURIX SoCs, the structure should be allocated to global uncached LMU RAM (usually the 0xb00x’xxxx memory range).

 

The correct approach is highly specific to the build environment used by the project. Pick one of the following approaches or use the features of a project-specific build environment to allocate the SWAT structure into globally accessible RAM:

 

In case of an MPU, all contexts that generate software trace messages by calling the SWAT observer API must have access to the SWAT structure:

•For observing Task and ISR events using OS hooks - Access from the OS context must be enabled.

•For Runnables - Access from the enabled VFB trace hooks must be enabled.

•For signals - Access from all manually added signal observer calls must be feasible.

 

 

Step 4: Integrate and rebuild code

To integrate software tracing into your project, you have to add the generated files, as well as the files from the target-code directory to your software build.

In general, C source files should be added to one of the source directories of the project, and header files to one of the include directories. Depending on the build environment, C files might have to be explicitly added to the build. For example, when using Vector MICROSAR Makefiles, the following code could be used to add the C files to the build:

 

Ensure the appropriate swat_buffer_arch.h file is included for your target architecture:

•Set the SWAT_ARCH and SWAT_OS variables when using CMake to select the target architecture and operating system.

•Use the -I flag to specify the architecture-specific directory (e.g., -I./arch/tricore for TriCore targets)

 

 

 

 

•Generated files:

oswat_config.h

orte_vfb_impl.c (if Runnable tracing is enabled)

oOs_TimingHooks_winidea.h (if Vector MICROSAR Thread tracing is enabled)

•Static files from the target-code directory:

oswat_buffer.c

oswat_buffer.h

oswat_observer.c

oswat_observer.h

•architecture and OS specific files. For example, for Vector MICROSAR running on an Infineon TriCore microcontroller add these files:

oarch/tricore/swat_buffer_arch.h

oos/microsar/swat_observer_microsar.h

 

The source files are now referenced by the build system, and the trace variable has been properly allocated.

 

 

a.Download and run the application.

b.Open SWAT_ring in the Watch window.

c.Confirm that data is being added to the buffer.

d.Confirm that SWAT_ring.header has been initialized.

 

After you run the application for a few milliseconds, data should be added to the buffer and the index variables should change.

 

 

 

Step 5: Configure winIDEA

To configure winIDEA with the generated profiler.xml file, select the following options:

•RTOS description file type - winIDEA OS Info XML.

•RTOS description file location - Location of the profiler.xml file.

 

a.Configure:

oFor Arm-based SoCs:

i.Set Operation mode to SoC.

ii.Go to Hardware | CPU Options | SoC and set Trace Capture method to None.

oFor all other architectures set Operation mode to None.

b.Set the correct Cycle duration.

 

For Infineon AURIX, refer to Clocks to configure the Cycle duration.

 

 

After configuring profiler.xml, you can now use the winIDEA Analyzer to record and profile the instrumentation data.

 

•SWAT_Config

•Threads

•Runnables

•Custom signals (if applicable)

 

You can trace from Reset by starting the recording first and then the Target, or you can also start recording when the application is already running.

 

If everything is set up correctly:

•The status field should display   SAMPLING   with an increasing number indicating how much data has been recorded.

•After a few seconds, the Profiler Timeline should start to populate with Thread and Runnable data.

 

 

 

Synchronized trace

Software Tracing has the ability to record synchronized traces with multiple trace sources. For example, it is possible to record via SWAT (for one ECU), hardware tracing (for a second ECU), and mDIO (for I/O pin states) into a single, synchronized trace, which means all events share a common time base.

To configure Synchronized Tracing, follow these steps:

 

This is done via the time_address attribute in iTCHi, swat section. For example, for Infineon AURIX, STM0.TIM0 is used, which has the address 0xF0001010.

 

 

 

Synchronized Tracing of SWAT in combination with other trace sources is now possible. Refer to Sync Trace for more information.

 

 

Recording between arbitrary points

A common use case is to measure the time between two arbitrary points in the code. These two points could be located inside the same function (to measure the execution time of a specific code block) or in totally different modules (to measure the propagation delay of a value from one point to another). SWAT supports measurement of such scenarios via signals.

Follow these steps to configure signals:

 

 

The new signal does not actually have to exist in the code. For example, it could just be called a_b_measurement.

 

 

 

Integrate it into the project following the regular guide. Reference the bottom of swat_config.h to verify that the configuration for the signal has been created:

 

You are now ready to integrate the observer call into your code. Let’s say you want to measure the time of a specific code block in the function example_function_timing. Make the observer API visible by including swat_observer.h. You can then create signal events as shown below. The first argument to the SWAT_observe function is the value that the signal should take, and the second argument is the ID of the signal.

 

You can then select the Profiler object for the a_b_measurement signal in the winIDEA Analyzer. If the code has been integrated correctly, and the function is executed, you can see in the timeline that a_b_measurement changes to 1 whenever the code block starts to be executed and back to 0 after it has finished execution.

 

 

More resources

•Trace Configuration

•OS Profiling