Infineon Aurix

From ErikaWiki

Revision as of 09:22, 19 April 2013 by Eguidieri (Talk | contribs)
Jump to: navigation, search

Contents

Infineon Aurix support

ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid it will be released soon. Currently only the TC27x AURIX family have been fully ported:

  1. Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).
  2. Support for single- and multi-stack configurations.
  3. ISR Type 1 and Type 2.
  4. ORTI support.
  5. Full Lauterbach support.
  • Supported compilers:
    • HIGHTEC GCC Compiler v4.6.2.0 (for both Single and Multicore).
    • TASKING VX-toolset for TriCore v4.0r1 (only for singlecore)
  • Mode of operation
    • Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.
    • Multistack: Every thread can have its private stack, or it can share it with other threads.
    • Multicore: It follows the same philosophy used by ERIKA on other multicore systems and specified by Autosar: two instances of the operating systems run on the two cores, and communication between cores is performed with a few APIs and shared memory.

MCU & Board

  • The porting have been completly developed on top of:
    • TriBoard TC2x5 v2.0 equiped with a TC275TE MCU

Target Configuration and Programming

ERIKA Enterprise is configured through RT-Druid and an OIL file. Here are listed, after the information to set compiler path, the OIL fields custumized for Tricore Aurix architecture.

Compiler Path

It is possible to choose the path of the compiler in three different ways:

  • PATH enviornment variable: You can put compilers bin directories in PATH and the environmet can use them from here.
  • Compiler specific environment variables:
    • HIGHTEC GCC toolchain: You can specify the compiler path for HIGHTEC GCC with the TRICORE_GCCDIR.
    • Altium TASKING toolchain: You can specify the compiler path for Altium TASKING with the TRICORE_TASKINGDIR.
  • RT-Druid configuration file see RT-Druid configuration#Compiler paths:
    • preference_tricore__path_for_gnu_compiler set HIGHTEC gcc compiler path for Tricore AURIX
    • preference_tricore__path_for_tasking_compiler set Altium TASKING compiler path for Tricore AURIX

CPU

CPU_DATA must be set to TRICORE. The compiler is specificed with the COMPILER_TYPE item, supported values are GNU (the default value) and TASKING.

On multicore systems, one CPU_DATA instance can exist for each core. They must have different IDs. See ERIKA multicore support for more details about multicore systems on Erika. Later in this page you will find a paragraph relative to specific multicore support developed for Tricore Aurix, according to Autosar OS 4.0 Rev 3 specifications.

Tricore AURIX support CPU 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 family), is guaranteed to be perfectly matched.

N.B. To get the real value set you can use EE_tc27x_get_clock() API after executing StartOS, PLL configuration is done during OS start-up.

Moreover a new field to declare a custom linker script have been added to CPU_DATA block: LINKERSCRIPT = "fake.ld";

Example of a CPU_DATA section:

   CPU_DATA = TRICORE {
     CPU_CLOCK = 200.0;
     APP_SRC = "code.c";
     COMPILER_TYPE = GNU;
     MULTI_STACK = TRUE {
       IRQ_STACK = TRUE {
           SYS_SIZE = 128;
       };
     };
   };

MCU

MCU_DATA support only the TC27x value. Compiler can be specified even in MCU_DATA block and will inherited by all configured CPUs (useful in multicore project configuration).

 MCU_DATA = TRICORE {
   MODEL = TC27x;
   COMPILER_TYPE = GNU;
 };

BOARD

There is only support form TriBoard TC2x5 equiped with a TC275TE MCU. This board only provide debug interface and 8 leds, so the support is limited to the LEDs configuration/driving and, because standard ERIKA demos require it, an external button (external means that have to be soldered by the user) mounted on pin P15.8 of TC275TE (corresponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector). Add the following OIL field to enable this support.

 BOARD_DATA = TRIBOARD_TC2X5;

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. It must be the application code that configure the service request node (SRN') with the right priority, assigning in this way the right handler.

 ISR IsrLow {
   CATEGORY = 2;
   PRIORITY = 1;
   HANDLER = "isr_low"; 
 };

The mean of the fields are:

  • CATEGORY: the type of ISR as specified by OSEK.
  • PRIORITY: The ISR priority that represent it's position inside Interrupt Vector so it has to be considered as ISR Identifier. The ENTRY field, the one usually used to declare Interrupt IDs, is still available but it's superfluous because it has to be equal to PRIORITY and, in any case, priority value take the precedence.
  • HANDLER: Declare the interrupt handler symbol. If it's not declared the the handler symbol is supposed to be equal to ISR block name (IsrLow in the example).

EEOPT

EEOPT is a way to specify configuration flags to the Erika build environment. EEOPTs can be specified as strings in the OS section of the OIL file. Examples:

EE_OPT = "EE_DEBUG";
EE_OPT = "__ASSERT__";

Please notice that spelling inside the OIL file includes an underscore: EE_OPT.

The only supported format for EEOPTs is a single name, which should be a valid C identifier (i.e., only Latin letters, digits, and underscore are allowed; the first character cannot be a digit). And any other format is not supported, and even if it works now, it may break in the future.

The following EEOPTs are specific of AURIX Architecture:

  • EE_DEBUG: Replace the often used DEBUG option (because it conflict with compilers DEBUG define). Enable debug compiler options, basically less optimization and debug symbols generation plus defualt TRAP handlers are implemented as busy loops instead of system reset.
  • EE_EXECUTE_FROM_RAM: When specified, a linker script is used that maps both code and data in the RAM space. Executables produced with this option can be used only together with a debugger that loads the program in memory. By default, code and constant data are mapped to Flash, data to RAM.
  • EE_SAVE_TEMP_FILES: Enable temporary files saving for the compiler, useful to debug build process and to inspect generate assembly code. It's useful only for HIGHTEC GCC compiler because for TASKING compiler is always active. For the GCC compiler it has been added the switch because the size of temporary files is huge.

OSEK/VDX Extensions

This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.

Resource Managament at ISR level

This feauture is automatically enabled by RT-Druid during the configuration generation step. To specify that a Resource is used by both a Task and a ISR you need to add that resource to the corrisponding ISR object as follows:

 TASK Task1 {
   ...
   RESOURCE = "ResourceA";
 };
 
 ISR <SYMBOL> {
   PRIORITY = <PRIORITY_LEVEL>;
   CATEGORY = <ISR_TYPE>;
   RESOURCE = "ResourceA";
 };
 
 RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };

System Timer

The OSEK/VDX standard provides support for a System Counter (a counter that is automatically linked to a hardware timer). The System Timer is used to give a coherent timing reference across the entire application.

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_DATA = TRICORE{
   CPU_CLOCK = 200.0;
   ...
 };
 
 COUNTER SystemTimer {
   MINCYCLE = 1;
   MAXALLOWEDVALUE = 2147483647;
   TICKSPERBASE = 1;
   TYPE = HARDWARE {
     DEVICE = "STM_SR0";
     SYSTEM_TIMER = TRUE;
     PRIORITY = 1;
   };
   SECONDSPERTICK = 0.001;
 };

The meaning of the various attributes is as follows:

  • CPU_DATA/CPU_CLOCK is used to declare the clock frequency (in MHZ).
  • 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
  • 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;
   ACTION  = ACTIVATETASK{
      TASK = TaskExample;
   };
 };

CPU MCU & BOARD API

In addition to AUTOSAR OS Kernel Interface, in ERIKA AURIX porting are implemented a bunch of utility functions that will be considered as part of ERIKA API. As usual they are separated in the three logical layer that compose ERIKA architecture abstraction: CPU, MCU & BOARD.

CPU API

In this layer are declared the functions to temporary disable ENDINIT and SAFETY_ENDINIT register protection (see Infineon AURIX documentation). These functions are a little bit tricky: declaration belong to CPU layer, because AURIX architecture documentation states that every AURIX implementation has some kind of ENDINIT and SAFETY_ENDINIT protection, but delegate implementation details to each AURIX family, so functions definitions has been done inside MCU files.

  1. void EE_tc_endint_disable( void ): Temporary disable ENDINT protection.
  2. void EE_tc_endint_enable( void ): Re-enable ENDINT protection.
  1. void EE_tc_safety_endinit_disable( void ): Temporary disable SAFETY_ENDINIT protection.
  2. void EE_tc_safety_endinit_enable( void ): Re-enable SAFETY_ENDINIT protection.

MCU API

Most part of the utili

Personal tools