winIDEA Help

In this topic:

•Running Task/ISR

•Running Task/ISR tracing with BTF Export

•Running Task/ISR Sampling

•Task state tracing with single state variables

•Task state tracing with complex state native

•Task state tracing with instrumentation

•Runnable tracing with instrumentation

•Running Task/ISR tracing with OS Signaling (not supported)

•Runnable program flow

•Signals

•Spinlock with instrumentation

•Software Tracing

 

 

Introduction

This topic explains the available Trace Configuration Helper commands and their configuration attributes. Each of the commands requires at least an orti_file and a profiler_xml_file in your itchi.json file. If you do not have at least two attributes in your configuration read through the Basic configuration steps first.

 

It is possible to combine multiple commands for a single call to iTCHi. For example, if you want to trace tasks and Runnables you can combine the --running_taskisr command with the --runnable_instrumentation command.

 

If you have an existing Profiler XML file, iTCHi will only change the XML attributes related to the current command. For example, if you have received a Profiler XML that configures Task state tracing you can add Runnable tracing and iTCHi will leave the existing configuration as it is.

 

You can also specify commands via the commands attribute in the itchi.json. Generate the iTCHi default configuration file via --write_default_config and then change the desired command attributes under commands to true. These commands will always be active in addition to the ones specified via the command line.

 

 

Running Task/ISR

A Running Task/ISR trace records the currently running Task and ISR for each CPU core that runs an OSEK/AUTOSAR OS. This is the most basic form of tracing. Using the Profiler XML with this command is similar to using the ORTI file by itself. However, there are two reasons why it might still be necessary to use iTCHi to generate a Profiler XML:

•Missing default Task or ISR attribute

•Running Task or ISR expression containing pointers. For these cases add the following JSON object to your iTCHi configuration file:

 

 

Default Task/ISR

ORTI specifies that the Running Task and the Running ISR2 attributes contain a value NO_TASK and NO_ISR respectively. These are the default values when no other task or ISR is active. winIDEA needs to be aware of these values to properly analyze a trace. However, some operating systems do not follow the notion of NO_TASK / NO_ISR. In that case winIDEA might complain about a missing default Task or default ISR (no default IRQ). To work around this issue it is possible to specify a default Task and ISR via the iTCHi configuration file. For example, the new default task could be BackgroundTaskCore0.

 

iTCHi uses the following steps to decide which default Task and ISR is written into the Profiler XML file:

1.If a default ISR2 or Task is specified in the iTCHi configuration, it is used.

2.If NO_ISR / NO_TASK is found in the ORTI file, it is used.

3.If INVALID_ISR / INVALID_TASK is found in the ORTI file, it is used.

4.Otherwise, the last element in the RUNNINGTASK / RUNNINGISR2 declaration is used.

 

 

Task/ISR expression with pointer

If the running Task or running ISR expression contains a pointer winIDEA might not be able to resolve the address. In this case, iTCHi prints a warning and the expression can be changed via the configuration file. This makes sense for some operating systems where the running Task or ISR is accessible via a pointer, but also via a static symbol.

 

For example, if instead of OS_kernel_ptr[0]->isrCurrent the expression (OS_kernelData_core0).isrCurrent should be written to the Profiler XML file you can add the following two-item lists to the search and replace list:

 

Please note that the search_replace_list must be a JSON object where the value replaces a specific key. iTCHi will iterate over the items and replace each key with the respective value for both the running Task and the running ISR expression.

 

 

Update AUTOSAR to physical core mapping

On SoCs with multiple Cortex-M and Cortex-A cores you might run into the situation that the AUTOSAR cores in the ORTI file do not match the physical cores in the real-world. For example, you might have only one AUTOSAR core that runs on the physical Cortex-M core of your SoC. That Cortex-M core might have the ID 3, in that case you would update the mapping as shown in the following listing:

 

 

You might also want to rename a specific (ORTI) core to a more expressive name. For example, if you know that the ORTI core 0 on a NXP/ST Power Architecture device has the name CPU2, then you could use the following mapping:

 

 

Running Task/ISR tracing with BTF Export

In addition to writing the information for a running Task/ISR trace this command also adds the necessary information for a BTF Export to the Profiler XML. This works by creating pseudo states for all Task and ISR profiler objects that are used by the BTF export algorithm to create the respective BTF events. The command uses the same configuration attributes as the regular Running Task/ISR command.

 

 

Running Task/ISR Sampling

There are cases when OS and RTE profiling is not feasible because hardware tracing is not available. In such cases, winIDEA Profiler Sampling can help you get an approximation of your Task and ISR load based on sampling (periodically reading) the Running Task and ISR variables.

 

 

iTCHi can help you to create the correct Profiler XML for this use case. First, you need to create a default iTCHi configuration file that includes the orti_file and profiler_xml_file attributes, as explained in the Running Task/ISR section.

 

Then you can run iTCHi with the --running_taskisr_sampling command.

 

 

Now, point winIDEA to the generated Profiler XML file and open the Analyzer. Under Profiler OS Objects, you should find the Running Task/ISR objects with (SAMPLING) at the end. Make sure only to select these objects and start a recording.

You should now see the Task and ISR sampling data for the selected objects.

 

 

Task state tracing with single state variables

For Running Task/ISR profiling there is no indication for why a task switch occurs. Different reasons for task switches are preemptions, waiting for events and terminations. ORTI specifies a STATE attribute for each task object to make this information accessible. The STATE attribute can either be a single variable or a more complicated expression consisting of multiple variables. The string OS_taskTableBase[27].dynamic->state is an example for a single variable (though the pointer is problematic), whereas the following string is considered a complex expression:

 

 

If the task states in your ORTI file use complex expressions skip to Task State Tracing with Complex Expressions.

This command creates the Profiler XML suitable for state tracing with a single variable for each task. ISRs are still traced via RUNNINGISR2 and the configuration from Running Task/ISR applies.

For single core applications creating the Profiler XML from the ORTI file works automatically. For multi-core applications additional configuration is necessary because the ORTI file does not specify a core index attribute for tasks. There are different ways to specify the core indices in the iTCHi configuration file. If you are using a multi-core application add the following object to your configuration file:

 

There are three ways to get the task to core mapping:

•Specify the core fore each task explicitly.

•Reference an Os_config.h or Mk_Gen_Config.h file. This is the recommended way if you use the EB tresos AutoCore OS.

•Use a heuristic to extract the core ID from the STATE expression.

 

 

 

Manually define task to core mapping

The attribute task_to_core_mapping points to a dictionary that maps from task names to core indices. iTCHi sets the core index for each task based on this mapping. If no mapping is available for a certain task iTCHi defaults to 0 and logs a warning. iTCHi does not report a mapping for a non-existent task.

The following shows an example mapping that maps task_a and task_c to core 0 while task_b is allocated to core 3:

 

 

Extract mapping from EB tresos AutoCore OS Os_config.h file

If using EB tresos AutoCore OS, you can point the autocore_os_config_h attribute to the Os_config.h file of their application. This file includes a structure with the core index as well as a non-pointer version of the state variable for each task.

For newer versions of EB tresos AutoCore you might want to specify autocore_mk_gen_config_h instead. It depends on the exact version and chip architecture you are using.

 

 

iTCHi heuristic feature

iTCHi can try to find the core for each task. If task_to_core_heuristic is set to true, iTCHi scans the task state formula with the regular expression [Cc]ore_?(\d+). If the formula matches the regular expression iTCHi assigns the respective number (\d+) to the task. If the regex does not match iTCHi assigns the core 0 to the task and logs a warning.

 

 

Task state tracing with complex state native

For complex state variables (ORTI STATE attributes consisting of more than one variable), the winIDEA Analyzer has the capability to reconstruct the task states if all variables in the state formula are part of the trace recording.

This feature uses the iTCHi configuration options from the Running Task/ISR sections to remap AUTOSAR cores and remove pointers from the Running TASK or ISR expressions.

 

The following snippet shows the iTCHi configuration for this command:

 

 

 

Constant variables

The STATE expressions of some operating systems contain variables that are only written once at the start-up of the application. If that initial write event is not traced, the Profiler Inspectors cannot reconstruct the task state. To avoid this issue such variables can be set to a constant value. For example, consider the following expression:

 

In this example the OsState is only initialized to 2 once when the application starts to execute. If that write is not recorded the expression as a whole cannot be evaluated. In this case, it is best to define that variable as a constant via constant_variables. This attribute is a dictionary that maps from variable names to integers:

 

 

Task state tracing with instrumentation

This command utilizes the OS hooks to generate Task and ISR events by either writing into a global variable or using an instrumentation trace technique (such as RH850 Software Trace (SFT)).

Task state tracing is currently supported for the Vector MICROSAR OS via the --task_state_instrumentation_microsar command and for EB tresos AutoCore OS via --task_state_instrumentation_autocore.

 

Vector MICROSAR

For MICROSAR, the following configuration section is required:

 

iTCHi supports different types of instrumentation. Set the instrumentation_type attribute to data_trace, stm_trace, or software_trace depending on the approach you are using. This will also effect the generated instrumentation files:

•For data_trace, use trace_variable to specify the name of the trace variable.

•For stm_trace, use stm_base_address and stm_channel to specify the respective values. Both values must be hex-strings, i.e., start with 0x.

•For software_trace, use db_push_register to specify the DB push register.

 

 

Elektrobit tresos AutoCore

For tresos AutoCore the following configuration section is required:

 

 

Runnable tracing with instrumentation

Runnable tracing is an important feature to get deeper insights into the behavior of an application. Runnables can be traced via program flow trace or via instrumentation utilizing data trace. While program flow trace works without instrumentation, it produces short trace durations for most setups. Instrumentation-based tracing is good compromise as it generates significant longer traces while keeping the instrumentation as minimal as possible.

Instrumented tracing works by utilizing the VFB trace feature of the AUTOSAR RTE. VFB trace enables you to generate instrumentation hooks for Runnables and other RTE objects of interests. Once you have activated the VFB hooks (e.g., Vector) in your RTE generation tool, iTCHi helps to implement the instrumentation and to make winIDEA aware of the Runnable identifier to Runnable name mapping.

 

To use this feature add the following object to your iTCHi configuration file:

 

The impl_vfb_hooks_c attribute specifies the location of the instrumentation file that is generated by iTCHi. At the moment VFB tracing is supported for Vector MICROSAR Classic RTE, Elektrobit tresos AutoCore RTE and ETAS RTA-RTE.

More information about the iTCHi usage for the different RTE suppliers can be found in the next sections.

 

 

iTCHi comes with default instrumentation templates. The template_file attribute allows you to specify a custom template. If you point template_file to a non-existing file iTCHi will write the default template into this file. If you leave the attribute empty or remove it the default template file is used.

Refer to Task state tracing with instrumentation for an explanation of the instrumentation_type, trace_variable, stm, and db_push_register attributes.

 

 

Runnable instrumentation with Vector MICROSAR Classic RTE

DaVinci Configurator writes the active RTE hooks into Rte_Hook.h during the RTE code generation step. iTCHi extracts those hooks from the header file (rte_hook_h points to the Rte_Hook.h header file), assigns an identifier and writes them into the Profiler XML and the impl_vfb_hooks_c file.

The following regular expression (regex) is used to find hooks within the header file. The outer parentheses are simply Python’s way of allowing multi-line strings. The parentheses inside the string specify matching groups.

 

You can overwrite the default regex via the regex attribute within runnable_instrumentation. If you create a default iTCHi file with --write_default_config it will contain the default regex that you can adapt to your needs. Keep in mind that \ and " have to be escaped in the JSON file. Also, regular parentheses are used for grouping in Python. For example, (foo) specifies a group that matches the string foo. If you want to use groups yourself be sure to make them non-capturing with (?:foo), because iTCHi relies on exact the four groups that are part of the default regex.

 

 

Runnable instrumentation with Elektrobit tresos AutoCore RTE

EB tresos Studio stores active RTE hooks in the Rte.xdm XML file. iTCHi is able to parse this file (rte_xdm points to the Rte.xdm file) and extract all active Runnable hooks. The rest works similar to Vector MICROSAR Classic RTE; iTCHi assigns an identifier to each Runnable, generates the instrumentation and writes the identifier to name mapping into the Profiler XML file.

 

 

 

Runnable instrumentation with ETAS RTA-RTE

By default, ETAS ISOLAR-A/B stores the active RTE hooks in Rte_EcucValues.arxml. iTCHi is able to parse this file (rte_arxml points to the Rte_EcucValues.arxml file) and extract all active Runnable hooks. iTCHi uses the reference of the vendor specific module definition (VSMD) for the relevant configuration parameter to extract all active Runnable hooks. By setting rte_stack_supplier to etas, the default ETAS VSMD path is automatically used. The used VSMD path can be overridden by setting the parameter rte_vsmd_path. The rest works similar to Vector MICROSAR Classic RTE; iTCHi assigns an identifier to each Runnable, generates the instrumentation and writes the identifier to name mapping into the Profiler XML file.

 

 

 

Running Task/ISR tracing with OS Signaling (not supported)

Task/ISR tracing with additional OS Signaling gives the Profiler the information whether a task context switch was caused by a preemption, termination, or waiting transition. This information is signaled with an additional ORTI Attribute vs_OSSIGNAL and is only supported by ETAS RTA-OS. If you need support for this feature contact a TASKING FAE.

 

 

Runnable program flow

Runnables are functions and can be recorded via program flow trace. The Profiler XML file can specify which functions should be treated as Runnables. This has two benefits:

•Runnables are shown under a dedicated node in the Profiler Timeline. Second, the

•Functions that are marked as Runnables are included in the BTF export for analysis in third party timing-tools.

 

Add the runnable_program_flow object to your iTCHi configuration file. runnables is a list of function symbols that will be added to the Profiler XML as a Runnable.

 

Once you have added the Runnables to the Profiler XML file, run iTCHi with the --runnable_program_flow command.

 

 

Signals

The term signal means a single global variable. The winIDEA Analyzer can display global variables via data areas. Alternatively, you can configure signals in the Profiler XML. The biggest advantage of this approach is that winIDEA exports these signals into BTF.

 

Adding signal objects to Profiler XML:

1. Create a signals configuration object.

2. Add signals via a second signals attribute that points to a list of strings.

 

 

 

Spinlock with instrumentation

Please contact your TASKING FAE if you want to use spinlock profiling.

 

 

 

Software Tracing

The --swat command provides software-based tracing capabilities for embedded systems where hardware tracing is not available or suitable. Software Tracing implements a lightweight, lock-free ring buffer mechanism that enables monitoring of system events with minimal overhead. For detailed information about using Software Tracing in your project, please refer to the dedicated documentation. If you're interested in using software tracing, please reach out to TASKING for support and guidance on the best configuration for your specific use case.