Infineon Tricore AURIX

Jump to: navigation, search


This manual describes the porting details of the ERIKA Enterprise v3 kernel(s) for families of microcontrollers which integrate Infineon TriCore AURIX CPUs.

TriCore Aurix features supported

The following are the main features of the currently implemented support:


The following tutorials are available for this architecture:

Configuration and Programming

ERIKA Enterprise is configured through RT-Druid and an OIL file and some other properties.

The following sections describe the properties and OIL fields customized for Infineon TriCore Architecture.

GCC Compiler Path

It is possible to choose the path in four different ways:

  • Setting the compiler bin folder on the PATH environment variable
  • Specific environment variables: BINDIR
    • E.g.: BINDIR=C:\HIGHTEC\toolchains\tricore\v4.9.1.0-infineon-1.1
  • RT-Druid Eclipse IDE Property.
  • RT-Druid Configuration File Entry: preference_tricore__path_for_hightec_gcc_compiler
    • E.g.: preference_tricore__path_for_hightec_gcc_compiler=C:\HIGHTEC\toolchains\tricore\v4.9.1.0-infineon-1.1

Here is an example of RT-Druid configuration file.

Lauterbach TRACE32 Path

It is possible to choose the path in two different ways:

  • RT-Druid Eclipse IDE Property.
  • RT-Druid Configuration File Entry: preference_lauterbach__path_for_trace32
    • E.g.: preference_lauterbach__path_for_trace32=C:\T32

Here is an example of RT-Druid configuration file.

Lauterbach Emulator Interface

It is possible to choose the path in two different ways:

  • RT-Druid Eclipse IDE Property.
  • RT-Druid Configuration File Entry: preference_lauterbach__emulator_usb_interface
    • E.g.: preference_lauterbach__emulator_usb_interface=true

Here is an example of RT-Druid configuration file.


CPU_DATA object must be set to TRICORE.

Example of a CPU_DATA section:



On multicore systems, one CPU_DATA instance exists for each core. They must have different IDs to be considered really distinct cores (all the CPU_DATA block with the same ID are merged together during generation and this may or may not cause validation errors if this happens by misconfiguration). Later in this page you will find a paragraph relative to specific multicore support developed for Tricore Aurix, according to Autosar OS 4.3.1 specifications.

ID is a numeric value starting from 0 (default value). ID value correspond to the core physical ID, so the ID=0 MUST be configured always as is requested by Autosar specifications, the otehr ID values are free to be configured or not.

In TriCore TC27X family this number can be 2 at most, since this family is equipped with 3 cores. TriCore TC23X family is a singlecore family, so ID shuld not be specified for this family or, if specified, MUST be 0.


COMPILER attribute of CPU_DATA supports for now the GCC value only. Deafult value is GCC.

Example of a COMPILER attribute of CPU_DATA section:



MINIMAL_OPTS boolean property of COMPILER attribute of CPU_DATA configures the build system with minimal compiling and linking options. The default value is set to FALSE.

Example of a MINIMAL_OPTS property of COMPILER attribute of CPU_DATA section:

          MINIMAL_OPTS = TRUE;


Tricore AURIX support MCU clock configuration with a simple PLL driver. The target clock value in MHz can be set with the CPU_CLOCK field. We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value. In any case max declared CPU clock value (i.e. 200 Mhz for TC27x & TC23x families), is guaranteed to be perfectly matched.

N.B. To get the real value set you can use osEE_tc_get_fsource() since SRI divider is set to 1 and no Core Dividers (CCUCON6-8) are set. By default ERIKA3 start-up code configure PLL before the main. The PLL's configuration can be skipped adding


to the OIL file, inside OS block.


The MCUs support for the Tricore AURIX is configured correctly by simply specifying the MCU_DATA item without additional options.

In case you are debugging with Lauterbach TRACE32, you need to specify the DERIVATIVE and REVISION in order for the .cmm scripts to be generated correctly.

Valid configuratuions

The following are the configuration that have been tested for the MCU_DATA setting:

  • TC223
   MCU_DATA = TC22X {
     DERIVATIVE = "tc223l";

  • TC233
   MCU_DATA = TC23X {
     DERIVATIVE = "tc233lp";
  • TC265
   MCU_DATA = TC27X {
     DERIVATIVE = "tc265de";
  • TC275
   MCU_DATA = TC27X {
     DERIVATIVE = "tc275tf";
  • TC277
   MCU_DATA = TC27X {
     DERIVATIVE = "tc277tf";
  • TC297
   MCU_DATA = TC29X {
     DERIVATIVE = "tc297tf";
  • TC399
   MCU_DATA = TC39X {
     DERIVATIVE = "tc399xe-AStep";
     REVISION = "AA";


The following MCU_DATA values are supported TC22X, TC23X, TC26X, TC27X, TC29X and TC39X for the AURIX 2G.

Example of a MCU_DATA section:

   MCU_DATA = TC27X {


DERIVATIVE attribute of MCU_DATA is an OIL attribute of type of String. This field is used to generate Lauterbach scripts, its value has to be a valid system.cpu value for Lauterbach scripts, belonging to the selected TriCore family. Please note that if you configure MCU_DATA = TC27X, the DERIVATIVE string has to point to a MCU belonging to the TC27X family. Please note that no consistency checks have been implemented (you will notice it because Lauterbach TRACE32 will not start).

Example of DERIVATIVE attribute of a MCU_DATA section:

   MCU_DATA = TC27X {
     DERIVATIVE = "TC275TF";

"TC275TF" is the default value for the attribute DERIVATIVE if MCU_DATA TC27X is configured


REVISION attribute of MCU_DATA is an OIL attribute of type of String. Its value is used to select the correct compiler options that are dependent to the silicon revision of a MCU.

Interrupt Handling

Due to the special implementation of the Interrupt Vector in AURIX architecture, each entry of the vector table is simply identified by it's priority value. The SRN register of the source is configured by ERIKA3 during the StartOS.

Valid values for the SOURCE field of an ISR follow the same naming convention used by Infineon inside its own iLLDs (Infineon Low Level Drivers).

System Timer

The OSEK/VDX standard provides support for a System Counter (a counter that is automatically linked to a hardware timer).

In ERIKA Enterprise, this special counter has been named System Timer. To use it, you need to set a specific attribute in a Counter definition. Please note that only one counter for each core can be the System Timer.

A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive IncrementCounter.

The following is an example OIL definition for a System Counter:

   CPU_CLOCK = 200.0;
 COUNTER SystemTimer {
   CPU_ID = 0;
   MINCYCLE = 1;
   MAXALLOWEDVALUE = 2147483647;
     DEVICE = "STM_SR0";
     PRIORITY = 1;

The meaning of the various attributes is as follows:

  • CPU_DATA/CPU_CLOCK is used to declare the clock frequency (in MHZ).
  • COUNTER/CPU_ID is used to tie the counter with a specific core (if the core to be tied to is 0, explicitly declaring CPU_ID is not necessary)
  • COUNTER/TYPE must be set to HARDWARE, and SYSTEM_TIMER must be set to true.
  • COUNTER/TYPE/DEVICE must be a valid device that can be used for a system timer. Currently, for TRICORE only STM (System Timer Module) MCU peripheral is a valid device for system timer. Both Interrupt source of this peripheral can be set to device and allowed values are STM_SR0 and STM_SR1. STM_SR0 and STM_SR1 refer to the core correspindig STM comparator interrupt, so when the system timer is tied with core0 they point to STM0SR0 and STM0SR1 ISRs sources respectively (Infineon naming convention).
  • COUNTER/TYPE/PRIORITY By default SYSTEM_TIMER is tied to smallest ISR priority (i.e. PRIORITY = 1;), but it can be overritten. Ovveride is necessay in multicore environment because priority 1 is used by the Intercore Interrupt Request.
  • COUNTER/SECONDSPERTICK is used to declare the wanted time duration of one hardware tick in seconds.

The System Timer can be attached to ALARMs as usual, as in the following example:

 ALARM AlarmExample {
   COUNTER = SystemTimer;
      TASK = TaskExample;

Multicore Implementations Details

TriCore 1.6.{1,2} ISA documents clearly states the following about global registers A8 e A9: "They are normally used by the operating system to reduce system overhead". So default multicore implementation of ERIKA3 take advantage of this, storing a reference to a core-private internal data structure in A9. Said that, it seems that this policy could conflict with future compilers features so this behavior has been made configurable (switchable off) through EEOPT.