http://erika.tuxfamily.org/wiki/index.php?title=Special:Contributions&feed=atom&limit=20&target=Eguidieri&year=&month=ErikaWiki - User contributions [en]2024-03-28T22:09:10ZFrom ErikaWikiMediaWiki 1.16.4http://erika.tuxfamily.org/wiki/index.php?title=Infineon_AurixInfineon Aurix2017-11-21T11:09:02Z<p>Eguidieri: /* Infineon Aurix support */</p>
<hr />
<div>[[Category:Supported Devices]]<br />
= Infineon Aurix support =<br />
<br />
ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid will be released soon.<br />
Currently only the TC27x AURIX family have been fully ported: <br />
<br />
# Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers:<br />
** HIGHTEC GCC Compiler v4.6.3.1 & 4.9.2.0 (for both Single and Multicore).<br />
** TASKING VX-toolset for TriCore v4.0r1 (only for Singlecore).<br />
** WIND RIVER DIAB Compiler Rel. 5.9.2.0 (only for Singlecore). <br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: It follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ 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.<br />
<br />
* '''CYGWIN'''<br />
** '''Under Cygwin environment you MUST use make command version 4.2.1 or above'''<br />
<br />
=== MCU & Board ===<br />
* The porting have been completly developed on top of:<br />
** TriBoard TC2x5 v2.0 equiped with a TC275TE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC264DE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC297TA MCU (ask info AT evidence DOT eu DOT com)<br />
<br />
= Target Configuration and Programming =<br />
<br />
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]. Here are listed, after the information to set compiler path, the OIL fields customized for Tricore Aurix architecture.<br />
<br />
=== Compiler Path ===<br />
<br />
It is possible to choose the path of the compiler in three different ways:<br />
<br />
* ''PATH enviornment variable'': You can put compilers bin directories in PATH and the environmet can use them from here. <br />
* ''Compiler specific environment variables'':<br />
** '''HIGHTEC GCC toolchain''': You can specify the compiler path for HIGHTEC GCC with the '''TRICORE_GCCDIR'''.<br />
** '''Altium TASKING toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_TASKINGDIR'''.<br />
** '''Wind River Diab toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_DIABDIR'''.<br />
* ''RT-Druid configuration file'' see [[RT-Druid configuration#Compiler paths]]:<br />
** '''preference_tricore__path_for_gnu_compiler''' set HIGHTEC gcc compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_tasking_compiler''' set Altium TASKING compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_diab_compiler''' set Wind River Diab compiler path for Tricore AURIX<br />
<br />
Here is an [[Common oil.pref example|example of RT-Druid configuration file]].<br />
<br />
=== CPU ===<br />
<br />
'''CPU_DATA''' must be set to '''TRICORE'''.<br />
The compiler is specificed with the '''COMPILER_TYPE''' item, supported values are '''GNU''' (the default value) and '''TASKING'''.<br />
<br />
On multicore systems, one '''CPU_DATA''' instance can exist for each core. They must have different '''ID'''s. 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.<br />
<br />
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.<br />
We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value.<br />
In any case max declared CPU clock value (i.e. 200 Mhz for TC27x & TC26x families), is guaranteed to be perfectly matched.<br />
<br />
'''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.<br />
<br />
Moreover a new field to declare a custom linker script have been added to CPU_DATA block: '''LINKERSCRIPT = "fake.ld";'''<br />
<br />
Example of a CPU_DATA section:<br />
<br />
CPU_DATA = TRICORE {<br />
CPU_CLOCK = 200.0;<br />
APP_SRC = "code.c";<br />
COMPILER_TYPE = GNU;<br />
MULTI_STACK = TRUE {<br />
IRQ_STACK = TRUE {<br />
SYS_SIZE = 128;<br />
};<br />
};<br />
};<br />
<br />
=== MCU ===<br />
<br />
'''MCU_DATA''' supports the '''TC27x''', '''TC27xA''', '''TC27xB''', '''TC27xC''' and '''TC26x''' values. Compiler can be specified even in '''MCU_DATA''' block and will inherited by all configured CPUs (useful in multicore project configuration).<br />
<br />
Note: due to a currupted register file of GNU compiler ( HighTec GCC Version 4.9.x.x ), the compiling of '''TC27x''' and '''TC27xA''' MCU models is broken.<br />
<br />
MCU_DATA = TRICORE {<br />
MODEL = TC27x;<br />
COMPILER_TYPE = GNU;<br />
};<br />
<br />
=== BOARD ===<br />
<br />
There is only support form TriBoard TC2x5. 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 (corresponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector). Add the following OIL field to enable this support.<br />
<br />
BOARD_DATA = TRIBOARD_TC2X5;<br />
<br />
=== Interrupt Handling ===<br />
<br />
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.<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
HANDLER = "isr_low"; <br />
};<br />
<br />
The mean of the fields are:<br />
*'''CATEGORY''': the type of ISR as specified by OSEK. <br />
*'''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.<br />
*'''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).<br />
<br />
=== Trap Handling ===<br />
<br />
With TriCore AURIX, for the first time, we support the options to register handler for TRAP/Exceptions. OSEK OIL do not provide any field for trap handling: it suppose that all the handling is done inside the Kernel. Usually that's what happens, but sometime can be useful have some mechanism to attach an handler for a particular class of TRAPs.<br />
<br />
We decide to exetend ISR entry with the field '''TRAP''' that can be set to TRUE to enable TRAP handling. In this case you have to choose the TRAP class with the field LEVEL (or ENTRY). The only valid values for this configuration are:<br />
<br />
*'''TRAP_MMU''' (Actually useless because TC27x and TC26x families don't have MMU, just a place holder)<br />
*'''TRAP_PROT''' (Handler for protection traps)<br />
*'''TRAP_INST''' (Handler for instructions traps)<br />
*'''TRAP_CONT''' (Handler for context traps) <br />
*'''TRAP_BUS''' (Handler forn bus traps)<br />
*'''TRAP_ASS''' (Handler for assertion traps) (please don't be silly :))<br />
*'''TRAP_SYS''' (Handler for system calls)<br />
*'''TRAP_NMI''' (Handler for NMI trap)<br />
<br />
OIL TRAP configuration example:<br />
<br />
ISR trap_context {<br />
LEVEL = "TRAP_CONT";<br />
HANDLER = "EE_trap_context"; //Trap handler<br />
TRAP = TRUE;<br />
};<br />
<br />
To define the handler in your code, you have to use the following syntax:<br />
<br />
TRAP(EE_CLASS_TRAPCONT, EE_trap_context) {<br />
while(1) {<br />
; /* dummy */<br />
}<br />
}<br />
<br />
TRAP class identifiers are the following:<br />
<br />
*EE_CLASS_TRAPMMU<br />
*EE_CLASS_TRAPPROT<br />
*EE_CLASS_TRAPINST<br />
*EE_CLASS_TRAPCONT<br />
*EE_CLASS_TRAPBUS<br />
*EE_CLASS_TRAPASS<br />
*EE_CLASS_TRAPSYS<br />
*EE_CLASS_TRAPNMI<br />
<br />
Inside the TRAP handler TIN (Trap Identification Number) value can be accessed with '''EE_tc_get_TIN()''' function or, for HIGHTEC GNUC Compiler, with the local variable '''tin'''. For more information you can check the '''$(ee)/pkg/cpu/tricore/inc/ee_tc_trap.h''' file.<br />
<br />
=== EEOPT ===<br />
<br />
EEOPT is a way to specify configuration flags to the Erika build environment.<br />
EEOPTs can be specified as strings in the OS section of the OIL file. Examples:<br />
<br />
EE_OPT = "EE_DEBUG";<br />
EE_OPT = "__ASSERT__";<br />
<br />
Please notice that spelling inside the OIL file includes an underscore: EE_OPT.<br />
<br />
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.<br />
<br />
The following EEOPTs are specific of AURIX Architecture:<br />
* '''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.<br />
* '''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.<br />
* '''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'''.<br />
* '''EE_ICACHE_ENABLED''': Enable the instruction cache in start-up code.<br />
* '''EE_DCACHE_ENABLED''': Enable data cache in start-up code<br />
<br />
= OSEK/VDX Extensions =<br />
<br />
This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.<br />
<br />
=== Resource Managament at ISR level ===<br />
<br />
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:<br />
<br />
TASK Task1 {<br />
...<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
ISR <SYMBOL> {<br />
PRIORITY = <PRIORITY_LEVEL>;<br />
CATEGORY = <ISR_TYPE>;<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };<br />
<br />
=== System Timer ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive '''IncrementCounter'''.<br />
<br />
The following is an example OIL definition for a System Counter:<br />
<br />
CPU_DATA = TRICORE{<br />
CPU_CLOCK = 200.0;<br />
...<br />
};<br />
<br />
COUNTER SystemTimer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM_SR0";<br />
SYSTEM_TIMER = TRUE;<br />
PRIORITY = 1;<br />
};<br />
SECONDSPERTICK = 0.001;<br />
};<br />
<br />
The meaning of the various attributes is as follows:<br />
* '''CPU_DATA/CPU_CLOCK''' is used to declare the clock frequency (in MHZ).<br />
* '''COUNTER/TYPE''' must be set to '''HARDWARE''', and '''SYSTEM_TIMER''' must be set to true.<br />
* '''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'''<br />
* '''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'''.<br />
* '''COUNTER/SECONDSPERTICK''' is used to declare the wanted time duration of one hardware tick in seconds.<br />
<br />
The System Timer can be attached to ALARMs as usual, as in the following example:<br />
<br />
ALARM AlarmExample {<br />
COUNTER = SystemTimer;<br />
ACTION = ACTIVATETASK{<br />
TASK = TaskExample;<br />
};<br />
};<br />
<br />
= CPU MCU & BOARD API =<br />
<br />
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'''.<br />
<br />
=== CPU API ===<br />
<br />
CPU layer represent all the behaviour shared between all the families of AURIX MCUs. 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.<br />
<br />
* '''void EE_tc_endint_disable( void )''': Temporary disable ENDINT protection.<br />
* '''void EE_tc_endint_enable( void )''': Re-enable ENDINT protection.<br />
<br />
* '''void EE_tc_safety_endinit_disable( void )''': Temporary disable SAFETY_ENDINIT protection.<br />
* '''void EE_tc_safety_endinit_enable( void )''': Re-enable SAFETY_ENDINIT protection.<br />
<br />
=== MCU API ===<br />
<br />
MCU layer represent the behaviour tied to an specific AURIX family of MCUs. For now only family TC27x is supported.<br />
Most part of the utilities belong to this layer:<br />
<br />
* '''void EE_tc2Yx_get_clock ( void )''': Return CPU clock frequency in HZ.<br />
* '''void EE_tc2Yx_configure_clock( EE_UREG fclock )''': Make the best effort to set CPU clock frequency to fclock value. It's the function used by '''StartOS''' when a '''CPU_CLOCK''' is configured in '''CPU_DATA'''.<br />
* '''void EE_tc2Yx_delay ( EE_UREG usec )''': Implement a busy loop wait of '''usec''' micorseconds.<br />
* '''void EE_tc2Yx_stm_set_sr0( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 0''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc2Yx_stm_set_sr0_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 0 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
* '''void EE_tc2Yx_stm_set_sr1( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 1''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc2Yx_stm_set_sr1_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 1 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
<br />
'''SR0''' and '''SR1''' API are both available to the user if '''System Timer''' is '''not''' configured. Otherwise only the one not used by system timer will be available.<br />
<br />
=== Board API ===<br />
<br />
BOARD layer represent the specific board support. There is only aminimal support for TriBoard TC2x5 v2.0 equiped with a TC275TE MCU:<br />
<br />
* '''void EE_tc2x5_leds_init( void )''': Initialize the 8 boards leds.<br />
* '''void EE_tc2x5_leds_on( void )''': Turns all the 8 leds.<br />
* '''void EE_tc2x5_leds_off( void )''': Turns off all the 8 leds.<br />
* '''void EE_tc2x5_turn_led(enum EE_tc2x5_led_id led_id, enum EE_tc2x5_led_status onoff)''': Turn the status of the led '''led_id''' (led IDs are collected in an enum in the form: '''EE_TRIBOARD_2X5_LED_{x}''' with {x}=[1..8]) on (onoff == '''EE_TRIBOARD_2X5_LED_ON''') or off (onoff == '''EE_TRIBOARD_2X5_LED_OFF''').<br />
* '''EE_BIT EE_tc2x5_read_button( void ): read external button value<br />
* '''void EE_tc2x5_button_irq_init( EE_TYPEISR2PRIO intvec )''': Configure the external button has an interrupt source and tie it to '''intvec''' priority handler.<br />
* '''void EE_tc2x5_button_irq_clear_request( void )''': Clear external button interrupt request.<br />
<br />
External button have to be connected to pin P15.8 on TC275TE corrisponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector of TriBoard TC2x5.<br />
<br />
= Debugger support =<br />
<br />
* [[Lauterbach TRACE32 Support for Infineon Aurix]]<br />
* [[iSYSTEM winIDEA Support for Infineon Aurix]]<br />
<br />
= Multicore Autosar OS Support =<br />
<br />
For details please see the following page: [[Erika AUTOSAR OS]]<br />
<br />
=== Build Multicore Application Single ELF with HighTec GCC Compiler ===<br />
<br />
The conventional ERIKA multicore build chain generate an ELF file for each core and the real application image is loaded on the device by Lauterbach, trought scripts. This approach is not straightforwardly portable on other programmer tools. Fortunately HighTec GCC Compiler has some peculiar features that have allowed us to change this approach, and for TriCore is possible to compile a Multicore Application contained in a single ELF.<br />
<br />
To enable this new build method add the following '''EEOPT=EE_BUILD_SINGLE_ELF''' to the project OIL file.<br />
<br />
To export some symbols from a core an '''HighTec GCC export file''' is needed. An HighTec export file looks like this:<br />
<br />
EXPORT FUNCTION _START ;<br />
EXPORT FUNCTION ErrorHook ;<br />
EXPORT FUNCTION StartupHook ;<br />
EXPORT FUNCTION ShutdownHook ;<br />
<br />
EXPORT OBJECT EE_oo_ErrorHook_ServiceID ;<br />
EXPORT OBJECT EE_oo_ErrorHook_data ;<br />
<br />
...<br />
<br />
To inform the build system to use an export file for a given core change the '''COMPILER_TYPE''' field of '''CPU_DATA''' OIL container, in the following way:<br />
<br />
CPU_DATA = TRICORE {<br />
ID = "master";<br />
...<br />
COMPILER_TYPE = GNU {<br />
EXPORT_FILE = "<relative path to the export file>";<br />
};<br />
...<br />
}; <br />
<br />
If this is done add explicitly '''EEOPT=EE_BUILD_SINGLE_ELF''' is no more needed.<br />
<br />
'''N.B:''' When used this approach an export files for the master core have to be provided always. The file can be empty if no symbols have to be exported by master core.<br />
<br />
This build approach is showed on following RT-Druid TriCore templates:<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test''<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore Spinlocks test''<br />
<br />
= Additional Notes =<br />
<br />
Since ERIKA 2.4.0 full AUTOSAR SC4 OS support for AURIX is publically released: you can find all the information about the implemented features and how to configure them at this page: [[Erika AUTOSAR OS]].</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=Infineon_AurixInfineon Aurix2017-11-21T11:07:53Z<p>Eguidieri: /* Compiler Path */</p>
<hr />
<div>[[Category:Supported Devices]]<br />
= Infineon Aurix support =<br />
<br />
ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid will be released soon.<br />
Currently only the TC27x AURIX family have been fully ported: <br />
<br />
# Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers:<br />
** HIGHTEC GCC Compiler v4.6.3.1 (for both Single and Multicore). '''NOTE Version 4.6.3.0 DOES NOT WORK!!!''' (it has a problem on Tricore header files)<br />
** TASKING VX-toolset for TriCore v4.0r1 (only for Singlecore).<br />
** WIND RIVER DIAB Compiler Rel. 5.9.2.0 (only for Singlecore). <br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: It follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ 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.<br />
<br />
* '''CYGWIN'''<br />
** '''Under Cygwin environment you MUST use make command version 4.2.1 or above'''<br />
<br />
=== MCU & Board ===<br />
* The porting have been completly developed on top of:<br />
** TriBoard TC2x5 v2.0 equiped with a TC275TE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC264DE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC297TA MCU (ask info AT evidence DOT eu DOT com)<br />
<br />
= Target Configuration and Programming =<br />
<br />
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]. Here are listed, after the information to set compiler path, the OIL fields customized for Tricore Aurix architecture.<br />
<br />
=== Compiler Path ===<br />
<br />
It is possible to choose the path of the compiler in three different ways:<br />
<br />
* ''PATH enviornment variable'': You can put compilers bin directories in PATH and the environmet can use them from here. <br />
* ''Compiler specific environment variables'':<br />
** '''HIGHTEC GCC toolchain''': You can specify the compiler path for HIGHTEC GCC with the '''TRICORE_GCCDIR'''.<br />
** '''Altium TASKING toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_TASKINGDIR'''.<br />
** '''Wind River Diab toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_DIABDIR'''.<br />
* ''RT-Druid configuration file'' see [[RT-Druid configuration#Compiler paths]]:<br />
** '''preference_tricore__path_for_gnu_compiler''' set HIGHTEC gcc compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_tasking_compiler''' set Altium TASKING compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_diab_compiler''' set Wind River Diab compiler path for Tricore AURIX<br />
<br />
Here is an [[Common oil.pref example|example of RT-Druid configuration file]].<br />
<br />
=== CPU ===<br />
<br />
'''CPU_DATA''' must be set to '''TRICORE'''.<br />
The compiler is specificed with the '''COMPILER_TYPE''' item, supported values are '''GNU''' (the default value) and '''TASKING'''.<br />
<br />
On multicore systems, one '''CPU_DATA''' instance can exist for each core. They must have different '''ID'''s. 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.<br />
<br />
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.<br />
We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value.<br />
In any case max declared CPU clock value (i.e. 200 Mhz for TC27x & TC26x families), is guaranteed to be perfectly matched.<br />
<br />
'''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.<br />
<br />
Moreover a new field to declare a custom linker script have been added to CPU_DATA block: '''LINKERSCRIPT = "fake.ld";'''<br />
<br />
Example of a CPU_DATA section:<br />
<br />
CPU_DATA = TRICORE {<br />
CPU_CLOCK = 200.0;<br />
APP_SRC = "code.c";<br />
COMPILER_TYPE = GNU;<br />
MULTI_STACK = TRUE {<br />
IRQ_STACK = TRUE {<br />
SYS_SIZE = 128;<br />
};<br />
};<br />
};<br />
<br />
=== MCU ===<br />
<br />
'''MCU_DATA''' supports the '''TC27x''', '''TC27xA''', '''TC27xB''', '''TC27xC''' and '''TC26x''' values. Compiler can be specified even in '''MCU_DATA''' block and will inherited by all configured CPUs (useful in multicore project configuration).<br />
<br />
Note: due to a currupted register file of GNU compiler ( HighTec GCC Version 4.9.x.x ), the compiling of '''TC27x''' and '''TC27xA''' MCU models is broken.<br />
<br />
MCU_DATA = TRICORE {<br />
MODEL = TC27x;<br />
COMPILER_TYPE = GNU;<br />
};<br />
<br />
=== BOARD ===<br />
<br />
There is only support form TriBoard TC2x5. 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 (corresponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector). Add the following OIL field to enable this support.<br />
<br />
BOARD_DATA = TRIBOARD_TC2X5;<br />
<br />
=== Interrupt Handling ===<br />
<br />
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.<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
HANDLER = "isr_low"; <br />
};<br />
<br />
The mean of the fields are:<br />
*'''CATEGORY''': the type of ISR as specified by OSEK. <br />
*'''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.<br />
*'''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).<br />
<br />
=== Trap Handling ===<br />
<br />
With TriCore AURIX, for the first time, we support the options to register handler for TRAP/Exceptions. OSEK OIL do not provide any field for trap handling: it suppose that all the handling is done inside the Kernel. Usually that's what happens, but sometime can be useful have some mechanism to attach an handler for a particular class of TRAPs.<br />
<br />
We decide to exetend ISR entry with the field '''TRAP''' that can be set to TRUE to enable TRAP handling. In this case you have to choose the TRAP class with the field LEVEL (or ENTRY). The only valid values for this configuration are:<br />
<br />
*'''TRAP_MMU''' (Actually useless because TC27x and TC26x families don't have MMU, just a place holder)<br />
*'''TRAP_PROT''' (Handler for protection traps)<br />
*'''TRAP_INST''' (Handler for instructions traps)<br />
*'''TRAP_CONT''' (Handler for context traps) <br />
*'''TRAP_BUS''' (Handler forn bus traps)<br />
*'''TRAP_ASS''' (Handler for assertion traps) (please don't be silly :))<br />
*'''TRAP_SYS''' (Handler for system calls)<br />
*'''TRAP_NMI''' (Handler for NMI trap)<br />
<br />
OIL TRAP configuration example:<br />
<br />
ISR trap_context {<br />
LEVEL = "TRAP_CONT";<br />
HANDLER = "EE_trap_context"; //Trap handler<br />
TRAP = TRUE;<br />
};<br />
<br />
To define the handler in your code, you have to use the following syntax:<br />
<br />
TRAP(EE_CLASS_TRAPCONT, EE_trap_context) {<br />
while(1) {<br />
; /* dummy */<br />
}<br />
}<br />
<br />
TRAP class identifiers are the following:<br />
<br />
*EE_CLASS_TRAPMMU<br />
*EE_CLASS_TRAPPROT<br />
*EE_CLASS_TRAPINST<br />
*EE_CLASS_TRAPCONT<br />
*EE_CLASS_TRAPBUS<br />
*EE_CLASS_TRAPASS<br />
*EE_CLASS_TRAPSYS<br />
*EE_CLASS_TRAPNMI<br />
<br />
Inside the TRAP handler TIN (Trap Identification Number) value can be accessed with '''EE_tc_get_TIN()''' function or, for HIGHTEC GNUC Compiler, with the local variable '''tin'''. For more information you can check the '''$(ee)/pkg/cpu/tricore/inc/ee_tc_trap.h''' file.<br />
<br />
=== EEOPT ===<br />
<br />
EEOPT is a way to specify configuration flags to the Erika build environment.<br />
EEOPTs can be specified as strings in the OS section of the OIL file. Examples:<br />
<br />
EE_OPT = "EE_DEBUG";<br />
EE_OPT = "__ASSERT__";<br />
<br />
Please notice that spelling inside the OIL file includes an underscore: EE_OPT.<br />
<br />
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.<br />
<br />
The following EEOPTs are specific of AURIX Architecture:<br />
* '''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.<br />
* '''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.<br />
* '''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'''.<br />
* '''EE_ICACHE_ENABLED''': Enable the instruction cache in start-up code.<br />
* '''EE_DCACHE_ENABLED''': Enable data cache in start-up code<br />
<br />
= OSEK/VDX Extensions =<br />
<br />
This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.<br />
<br />
=== Resource Managament at ISR level ===<br />
<br />
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:<br />
<br />
TASK Task1 {<br />
...<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
ISR <SYMBOL> {<br />
PRIORITY = <PRIORITY_LEVEL>;<br />
CATEGORY = <ISR_TYPE>;<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };<br />
<br />
=== System Timer ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive '''IncrementCounter'''.<br />
<br />
The following is an example OIL definition for a System Counter:<br />
<br />
CPU_DATA = TRICORE{<br />
CPU_CLOCK = 200.0;<br />
...<br />
};<br />
<br />
COUNTER SystemTimer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM_SR0";<br />
SYSTEM_TIMER = TRUE;<br />
PRIORITY = 1;<br />
};<br />
SECONDSPERTICK = 0.001;<br />
};<br />
<br />
The meaning of the various attributes is as follows:<br />
* '''CPU_DATA/CPU_CLOCK''' is used to declare the clock frequency (in MHZ).<br />
* '''COUNTER/TYPE''' must be set to '''HARDWARE''', and '''SYSTEM_TIMER''' must be set to true.<br />
* '''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'''<br />
* '''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'''.<br />
* '''COUNTER/SECONDSPERTICK''' is used to declare the wanted time duration of one hardware tick in seconds.<br />
<br />
The System Timer can be attached to ALARMs as usual, as in the following example:<br />
<br />
ALARM AlarmExample {<br />
COUNTER = SystemTimer;<br />
ACTION = ACTIVATETASK{<br />
TASK = TaskExample;<br />
};<br />
};<br />
<br />
= CPU MCU & BOARD API =<br />
<br />
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'''.<br />
<br />
=== CPU API ===<br />
<br />
CPU layer represent all the behaviour shared between all the families of AURIX MCUs. 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.<br />
<br />
* '''void EE_tc_endint_disable( void )''': Temporary disable ENDINT protection.<br />
* '''void EE_tc_endint_enable( void )''': Re-enable ENDINT protection.<br />
<br />
* '''void EE_tc_safety_endinit_disable( void )''': Temporary disable SAFETY_ENDINIT protection.<br />
* '''void EE_tc_safety_endinit_enable( void )''': Re-enable SAFETY_ENDINIT protection.<br />
<br />
=== MCU API ===<br />
<br />
MCU layer represent the behaviour tied to an specific AURIX family of MCUs. For now only family TC27x is supported.<br />
Most part of the utilities belong to this layer:<br />
<br />
* '''void EE_tc2Yx_get_clock ( void )''': Return CPU clock frequency in HZ.<br />
* '''void EE_tc2Yx_configure_clock( EE_UREG fclock )''': Make the best effort to set CPU clock frequency to fclock value. It's the function used by '''StartOS''' when a '''CPU_CLOCK''' is configured in '''CPU_DATA'''.<br />
* '''void EE_tc2Yx_delay ( EE_UREG usec )''': Implement a busy loop wait of '''usec''' micorseconds.<br />
* '''void EE_tc2Yx_stm_set_sr0( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 0''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc2Yx_stm_set_sr0_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 0 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
* '''void EE_tc2Yx_stm_set_sr1( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 1''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc2Yx_stm_set_sr1_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 1 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
<br />
'''SR0''' and '''SR1''' API are both available to the user if '''System Timer''' is '''not''' configured. Otherwise only the one not used by system timer will be available.<br />
<br />
=== Board API ===<br />
<br />
BOARD layer represent the specific board support. There is only aminimal support for TriBoard TC2x5 v2.0 equiped with a TC275TE MCU:<br />
<br />
* '''void EE_tc2x5_leds_init( void )''': Initialize the 8 boards leds.<br />
* '''void EE_tc2x5_leds_on( void )''': Turns all the 8 leds.<br />
* '''void EE_tc2x5_leds_off( void )''': Turns off all the 8 leds.<br />
* '''void EE_tc2x5_turn_led(enum EE_tc2x5_led_id led_id, enum EE_tc2x5_led_status onoff)''': Turn the status of the led '''led_id''' (led IDs are collected in an enum in the form: '''EE_TRIBOARD_2X5_LED_{x}''' with {x}=[1..8]) on (onoff == '''EE_TRIBOARD_2X5_LED_ON''') or off (onoff == '''EE_TRIBOARD_2X5_LED_OFF''').<br />
* '''EE_BIT EE_tc2x5_read_button( void ): read external button value<br />
* '''void EE_tc2x5_button_irq_init( EE_TYPEISR2PRIO intvec )''': Configure the external button has an interrupt source and tie it to '''intvec''' priority handler.<br />
* '''void EE_tc2x5_button_irq_clear_request( void )''': Clear external button interrupt request.<br />
<br />
External button have to be connected to pin P15.8 on TC275TE corrisponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector of TriBoard TC2x5.<br />
<br />
= Debugger support =<br />
<br />
* [[Lauterbach TRACE32 Support for Infineon Aurix]]<br />
* [[iSYSTEM winIDEA Support for Infineon Aurix]]<br />
<br />
= Multicore Autosar OS Support =<br />
<br />
For details please see the following page: [[Erika AUTOSAR OS]]<br />
<br />
=== Build Multicore Application Single ELF with HighTec GCC Compiler ===<br />
<br />
The conventional ERIKA multicore build chain generate an ELF file for each core and the real application image is loaded on the device by Lauterbach, trought scripts. This approach is not straightforwardly portable on other programmer tools. Fortunately HighTec GCC Compiler has some peculiar features that have allowed us to change this approach, and for TriCore is possible to compile a Multicore Application contained in a single ELF.<br />
<br />
To enable this new build method add the following '''EEOPT=EE_BUILD_SINGLE_ELF''' to the project OIL file.<br />
<br />
To export some symbols from a core an '''HighTec GCC export file''' is needed. An HighTec export file looks like this:<br />
<br />
EXPORT FUNCTION _START ;<br />
EXPORT FUNCTION ErrorHook ;<br />
EXPORT FUNCTION StartupHook ;<br />
EXPORT FUNCTION ShutdownHook ;<br />
<br />
EXPORT OBJECT EE_oo_ErrorHook_ServiceID ;<br />
EXPORT OBJECT EE_oo_ErrorHook_data ;<br />
<br />
...<br />
<br />
To inform the build system to use an export file for a given core change the '''COMPILER_TYPE''' field of '''CPU_DATA''' OIL container, in the following way:<br />
<br />
CPU_DATA = TRICORE {<br />
ID = "master";<br />
...<br />
COMPILER_TYPE = GNU {<br />
EXPORT_FILE = "<relative path to the export file>";<br />
};<br />
...<br />
}; <br />
<br />
If this is done add explicitly '''EEOPT=EE_BUILD_SINGLE_ELF''' is no more needed.<br />
<br />
'''N.B:''' When used this approach an export files for the master core have to be provided always. The file can be empty if no symbols have to be exported by master core.<br />
<br />
This build approach is showed on following RT-Druid TriCore templates:<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test''<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore Spinlocks test''<br />
<br />
= Additional Notes =<br />
<br />
Since ERIKA 2.4.0 full AUTOSAR SC4 OS support for AURIX is publically released: you can find all the information about the implemented features and how to configure them at this page: [[Erika AUTOSAR OS]].</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=Infineon_AurixInfineon Aurix2017-11-21T11:07:31Z<p>Eguidieri: /* Compilers Notes */</p>
<hr />
<div>[[Category:Supported Devices]]<br />
= Infineon Aurix support =<br />
<br />
ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid will be released soon.<br />
Currently only the TC27x AURIX family have been fully ported: <br />
<br />
# Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers:<br />
** HIGHTEC GCC Compiler v4.6.3.1 (for both Single and Multicore). '''NOTE Version 4.6.3.0 DOES NOT WORK!!!''' (it has a problem on Tricore header files)<br />
** TASKING VX-toolset for TriCore v4.0r1 (only for Singlecore).<br />
** WIND RIVER DIAB Compiler Rel. 5.9.2.0 (only for Singlecore). <br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: It follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ 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.<br />
<br />
* '''CYGWIN'''<br />
** '''Under Cygwin environment you MUST use make command version 4.2.1 or above'''<br />
<br />
=== MCU & Board ===<br />
* The porting have been completly developed on top of:<br />
** TriBoard TC2x5 v2.0 equiped with a TC275TE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC264DE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC297TA MCU (ask info AT evidence DOT eu DOT com)<br />
<br />
= Target Configuration and Programming =<br />
<br />
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]. Here are listed, after the information to set compiler path, the OIL fields customized for Tricore Aurix architecture.<br />
<br />
=== Compiler Path ===<br />
<br />
It is possible to choose the path of the compiler in three different ways:<br />
<br />
* ''PATH enviornment variable'': You can put compilers bin directories in PATH and the environmet can use them from here. <br />
* ''Compiler specific environment variables'':<br />
** '''HIGHTEC GCC toolchain''': You can specify the compiler path for HIGHTEC GCC with the '''TRICORE_GCCDIR'''.<br />
** '''Altium TASKING toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_TASKINGDIR'''.<br />
** '''Wind River Diab toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_DIABDIR'''.<br />
* ''RT-Druid configuration file'' see [[RT-Druid configuration#Compiler paths]]:<br />
** '''preference_tricore__path_for_gnu_compiler''' set HIGHTEC gcc compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_tasking_compiler''' set Altium TASKING compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_diab_compiler''' set Wind River Diab compiler path for Tricore AURIX[[#Compilers Notes|<sup>[a]</sup>]]<br />
<br />
Here is an [[Common oil.pref example|example of RT-Druid configuration file]].<br />
<br />
=== CPU ===<br />
<br />
'''CPU_DATA''' must be set to '''TRICORE'''.<br />
The compiler is specificed with the '''COMPILER_TYPE''' item, supported values are '''GNU''' (the default value) and '''TASKING'''.<br />
<br />
On multicore systems, one '''CPU_DATA''' instance can exist for each core. They must have different '''ID'''s. 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.<br />
<br />
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.<br />
We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value.<br />
In any case max declared CPU clock value (i.e. 200 Mhz for TC27x & TC26x families), is guaranteed to be perfectly matched.<br />
<br />
'''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.<br />
<br />
Moreover a new field to declare a custom linker script have been added to CPU_DATA block: '''LINKERSCRIPT = "fake.ld";'''<br />
<br />
Example of a CPU_DATA section:<br />
<br />
CPU_DATA = TRICORE {<br />
CPU_CLOCK = 200.0;<br />
APP_SRC = "code.c";<br />
COMPILER_TYPE = GNU;<br />
MULTI_STACK = TRUE {<br />
IRQ_STACK = TRUE {<br />
SYS_SIZE = 128;<br />
};<br />
};<br />
};<br />
<br />
=== MCU ===<br />
<br />
'''MCU_DATA''' supports the '''TC27x''', '''TC27xA''', '''TC27xB''', '''TC27xC''' and '''TC26x''' values. Compiler can be specified even in '''MCU_DATA''' block and will inherited by all configured CPUs (useful in multicore project configuration).<br />
<br />
Note: due to a currupted register file of GNU compiler ( HighTec GCC Version 4.9.x.x ), the compiling of '''TC27x''' and '''TC27xA''' MCU models is broken.<br />
<br />
MCU_DATA = TRICORE {<br />
MODEL = TC27x;<br />
COMPILER_TYPE = GNU;<br />
};<br />
<br />
=== BOARD ===<br />
<br />
There is only support form TriBoard TC2x5. 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 (corresponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector). Add the following OIL field to enable this support.<br />
<br />
BOARD_DATA = TRIBOARD_TC2X5;<br />
<br />
=== Interrupt Handling ===<br />
<br />
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.<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
HANDLER = "isr_low"; <br />
};<br />
<br />
The mean of the fields are:<br />
*'''CATEGORY''': the type of ISR as specified by OSEK. <br />
*'''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.<br />
*'''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).<br />
<br />
=== Trap Handling ===<br />
<br />
With TriCore AURIX, for the first time, we support the options to register handler for TRAP/Exceptions. OSEK OIL do not provide any field for trap handling: it suppose that all the handling is done inside the Kernel. Usually that's what happens, but sometime can be useful have some mechanism to attach an handler for a particular class of TRAPs.<br />
<br />
We decide to exetend ISR entry with the field '''TRAP''' that can be set to TRUE to enable TRAP handling. In this case you have to choose the TRAP class with the field LEVEL (or ENTRY). The only valid values for this configuration are:<br />
<br />
*'''TRAP_MMU''' (Actually useless because TC27x and TC26x families don't have MMU, just a place holder)<br />
*'''TRAP_PROT''' (Handler for protection traps)<br />
*'''TRAP_INST''' (Handler for instructions traps)<br />
*'''TRAP_CONT''' (Handler for context traps) <br />
*'''TRAP_BUS''' (Handler forn bus traps)<br />
*'''TRAP_ASS''' (Handler for assertion traps) (please don't be silly :))<br />
*'''TRAP_SYS''' (Handler for system calls)<br />
*'''TRAP_NMI''' (Handler for NMI trap)<br />
<br />
OIL TRAP configuration example:<br />
<br />
ISR trap_context {<br />
LEVEL = "TRAP_CONT";<br />
HANDLER = "EE_trap_context"; //Trap handler<br />
TRAP = TRUE;<br />
};<br />
<br />
To define the handler in your code, you have to use the following syntax:<br />
<br />
TRAP(EE_CLASS_TRAPCONT, EE_trap_context) {<br />
while(1) {<br />
; /* dummy */<br />
}<br />
}<br />
<br />
TRAP class identifiers are the following:<br />
<br />
*EE_CLASS_TRAPMMU<br />
*EE_CLASS_TRAPPROT<br />
*EE_CLASS_TRAPINST<br />
*EE_CLASS_TRAPCONT<br />
*EE_CLASS_TRAPBUS<br />
*EE_CLASS_TRAPASS<br />
*EE_CLASS_TRAPSYS<br />
*EE_CLASS_TRAPNMI<br />
<br />
Inside the TRAP handler TIN (Trap Identification Number) value can be accessed with '''EE_tc_get_TIN()''' function or, for HIGHTEC GNUC Compiler, with the local variable '''tin'''. For more information you can check the '''$(ee)/pkg/cpu/tricore/inc/ee_tc_trap.h''' file.<br />
<br />
=== EEOPT ===<br />
<br />
EEOPT is a way to specify configuration flags to the Erika build environment.<br />
EEOPTs can be specified as strings in the OS section of the OIL file. Examples:<br />
<br />
EE_OPT = "EE_DEBUG";<br />
EE_OPT = "__ASSERT__";<br />
<br />
Please notice that spelling inside the OIL file includes an underscore: EE_OPT.<br />
<br />
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.<br />
<br />
The following EEOPTs are specific of AURIX Architecture:<br />
* '''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.<br />
* '''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.<br />
* '''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'''.<br />
* '''EE_ICACHE_ENABLED''': Enable the instruction cache in start-up code.<br />
* '''EE_DCACHE_ENABLED''': Enable data cache in start-up code<br />
<br />
= OSEK/VDX Extensions =<br />
<br />
This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.<br />
<br />
=== Resource Managament at ISR level ===<br />
<br />
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:<br />
<br />
TASK Task1 {<br />
...<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
ISR <SYMBOL> {<br />
PRIORITY = <PRIORITY_LEVEL>;<br />
CATEGORY = <ISR_TYPE>;<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };<br />
<br />
=== System Timer ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive '''IncrementCounter'''.<br />
<br />
The following is an example OIL definition for a System Counter:<br />
<br />
CPU_DATA = TRICORE{<br />
CPU_CLOCK = 200.0;<br />
...<br />
};<br />
<br />
COUNTER SystemTimer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM_SR0";<br />
SYSTEM_TIMER = TRUE;<br />
PRIORITY = 1;<br />
};<br />
SECONDSPERTICK = 0.001;<br />
};<br />
<br />
The meaning of the various attributes is as follows:<br />
* '''CPU_DATA/CPU_CLOCK''' is used to declare the clock frequency (in MHZ).<br />
* '''COUNTER/TYPE''' must be set to '''HARDWARE''', and '''SYSTEM_TIMER''' must be set to true.<br />
* '''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'''<br />
* '''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'''.<br />
* '''COUNTER/SECONDSPERTICK''' is used to declare the wanted time duration of one hardware tick in seconds.<br />
<br />
The System Timer can be attached to ALARMs as usual, as in the following example:<br />
<br />
ALARM AlarmExample {<br />
COUNTER = SystemTimer;<br />
ACTION = ACTIVATETASK{<br />
TASK = TaskExample;<br />
};<br />
};<br />
<br />
= CPU MCU & BOARD API =<br />
<br />
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'''.<br />
<br />
=== CPU API ===<br />
<br />
CPU layer represent all the behaviour shared between all the families of AURIX MCUs. 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.<br />
<br />
* '''void EE_tc_endint_disable( void )''': Temporary disable ENDINT protection.<br />
* '''void EE_tc_endint_enable( void )''': Re-enable ENDINT protection.<br />
<br />
* '''void EE_tc_safety_endinit_disable( void )''': Temporary disable SAFETY_ENDINIT protection.<br />
* '''void EE_tc_safety_endinit_enable( void )''': Re-enable SAFETY_ENDINIT protection.<br />
<br />
=== MCU API ===<br />
<br />
MCU layer represent the behaviour tied to an specific AURIX family of MCUs. For now only family TC27x is supported.<br />
Most part of the utilities belong to this layer:<br />
<br />
* '''void EE_tc2Yx_get_clock ( void )''': Return CPU clock frequency in HZ.<br />
* '''void EE_tc2Yx_configure_clock( EE_UREG fclock )''': Make the best effort to set CPU clock frequency to fclock value. It's the function used by '''StartOS''' when a '''CPU_CLOCK''' is configured in '''CPU_DATA'''.<br />
* '''void EE_tc2Yx_delay ( EE_UREG usec )''': Implement a busy loop wait of '''usec''' micorseconds.<br />
* '''void EE_tc2Yx_stm_set_sr0( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 0''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc2Yx_stm_set_sr0_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 0 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
* '''void EE_tc2Yx_stm_set_sr1( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 1''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc2Yx_stm_set_sr1_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 1 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
<br />
'''SR0''' and '''SR1''' API are both available to the user if '''System Timer''' is '''not''' configured. Otherwise only the one not used by system timer will be available.<br />
<br />
=== Board API ===<br />
<br />
BOARD layer represent the specific board support. There is only aminimal support for TriBoard TC2x5 v2.0 equiped with a TC275TE MCU:<br />
<br />
* '''void EE_tc2x5_leds_init( void )''': Initialize the 8 boards leds.<br />
* '''void EE_tc2x5_leds_on( void )''': Turns all the 8 leds.<br />
* '''void EE_tc2x5_leds_off( void )''': Turns off all the 8 leds.<br />
* '''void EE_tc2x5_turn_led(enum EE_tc2x5_led_id led_id, enum EE_tc2x5_led_status onoff)''': Turn the status of the led '''led_id''' (led IDs are collected in an enum in the form: '''EE_TRIBOARD_2X5_LED_{x}''' with {x}=[1..8]) on (onoff == '''EE_TRIBOARD_2X5_LED_ON''') or off (onoff == '''EE_TRIBOARD_2X5_LED_OFF''').<br />
* '''EE_BIT EE_tc2x5_read_button( void ): read external button value<br />
* '''void EE_tc2x5_button_irq_init( EE_TYPEISR2PRIO intvec )''': Configure the external button has an interrupt source and tie it to '''intvec''' priority handler.<br />
* '''void EE_tc2x5_button_irq_clear_request( void )''': Clear external button interrupt request.<br />
<br />
External button have to be connected to pin P15.8 on TC275TE corrisponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector of TriBoard TC2x5.<br />
<br />
= Debugger support =<br />
<br />
* [[Lauterbach TRACE32 Support for Infineon Aurix]]<br />
* [[iSYSTEM winIDEA Support for Infineon Aurix]]<br />
<br />
= Multicore Autosar OS Support =<br />
<br />
For details please see the following page: [[Erika AUTOSAR OS]]<br />
<br />
=== Build Multicore Application Single ELF with HighTec GCC Compiler ===<br />
<br />
The conventional ERIKA multicore build chain generate an ELF file for each core and the real application image is loaded on the device by Lauterbach, trought scripts. This approach is not straightforwardly portable on other programmer tools. Fortunately HighTec GCC Compiler has some peculiar features that have allowed us to change this approach, and for TriCore is possible to compile a Multicore Application contained in a single ELF.<br />
<br />
To enable this new build method add the following '''EEOPT=EE_BUILD_SINGLE_ELF''' to the project OIL file.<br />
<br />
To export some symbols from a core an '''HighTec GCC export file''' is needed. An HighTec export file looks like this:<br />
<br />
EXPORT FUNCTION _START ;<br />
EXPORT FUNCTION ErrorHook ;<br />
EXPORT FUNCTION StartupHook ;<br />
EXPORT FUNCTION ShutdownHook ;<br />
<br />
EXPORT OBJECT EE_oo_ErrorHook_ServiceID ;<br />
EXPORT OBJECT EE_oo_ErrorHook_data ;<br />
<br />
...<br />
<br />
To inform the build system to use an export file for a given core change the '''COMPILER_TYPE''' field of '''CPU_DATA''' OIL container, in the following way:<br />
<br />
CPU_DATA = TRICORE {<br />
ID = "master";<br />
...<br />
COMPILER_TYPE = GNU {<br />
EXPORT_FILE = "<relative path to the export file>";<br />
};<br />
...<br />
}; <br />
<br />
If this is done add explicitly '''EEOPT=EE_BUILD_SINGLE_ELF''' is no more needed.<br />
<br />
'''N.B:''' When used this approach an export files for the master core have to be provided always. The file can be empty if no symbols have to be exported by master core.<br />
<br />
This build approach is showed on following RT-Druid TriCore templates:<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test''<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore Spinlocks test''<br />
<br />
= Additional Notes =<br />
<br />
Since ERIKA 2.4.0 full AUTOSAR SC4 OS support for AURIX is publically released: you can find all the information about the implemented features and how to configure them at this page: [[Erika AUTOSAR OS]].</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=Infineon_AurixInfineon Aurix2017-07-19T08:46:26Z<p>Eguidieri: /* Infineon Aurix support */</p>
<hr />
<div>[[Category:Supported Devices]]<br />
= Infineon Aurix support =<br />
<br />
ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid will be released soon.<br />
Currently only the TC27x AURIX family have been fully ported: <br />
<br />
# Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers:<br />
** HIGHTEC GCC Compiler v4.6.3.1 (for both Single and Multicore). '''NOTE Version 4.6.3.0 DOES NOT WORK!!!''' (it has a problem on Tricore header files)<br />
** TASKING VX-toolset for TriCore v4.0r1 (only for Singlecore).<br />
** WIND RIVER DIAB Compiler Rel. 5.9.2.0 (only for Singlecore). <br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: It follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ 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.<br />
<br />
* '''CYGWIN'''<br />
** '''Under Cygwin environment you MUST use make command version 4.2.1 or above'''<br />
<br />
=== MCU & Board ===<br />
* The porting have been completly developed on top of:<br />
** TriBoard TC2x5 v2.0 equiped with a TC275TE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC264DE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC297TA MCU (ask info AT evidence DOT eu DOT com)<br />
<br />
= Target Configuration and Programming =<br />
<br />
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]. Here are listed, after the information to set compiler path, the OIL fields customized for Tricore Aurix architecture.<br />
<br />
=== Compiler Path ===<br />
<br />
It is possible to choose the path of the compiler in three different ways:<br />
<br />
* ''PATH enviornment variable'': You can put compilers bin directories in PATH and the environmet can use them from here. <br />
* ''Compiler specific environment variables'':<br />
** '''HIGHTEC GCC toolchain''': You can specify the compiler path for HIGHTEC GCC with the '''TRICORE_GCCDIR'''.<br />
** '''Altium TASKING toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_TASKINGDIR'''.<br />
** '''Wind River Diab toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_DIABDIR'''.<br />
* ''RT-Druid configuration file'' see [[RT-Druid configuration#Compiler paths]]:<br />
** '''preference_tricore__path_for_gnu_compiler''' set HIGHTEC gcc compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_tasking_compiler''' set Altium TASKING compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_diab_compiler''' set Wind River Diab compiler path for Tricore AURIX[[#Compilers Notes|<sup>[a]</sup>]]<br />
<br />
Here is an [[Common oil.pref example|example of RT-Druid configuration file]].<br />
<br />
==== Compilers Notes ====<br />
* [a] RT-Druid support for Diab will be released ASAP.<br />
<br />
=== CPU ===<br />
<br />
'''CPU_DATA''' must be set to '''TRICORE'''.<br />
The compiler is specificed with the '''COMPILER_TYPE''' item, supported values are '''GNU''' (the default value) and '''TASKING'''.<br />
<br />
On multicore systems, one '''CPU_DATA''' instance can exist for each core. They must have different '''ID'''s. 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.<br />
<br />
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.<br />
We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value.<br />
In any case max declared CPU clock value (i.e. 200 Mhz for TC27x & TC26x families), is guaranteed to be perfectly matched.<br />
<br />
'''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.<br />
<br />
Moreover a new field to declare a custom linker script have been added to CPU_DATA block: '''LINKERSCRIPT = "fake.ld";'''<br />
<br />
Example of a CPU_DATA section:<br />
<br />
CPU_DATA = TRICORE {<br />
CPU_CLOCK = 200.0;<br />
APP_SRC = "code.c";<br />
COMPILER_TYPE = GNU;<br />
MULTI_STACK = TRUE {<br />
IRQ_STACK = TRUE {<br />
SYS_SIZE = 128;<br />
};<br />
};<br />
};<br />
<br />
=== MCU ===<br />
<br />
'''MCU_DATA''' support the '''TC27x''' and '''TC26x''' values. Compiler can be specified even in '''MCU_DATA''' block and will inherited by all configured CPUs (useful in multicore project configuration).<br />
<br />
MCU_DATA = TRICORE {<br />
MODEL = TC27x;<br />
COMPILER_TYPE = GNU;<br />
};<br />
<br />
=== BOARD ===<br />
<br />
There is only support form TriBoard TC2x5. 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 (corresponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector). Add the following OIL field to enable this support.<br />
<br />
BOARD_DATA = TRIBOARD_TC2X5;<br />
<br />
=== Interrupt Handling ===<br />
<br />
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.<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
HANDLER = "isr_low"; <br />
};<br />
<br />
The mean of the fields are:<br />
*'''CATEGORY''': the type of ISR as specified by OSEK. <br />
*'''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.<br />
*'''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).<br />
<br />
=== Trap Handling ===<br />
<br />
With TriCore AURIX, for the first time, we support the options to register handler for TRAP/Exceptions. OSEK OIL do not provide any field for trap handling: it suppose that all the handling is done inside the Kernel. Usually that's what happens, but sometime can be useful have some mechanism to attach an handler for a particular class of TRAPs.<br />
<br />
We decide to exetend ISR entry with the field '''TRAP''' that can be set to TRUE to enable TRAP handling. In this case you have to choose the TRAP class with the field LEVEL (or ENTRY). The only valid values for this configuration are:<br />
<br />
*'''TRAP_MMU''' (Actually useless because TC27x and TC26x families don't have MMU, just a place holder)<br />
*'''TRAP_PROT''' (Handler for protection traps)<br />
*'''TRAP_INST''' (Handler for instructions traps)<br />
*'''TRAP_CONT''' (Handler for context traps) <br />
*'''TRAP_BUS''' (Handler forn bus traps)<br />
*'''TRAP_ASS''' (Handler for assertion traps) (please don't be silly :))<br />
*'''TRAP_SYS''' (Handler for system calls)<br />
*'''TRAP_NMI''' (Handler for NMI trap)<br />
<br />
OIL TRAP configuration example:<br />
<br />
ISR trap_context {<br />
LEVEL = "TRAP_CONT";<br />
HANDLER = "EE_trap_context"; //Trap handler<br />
TRAP = TRUE;<br />
};<br />
<br />
To define the handler in your code, you have to use the following syntax:<br />
<br />
TRAP(EE_CLASS_TRAPCONT, EE_trap_context) {<br />
while(1) {<br />
; /* dummy */<br />
}<br />
}<br />
<br />
TRAP class identifiers are the following:<br />
<br />
*EE_CLASS_TRAPMMU<br />
*EE_CLASS_TRAPPROT<br />
*EE_CLASS_TRAPINST<br />
*EE_CLASS_TRAPCONT<br />
*EE_CLASS_TRAPBUS<br />
*EE_CLASS_TRAPASS<br />
*EE_CLASS_TRAPSYS<br />
*EE_CLASS_TRAPNMI<br />
<br />
Inside the TRAP handler TIN (Trap Identification Number) value can be accessed with '''EE_tc_get_TIN()''' function or, for HIGHTEC GNUC Compiler, with the local variable '''tin'''. For more information you can check the '''$(ee)/pkg/cpu/tricore/inc/ee_tc_trap.h''' file.<br />
<br />
=== EEOPT ===<br />
<br />
EEOPT is a way to specify configuration flags to the Erika build environment.<br />
EEOPTs can be specified as strings in the OS section of the OIL file. Examples:<br />
<br />
EE_OPT = "EE_DEBUG";<br />
EE_OPT = "__ASSERT__";<br />
<br />
Please notice that spelling inside the OIL file includes an underscore: EE_OPT.<br />
<br />
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.<br />
<br />
The following EEOPTs are specific of AURIX Architecture:<br />
* '''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.<br />
* '''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.<br />
* '''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'''.<br />
* '''EE_ICACHE_ENABLED''': Enable the instruction cache in start-up code.<br />
* '''EE_DCACHE_ENABLED''': Enable data cache in start-up code<br />
<br />
= OSEK/VDX Extensions =<br />
<br />
This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.<br />
<br />
=== Resource Managament at ISR level ===<br />
<br />
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:<br />
<br />
TASK Task1 {<br />
...<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
ISR <SYMBOL> {<br />
PRIORITY = <PRIORITY_LEVEL>;<br />
CATEGORY = <ISR_TYPE>;<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };<br />
<br />
=== System Timer ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive '''IncrementCounter'''.<br />
<br />
The following is an example OIL definition for a System Counter:<br />
<br />
CPU_DATA = TRICORE{<br />
CPU_CLOCK = 200.0;<br />
...<br />
};<br />
<br />
COUNTER SystemTimer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM_SR0";<br />
SYSTEM_TIMER = TRUE;<br />
PRIORITY = 1;<br />
};<br />
SECONDSPERTICK = 0.001;<br />
};<br />
<br />
The meaning of the various attributes is as follows:<br />
* '''CPU_DATA/CPU_CLOCK''' is used to declare the clock frequency (in MHZ).<br />
* '''COUNTER/TYPE''' must be set to '''HARDWARE''', and '''SYSTEM_TIMER''' must be set to true.<br />
* '''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'''<br />
* '''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'''.<br />
* '''COUNTER/SECONDSPERTICK''' is used to declare the wanted time duration of one hardware tick in seconds.<br />
<br />
The System Timer can be attached to ALARMs as usual, as in the following example:<br />
<br />
ALARM AlarmExample {<br />
COUNTER = SystemTimer;<br />
ACTION = ACTIVATETASK{<br />
TASK = TaskExample;<br />
};<br />
};<br />
<br />
= CPU MCU & BOARD API =<br />
<br />
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'''.<br />
<br />
=== CPU API ===<br />
<br />
CPU layer represent all the behaviour shared between all the families of AURIX MCUs. 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.<br />
<br />
* '''void EE_tc_endint_disable( void )''': Temporary disable ENDINT protection.<br />
* '''void EE_tc_endint_enable( void )''': Re-enable ENDINT protection.<br />
<br />
* '''void EE_tc_safety_endinit_disable( void )''': Temporary disable SAFETY_ENDINIT protection.<br />
* '''void EE_tc_safety_endinit_enable( void )''': Re-enable SAFETY_ENDINIT protection.<br />
<br />
=== MCU API ===<br />
<br />
MCU layer represent the behaviour tied to an specific AURIX family of MCUs. For now only family TC27x is supported.<br />
Most part of the utilities belong to this layer:<br />
<br />
* '''void EE_tc2Yx_get_clock ( void )''': Return CPU clock frequency in HZ.<br />
* '''void EE_tc2Yx_configure_clock( EE_UREG fclock )''': Make the best effort to set CPU clock frequency to fclock value. It's the function used by '''StartOS''' when a '''CPU_CLOCK''' is configured in '''CPU_DATA'''.<br />
* '''void EE_tc2Yx_delay ( EE_UREG usec )''': Implement a busy loop wait of '''usec''' micorseconds.<br />
* '''void EE_tc2Yx_stm_set_sr0( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 0''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc2Yx_stm_set_sr0_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 0 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
* '''void EE_tc2Yx_stm_set_sr1( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 1''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc2Yx_stm_set_sr1_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 1 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
<br />
'''SR0''' and '''SR1''' API are both available to the user if '''System Timer''' is '''not''' configured. Otherwise only the one not used by system timer will be available.<br />
<br />
=== Board API ===<br />
<br />
BOARD layer represent the specific board support. There is only aminimal support for TriBoard TC2x5 v2.0 equiped with a TC275TE MCU:<br />
<br />
* '''void EE_tc2x5_leds_init( void )''': Initialize the 8 boards leds.<br />
* '''void EE_tc2x5_leds_on( void )''': Turns all the 8 leds.<br />
* '''void EE_tc2x5_leds_off( void )''': Turns off all the 8 leds.<br />
* '''void EE_tc2x5_turn_led(enum EE_tc2x5_led_id led_id, enum EE_tc2x5_led_status onoff)''': Turn the status of the led '''led_id''' (led IDs are collected in an enum in the form: '''EE_TRIBOARD_2X5_LED_{x}''' with {x}=[1..8]) on (onoff == '''EE_TRIBOARD_2X5_LED_ON''') or off (onoff == '''EE_TRIBOARD_2X5_LED_OFF''').<br />
* '''EE_BIT EE_tc2x5_read_button( void ): read external button value<br />
* '''void EE_tc2x5_button_irq_init( EE_TYPEISR2PRIO intvec )''': Configure the external button has an interrupt source and tie it to '''intvec''' priority handler.<br />
* '''void EE_tc2x5_button_irq_clear_request( void )''': Clear external button interrupt request.<br />
<br />
External button have to be connected to pin P15.8 on TC275TE corrisponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector of TriBoard TC2x5.<br />
<br />
= Debugger support =<br />
<br />
* [[Lauterbach TRACE32 Support for Infineon Aurix]]<br />
* [[iSYSTEM winIDEA Support for Infineon Aurix]]<br />
<br />
= Multicore Autosar OS Support =<br />
<br />
For details please see the following page: [[Erika AUTOSAR OS]]<br />
<br />
=== Build Multicore Application Single ELF with HighTec GCC Compiler ===<br />
<br />
The conventional ERIKA multicore build chain generate an ELF file for each core and the real application image is loaded on the device by Lauterbach, trought scripts. This approach is not straightforwardly portable on other programmer tools. Fortunately HighTec GCC Compiler has some peculiar features that have allowed us to change this approach, and for TriCore is possible to compile a Multicore Application contained in a single ELF.<br />
<br />
To enable this new build method add the following '''EEOPT=EE_BUILD_SINGLE_ELF''' to the project OIL file.<br />
<br />
To export some symbols from a core an '''HighTec GCC export file''' is needed. An HighTec export file looks like this:<br />
<br />
EXPORT FUNCTION _START ;<br />
EXPORT FUNCTION ErrorHook ;<br />
EXPORT FUNCTION StartupHook ;<br />
EXPORT FUNCTION ShutdownHook ;<br />
<br />
EXPORT OBJECT EE_oo_ErrorHook_ServiceID ;<br />
EXPORT OBJECT EE_oo_ErrorHook_data ;<br />
<br />
...<br />
<br />
To inform the build system to use an export file for a given core change the '''COMPILER_TYPE''' field of '''CPU_DATA''' OIL container, in the following way:<br />
<br />
CPU_DATA = TRICORE {<br />
ID = "master";<br />
...<br />
COMPILER_TYPE = GNU {<br />
EXPORT_FILE = "<relative path to the export file>";<br />
};<br />
...<br />
}; <br />
<br />
If this is done add explicitly '''EEOPT=EE_BUILD_SINGLE_ELF''' is no more needed.<br />
<br />
'''N.B:''' When used this approach an export files for the master core have to be provided always. The file can be empty if no symbols have to be exported by master core.<br />
<br />
This build approach is showed on following RT-Druid TriCore templates:<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test''<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore Spinlocks test''<br />
<br />
= Additional Notes =<br />
<br />
Since ERIKA 2.4.0 full AUTOSAR SC4 OS support for AURIX is publically released: you can find all the information about the implemented features and how to configure them at this page: [[Erika AUTOSAR OS]].</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=Infineon_AurixInfineon Aurix2017-03-23T10:17:15Z<p>Eguidieri: /* CPU */</p>
<hr />
<div>[[Category:Supported Devices]]<br />
= Infineon Aurix support =<br />
<br />
ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid will be released soon.<br />
Currently only the TC27x AURIX family have been fully ported: <br />
<br />
# Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers:<br />
** HIGHTEC GCC Compiler v4.6.3.1 (for both Single and Multicore). '''NOTE Version 4.6.3.0 DOES NOT WORK!!!''' (it has a problem on Tricore header files)<br />
** TASKING VX-toolset for TriCore v4.0r1 (only for Singlecore).<br />
** WIND RIVER DIAB Compiler Rel. 5.9.2.0 (only for Singlecore). <br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: It follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ 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.<br />
<br />
=== MCU & Board ===<br />
* The porting have been completly developed on top of:<br />
** TriBoard TC2x5 v2.0 equiped with a TC275TE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC264DE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC297TA MCU (ask info AT evidence DOT eu DOT com)<br />
<br />
= Target Configuration and Programming =<br />
<br />
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]. Here are listed, after the information to set compiler path, the OIL fields customized for Tricore Aurix architecture.<br />
<br />
=== Compiler Path ===<br />
<br />
It is possible to choose the path of the compiler in three different ways:<br />
<br />
* ''PATH enviornment variable'': You can put compilers bin directories in PATH and the environmet can use them from here. <br />
* ''Compiler specific environment variables'':<br />
** '''HIGHTEC GCC toolchain''': You can specify the compiler path for HIGHTEC GCC with the '''TRICORE_GCCDIR'''.<br />
** '''Altium TASKING toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_TASKINGDIR'''.<br />
** '''Wind River Diab toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_DIABDIR'''.<br />
* ''RT-Druid configuration file'' see [[RT-Druid configuration#Compiler paths]]:<br />
** '''preference_tricore__path_for_gnu_compiler''' set HIGHTEC gcc compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_tasking_compiler''' set Altium TASKING compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_diab_compiler''' set Wind River Diab compiler path for Tricore AURIX[[#Compilers Notes|<sup>[a]</sup>]]<br />
<br />
Here is an [[Common oil.pref example|example of RT-Druid configuration file]].<br />
<br />
==== Compilers Notes ====<br />
* [a] RT-Druid support for Diab will be released ASAP.<br />
<br />
=== CPU ===<br />
<br />
'''CPU_DATA''' must be set to '''TRICORE'''.<br />
The compiler is specificed with the '''COMPILER_TYPE''' item, supported values are '''GNU''' (the default value) and '''TASKING'''.<br />
<br />
On multicore systems, one '''CPU_DATA''' instance can exist for each core. They must have different '''ID'''s. 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.<br />
<br />
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.<br />
We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value.<br />
In any case max declared CPU clock value (i.e. 200 Mhz for TC27x & TC26x families), is guaranteed to be perfectly matched.<br />
<br />
'''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.<br />
<br />
Moreover a new field to declare a custom linker script have been added to CPU_DATA block: '''LINKERSCRIPT = "fake.ld";'''<br />
<br />
Example of a CPU_DATA section:<br />
<br />
CPU_DATA = TRICORE {<br />
CPU_CLOCK = 200.0;<br />
APP_SRC = "code.c";<br />
COMPILER_TYPE = GNU;<br />
MULTI_STACK = TRUE {<br />
IRQ_STACK = TRUE {<br />
SYS_SIZE = 128;<br />
};<br />
};<br />
};<br />
<br />
=== MCU ===<br />
<br />
'''MCU_DATA''' support the '''TC27x''' and '''TC26x''' values. Compiler can be specified even in '''MCU_DATA''' block and will inherited by all configured CPUs (useful in multicore project configuration).<br />
<br />
MCU_DATA = TRICORE {<br />
MODEL = TC27x;<br />
COMPILER_TYPE = GNU;<br />
};<br />
<br />
=== BOARD ===<br />
<br />
There is only support form TriBoard TC2x5. 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 (corresponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector). Add the following OIL field to enable this support.<br />
<br />
BOARD_DATA = TRIBOARD_TC2X5;<br />
<br />
=== Interrupt Handling ===<br />
<br />
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.<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
HANDLER = "isr_low"; <br />
};<br />
<br />
The mean of the fields are:<br />
*'''CATEGORY''': the type of ISR as specified by OSEK. <br />
*'''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.<br />
*'''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).<br />
<br />
=== Trap Handling ===<br />
<br />
With TriCore AURIX, for the first time, we support the options to register handler for TRAP/Exceptions. OSEK OIL do not provide any field for trap handling: it suppose that all the handling is done inside the Kernel. Usually that's what happens, but sometime can be useful have some mechanism to attach an handler for a particular class of TRAPs.<br />
<br />
We decide to exetend ISR entry with the field '''TRAP''' that can be set to TRUE to enable TRAP handling. In this case you have to choose the TRAP class with the field LEVEL (or ENTRY). The only valid values for this configuration are:<br />
<br />
*'''TRAP_MMU''' (Actually useless because TC27x and TC26x families don't have MMU, just a place holder)<br />
*'''TRAP_PROT''' (Handler for protection traps)<br />
*'''TRAP_INST''' (Handler for instructions traps)<br />
*'''TRAP_CONT''' (Handler for context traps) <br />
*'''TRAP_BUS''' (Handler forn bus traps)<br />
*'''TRAP_ASS''' (Handler for assertion traps) (please don't be silly :))<br />
*'''TRAP_SYS''' (Handler for system calls)<br />
*'''TRAP_NMI''' (Handler for NMI trap)<br />
<br />
OIL TRAP configuration example:<br />
<br />
ISR trap_context {<br />
LEVEL = "TRAP_CONT";<br />
HANDLER = "EE_trap_context"; //Trap handler<br />
TRAP = TRUE;<br />
};<br />
<br />
To define the handler in your code, you have to use the following syntax:<br />
<br />
TRAP(EE_CLASS_TRAPCONT, EE_trap_context) {<br />
while(1) {<br />
; /* dummy */<br />
}<br />
}<br />
<br />
TRAP class identifiers are the following:<br />
<br />
*EE_CLASS_TRAPMMU<br />
*EE_CLASS_TRAPPROT<br />
*EE_CLASS_TRAPINST<br />
*EE_CLASS_TRAPCONT<br />
*EE_CLASS_TRAPBUS<br />
*EE_CLASS_TRAPASS<br />
*EE_CLASS_TRAPSYS<br />
*EE_CLASS_TRAPNMI<br />
<br />
Inside the TRAP handler TIN (Trap Identification Number) value can be accessed with '''EE_tc_get_TIN()''' function or, for HIGHTEC GNUC Compiler, with the local variable '''tin'''. For more information you can check the '''$(ee)/pkg/cpu/tricore/inc/ee_tc_trap.h''' file.<br />
<br />
=== EEOPT ===<br />
<br />
EEOPT is a way to specify configuration flags to the Erika build environment.<br />
EEOPTs can be specified as strings in the OS section of the OIL file. Examples:<br />
<br />
EE_OPT = "EE_DEBUG";<br />
EE_OPT = "__ASSERT__";<br />
<br />
Please notice that spelling inside the OIL file includes an underscore: EE_OPT.<br />
<br />
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.<br />
<br />
The following EEOPTs are specific of AURIX Architecture:<br />
* '''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.<br />
* '''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.<br />
* '''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'''.<br />
* '''EE_ICACHE_ENABLED''': Enable the instruction cache in start-up code.<br />
* '''EE_DCACHE_ENABLED''': Enable data cache in start-up code<br />
<br />
= OSEK/VDX Extensions =<br />
<br />
This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.<br />
<br />
=== Resource Managament at ISR level ===<br />
<br />
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:<br />
<br />
TASK Task1 {<br />
...<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
ISR <SYMBOL> {<br />
PRIORITY = <PRIORITY_LEVEL>;<br />
CATEGORY = <ISR_TYPE>;<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };<br />
<br />
=== System Timer ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive '''IncrementCounter'''.<br />
<br />
The following is an example OIL definition for a System Counter:<br />
<br />
CPU_DATA = TRICORE{<br />
CPU_CLOCK = 200.0;<br />
...<br />
};<br />
<br />
COUNTER SystemTimer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM_SR0";<br />
SYSTEM_TIMER = TRUE;<br />
PRIORITY = 1;<br />
};<br />
SECONDSPERTICK = 0.001;<br />
};<br />
<br />
The meaning of the various attributes is as follows:<br />
* '''CPU_DATA/CPU_CLOCK''' is used to declare the clock frequency (in MHZ).<br />
* '''COUNTER/TYPE''' must be set to '''HARDWARE''', and '''SYSTEM_TIMER''' must be set to true.<br />
* '''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'''<br />
* '''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'''.<br />
* '''COUNTER/SECONDSPERTICK''' is used to declare the wanted time duration of one hardware tick in seconds.<br />
<br />
The System Timer can be attached to ALARMs as usual, as in the following example:<br />
<br />
ALARM AlarmExample {<br />
COUNTER = SystemTimer;<br />
ACTION = ACTIVATETASK{<br />
TASK = TaskExample;<br />
};<br />
};<br />
<br />
= CPU MCU & BOARD API =<br />
<br />
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'''.<br />
<br />
=== CPU API ===<br />
<br />
CPU layer represent all the behaviour shared between all the families of AURIX MCUs. 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.<br />
<br />
* '''void EE_tc_endint_disable( void )''': Temporary disable ENDINT protection.<br />
* '''void EE_tc_endint_enable( void )''': Re-enable ENDINT protection.<br />
<br />
* '''void EE_tc_safety_endinit_disable( void )''': Temporary disable SAFETY_ENDINIT protection.<br />
* '''void EE_tc_safety_endinit_enable( void )''': Re-enable SAFETY_ENDINIT protection.<br />
<br />
=== MCU API ===<br />
<br />
MCU layer represent the behaviour tied to an specific AURIX family of MCUs. For now only family TC27x is supported.<br />
Most part of the utilities belong to this layer:<br />
<br />
* '''void EE_tc2Yx_get_clock ( void )''': Return CPU clock frequency in HZ.<br />
* '''void EE_tc2Yx_configure_clock( EE_UREG fclock )''': Make the best effort to set CPU clock frequency to fclock value. It's the function used by '''StartOS''' when a '''CPU_CLOCK''' is configured in '''CPU_DATA'''.<br />
* '''void EE_tc2Yx_delay ( EE_UREG usec )''': Implement a busy loop wait of '''usec''' micorseconds.<br />
* '''void EE_tc2Yx_stm_set_sr0( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 0''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc2Yx_stm_set_sr0_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 0 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
* '''void EE_tc2Yx_stm_set_sr1( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 1''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc2Yx_stm_set_sr1_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 1 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
<br />
'''SR0''' and '''SR1''' API are both available to the user if '''System Timer''' is '''not''' configured. Otherwise only the one not used by system timer will be available.<br />
<br />
=== Board API ===<br />
<br />
BOARD layer represent the specific board support. There is only aminimal support for TriBoard TC2x5 v2.0 equiped with a TC275TE MCU:<br />
<br />
* '''void EE_tc2x5_leds_init( void )''': Initialize the 8 boards leds.<br />
* '''void EE_tc2x5_leds_on( void )''': Turns all the 8 leds.<br />
* '''void EE_tc2x5_leds_off( void )''': Turns off all the 8 leds.<br />
* '''void EE_tc2x5_turn_led(enum EE_tc2x5_led_id led_id, enum EE_tc2x5_led_status onoff)''': Turn the status of the led '''led_id''' (led IDs are collected in an enum in the form: '''EE_TRIBOARD_2X5_LED_{x}''' with {x}=[1..8]) on (onoff == '''EE_TRIBOARD_2X5_LED_ON''') or off (onoff == '''EE_TRIBOARD_2X5_LED_OFF''').<br />
* '''EE_BIT EE_tc2x5_read_button( void ): read external button value<br />
* '''void EE_tc2x5_button_irq_init( EE_TYPEISR2PRIO intvec )''': Configure the external button has an interrupt source and tie it to '''intvec''' priority handler.<br />
* '''void EE_tc2x5_button_irq_clear_request( void )''': Clear external button interrupt request.<br />
<br />
External button have to be connected to pin P15.8 on TC275TE corrisponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector of TriBoard TC2x5.<br />
<br />
= Debugger support =<br />
<br />
* [[Lauterbach TRACE32 Support for Infineon Aurix]]<br />
* [[iSYSTEM winIDEA Support for Infineon Aurix]]<br />
<br />
= Multicore Autosar OS Support =<br />
<br />
For details please see the following page: [[Erika AUTOSAR OS]]<br />
<br />
=== Build Multicore Application Single ELF with HighTec GCC Compiler ===<br />
<br />
The conventional ERIKA multicore build chain generate an ELF file for each core and the real application image is loaded on the device by Lauterbach, trought scripts. This approach is not straightforwardly portable on other programmer tools. Fortunately HighTec GCC Compiler has some peculiar features that have allowed us to change this approach, and for TriCore is possible to compile a Multicore Application contained in a single ELF.<br />
<br />
To enable this new build method add the following '''EEOPT=EE_BUILD_SINGLE_ELF''' to the project OIL file.<br />
<br />
To export some symbols from a core an '''HighTec GCC export file''' is needed. An HighTec export file looks like this:<br />
<br />
EXPORT FUNCTION _START ;<br />
EXPORT FUNCTION ErrorHook ;<br />
EXPORT FUNCTION StartupHook ;<br />
EXPORT FUNCTION ShutdownHook ;<br />
<br />
EXPORT OBJECT EE_oo_ErrorHook_ServiceID ;<br />
EXPORT OBJECT EE_oo_ErrorHook_data ;<br />
<br />
...<br />
<br />
To inform the build system to use an export file for a given core change the '''COMPILER_TYPE''' field of '''CPU_DATA''' OIL container, in the following way:<br />
<br />
CPU_DATA = TRICORE {<br />
ID = "master";<br />
...<br />
COMPILER_TYPE = GNU {<br />
EXPORT_FILE = "<relative path to the export file>";<br />
};<br />
...<br />
}; <br />
<br />
If this is done add explicitly '''EEOPT=EE_BUILD_SINGLE_ELF''' is no more needed.<br />
<br />
'''N.B:''' When used this approach an export files for the master core have to be provided always. The file can be empty if no symbols have to be exported by master core.<br />
<br />
This build approach is showed on following RT-Druid TriCore templates:<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test''<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore Spinlocks test''<br />
<br />
= Additional Notes =<br />
<br />
Since ERIKA 2.4.0 full AUTOSAR SC4 OS support for AURIX is publically released: you can find all the information about the implemented features and how to configure them at this page: [[Erika AUTOSAR OS]].</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=Infineon_AurixInfineon Aurix2017-03-23T10:15:58Z<p>Eguidieri: /* MCU API */</p>
<hr />
<div>[[Category:Supported Devices]]<br />
= Infineon Aurix support =<br />
<br />
ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid will be released soon.<br />
Currently only the TC27x AURIX family have been fully ported: <br />
<br />
# Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers:<br />
** HIGHTEC GCC Compiler v4.6.3.1 (for both Single and Multicore). '''NOTE Version 4.6.3.0 DOES NOT WORK!!!''' (it has a problem on Tricore header files)<br />
** TASKING VX-toolset for TriCore v4.0r1 (only for Singlecore).<br />
** WIND RIVER DIAB Compiler Rel. 5.9.2.0 (only for Singlecore). <br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: It follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ 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.<br />
<br />
=== MCU & Board ===<br />
* The porting have been completly developed on top of:<br />
** TriBoard TC2x5 v2.0 equiped with a TC275TE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC264DE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC297TA MCU (ask info AT evidence DOT eu DOT com)<br />
<br />
= Target Configuration and Programming =<br />
<br />
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]. Here are listed, after the information to set compiler path, the OIL fields customized for Tricore Aurix architecture.<br />
<br />
=== Compiler Path ===<br />
<br />
It is possible to choose the path of the compiler in three different ways:<br />
<br />
* ''PATH enviornment variable'': You can put compilers bin directories in PATH and the environmet can use them from here. <br />
* ''Compiler specific environment variables'':<br />
** '''HIGHTEC GCC toolchain''': You can specify the compiler path for HIGHTEC GCC with the '''TRICORE_GCCDIR'''.<br />
** '''Altium TASKING toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_TASKINGDIR'''.<br />
** '''Wind River Diab toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_DIABDIR'''.<br />
* ''RT-Druid configuration file'' see [[RT-Druid configuration#Compiler paths]]:<br />
** '''preference_tricore__path_for_gnu_compiler''' set HIGHTEC gcc compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_tasking_compiler''' set Altium TASKING compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_diab_compiler''' set Wind River Diab compiler path for Tricore AURIX[[#Compilers Notes|<sup>[a]</sup>]]<br />
<br />
Here is an [[Common oil.pref example|example of RT-Druid configuration file]].<br />
<br />
==== Compilers Notes ====<br />
* [a] RT-Druid support for Diab will be released ASAP.<br />
<br />
=== CPU ===<br />
<br />
'''CPU_DATA''' must be set to '''TRICORE'''.<br />
The compiler is specificed with the '''COMPILER_TYPE''' item, supported values are '''GNU''' (the default value) and '''TASKING'''.<br />
<br />
On multicore systems, one '''CPU_DATA''' instance can exist for each core. They must have different '''ID'''s. 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.<br />
<br />
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.<br />
We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value.<br />
In any case max declared CPU clock value (i.e. 200 Mhz for TC27x family), is guaranteed to be perfectly matched.<br />
<br />
'''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.<br />
<br />
Moreover a new field to declare a custom linker script have been added to CPU_DATA block: '''LINKERSCRIPT = "fake.ld";'''<br />
<br />
Example of a CPU_DATA section:<br />
<br />
CPU_DATA = TRICORE {<br />
CPU_CLOCK = 200.0;<br />
APP_SRC = "code.c";<br />
COMPILER_TYPE = GNU;<br />
MULTI_STACK = TRUE {<br />
IRQ_STACK = TRUE {<br />
SYS_SIZE = 128;<br />
};<br />
};<br />
};<br />
=== MCU ===<br />
<br />
'''MCU_DATA''' support the '''TC27x''' and '''TC26x''' values. Compiler can be specified even in '''MCU_DATA''' block and will inherited by all configured CPUs (useful in multicore project configuration).<br />
<br />
MCU_DATA = TRICORE {<br />
MODEL = TC27x;<br />
COMPILER_TYPE = GNU;<br />
};<br />
<br />
=== BOARD ===<br />
<br />
There is only support form TriBoard TC2x5. 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 (corresponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector). Add the following OIL field to enable this support.<br />
<br />
BOARD_DATA = TRIBOARD_TC2X5;<br />
<br />
=== Interrupt Handling ===<br />
<br />
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.<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
HANDLER = "isr_low"; <br />
};<br />
<br />
The mean of the fields are:<br />
*'''CATEGORY''': the type of ISR as specified by OSEK. <br />
*'''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.<br />
*'''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).<br />
<br />
=== Trap Handling ===<br />
<br />
With TriCore AURIX, for the first time, we support the options to register handler for TRAP/Exceptions. OSEK OIL do not provide any field for trap handling: it suppose that all the handling is done inside the Kernel. Usually that's what happens, but sometime can be useful have some mechanism to attach an handler for a particular class of TRAPs.<br />
<br />
We decide to exetend ISR entry with the field '''TRAP''' that can be set to TRUE to enable TRAP handling. In this case you have to choose the TRAP class with the field LEVEL (or ENTRY). The only valid values for this configuration are:<br />
<br />
*'''TRAP_MMU''' (Actually useless because TC27x and TC26x families don't have MMU, just a place holder)<br />
*'''TRAP_PROT''' (Handler for protection traps)<br />
*'''TRAP_INST''' (Handler for instructions traps)<br />
*'''TRAP_CONT''' (Handler for context traps) <br />
*'''TRAP_BUS''' (Handler forn bus traps)<br />
*'''TRAP_ASS''' (Handler for assertion traps) (please don't be silly :))<br />
*'''TRAP_SYS''' (Handler for system calls)<br />
*'''TRAP_NMI''' (Handler for NMI trap)<br />
<br />
OIL TRAP configuration example:<br />
<br />
ISR trap_context {<br />
LEVEL = "TRAP_CONT";<br />
HANDLER = "EE_trap_context"; //Trap handler<br />
TRAP = TRUE;<br />
};<br />
<br />
To define the handler in your code, you have to use the following syntax:<br />
<br />
TRAP(EE_CLASS_TRAPCONT, EE_trap_context) {<br />
while(1) {<br />
; /* dummy */<br />
}<br />
}<br />
<br />
TRAP class identifiers are the following:<br />
<br />
*EE_CLASS_TRAPMMU<br />
*EE_CLASS_TRAPPROT<br />
*EE_CLASS_TRAPINST<br />
*EE_CLASS_TRAPCONT<br />
*EE_CLASS_TRAPBUS<br />
*EE_CLASS_TRAPASS<br />
*EE_CLASS_TRAPSYS<br />
*EE_CLASS_TRAPNMI<br />
<br />
Inside the TRAP handler TIN (Trap Identification Number) value can be accessed with '''EE_tc_get_TIN()''' function or, for HIGHTEC GNUC Compiler, with the local variable '''tin'''. For more information you can check the '''$(ee)/pkg/cpu/tricore/inc/ee_tc_trap.h''' file.<br />
<br />
=== EEOPT ===<br />
<br />
EEOPT is a way to specify configuration flags to the Erika build environment.<br />
EEOPTs can be specified as strings in the OS section of the OIL file. Examples:<br />
<br />
EE_OPT = "EE_DEBUG";<br />
EE_OPT = "__ASSERT__";<br />
<br />
Please notice that spelling inside the OIL file includes an underscore: EE_OPT.<br />
<br />
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.<br />
<br />
The following EEOPTs are specific of AURIX Architecture:<br />
* '''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.<br />
* '''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.<br />
* '''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'''.<br />
* '''EE_ICACHE_ENABLED''': Enable the instruction cache in start-up code.<br />
* '''EE_DCACHE_ENABLED''': Enable data cache in start-up code<br />
<br />
= OSEK/VDX Extensions =<br />
<br />
This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.<br />
<br />
=== Resource Managament at ISR level ===<br />
<br />
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:<br />
<br />
TASK Task1 {<br />
...<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
ISR <SYMBOL> {<br />
PRIORITY = <PRIORITY_LEVEL>;<br />
CATEGORY = <ISR_TYPE>;<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };<br />
<br />
=== System Timer ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive '''IncrementCounter'''.<br />
<br />
The following is an example OIL definition for a System Counter:<br />
<br />
CPU_DATA = TRICORE{<br />
CPU_CLOCK = 200.0;<br />
...<br />
};<br />
<br />
COUNTER SystemTimer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM_SR0";<br />
SYSTEM_TIMER = TRUE;<br />
PRIORITY = 1;<br />
};<br />
SECONDSPERTICK = 0.001;<br />
};<br />
<br />
The meaning of the various attributes is as follows:<br />
* '''CPU_DATA/CPU_CLOCK''' is used to declare the clock frequency (in MHZ).<br />
* '''COUNTER/TYPE''' must be set to '''HARDWARE''', and '''SYSTEM_TIMER''' must be set to true.<br />
* '''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'''<br />
* '''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'''.<br />
* '''COUNTER/SECONDSPERTICK''' is used to declare the wanted time duration of one hardware tick in seconds.<br />
<br />
The System Timer can be attached to ALARMs as usual, as in the following example:<br />
<br />
ALARM AlarmExample {<br />
COUNTER = SystemTimer;<br />
ACTION = ACTIVATETASK{<br />
TASK = TaskExample;<br />
};<br />
};<br />
<br />
= CPU MCU & BOARD API =<br />
<br />
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'''.<br />
<br />
=== CPU API ===<br />
<br />
CPU layer represent all the behaviour shared between all the families of AURIX MCUs. 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.<br />
<br />
* '''void EE_tc_endint_disable( void )''': Temporary disable ENDINT protection.<br />
* '''void EE_tc_endint_enable( void )''': Re-enable ENDINT protection.<br />
<br />
* '''void EE_tc_safety_endinit_disable( void )''': Temporary disable SAFETY_ENDINIT protection.<br />
* '''void EE_tc_safety_endinit_enable( void )''': Re-enable SAFETY_ENDINIT protection.<br />
<br />
=== MCU API ===<br />
<br />
MCU layer represent the behaviour tied to an specific AURIX family of MCUs. For now only family TC27x is supported.<br />
Most part of the utilities belong to this layer:<br />
<br />
* '''void EE_tc2Yx_get_clock ( void )''': Return CPU clock frequency in HZ.<br />
* '''void EE_tc2Yx_configure_clock( EE_UREG fclock )''': Make the best effort to set CPU clock frequency to fclock value. It's the function used by '''StartOS''' when a '''CPU_CLOCK''' is configured in '''CPU_DATA'''.<br />
* '''void EE_tc2Yx_delay ( EE_UREG usec )''': Implement a busy loop wait of '''usec''' micorseconds.<br />
* '''void EE_tc2Yx_stm_set_sr0( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 0''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc2Yx_stm_set_sr0_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 0 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
* '''void EE_tc2Yx_stm_set_sr1( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 1''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc2Yx_stm_set_sr1_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 1 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
<br />
'''SR0''' and '''SR1''' API are both available to the user if '''System Timer''' is '''not''' configured. Otherwise only the one not used by system timer will be available.<br />
<br />
=== Board API ===<br />
<br />
BOARD layer represent the specific board support. There is only aminimal support for TriBoard TC2x5 v2.0 equiped with a TC275TE MCU:<br />
<br />
* '''void EE_tc2x5_leds_init( void )''': Initialize the 8 boards leds.<br />
* '''void EE_tc2x5_leds_on( void )''': Turns all the 8 leds.<br />
* '''void EE_tc2x5_leds_off( void )''': Turns off all the 8 leds.<br />
* '''void EE_tc2x5_turn_led(enum EE_tc2x5_led_id led_id, enum EE_tc2x5_led_status onoff)''': Turn the status of the led '''led_id''' (led IDs are collected in an enum in the form: '''EE_TRIBOARD_2X5_LED_{x}''' with {x}=[1..8]) on (onoff == '''EE_TRIBOARD_2X5_LED_ON''') or off (onoff == '''EE_TRIBOARD_2X5_LED_OFF''').<br />
* '''EE_BIT EE_tc2x5_read_button( void ): read external button value<br />
* '''void EE_tc2x5_button_irq_init( EE_TYPEISR2PRIO intvec )''': Configure the external button has an interrupt source and tie it to '''intvec''' priority handler.<br />
* '''void EE_tc2x5_button_irq_clear_request( void )''': Clear external button interrupt request.<br />
<br />
External button have to be connected to pin P15.8 on TC275TE corrisponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector of TriBoard TC2x5.<br />
<br />
= Debugger support =<br />
<br />
* [[Lauterbach TRACE32 Support for Infineon Aurix]]<br />
* [[iSYSTEM winIDEA Support for Infineon Aurix]]<br />
<br />
= Multicore Autosar OS Support =<br />
<br />
For details please see the following page: [[Erika AUTOSAR OS]]<br />
<br />
=== Build Multicore Application Single ELF with HighTec GCC Compiler ===<br />
<br />
The conventional ERIKA multicore build chain generate an ELF file for each core and the real application image is loaded on the device by Lauterbach, trought scripts. This approach is not straightforwardly portable on other programmer tools. Fortunately HighTec GCC Compiler has some peculiar features that have allowed us to change this approach, and for TriCore is possible to compile a Multicore Application contained in a single ELF.<br />
<br />
To enable this new build method add the following '''EEOPT=EE_BUILD_SINGLE_ELF''' to the project OIL file.<br />
<br />
To export some symbols from a core an '''HighTec GCC export file''' is needed. An HighTec export file looks like this:<br />
<br />
EXPORT FUNCTION _START ;<br />
EXPORT FUNCTION ErrorHook ;<br />
EXPORT FUNCTION StartupHook ;<br />
EXPORT FUNCTION ShutdownHook ;<br />
<br />
EXPORT OBJECT EE_oo_ErrorHook_ServiceID ;<br />
EXPORT OBJECT EE_oo_ErrorHook_data ;<br />
<br />
...<br />
<br />
To inform the build system to use an export file for a given core change the '''COMPILER_TYPE''' field of '''CPU_DATA''' OIL container, in the following way:<br />
<br />
CPU_DATA = TRICORE {<br />
ID = "master";<br />
...<br />
COMPILER_TYPE = GNU {<br />
EXPORT_FILE = "<relative path to the export file>";<br />
};<br />
...<br />
}; <br />
<br />
If this is done add explicitly '''EEOPT=EE_BUILD_SINGLE_ELF''' is no more needed.<br />
<br />
'''N.B:''' When used this approach an export files for the master core have to be provided always. The file can be empty if no symbols have to be exported by master core.<br />
<br />
This build approach is showed on following RT-Druid TriCore templates:<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test''<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore Spinlocks test''<br />
<br />
= Additional Notes =<br />
<br />
Since ERIKA 2.4.0 full AUTOSAR SC4 OS support for AURIX is publically released: you can find all the information about the implemented features and how to configure them at this page: [[Erika AUTOSAR OS]].</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=Infineon_AurixInfineon Aurix2017-03-23T10:14:30Z<p>Eguidieri: /* Trap Handling */</p>
<hr />
<div>[[Category:Supported Devices]]<br />
= Infineon Aurix support =<br />
<br />
ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid will be released soon.<br />
Currently only the TC27x AURIX family have been fully ported: <br />
<br />
# Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers:<br />
** HIGHTEC GCC Compiler v4.6.3.1 (for both Single and Multicore). '''NOTE Version 4.6.3.0 DOES NOT WORK!!!''' (it has a problem on Tricore header files)<br />
** TASKING VX-toolset for TriCore v4.0r1 (only for Singlecore).<br />
** WIND RIVER DIAB Compiler Rel. 5.9.2.0 (only for Singlecore). <br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: It follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ 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.<br />
<br />
=== MCU & Board ===<br />
* The porting have been completly developed on top of:<br />
** TriBoard TC2x5 v2.0 equiped with a TC275TE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC264DE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC297TA MCU (ask info AT evidence DOT eu DOT com)<br />
<br />
= Target Configuration and Programming =<br />
<br />
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]. Here are listed, after the information to set compiler path, the OIL fields customized for Tricore Aurix architecture.<br />
<br />
=== Compiler Path ===<br />
<br />
It is possible to choose the path of the compiler in three different ways:<br />
<br />
* ''PATH enviornment variable'': You can put compilers bin directories in PATH and the environmet can use them from here. <br />
* ''Compiler specific environment variables'':<br />
** '''HIGHTEC GCC toolchain''': You can specify the compiler path for HIGHTEC GCC with the '''TRICORE_GCCDIR'''.<br />
** '''Altium TASKING toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_TASKINGDIR'''.<br />
** '''Wind River Diab toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_DIABDIR'''.<br />
* ''RT-Druid configuration file'' see [[RT-Druid configuration#Compiler paths]]:<br />
** '''preference_tricore__path_for_gnu_compiler''' set HIGHTEC gcc compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_tasking_compiler''' set Altium TASKING compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_diab_compiler''' set Wind River Diab compiler path for Tricore AURIX[[#Compilers Notes|<sup>[a]</sup>]]<br />
<br />
Here is an [[Common oil.pref example|example of RT-Druid configuration file]].<br />
<br />
==== Compilers Notes ====<br />
* [a] RT-Druid support for Diab will be released ASAP.<br />
<br />
=== CPU ===<br />
<br />
'''CPU_DATA''' must be set to '''TRICORE'''.<br />
The compiler is specificed with the '''COMPILER_TYPE''' item, supported values are '''GNU''' (the default value) and '''TASKING'''.<br />
<br />
On multicore systems, one '''CPU_DATA''' instance can exist for each core. They must have different '''ID'''s. 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.<br />
<br />
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.<br />
We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value.<br />
In any case max declared CPU clock value (i.e. 200 Mhz for TC27x family), is guaranteed to be perfectly matched.<br />
<br />
'''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.<br />
<br />
Moreover a new field to declare a custom linker script have been added to CPU_DATA block: '''LINKERSCRIPT = "fake.ld";'''<br />
<br />
Example of a CPU_DATA section:<br />
<br />
CPU_DATA = TRICORE {<br />
CPU_CLOCK = 200.0;<br />
APP_SRC = "code.c";<br />
COMPILER_TYPE = GNU;<br />
MULTI_STACK = TRUE {<br />
IRQ_STACK = TRUE {<br />
SYS_SIZE = 128;<br />
};<br />
};<br />
};<br />
=== MCU ===<br />
<br />
'''MCU_DATA''' support the '''TC27x''' and '''TC26x''' values. Compiler can be specified even in '''MCU_DATA''' block and will inherited by all configured CPUs (useful in multicore project configuration).<br />
<br />
MCU_DATA = TRICORE {<br />
MODEL = TC27x;<br />
COMPILER_TYPE = GNU;<br />
};<br />
<br />
=== BOARD ===<br />
<br />
There is only support form TriBoard TC2x5. 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 (corresponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector). Add the following OIL field to enable this support.<br />
<br />
BOARD_DATA = TRIBOARD_TC2X5;<br />
<br />
=== Interrupt Handling ===<br />
<br />
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.<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
HANDLER = "isr_low"; <br />
};<br />
<br />
The mean of the fields are:<br />
*'''CATEGORY''': the type of ISR as specified by OSEK. <br />
*'''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.<br />
*'''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).<br />
<br />
=== Trap Handling ===<br />
<br />
With TriCore AURIX, for the first time, we support the options to register handler for TRAP/Exceptions. OSEK OIL do not provide any field for trap handling: it suppose that all the handling is done inside the Kernel. Usually that's what happens, but sometime can be useful have some mechanism to attach an handler for a particular class of TRAPs.<br />
<br />
We decide to exetend ISR entry with the field '''TRAP''' that can be set to TRUE to enable TRAP handling. In this case you have to choose the TRAP class with the field LEVEL (or ENTRY). The only valid values for this configuration are:<br />
<br />
*'''TRAP_MMU''' (Actually useless because TC27x and TC26x families don't have MMU, just a place holder)<br />
*'''TRAP_PROT''' (Handler for protection traps)<br />
*'''TRAP_INST''' (Handler for instructions traps)<br />
*'''TRAP_CONT''' (Handler for context traps) <br />
*'''TRAP_BUS''' (Handler forn bus traps)<br />
*'''TRAP_ASS''' (Handler for assertion traps) (please don't be silly :))<br />
*'''TRAP_SYS''' (Handler for system calls)<br />
*'''TRAP_NMI''' (Handler for NMI trap)<br />
<br />
OIL TRAP configuration example:<br />
<br />
ISR trap_context {<br />
LEVEL = "TRAP_CONT";<br />
HANDLER = "EE_trap_context"; //Trap handler<br />
TRAP = TRUE;<br />
};<br />
<br />
To define the handler in your code, you have to use the following syntax:<br />
<br />
TRAP(EE_CLASS_TRAPCONT, EE_trap_context) {<br />
while(1) {<br />
; /* dummy */<br />
}<br />
}<br />
<br />
TRAP class identifiers are the following:<br />
<br />
*EE_CLASS_TRAPMMU<br />
*EE_CLASS_TRAPPROT<br />
*EE_CLASS_TRAPINST<br />
*EE_CLASS_TRAPCONT<br />
*EE_CLASS_TRAPBUS<br />
*EE_CLASS_TRAPASS<br />
*EE_CLASS_TRAPSYS<br />
*EE_CLASS_TRAPNMI<br />
<br />
Inside the TRAP handler TIN (Trap Identification Number) value can be accessed with '''EE_tc_get_TIN()''' function or, for HIGHTEC GNUC Compiler, with the local variable '''tin'''. For more information you can check the '''$(ee)/pkg/cpu/tricore/inc/ee_tc_trap.h''' file.<br />
<br />
=== EEOPT ===<br />
<br />
EEOPT is a way to specify configuration flags to the Erika build environment.<br />
EEOPTs can be specified as strings in the OS section of the OIL file. Examples:<br />
<br />
EE_OPT = "EE_DEBUG";<br />
EE_OPT = "__ASSERT__";<br />
<br />
Please notice that spelling inside the OIL file includes an underscore: EE_OPT.<br />
<br />
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.<br />
<br />
The following EEOPTs are specific of AURIX Architecture:<br />
* '''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.<br />
* '''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.<br />
* '''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'''.<br />
* '''EE_ICACHE_ENABLED''': Enable the instruction cache in start-up code.<br />
* '''EE_DCACHE_ENABLED''': Enable data cache in start-up code<br />
<br />
= OSEK/VDX Extensions =<br />
<br />
This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.<br />
<br />
=== Resource Managament at ISR level ===<br />
<br />
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:<br />
<br />
TASK Task1 {<br />
...<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
ISR <SYMBOL> {<br />
PRIORITY = <PRIORITY_LEVEL>;<br />
CATEGORY = <ISR_TYPE>;<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };<br />
<br />
=== System Timer ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive '''IncrementCounter'''.<br />
<br />
The following is an example OIL definition for a System Counter:<br />
<br />
CPU_DATA = TRICORE{<br />
CPU_CLOCK = 200.0;<br />
...<br />
};<br />
<br />
COUNTER SystemTimer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM_SR0";<br />
SYSTEM_TIMER = TRUE;<br />
PRIORITY = 1;<br />
};<br />
SECONDSPERTICK = 0.001;<br />
};<br />
<br />
The meaning of the various attributes is as follows:<br />
* '''CPU_DATA/CPU_CLOCK''' is used to declare the clock frequency (in MHZ).<br />
* '''COUNTER/TYPE''' must be set to '''HARDWARE''', and '''SYSTEM_TIMER''' must be set to true.<br />
* '''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'''<br />
* '''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'''.<br />
* '''COUNTER/SECONDSPERTICK''' is used to declare the wanted time duration of one hardware tick in seconds.<br />
<br />
The System Timer can be attached to ALARMs as usual, as in the following example:<br />
<br />
ALARM AlarmExample {<br />
COUNTER = SystemTimer;<br />
ACTION = ACTIVATETASK{<br />
TASK = TaskExample;<br />
};<br />
};<br />
<br />
= CPU MCU & BOARD API =<br />
<br />
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'''.<br />
<br />
=== CPU API ===<br />
<br />
CPU layer represent all the behaviour shared between all the families of AURIX MCUs. 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.<br />
<br />
* '''void EE_tc_endint_disable( void )''': Temporary disable ENDINT protection.<br />
* '''void EE_tc_endint_enable( void )''': Re-enable ENDINT protection.<br />
<br />
* '''void EE_tc_safety_endinit_disable( void )''': Temporary disable SAFETY_ENDINIT protection.<br />
* '''void EE_tc_safety_endinit_enable( void )''': Re-enable SAFETY_ENDINIT protection.<br />
<br />
=== MCU API ===<br />
<br />
MCU layer represent the behaviour tied to an specific AURIX family of MCUs. For now only family TC27x is supported.<br />
Most part of the utilities belong to this layer:<br />
<br />
* '''void EE_tc27x_get_clock ( void )''': Return CPU clock frequency in HZ.<br />
* '''void EE_tc27x_configure_clock( EE_UREG fclock )''': Make the best effort to set CPU clock frequency to fclock value. It's the function used by '''StartOS''' when a '''CPU_CLOCK''' is configured in '''CPU_DATA'''.<br />
* '''void EE_tc27x_delay ( EE_UREG usec )''': Implement a busy loop wait of '''usec''' micorseconds.<br />
* '''void EE_tc27x_stm_set_sr0( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 0''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr0_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 0 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
* '''void EE_tc27x_stm_set_sr1( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 1''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr1_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 1 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
<br />
'''SR0''' and '''SR1''' API are both available to the user if '''System Timer''' is '''not''' configured. Otherwise only the one not used by system timer will be available.<br />
<br />
=== Board API ===<br />
<br />
BOARD layer represent the specific board support. There is only aminimal support for TriBoard TC2x5 v2.0 equiped with a TC275TE MCU:<br />
<br />
* '''void EE_tc2x5_leds_init( void )''': Initialize the 8 boards leds.<br />
* '''void EE_tc2x5_leds_on( void )''': Turns all the 8 leds.<br />
* '''void EE_tc2x5_leds_off( void )''': Turns off all the 8 leds.<br />
* '''void EE_tc2x5_turn_led(enum EE_tc2x5_led_id led_id, enum EE_tc2x5_led_status onoff)''': Turn the status of the led '''led_id''' (led IDs are collected in an enum in the form: '''EE_TRIBOARD_2X5_LED_{x}''' with {x}=[1..8]) on (onoff == '''EE_TRIBOARD_2X5_LED_ON''') or off (onoff == '''EE_TRIBOARD_2X5_LED_OFF''').<br />
* '''EE_BIT EE_tc2x5_read_button( void ): read external button value<br />
* '''void EE_tc2x5_button_irq_init( EE_TYPEISR2PRIO intvec )''': Configure the external button has an interrupt source and tie it to '''intvec''' priority handler.<br />
* '''void EE_tc2x5_button_irq_clear_request( void )''': Clear external button interrupt request.<br />
<br />
External button have to be connected to pin P15.8 on TC275TE corrisponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector of TriBoard TC2x5.<br />
<br />
= Debugger support =<br />
<br />
* [[Lauterbach TRACE32 Support for Infineon Aurix]]<br />
* [[iSYSTEM winIDEA Support for Infineon Aurix]]<br />
<br />
= Multicore Autosar OS Support =<br />
<br />
For details please see the following page: [[Erika AUTOSAR OS]]<br />
<br />
=== Build Multicore Application Single ELF with HighTec GCC Compiler ===<br />
<br />
The conventional ERIKA multicore build chain generate an ELF file for each core and the real application image is loaded on the device by Lauterbach, trought scripts. This approach is not straightforwardly portable on other programmer tools. Fortunately HighTec GCC Compiler has some peculiar features that have allowed us to change this approach, and for TriCore is possible to compile a Multicore Application contained in a single ELF.<br />
<br />
To enable this new build method add the following '''EEOPT=EE_BUILD_SINGLE_ELF''' to the project OIL file.<br />
<br />
To export some symbols from a core an '''HighTec GCC export file''' is needed. An HighTec export file looks like this:<br />
<br />
EXPORT FUNCTION _START ;<br />
EXPORT FUNCTION ErrorHook ;<br />
EXPORT FUNCTION StartupHook ;<br />
EXPORT FUNCTION ShutdownHook ;<br />
<br />
EXPORT OBJECT EE_oo_ErrorHook_ServiceID ;<br />
EXPORT OBJECT EE_oo_ErrorHook_data ;<br />
<br />
...<br />
<br />
To inform the build system to use an export file for a given core change the '''COMPILER_TYPE''' field of '''CPU_DATA''' OIL container, in the following way:<br />
<br />
CPU_DATA = TRICORE {<br />
ID = "master";<br />
...<br />
COMPILER_TYPE = GNU {<br />
EXPORT_FILE = "<relative path to the export file>";<br />
};<br />
...<br />
}; <br />
<br />
If this is done add explicitly '''EEOPT=EE_BUILD_SINGLE_ELF''' is no more needed.<br />
<br />
'''N.B:''' When used this approach an export files for the master core have to be provided always. The file can be empty if no symbols have to be exported by master core.<br />
<br />
This build approach is showed on following RT-Druid TriCore templates:<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test''<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore Spinlocks test''<br />
<br />
= Additional Notes =<br />
<br />
Since ERIKA 2.4.0 full AUTOSAR SC4 OS support for AURIX is publically released: you can find all the information about the implemented features and how to configure them at this page: [[Erika AUTOSAR OS]].</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=Infineon_AurixInfineon Aurix2017-03-23T10:12:37Z<p>Eguidieri: /* BOARD */</p>
<hr />
<div>[[Category:Supported Devices]]<br />
= Infineon Aurix support =<br />
<br />
ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid will be released soon.<br />
Currently only the TC27x AURIX family have been fully ported: <br />
<br />
# Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers:<br />
** HIGHTEC GCC Compiler v4.6.3.1 (for both Single and Multicore). '''NOTE Version 4.6.3.0 DOES NOT WORK!!!''' (it has a problem on Tricore header files)<br />
** TASKING VX-toolset for TriCore v4.0r1 (only for Singlecore).<br />
** WIND RIVER DIAB Compiler Rel. 5.9.2.0 (only for Singlecore). <br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: It follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ 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.<br />
<br />
=== MCU & Board ===<br />
* The porting have been completly developed on top of:<br />
** TriBoard TC2x5 v2.0 equiped with a TC275TE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC264DE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC297TA MCU (ask info AT evidence DOT eu DOT com)<br />
<br />
= Target Configuration and Programming =<br />
<br />
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]. Here are listed, after the information to set compiler path, the OIL fields customized for Tricore Aurix architecture.<br />
<br />
=== Compiler Path ===<br />
<br />
It is possible to choose the path of the compiler in three different ways:<br />
<br />
* ''PATH enviornment variable'': You can put compilers bin directories in PATH and the environmet can use them from here. <br />
* ''Compiler specific environment variables'':<br />
** '''HIGHTEC GCC toolchain''': You can specify the compiler path for HIGHTEC GCC with the '''TRICORE_GCCDIR'''.<br />
** '''Altium TASKING toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_TASKINGDIR'''.<br />
** '''Wind River Diab toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_DIABDIR'''.<br />
* ''RT-Druid configuration file'' see [[RT-Druid configuration#Compiler paths]]:<br />
** '''preference_tricore__path_for_gnu_compiler''' set HIGHTEC gcc compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_tasking_compiler''' set Altium TASKING compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_diab_compiler''' set Wind River Diab compiler path for Tricore AURIX[[#Compilers Notes|<sup>[a]</sup>]]<br />
<br />
Here is an [[Common oil.pref example|example of RT-Druid configuration file]].<br />
<br />
==== Compilers Notes ====<br />
* [a] RT-Druid support for Diab will be released ASAP.<br />
<br />
=== CPU ===<br />
<br />
'''CPU_DATA''' must be set to '''TRICORE'''.<br />
The compiler is specificed with the '''COMPILER_TYPE''' item, supported values are '''GNU''' (the default value) and '''TASKING'''.<br />
<br />
On multicore systems, one '''CPU_DATA''' instance can exist for each core. They must have different '''ID'''s. 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.<br />
<br />
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.<br />
We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value.<br />
In any case max declared CPU clock value (i.e. 200 Mhz for TC27x family), is guaranteed to be perfectly matched.<br />
<br />
'''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.<br />
<br />
Moreover a new field to declare a custom linker script have been added to CPU_DATA block: '''LINKERSCRIPT = "fake.ld";'''<br />
<br />
Example of a CPU_DATA section:<br />
<br />
CPU_DATA = TRICORE {<br />
CPU_CLOCK = 200.0;<br />
APP_SRC = "code.c";<br />
COMPILER_TYPE = GNU;<br />
MULTI_STACK = TRUE {<br />
IRQ_STACK = TRUE {<br />
SYS_SIZE = 128;<br />
};<br />
};<br />
};<br />
=== MCU ===<br />
<br />
'''MCU_DATA''' support the '''TC27x''' and '''TC26x''' values. Compiler can be specified even in '''MCU_DATA''' block and will inherited by all configured CPUs (useful in multicore project configuration).<br />
<br />
MCU_DATA = TRICORE {<br />
MODEL = TC27x;<br />
COMPILER_TYPE = GNU;<br />
};<br />
<br />
=== BOARD ===<br />
<br />
There is only support form TriBoard TC2x5. 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 (corresponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector). Add the following OIL field to enable this support.<br />
<br />
BOARD_DATA = TRIBOARD_TC2X5;<br />
<br />
=== Interrupt Handling ===<br />
<br />
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.<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
HANDLER = "isr_low"; <br />
};<br />
<br />
The mean of the fields are:<br />
*'''CATEGORY''': the type of ISR as specified by OSEK. <br />
*'''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.<br />
*'''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).<br />
<br />
=== Trap Handling ===<br />
<br />
With TriCore AURIX, for the first time, we support the options to register handler for TRAP/Exceptions. OSEK OIL do not provide any field for trap handling: it suppose that all the handling is done inside the Kernel. Usually that's what happens, but sometime can be useful have some mechanism to attach an handler for a particular class of TRAPs.<br />
<br />
We decide to exetend ISR entry with the field '''TRAP''' that can be set to TRUE to enable TRAP handling. In this case you have to choose the TRAP class with the field LEVEL (or ENTRY). The only valid values for this configuration are:<br />
<br />
*'''TRAP_MMU''' (Actually useless because TC27x family don't have MMU, just a place holder)<br />
*'''TRAP_PROT''' (Handler for protection traps)<br />
*'''TRAP_INST''' (Handler for instructions traps)<br />
*'''TRAP_CONT''' (Handler for context traps) <br />
*'''TRAP_BUS''' (Handler forn bus traps)<br />
*'''TRAP_ASS''' (Handler for assertion traps) (please don't be silly :))<br />
*'''TRAP_SYS''' (Handler for system calls)<br />
*'''TRAP_NMI''' (Handler for NMI trap)<br />
<br />
OIL TRAP configuration example:<br />
<br />
ISR trap_context {<br />
LEVEL = "TRAP_CONT";<br />
HANDLER = "EE_trap_context"; //Trap handler<br />
TRAP = TRUE;<br />
};<br />
<br />
To define the handler in your code, you have to use the following syntax:<br />
<br />
TRAP(EE_CLASS_TRAPCONT, EE_trap_context) {<br />
while(1) {<br />
; /* dummy */<br />
}<br />
}<br />
<br />
TRAP class identifiers are the following:<br />
<br />
*EE_CLASS_TRAPMMU<br />
*EE_CLASS_TRAPPROT<br />
*EE_CLASS_TRAPINST<br />
*EE_CLASS_TRAPCONT<br />
*EE_CLASS_TRAPBUS<br />
*EE_CLASS_TRAPASS<br />
*EE_CLASS_TRAPSYS<br />
*EE_CLASS_TRAPNMI<br />
<br />
Inside the TRAP handler TIN (Trap Identification Number) value can be accessed with '''EE_tc_get_TIN()''' function or, for HIGHTEC GNUC Compiler, with the local variable '''tin'''. For more information you can check the '''$(ee)/pkg/cpu/tricore/inc/ee_tc_trap.h''' file.<br />
<br />
=== EEOPT ===<br />
<br />
EEOPT is a way to specify configuration flags to the Erika build environment.<br />
EEOPTs can be specified as strings in the OS section of the OIL file. Examples:<br />
<br />
EE_OPT = "EE_DEBUG";<br />
EE_OPT = "__ASSERT__";<br />
<br />
Please notice that spelling inside the OIL file includes an underscore: EE_OPT.<br />
<br />
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.<br />
<br />
The following EEOPTs are specific of AURIX Architecture:<br />
* '''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.<br />
* '''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.<br />
* '''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'''.<br />
* '''EE_ICACHE_ENABLED''': Enable the instruction cache in start-up code.<br />
* '''EE_DCACHE_ENABLED''': Enable data cache in start-up code<br />
<br />
= OSEK/VDX Extensions =<br />
<br />
This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.<br />
<br />
=== Resource Managament at ISR level ===<br />
<br />
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:<br />
<br />
TASK Task1 {<br />
...<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
ISR <SYMBOL> {<br />
PRIORITY = <PRIORITY_LEVEL>;<br />
CATEGORY = <ISR_TYPE>;<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };<br />
<br />
=== System Timer ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive '''IncrementCounter'''.<br />
<br />
The following is an example OIL definition for a System Counter:<br />
<br />
CPU_DATA = TRICORE{<br />
CPU_CLOCK = 200.0;<br />
...<br />
};<br />
<br />
COUNTER SystemTimer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM_SR0";<br />
SYSTEM_TIMER = TRUE;<br />
PRIORITY = 1;<br />
};<br />
SECONDSPERTICK = 0.001;<br />
};<br />
<br />
The meaning of the various attributes is as follows:<br />
* '''CPU_DATA/CPU_CLOCK''' is used to declare the clock frequency (in MHZ).<br />
* '''COUNTER/TYPE''' must be set to '''HARDWARE''', and '''SYSTEM_TIMER''' must be set to true.<br />
* '''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'''<br />
* '''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'''.<br />
* '''COUNTER/SECONDSPERTICK''' is used to declare the wanted time duration of one hardware tick in seconds.<br />
<br />
The System Timer can be attached to ALARMs as usual, as in the following example:<br />
<br />
ALARM AlarmExample {<br />
COUNTER = SystemTimer;<br />
ACTION = ACTIVATETASK{<br />
TASK = TaskExample;<br />
};<br />
};<br />
<br />
= CPU MCU & BOARD API =<br />
<br />
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'''.<br />
<br />
=== CPU API ===<br />
<br />
CPU layer represent all the behaviour shared between all the families of AURIX MCUs. 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.<br />
<br />
* '''void EE_tc_endint_disable( void )''': Temporary disable ENDINT protection.<br />
* '''void EE_tc_endint_enable( void )''': Re-enable ENDINT protection.<br />
<br />
* '''void EE_tc_safety_endinit_disable( void )''': Temporary disable SAFETY_ENDINIT protection.<br />
* '''void EE_tc_safety_endinit_enable( void )''': Re-enable SAFETY_ENDINIT protection.<br />
<br />
=== MCU API ===<br />
<br />
MCU layer represent the behaviour tied to an specific AURIX family of MCUs. For now only family TC27x is supported.<br />
Most part of the utilities belong to this layer:<br />
<br />
* '''void EE_tc27x_get_clock ( void )''': Return CPU clock frequency in HZ.<br />
* '''void EE_tc27x_configure_clock( EE_UREG fclock )''': Make the best effort to set CPU clock frequency to fclock value. It's the function used by '''StartOS''' when a '''CPU_CLOCK''' is configured in '''CPU_DATA'''.<br />
* '''void EE_tc27x_delay ( EE_UREG usec )''': Implement a busy loop wait of '''usec''' micorseconds.<br />
* '''void EE_tc27x_stm_set_sr0( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 0''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr0_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 0 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
* '''void EE_tc27x_stm_set_sr1( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 1''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr1_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 1 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
<br />
'''SR0''' and '''SR1''' API are both available to the user if '''System Timer''' is '''not''' configured. Otherwise only the one not used by system timer will be available.<br />
<br />
=== Board API ===<br />
<br />
BOARD layer represent the specific board support. There is only aminimal support for TriBoard TC2x5 v2.0 equiped with a TC275TE MCU:<br />
<br />
* '''void EE_tc2x5_leds_init( void )''': Initialize the 8 boards leds.<br />
* '''void EE_tc2x5_leds_on( void )''': Turns all the 8 leds.<br />
* '''void EE_tc2x5_leds_off( void )''': Turns off all the 8 leds.<br />
* '''void EE_tc2x5_turn_led(enum EE_tc2x5_led_id led_id, enum EE_tc2x5_led_status onoff)''': Turn the status of the led '''led_id''' (led IDs are collected in an enum in the form: '''EE_TRIBOARD_2X5_LED_{x}''' with {x}=[1..8]) on (onoff == '''EE_TRIBOARD_2X5_LED_ON''') or off (onoff == '''EE_TRIBOARD_2X5_LED_OFF''').<br />
* '''EE_BIT EE_tc2x5_read_button( void ): read external button value<br />
* '''void EE_tc2x5_button_irq_init( EE_TYPEISR2PRIO intvec )''': Configure the external button has an interrupt source and tie it to '''intvec''' priority handler.<br />
* '''void EE_tc2x5_button_irq_clear_request( void )''': Clear external button interrupt request.<br />
<br />
External button have to be connected to pin P15.8 on TC275TE corrisponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector of TriBoard TC2x5.<br />
<br />
= Debugger support =<br />
<br />
* [[Lauterbach TRACE32 Support for Infineon Aurix]]<br />
* [[iSYSTEM winIDEA Support for Infineon Aurix]]<br />
<br />
= Multicore Autosar OS Support =<br />
<br />
For details please see the following page: [[Erika AUTOSAR OS]]<br />
<br />
=== Build Multicore Application Single ELF with HighTec GCC Compiler ===<br />
<br />
The conventional ERIKA multicore build chain generate an ELF file for each core and the real application image is loaded on the device by Lauterbach, trought scripts. This approach is not straightforwardly portable on other programmer tools. Fortunately HighTec GCC Compiler has some peculiar features that have allowed us to change this approach, and for TriCore is possible to compile a Multicore Application contained in a single ELF.<br />
<br />
To enable this new build method add the following '''EEOPT=EE_BUILD_SINGLE_ELF''' to the project OIL file.<br />
<br />
To export some symbols from a core an '''HighTec GCC export file''' is needed. An HighTec export file looks like this:<br />
<br />
EXPORT FUNCTION _START ;<br />
EXPORT FUNCTION ErrorHook ;<br />
EXPORT FUNCTION StartupHook ;<br />
EXPORT FUNCTION ShutdownHook ;<br />
<br />
EXPORT OBJECT EE_oo_ErrorHook_ServiceID ;<br />
EXPORT OBJECT EE_oo_ErrorHook_data ;<br />
<br />
...<br />
<br />
To inform the build system to use an export file for a given core change the '''COMPILER_TYPE''' field of '''CPU_DATA''' OIL container, in the following way:<br />
<br />
CPU_DATA = TRICORE {<br />
ID = "master";<br />
...<br />
COMPILER_TYPE = GNU {<br />
EXPORT_FILE = "<relative path to the export file>";<br />
};<br />
...<br />
}; <br />
<br />
If this is done add explicitly '''EEOPT=EE_BUILD_SINGLE_ELF''' is no more needed.<br />
<br />
'''N.B:''' When used this approach an export files for the master core have to be provided always. The file can be empty if no symbols have to be exported by master core.<br />
<br />
This build approach is showed on following RT-Druid TriCore templates:<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test''<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore Spinlocks test''<br />
<br />
= Additional Notes =<br />
<br />
Since ERIKA 2.4.0 full AUTOSAR SC4 OS support for AURIX is publically released: you can find all the information about the implemented features and how to configure them at this page: [[Erika AUTOSAR OS]].</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=Infineon_AurixInfineon Aurix2017-03-23T10:12:05Z<p>Eguidieri: /* MCU */</p>
<hr />
<div>[[Category:Supported Devices]]<br />
= Infineon Aurix support =<br />
<br />
ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid will be released soon.<br />
Currently only the TC27x AURIX family have been fully ported: <br />
<br />
# Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers:<br />
** HIGHTEC GCC Compiler v4.6.3.1 (for both Single and Multicore). '''NOTE Version 4.6.3.0 DOES NOT WORK!!!''' (it has a problem on Tricore header files)<br />
** TASKING VX-toolset for TriCore v4.0r1 (only for Singlecore).<br />
** WIND RIVER DIAB Compiler Rel. 5.9.2.0 (only for Singlecore). <br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: It follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ 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.<br />
<br />
=== MCU & Board ===<br />
* The porting have been completly developed on top of:<br />
** TriBoard TC2x5 v2.0 equiped with a TC275TE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC264DE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC297TA MCU (ask info AT evidence DOT eu DOT com)<br />
<br />
= Target Configuration and Programming =<br />
<br />
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]. Here are listed, after the information to set compiler path, the OIL fields customized for Tricore Aurix architecture.<br />
<br />
=== Compiler Path ===<br />
<br />
It is possible to choose the path of the compiler in three different ways:<br />
<br />
* ''PATH enviornment variable'': You can put compilers bin directories in PATH and the environmet can use them from here. <br />
* ''Compiler specific environment variables'':<br />
** '''HIGHTEC GCC toolchain''': You can specify the compiler path for HIGHTEC GCC with the '''TRICORE_GCCDIR'''.<br />
** '''Altium TASKING toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_TASKINGDIR'''.<br />
** '''Wind River Diab toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_DIABDIR'''.<br />
* ''RT-Druid configuration file'' see [[RT-Druid configuration#Compiler paths]]:<br />
** '''preference_tricore__path_for_gnu_compiler''' set HIGHTEC gcc compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_tasking_compiler''' set Altium TASKING compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_diab_compiler''' set Wind River Diab compiler path for Tricore AURIX[[#Compilers Notes|<sup>[a]</sup>]]<br />
<br />
Here is an [[Common oil.pref example|example of RT-Druid configuration file]].<br />
<br />
==== Compilers Notes ====<br />
* [a] RT-Druid support for Diab will be released ASAP.<br />
<br />
=== CPU ===<br />
<br />
'''CPU_DATA''' must be set to '''TRICORE'''.<br />
The compiler is specificed with the '''COMPILER_TYPE''' item, supported values are '''GNU''' (the default value) and '''TASKING'''.<br />
<br />
On multicore systems, one '''CPU_DATA''' instance can exist for each core. They must have different '''ID'''s. 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.<br />
<br />
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.<br />
We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value.<br />
In any case max declared CPU clock value (i.e. 200 Mhz for TC27x family), is guaranteed to be perfectly matched.<br />
<br />
'''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.<br />
<br />
Moreover a new field to declare a custom linker script have been added to CPU_DATA block: '''LINKERSCRIPT = "fake.ld";'''<br />
<br />
Example of a CPU_DATA section:<br />
<br />
CPU_DATA = TRICORE {<br />
CPU_CLOCK = 200.0;<br />
APP_SRC = "code.c";<br />
COMPILER_TYPE = GNU;<br />
MULTI_STACK = TRUE {<br />
IRQ_STACK = TRUE {<br />
SYS_SIZE = 128;<br />
};<br />
};<br />
};<br />
=== MCU ===<br />
<br />
'''MCU_DATA''' support the '''TC27x''' and '''TC26x''' values. Compiler can be specified even in '''MCU_DATA''' block and will inherited by all configured CPUs (useful in multicore project configuration).<br />
<br />
MCU_DATA = TRICORE {<br />
MODEL = TC27x;<br />
COMPILER_TYPE = GNU;<br />
};<br />
<br />
=== BOARD ===<br />
<br />
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.<br />
<br />
BOARD_DATA = TRIBOARD_TC2X5;<br />
<br />
=== Interrupt Handling ===<br />
<br />
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.<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
HANDLER = "isr_low"; <br />
};<br />
<br />
The mean of the fields are:<br />
*'''CATEGORY''': the type of ISR as specified by OSEK. <br />
*'''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.<br />
*'''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).<br />
<br />
=== Trap Handling ===<br />
<br />
With TriCore AURIX, for the first time, we support the options to register handler for TRAP/Exceptions. OSEK OIL do not provide any field for trap handling: it suppose that all the handling is done inside the Kernel. Usually that's what happens, but sometime can be useful have some mechanism to attach an handler for a particular class of TRAPs.<br />
<br />
We decide to exetend ISR entry with the field '''TRAP''' that can be set to TRUE to enable TRAP handling. In this case you have to choose the TRAP class with the field LEVEL (or ENTRY). The only valid values for this configuration are:<br />
<br />
*'''TRAP_MMU''' (Actually useless because TC27x family don't have MMU, just a place holder)<br />
*'''TRAP_PROT''' (Handler for protection traps)<br />
*'''TRAP_INST''' (Handler for instructions traps)<br />
*'''TRAP_CONT''' (Handler for context traps) <br />
*'''TRAP_BUS''' (Handler forn bus traps)<br />
*'''TRAP_ASS''' (Handler for assertion traps) (please don't be silly :))<br />
*'''TRAP_SYS''' (Handler for system calls)<br />
*'''TRAP_NMI''' (Handler for NMI trap)<br />
<br />
OIL TRAP configuration example:<br />
<br />
ISR trap_context {<br />
LEVEL = "TRAP_CONT";<br />
HANDLER = "EE_trap_context"; //Trap handler<br />
TRAP = TRUE;<br />
};<br />
<br />
To define the handler in your code, you have to use the following syntax:<br />
<br />
TRAP(EE_CLASS_TRAPCONT, EE_trap_context) {<br />
while(1) {<br />
; /* dummy */<br />
}<br />
}<br />
<br />
TRAP class identifiers are the following:<br />
<br />
*EE_CLASS_TRAPMMU<br />
*EE_CLASS_TRAPPROT<br />
*EE_CLASS_TRAPINST<br />
*EE_CLASS_TRAPCONT<br />
*EE_CLASS_TRAPBUS<br />
*EE_CLASS_TRAPASS<br />
*EE_CLASS_TRAPSYS<br />
*EE_CLASS_TRAPNMI<br />
<br />
Inside the TRAP handler TIN (Trap Identification Number) value can be accessed with '''EE_tc_get_TIN()''' function or, for HIGHTEC GNUC Compiler, with the local variable '''tin'''. For more information you can check the '''$(ee)/pkg/cpu/tricore/inc/ee_tc_trap.h''' file.<br />
<br />
=== EEOPT ===<br />
<br />
EEOPT is a way to specify configuration flags to the Erika build environment.<br />
EEOPTs can be specified as strings in the OS section of the OIL file. Examples:<br />
<br />
EE_OPT = "EE_DEBUG";<br />
EE_OPT = "__ASSERT__";<br />
<br />
Please notice that spelling inside the OIL file includes an underscore: EE_OPT.<br />
<br />
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.<br />
<br />
The following EEOPTs are specific of AURIX Architecture:<br />
* '''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.<br />
* '''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.<br />
* '''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'''.<br />
* '''EE_ICACHE_ENABLED''': Enable the instruction cache in start-up code.<br />
* '''EE_DCACHE_ENABLED''': Enable data cache in start-up code<br />
<br />
= OSEK/VDX Extensions =<br />
<br />
This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.<br />
<br />
=== Resource Managament at ISR level ===<br />
<br />
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:<br />
<br />
TASK Task1 {<br />
...<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
ISR <SYMBOL> {<br />
PRIORITY = <PRIORITY_LEVEL>;<br />
CATEGORY = <ISR_TYPE>;<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };<br />
<br />
=== System Timer ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive '''IncrementCounter'''.<br />
<br />
The following is an example OIL definition for a System Counter:<br />
<br />
CPU_DATA = TRICORE{<br />
CPU_CLOCK = 200.0;<br />
...<br />
};<br />
<br />
COUNTER SystemTimer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM_SR0";<br />
SYSTEM_TIMER = TRUE;<br />
PRIORITY = 1;<br />
};<br />
SECONDSPERTICK = 0.001;<br />
};<br />
<br />
The meaning of the various attributes is as follows:<br />
* '''CPU_DATA/CPU_CLOCK''' is used to declare the clock frequency (in MHZ).<br />
* '''COUNTER/TYPE''' must be set to '''HARDWARE''', and '''SYSTEM_TIMER''' must be set to true.<br />
* '''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'''<br />
* '''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'''.<br />
* '''COUNTER/SECONDSPERTICK''' is used to declare the wanted time duration of one hardware tick in seconds.<br />
<br />
The System Timer can be attached to ALARMs as usual, as in the following example:<br />
<br />
ALARM AlarmExample {<br />
COUNTER = SystemTimer;<br />
ACTION = ACTIVATETASK{<br />
TASK = TaskExample;<br />
};<br />
};<br />
<br />
= CPU MCU & BOARD API =<br />
<br />
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'''.<br />
<br />
=== CPU API ===<br />
<br />
CPU layer represent all the behaviour shared between all the families of AURIX MCUs. 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.<br />
<br />
* '''void EE_tc_endint_disable( void )''': Temporary disable ENDINT protection.<br />
* '''void EE_tc_endint_enable( void )''': Re-enable ENDINT protection.<br />
<br />
* '''void EE_tc_safety_endinit_disable( void )''': Temporary disable SAFETY_ENDINIT protection.<br />
* '''void EE_tc_safety_endinit_enable( void )''': Re-enable SAFETY_ENDINIT protection.<br />
<br />
=== MCU API ===<br />
<br />
MCU layer represent the behaviour tied to an specific AURIX family of MCUs. For now only family TC27x is supported.<br />
Most part of the utilities belong to this layer:<br />
<br />
* '''void EE_tc27x_get_clock ( void )''': Return CPU clock frequency in HZ.<br />
* '''void EE_tc27x_configure_clock( EE_UREG fclock )''': Make the best effort to set CPU clock frequency to fclock value. It's the function used by '''StartOS''' when a '''CPU_CLOCK''' is configured in '''CPU_DATA'''.<br />
* '''void EE_tc27x_delay ( EE_UREG usec )''': Implement a busy loop wait of '''usec''' micorseconds.<br />
* '''void EE_tc27x_stm_set_sr0( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 0''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr0_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 0 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
* '''void EE_tc27x_stm_set_sr1( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 1''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr1_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 1 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
<br />
'''SR0''' and '''SR1''' API are both available to the user if '''System Timer''' is '''not''' configured. Otherwise only the one not used by system timer will be available.<br />
<br />
=== Board API ===<br />
<br />
BOARD layer represent the specific board support. There is only aminimal support for TriBoard TC2x5 v2.0 equiped with a TC275TE MCU:<br />
<br />
* '''void EE_tc2x5_leds_init( void )''': Initialize the 8 boards leds.<br />
* '''void EE_tc2x5_leds_on( void )''': Turns all the 8 leds.<br />
* '''void EE_tc2x5_leds_off( void )''': Turns off all the 8 leds.<br />
* '''void EE_tc2x5_turn_led(enum EE_tc2x5_led_id led_id, enum EE_tc2x5_led_status onoff)''': Turn the status of the led '''led_id''' (led IDs are collected in an enum in the form: '''EE_TRIBOARD_2X5_LED_{x}''' with {x}=[1..8]) on (onoff == '''EE_TRIBOARD_2X5_LED_ON''') or off (onoff == '''EE_TRIBOARD_2X5_LED_OFF''').<br />
* '''EE_BIT EE_tc2x5_read_button( void ): read external button value<br />
* '''void EE_tc2x5_button_irq_init( EE_TYPEISR2PRIO intvec )''': Configure the external button has an interrupt source and tie it to '''intvec''' priority handler.<br />
* '''void EE_tc2x5_button_irq_clear_request( void )''': Clear external button interrupt request.<br />
<br />
External button have to be connected to pin P15.8 on TC275TE corrisponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector of TriBoard TC2x5.<br />
<br />
= Debugger support =<br />
<br />
* [[Lauterbach TRACE32 Support for Infineon Aurix]]<br />
* [[iSYSTEM winIDEA Support for Infineon Aurix]]<br />
<br />
= Multicore Autosar OS Support =<br />
<br />
For details please see the following page: [[Erika AUTOSAR OS]]<br />
<br />
=== Build Multicore Application Single ELF with HighTec GCC Compiler ===<br />
<br />
The conventional ERIKA multicore build chain generate an ELF file for each core and the real application image is loaded on the device by Lauterbach, trought scripts. This approach is not straightforwardly portable on other programmer tools. Fortunately HighTec GCC Compiler has some peculiar features that have allowed us to change this approach, and for TriCore is possible to compile a Multicore Application contained in a single ELF.<br />
<br />
To enable this new build method add the following '''EEOPT=EE_BUILD_SINGLE_ELF''' to the project OIL file.<br />
<br />
To export some symbols from a core an '''HighTec GCC export file''' is needed. An HighTec export file looks like this:<br />
<br />
EXPORT FUNCTION _START ;<br />
EXPORT FUNCTION ErrorHook ;<br />
EXPORT FUNCTION StartupHook ;<br />
EXPORT FUNCTION ShutdownHook ;<br />
<br />
EXPORT OBJECT EE_oo_ErrorHook_ServiceID ;<br />
EXPORT OBJECT EE_oo_ErrorHook_data ;<br />
<br />
...<br />
<br />
To inform the build system to use an export file for a given core change the '''COMPILER_TYPE''' field of '''CPU_DATA''' OIL container, in the following way:<br />
<br />
CPU_DATA = TRICORE {<br />
ID = "master";<br />
...<br />
COMPILER_TYPE = GNU {<br />
EXPORT_FILE = "<relative path to the export file>";<br />
};<br />
...<br />
}; <br />
<br />
If this is done add explicitly '''EEOPT=EE_BUILD_SINGLE_ELF''' is no more needed.<br />
<br />
'''N.B:''' When used this approach an export files for the master core have to be provided always. The file can be empty if no symbols have to be exported by master core.<br />
<br />
This build approach is showed on following RT-Druid TriCore templates:<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test''<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore Spinlocks test''<br />
<br />
= Additional Notes =<br />
<br />
Since ERIKA 2.4.0 full AUTOSAR SC4 OS support for AURIX is publically released: you can find all the information about the implemented features and how to configure them at this page: [[Erika AUTOSAR OS]].</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=Infineon_AurixInfineon Aurix2017-03-23T10:11:08Z<p>Eguidieri: /* MCU & Board */</p>
<hr />
<div>[[Category:Supported Devices]]<br />
= Infineon Aurix support =<br />
<br />
ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid will be released soon.<br />
Currently only the TC27x AURIX family have been fully ported: <br />
<br />
# Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers:<br />
** HIGHTEC GCC Compiler v4.6.3.1 (for both Single and Multicore). '''NOTE Version 4.6.3.0 DOES NOT WORK!!!''' (it has a problem on Tricore header files)<br />
** TASKING VX-toolset for TriCore v4.0r1 (only for Singlecore).<br />
** WIND RIVER DIAB Compiler Rel. 5.9.2.0 (only for Singlecore). <br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: It follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ 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.<br />
<br />
=== MCU & Board ===<br />
* The porting have been completly developed on top of:<br />
** TriBoard TC2x5 v2.0 equiped with a TC275TE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC264DE MCU<br />
** TriBoard TC2x5 v2.0 equiped with a TC297TA MCU (ask info AT evidence DOT eu DOT com)<br />
<br />
= Target Configuration and Programming =<br />
<br />
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]. Here are listed, after the information to set compiler path, the OIL fields customized for Tricore Aurix architecture.<br />
<br />
=== Compiler Path ===<br />
<br />
It is possible to choose the path of the compiler in three different ways:<br />
<br />
* ''PATH enviornment variable'': You can put compilers bin directories in PATH and the environmet can use them from here. <br />
* ''Compiler specific environment variables'':<br />
** '''HIGHTEC GCC toolchain''': You can specify the compiler path for HIGHTEC GCC with the '''TRICORE_GCCDIR'''.<br />
** '''Altium TASKING toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_TASKINGDIR'''.<br />
** '''Wind River Diab toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_DIABDIR'''.<br />
* ''RT-Druid configuration file'' see [[RT-Druid configuration#Compiler paths]]:<br />
** '''preference_tricore__path_for_gnu_compiler''' set HIGHTEC gcc compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_tasking_compiler''' set Altium TASKING compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_diab_compiler''' set Wind River Diab compiler path for Tricore AURIX[[#Compilers Notes|<sup>[a]</sup>]]<br />
<br />
Here is an [[Common oil.pref example|example of RT-Druid configuration file]].<br />
<br />
==== Compilers Notes ====<br />
* [a] RT-Druid support for Diab will be released ASAP.<br />
<br />
=== CPU ===<br />
<br />
'''CPU_DATA''' must be set to '''TRICORE'''.<br />
The compiler is specificed with the '''COMPILER_TYPE''' item, supported values are '''GNU''' (the default value) and '''TASKING'''.<br />
<br />
On multicore systems, one '''CPU_DATA''' instance can exist for each core. They must have different '''ID'''s. 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.<br />
<br />
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.<br />
We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value.<br />
In any case max declared CPU clock value (i.e. 200 Mhz for TC27x family), is guaranteed to be perfectly matched.<br />
<br />
'''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.<br />
<br />
Moreover a new field to declare a custom linker script have been added to CPU_DATA block: '''LINKERSCRIPT = "fake.ld";'''<br />
<br />
Example of a CPU_DATA section:<br />
<br />
CPU_DATA = TRICORE {<br />
CPU_CLOCK = 200.0;<br />
APP_SRC = "code.c";<br />
COMPILER_TYPE = GNU;<br />
MULTI_STACK = TRUE {<br />
IRQ_STACK = TRUE {<br />
SYS_SIZE = 128;<br />
};<br />
};<br />
};<br />
=== MCU ===<br />
<br />
'''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).<br />
<br />
MCU_DATA = TRICORE {<br />
MODEL = TC27x;<br />
COMPILER_TYPE = GNU;<br />
};<br />
<br />
=== BOARD ===<br />
<br />
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.<br />
<br />
BOARD_DATA = TRIBOARD_TC2X5;<br />
<br />
=== Interrupt Handling ===<br />
<br />
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.<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
HANDLER = "isr_low"; <br />
};<br />
<br />
The mean of the fields are:<br />
*'''CATEGORY''': the type of ISR as specified by OSEK. <br />
*'''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.<br />
*'''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).<br />
<br />
=== Trap Handling ===<br />
<br />
With TriCore AURIX, for the first time, we support the options to register handler for TRAP/Exceptions. OSEK OIL do not provide any field for trap handling: it suppose that all the handling is done inside the Kernel. Usually that's what happens, but sometime can be useful have some mechanism to attach an handler for a particular class of TRAPs.<br />
<br />
We decide to exetend ISR entry with the field '''TRAP''' that can be set to TRUE to enable TRAP handling. In this case you have to choose the TRAP class with the field LEVEL (or ENTRY). The only valid values for this configuration are:<br />
<br />
*'''TRAP_MMU''' (Actually useless because TC27x family don't have MMU, just a place holder)<br />
*'''TRAP_PROT''' (Handler for protection traps)<br />
*'''TRAP_INST''' (Handler for instructions traps)<br />
*'''TRAP_CONT''' (Handler for context traps) <br />
*'''TRAP_BUS''' (Handler forn bus traps)<br />
*'''TRAP_ASS''' (Handler for assertion traps) (please don't be silly :))<br />
*'''TRAP_SYS''' (Handler for system calls)<br />
*'''TRAP_NMI''' (Handler for NMI trap)<br />
<br />
OIL TRAP configuration example:<br />
<br />
ISR trap_context {<br />
LEVEL = "TRAP_CONT";<br />
HANDLER = "EE_trap_context"; //Trap handler<br />
TRAP = TRUE;<br />
};<br />
<br />
To define the handler in your code, you have to use the following syntax:<br />
<br />
TRAP(EE_CLASS_TRAPCONT, EE_trap_context) {<br />
while(1) {<br />
; /* dummy */<br />
}<br />
}<br />
<br />
TRAP class identifiers are the following:<br />
<br />
*EE_CLASS_TRAPMMU<br />
*EE_CLASS_TRAPPROT<br />
*EE_CLASS_TRAPINST<br />
*EE_CLASS_TRAPCONT<br />
*EE_CLASS_TRAPBUS<br />
*EE_CLASS_TRAPASS<br />
*EE_CLASS_TRAPSYS<br />
*EE_CLASS_TRAPNMI<br />
<br />
Inside the TRAP handler TIN (Trap Identification Number) value can be accessed with '''EE_tc_get_TIN()''' function or, for HIGHTEC GNUC Compiler, with the local variable '''tin'''. For more information you can check the '''$(ee)/pkg/cpu/tricore/inc/ee_tc_trap.h''' file.<br />
<br />
=== EEOPT ===<br />
<br />
EEOPT is a way to specify configuration flags to the Erika build environment.<br />
EEOPTs can be specified as strings in the OS section of the OIL file. Examples:<br />
<br />
EE_OPT = "EE_DEBUG";<br />
EE_OPT = "__ASSERT__";<br />
<br />
Please notice that spelling inside the OIL file includes an underscore: EE_OPT.<br />
<br />
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.<br />
<br />
The following EEOPTs are specific of AURIX Architecture:<br />
* '''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.<br />
* '''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.<br />
* '''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'''.<br />
* '''EE_ICACHE_ENABLED''': Enable the instruction cache in start-up code.<br />
* '''EE_DCACHE_ENABLED''': Enable data cache in start-up code<br />
<br />
= OSEK/VDX Extensions =<br />
<br />
This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.<br />
<br />
=== Resource Managament at ISR level ===<br />
<br />
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:<br />
<br />
TASK Task1 {<br />
...<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
ISR <SYMBOL> {<br />
PRIORITY = <PRIORITY_LEVEL>;<br />
CATEGORY = <ISR_TYPE>;<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };<br />
<br />
=== System Timer ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive '''IncrementCounter'''.<br />
<br />
The following is an example OIL definition for a System Counter:<br />
<br />
CPU_DATA = TRICORE{<br />
CPU_CLOCK = 200.0;<br />
...<br />
};<br />
<br />
COUNTER SystemTimer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM_SR0";<br />
SYSTEM_TIMER = TRUE;<br />
PRIORITY = 1;<br />
};<br />
SECONDSPERTICK = 0.001;<br />
};<br />
<br />
The meaning of the various attributes is as follows:<br />
* '''CPU_DATA/CPU_CLOCK''' is used to declare the clock frequency (in MHZ).<br />
* '''COUNTER/TYPE''' must be set to '''HARDWARE''', and '''SYSTEM_TIMER''' must be set to true.<br />
* '''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'''<br />
* '''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'''.<br />
* '''COUNTER/SECONDSPERTICK''' is used to declare the wanted time duration of one hardware tick in seconds.<br />
<br />
The System Timer can be attached to ALARMs as usual, as in the following example:<br />
<br />
ALARM AlarmExample {<br />
COUNTER = SystemTimer;<br />
ACTION = ACTIVATETASK{<br />
TASK = TaskExample;<br />
};<br />
};<br />
<br />
= CPU MCU & BOARD API =<br />
<br />
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'''.<br />
<br />
=== CPU API ===<br />
<br />
CPU layer represent all the behaviour shared between all the families of AURIX MCUs. 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.<br />
<br />
* '''void EE_tc_endint_disable( void )''': Temporary disable ENDINT protection.<br />
* '''void EE_tc_endint_enable( void )''': Re-enable ENDINT protection.<br />
<br />
* '''void EE_tc_safety_endinit_disable( void )''': Temporary disable SAFETY_ENDINIT protection.<br />
* '''void EE_tc_safety_endinit_enable( void )''': Re-enable SAFETY_ENDINIT protection.<br />
<br />
=== MCU API ===<br />
<br />
MCU layer represent the behaviour tied to an specific AURIX family of MCUs. For now only family TC27x is supported.<br />
Most part of the utilities belong to this layer:<br />
<br />
* '''void EE_tc27x_get_clock ( void )''': Return CPU clock frequency in HZ.<br />
* '''void EE_tc27x_configure_clock( EE_UREG fclock )''': Make the best effort to set CPU clock frequency to fclock value. It's the function used by '''StartOS''' when a '''CPU_CLOCK''' is configured in '''CPU_DATA'''.<br />
* '''void EE_tc27x_delay ( EE_UREG usec )''': Implement a busy loop wait of '''usec''' micorseconds.<br />
* '''void EE_tc27x_stm_set_sr0( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 0''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr0_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 0 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
* '''void EE_tc27x_stm_set_sr1( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 1''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr1_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 1 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
<br />
'''SR0''' and '''SR1''' API are both available to the user if '''System Timer''' is '''not''' configured. Otherwise only the one not used by system timer will be available.<br />
<br />
=== Board API ===<br />
<br />
BOARD layer represent the specific board support. There is only aminimal support for TriBoard TC2x5 v2.0 equiped with a TC275TE MCU:<br />
<br />
* '''void EE_tc2x5_leds_init( void )''': Initialize the 8 boards leds.<br />
* '''void EE_tc2x5_leds_on( void )''': Turns all the 8 leds.<br />
* '''void EE_tc2x5_leds_off( void )''': Turns off all the 8 leds.<br />
* '''void EE_tc2x5_turn_led(enum EE_tc2x5_led_id led_id, enum EE_tc2x5_led_status onoff)''': Turn the status of the led '''led_id''' (led IDs are collected in an enum in the form: '''EE_TRIBOARD_2X5_LED_{x}''' with {x}=[1..8]) on (onoff == '''EE_TRIBOARD_2X5_LED_ON''') or off (onoff == '''EE_TRIBOARD_2X5_LED_OFF''').<br />
* '''EE_BIT EE_tc2x5_read_button( void ): read external button value<br />
* '''void EE_tc2x5_button_irq_init( EE_TYPEISR2PRIO intvec )''': Configure the external button has an interrupt source and tie it to '''intvec''' priority handler.<br />
* '''void EE_tc2x5_button_irq_clear_request( void )''': Clear external button interrupt request.<br />
<br />
External button have to be connected to pin P15.8 on TC275TE corrisponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector of TriBoard TC2x5.<br />
<br />
= Debugger support =<br />
<br />
* [[Lauterbach TRACE32 Support for Infineon Aurix]]<br />
* [[iSYSTEM winIDEA Support for Infineon Aurix]]<br />
<br />
= Multicore Autosar OS Support =<br />
<br />
For details please see the following page: [[Erika AUTOSAR OS]]<br />
<br />
=== Build Multicore Application Single ELF with HighTec GCC Compiler ===<br />
<br />
The conventional ERIKA multicore build chain generate an ELF file for each core and the real application image is loaded on the device by Lauterbach, trought scripts. This approach is not straightforwardly portable on other programmer tools. Fortunately HighTec GCC Compiler has some peculiar features that have allowed us to change this approach, and for TriCore is possible to compile a Multicore Application contained in a single ELF.<br />
<br />
To enable this new build method add the following '''EEOPT=EE_BUILD_SINGLE_ELF''' to the project OIL file.<br />
<br />
To export some symbols from a core an '''HighTec GCC export file''' is needed. An HighTec export file looks like this:<br />
<br />
EXPORT FUNCTION _START ;<br />
EXPORT FUNCTION ErrorHook ;<br />
EXPORT FUNCTION StartupHook ;<br />
EXPORT FUNCTION ShutdownHook ;<br />
<br />
EXPORT OBJECT EE_oo_ErrorHook_ServiceID ;<br />
EXPORT OBJECT EE_oo_ErrorHook_data ;<br />
<br />
...<br />
<br />
To inform the build system to use an export file for a given core change the '''COMPILER_TYPE''' field of '''CPU_DATA''' OIL container, in the following way:<br />
<br />
CPU_DATA = TRICORE {<br />
ID = "master";<br />
...<br />
COMPILER_TYPE = GNU {<br />
EXPORT_FILE = "<relative path to the export file>";<br />
};<br />
...<br />
}; <br />
<br />
If this is done add explicitly '''EEOPT=EE_BUILD_SINGLE_ELF''' is no more needed.<br />
<br />
'''N.B:''' When used this approach an export files for the master core have to be provided always. The file can be empty if no symbols have to be exported by master core.<br />
<br />
This build approach is showed on following RT-Druid TriCore templates:<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test''<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore Spinlocks test''<br />
<br />
= Additional Notes =<br />
<br />
Since ERIKA 2.4.0 full AUTOSAR SC4 OS support for AURIX is publically released: you can find all the information about the implemented features and how to configure them at this page: [[Erika AUTOSAR OS]].</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=ERIKA_%26_Autosar_OS_RequirementsERIKA & Autosar OS Requirements2016-09-30T14:34:49Z<p>Eguidieri: /* Timing Protection: Resource Locking and Interrupt Disabling */</p>
<hr />
<div>= Introduction =<br />
Erika Enterprise is the first open-source Free RTOS that has been certified OSEK/VDX compliant and it's under current developtment to fulfil Autosar 4 OS Requirements too. In the following table are logged the AUTOSAR requirements already implemneted in ERIKA.<br />
<br />
* All the requirement tagged as OK are implemented in all supported Architectures.<br />
* All the requirements related to '''memory protection''' are available only for those MCU that have memory protection implmentented: currently only support for Freescale MPC5674F has been released.<br />
* All the requirements tagged as TriCore are implemented but will be realesed when the full support for TriCore AURIX will be released.<br />
<br />
Scalability Classes are not implemented yet, but each feature/API is activated only if required by the configuration.<br />
<br />
= Tasks =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS052 || OK<br />
| If a task returns from its entry function without making a TerminateTask() or ChainTask() call, the Operating System shall terminate the task (and call the PostTaskHook() if configured).<br />
|-<br />
| OS069 || OK<br />
| If a task returns from its entry function without making a TerminateTask() or ChainTask() call AND the error hook is configured, the Operating System shall call the ErrorHook() (this is done regardless of whether the task causes other errors, e.g. E_OS_RESOURCE) with status E_OS_MISSINGEND before the task leaves the RUNNING state.<br />
|-<br />
| OS070 || OK<br />
| If a task returns from the entry function without making a TerminateTask() or ChainTask() call and still holds OSEK Resources, the Operating System shall release them.<br />
|-<br />
| OS239 || OK<br />
| If a task returns from the entry function without making a TerminateTask() or ChainTask() call and interrupts are still disabled, the Operating System shall enable them.<br />
|-<br />
| OS071 || OK<br />
| If the PostTaskHook() is configured, the Operating System shall not call the hook if ShutdownOS() is called.<br />
|}<br />
<br />
= ISR2s =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS368 || OK<br />
| If a Category 2 OsIsr calls DisableAllInterupts() SuspendAllInterrupts() / SuspendOSInterrupts() and ends (returns) without calling the corresponding EnableAllInterrupts() / ResumeAllInterrupts() / ResumeOSInterrupts(), the Operating System shall perform the missing service and shall call the ErrorHook() (if configured) with the status E_OS_DISABLEDINT.<br />
|-<br />
| OS369 || OK<br />
| If a Category 2 OsIsr calls GetResource() and ends (returns) without calling the corresponding ReleaseResource(), the Operating System shall perform the ReleaseResource() call and shall call the ErrorHook() (if configured) with the status E_OS_RESOURCE.<br />
|}<br />
<br />
= Hooks =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS236 || OK TriCore<br />
| If both a system-specific and one (or more) application specific startup hook(s) are configured, the Operating System shall call the system-specific startup hook before the application-specific startup hook(s).<br />
|-<br />
| OS112 || OK TriCore<br />
| If an application-specific shutdown hook is configured for an OS-Application <App>, the Operating System shall call ShutdownHook_<App> on shutdown of the OS.<br />
|-<br />
| OS225 || OK TriCore<br />
| The Operating System shall execute an application-specific shutdown hook with the access rights of the associated OS-Application.<br />
|-<br />
| OS237 || OK TriCore<br />
| If both a system-specific and one (or more) application specific shutdown hook(s) are configured, the Operating System shall call the system-specific shutdown hook after the application-specific shutdown hook(s).<br />
|-<br />
| OS246 || OK TriCore<br />
| When an error occurs AND an application-specific error hook is configured for the faulty OS-Application <App>, the Operating System shall call that application- specific error hook ErrorHook_<App> after the system specific error hook is called (if configured).<br />
|-<br />
| OS085 || OK TriCore<br />
| The Operating System shall execute an application-specific error hook with the access rights of the associated OS-Application.<br />
|}<br />
<br />
= Timers and Counters =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS301 || OK<br />
| The Operating System shall provide the ability to increment a software counter as an alternative action on alarm expiry.<br />
|-<br />
| OS399 || OK<br />
| The OS shall provide an API call to increment a software counter.<br />
|-<br />
| OS374 || OK<br />
| The Operating System shall handle all the initialization and configuration of timers used directly by the OS and not handled by the GPT driver.<br />
|-<br />
| OS383 || OK (partials)<br />
| The Operating System shall provide a service to read the current count value of a counter (returning either the hardware timer ticks if counter is driven by hardware or the software ticks when user drives counter).<br />
|-<br />
| OS392 || OK<br />
| The Operating System shall provide a service to get the number of ticks between the current tick value and a previously read tick value.<br />
|-<br />
| OS384 ||<br />
| The Operating System shall adjust the read out values of hardware timers (which drive counters) in such that the lowest value is zero and consecutive reads return an increasing count value until the timer wraps at its modulus.<br />
|}<br />
<br />
== Autosar New API for Timers and Counters ==<br />
<br />
=== IncrementCounter ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS399 || OK<br />
| IncrementCounter<br />
|-<br />
| OS285 || OK<br />
| If the input parameter <CounterID> in a call of IncrementCounter() is not valid OR the counter is a hardware counter, IncrementCounter() shall return E_OS_ID.<br />
|-<br />
| OS286 || OK<br />
| If the input parameter of IncrementCounter() is valid, IncrementCounter() shall increment the counter <CounterID> by one (if any alarm connected to this counter expires, the given action, e.g. task activation, is done) and shall return E_OK.<br />
|-<br />
| OS321 || OK<br />
| If in a call of IncrementCounter() an error happens during the execution of an alarm action, e.g. E_OS_LIMIT caused by a task activation, IncrementCounter() shall call the error hook(s), but the IncrementCounter() service itself shall return E_OK.<br />
|-<br />
| OS529 || OK<br />
| Caveats of IncrementCounter(): If called from a task, rescheduling may take place.<br />
|-<br />
| OS530 || OK<br />
| Availability of IncrementCounter(): Available in all Scalability Classes.<br />
|}<br />
<br />
=== GetCounterValue ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS383 || OK<br />
| GetCounterValue<br />
|-<br />
| OS376 || OK<br />
| If the input parameter <CounterID> in a call of GetCounterValue() is not valid, GetCounterValue() shall return E_OS_ID.<br />
|-<br />
| OS377 || OK<br />
| If the input parameter <CounterID> in a call of GetCounterValue() is valid, GetCounterValue() shall return the current tick value of the counter via <Value> and return E_OK.<br />
|-<br />
| OS531 || OK (partials)<br />
| Caveats of GetCounterValue(): Note that for counters of OsCounterType = HARDWARE the real timer value (the – possibly adjusted – hardware value, see OS384) is returned, whereas for counters of OsCounterType = SOFTWARE the current “software” tick value is returned.<br />
|-<br />
| OS532 || OK<br />
| Availability of GetCounterValue(): Available in all Scalability Classes.<br />
|}<br />
<br />
=== GetElapsedValue ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS392 || OK<br />
| GetElapsedValue<br />
|-<br />
| OS381 || OK<br />
| If the input parameter <CounterID> in a call of GetElapsedValue() is not valid GetElapsedValue() shall return E_OS_ID.<br />
|-<br />
| OS391 || OK<br />
| If the <Value> in a call of GetElapsedValue() is larger than the max allowed value of the <CounterID>, GetElapsedValue() shall return E_OS_VALUE.<br />
|-<br />
| OS382 || OK<br />
| If the input parameters in a call of GetElapsedValue() are valid, GetElapsedValue() shall return the number of elapsed ticks since the given <Value> value via <ElapsedValue> and shall return E_OK.<br />
|-<br />
| OS460 || OK<br />
| GetElapsedValue() shall return the current tick value of the counter in the <Value> parameter.<br />
|-<br />
| OS533 || OK<br />
| Caveats of GetCounterValue():If the timer already passed the <Value> value a second (or multiple) time, the result returned is wrong. The reason is that the service can not detect such a relative overflow.<br />
|-<br />
| OS534 || OK<br />
| Availability of GetCounterValue(): Available in all Scalability Classes.<br />
|}<br />
<br />
== OSEK Requirements Extensions ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS304 || OK<br />
| If in a call to SetRelAlarm() the parameter “increment” is set to zero, the service shall return E_OS_VALUE in standard and extended status .<br />
|-<br />
| OS424 || OK<br />
| The first call to StartOS() (for starting the Operating System) shall not return.<br />
|-<br />
| OS425 || OK<br />
| If ShutdownOS() is called and ShutdownHook() returns then the operating system shall disable all interrupts and enter an endless loop.<br />
|-<br />
| OS299 || OK<br />
|The Operating System shall provide the services DisableAllInterrupts(), EnableAllInterrupts(), SuspendAllInterrupts(), ResumeAllInterrupts() prior to calling StartOS() and after calling ShutdownOS(). (It is assumed that the static variables of these functions are initialized).<br />
|-<br />
| OS051 || OK TriCore<br />
| If an invalid address (address is not writable by this OS-Application) is passed as an out-parameter to an OS service, the Operating System shall return the status code E_OS_ILLEGAL_ADDRESS.<br />
|-<br />
| OS088 || OK TriCore<br />
| If an OS-Application makes a service call from the wrong context AND is currently not inside a Category 1 OsIsr the Operating System shall not perform the requested action (the service call shall have no effect), and return E_OS_CALLEVEL or the “invalid value” of the service.<br />
|-<br />
| OS092 || OK<br />
| If EnableAllInterrupts() ResumeAllInterrupts() / ResumeOSInterrupts() are called and no corresponding DisableAllInterupts() / SuspendAllInterrupts() / SuspendOSInterrupts() was done before, the Operating System shall not perform this OS service.<br />
|-<br />
| OS093 || OK<br />
| If interrupts are disabled/suspended by a Task/OsIsr and the Task/OsIsr calls any OS service (excluding the interrupt services) then the Operating System shall ignore the service AND shall return E_OS_DISABLEDINT if the service returns a StatusType value.<br />
|-<br />
| OS054 || OK TriCore<br />
| The Operating System shall ignore calls to ShutdownOS() from non-trusted OS-Applications.<br />
|-<br />
| OS056 || OK TriCore<br />
| If an OS-object identifier is the parameter of a system service, and no sufficient access rights have been assigned at configuration time (Parameter Os[...]AccessingApplication) to the calling Task/Category 2 OsIsr, the system service shall return E_OS_ACCESS.<br />
|-<br />
| OS449 || OK<br />
| CheckTaskMemoryAccess and CheckIsrMemoryAccess check the memory access. Memory access checking is possible for all OS-Applications and from all OS- Applications and does not need granted rights (This is an exception to OS056).<br />
|-<br />
| OS450 || OK<br />
| CheckObjectAccess checks the access rights for OS objects. Checking object access is possible for all OS-Applications and from all OS-Applications and does not need granted rights (This is an exception to OS056).<br />
|-<br />
| OS439 || OK<br />
| The Operating System shall offer the OSEK error macros (OSError...()) to all configured error hooks AND there shall be two (like in OIL) global configuration parameter to switch these macros on or off.<br />
|-<br />
| OS367 || OK<br />
| Operating System services which do not return a StatusType shall not raise the error hook(s).<br />
|-<br />
| OS566 || OK<br />
| The Operating System API shall check in extended mode all pointer argument for NULL pointer and return OS_E_PARAMETER if such argument is NULL.<br />
|}<br />
<br />
= Minor Further Requirements =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS398 || OK<br />
| The OS shall not define the symbol LOCALMESSAGESONLY<br />
|-<br />
| OS242 || No scalability Classes support (But this will be prevented in Any AS configuration)<br />
| The Operating System shall only allow Alarm Callbacks in Scalability Class 1.<br />
|}<br />
<br />
= Memory protection =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS198 || Partial [[#Memory protection notes|<sup>[a]</sup>]]<br />
| The Operating System shall prevent write access to its own data sections and its own stack from non-trusted OS-Applications.<br />
|-<br />
| OS026 || OK (configurable)<br />
| The Operating System may prevent read access to an OS-Application’s data section attempted by other non-trusted OS-Applications.<br />
|-<br />
| OS086 || OK<br />
| The Operating System shall permit an OS-Application read and write access to that OS-Application’s own private data sections.<br />
|-<br />
| OS207 || OK<br />
| The Operating System shall prevent write access to the OS-Application’s private data sections from other non-trusted OS-Applications.<br />
|-<br />
| OS196 || OK<br />
| The Operating System shall permit a Task/Category 2 OsIsr read and write access to that Task’s/Category 2 OsIsr’s own private stack.<br />
|-<br />
| OS208 || OK (not prevented)<br />
| The Operating System may prevent write access to the private stack of Tasks/Category 2 OsIsrs of a non-trusted application from all other Tasks/OsIsrs in the same OS-Application.<br />
|-<br />
| OS355 || OK<br />
| The Operating System shall prevent write access to all private stacks of Tasks/Category 2 OsIsrs of an OS-Application from other non-trusted OS- Applications.<br />
|-<br />
| OS087 || OK<br />
| The Operating System shall permit a Task/Category 2 OsIsr read and write access to that Task’s/Category 2 OsIsr’s own private data sections.<br />
|-<br />
| OS195 || OK (not prevented)<br />
| The Operating System may prevent write access to the private data sections of a Task/Category 2 OsIsr of a non-trusted application from all other Tasks/OsIsrs in the same OS-Application.<br />
|-<br />
| OS356 || OK<br />
| The Operating System shall prevent write access to all private data sections of a Task/Category 2 OsIsr of an OS-Application from other non-trusted OS- Applications.<br />
|-<br />
| OS027 || OK (not protected)<br />
| The Operating System may provide an OS-Application the ability to protect its code sections against executing by non-trusted OS-Applications.<br />
|-<br />
| OS081 || OK (all code is shared)<br />
| The Operating System shall provide the ability to provide shared library code in sections that are executable by all OS-Applications.<br />
|-<br />
| OS209 || OK<br />
| The Operating System shall permit trusted OS-Applications read and write access to peripherals.<br />
|-<br />
| OS083 || Not done [[#Memory protection notes|<sup>[b]</sup>]]<br />
| The Operating System shall allow non-trusted OS-Applications to write to their assigned peripherals only (incl. reads that have the side effect of writing to a memory location).<br />
|-<br />
| OS044 || OK TriCore [[#Memory protection notes|<sup>[c]</sup>]]<br />
| If a memory access violation is detected, the Operating System shall call the Protection Hook with status code E_OS_PROTECTION_MEMORY.<br />
|}<br />
<br />
No timing and memory protection for alarm callbacks.<br />
<br />
== CheckISRMemoryAccess ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS512 || OK<br />
| CheckISRMemoryAccess<br />
|-<br />
| OS267 || OK<br />
| If the ISR reference <ISRID> in a call of CheckISRMemoryAccess() is valid, CheckISRMemoryAccess() shall return the access rights of the ISR on the specified memory area.<br />
|-<br />
| OS313 || OK [[#Memory protection notes|<sup>[d]</sup>]]<br />
| If an access right (e.g. “read”) is not valid for the whole memory area specified in a call of CheckISRMemoryAccess(), CheckISRMemoryAccess() shall yield no access regarding this right.<br />
|-<br />
| OS268 || OK<br />
| If the ISR reference <ISRID> is not valid, CheckISRMemoryAccess() shall yield no access rights.<br />
|-<br />
| OS517 || No scalability Classes support<br />
| Availability of CheckISRMemoryAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
== CheckTaskMemoryAccess ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS513 || OK<br />
| CheckTaskMemoryAccess<br />
|-<br />
| OS269 || OK<br />
| If the Task reference <TaskID> in a call of CheckTaskMemoryAccess() is valid, CheckTaskMemoryAccess() shall return the access rights of the task on the specified memory area.<br />
|-<br />
| OS314 || OK [[#Memory protection notes|<sup>[d]</sup>]]<br />
| If an access right (e.g. “read”) is not valid for the whole memory area specified in a call of CheckTaskMemoryAccess(), CheckTaskMemoryAccess() shall yield no access regarding this right.<br />
|-<br />
| OS270 || OK<br />
| If the Task reference <TaskID> in a call of CheckTaskMemoryAccess() is not valid, CheckTaskMemoryAccess() shall yield no access rights.<br />
|-<br />
| OS518 || No scalability Classes support<br />
| Availability of CheckTaskMemoryAccess(): Available in Scalability Classes 3 and 4<br />
|}<br />
<br />
== Memory protection notes ==<br />
* [a] - The OS shares the stack with tasks and ISRs. If SP is invalid when calling a system API, a fault may happen. If a context change happens inside a system call (e.g., ActivateTask() made on a task with higher priority), data from the OS remain saved on the stack of the calling task; other tasks or ISRs from the same OS-Application can overwrite those values. A solution for this problem is in testing on TriCore implementation, but since the kernel on AURIX never allocate stack (this is due to the special carateristic of TriCore Architecture and the compilers optimizations) the implementation cannot be proved until it will backported on PPC or on a new architecture with this pontential problem.<br />
* [b] - This is tricky. Currently, only trusted OS-Applications can access MCU registers. Probably the granularity of the MMU is not enough, and maybe the MPU is not suitable either.<br />
* [c] - In MPC5674F When a protection error occur, one of the IVOR routines is called, which jump to <code>__empty_handler</code>. In TriCore protection hook will be fully supported.<br />
* [d] - The current implementation is more restrictive. If the given memory range is not contained in a single memory section (e.g., it starts inside the stack section and ends inside BSS), no access is returned. This should not create problems, as crossing sections depends on the memory layout; relying on that would be very fragile and no application should do it.<br />
<br />
= Stack monitoring =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS067 || OK TriCore<br />
| The Operating System shall offer a stack monitoring which detects possible stack faults of Task(s)/Category 2 OsIsr(s).<br />
|-<br />
| OS068 || OK TriCore<br />
| If a stack fault is detected by stack monitoring AND the configured scalability class is 1 or 2, the Operating System shall call the ShutdownOS() service with the status E_OS_STACKFAULT.<br />
|-<br />
| OS396 || OK TriCore<br />
| If a stack fault is detected by stack monitoring AND the configured scalability class is 3 or 4, the Operating System shall call the ProtectionHook() with the status E_OS_STACKFAULT.<br />
|}<br />
<br />
= OS-Applications =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS445 || Partial [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| The Operating System shall support OS-Applications which are a composition of (at least one Task OR OsIsr) AND (zero or more Alarms, Schedule tables, Counters or Resources) AND (zero or one hooks for startup, error and shutdown).<br />
|-<br />
| OS446 || OK<br />
| The Operating System shall support the notion of trusted and not trusted OS-Applications.<br />
|-<br />
| OS464 || OK<br />
| Trusted OS-Applications may offer services (“trusted services”) to other (even non-trusted) OS-Applications.<br />
|-<br />
| OS016 || OK (see GetApplicationID())<br />
| The Operating System shall provide a service to determine the currently running OS-Application (a unique identifier shall be allocated to each application).<br />
|-<br />
| OS017 || OK (see CheckObjectOwnership())<br />
| The Operating System shall provide a service to determine to which OS-Application a given Task, OsIsr, Resource, Counter, Alarm or Schedule Table belongs.<br />
|-<br />
| OS256 || OK (see CheckObjectAccess())<br />
| The Operating System shall provide a service to determine which OS-Applications are allowed to use the IDs of a Task, OsIsr, Resource, Counter, Alarm or Schedule Table in API calls.<br />
|-<br />
| OS258 || OK (see TerminateApplication())<br />
| The Operating System shall provide a service to terminate the OS-Application to which the calling Task/Category 2 OsIsr/application specific error hook belongs. (This is an OS-Application level variant of the TerminateTask() service)<br />
|-<br />
| OS447 || OK<br />
| Terminating an OS-Application means to:<br />
* terminate all running, ready and waiting Tasks/OsIsrs of the OS-Application AND<br />
* disabling all interrupts of the OS-Application AND<br />
* stop all active alarms of the OS-Applications AND<br />
* stop all schedule tables of the OS-Application.<br />
|-<br />
| OS448 || OK TriCore<br />
| OS-Applications, trusted or non-trusted, shall by default have only access rights to objects belonging to this OS-Application. Access rights from other OS-Applications shall be granted explicitely by configuration.<br />
|-<br />
| OS060 || OK TriCore [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| If an application-specific startup hook is configured for an OS-Application <App>, the Operating System shall call StartupHook_<App> on startup of the OS.<br />
|-<br />
| OS110 || OK [[#OS-Applications notes|<sup>[c]</sup>]]<br />
| If the Operating System forcibly terminates an OS-Application, it:<br />
* forcibly terminates all Tasks/OsIsrs of the OS-Application AND<br />
* cancels all alarms of the OS-Application AND<br />
* stops schedule tables of the OS-Application AND<br />
* disables interrupt sources of Category 2 OsIsrs belonging to the OS-Application<br />
|-<br />
| OS111 || OK [[#OS-Applications notes|<sup>[c]</sup>]]<br />
| When the Operating System restarts an OS-Application it activates the configured OsRestartTask.<br />
|}<br />
<br />
== New Autosar API ==<br />
<br />
=== GetApplicationID ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS016 || OK<br />
| GetApplicationID<br />
|-<br />
| OS261 || OK TriCore [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| GetApplicationID() shall return the application identifier to which the executing Task/ISR/hook belongs.<br />
|-<br />
| OS262 || OK<br />
| If no OS-Application is running, GetApplicationID() shall return INVALID_OSAPPLICATION.<br />
|-<br />
| OS514 || No scalability Classes support<br />
| Availability of GetApplicationID(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== CheckObjectAccess ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS256 || OK TriCore<br />
| CheckObjectAccess<br />
|-<br />
| OS271 || OK TriCore<br />
| If the OS-Application <ApplID> in a call of CheckObjectAccess() has access to the queried object, CheckObjectAccess() shall return ACCESS.<br />
|-<br />
| OS272 || OK TriCore<br />
| If the OS-Application <ApplID> in a call of CheckObjectAccess() has no access to the queried object, CheckObjectAccess() shall return NO_ACCESS.<br />
|-<br />
| OS423 || OK TriCore<br />
| If in a call of CheckObjectAccess() the object to be examined is not a valid object OR <ApplID> is invalid OR <ObjectType> is invalid THEN CheckObjectAccess() shall return NO_ACCESS.<br />
|-<br />
| OS519 || No scalability Classes support<br />
| Availability of CheckObjectAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== CheckObjectOwnership ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS017 || OK TriCore<br />
| CheckObjectOwnership<br />
|-<br />
| OS273 || OK TriCore<br />
| If the object ObjectType specified in a call of CheckObjectOwnership() exists, CheckObjectOwnership() shall return the identifier of the OS-Application to which the object belongs.<br />
|-<br />
| OS274 || OK TriCore<br />
| If in a call of CheckObjectOwnership() the specified object ObjectType is invalid OR the argument of the type (the “...”) is invalid, CheckObjectOwnership() shall return INVALID_OSAPPLICATION.<br />
|-<br />
| OS520 || No scalability Classes support<br />
| Availability of CheckObjectOwnership():Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== TerminateApplication ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS258 || OK TriCore<br />
| TerminateApplication<br />
|-<br />
| OS493 || OK TriCore<br />
| If the input parameter <Application> in a call of TerminateApplication() is not valid TerminateApplication() shall return E_OS_ID.<br />
|-<br />
| OS459 || OK TriCore<br />
| If the <RestartOption> in a call of TerminateApplication() is invalid, TerminateApplication() shall return E_OS_VALUE.<br />
|-<br />
| OS494 || OK TriCore<br />
| If the input parameter <Application> in a call of TerminateApplication() is valid AND the caller belongs to a non-trusted OS-Application AND the caller does not belong to <Application> TerminateApplication() shall return E_OS_ACCESS.<br />
|-<br />
| OS507 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_TERMINATED TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS508 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_RESTARTING and the caller does not belong to the <Application> then TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS548 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_RESTARTING AND the caller does belong to the <Application> AND the <RestartOption> is equal RESTART then TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS287 || OK TriCore<br />
| If the parameters in a call of TerminateApplication() are valid and the above criteria are met TerminateApplication() shall terminate <Application> (i.e. to kill all tasks, disable the interrupt sources of those ISRs which belong to the OS-Application and free all other OS resources associated with the application) AND shall activate the configured OsRestartTask of <Application> if <RestartOption> equals RESTART. If the <Application> is restarted, its state is set to APPLICATION_RESTARTING otherwise to APPLICATION_TERMINATED. If the caller belongs to <Application> TerminateApplication() shall not return, otherwise it shall return E_OK.<br />
|-<br />
| OS535 || OK TriCore<br />
| Caveats of TerminateApplication():<br />
* If no applications are configured the implementation shall make sure that this service is not available.<br />
* Tasks and interrupts that are owned by a trusted application can terminate any OS-Application. Tasks and interrupts that are owned by a non-trusted application can only terminate their owning OS-Application.<br />
|-<br />
| OS536 || No scalability Classes support<br />
| Availability of TerminateApplication(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== AllowAccess ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS501 || OK TriCore<br />
| AllowAccess<br />
|-<br />
| OS497 || OK TriCore<br />
| If the state of the OS-Application of the caller of AllowAccess() is not APPLICATION_RESTARTING AllowAccess() shall return E_OS_STATE.<br />
|-<br />
| OS498 || OK TriCore<br />
| If the state of the OS-Application of the caller of AllowAccess() is APPLICATION_RESTARTING, AllowAccess() shall set the state to APPLICATION_ACCESSIBLE and allow other OS-Applications to access the configured objects of the callers OS-Application.<br />
|-<br />
| OS547 || No scalability Classes support<br />
| Availability of AllowAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== GetApplicationState ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS499 || OK TriCore<br />
| GetApplicationState<br />
|-<br />
| OS495 || OK TriCore<br />
| If the <Application> in a call of GetApplicationState() is not valid GetApplicationState() shall return E_OS_ID.<br />
|-<br />
| OS496 || OK TriCore<br />
| If the parameters in a call of GetApplicationState() are valid, GetApplicationState() shall return the state of OS-Application <Application> in <Value>.<br />
|-<br />
| OS537 || No scalability Classes support<br />
| Availability of GetApplicationState(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific StartupHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS539 || OK<br />
| Application specific StartupHook. The application specific StartupHook is always called after the standard StartupHook() (see OS236). If more than one OS-Application is configured which use startup hooks, the order of calls to the startup hooks of the different OS- Applications is not defined.<br />
|-<br />
| OS543 || No scalability Classes support<br />
| Availability of StartupHook_<App>(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific ErrorHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS540 || OK TriCore<br />
| Application specific ErrorHook. If the general ErrorHook() is configured, the general ErrorHook() is called before the application specific error hook is called (see OS246).<br />
|-<br />
| OS544 || OK TriCore<br />
| Availability of ErrorHook_<App>(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific ShutdownHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS541 || OK<br />
| Application specific ShutdownHook. If the general ShutdownHook() is configured, the general ShutdownHook() is called after all application specific shutdown hook(s) are called (see OS237). If more OS-Applications with an application specific shutdown hook exist the order of calls to these application specific shutdown hooks is not defined.<br />
|-<br />
| OS545 || No scalability Classes support<br />
| Availability of ShutdownHook_<App>(): Available in Scalability Classes 3 and 4. <br />
|}<br />
<br />
=== OS-Applications notes ===<br />
* [a] - Application-specific hook will be supported by TriCore full release.<br />
* [b] - Object protection will be introduced by TriCore full release, by now all objects are accessible by any OS-Application.<br />
* [c] - Termination of OS-Applications will be introduced by TriCore full release, is not supported yet.<br />
<br />
== Privileged mode ==<br />
<br />
Please see note [[#Privileged mode notes|<sup>[a]</sup>]].<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS058 || OK<br />
| If supported by hardware, the Operating System shall execute non-trusted OS-Applications in non-privileged mode.<br />
|-<br />
| OS096 || OK<br />
| As far as supported by hardware, the Operating System shall not allow non- trusted OS-Applications to access control registers managed by the Operating System.<br />
|-<br />
| OS245 || OK[[#Privileged mode notes|<sup>[b]</sup>]]<br />
| If an instruction exception occurs (e.g. division by zero) the operating system shall call the protection hook with E_OS_PROTECTION_EXCEPTION.<br />
|-<br />
| OS451 || OK<br />
| The Operating System shall allow to export services from trusted OS-Applications.<br />
|-<br />
| OS097 || OK<br />
| The Operating System shall provide a mechanism to call a trusted function from a (trusted or non-trusted) OS-Application.<br />
|-<br />
| OS100 || OK<br />
| If a called trusted function is not configured the Operating System shall call the ErrorHook with E_OS_SERVICEID.<br />
|-<br />
| OS226 || OK[[#Privileged mode notes|<sup>[b]</sup>]]<br />
| The Operating System shall execute an application-specific startup hook with the access rights of the associated OS-Application.<br />
|}<br />
<br />
=== CallTrustedFunction ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS097 || OK<br />
| CallTrustedFunction<br />
|-<br />
| OS265 || OK<br />
| If <FunctionIndex> is a defined function index, CallTrustedFunction() shall switch the processor into privileged mode AND shall call the function <FunctionIndex> out of a list of implementation specific trusted functions with disabled memory protection AND shall return E_OK after completion.<br />
|-<br />
| OS312 || OK<br />
| Caveats of CallTrustedFunction():<br />
* The called trusted function must conform to the following C prototype: void TRUSTED_<name_of_the_trusted_service>( TrustedFunctionIndexType,TrustedFunctionParameterRefType); (The arguments are the same as the arguments of CallTrustedFunction).<br />
* Normally, a user will not directly call this service, but it will be part of some standard interface, e.g. a standard I/O interface.<br />
* It is the duty of the called trusted function to check rights of passed parameters, especially if parameters are interpreted as out parameters.<br />
* It should be noted that the CallTrustedFunction() does not disable timing protection for the task which called the service. This may lead to timing faults (calls of the ProtectionHook()) even inside of a trusted OS-Application. It is therefore recommended to use CallTrustedFunction() only for stateless functions (e.g. functions which do not write or do not have internal states)<br />
|-<br />
| OS266 || OK [[#Privileged mode notes|<sup>[b]</sup>]]<br />
| When CallTrustedFunction() calls the function <FunctionIndex>, that function shall be executed with the same processor mode and memory protection boundaries as the OS-Application to which it belongs. It shall however retain the timing protection and service protection limitations of the calling Task or ISR, and the notion of "current application" shall remain that of the calling Task or Category 2 ISR.<br />
|-<br />
| OS364 || OK [[#Privileged mode notes|<sup>[b]</sup>]][[#Privileged mode notes|<sup>[c]</sup>]]<br />
| If CallTrustedFunction() calls the trusted function from a Category 2 ISR context, that function shall continue to run on the same interrupt priority and be allowed to call all system services defined for Category 2 ISR (see table in chapter 7.7.3.2).<br />
|-<br />
| OS365 || OK [[#Privileged mode notes|<sup>[b]</sup>]][[#Privileged mode notes|<sup>[c]</sup>]]<br />
| If CallTrustedFunction() calls the trusted function from a task context, that function shall continue to run on the same priority and be allowed to call all system services defined for tasks (see table in chapter 7.7.3.2).<br />
|}<br />
<br />
=== Privileged mode notes ===<br />
: [a] - In MPC5674F priviliged mode is enabled by the SC4 flag (This incomplete support of scalability classes have been removed in TriCore porting).<br />
: [b] - Supported only by TriCore implementation.<br />
: [c] - In MPC5674F a trusted function is executed in the security context of the calling function, although it runs in privileged mode.<br />
<br />
== Protection hook ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS099 || OK (See CheckTaskMemoryAccess() and CheckISRMemoryAccess())<br />
| The Operating System shall offer OS-Applications a service to check if a memory region is write/read/execute accessible from a Task/Category 2 OsIsr and also return information if the memory region is part of the stack space.<br />
|-<br />
| OS211 || OK TriCore<br />
| The Operating System shall execute the ProtectionHook() with the same permissions as the Operating System.<br />
|-<br />
| OS106 || OK TriCore<br />
| The Operating System shall perform one of the following reactions depending on the return value of the ProtectionHook():<br />
* Do nothing<br />
* Forcibly terminate the faulty Task/Category 2 OsIsr OR<br />
* Forcibly terminate the faulty OS-Application OR<br />
* Forcibly terminate the faulty OS-Application and restart the OS-Application. OR<br />
* Call ShutdownOS().<br />
|-<br />
| OS107 || OK TriCore<br />
| If no ProtectionHook() is configured and a protection error occurs, the Operating System shall call ShutdownOS().<br />
|-<br />
| OS475 || OK TriCore<br />
| If the reaction is to do nothing and the ProtectionHook() was not called with E_OS_PROTECTION_ARRIVAL then the Operating System shall call ShutdownOS()<br />
|-<br />
| OS243 || OK TriCore<br />
| If the reaction is to forcibly terminate the Task/Category 2 OsIsr and no Task or OsIsr can be associated with the error, the running OS-Application is forcibly terminated by the Operating System.<br />
|-<br />
| OS244 || OK TriCore<br />
| If the reaction is to forcibly terminate the faulty OS-Application and no OS- Application can be assigned, ShutdownOS()is called.<br />
|-<br />
| OS108 || OK TriCore<br />
| If the Operating System forcibly terminates a task, it terminates the task (no PostTaskHook() for the task will be called), releases all allocated OSEK resources and calls EnableAllInterrupts()/ / ResumeOSInterrupts() ResumeAllInterrupts() if the Task called DisableAllInterrupts() / / SuspendAllInterrupts() before without the SuspendOSInterrupts() EnableAllInterrupts()/ / corresponding ResumeOSInterrupts() ResumeAllInterrupts() call.<br />
|-<br />
| OS109 || OK TriCore<br />
| If the Operating System forcibly terminates an interrupt service routine, it clears the interrupt request, aborts the interrupt service routine (The interrupt source stays in the current state.) and releases all OSEK resources the interrupt service routine has allocated and calls EnableAllInterrupts() / ResumeOSInterrupts() / ResumeAllInterrupts() if the interrupt called DisableAllInterrupts() / / SuspendAllInterrupts() before without the SuspendOSInterrupts() corresponding EnableAllInterrupts()/ / ResumeOSInterrupts() ResumeAllInterrupts() call.<br />
|-<br />
| OS538 || OK TriCore<br />
| Protection Hook Depending on the return value the Operating System module will either:<br />
* forcibly terminate the Task/Category 2 ISR which causes the problem OR<br />
* forcibly terminate the OS-Application the Task/Category 2 ISR belong (optional with restart) OR<br />
* shutdown the system OR<br />
* do nothing (see 7.8.2)<br />
|-<br />
| OS308 || OK TriCore<br />
| If ProtectionHook() returns an invalid value, the Operating System module shall take the same action as if no protection hook is configured.<br />
|-<br />
| OS542 || No scalability Classes support<br />
| Availability of ProtectionHook(): Available in Scalability Classes 2, 3 and 4.<br />
|}<br />
<br />
= Other New Autosar APIs =<br />
<br />
=== GetISRID ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS511 || OK<br />
| GetISRID<br />
|-<br />
| OS263 || OK<br />
| If called from category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID() shall return the identifier of the currently executing ISR.<br />
|-<br />
| OS264 || partial<br />
| If its caller is not a category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID() shall return INVALID_ISR.<br />
|-<br />
| OS515 || OK (?)<br />
| Availability of GetISRID(): Available in all Scalability Classes.<br />
|}<br />
<br />
<br />
= Timing Protection =<br />
<br />
Actually implemented only for Tricore<br />
<br />
== General Requirement ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS028 || OK, but not Enforced by RT-Druid<br />
| In a non-trusted OS-Application, the Operating System module shall apply timing protection to every Task/Category 2 ISR of this non-trusted OS-Application<br />
|-<br />
| OS089 || OK<br />
| In a trusted OS-Application, the Operating System module shall provide the ability to apply timing protection to Tasks/Category 2 ISRs of this OS-Application.<br />
|-<br />
| OS397 || OK<br />
| If no OS-Application is configured, the Operating System module shall be able to apply timing protection to Tasks/Category 2 ISRs.<br />
|}<br />
<br />
== Timing Protection: Tasks ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS064 || OK<br />
| If a task’s OsTaskExecutionBudget is reached then the Operating System module shall call the ProtectionHook() with E_OS_PROTECTION_TIME.<br />
|-<br />
| OS473 || OK<br />
| OsTaskExecutionBudget on a transition to the SUSPENDED or WAITING states.<br />
|-<br />
| OS465 || OK<br />
| The Operating System module shall limit the inter-arrival time of tasks to one per OsTaskTimeFrame<br />
|-<br />
| OS469 || OK<br />
| The Operating System module shall start an OsTaskTimeFrame when a task is activated successfully<br />
|-<br />
| OS472 || OK<br />
| The Operating System module shall start an OsTaskTimeFrame when a task is released successfully<br />
|-<br />
| OS466 || OK<br />
| If an attempt is made to activate a task before the end of an OsTaskTimeFrame then the Operating System module shall not perform the activation AND shall call the ProtectionHook() with E_OS_PROTECTION_ARRIVAL<br />
|-<br />
| OS467 || OK<br />
| If an attempt is made to release a task before the end of an OsTaskTimeFrame then the Operating System module shall not perform the release AND shall call the ProtectionHook() with E_OS_PROTECTION_ARRIVAL AND the event shall be set<br />
|-<br />
|}<br />
<br />
<br />
== Timing Protection: ISR2 ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS210 || OK<br />
| If a Category 2 ISR’s OsIsrExecutionBudget is reached then the Operating System module shall call the ProtectionHook() with E_OS_PROTECTION_TIME<br />
|-<br />
| OS474 || OK<br />
| The Operating System module shall rest an ISR’s OsIsrExecutionBudget when the ISR returns control to the Operating terminates<br />
|-<br />
| OS470 || OK<br />
| The Operating System module shall limit the inter-arrival time of Category 2 ISRs to one per OsIsrTimeFrame<br />
|-<br />
| OS471 || OK<br />
| The Operating System module shall measure the start of an OsIsrTimeFrame from the point at which it recognises the interrupt (i.e. in the Operating System interrupt wrapper)<br />
|-<br />
| OS048 || OK<br />
| If Category 2 interrupt occurs before the end of the OsIsrTimeFrame then the Operating System module shall not execute the user provided ISR AND shall call the ProtectionHook() with E_OS_PROTECTION_ARRIVAL<br />
|}<br />
<br />
== Timing Protection: Resource Locking and Interrupt Disabling ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS033 || OK<br />
| <nowiki>If a Task/Category 2 ISR holds an OSEK Resource and exceeds the Os[Task|Isr]ResourceLockBudget, the Operating System module shall call the ProtectionHook() with E_OS_PROTECTION_LOCKED</nowiki><br />
|-<br />
| OS037 || OK<br />
| <nowiki>If a ISR disables interrupts (via Suspend/Disable|All/OS|Interrupts()) and exceeds the configured Os[Task|Isr][All|OS]InterruptLockBudget, the Operating System module shall call the ProtectionHook() Task/Category2 with E_OS_PROTECTION_LOCKED </nowiki><br />
|}<br />
<br />
= Multi-Core =<br />
<br />
== Basic Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS567 || OK (We have some doubts relates to this, but it should be OK)<br />
| The generated part of the OS is derived from a single configuration that contains the relevant information for all cores. This implies, that IDs (e.g. TASKID, RESOURCEID, …) are unique across cores. Every ID shall refer exactly to one entity independent from the core on which the entity is accessed. This applies also to objects that cannot be shared between cores. (BSW4080008)<br />
|-<br />
| OS568 || OK<br />
|Implementations shall be able to independently execute a TASK or an ISR on each started AUTOSAR OS core in parallel. (BSW4080001)<br />
|-<br />
| OS569 || OK<br />
|The scheduling strategy as defined in AUTOSAR OS shall apply for each individual core in a Multi-Core system, for the TASKs and ISR assigned to the core. (BSW4080001, BSW4080013)<br />
|-<br />
| OS570 || OK<br />
| All TASKs that are assigned to the same OS-Application shall execute on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS571 || OK<br />
| All ISRs that are assigned to the same OS-Application shall execute on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS572 || N.A. in Supported Architectures (PPC TriCore)<br />
| ISR balancing (if supported by the HW) shall be switched off at boot time by the OS. (BSW4080005, BSW4080006)<br />
|-<br />
| OS764 || No scalability classes support (OS-Applications are enabled when configurated).<br />
| The OS module shall support OS-Applications in case of Multi-Core also for SC1 and SC2.<br />
|-<br />
| OS763 || No scalability classes support (But we don't understend this requirement).<br />
| In an SC1 system standard mode shall be possible.<br />
|-<br />
| OS573 ||<br />
| The binding of OS-Applications to cores shall be configured within the OS-Application container. A new configuration item: OsApplicationCoreAssignment{CORE} within the OS-Application container shall be used to define the core to which the OS-Application is bound. The OS generator will map the configuration parameter “CORE” to a certain core, so that all OS-Applications with the same configuration parameter reside on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS623 || OK<br />
| The OS API function CallTrustedFunction shall return E_OS_ACCESS in extended status if the target trusted function is part of an OS-Application on another core. (BSW4080013)<br />
|-<br />
|}<br />
<br />
== Multi-Core start-up Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS574 || OK<br />
| The master core shall be able to activate cores. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS575 || OK<br />
| Any slave core shall be able to activate cores. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS576 || OK<br />
| It shall be allowed to use only a subset of the cores available on a μC for the AUTOSAR system. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS577 || OK (TriCore e PPC e200zx are naturally in Master-Slave configuration)<br />
| The cores shall boot in master-slave mode. If this is not supported by the hardware, it shall be that the cores boot in parallel and emulate the behavior of a master-slave system.. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS578 || N.A.<br />
| In case of an emulation a slave core (CoreS), which is controlled by the AUTOSAR OS (AUTOSAR core), shall not enter the main function before another<br />
core has activated the slave core by means of StartCore(CoreS). (BSW4080006)<br />
|-<br />
| OS579 || OK<br />
| All cores that belong to the AUTOSAR system shall be synchronized within the StartOS function before the scheduling is started and after the global<br />
StartupHook is called.. (BSW4080001, BSW4080006)<br />
|-<br />
| OS580 || OK<br />
| All cores that belong to the AUTOSAR system shall be synchronized within the StartOS function before the scheduling is started and after the global<br />
StartupHook is called.. (BSW4080006)<br />
|-<br />
| OS581 || OK TriCore<br />
| The global StartupHook shall be called on all cores immediately after the first synchronisation point (BSW4080006)<br />
|-<br />
| OS582 || OK TriCore<br />
| The OS-Application-specific StartupHooks shall be called after the global StartupHook but only on the cores to which the OS-Application is bound (BSW4080006, BSW4080008)<br />
|-<br />
| || OK TriCore<br />
| The AUTOSAR OS API provides a StartCore function to start the cores under its control. The StartCore function takes a scalar value parameter of type CoreIDType, specifying the core that shall be started. StartCore can be called more than once on the master core and also on slave cores. Each core can only be started once, however The StartOS function shall be called on all cores that have been activated by StartCore. It is not allowed to call StartCore from a core that has already called StartOS. Cores that belong to the AUTOSAR system shall be started by the designated AUTOSAR OS API service StartCore.<br />
|-<br />
| OS583 || OK TriCore<br />
| The number of cores that can be controlled by the AUTOSAR OS shall be configured offline. A new configuration item (OsNumberOfCores) within the “OsOS” container is used to specify the maximum number of cores that are controlled by the AUTOSAR OS. If no value for (OsNumberOfCores) has been specified the number of cores shall be one. (BSW4080001, BSW4080011) <br />
|-<br />
| OS584 || OK TriCore<br />
| The AUTOSAR OS shall provide a function called StartNonAutosarCore that can be used to start cores, which are not controlled by the AUTOSAR OS. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS585 || OK TriCore<br />
| It shall be possible to activate cores that are not controlled by the AUTOSAR OS before and after calling StartOS. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS606 || OK TriCore<br />
| The AUTOSAR specification does not support the activation of AUTOSAR cores after calling StartOS on that core. If StartCore is called after StartOS it shall return with E_OS_ACCESS in extended status. (BSW4080001)<br />
|-<br />
| OS607 || OK TriCore<br />
| StartOS shall start the OS on the core on which it is called. (BSW4080006, BSW4080013)<br />
|-<br />
| OS608 || OK TriCore<br />
| If more than one core calls StartOS with an AppMode other than “DONOTCARE”, the AppModes shall be the same. StartOS shall check this at the first synchronisation point. In case of violation, StartOS shall not start the scheduling, shall not call any StartupHooks, and shall enter an endless loop on every core. (BSW4080006)<br />
|-<br />
| OS609 || OK TriCore<br />
| If StartOS is called with the AppMode “DONOTCARE” the application mode of the other core(s) (differing from “DONOTCARE”) shall be used. (BSW4080006)<br />
|-<br />
| OS610 || OK TriCore<br />
| At least one core shall define an AppMode other than “DONOTCARE”. (BSW4080006)<br />
|-<br />
| OS611 || OK TriCore<br />
| If the IOC is configured, StartOS shall initialize the data structures of the IOC. (BSW4080020)<br />
|-<br />
| OS668 || OK<br />
| The AUTOSAR Operating System shall automatically activate all auto-start TASKs configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
| OS669 || OK<br />
| The AUTOSAR Operating System shall automatically activate all auto-start ALARMs configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
| OS670 || Not Schedule tables supported yet<br />
| The AUTOSAR Operating System shall automatically activate all auto-start schedule tables configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
|}<br />
<br />
== Multicore Shutdown Requirements ==<br />
<br />
AUTOSAR supports two shutdown concepts, the synchronized shutdown and the individual shutdown concept. While the synchronized shutdown is triggered by the new API function '''ShutdownAllCores()''', the individual shutdown is invoked by the existing API function '''ShutdownOS()'''.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS586 || OK TriCore<br />
| During the shutdown, the OS-Application specific ShutdownHook shall be called on the core on which the corresponding OS-Application is bound. (BSW4080007)<br />
|- <br />
| OS587 || OK TriCore (if ShutdownAllCores has been called)<br />
| Before calling the global ShutdownHook, all cores shall be synchronized. (BSW4080007)<br />
|- <br />
| OS588 || OK<br />
| The global ShutdownHook shall be called on all cores. (BSW4080007)<br />
|-<br />
| OS762 || OK TriCore (fullfilled by ProtectionHook implementation)<br />
| In cases where the OS detects a fatal internal error all cores shall be shutdown.<br />
|-<br />
| OS616 || OK<br />
| ShutdownOS shall be callable from each core running an AUTOSAR OS. (BSW4080001, BSW4080007)<br />
|-<br />
| OS617 || OK<br />
| ShutdownOS shall shutdown the core on which it was called. (BSW4080007)<br />
|-<br />
| OS618 || OK<br />
| The OS shall not start TASKs of an OS-Application once the shutdown procedure has been entered on a particular core. (BSW4080013)<br />
|-<br />
| OS619 || OK<br />
| The AUTOSAR OS function ShutdownOS shall be callable in parallel on multiple cores. (BSW4080013)<br />
|-<br />
| OS620 || OK TriCore<br />
| ShutdownOS shall release all spinlocks which are occupied by the calling core. (BSW4080021)<br />
|-<br />
| OS621 || OK TriCore<br />
| ShutdownAllCores shall be callable from each core running an AUTOSAR OS. (BSW4080007)<br />
|-<br />
|}<br />
<br />
== OS Other Services Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS589 || OK TriCore<br />
| All functions that are not allowed to operate cross core shall return E_OS_CORE in extended status if called with parameters that require a cross core operation. (BSW4080013)<br />
|-<br />
| OS590 || OK<br />
| The OS service “DisableAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS591 || OK<br />
| The OS service “EnableAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS592 || OK<br />
| The OS service “SuspendAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS593 || OK<br />
| The OS service “ResumeAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS594 || OK<br />
| The OS service “SuspendOSInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS595 || OK<br />
| The OS service “ResumeOSInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS596 || OK<br />
| It shall be possible to activate a TASK that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080001, BSW4080015)<br />
|-<br />
| OS598 || OK TriCore (RPC Dispactcher)<br />
| The call of ActivateTask across cores shall behave synchronously, i.e. a call returns after the task has been activated or an error has been detected. It shall not be possible to continue execution on the calling core before ActivateTask is accomplished on the remote core. (BSW4080015)<br />
|-<br />
| OS599 || OK TriCore (RPC Dispactcher)<br />
| In case of an error when calling ActivateTask across cores, the error handler shall be called on the core on which ActivateTask was originally called. (BSW4080015)<br />
|-<br />
| OS600 || OK<br />
| It shall be possible to chain a TASK that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080001, BSW4080015)<br />
|-<br />
| OS602 || OK<br />
| It shall be possible to set an EVENT that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080016)<br />
|-<br />
| OS604 || OK TriCore (RPC Dispactcher)<br />
| The call of SetEvent across cores shall behave synchronously, i.e. a call returns after the Event has been set or an error has been detected. It shall not be possible to continue execution on the calling core before SetEvent is accomplished on the remote core. (BSW4080016)<br />
|-<br />
| OS605 || OK TriCore (RPC Dispactcher [[#MultiCore notes|<sup>[a]</sup>]])<br />
| In case of an error when calling SetEvent across cores, the error handler shall be called on the core on which SetEvent was originally called. (BSW4080016)<br />
|-<br />
| OS612 || OK TriCore<br />
| In extended status TerminateTask / ChainTask shall return with an error (E_OS_SPINLOCK), which can be evaluated in the application. (BSW4080021)<br />
|-<br />
| OS613 || OK TriCore<br />
| Spinlocks occupied by TASKS that are terminated in response to a protection hook shall be automatically released. This applies also to the case in which an OS-Application is terminated. (BSW4080021)<br />
|-<br />
| OS614 || OK TriCore<br />
| TerminateApplication shall check if any of the TASKs in the OS-Application have occupied a spinlock. If so, the spinlocks shall be released.(BSW4080021)<br />
|-<br />
| OS615 ||<br />
| If TerminateApplication(A) is called in parallel from different cores, the OsApplication “A” is terminated by the first call, any subsequent calls will return with 'E_OK' in standard and extended status without doing anything, until the termination is completed.<br />
|-<br />
| OS622 || OK<br />
| The AUTOSAR Operating System WaitEvent API service shall check if it has been called while the calling TASK has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the TASK shall not enter the wait state. (BSW4080021)<br />
|-<br />
| OS624 || OK<br />
| The AUTOSAR Operating System Schedule API service shall check if it has been called while the calling TASK has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the scheduler shall not be called. (BSW4080021)<br />
|-<br />
| OS629 || OK<br />
| A COUNTER belonging to an OS-Application shall be incremented by the core on which the OS-Application resides. The COUNTER shall not be incremented by other cores. (BSW4080013)<br />
|-<br />
| OS630 || OK<br />
| It shall not be allowed to drive a schedule table from a COUNTER, which is assigned to a different core. (BSW4080013)<br />
|-<br />
| OS631 || OK<br />
| It shall not be allowed to drive an ALARM from a COUNTER, which is assigned to a different core. (BSW4080013)<br />
|-<br />
| OS632 || OK<br />
| If an ALARM expires, it shall be allowed to activate a TASK on a different core. (BSW4080018)<br />
|-<br />
| OS633 || OK<br />
| If an ALARM expires, it shall be allowed to set an EVENT on a different core. (BSW4080018)<br />
|-<br />
| OS634 || OK<br />
| The AUTOSAR Operating System shall process an ALARM on the core on which its corresponding OS-Application resides. (BSW4080018)<br />
|-<br />
| OS635 || OK<br />
| ALARM callbacks shall be executed on the core to which the ALARM is bound. This is only applicable to SC1 systems, because otherwise Alarm Callback<br />
are not allowed (OS242). (BSW4080013)<br />
|-<br />
| OS636 || OK<br />
| SetRelAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|-<br />
| OS637 || OK<br />
| SetAbsAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS638 || OK<br />
| CancelAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS639 || OK<br />
| GetAlarmBase shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS640 || OK<br />
| GetAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
|}<br />
<br />
== MultiCore notes ==<br />
: [a] - [[Infineon_Aurix#Multicore_Autosar_OS_Support|New RPC MultiCore dispatcher]]<br />
<br />
== Other AUTOSAR Multicore API ==<br />
<br />
=== GetCoreID ===<br />
<br />
Every HW assigns a unique physical Id to a core. The physical core Id is the only way to distinguish between cores. <br />
The physical core Ids of a μC are not necessarily consecutive and do not necessarily start with zero.<br />
The SW requires a mechanism to identify a core, e.g. to use core specific variables. Because the physical core Id usually can not be used as a direct array index for core specific variables, a logical CoreID is necessary to map physical core Ids to array indexes. In the SW it is not necessary to know the physical core Id, the logical CoreID is sufficient.<br />
The mapping of OSApplications and other SW objects to cores is specified in the configuration files. All such mappings shall be HW independent and therefore shall not be based on the physical core Id but on the logical CoreID. The function GetCoreID internally maps the physical core Id to the logical CoreID. The mapping is implementation specific. GetCoreID can be either a C function or a macro.<br />
<br />
'''N.B''' In Erika with code replication the core ID is not a real issue.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS625 || OK TriCore<br />
| The AUTOSAR Operating System API function GetCoreID shall be callable before StartOS. (BSW4080006)<br />
|-<br />
| OS626 || OK TriCore<br />
| An implementation shall offer a function GetNumberOfActivatedCores that returns the number of cores running the AUTOSAR OS. (BSW4080001)<br />
|-<br />
| OS627 || OK TriCore<br />
| An implementation shall define a set of constants OS_CORE_ID_<No> of the type CoreIDType with <No> a value from 0 to “OsNumberOfCores -1. (BSW4080001)<br />
|-<br />
| OS628 || OK TriCore<br />
| An implementation shall offer a constant OS_CORE_ID_MASTER of the type CoreIDType that refers to the master core. (BSW4080001)<br />
|}<br />
<br />
== Spinlocks ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS648 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a spinlock mechanism that works across cores. (BSW4080018, BSW4080021)<br />
|-<br />
| OS649 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a GetSpinlock function which occupies a spinlock. If the spinlock is already occupied, GetSpinlock shall<br />
keep on trying to occupy the spinlock until it succeeds. (BSW4080018, BSW4080021)<br />
|-<br />
| OS650 || OK TriCore<br />
| GetSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS651 || OK TriCore<br />
| GetSpinlock shall be callable from ISR2 level. The behavior of GetSpinlock is undefined if called from a category 1 ISR. (BSW4080021)<br />
|-<br />
| OS652 || OK TriCore (With Trivial spinlocks)<br />
| The AUTOSAR Operating System shall provide a TryToGetSpinlock function which occupies a spinlock. If the spinlock is already occupied by a TASK,<br />
TryToGetSpinlock shall return. (BSW4080018, BSW4080021)<br />
|-<br />
| OS653 || OK TriCore<br />
| TryToGetSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS654 || OK TriCore<br />
| TryToGetSpinlock shall be callable from ISR2 level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS655 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a ReleaseSpinlock function which releases an occupied spinlock. If the spinlock is not occupied an error<br />
shall be returned. (BSW4080018, BSW4080021)<br />
|-<br />
| OS656 || OK TriCore<br />
| ReleaseSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS657 || OK TriCore<br />
| ReleaseSpinlock shall be callable from ISR2 level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS658 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if a TASK tries to occupy a spinlock that is assigned to a TASK/ISR2 on the same core (including<br />
itself). (BSW4080018, BSW4080021)<br />
|-<br />
| OS659 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if an ISR2 tries to occupy a spinlock that is assigned to a TASK/ISR2 on the same core.<br />
(BSW4080018, BSW4080021)<br />
|-<br />
| OS660 || OK TriCore<br />
| A unique order in which multiple spinlocks can be occupied by a TASK/ISR2 should be configurable in the AUTOSAR Operating System. This might<br />
be realized by the configuration item (OsSpinlockSuccessor{NEXT_SPINLOCK}) where “NEXT_SPINLOCK” refers to the consecutive spinlock. (See chapter 10.2.5) (BSW4080018, BSW4080021)<br />
|-<br />
| OS661 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if a TASK/ISR2 that currently holds a spinlock tries to seize another spinlock that has not been<br />
configured as a direct or indirect successor of the latest acquired spinlock (by means of the OsSpinlockSuccessor configuration parameter) or if no successor is configured. (BSW4080018, BSW4080021)<br />
|-<br />
|}<br />
<br />
= Inter-OS-Application Communicator (IOC) Requirements =<br />
<br />
IOC stands for Inter OS-Application Communicator. The "IOC" is responsible for the communication between OS-Applications and in<br />
particular for the communication crossing core or memory protection boundaries. It's internal functionality is closely connected to the Operating System.<br />
<br />
Memory protection boundaries are a characteristic of OS-Applications and special communication mechanisms are needed to cross them.<br />
Multi-Core systems may also need additional measures to make communication between cores safe.<br />
<br />
The IOC provides communication services between OS-Applications and in particular over core boundaries in Multi-Core systems. Because the cross-core communication is always an inter-OS-Application communication, the two mechanisms are combined. An inter OS-Application communication may not necessarily require a cross core communication, however.<br />
<br />
In systems with only one core, the IOC can be omitted completely, if just one OS-Application is available, or if no OS-Application uses memory protection mechanisms.<br />
<br />
'''N.B''' Since a lot of Code of IOC is configurated and generated starting from RTE configuration, it doesn't make sense generate a whole IOC system without a complete RTE generator. But '''we choiced the cross-boundaries communication mechanism''' that is the heart of IOC. The same mechanism is employed to implement OS Services remote invocation.<br />
<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS671 ||<br />
| The IOC implementation shall be part of the Operating System The IOC is a third type of communication, in addition to:<br />
* Intra OS-Application communication: Always handled within the RTE<br />
* Inter ECU communication: already available via well defined interfaces to the communication stack (COM).<br />
(BSW4080020)<br />
|-<br />
|}</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=ERIKA_%26_Autosar_OS_RequirementsERIKA & Autosar OS Requirements2016-09-30T14:14:37Z<p>Eguidieri: /* Timing Protection */</p>
<hr />
<div>= Introduction =<br />
Erika Enterprise is the first open-source Free RTOS that has been certified OSEK/VDX compliant and it's under current developtment to fulfil Autosar 4 OS Requirements too. In the following table are logged the AUTOSAR requirements already implemneted in ERIKA.<br />
<br />
* All the requirement tagged as OK are implemented in all supported Architectures.<br />
* All the requirements related to '''memory protection''' are available only for those MCU that have memory protection implmentented: currently only support for Freescale MPC5674F has been released.<br />
* All the requirements tagged as TriCore are implemented but will be realesed when the full support for TriCore AURIX will be released.<br />
<br />
Scalability Classes are not implemented yet, but each feature/API is activated only if required by the configuration.<br />
<br />
= Tasks =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS052 || OK<br />
| If a task returns from its entry function without making a TerminateTask() or ChainTask() call, the Operating System shall terminate the task (and call the PostTaskHook() if configured).<br />
|-<br />
| OS069 || OK<br />
| If a task returns from its entry function without making a TerminateTask() or ChainTask() call AND the error hook is configured, the Operating System shall call the ErrorHook() (this is done regardless of whether the task causes other errors, e.g. E_OS_RESOURCE) with status E_OS_MISSINGEND before the task leaves the RUNNING state.<br />
|-<br />
| OS070 || OK<br />
| If a task returns from the entry function without making a TerminateTask() or ChainTask() call and still holds OSEK Resources, the Operating System shall release them.<br />
|-<br />
| OS239 || OK<br />
| If a task returns from the entry function without making a TerminateTask() or ChainTask() call and interrupts are still disabled, the Operating System shall enable them.<br />
|-<br />
| OS071 || OK<br />
| If the PostTaskHook() is configured, the Operating System shall not call the hook if ShutdownOS() is called.<br />
|}<br />
<br />
= ISR2s =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS368 || OK<br />
| If a Category 2 OsIsr calls DisableAllInterupts() SuspendAllInterrupts() / SuspendOSInterrupts() and ends (returns) without calling the corresponding EnableAllInterrupts() / ResumeAllInterrupts() / ResumeOSInterrupts(), the Operating System shall perform the missing service and shall call the ErrorHook() (if configured) with the status E_OS_DISABLEDINT.<br />
|-<br />
| OS369 || OK<br />
| If a Category 2 OsIsr calls GetResource() and ends (returns) without calling the corresponding ReleaseResource(), the Operating System shall perform the ReleaseResource() call and shall call the ErrorHook() (if configured) with the status E_OS_RESOURCE.<br />
|}<br />
<br />
= Hooks =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS236 || OK TriCore<br />
| If both a system-specific and one (or more) application specific startup hook(s) are configured, the Operating System shall call the system-specific startup hook before the application-specific startup hook(s).<br />
|-<br />
| OS112 || OK TriCore<br />
| If an application-specific shutdown hook is configured for an OS-Application <App>, the Operating System shall call ShutdownHook_<App> on shutdown of the OS.<br />
|-<br />
| OS225 || OK TriCore<br />
| The Operating System shall execute an application-specific shutdown hook with the access rights of the associated OS-Application.<br />
|-<br />
| OS237 || OK TriCore<br />
| If both a system-specific and one (or more) application specific shutdown hook(s) are configured, the Operating System shall call the system-specific shutdown hook after the application-specific shutdown hook(s).<br />
|-<br />
| OS246 || OK TriCore<br />
| When an error occurs AND an application-specific error hook is configured for the faulty OS-Application <App>, the Operating System shall call that application- specific error hook ErrorHook_<App> after the system specific error hook is called (if configured).<br />
|-<br />
| OS085 || OK TriCore<br />
| The Operating System shall execute an application-specific error hook with the access rights of the associated OS-Application.<br />
|}<br />
<br />
= Timers and Counters =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS301 || OK<br />
| The Operating System shall provide the ability to increment a software counter as an alternative action on alarm expiry.<br />
|-<br />
| OS399 || OK<br />
| The OS shall provide an API call to increment a software counter.<br />
|-<br />
| OS374 || OK<br />
| The Operating System shall handle all the initialization and configuration of timers used directly by the OS and not handled by the GPT driver.<br />
|-<br />
| OS383 || OK (partials)<br />
| The Operating System shall provide a service to read the current count value of a counter (returning either the hardware timer ticks if counter is driven by hardware or the software ticks when user drives counter).<br />
|-<br />
| OS392 || OK<br />
| The Operating System shall provide a service to get the number of ticks between the current tick value and a previously read tick value.<br />
|-<br />
| OS384 ||<br />
| The Operating System shall adjust the read out values of hardware timers (which drive counters) in such that the lowest value is zero and consecutive reads return an increasing count value until the timer wraps at its modulus.<br />
|}<br />
<br />
== Autosar New API for Timers and Counters ==<br />
<br />
=== IncrementCounter ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS399 || OK<br />
| IncrementCounter<br />
|-<br />
| OS285 || OK<br />
| If the input parameter <CounterID> in a call of IncrementCounter() is not valid OR the counter is a hardware counter, IncrementCounter() shall return E_OS_ID.<br />
|-<br />
| OS286 || OK<br />
| If the input parameter of IncrementCounter() is valid, IncrementCounter() shall increment the counter <CounterID> by one (if any alarm connected to this counter expires, the given action, e.g. task activation, is done) and shall return E_OK.<br />
|-<br />
| OS321 || OK<br />
| If in a call of IncrementCounter() an error happens during the execution of an alarm action, e.g. E_OS_LIMIT caused by a task activation, IncrementCounter() shall call the error hook(s), but the IncrementCounter() service itself shall return E_OK.<br />
|-<br />
| OS529 || OK<br />
| Caveats of IncrementCounter(): If called from a task, rescheduling may take place.<br />
|-<br />
| OS530 || OK<br />
| Availability of IncrementCounter(): Available in all Scalability Classes.<br />
|}<br />
<br />
=== GetCounterValue ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS383 || OK<br />
| GetCounterValue<br />
|-<br />
| OS376 || OK<br />
| If the input parameter <CounterID> in a call of GetCounterValue() is not valid, GetCounterValue() shall return E_OS_ID.<br />
|-<br />
| OS377 || OK<br />
| If the input parameter <CounterID> in a call of GetCounterValue() is valid, GetCounterValue() shall return the current tick value of the counter via <Value> and return E_OK.<br />
|-<br />
| OS531 || OK (partials)<br />
| Caveats of GetCounterValue(): Note that for counters of OsCounterType = HARDWARE the real timer value (the – possibly adjusted – hardware value, see OS384) is returned, whereas for counters of OsCounterType = SOFTWARE the current “software” tick value is returned.<br />
|-<br />
| OS532 || OK<br />
| Availability of GetCounterValue(): Available in all Scalability Classes.<br />
|}<br />
<br />
=== GetElapsedValue ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS392 || OK<br />
| GetElapsedValue<br />
|-<br />
| OS381 || OK<br />
| If the input parameter <CounterID> in a call of GetElapsedValue() is not valid GetElapsedValue() shall return E_OS_ID.<br />
|-<br />
| OS391 || OK<br />
| If the <Value> in a call of GetElapsedValue() is larger than the max allowed value of the <CounterID>, GetElapsedValue() shall return E_OS_VALUE.<br />
|-<br />
| OS382 || OK<br />
| If the input parameters in a call of GetElapsedValue() are valid, GetElapsedValue() shall return the number of elapsed ticks since the given <Value> value via <ElapsedValue> and shall return E_OK.<br />
|-<br />
| OS460 || OK<br />
| GetElapsedValue() shall return the current tick value of the counter in the <Value> parameter.<br />
|-<br />
| OS533 || OK<br />
| Caveats of GetCounterValue():If the timer already passed the <Value> value a second (or multiple) time, the result returned is wrong. The reason is that the service can not detect such a relative overflow.<br />
|-<br />
| OS534 || OK<br />
| Availability of GetCounterValue(): Available in all Scalability Classes.<br />
|}<br />
<br />
== OSEK Requirements Extensions ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS304 || OK<br />
| If in a call to SetRelAlarm() the parameter “increment” is set to zero, the service shall return E_OS_VALUE in standard and extended status .<br />
|-<br />
| OS424 || OK<br />
| The first call to StartOS() (for starting the Operating System) shall not return.<br />
|-<br />
| OS425 || OK<br />
| If ShutdownOS() is called and ShutdownHook() returns then the operating system shall disable all interrupts and enter an endless loop.<br />
|-<br />
| OS299 || OK<br />
|The Operating System shall provide the services DisableAllInterrupts(), EnableAllInterrupts(), SuspendAllInterrupts(), ResumeAllInterrupts() prior to calling StartOS() and after calling ShutdownOS(). (It is assumed that the static variables of these functions are initialized).<br />
|-<br />
| OS051 || OK TriCore<br />
| If an invalid address (address is not writable by this OS-Application) is passed as an out-parameter to an OS service, the Operating System shall return the status code E_OS_ILLEGAL_ADDRESS.<br />
|-<br />
| OS088 || OK TriCore<br />
| If an OS-Application makes a service call from the wrong context AND is currently not inside a Category 1 OsIsr the Operating System shall not perform the requested action (the service call shall have no effect), and return E_OS_CALLEVEL or the “invalid value” of the service.<br />
|-<br />
| OS092 || OK<br />
| If EnableAllInterrupts() ResumeAllInterrupts() / ResumeOSInterrupts() are called and no corresponding DisableAllInterupts() / SuspendAllInterrupts() / SuspendOSInterrupts() was done before, the Operating System shall not perform this OS service.<br />
|-<br />
| OS093 || OK<br />
| If interrupts are disabled/suspended by a Task/OsIsr and the Task/OsIsr calls any OS service (excluding the interrupt services) then the Operating System shall ignore the service AND shall return E_OS_DISABLEDINT if the service returns a StatusType value.<br />
|-<br />
| OS054 || OK TriCore<br />
| The Operating System shall ignore calls to ShutdownOS() from non-trusted OS-Applications.<br />
|-<br />
| OS056 || OK TriCore<br />
| If an OS-object identifier is the parameter of a system service, and no sufficient access rights have been assigned at configuration time (Parameter Os[...]AccessingApplication) to the calling Task/Category 2 OsIsr, the system service shall return E_OS_ACCESS.<br />
|-<br />
| OS449 || OK<br />
| CheckTaskMemoryAccess and CheckIsrMemoryAccess check the memory access. Memory access checking is possible for all OS-Applications and from all OS- Applications and does not need granted rights (This is an exception to OS056).<br />
|-<br />
| OS450 || OK<br />
| CheckObjectAccess checks the access rights for OS objects. Checking object access is possible for all OS-Applications and from all OS-Applications and does not need granted rights (This is an exception to OS056).<br />
|-<br />
| OS439 || OK<br />
| The Operating System shall offer the OSEK error macros (OSError...()) to all configured error hooks AND there shall be two (like in OIL) global configuration parameter to switch these macros on or off.<br />
|-<br />
| OS367 || OK<br />
| Operating System services which do not return a StatusType shall not raise the error hook(s).<br />
|-<br />
| OS566 || OK<br />
| The Operating System API shall check in extended mode all pointer argument for NULL pointer and return OS_E_PARAMETER if such argument is NULL.<br />
|}<br />
<br />
= Minor Further Requirements =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS398 || OK<br />
| The OS shall not define the symbol LOCALMESSAGESONLY<br />
|-<br />
| OS242 || No scalability Classes support (But this will be prevented in Any AS configuration)<br />
| The Operating System shall only allow Alarm Callbacks in Scalability Class 1.<br />
|}<br />
<br />
= Memory protection =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS198 || Partial [[#Memory protection notes|<sup>[a]</sup>]]<br />
| The Operating System shall prevent write access to its own data sections and its own stack from non-trusted OS-Applications.<br />
|-<br />
| OS026 || OK (configurable)<br />
| The Operating System may prevent read access to an OS-Application’s data section attempted by other non-trusted OS-Applications.<br />
|-<br />
| OS086 || OK<br />
| The Operating System shall permit an OS-Application read and write access to that OS-Application’s own private data sections.<br />
|-<br />
| OS207 || OK<br />
| The Operating System shall prevent write access to the OS-Application’s private data sections from other non-trusted OS-Applications.<br />
|-<br />
| OS196 || OK<br />
| The Operating System shall permit a Task/Category 2 OsIsr read and write access to that Task’s/Category 2 OsIsr’s own private stack.<br />
|-<br />
| OS208 || OK (not prevented)<br />
| The Operating System may prevent write access to the private stack of Tasks/Category 2 OsIsrs of a non-trusted application from all other Tasks/OsIsrs in the same OS-Application.<br />
|-<br />
| OS355 || OK<br />
| The Operating System shall prevent write access to all private stacks of Tasks/Category 2 OsIsrs of an OS-Application from other non-trusted OS- Applications.<br />
|-<br />
| OS087 || OK<br />
| The Operating System shall permit a Task/Category 2 OsIsr read and write access to that Task’s/Category 2 OsIsr’s own private data sections.<br />
|-<br />
| OS195 || OK (not prevented)<br />
| The Operating System may prevent write access to the private data sections of a Task/Category 2 OsIsr of a non-trusted application from all other Tasks/OsIsrs in the same OS-Application.<br />
|-<br />
| OS356 || OK<br />
| The Operating System shall prevent write access to all private data sections of a Task/Category 2 OsIsr of an OS-Application from other non-trusted OS- Applications.<br />
|-<br />
| OS027 || OK (not protected)<br />
| The Operating System may provide an OS-Application the ability to protect its code sections against executing by non-trusted OS-Applications.<br />
|-<br />
| OS081 || OK (all code is shared)<br />
| The Operating System shall provide the ability to provide shared library code in sections that are executable by all OS-Applications.<br />
|-<br />
| OS209 || OK<br />
| The Operating System shall permit trusted OS-Applications read and write access to peripherals.<br />
|-<br />
| OS083 || Not done [[#Memory protection notes|<sup>[b]</sup>]]<br />
| The Operating System shall allow non-trusted OS-Applications to write to their assigned peripherals only (incl. reads that have the side effect of writing to a memory location).<br />
|-<br />
| OS044 || OK TriCore [[#Memory protection notes|<sup>[c]</sup>]]<br />
| If a memory access violation is detected, the Operating System shall call the Protection Hook with status code E_OS_PROTECTION_MEMORY.<br />
|}<br />
<br />
No timing and memory protection for alarm callbacks.<br />
<br />
== CheckISRMemoryAccess ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS512 || OK<br />
| CheckISRMemoryAccess<br />
|-<br />
| OS267 || OK<br />
| If the ISR reference <ISRID> in a call of CheckISRMemoryAccess() is valid, CheckISRMemoryAccess() shall return the access rights of the ISR on the specified memory area.<br />
|-<br />
| OS313 || OK [[#Memory protection notes|<sup>[d]</sup>]]<br />
| If an access right (e.g. “read”) is not valid for the whole memory area specified in a call of CheckISRMemoryAccess(), CheckISRMemoryAccess() shall yield no access regarding this right.<br />
|-<br />
| OS268 || OK<br />
| If the ISR reference <ISRID> is not valid, CheckISRMemoryAccess() shall yield no access rights.<br />
|-<br />
| OS517 || No scalability Classes support<br />
| Availability of CheckISRMemoryAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
== CheckTaskMemoryAccess ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS513 || OK<br />
| CheckTaskMemoryAccess<br />
|-<br />
| OS269 || OK<br />
| If the Task reference <TaskID> in a call of CheckTaskMemoryAccess() is valid, CheckTaskMemoryAccess() shall return the access rights of the task on the specified memory area.<br />
|-<br />
| OS314 || OK [[#Memory protection notes|<sup>[d]</sup>]]<br />
| If an access right (e.g. “read”) is not valid for the whole memory area specified in a call of CheckTaskMemoryAccess(), CheckTaskMemoryAccess() shall yield no access regarding this right.<br />
|-<br />
| OS270 || OK<br />
| If the Task reference <TaskID> in a call of CheckTaskMemoryAccess() is not valid, CheckTaskMemoryAccess() shall yield no access rights.<br />
|-<br />
| OS518 || No scalability Classes support<br />
| Availability of CheckTaskMemoryAccess(): Available in Scalability Classes 3 and 4<br />
|}<br />
<br />
== Memory protection notes ==<br />
* [a] - The OS shares the stack with tasks and ISRs. If SP is invalid when calling a system API, a fault may happen. If a context change happens inside a system call (e.g., ActivateTask() made on a task with higher priority), data from the OS remain saved on the stack of the calling task; other tasks or ISRs from the same OS-Application can overwrite those values. A solution for this problem is in testing on TriCore implementation, but since the kernel on AURIX never allocate stack (this is due to the special carateristic of TriCore Architecture and the compilers optimizations) the implementation cannot be proved until it will backported on PPC or on a new architecture with this pontential problem.<br />
* [b] - This is tricky. Currently, only trusted OS-Applications can access MCU registers. Probably the granularity of the MMU is not enough, and maybe the MPU is not suitable either.<br />
* [c] - In MPC5674F When a protection error occur, one of the IVOR routines is called, which jump to <code>__empty_handler</code>. In TriCore protection hook will be fully supported.<br />
* [d] - The current implementation is more restrictive. If the given memory range is not contained in a single memory section (e.g., it starts inside the stack section and ends inside BSS), no access is returned. This should not create problems, as crossing sections depends on the memory layout; relying on that would be very fragile and no application should do it.<br />
<br />
= Stack monitoring =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS067 || OK TriCore<br />
| The Operating System shall offer a stack monitoring which detects possible stack faults of Task(s)/Category 2 OsIsr(s).<br />
|-<br />
| OS068 || OK TriCore<br />
| If a stack fault is detected by stack monitoring AND the configured scalability class is 1 or 2, the Operating System shall call the ShutdownOS() service with the status E_OS_STACKFAULT.<br />
|-<br />
| OS396 || OK TriCore<br />
| If a stack fault is detected by stack monitoring AND the configured scalability class is 3 or 4, the Operating System shall call the ProtectionHook() with the status E_OS_STACKFAULT.<br />
|}<br />
<br />
= OS-Applications =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS445 || Partial [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| The Operating System shall support OS-Applications which are a composition of (at least one Task OR OsIsr) AND (zero or more Alarms, Schedule tables, Counters or Resources) AND (zero or one hooks for startup, error and shutdown).<br />
|-<br />
| OS446 || OK<br />
| The Operating System shall support the notion of trusted and not trusted OS-Applications.<br />
|-<br />
| OS464 || OK<br />
| Trusted OS-Applications may offer services (“trusted services”) to other (even non-trusted) OS-Applications.<br />
|-<br />
| OS016 || OK (see GetApplicationID())<br />
| The Operating System shall provide a service to determine the currently running OS-Application (a unique identifier shall be allocated to each application).<br />
|-<br />
| OS017 || OK (see CheckObjectOwnership())<br />
| The Operating System shall provide a service to determine to which OS-Application a given Task, OsIsr, Resource, Counter, Alarm or Schedule Table belongs.<br />
|-<br />
| OS256 || OK (see CheckObjectAccess())<br />
| The Operating System shall provide a service to determine which OS-Applications are allowed to use the IDs of a Task, OsIsr, Resource, Counter, Alarm or Schedule Table in API calls.<br />
|-<br />
| OS258 || OK (see TerminateApplication())<br />
| The Operating System shall provide a service to terminate the OS-Application to which the calling Task/Category 2 OsIsr/application specific error hook belongs. (This is an OS-Application level variant of the TerminateTask() service)<br />
|-<br />
| OS447 || OK<br />
| Terminating an OS-Application means to:<br />
* terminate all running, ready and waiting Tasks/OsIsrs of the OS-Application AND<br />
* disabling all interrupts of the OS-Application AND<br />
* stop all active alarms of the OS-Applications AND<br />
* stop all schedule tables of the OS-Application.<br />
|-<br />
| OS448 || OK TriCore<br />
| OS-Applications, trusted or non-trusted, shall by default have only access rights to objects belonging to this OS-Application. Access rights from other OS-Applications shall be granted explicitely by configuration.<br />
|-<br />
| OS060 || OK TriCore [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| If an application-specific startup hook is configured for an OS-Application <App>, the Operating System shall call StartupHook_<App> on startup of the OS.<br />
|-<br />
| OS110 || OK [[#OS-Applications notes|<sup>[c]</sup>]]<br />
| If the Operating System forcibly terminates an OS-Application, it:<br />
* forcibly terminates all Tasks/OsIsrs of the OS-Application AND<br />
* cancels all alarms of the OS-Application AND<br />
* stops schedule tables of the OS-Application AND<br />
* disables interrupt sources of Category 2 OsIsrs belonging to the OS-Application<br />
|-<br />
| OS111 || OK [[#OS-Applications notes|<sup>[c]</sup>]]<br />
| When the Operating System restarts an OS-Application it activates the configured OsRestartTask.<br />
|}<br />
<br />
== New Autosar API ==<br />
<br />
=== GetApplicationID ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS016 || OK<br />
| GetApplicationID<br />
|-<br />
| OS261 || OK TriCore [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| GetApplicationID() shall return the application identifier to which the executing Task/ISR/hook belongs.<br />
|-<br />
| OS262 || OK<br />
| If no OS-Application is running, GetApplicationID() shall return INVALID_OSAPPLICATION.<br />
|-<br />
| OS514 || No scalability Classes support<br />
| Availability of GetApplicationID(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== CheckObjectAccess ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS256 || OK TriCore<br />
| CheckObjectAccess<br />
|-<br />
| OS271 || OK TriCore<br />
| If the OS-Application <ApplID> in a call of CheckObjectAccess() has access to the queried object, CheckObjectAccess() shall return ACCESS.<br />
|-<br />
| OS272 || OK TriCore<br />
| If the OS-Application <ApplID> in a call of CheckObjectAccess() has no access to the queried object, CheckObjectAccess() shall return NO_ACCESS.<br />
|-<br />
| OS423 || OK TriCore<br />
| If in a call of CheckObjectAccess() the object to be examined is not a valid object OR <ApplID> is invalid OR <ObjectType> is invalid THEN CheckObjectAccess() shall return NO_ACCESS.<br />
|-<br />
| OS519 || No scalability Classes support<br />
| Availability of CheckObjectAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== CheckObjectOwnership ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS017 || OK TriCore<br />
| CheckObjectOwnership<br />
|-<br />
| OS273 || OK TriCore<br />
| If the object ObjectType specified in a call of CheckObjectOwnership() exists, CheckObjectOwnership() shall return the identifier of the OS-Application to which the object belongs.<br />
|-<br />
| OS274 || OK TriCore<br />
| If in a call of CheckObjectOwnership() the specified object ObjectType is invalid OR the argument of the type (the “...”) is invalid, CheckObjectOwnership() shall return INVALID_OSAPPLICATION.<br />
|-<br />
| OS520 || No scalability Classes support<br />
| Availability of CheckObjectOwnership():Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== TerminateApplication ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS258 || OK TriCore<br />
| TerminateApplication<br />
|-<br />
| OS493 || OK TriCore<br />
| If the input parameter <Application> in a call of TerminateApplication() is not valid TerminateApplication() shall return E_OS_ID.<br />
|-<br />
| OS459 || OK TriCore<br />
| If the <RestartOption> in a call of TerminateApplication() is invalid, TerminateApplication() shall return E_OS_VALUE.<br />
|-<br />
| OS494 || OK TriCore<br />
| If the input parameter <Application> in a call of TerminateApplication() is valid AND the caller belongs to a non-trusted OS-Application AND the caller does not belong to <Application> TerminateApplication() shall return E_OS_ACCESS.<br />
|-<br />
| OS507 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_TERMINATED TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS508 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_RESTARTING and the caller does not belong to the <Application> then TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS548 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_RESTARTING AND the caller does belong to the <Application> AND the <RestartOption> is equal RESTART then TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS287 || OK TriCore<br />
| If the parameters in a call of TerminateApplication() are valid and the above criteria are met TerminateApplication() shall terminate <Application> (i.e. to kill all tasks, disable the interrupt sources of those ISRs which belong to the OS-Application and free all other OS resources associated with the application) AND shall activate the configured OsRestartTask of <Application> if <RestartOption> equals RESTART. If the <Application> is restarted, its state is set to APPLICATION_RESTARTING otherwise to APPLICATION_TERMINATED. If the caller belongs to <Application> TerminateApplication() shall not return, otherwise it shall return E_OK.<br />
|-<br />
| OS535 || OK TriCore<br />
| Caveats of TerminateApplication():<br />
* If no applications are configured the implementation shall make sure that this service is not available.<br />
* Tasks and interrupts that are owned by a trusted application can terminate any OS-Application. Tasks and interrupts that are owned by a non-trusted application can only terminate their owning OS-Application.<br />
|-<br />
| OS536 || No scalability Classes support<br />
| Availability of TerminateApplication(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== AllowAccess ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS501 || OK TriCore<br />
| AllowAccess<br />
|-<br />
| OS497 || OK TriCore<br />
| If the state of the OS-Application of the caller of AllowAccess() is not APPLICATION_RESTARTING AllowAccess() shall return E_OS_STATE.<br />
|-<br />
| OS498 || OK TriCore<br />
| If the state of the OS-Application of the caller of AllowAccess() is APPLICATION_RESTARTING, AllowAccess() shall set the state to APPLICATION_ACCESSIBLE and allow other OS-Applications to access the configured objects of the callers OS-Application.<br />
|-<br />
| OS547 || No scalability Classes support<br />
| Availability of AllowAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== GetApplicationState ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS499 || OK TriCore<br />
| GetApplicationState<br />
|-<br />
| OS495 || OK TriCore<br />
| If the <Application> in a call of GetApplicationState() is not valid GetApplicationState() shall return E_OS_ID.<br />
|-<br />
| OS496 || OK TriCore<br />
| If the parameters in a call of GetApplicationState() are valid, GetApplicationState() shall return the state of OS-Application <Application> in <Value>.<br />
|-<br />
| OS537 || No scalability Classes support<br />
| Availability of GetApplicationState(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific StartupHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS539 || OK<br />
| Application specific StartupHook. The application specific StartupHook is always called after the standard StartupHook() (see OS236). If more than one OS-Application is configured which use startup hooks, the order of calls to the startup hooks of the different OS- Applications is not defined.<br />
|-<br />
| OS543 || No scalability Classes support<br />
| Availability of StartupHook_<App>(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific ErrorHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS540 || OK TriCore<br />
| Application specific ErrorHook. If the general ErrorHook() is configured, the general ErrorHook() is called before the application specific error hook is called (see OS246).<br />
|-<br />
| OS544 || OK TriCore<br />
| Availability of ErrorHook_<App>(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific ShutdownHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS541 || OK<br />
| Application specific ShutdownHook. If the general ShutdownHook() is configured, the general ShutdownHook() is called after all application specific shutdown hook(s) are called (see OS237). If more OS-Applications with an application specific shutdown hook exist the order of calls to these application specific shutdown hooks is not defined.<br />
|-<br />
| OS545 || No scalability Classes support<br />
| Availability of ShutdownHook_<App>(): Available in Scalability Classes 3 and 4. <br />
|}<br />
<br />
=== OS-Applications notes ===<br />
* [a] - Application-specific hook will be supported by TriCore full release.<br />
* [b] - Object protection will be introduced by TriCore full release, by now all objects are accessible by any OS-Application.<br />
* [c] - Termination of OS-Applications will be introduced by TriCore full release, is not supported yet.<br />
<br />
== Privileged mode ==<br />
<br />
Please see note [[#Privileged mode notes|<sup>[a]</sup>]].<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS058 || OK<br />
| If supported by hardware, the Operating System shall execute non-trusted OS-Applications in non-privileged mode.<br />
|-<br />
| OS096 || OK<br />
| As far as supported by hardware, the Operating System shall not allow non- trusted OS-Applications to access control registers managed by the Operating System.<br />
|-<br />
| OS245 || OK[[#Privileged mode notes|<sup>[b]</sup>]]<br />
| If an instruction exception occurs (e.g. division by zero) the operating system shall call the protection hook with E_OS_PROTECTION_EXCEPTION.<br />
|-<br />
| OS451 || OK<br />
| The Operating System shall allow to export services from trusted OS-Applications.<br />
|-<br />
| OS097 || OK<br />
| The Operating System shall provide a mechanism to call a trusted function from a (trusted or non-trusted) OS-Application.<br />
|-<br />
| OS100 || OK<br />
| If a called trusted function is not configured the Operating System shall call the ErrorHook with E_OS_SERVICEID.<br />
|-<br />
| OS226 || OK[[#Privileged mode notes|<sup>[b]</sup>]]<br />
| The Operating System shall execute an application-specific startup hook with the access rights of the associated OS-Application.<br />
|}<br />
<br />
=== CallTrustedFunction ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS097 || OK<br />
| CallTrustedFunction<br />
|-<br />
| OS265 || OK<br />
| If <FunctionIndex> is a defined function index, CallTrustedFunction() shall switch the processor into privileged mode AND shall call the function <FunctionIndex> out of a list of implementation specific trusted functions with disabled memory protection AND shall return E_OK after completion.<br />
|-<br />
| OS312 || OK<br />
| Caveats of CallTrustedFunction():<br />
* The called trusted function must conform to the following C prototype: void TRUSTED_<name_of_the_trusted_service>( TrustedFunctionIndexType,TrustedFunctionParameterRefType); (The arguments are the same as the arguments of CallTrustedFunction).<br />
* Normally, a user will not directly call this service, but it will be part of some standard interface, e.g. a standard I/O interface.<br />
* It is the duty of the called trusted function to check rights of passed parameters, especially if parameters are interpreted as out parameters.<br />
* It should be noted that the CallTrustedFunction() does not disable timing protection for the task which called the service. This may lead to timing faults (calls of the ProtectionHook()) even inside of a trusted OS-Application. It is therefore recommended to use CallTrustedFunction() only for stateless functions (e.g. functions which do not write or do not have internal states)<br />
|-<br />
| OS266 || OK [[#Privileged mode notes|<sup>[b]</sup>]]<br />
| When CallTrustedFunction() calls the function <FunctionIndex>, that function shall be executed with the same processor mode and memory protection boundaries as the OS-Application to which it belongs. It shall however retain the timing protection and service protection limitations of the calling Task or ISR, and the notion of "current application" shall remain that of the calling Task or Category 2 ISR.<br />
|-<br />
| OS364 || OK [[#Privileged mode notes|<sup>[b]</sup>]][[#Privileged mode notes|<sup>[c]</sup>]]<br />
| If CallTrustedFunction() calls the trusted function from a Category 2 ISR context, that function shall continue to run on the same interrupt priority and be allowed to call all system services defined for Category 2 ISR (see table in chapter 7.7.3.2).<br />
|-<br />
| OS365 || OK [[#Privileged mode notes|<sup>[b]</sup>]][[#Privileged mode notes|<sup>[c]</sup>]]<br />
| If CallTrustedFunction() calls the trusted function from a task context, that function shall continue to run on the same priority and be allowed to call all system services defined for tasks (see table in chapter 7.7.3.2).<br />
|}<br />
<br />
=== Privileged mode notes ===<br />
: [a] - In MPC5674F priviliged mode is enabled by the SC4 flag (This incomplete support of scalability classes have been removed in TriCore porting).<br />
: [b] - Supported only by TriCore implementation.<br />
: [c] - In MPC5674F a trusted function is executed in the security context of the calling function, although it runs in privileged mode.<br />
<br />
== Protection hook ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS099 || OK (See CheckTaskMemoryAccess() and CheckISRMemoryAccess())<br />
| The Operating System shall offer OS-Applications a service to check if a memory region is write/read/execute accessible from a Task/Category 2 OsIsr and also return information if the memory region is part of the stack space.<br />
|-<br />
| OS211 || OK TriCore<br />
| The Operating System shall execute the ProtectionHook() with the same permissions as the Operating System.<br />
|-<br />
| OS106 || OK TriCore<br />
| The Operating System shall perform one of the following reactions depending on the return value of the ProtectionHook():<br />
* Do nothing<br />
* Forcibly terminate the faulty Task/Category 2 OsIsr OR<br />
* Forcibly terminate the faulty OS-Application OR<br />
* Forcibly terminate the faulty OS-Application and restart the OS-Application. OR<br />
* Call ShutdownOS().<br />
|-<br />
| OS107 || OK TriCore<br />
| If no ProtectionHook() is configured and a protection error occurs, the Operating System shall call ShutdownOS().<br />
|-<br />
| OS475 || OK TriCore<br />
| If the reaction is to do nothing and the ProtectionHook() was not called with E_OS_PROTECTION_ARRIVAL then the Operating System shall call ShutdownOS()<br />
|-<br />
| OS243 || OK TriCore<br />
| If the reaction is to forcibly terminate the Task/Category 2 OsIsr and no Task or OsIsr can be associated with the error, the running OS-Application is forcibly terminated by the Operating System.<br />
|-<br />
| OS244 || OK TriCore<br />
| If the reaction is to forcibly terminate the faulty OS-Application and no OS- Application can be assigned, ShutdownOS()is called.<br />
|-<br />
| OS108 || OK TriCore<br />
| If the Operating System forcibly terminates a task, it terminates the task (no PostTaskHook() for the task will be called), releases all allocated OSEK resources and calls EnableAllInterrupts()/ / ResumeOSInterrupts() ResumeAllInterrupts() if the Task called DisableAllInterrupts() / / SuspendAllInterrupts() before without the SuspendOSInterrupts() EnableAllInterrupts()/ / corresponding ResumeOSInterrupts() ResumeAllInterrupts() call.<br />
|-<br />
| OS109 || OK TriCore<br />
| If the Operating System forcibly terminates an interrupt service routine, it clears the interrupt request, aborts the interrupt service routine (The interrupt source stays in the current state.) and releases all OSEK resources the interrupt service routine has allocated and calls EnableAllInterrupts() / ResumeOSInterrupts() / ResumeAllInterrupts() if the interrupt called DisableAllInterrupts() / / SuspendAllInterrupts() before without the SuspendOSInterrupts() corresponding EnableAllInterrupts()/ / ResumeOSInterrupts() ResumeAllInterrupts() call.<br />
|-<br />
| OS538 || OK TriCore<br />
| Protection Hook Depending on the return value the Operating System module will either:<br />
* forcibly terminate the Task/Category 2 ISR which causes the problem OR<br />
* forcibly terminate the OS-Application the Task/Category 2 ISR belong (optional with restart) OR<br />
* shutdown the system OR<br />
* do nothing (see 7.8.2)<br />
|-<br />
| OS308 || OK TriCore<br />
| If ProtectionHook() returns an invalid value, the Operating System module shall take the same action as if no protection hook is configured.<br />
|-<br />
| OS542 || No scalability Classes support<br />
| Availability of ProtectionHook(): Available in Scalability Classes 2, 3 and 4.<br />
|}<br />
<br />
= Other New Autosar APIs =<br />
<br />
=== GetISRID ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS511 || OK<br />
| GetISRID<br />
|-<br />
| OS263 || OK<br />
| If called from category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID() shall return the identifier of the currently executing ISR.<br />
|-<br />
| OS264 || partial<br />
| If its caller is not a category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID() shall return INVALID_ISR.<br />
|-<br />
| OS515 || OK (?)<br />
| Availability of GetISRID(): Available in all Scalability Classes.<br />
|}<br />
<br />
<br />
= Timing Protection =<br />
<br />
Actually implemented only for Tricore<br />
<br />
== General Requirement ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS028 || OK, but not Enforced by RT-Druid<br />
| In a non-trusted OS-Application, the Operating System module shall apply timing protection to every Task/Category 2 ISR of this non-trusted OS-Application<br />
|-<br />
| OS089 || OK<br />
| In a trusted OS-Application, the Operating System module shall provide the ability to apply timing protection to Tasks/Category 2 ISRs of this OS-Application.<br />
|-<br />
| OS397 || OK<br />
| If no OS-Application is configured, the Operating System module shall be able to apply timing protection to Tasks/Category 2 ISRs.<br />
|}<br />
<br />
== Timing Protection: Tasks ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS064 || OK<br />
| If a task’s OsTaskExecutionBudget is reached then the Operating System module shall call the ProtectionHook() with E_OS_PROTECTION_TIME.<br />
|-<br />
| OS473 || OK<br />
| OsTaskExecutionBudget on a transition to the SUSPENDED or WAITING states.<br />
|-<br />
| OS465 || OK<br />
| The Operating System module shall limit the inter-arrival time of tasks to one per OsTaskTimeFrame<br />
|-<br />
| OS469 || OK<br />
| The Operating System module shall start an OsTaskTimeFrame when a task is activated successfully<br />
|-<br />
| OS472 || OK<br />
| The Operating System module shall start an OsTaskTimeFrame when a task is released successfully<br />
|-<br />
| OS466 || OK<br />
| If an attempt is made to activate a task before the end of an OsTaskTimeFrame then the Operating System module shall not perform the activation AND shall call the ProtectionHook() with E_OS_PROTECTION_ARRIVAL<br />
|-<br />
| OS467 || OK<br />
| If an attempt is made to release a task before the end of an OsTaskTimeFrame then the Operating System module shall not perform the release AND shall call the ProtectionHook() with E_OS_PROTECTION_ARRIVAL AND the event shall be set<br />
|-<br />
|}<br />
<br />
<br />
== Timing Protection: ISR2 ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS210 || OK<br />
| If a Category 2 ISR’s OsIsrExecutionBudget is reached then the Operating System module shall call the ProtectionHook() with E_OS_PROTECTION_TIME<br />
|-<br />
| OS474 || OK<br />
| The Operating System module shall rest an ISR’s OsIsrExecutionBudget when the ISR returns control to the Operating terminates<br />
|-<br />
| OS470 || OK<br />
| The Operating System module shall limit the inter-arrival time of Category 2 ISRs to one per OsIsrTimeFrame<br />
|-<br />
| OS471 || OK<br />
| The Operating System module shall measure the start of an OsIsrTimeFrame from the point at which it recognises the interrupt (i.e. in the Operating System interrupt wrapper)<br />
|-<br />
| OS048 || OK<br />
| If Category 2 interrupt occurs before the end of the OsIsrTimeFrame then the Operating System module shall not execute the user provided ISR AND shall call the ProtectionHook() with E_OS_PROTECTION_ARRIVAL<br />
|}<br />
<br />
== Timing Protection: Resource Locking and Interrupt Disabling ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS033 || OK<br />
| If a Task/Category 2 ISR holds an OSEK Resource and exceeds the OsTaskResourceLockBudget or OsIsrResourceLockBudget, the Operating System module shall call the ProtectionHook() with E_OS_PROTECTION_LOCKED<br />
|}<br />
<br />
= Multi-Core =<br />
<br />
== Basic Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS567 || OK (We have some doubts relates to this, but it should be OK)<br />
| The generated part of the OS is derived from a single configuration that contains the relevant information for all cores. This implies, that IDs (e.g. TASKID, RESOURCEID, …) are unique across cores. Every ID shall refer exactly to one entity independent from the core on which the entity is accessed. This applies also to objects that cannot be shared between cores. (BSW4080008)<br />
|-<br />
| OS568 || OK<br />
|Implementations shall be able to independently execute a TASK or an ISR on each started AUTOSAR OS core in parallel. (BSW4080001)<br />
|-<br />
| OS569 || OK<br />
|The scheduling strategy as defined in AUTOSAR OS shall apply for each individual core in a Multi-Core system, for the TASKs and ISR assigned to the core. (BSW4080001, BSW4080013)<br />
|-<br />
| OS570 || OK<br />
| All TASKs that are assigned to the same OS-Application shall execute on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS571 || OK<br />
| All ISRs that are assigned to the same OS-Application shall execute on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS572 || N.A. in Supported Architectures (PPC TriCore)<br />
| ISR balancing (if supported by the HW) shall be switched off at boot time by the OS. (BSW4080005, BSW4080006)<br />
|-<br />
| OS764 || No scalability classes support (OS-Applications are enabled when configurated).<br />
| The OS module shall support OS-Applications in case of Multi-Core also for SC1 and SC2.<br />
|-<br />
| OS763 || No scalability classes support (But we don't understend this requirement).<br />
| In an SC1 system standard mode shall be possible.<br />
|-<br />
| OS573 ||<br />
| The binding of OS-Applications to cores shall be configured within the OS-Application container. A new configuration item: OsApplicationCoreAssignment{CORE} within the OS-Application container shall be used to define the core to which the OS-Application is bound. The OS generator will map the configuration parameter “CORE” to a certain core, so that all OS-Applications with the same configuration parameter reside on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS623 || OK<br />
| The OS API function CallTrustedFunction shall return E_OS_ACCESS in extended status if the target trusted function is part of an OS-Application on another core. (BSW4080013)<br />
|-<br />
|}<br />
<br />
== Multi-Core start-up Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS574 || OK<br />
| The master core shall be able to activate cores. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS575 || OK<br />
| Any slave core shall be able to activate cores. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS576 || OK<br />
| It shall be allowed to use only a subset of the cores available on a μC for the AUTOSAR system. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS577 || OK (TriCore e PPC e200zx are naturally in Master-Slave configuration)<br />
| The cores shall boot in master-slave mode. If this is not supported by the hardware, it shall be that the cores boot in parallel and emulate the behavior of a master-slave system.. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS578 || N.A.<br />
| In case of an emulation a slave core (CoreS), which is controlled by the AUTOSAR OS (AUTOSAR core), shall not enter the main function before another<br />
core has activated the slave core by means of StartCore(CoreS). (BSW4080006)<br />
|-<br />
| OS579 || OK<br />
| All cores that belong to the AUTOSAR system shall be synchronized within the StartOS function before the scheduling is started and after the global<br />
StartupHook is called.. (BSW4080001, BSW4080006)<br />
|-<br />
| OS580 || OK<br />
| All cores that belong to the AUTOSAR system shall be synchronized within the StartOS function before the scheduling is started and after the global<br />
StartupHook is called.. (BSW4080006)<br />
|-<br />
| OS581 || OK TriCore<br />
| The global StartupHook shall be called on all cores immediately after the first synchronisation point (BSW4080006)<br />
|-<br />
| OS582 || OK TriCore<br />
| The OS-Application-specific StartupHooks shall be called after the global StartupHook but only on the cores to which the OS-Application is bound (BSW4080006, BSW4080008)<br />
|-<br />
| || OK TriCore<br />
| The AUTOSAR OS API provides a StartCore function to start the cores under its control. The StartCore function takes a scalar value parameter of type CoreIDType, specifying the core that shall be started. StartCore can be called more than once on the master core and also on slave cores. Each core can only be started once, however The StartOS function shall be called on all cores that have been activated by StartCore. It is not allowed to call StartCore from a core that has already called StartOS. Cores that belong to the AUTOSAR system shall be started by the designated AUTOSAR OS API service StartCore.<br />
|-<br />
| OS583 || OK TriCore<br />
| The number of cores that can be controlled by the AUTOSAR OS shall be configured offline. A new configuration item (OsNumberOfCores) within the “OsOS” container is used to specify the maximum number of cores that are controlled by the AUTOSAR OS. If no value for (OsNumberOfCores) has been specified the number of cores shall be one. (BSW4080001, BSW4080011) <br />
|-<br />
| OS584 || OK TriCore<br />
| The AUTOSAR OS shall provide a function called StartNonAutosarCore that can be used to start cores, which are not controlled by the AUTOSAR OS. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS585 || OK TriCore<br />
| It shall be possible to activate cores that are not controlled by the AUTOSAR OS before and after calling StartOS. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS606 || OK TriCore<br />
| The AUTOSAR specification does not support the activation of AUTOSAR cores after calling StartOS on that core. If StartCore is called after StartOS it shall return with E_OS_ACCESS in extended status. (BSW4080001)<br />
|-<br />
| OS607 || OK TriCore<br />
| StartOS shall start the OS on the core on which it is called. (BSW4080006, BSW4080013)<br />
|-<br />
| OS608 || OK TriCore<br />
| If more than one core calls StartOS with an AppMode other than “DONOTCARE”, the AppModes shall be the same. StartOS shall check this at the first synchronisation point. In case of violation, StartOS shall not start the scheduling, shall not call any StartupHooks, and shall enter an endless loop on every core. (BSW4080006)<br />
|-<br />
| OS609 || OK TriCore<br />
| If StartOS is called with the AppMode “DONOTCARE” the application mode of the other core(s) (differing from “DONOTCARE”) shall be used. (BSW4080006)<br />
|-<br />
| OS610 || OK TriCore<br />
| At least one core shall define an AppMode other than “DONOTCARE”. (BSW4080006)<br />
|-<br />
| OS611 || OK TriCore<br />
| If the IOC is configured, StartOS shall initialize the data structures of the IOC. (BSW4080020)<br />
|-<br />
| OS668 || OK<br />
| The AUTOSAR Operating System shall automatically activate all auto-start TASKs configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
| OS669 || OK<br />
| The AUTOSAR Operating System shall automatically activate all auto-start ALARMs configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
| OS670 || Not Schedule tables supported yet<br />
| The AUTOSAR Operating System shall automatically activate all auto-start schedule tables configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
|}<br />
<br />
== Multicore Shutdown Requirements ==<br />
<br />
AUTOSAR supports two shutdown concepts, the synchronized shutdown and the individual shutdown concept. While the synchronized shutdown is triggered by the new API function '''ShutdownAllCores()''', the individual shutdown is invoked by the existing API function '''ShutdownOS()'''.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS586 || OK TriCore<br />
| During the shutdown, the OS-Application specific ShutdownHook shall be called on the core on which the corresponding OS-Application is bound. (BSW4080007)<br />
|- <br />
| OS587 || OK TriCore (if ShutdownAllCores has been called)<br />
| Before calling the global ShutdownHook, all cores shall be synchronized. (BSW4080007)<br />
|- <br />
| OS588 || OK<br />
| The global ShutdownHook shall be called on all cores. (BSW4080007)<br />
|-<br />
| OS762 || OK TriCore (fullfilled by ProtectionHook implementation)<br />
| In cases where the OS detects a fatal internal error all cores shall be shutdown.<br />
|-<br />
| OS616 || OK<br />
| ShutdownOS shall be callable from each core running an AUTOSAR OS. (BSW4080001, BSW4080007)<br />
|-<br />
| OS617 || OK<br />
| ShutdownOS shall shutdown the core on which it was called. (BSW4080007)<br />
|-<br />
| OS618 || OK<br />
| The OS shall not start TASKs of an OS-Application once the shutdown procedure has been entered on a particular core. (BSW4080013)<br />
|-<br />
| OS619 || OK<br />
| The AUTOSAR OS function ShutdownOS shall be callable in parallel on multiple cores. (BSW4080013)<br />
|-<br />
| OS620 || OK TriCore<br />
| ShutdownOS shall release all spinlocks which are occupied by the calling core. (BSW4080021)<br />
|-<br />
| OS621 || OK TriCore<br />
| ShutdownAllCores shall be callable from each core running an AUTOSAR OS. (BSW4080007)<br />
|-<br />
|}<br />
<br />
== OS Other Services Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS589 || OK TriCore<br />
| All functions that are not allowed to operate cross core shall return E_OS_CORE in extended status if called with parameters that require a cross core operation. (BSW4080013)<br />
|-<br />
| OS590 || OK<br />
| The OS service “DisableAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS591 || OK<br />
| The OS service “EnableAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS592 || OK<br />
| The OS service “SuspendAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS593 || OK<br />
| The OS service “ResumeAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS594 || OK<br />
| The OS service “SuspendOSInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS595 || OK<br />
| The OS service “ResumeOSInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS596 || OK<br />
| It shall be possible to activate a TASK that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080001, BSW4080015)<br />
|-<br />
| OS598 || OK TriCore (RPC Dispactcher)<br />
| The call of ActivateTask across cores shall behave synchronously, i.e. a call returns after the task has been activated or an error has been detected. It shall not be possible to continue execution on the calling core before ActivateTask is accomplished on the remote core. (BSW4080015)<br />
|-<br />
| OS599 || OK TriCore (RPC Dispactcher)<br />
| In case of an error when calling ActivateTask across cores, the error handler shall be called on the core on which ActivateTask was originally called. (BSW4080015)<br />
|-<br />
| OS600 || OK<br />
| It shall be possible to chain a TASK that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080001, BSW4080015)<br />
|-<br />
| OS602 || OK<br />
| It shall be possible to set an EVENT that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080016)<br />
|-<br />
| OS604 || OK TriCore (RPC Dispactcher)<br />
| The call of SetEvent across cores shall behave synchronously, i.e. a call returns after the Event has been set or an error has been detected. It shall not be possible to continue execution on the calling core before SetEvent is accomplished on the remote core. (BSW4080016)<br />
|-<br />
| OS605 || OK TriCore (RPC Dispactcher [[#MultiCore notes|<sup>[a]</sup>]])<br />
| In case of an error when calling SetEvent across cores, the error handler shall be called on the core on which SetEvent was originally called. (BSW4080016)<br />
|-<br />
| OS612 || OK TriCore<br />
| In extended status TerminateTask / ChainTask shall return with an error (E_OS_SPINLOCK), which can be evaluated in the application. (BSW4080021)<br />
|-<br />
| OS613 || OK TriCore<br />
| Spinlocks occupied by TASKS that are terminated in response to a protection hook shall be automatically released. This applies also to the case in which an OS-Application is terminated. (BSW4080021)<br />
|-<br />
| OS614 || OK TriCore<br />
| TerminateApplication shall check if any of the TASKs in the OS-Application have occupied a spinlock. If so, the spinlocks shall be released.(BSW4080021)<br />
|-<br />
| OS615 ||<br />
| If TerminateApplication(A) is called in parallel from different cores, the OsApplication “A” is terminated by the first call, any subsequent calls will return with 'E_OK' in standard and extended status without doing anything, until the termination is completed.<br />
|-<br />
| OS622 || OK<br />
| The AUTOSAR Operating System WaitEvent API service shall check if it has been called while the calling TASK has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the TASK shall not enter the wait state. (BSW4080021)<br />
|-<br />
| OS624 || OK<br />
| The AUTOSAR Operating System Schedule API service shall check if it has been called while the calling TASK has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the scheduler shall not be called. (BSW4080021)<br />
|-<br />
| OS629 || OK<br />
| A COUNTER belonging to an OS-Application shall be incremented by the core on which the OS-Application resides. The COUNTER shall not be incremented by other cores. (BSW4080013)<br />
|-<br />
| OS630 || OK<br />
| It shall not be allowed to drive a schedule table from a COUNTER, which is assigned to a different core. (BSW4080013)<br />
|-<br />
| OS631 || OK<br />
| It shall not be allowed to drive an ALARM from a COUNTER, which is assigned to a different core. (BSW4080013)<br />
|-<br />
| OS632 || OK<br />
| If an ALARM expires, it shall be allowed to activate a TASK on a different core. (BSW4080018)<br />
|-<br />
| OS633 || OK<br />
| If an ALARM expires, it shall be allowed to set an EVENT on a different core. (BSW4080018)<br />
|-<br />
| OS634 || OK<br />
| The AUTOSAR Operating System shall process an ALARM on the core on which its corresponding OS-Application resides. (BSW4080018)<br />
|-<br />
| OS635 || OK<br />
| ALARM callbacks shall be executed on the core to which the ALARM is bound. This is only applicable to SC1 systems, because otherwise Alarm Callback<br />
are not allowed (OS242). (BSW4080013)<br />
|-<br />
| OS636 || OK<br />
| SetRelAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|-<br />
| OS637 || OK<br />
| SetAbsAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS638 || OK<br />
| CancelAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS639 || OK<br />
| GetAlarmBase shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS640 || OK<br />
| GetAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
|}<br />
<br />
== MultiCore notes ==<br />
: [a] - [[Infineon_Aurix#Multicore_Autosar_OS_Support|New RPC MultiCore dispatcher]]<br />
<br />
== Other AUTOSAR Multicore API ==<br />
<br />
=== GetCoreID ===<br />
<br />
Every HW assigns a unique physical Id to a core. The physical core Id is the only way to distinguish between cores. <br />
The physical core Ids of a μC are not necessarily consecutive and do not necessarily start with zero.<br />
The SW requires a mechanism to identify a core, e.g. to use core specific variables. Because the physical core Id usually can not be used as a direct array index for core specific variables, a logical CoreID is necessary to map physical core Ids to array indexes. In the SW it is not necessary to know the physical core Id, the logical CoreID is sufficient.<br />
The mapping of OSApplications and other SW objects to cores is specified in the configuration files. All such mappings shall be HW independent and therefore shall not be based on the physical core Id but on the logical CoreID. The function GetCoreID internally maps the physical core Id to the logical CoreID. The mapping is implementation specific. GetCoreID can be either a C function or a macro.<br />
<br />
'''N.B''' In Erika with code replication the core ID is not a real issue.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS625 || OK TriCore<br />
| The AUTOSAR Operating System API function GetCoreID shall be callable before StartOS. (BSW4080006)<br />
|-<br />
| OS626 || OK TriCore<br />
| An implementation shall offer a function GetNumberOfActivatedCores that returns the number of cores running the AUTOSAR OS. (BSW4080001)<br />
|-<br />
| OS627 || OK TriCore<br />
| An implementation shall define a set of constants OS_CORE_ID_<No> of the type CoreIDType with <No> a value from 0 to “OsNumberOfCores -1. (BSW4080001)<br />
|-<br />
| OS628 || OK TriCore<br />
| An implementation shall offer a constant OS_CORE_ID_MASTER of the type CoreIDType that refers to the master core. (BSW4080001)<br />
|}<br />
<br />
== Spinlocks ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS648 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a spinlock mechanism that works across cores. (BSW4080018, BSW4080021)<br />
|-<br />
| OS649 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a GetSpinlock function which occupies a spinlock. If the spinlock is already occupied, GetSpinlock shall<br />
keep on trying to occupy the spinlock until it succeeds. (BSW4080018, BSW4080021)<br />
|-<br />
| OS650 || OK TriCore<br />
| GetSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS651 || OK TriCore<br />
| GetSpinlock shall be callable from ISR2 level. The behavior of GetSpinlock is undefined if called from a category 1 ISR. (BSW4080021)<br />
|-<br />
| OS652 || OK TriCore (With Trivial spinlocks)<br />
| The AUTOSAR Operating System shall provide a TryToGetSpinlock function which occupies a spinlock. If the spinlock is already occupied by a TASK,<br />
TryToGetSpinlock shall return. (BSW4080018, BSW4080021)<br />
|-<br />
| OS653 || OK TriCore<br />
| TryToGetSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS654 || OK TriCore<br />
| TryToGetSpinlock shall be callable from ISR2 level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS655 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a ReleaseSpinlock function which releases an occupied spinlock. If the spinlock is not occupied an error<br />
shall be returned. (BSW4080018, BSW4080021)<br />
|-<br />
| OS656 || OK TriCore<br />
| ReleaseSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS657 || OK TriCore<br />
| ReleaseSpinlock shall be callable from ISR2 level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS658 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if a TASK tries to occupy a spinlock that is assigned to a TASK/ISR2 on the same core (including<br />
itself). (BSW4080018, BSW4080021)<br />
|-<br />
| OS659 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if an ISR2 tries to occupy a spinlock that is assigned to a TASK/ISR2 on the same core.<br />
(BSW4080018, BSW4080021)<br />
|-<br />
| OS660 || OK TriCore<br />
| A unique order in which multiple spinlocks can be occupied by a TASK/ISR2 should be configurable in the AUTOSAR Operating System. This might<br />
be realized by the configuration item (OsSpinlockSuccessor{NEXT_SPINLOCK}) where “NEXT_SPINLOCK” refers to the consecutive spinlock. (See chapter 10.2.5) (BSW4080018, BSW4080021)<br />
|-<br />
| OS661 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if a TASK/ISR2 that currently holds a spinlock tries to seize another spinlock that has not been<br />
configured as a direct or indirect successor of the latest acquired spinlock (by means of the OsSpinlockSuccessor configuration parameter) or if no successor is configured. (BSW4080018, BSW4080021)<br />
|-<br />
|}<br />
<br />
= Inter-OS-Application Communicator (IOC) Requirements =<br />
<br />
IOC stands for Inter OS-Application Communicator. The "IOC" is responsible for the communication between OS-Applications and in<br />
particular for the communication crossing core or memory protection boundaries. It's internal functionality is closely connected to the Operating System.<br />
<br />
Memory protection boundaries are a characteristic of OS-Applications and special communication mechanisms are needed to cross them.<br />
Multi-Core systems may also need additional measures to make communication between cores safe.<br />
<br />
The IOC provides communication services between OS-Applications and in particular over core boundaries in Multi-Core systems. Because the cross-core communication is always an inter-OS-Application communication, the two mechanisms are combined. An inter OS-Application communication may not necessarily require a cross core communication, however.<br />
<br />
In systems with only one core, the IOC can be omitted completely, if just one OS-Application is available, or if no OS-Application uses memory protection mechanisms.<br />
<br />
'''N.B''' Since a lot of Code of IOC is configurated and generated starting from RTE configuration, it doesn't make sense generate a whole IOC system without a complete RTE generator. But '''we choiced the cross-boundaries communication mechanism''' that is the heart of IOC. The same mechanism is employed to implement OS Services remote invocation.<br />
<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS671 ||<br />
| The IOC implementation shall be part of the Operating System The IOC is a third type of communication, in addition to:<br />
* Intra OS-Application communication: Always handled within the RTE<br />
* Inter ECU communication: already available via well defined interfaces to the communication stack (COM).<br />
(BSW4080020)<br />
|-<br />
|}</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=ERIKA_%26_Autosar_OS_RequirementsERIKA & Autosar OS Requirements2016-09-30T14:07:35Z<p>Eguidieri: /* Timing Protection */</p>
<hr />
<div>= Introduction =<br />
Erika Enterprise is the first open-source Free RTOS that has been certified OSEK/VDX compliant and it's under current developtment to fulfil Autosar 4 OS Requirements too. In the following table are logged the AUTOSAR requirements already implemneted in ERIKA.<br />
<br />
* All the requirement tagged as OK are implemented in all supported Architectures.<br />
* All the requirements related to '''memory protection''' are available only for those MCU that have memory protection implmentented: currently only support for Freescale MPC5674F has been released.<br />
* All the requirements tagged as TriCore are implemented but will be realesed when the full support for TriCore AURIX will be released.<br />
<br />
Scalability Classes are not implemented yet, but each feature/API is activated only if required by the configuration.<br />
<br />
= Tasks =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS052 || OK<br />
| If a task returns from its entry function without making a TerminateTask() or ChainTask() call, the Operating System shall terminate the task (and call the PostTaskHook() if configured).<br />
|-<br />
| OS069 || OK<br />
| If a task returns from its entry function without making a TerminateTask() or ChainTask() call AND the error hook is configured, the Operating System shall call the ErrorHook() (this is done regardless of whether the task causes other errors, e.g. E_OS_RESOURCE) with status E_OS_MISSINGEND before the task leaves the RUNNING state.<br />
|-<br />
| OS070 || OK<br />
| If a task returns from the entry function without making a TerminateTask() or ChainTask() call and still holds OSEK Resources, the Operating System shall release them.<br />
|-<br />
| OS239 || OK<br />
| If a task returns from the entry function without making a TerminateTask() or ChainTask() call and interrupts are still disabled, the Operating System shall enable them.<br />
|-<br />
| OS071 || OK<br />
| If the PostTaskHook() is configured, the Operating System shall not call the hook if ShutdownOS() is called.<br />
|}<br />
<br />
= ISR2s =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS368 || OK<br />
| If a Category 2 OsIsr calls DisableAllInterupts() SuspendAllInterrupts() / SuspendOSInterrupts() and ends (returns) without calling the corresponding EnableAllInterrupts() / ResumeAllInterrupts() / ResumeOSInterrupts(), the Operating System shall perform the missing service and shall call the ErrorHook() (if configured) with the status E_OS_DISABLEDINT.<br />
|-<br />
| OS369 || OK<br />
| If a Category 2 OsIsr calls GetResource() and ends (returns) without calling the corresponding ReleaseResource(), the Operating System shall perform the ReleaseResource() call and shall call the ErrorHook() (if configured) with the status E_OS_RESOURCE.<br />
|}<br />
<br />
= Hooks =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS236 || OK TriCore<br />
| If both a system-specific and one (or more) application specific startup hook(s) are configured, the Operating System shall call the system-specific startup hook before the application-specific startup hook(s).<br />
|-<br />
| OS112 || OK TriCore<br />
| If an application-specific shutdown hook is configured for an OS-Application <App>, the Operating System shall call ShutdownHook_<App> on shutdown of the OS.<br />
|-<br />
| OS225 || OK TriCore<br />
| The Operating System shall execute an application-specific shutdown hook with the access rights of the associated OS-Application.<br />
|-<br />
| OS237 || OK TriCore<br />
| If both a system-specific and one (or more) application specific shutdown hook(s) are configured, the Operating System shall call the system-specific shutdown hook after the application-specific shutdown hook(s).<br />
|-<br />
| OS246 || OK TriCore<br />
| When an error occurs AND an application-specific error hook is configured for the faulty OS-Application <App>, the Operating System shall call that application- specific error hook ErrorHook_<App> after the system specific error hook is called (if configured).<br />
|-<br />
| OS085 || OK TriCore<br />
| The Operating System shall execute an application-specific error hook with the access rights of the associated OS-Application.<br />
|}<br />
<br />
= Timers and Counters =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS301 || OK<br />
| The Operating System shall provide the ability to increment a software counter as an alternative action on alarm expiry.<br />
|-<br />
| OS399 || OK<br />
| The OS shall provide an API call to increment a software counter.<br />
|-<br />
| OS374 || OK<br />
| The Operating System shall handle all the initialization and configuration of timers used directly by the OS and not handled by the GPT driver.<br />
|-<br />
| OS383 || OK (partials)<br />
| The Operating System shall provide a service to read the current count value of a counter (returning either the hardware timer ticks if counter is driven by hardware or the software ticks when user drives counter).<br />
|-<br />
| OS392 || OK<br />
| The Operating System shall provide a service to get the number of ticks between the current tick value and a previously read tick value.<br />
|-<br />
| OS384 ||<br />
| The Operating System shall adjust the read out values of hardware timers (which drive counters) in such that the lowest value is zero and consecutive reads return an increasing count value until the timer wraps at its modulus.<br />
|}<br />
<br />
== Autosar New API for Timers and Counters ==<br />
<br />
=== IncrementCounter ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS399 || OK<br />
| IncrementCounter<br />
|-<br />
| OS285 || OK<br />
| If the input parameter <CounterID> in a call of IncrementCounter() is not valid OR the counter is a hardware counter, IncrementCounter() shall return E_OS_ID.<br />
|-<br />
| OS286 || OK<br />
| If the input parameter of IncrementCounter() is valid, IncrementCounter() shall increment the counter <CounterID> by one (if any alarm connected to this counter expires, the given action, e.g. task activation, is done) and shall return E_OK.<br />
|-<br />
| OS321 || OK<br />
| If in a call of IncrementCounter() an error happens during the execution of an alarm action, e.g. E_OS_LIMIT caused by a task activation, IncrementCounter() shall call the error hook(s), but the IncrementCounter() service itself shall return E_OK.<br />
|-<br />
| OS529 || OK<br />
| Caveats of IncrementCounter(): If called from a task, rescheduling may take place.<br />
|-<br />
| OS530 || OK<br />
| Availability of IncrementCounter(): Available in all Scalability Classes.<br />
|}<br />
<br />
=== GetCounterValue ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS383 || OK<br />
| GetCounterValue<br />
|-<br />
| OS376 || OK<br />
| If the input parameter <CounterID> in a call of GetCounterValue() is not valid, GetCounterValue() shall return E_OS_ID.<br />
|-<br />
| OS377 || OK<br />
| If the input parameter <CounterID> in a call of GetCounterValue() is valid, GetCounterValue() shall return the current tick value of the counter via <Value> and return E_OK.<br />
|-<br />
| OS531 || OK (partials)<br />
| Caveats of GetCounterValue(): Note that for counters of OsCounterType = HARDWARE the real timer value (the – possibly adjusted – hardware value, see OS384) is returned, whereas for counters of OsCounterType = SOFTWARE the current “software” tick value is returned.<br />
|-<br />
| OS532 || OK<br />
| Availability of GetCounterValue(): Available in all Scalability Classes.<br />
|}<br />
<br />
=== GetElapsedValue ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS392 || OK<br />
| GetElapsedValue<br />
|-<br />
| OS381 || OK<br />
| If the input parameter <CounterID> in a call of GetElapsedValue() is not valid GetElapsedValue() shall return E_OS_ID.<br />
|-<br />
| OS391 || OK<br />
| If the <Value> in a call of GetElapsedValue() is larger than the max allowed value of the <CounterID>, GetElapsedValue() shall return E_OS_VALUE.<br />
|-<br />
| OS382 || OK<br />
| If the input parameters in a call of GetElapsedValue() are valid, GetElapsedValue() shall return the number of elapsed ticks since the given <Value> value via <ElapsedValue> and shall return E_OK.<br />
|-<br />
| OS460 || OK<br />
| GetElapsedValue() shall return the current tick value of the counter in the <Value> parameter.<br />
|-<br />
| OS533 || OK<br />
| Caveats of GetCounterValue():If the timer already passed the <Value> value a second (or multiple) time, the result returned is wrong. The reason is that the service can not detect such a relative overflow.<br />
|-<br />
| OS534 || OK<br />
| Availability of GetCounterValue(): Available in all Scalability Classes.<br />
|}<br />
<br />
== OSEK Requirements Extensions ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS304 || OK<br />
| If in a call to SetRelAlarm() the parameter “increment” is set to zero, the service shall return E_OS_VALUE in standard and extended status .<br />
|-<br />
| OS424 || OK<br />
| The first call to StartOS() (for starting the Operating System) shall not return.<br />
|-<br />
| OS425 || OK<br />
| If ShutdownOS() is called and ShutdownHook() returns then the operating system shall disable all interrupts and enter an endless loop.<br />
|-<br />
| OS299 || OK<br />
|The Operating System shall provide the services DisableAllInterrupts(), EnableAllInterrupts(), SuspendAllInterrupts(), ResumeAllInterrupts() prior to calling StartOS() and after calling ShutdownOS(). (It is assumed that the static variables of these functions are initialized).<br />
|-<br />
| OS051 || OK TriCore<br />
| If an invalid address (address is not writable by this OS-Application) is passed as an out-parameter to an OS service, the Operating System shall return the status code E_OS_ILLEGAL_ADDRESS.<br />
|-<br />
| OS088 || OK TriCore<br />
| If an OS-Application makes a service call from the wrong context AND is currently not inside a Category 1 OsIsr the Operating System shall not perform the requested action (the service call shall have no effect), and return E_OS_CALLEVEL or the “invalid value” of the service.<br />
|-<br />
| OS092 || OK<br />
| If EnableAllInterrupts() ResumeAllInterrupts() / ResumeOSInterrupts() are called and no corresponding DisableAllInterupts() / SuspendAllInterrupts() / SuspendOSInterrupts() was done before, the Operating System shall not perform this OS service.<br />
|-<br />
| OS093 || OK<br />
| If interrupts are disabled/suspended by a Task/OsIsr and the Task/OsIsr calls any OS service (excluding the interrupt services) then the Operating System shall ignore the service AND shall return E_OS_DISABLEDINT if the service returns a StatusType value.<br />
|-<br />
| OS054 || OK TriCore<br />
| The Operating System shall ignore calls to ShutdownOS() from non-trusted OS-Applications.<br />
|-<br />
| OS056 || OK TriCore<br />
| If an OS-object identifier is the parameter of a system service, and no sufficient access rights have been assigned at configuration time (Parameter Os[...]AccessingApplication) to the calling Task/Category 2 OsIsr, the system service shall return E_OS_ACCESS.<br />
|-<br />
| OS449 || OK<br />
| CheckTaskMemoryAccess and CheckIsrMemoryAccess check the memory access. Memory access checking is possible for all OS-Applications and from all OS- Applications and does not need granted rights (This is an exception to OS056).<br />
|-<br />
| OS450 || OK<br />
| CheckObjectAccess checks the access rights for OS objects. Checking object access is possible for all OS-Applications and from all OS-Applications and does not need granted rights (This is an exception to OS056).<br />
|-<br />
| OS439 || OK<br />
| The Operating System shall offer the OSEK error macros (OSError...()) to all configured error hooks AND there shall be two (like in OIL) global configuration parameter to switch these macros on or off.<br />
|-<br />
| OS367 || OK<br />
| Operating System services which do not return a StatusType shall not raise the error hook(s).<br />
|-<br />
| OS566 || OK<br />
| The Operating System API shall check in extended mode all pointer argument for NULL pointer and return OS_E_PARAMETER if such argument is NULL.<br />
|}<br />
<br />
= Minor Further Requirements =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS398 || OK<br />
| The OS shall not define the symbol LOCALMESSAGESONLY<br />
|-<br />
| OS242 || No scalability Classes support (But this will be prevented in Any AS configuration)<br />
| The Operating System shall only allow Alarm Callbacks in Scalability Class 1.<br />
|}<br />
<br />
= Memory protection =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS198 || Partial [[#Memory protection notes|<sup>[a]</sup>]]<br />
| The Operating System shall prevent write access to its own data sections and its own stack from non-trusted OS-Applications.<br />
|-<br />
| OS026 || OK (configurable)<br />
| The Operating System may prevent read access to an OS-Application’s data section attempted by other non-trusted OS-Applications.<br />
|-<br />
| OS086 || OK<br />
| The Operating System shall permit an OS-Application read and write access to that OS-Application’s own private data sections.<br />
|-<br />
| OS207 || OK<br />
| The Operating System shall prevent write access to the OS-Application’s private data sections from other non-trusted OS-Applications.<br />
|-<br />
| OS196 || OK<br />
| The Operating System shall permit a Task/Category 2 OsIsr read and write access to that Task’s/Category 2 OsIsr’s own private stack.<br />
|-<br />
| OS208 || OK (not prevented)<br />
| The Operating System may prevent write access to the private stack of Tasks/Category 2 OsIsrs of a non-trusted application from all other Tasks/OsIsrs in the same OS-Application.<br />
|-<br />
| OS355 || OK<br />
| The Operating System shall prevent write access to all private stacks of Tasks/Category 2 OsIsrs of an OS-Application from other non-trusted OS- Applications.<br />
|-<br />
| OS087 || OK<br />
| The Operating System shall permit a Task/Category 2 OsIsr read and write access to that Task’s/Category 2 OsIsr’s own private data sections.<br />
|-<br />
| OS195 || OK (not prevented)<br />
| The Operating System may prevent write access to the private data sections of a Task/Category 2 OsIsr of a non-trusted application from all other Tasks/OsIsrs in the same OS-Application.<br />
|-<br />
| OS356 || OK<br />
| The Operating System shall prevent write access to all private data sections of a Task/Category 2 OsIsr of an OS-Application from other non-trusted OS- Applications.<br />
|-<br />
| OS027 || OK (not protected)<br />
| The Operating System may provide an OS-Application the ability to protect its code sections against executing by non-trusted OS-Applications.<br />
|-<br />
| OS081 || OK (all code is shared)<br />
| The Operating System shall provide the ability to provide shared library code in sections that are executable by all OS-Applications.<br />
|-<br />
| OS209 || OK<br />
| The Operating System shall permit trusted OS-Applications read and write access to peripherals.<br />
|-<br />
| OS083 || Not done [[#Memory protection notes|<sup>[b]</sup>]]<br />
| The Operating System shall allow non-trusted OS-Applications to write to their assigned peripherals only (incl. reads that have the side effect of writing to a memory location).<br />
|-<br />
| OS044 || OK TriCore [[#Memory protection notes|<sup>[c]</sup>]]<br />
| If a memory access violation is detected, the Operating System shall call the Protection Hook with status code E_OS_PROTECTION_MEMORY.<br />
|}<br />
<br />
No timing and memory protection for alarm callbacks.<br />
<br />
== CheckISRMemoryAccess ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS512 || OK<br />
| CheckISRMemoryAccess<br />
|-<br />
| OS267 || OK<br />
| If the ISR reference <ISRID> in a call of CheckISRMemoryAccess() is valid, CheckISRMemoryAccess() shall return the access rights of the ISR on the specified memory area.<br />
|-<br />
| OS313 || OK [[#Memory protection notes|<sup>[d]</sup>]]<br />
| If an access right (e.g. “read”) is not valid for the whole memory area specified in a call of CheckISRMemoryAccess(), CheckISRMemoryAccess() shall yield no access regarding this right.<br />
|-<br />
| OS268 || OK<br />
| If the ISR reference <ISRID> is not valid, CheckISRMemoryAccess() shall yield no access rights.<br />
|-<br />
| OS517 || No scalability Classes support<br />
| Availability of CheckISRMemoryAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
== CheckTaskMemoryAccess ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS513 || OK<br />
| CheckTaskMemoryAccess<br />
|-<br />
| OS269 || OK<br />
| If the Task reference <TaskID> in a call of CheckTaskMemoryAccess() is valid, CheckTaskMemoryAccess() shall return the access rights of the task on the specified memory area.<br />
|-<br />
| OS314 || OK [[#Memory protection notes|<sup>[d]</sup>]]<br />
| If an access right (e.g. “read”) is not valid for the whole memory area specified in a call of CheckTaskMemoryAccess(), CheckTaskMemoryAccess() shall yield no access regarding this right.<br />
|-<br />
| OS270 || OK<br />
| If the Task reference <TaskID> in a call of CheckTaskMemoryAccess() is not valid, CheckTaskMemoryAccess() shall yield no access rights.<br />
|-<br />
| OS518 || No scalability Classes support<br />
| Availability of CheckTaskMemoryAccess(): Available in Scalability Classes 3 and 4<br />
|}<br />
<br />
== Memory protection notes ==<br />
* [a] - The OS shares the stack with tasks and ISRs. If SP is invalid when calling a system API, a fault may happen. If a context change happens inside a system call (e.g., ActivateTask() made on a task with higher priority), data from the OS remain saved on the stack of the calling task; other tasks or ISRs from the same OS-Application can overwrite those values. A solution for this problem is in testing on TriCore implementation, but since the kernel on AURIX never allocate stack (this is due to the special carateristic of TriCore Architecture and the compilers optimizations) the implementation cannot be proved until it will backported on PPC or on a new architecture with this pontential problem.<br />
* [b] - This is tricky. Currently, only trusted OS-Applications can access MCU registers. Probably the granularity of the MMU is not enough, and maybe the MPU is not suitable either.<br />
* [c] - In MPC5674F When a protection error occur, one of the IVOR routines is called, which jump to <code>__empty_handler</code>. In TriCore protection hook will be fully supported.<br />
* [d] - The current implementation is more restrictive. If the given memory range is not contained in a single memory section (e.g., it starts inside the stack section and ends inside BSS), no access is returned. This should not create problems, as crossing sections depends on the memory layout; relying on that would be very fragile and no application should do it.<br />
<br />
= Stack monitoring =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS067 || OK TriCore<br />
| The Operating System shall offer a stack monitoring which detects possible stack faults of Task(s)/Category 2 OsIsr(s).<br />
|-<br />
| OS068 || OK TriCore<br />
| If a stack fault is detected by stack monitoring AND the configured scalability class is 1 or 2, the Operating System shall call the ShutdownOS() service with the status E_OS_STACKFAULT.<br />
|-<br />
| OS396 || OK TriCore<br />
| If a stack fault is detected by stack monitoring AND the configured scalability class is 3 or 4, the Operating System shall call the ProtectionHook() with the status E_OS_STACKFAULT.<br />
|}<br />
<br />
= OS-Applications =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS445 || Partial [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| The Operating System shall support OS-Applications which are a composition of (at least one Task OR OsIsr) AND (zero or more Alarms, Schedule tables, Counters or Resources) AND (zero or one hooks for startup, error and shutdown).<br />
|-<br />
| OS446 || OK<br />
| The Operating System shall support the notion of trusted and not trusted OS-Applications.<br />
|-<br />
| OS464 || OK<br />
| Trusted OS-Applications may offer services (“trusted services”) to other (even non-trusted) OS-Applications.<br />
|-<br />
| OS016 || OK (see GetApplicationID())<br />
| The Operating System shall provide a service to determine the currently running OS-Application (a unique identifier shall be allocated to each application).<br />
|-<br />
| OS017 || OK (see CheckObjectOwnership())<br />
| The Operating System shall provide a service to determine to which OS-Application a given Task, OsIsr, Resource, Counter, Alarm or Schedule Table belongs.<br />
|-<br />
| OS256 || OK (see CheckObjectAccess())<br />
| The Operating System shall provide a service to determine which OS-Applications are allowed to use the IDs of a Task, OsIsr, Resource, Counter, Alarm or Schedule Table in API calls.<br />
|-<br />
| OS258 || OK (see TerminateApplication())<br />
| The Operating System shall provide a service to terminate the OS-Application to which the calling Task/Category 2 OsIsr/application specific error hook belongs. (This is an OS-Application level variant of the TerminateTask() service)<br />
|-<br />
| OS447 || OK<br />
| Terminating an OS-Application means to:<br />
* terminate all running, ready and waiting Tasks/OsIsrs of the OS-Application AND<br />
* disabling all interrupts of the OS-Application AND<br />
* stop all active alarms of the OS-Applications AND<br />
* stop all schedule tables of the OS-Application.<br />
|-<br />
| OS448 || OK TriCore<br />
| OS-Applications, trusted or non-trusted, shall by default have only access rights to objects belonging to this OS-Application. Access rights from other OS-Applications shall be granted explicitely by configuration.<br />
|-<br />
| OS060 || OK TriCore [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| If an application-specific startup hook is configured for an OS-Application <App>, the Operating System shall call StartupHook_<App> on startup of the OS.<br />
|-<br />
| OS110 || OK [[#OS-Applications notes|<sup>[c]</sup>]]<br />
| If the Operating System forcibly terminates an OS-Application, it:<br />
* forcibly terminates all Tasks/OsIsrs of the OS-Application AND<br />
* cancels all alarms of the OS-Application AND<br />
* stops schedule tables of the OS-Application AND<br />
* disables interrupt sources of Category 2 OsIsrs belonging to the OS-Application<br />
|-<br />
| OS111 || OK [[#OS-Applications notes|<sup>[c]</sup>]]<br />
| When the Operating System restarts an OS-Application it activates the configured OsRestartTask.<br />
|}<br />
<br />
== New Autosar API ==<br />
<br />
=== GetApplicationID ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS016 || OK<br />
| GetApplicationID<br />
|-<br />
| OS261 || OK TriCore [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| GetApplicationID() shall return the application identifier to which the executing Task/ISR/hook belongs.<br />
|-<br />
| OS262 || OK<br />
| If no OS-Application is running, GetApplicationID() shall return INVALID_OSAPPLICATION.<br />
|-<br />
| OS514 || No scalability Classes support<br />
| Availability of GetApplicationID(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== CheckObjectAccess ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS256 || OK TriCore<br />
| CheckObjectAccess<br />
|-<br />
| OS271 || OK TriCore<br />
| If the OS-Application <ApplID> in a call of CheckObjectAccess() has access to the queried object, CheckObjectAccess() shall return ACCESS.<br />
|-<br />
| OS272 || OK TriCore<br />
| If the OS-Application <ApplID> in a call of CheckObjectAccess() has no access to the queried object, CheckObjectAccess() shall return NO_ACCESS.<br />
|-<br />
| OS423 || OK TriCore<br />
| If in a call of CheckObjectAccess() the object to be examined is not a valid object OR <ApplID> is invalid OR <ObjectType> is invalid THEN CheckObjectAccess() shall return NO_ACCESS.<br />
|-<br />
| OS519 || No scalability Classes support<br />
| Availability of CheckObjectAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== CheckObjectOwnership ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS017 || OK TriCore<br />
| CheckObjectOwnership<br />
|-<br />
| OS273 || OK TriCore<br />
| If the object ObjectType specified in a call of CheckObjectOwnership() exists, CheckObjectOwnership() shall return the identifier of the OS-Application to which the object belongs.<br />
|-<br />
| OS274 || OK TriCore<br />
| If in a call of CheckObjectOwnership() the specified object ObjectType is invalid OR the argument of the type (the “...”) is invalid, CheckObjectOwnership() shall return INVALID_OSAPPLICATION.<br />
|-<br />
| OS520 || No scalability Classes support<br />
| Availability of CheckObjectOwnership():Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== TerminateApplication ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS258 || OK TriCore<br />
| TerminateApplication<br />
|-<br />
| OS493 || OK TriCore<br />
| If the input parameter <Application> in a call of TerminateApplication() is not valid TerminateApplication() shall return E_OS_ID.<br />
|-<br />
| OS459 || OK TriCore<br />
| If the <RestartOption> in a call of TerminateApplication() is invalid, TerminateApplication() shall return E_OS_VALUE.<br />
|-<br />
| OS494 || OK TriCore<br />
| If the input parameter <Application> in a call of TerminateApplication() is valid AND the caller belongs to a non-trusted OS-Application AND the caller does not belong to <Application> TerminateApplication() shall return E_OS_ACCESS.<br />
|-<br />
| OS507 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_TERMINATED TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS508 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_RESTARTING and the caller does not belong to the <Application> then TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS548 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_RESTARTING AND the caller does belong to the <Application> AND the <RestartOption> is equal RESTART then TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS287 || OK TriCore<br />
| If the parameters in a call of TerminateApplication() are valid and the above criteria are met TerminateApplication() shall terminate <Application> (i.e. to kill all tasks, disable the interrupt sources of those ISRs which belong to the OS-Application and free all other OS resources associated with the application) AND shall activate the configured OsRestartTask of <Application> if <RestartOption> equals RESTART. If the <Application> is restarted, its state is set to APPLICATION_RESTARTING otherwise to APPLICATION_TERMINATED. If the caller belongs to <Application> TerminateApplication() shall not return, otherwise it shall return E_OK.<br />
|-<br />
| OS535 || OK TriCore<br />
| Caveats of TerminateApplication():<br />
* If no applications are configured the implementation shall make sure that this service is not available.<br />
* Tasks and interrupts that are owned by a trusted application can terminate any OS-Application. Tasks and interrupts that are owned by a non-trusted application can only terminate their owning OS-Application.<br />
|-<br />
| OS536 || No scalability Classes support<br />
| Availability of TerminateApplication(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== AllowAccess ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS501 || OK TriCore<br />
| AllowAccess<br />
|-<br />
| OS497 || OK TriCore<br />
| If the state of the OS-Application of the caller of AllowAccess() is not APPLICATION_RESTARTING AllowAccess() shall return E_OS_STATE.<br />
|-<br />
| OS498 || OK TriCore<br />
| If the state of the OS-Application of the caller of AllowAccess() is APPLICATION_RESTARTING, AllowAccess() shall set the state to APPLICATION_ACCESSIBLE and allow other OS-Applications to access the configured objects of the callers OS-Application.<br />
|-<br />
| OS547 || No scalability Classes support<br />
| Availability of AllowAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== GetApplicationState ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS499 || OK TriCore<br />
| GetApplicationState<br />
|-<br />
| OS495 || OK TriCore<br />
| If the <Application> in a call of GetApplicationState() is not valid GetApplicationState() shall return E_OS_ID.<br />
|-<br />
| OS496 || OK TriCore<br />
| If the parameters in a call of GetApplicationState() are valid, GetApplicationState() shall return the state of OS-Application <Application> in <Value>.<br />
|-<br />
| OS537 || No scalability Classes support<br />
| Availability of GetApplicationState(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific StartupHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS539 || OK<br />
| Application specific StartupHook. The application specific StartupHook is always called after the standard StartupHook() (see OS236). If more than one OS-Application is configured which use startup hooks, the order of calls to the startup hooks of the different OS- Applications is not defined.<br />
|-<br />
| OS543 || No scalability Classes support<br />
| Availability of StartupHook_<App>(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific ErrorHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS540 || OK TriCore<br />
| Application specific ErrorHook. If the general ErrorHook() is configured, the general ErrorHook() is called before the application specific error hook is called (see OS246).<br />
|-<br />
| OS544 || OK TriCore<br />
| Availability of ErrorHook_<App>(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific ShutdownHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS541 || OK<br />
| Application specific ShutdownHook. If the general ShutdownHook() is configured, the general ShutdownHook() is called after all application specific shutdown hook(s) are called (see OS237). If more OS-Applications with an application specific shutdown hook exist the order of calls to these application specific shutdown hooks is not defined.<br />
|-<br />
| OS545 || No scalability Classes support<br />
| Availability of ShutdownHook_<App>(): Available in Scalability Classes 3 and 4. <br />
|}<br />
<br />
=== OS-Applications notes ===<br />
* [a] - Application-specific hook will be supported by TriCore full release.<br />
* [b] - Object protection will be introduced by TriCore full release, by now all objects are accessible by any OS-Application.<br />
* [c] - Termination of OS-Applications will be introduced by TriCore full release, is not supported yet.<br />
<br />
== Privileged mode ==<br />
<br />
Please see note [[#Privileged mode notes|<sup>[a]</sup>]].<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS058 || OK<br />
| If supported by hardware, the Operating System shall execute non-trusted OS-Applications in non-privileged mode.<br />
|-<br />
| OS096 || OK<br />
| As far as supported by hardware, the Operating System shall not allow non- trusted OS-Applications to access control registers managed by the Operating System.<br />
|-<br />
| OS245 || OK[[#Privileged mode notes|<sup>[b]</sup>]]<br />
| If an instruction exception occurs (e.g. division by zero) the operating system shall call the protection hook with E_OS_PROTECTION_EXCEPTION.<br />
|-<br />
| OS451 || OK<br />
| The Operating System shall allow to export services from trusted OS-Applications.<br />
|-<br />
| OS097 || OK<br />
| The Operating System shall provide a mechanism to call a trusted function from a (trusted or non-trusted) OS-Application.<br />
|-<br />
| OS100 || OK<br />
| If a called trusted function is not configured the Operating System shall call the ErrorHook with E_OS_SERVICEID.<br />
|-<br />
| OS226 || OK[[#Privileged mode notes|<sup>[b]</sup>]]<br />
| The Operating System shall execute an application-specific startup hook with the access rights of the associated OS-Application.<br />
|}<br />
<br />
=== CallTrustedFunction ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS097 || OK<br />
| CallTrustedFunction<br />
|-<br />
| OS265 || OK<br />
| If <FunctionIndex> is a defined function index, CallTrustedFunction() shall switch the processor into privileged mode AND shall call the function <FunctionIndex> out of a list of implementation specific trusted functions with disabled memory protection AND shall return E_OK after completion.<br />
|-<br />
| OS312 || OK<br />
| Caveats of CallTrustedFunction():<br />
* The called trusted function must conform to the following C prototype: void TRUSTED_<name_of_the_trusted_service>( TrustedFunctionIndexType,TrustedFunctionParameterRefType); (The arguments are the same as the arguments of CallTrustedFunction).<br />
* Normally, a user will not directly call this service, but it will be part of some standard interface, e.g. a standard I/O interface.<br />
* It is the duty of the called trusted function to check rights of passed parameters, especially if parameters are interpreted as out parameters.<br />
* It should be noted that the CallTrustedFunction() does not disable timing protection for the task which called the service. This may lead to timing faults (calls of the ProtectionHook()) even inside of a trusted OS-Application. It is therefore recommended to use CallTrustedFunction() only for stateless functions (e.g. functions which do not write or do not have internal states)<br />
|-<br />
| OS266 || OK [[#Privileged mode notes|<sup>[b]</sup>]]<br />
| When CallTrustedFunction() calls the function <FunctionIndex>, that function shall be executed with the same processor mode and memory protection boundaries as the OS-Application to which it belongs. It shall however retain the timing protection and service protection limitations of the calling Task or ISR, and the notion of "current application" shall remain that of the calling Task or Category 2 ISR.<br />
|-<br />
| OS364 || OK [[#Privileged mode notes|<sup>[b]</sup>]][[#Privileged mode notes|<sup>[c]</sup>]]<br />
| If CallTrustedFunction() calls the trusted function from a Category 2 ISR context, that function shall continue to run on the same interrupt priority and be allowed to call all system services defined for Category 2 ISR (see table in chapter 7.7.3.2).<br />
|-<br />
| OS365 || OK [[#Privileged mode notes|<sup>[b]</sup>]][[#Privileged mode notes|<sup>[c]</sup>]]<br />
| If CallTrustedFunction() calls the trusted function from a task context, that function shall continue to run on the same priority and be allowed to call all system services defined for tasks (see table in chapter 7.7.3.2).<br />
|}<br />
<br />
=== Privileged mode notes ===<br />
: [a] - In MPC5674F priviliged mode is enabled by the SC4 flag (This incomplete support of scalability classes have been removed in TriCore porting).<br />
: [b] - Supported only by TriCore implementation.<br />
: [c] - In MPC5674F a trusted function is executed in the security context of the calling function, although it runs in privileged mode.<br />
<br />
== Protection hook ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS099 || OK (See CheckTaskMemoryAccess() and CheckISRMemoryAccess())<br />
| The Operating System shall offer OS-Applications a service to check if a memory region is write/read/execute accessible from a Task/Category 2 OsIsr and also return information if the memory region is part of the stack space.<br />
|-<br />
| OS211 || OK TriCore<br />
| The Operating System shall execute the ProtectionHook() with the same permissions as the Operating System.<br />
|-<br />
| OS106 || OK TriCore<br />
| The Operating System shall perform one of the following reactions depending on the return value of the ProtectionHook():<br />
* Do nothing<br />
* Forcibly terminate the faulty Task/Category 2 OsIsr OR<br />
* Forcibly terminate the faulty OS-Application OR<br />
* Forcibly terminate the faulty OS-Application and restart the OS-Application. OR<br />
* Call ShutdownOS().<br />
|-<br />
| OS107 || OK TriCore<br />
| If no ProtectionHook() is configured and a protection error occurs, the Operating System shall call ShutdownOS().<br />
|-<br />
| OS475 || OK TriCore<br />
| If the reaction is to do nothing and the ProtectionHook() was not called with E_OS_PROTECTION_ARRIVAL then the Operating System shall call ShutdownOS()<br />
|-<br />
| OS243 || OK TriCore<br />
| If the reaction is to forcibly terminate the Task/Category 2 OsIsr and no Task or OsIsr can be associated with the error, the running OS-Application is forcibly terminated by the Operating System.<br />
|-<br />
| OS244 || OK TriCore<br />
| If the reaction is to forcibly terminate the faulty OS-Application and no OS- Application can be assigned, ShutdownOS()is called.<br />
|-<br />
| OS108 || OK TriCore<br />
| If the Operating System forcibly terminates a task, it terminates the task (no PostTaskHook() for the task will be called), releases all allocated OSEK resources and calls EnableAllInterrupts()/ / ResumeOSInterrupts() ResumeAllInterrupts() if the Task called DisableAllInterrupts() / / SuspendAllInterrupts() before without the SuspendOSInterrupts() EnableAllInterrupts()/ / corresponding ResumeOSInterrupts() ResumeAllInterrupts() call.<br />
|-<br />
| OS109 || OK TriCore<br />
| If the Operating System forcibly terminates an interrupt service routine, it clears the interrupt request, aborts the interrupt service routine (The interrupt source stays in the current state.) and releases all OSEK resources the interrupt service routine has allocated and calls EnableAllInterrupts() / ResumeOSInterrupts() / ResumeAllInterrupts() if the interrupt called DisableAllInterrupts() / / SuspendAllInterrupts() before without the SuspendOSInterrupts() corresponding EnableAllInterrupts()/ / ResumeOSInterrupts() ResumeAllInterrupts() call.<br />
|-<br />
| OS538 || OK TriCore<br />
| Protection Hook Depending on the return value the Operating System module will either:<br />
* forcibly terminate the Task/Category 2 ISR which causes the problem OR<br />
* forcibly terminate the OS-Application the Task/Category 2 ISR belong (optional with restart) OR<br />
* shutdown the system OR<br />
* do nothing (see 7.8.2)<br />
|-<br />
| OS308 || OK TriCore<br />
| If ProtectionHook() returns an invalid value, the Operating System module shall take the same action as if no protection hook is configured.<br />
|-<br />
| OS542 || No scalability Classes support<br />
| Availability of ProtectionHook(): Available in Scalability Classes 2, 3 and 4.<br />
|}<br />
<br />
= Other New Autosar APIs =<br />
<br />
=== GetISRID ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS511 || OK<br />
| GetISRID<br />
|-<br />
| OS263 || OK<br />
| If called from category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID() shall return the identifier of the currently executing ISR.<br />
|-<br />
| OS264 || partial<br />
| If its caller is not a category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID() shall return INVALID_ISR.<br />
|-<br />
| OS515 || OK (?)<br />
| Availability of GetISRID(): Available in all Scalability Classes.<br />
|}<br />
<br />
<br />
= Timing Protection =<br />
<br />
Actually implemented only for Tricore<br />
<br />
== General Requirement ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS028 || OK, but not Enforced by RT-Druid<br />
| In a non-trusted OS-Application, the Operating System module shall apply timing protection to every Task/Category 2 ISR of this non-trusted OS-Application<br />
|-<br />
| OS089 || OK<br />
| In a trusted OS-Application, the Operating System module shall provide the ability to apply timing protection to Tasks/Category 2 ISRs of this OS-Application.<br />
|-<br />
| OS397 || OK<br />
| If no OS-Application is configured, the Operating System module shall be able to apply timing protection to Tasks/Category 2 ISRs.<br />
|}<br />
<br />
== Timing Protection: Tasks ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS064 || OK<br />
| If a task’s OsTaskExecutionBudget is reached then the Operating System module shall call the ProtectionHook() with E_OS_PROTECTION_TIME.<br />
|-<br />
| OS473 || OK<br />
| OsTaskExecutionBudget on a transition to the SUSPENDED or WAITING states.<br />
|-<br />
| OS465 || OK<br />
| The Operating System module shall limit the inter-arrival time of tasks to one per OsTaskTimeFrame<br />
|-<br />
| OS469 || OK<br />
| The Operating System module shall start an OsTaskTimeFrame when a task is activated successfully<br />
|-<br />
| OS472 || OK<br />
| The Operating System module shall start an OsTaskTimeFrame when a task is released successfully<br />
|-<br />
| OS466 || OK<br />
| If an attempt is made to activate a task before the end of an OsTaskTimeFrame then the Operating System module shall not perform the activation AND shall call the ProtectionHook() with E_OS_PROTECTION_ARRIVAL<br />
|-<br />
| OS467 || OK<br />
| If an attempt is made to release a task before the end of an OsTaskTimeFrame then the Operating System module shall not perform the release AND shall call the ProtectionHook() with E_OS_PROTECTION_ARRIVAL AND the event shall be set<br />
|-<br />
|}<br />
<br />
<br />
== Timing Protection: ISR2 ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS210 || OK<br />
| If a Category 2 ISR’s OsIsrExecutionBudget is reached then the Operating System module shall call the ProtectionHook() with E_OS_PROTECTION_TIME<br />
|-<br />
| OS474 || OK<br />
| The Operating System module shall rest an ISR’s OsIsrExecutionBudget when the ISR returns control to the Operating terminates<br />
|-<br />
| OS470 || OK<br />
| The Operating System module shall limit the inter-arrival time of Category 2 ISRs to one per OsIsrTimeFrame<br />
|-<br />
| OS471 || OK<br />
| The Operating System module shall measure the start of an OsIsrTimeFrame from the point at which it recognises the interrupt (i.e. in the Operating System interrupt wrapper)<br />
|-<br />
| OS048 || OK<br />
| If Category 2 interrupt occurs before the end of the OsIsrTimeFrame then the Operating System module shall not execute the user provided ISR AND shall call the ProtectionHook() with E_OS_PROTECTION_ARRIVAL<br />
|}<br />
<br />
= Multi-Core =<br />
<br />
== Basic Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS567 || OK (We have some doubts relates to this, but it should be OK)<br />
| The generated part of the OS is derived from a single configuration that contains the relevant information for all cores. This implies, that IDs (e.g. TASKID, RESOURCEID, …) are unique across cores. Every ID shall refer exactly to one entity independent from the core on which the entity is accessed. This applies also to objects that cannot be shared between cores. (BSW4080008)<br />
|-<br />
| OS568 || OK<br />
|Implementations shall be able to independently execute a TASK or an ISR on each started AUTOSAR OS core in parallel. (BSW4080001)<br />
|-<br />
| OS569 || OK<br />
|The scheduling strategy as defined in AUTOSAR OS shall apply for each individual core in a Multi-Core system, for the TASKs and ISR assigned to the core. (BSW4080001, BSW4080013)<br />
|-<br />
| OS570 || OK<br />
| All TASKs that are assigned to the same OS-Application shall execute on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS571 || OK<br />
| All ISRs that are assigned to the same OS-Application shall execute on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS572 || N.A. in Supported Architectures (PPC TriCore)<br />
| ISR balancing (if supported by the HW) shall be switched off at boot time by the OS. (BSW4080005, BSW4080006)<br />
|-<br />
| OS764 || No scalability classes support (OS-Applications are enabled when configurated).<br />
| The OS module shall support OS-Applications in case of Multi-Core also for SC1 and SC2.<br />
|-<br />
| OS763 || No scalability classes support (But we don't understend this requirement).<br />
| In an SC1 system standard mode shall be possible.<br />
|-<br />
| OS573 ||<br />
| The binding of OS-Applications to cores shall be configured within the OS-Application container. A new configuration item: OsApplicationCoreAssignment{CORE} within the OS-Application container shall be used to define the core to which the OS-Application is bound. The OS generator will map the configuration parameter “CORE” to a certain core, so that all OS-Applications with the same configuration parameter reside on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS623 || OK<br />
| The OS API function CallTrustedFunction shall return E_OS_ACCESS in extended status if the target trusted function is part of an OS-Application on another core. (BSW4080013)<br />
|-<br />
|}<br />
<br />
== Multi-Core start-up Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS574 || OK<br />
| The master core shall be able to activate cores. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS575 || OK<br />
| Any slave core shall be able to activate cores. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS576 || OK<br />
| It shall be allowed to use only a subset of the cores available on a μC for the AUTOSAR system. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS577 || OK (TriCore e PPC e200zx are naturally in Master-Slave configuration)<br />
| The cores shall boot in master-slave mode. If this is not supported by the hardware, it shall be that the cores boot in parallel and emulate the behavior of a master-slave system.. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS578 || N.A.<br />
| In case of an emulation a slave core (CoreS), which is controlled by the AUTOSAR OS (AUTOSAR core), shall not enter the main function before another<br />
core has activated the slave core by means of StartCore(CoreS). (BSW4080006)<br />
|-<br />
| OS579 || OK<br />
| All cores that belong to the AUTOSAR system shall be synchronized within the StartOS function before the scheduling is started and after the global<br />
StartupHook is called.. (BSW4080001, BSW4080006)<br />
|-<br />
| OS580 || OK<br />
| All cores that belong to the AUTOSAR system shall be synchronized within the StartOS function before the scheduling is started and after the global<br />
StartupHook is called.. (BSW4080006)<br />
|-<br />
| OS581 || OK TriCore<br />
| The global StartupHook shall be called on all cores immediately after the first synchronisation point (BSW4080006)<br />
|-<br />
| OS582 || OK TriCore<br />
| The OS-Application-specific StartupHooks shall be called after the global StartupHook but only on the cores to which the OS-Application is bound (BSW4080006, BSW4080008)<br />
|-<br />
| || OK TriCore<br />
| The AUTOSAR OS API provides a StartCore function to start the cores under its control. The StartCore function takes a scalar value parameter of type CoreIDType, specifying the core that shall be started. StartCore can be called more than once on the master core and also on slave cores. Each core can only be started once, however The StartOS function shall be called on all cores that have been activated by StartCore. It is not allowed to call StartCore from a core that has already called StartOS. Cores that belong to the AUTOSAR system shall be started by the designated AUTOSAR OS API service StartCore.<br />
|-<br />
| OS583 || OK TriCore<br />
| The number of cores that can be controlled by the AUTOSAR OS shall be configured offline. A new configuration item (OsNumberOfCores) within the “OsOS” container is used to specify the maximum number of cores that are controlled by the AUTOSAR OS. If no value for (OsNumberOfCores) has been specified the number of cores shall be one. (BSW4080001, BSW4080011) <br />
|-<br />
| OS584 || OK TriCore<br />
| The AUTOSAR OS shall provide a function called StartNonAutosarCore that can be used to start cores, which are not controlled by the AUTOSAR OS. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS585 || OK TriCore<br />
| It shall be possible to activate cores that are not controlled by the AUTOSAR OS before and after calling StartOS. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS606 || OK TriCore<br />
| The AUTOSAR specification does not support the activation of AUTOSAR cores after calling StartOS on that core. If StartCore is called after StartOS it shall return with E_OS_ACCESS in extended status. (BSW4080001)<br />
|-<br />
| OS607 || OK TriCore<br />
| StartOS shall start the OS on the core on which it is called. (BSW4080006, BSW4080013)<br />
|-<br />
| OS608 || OK TriCore<br />
| If more than one core calls StartOS with an AppMode other than “DONOTCARE”, the AppModes shall be the same. StartOS shall check this at the first synchronisation point. In case of violation, StartOS shall not start the scheduling, shall not call any StartupHooks, and shall enter an endless loop on every core. (BSW4080006)<br />
|-<br />
| OS609 || OK TriCore<br />
| If StartOS is called with the AppMode “DONOTCARE” the application mode of the other core(s) (differing from “DONOTCARE”) shall be used. (BSW4080006)<br />
|-<br />
| OS610 || OK TriCore<br />
| At least one core shall define an AppMode other than “DONOTCARE”. (BSW4080006)<br />
|-<br />
| OS611 || OK TriCore<br />
| If the IOC is configured, StartOS shall initialize the data structures of the IOC. (BSW4080020)<br />
|-<br />
| OS668 || OK<br />
| The AUTOSAR Operating System shall automatically activate all auto-start TASKs configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
| OS669 || OK<br />
| The AUTOSAR Operating System shall automatically activate all auto-start ALARMs configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
| OS670 || Not Schedule tables supported yet<br />
| The AUTOSAR Operating System shall automatically activate all auto-start schedule tables configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
|}<br />
<br />
== Multicore Shutdown Requirements ==<br />
<br />
AUTOSAR supports two shutdown concepts, the synchronized shutdown and the individual shutdown concept. While the synchronized shutdown is triggered by the new API function '''ShutdownAllCores()''', the individual shutdown is invoked by the existing API function '''ShutdownOS()'''.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS586 || OK TriCore<br />
| During the shutdown, the OS-Application specific ShutdownHook shall be called on the core on which the corresponding OS-Application is bound. (BSW4080007)<br />
|- <br />
| OS587 || OK TriCore (if ShutdownAllCores has been called)<br />
| Before calling the global ShutdownHook, all cores shall be synchronized. (BSW4080007)<br />
|- <br />
| OS588 || OK<br />
| The global ShutdownHook shall be called on all cores. (BSW4080007)<br />
|-<br />
| OS762 || OK TriCore (fullfilled by ProtectionHook implementation)<br />
| In cases where the OS detects a fatal internal error all cores shall be shutdown.<br />
|-<br />
| OS616 || OK<br />
| ShutdownOS shall be callable from each core running an AUTOSAR OS. (BSW4080001, BSW4080007)<br />
|-<br />
| OS617 || OK<br />
| ShutdownOS shall shutdown the core on which it was called. (BSW4080007)<br />
|-<br />
| OS618 || OK<br />
| The OS shall not start TASKs of an OS-Application once the shutdown procedure has been entered on a particular core. (BSW4080013)<br />
|-<br />
| OS619 || OK<br />
| The AUTOSAR OS function ShutdownOS shall be callable in parallel on multiple cores. (BSW4080013)<br />
|-<br />
| OS620 || OK TriCore<br />
| ShutdownOS shall release all spinlocks which are occupied by the calling core. (BSW4080021)<br />
|-<br />
| OS621 || OK TriCore<br />
| ShutdownAllCores shall be callable from each core running an AUTOSAR OS. (BSW4080007)<br />
|-<br />
|}<br />
<br />
== OS Other Services Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS589 || OK TriCore<br />
| All functions that are not allowed to operate cross core shall return E_OS_CORE in extended status if called with parameters that require a cross core operation. (BSW4080013)<br />
|-<br />
| OS590 || OK<br />
| The OS service “DisableAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS591 || OK<br />
| The OS service “EnableAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS592 || OK<br />
| The OS service “SuspendAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS593 || OK<br />
| The OS service “ResumeAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS594 || OK<br />
| The OS service “SuspendOSInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS595 || OK<br />
| The OS service “ResumeOSInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS596 || OK<br />
| It shall be possible to activate a TASK that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080001, BSW4080015)<br />
|-<br />
| OS598 || OK TriCore (RPC Dispactcher)<br />
| The call of ActivateTask across cores shall behave synchronously, i.e. a call returns after the task has been activated or an error has been detected. It shall not be possible to continue execution on the calling core before ActivateTask is accomplished on the remote core. (BSW4080015)<br />
|-<br />
| OS599 || OK TriCore (RPC Dispactcher)<br />
| In case of an error when calling ActivateTask across cores, the error handler shall be called on the core on which ActivateTask was originally called. (BSW4080015)<br />
|-<br />
| OS600 || OK<br />
| It shall be possible to chain a TASK that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080001, BSW4080015)<br />
|-<br />
| OS602 || OK<br />
| It shall be possible to set an EVENT that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080016)<br />
|-<br />
| OS604 || OK TriCore (RPC Dispactcher)<br />
| The call of SetEvent across cores shall behave synchronously, i.e. a call returns after the Event has been set or an error has been detected. It shall not be possible to continue execution on the calling core before SetEvent is accomplished on the remote core. (BSW4080016)<br />
|-<br />
| OS605 || OK TriCore (RPC Dispactcher [[#MultiCore notes|<sup>[a]</sup>]])<br />
| In case of an error when calling SetEvent across cores, the error handler shall be called on the core on which SetEvent was originally called. (BSW4080016)<br />
|-<br />
| OS612 || OK TriCore<br />
| In extended status TerminateTask / ChainTask shall return with an error (E_OS_SPINLOCK), which can be evaluated in the application. (BSW4080021)<br />
|-<br />
| OS613 || OK TriCore<br />
| Spinlocks occupied by TASKS that are terminated in response to a protection hook shall be automatically released. This applies also to the case in which an OS-Application is terminated. (BSW4080021)<br />
|-<br />
| OS614 || OK TriCore<br />
| TerminateApplication shall check if any of the TASKs in the OS-Application have occupied a spinlock. If so, the spinlocks shall be released.(BSW4080021)<br />
|-<br />
| OS615 ||<br />
| If TerminateApplication(A) is called in parallel from different cores, the OsApplication “A” is terminated by the first call, any subsequent calls will return with 'E_OK' in standard and extended status without doing anything, until the termination is completed.<br />
|-<br />
| OS622 || OK<br />
| The AUTOSAR Operating System WaitEvent API service shall check if it has been called while the calling TASK has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the TASK shall not enter the wait state. (BSW4080021)<br />
|-<br />
| OS624 || OK<br />
| The AUTOSAR Operating System Schedule API service shall check if it has been called while the calling TASK has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the scheduler shall not be called. (BSW4080021)<br />
|-<br />
| OS629 || OK<br />
| A COUNTER belonging to an OS-Application shall be incremented by the core on which the OS-Application resides. The COUNTER shall not be incremented by other cores. (BSW4080013)<br />
|-<br />
| OS630 || OK<br />
| It shall not be allowed to drive a schedule table from a COUNTER, which is assigned to a different core. (BSW4080013)<br />
|-<br />
| OS631 || OK<br />
| It shall not be allowed to drive an ALARM from a COUNTER, which is assigned to a different core. (BSW4080013)<br />
|-<br />
| OS632 || OK<br />
| If an ALARM expires, it shall be allowed to activate a TASK on a different core. (BSW4080018)<br />
|-<br />
| OS633 || OK<br />
| If an ALARM expires, it shall be allowed to set an EVENT on a different core. (BSW4080018)<br />
|-<br />
| OS634 || OK<br />
| The AUTOSAR Operating System shall process an ALARM on the core on which its corresponding OS-Application resides. (BSW4080018)<br />
|-<br />
| OS635 || OK<br />
| ALARM callbacks shall be executed on the core to which the ALARM is bound. This is only applicable to SC1 systems, because otherwise Alarm Callback<br />
are not allowed (OS242). (BSW4080013)<br />
|-<br />
| OS636 || OK<br />
| SetRelAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|-<br />
| OS637 || OK<br />
| SetAbsAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS638 || OK<br />
| CancelAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS639 || OK<br />
| GetAlarmBase shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS640 || OK<br />
| GetAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
|}<br />
<br />
== MultiCore notes ==<br />
: [a] - [[Infineon_Aurix#Multicore_Autosar_OS_Support|New RPC MultiCore dispatcher]]<br />
<br />
== Other AUTOSAR Multicore API ==<br />
<br />
=== GetCoreID ===<br />
<br />
Every HW assigns a unique physical Id to a core. The physical core Id is the only way to distinguish between cores. <br />
The physical core Ids of a μC are not necessarily consecutive and do not necessarily start with zero.<br />
The SW requires a mechanism to identify a core, e.g. to use core specific variables. Because the physical core Id usually can not be used as a direct array index for core specific variables, a logical CoreID is necessary to map physical core Ids to array indexes. In the SW it is not necessary to know the physical core Id, the logical CoreID is sufficient.<br />
The mapping of OSApplications and other SW objects to cores is specified in the configuration files. All such mappings shall be HW independent and therefore shall not be based on the physical core Id but on the logical CoreID. The function GetCoreID internally maps the physical core Id to the logical CoreID. The mapping is implementation specific. GetCoreID can be either a C function or a macro.<br />
<br />
'''N.B''' In Erika with code replication the core ID is not a real issue.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS625 || OK TriCore<br />
| The AUTOSAR Operating System API function GetCoreID shall be callable before StartOS. (BSW4080006)<br />
|-<br />
| OS626 || OK TriCore<br />
| An implementation shall offer a function GetNumberOfActivatedCores that returns the number of cores running the AUTOSAR OS. (BSW4080001)<br />
|-<br />
| OS627 || OK TriCore<br />
| An implementation shall define a set of constants OS_CORE_ID_<No> of the type CoreIDType with <No> a value from 0 to “OsNumberOfCores -1. (BSW4080001)<br />
|-<br />
| OS628 || OK TriCore<br />
| An implementation shall offer a constant OS_CORE_ID_MASTER of the type CoreIDType that refers to the master core. (BSW4080001)<br />
|}<br />
<br />
== Spinlocks ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS648 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a spinlock mechanism that works across cores. (BSW4080018, BSW4080021)<br />
|-<br />
| OS649 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a GetSpinlock function which occupies a spinlock. If the spinlock is already occupied, GetSpinlock shall<br />
keep on trying to occupy the spinlock until it succeeds. (BSW4080018, BSW4080021)<br />
|-<br />
| OS650 || OK TriCore<br />
| GetSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS651 || OK TriCore<br />
| GetSpinlock shall be callable from ISR2 level. The behavior of GetSpinlock is undefined if called from a category 1 ISR. (BSW4080021)<br />
|-<br />
| OS652 || OK TriCore (With Trivial spinlocks)<br />
| The AUTOSAR Operating System shall provide a TryToGetSpinlock function which occupies a spinlock. If the spinlock is already occupied by a TASK,<br />
TryToGetSpinlock shall return. (BSW4080018, BSW4080021)<br />
|-<br />
| OS653 || OK TriCore<br />
| TryToGetSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS654 || OK TriCore<br />
| TryToGetSpinlock shall be callable from ISR2 level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS655 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a ReleaseSpinlock function which releases an occupied spinlock. If the spinlock is not occupied an error<br />
shall be returned. (BSW4080018, BSW4080021)<br />
|-<br />
| OS656 || OK TriCore<br />
| ReleaseSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS657 || OK TriCore<br />
| ReleaseSpinlock shall be callable from ISR2 level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS658 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if a TASK tries to occupy a spinlock that is assigned to a TASK/ISR2 on the same core (including<br />
itself). (BSW4080018, BSW4080021)<br />
|-<br />
| OS659 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if an ISR2 tries to occupy a spinlock that is assigned to a TASK/ISR2 on the same core.<br />
(BSW4080018, BSW4080021)<br />
|-<br />
| OS660 || OK TriCore<br />
| A unique order in which multiple spinlocks can be occupied by a TASK/ISR2 should be configurable in the AUTOSAR Operating System. This might<br />
be realized by the configuration item (OsSpinlockSuccessor{NEXT_SPINLOCK}) where “NEXT_SPINLOCK” refers to the consecutive spinlock. (See chapter 10.2.5) (BSW4080018, BSW4080021)<br />
|-<br />
| OS661 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if a TASK/ISR2 that currently holds a spinlock tries to seize another spinlock that has not been<br />
configured as a direct or indirect successor of the latest acquired spinlock (by means of the OsSpinlockSuccessor configuration parameter) or if no successor is configured. (BSW4080018, BSW4080021)<br />
|-<br />
|}<br />
<br />
= Inter-OS-Application Communicator (IOC) Requirements =<br />
<br />
IOC stands for Inter OS-Application Communicator. The "IOC" is responsible for the communication between OS-Applications and in<br />
particular for the communication crossing core or memory protection boundaries. It's internal functionality is closely connected to the Operating System.<br />
<br />
Memory protection boundaries are a characteristic of OS-Applications and special communication mechanisms are needed to cross them.<br />
Multi-Core systems may also need additional measures to make communication between cores safe.<br />
<br />
The IOC provides communication services between OS-Applications and in particular over core boundaries in Multi-Core systems. Because the cross-core communication is always an inter-OS-Application communication, the two mechanisms are combined. An inter OS-Application communication may not necessarily require a cross core communication, however.<br />
<br />
In systems with only one core, the IOC can be omitted completely, if just one OS-Application is available, or if no OS-Application uses memory protection mechanisms.<br />
<br />
'''N.B''' Since a lot of Code of IOC is configurated and generated starting from RTE configuration, it doesn't make sense generate a whole IOC system without a complete RTE generator. But '''we choiced the cross-boundaries communication mechanism''' that is the heart of IOC. The same mechanism is employed to implement OS Services remote invocation.<br />
<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS671 ||<br />
| The IOC implementation shall be part of the Operating System The IOC is a third type of communication, in addition to:<br />
* Intra OS-Application communication: Always handled within the RTE<br />
* Inter ECU communication: already available via well defined interfaces to the communication stack (COM).<br />
(BSW4080020)<br />
|-<br />
|}</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=ERIKA_%26_Autosar_OS_RequirementsERIKA & Autosar OS Requirements2016-09-30T13:48:25Z<p>Eguidieri: /* Other New Autosar APIs */</p>
<hr />
<div>= Introduction =<br />
Erika Enterprise is the first open-source Free RTOS that has been certified OSEK/VDX compliant and it's under current developtment to fulfil Autosar 4 OS Requirements too. In the following table are logged the AUTOSAR requirements already implemneted in ERIKA.<br />
<br />
* All the requirement tagged as OK are implemented in all supported Architectures.<br />
* All the requirements related to '''memory protection''' are available only for those MCU that have memory protection implmentented: currently only support for Freescale MPC5674F has been released.<br />
* All the requirements tagged as TriCore are implemented but will be realesed when the full support for TriCore AURIX will be released.<br />
<br />
Scalability Classes are not implemented yet, but each feature/API is activated only if required by the configuration.<br />
<br />
= Tasks =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS052 || OK<br />
| If a task returns from its entry function without making a TerminateTask() or ChainTask() call, the Operating System shall terminate the task (and call the PostTaskHook() if configured).<br />
|-<br />
| OS069 || OK<br />
| If a task returns from its entry function without making a TerminateTask() or ChainTask() call AND the error hook is configured, the Operating System shall call the ErrorHook() (this is done regardless of whether the task causes other errors, e.g. E_OS_RESOURCE) with status E_OS_MISSINGEND before the task leaves the RUNNING state.<br />
|-<br />
| OS070 || OK<br />
| If a task returns from the entry function without making a TerminateTask() or ChainTask() call and still holds OSEK Resources, the Operating System shall release them.<br />
|-<br />
| OS239 || OK<br />
| If a task returns from the entry function without making a TerminateTask() or ChainTask() call and interrupts are still disabled, the Operating System shall enable them.<br />
|-<br />
| OS071 || OK<br />
| If the PostTaskHook() is configured, the Operating System shall not call the hook if ShutdownOS() is called.<br />
|}<br />
<br />
= ISR2s =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS368 || OK<br />
| If a Category 2 OsIsr calls DisableAllInterupts() SuspendAllInterrupts() / SuspendOSInterrupts() and ends (returns) without calling the corresponding EnableAllInterrupts() / ResumeAllInterrupts() / ResumeOSInterrupts(), the Operating System shall perform the missing service and shall call the ErrorHook() (if configured) with the status E_OS_DISABLEDINT.<br />
|-<br />
| OS369 || OK<br />
| If a Category 2 OsIsr calls GetResource() and ends (returns) without calling the corresponding ReleaseResource(), the Operating System shall perform the ReleaseResource() call and shall call the ErrorHook() (if configured) with the status E_OS_RESOURCE.<br />
|}<br />
<br />
= Hooks =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS236 || OK TriCore<br />
| If both a system-specific and one (or more) application specific startup hook(s) are configured, the Operating System shall call the system-specific startup hook before the application-specific startup hook(s).<br />
|-<br />
| OS112 || OK TriCore<br />
| If an application-specific shutdown hook is configured for an OS-Application <App>, the Operating System shall call ShutdownHook_<App> on shutdown of the OS.<br />
|-<br />
| OS225 || OK TriCore<br />
| The Operating System shall execute an application-specific shutdown hook with the access rights of the associated OS-Application.<br />
|-<br />
| OS237 || OK TriCore<br />
| If both a system-specific and one (or more) application specific shutdown hook(s) are configured, the Operating System shall call the system-specific shutdown hook after the application-specific shutdown hook(s).<br />
|-<br />
| OS246 || OK TriCore<br />
| When an error occurs AND an application-specific error hook is configured for the faulty OS-Application <App>, the Operating System shall call that application- specific error hook ErrorHook_<App> after the system specific error hook is called (if configured).<br />
|-<br />
| OS085 || OK TriCore<br />
| The Operating System shall execute an application-specific error hook with the access rights of the associated OS-Application.<br />
|}<br />
<br />
= Timers and Counters =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS301 || OK<br />
| The Operating System shall provide the ability to increment a software counter as an alternative action on alarm expiry.<br />
|-<br />
| OS399 || OK<br />
| The OS shall provide an API call to increment a software counter.<br />
|-<br />
| OS374 || OK<br />
| The Operating System shall handle all the initialization and configuration of timers used directly by the OS and not handled by the GPT driver.<br />
|-<br />
| OS383 || OK (partials)<br />
| The Operating System shall provide a service to read the current count value of a counter (returning either the hardware timer ticks if counter is driven by hardware or the software ticks when user drives counter).<br />
|-<br />
| OS392 || OK<br />
| The Operating System shall provide a service to get the number of ticks between the current tick value and a previously read tick value.<br />
|-<br />
| OS384 ||<br />
| The Operating System shall adjust the read out values of hardware timers (which drive counters) in such that the lowest value is zero and consecutive reads return an increasing count value until the timer wraps at its modulus.<br />
|}<br />
<br />
== Autosar New API for Timers and Counters ==<br />
<br />
=== IncrementCounter ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS399 || OK<br />
| IncrementCounter<br />
|-<br />
| OS285 || OK<br />
| If the input parameter <CounterID> in a call of IncrementCounter() is not valid OR the counter is a hardware counter, IncrementCounter() shall return E_OS_ID.<br />
|-<br />
| OS286 || OK<br />
| If the input parameter of IncrementCounter() is valid, IncrementCounter() shall increment the counter <CounterID> by one (if any alarm connected to this counter expires, the given action, e.g. task activation, is done) and shall return E_OK.<br />
|-<br />
| OS321 || OK<br />
| If in a call of IncrementCounter() an error happens during the execution of an alarm action, e.g. E_OS_LIMIT caused by a task activation, IncrementCounter() shall call the error hook(s), but the IncrementCounter() service itself shall return E_OK.<br />
|-<br />
| OS529 || OK<br />
| Caveats of IncrementCounter(): If called from a task, rescheduling may take place.<br />
|-<br />
| OS530 || OK<br />
| Availability of IncrementCounter(): Available in all Scalability Classes.<br />
|}<br />
<br />
=== GetCounterValue ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS383 || OK<br />
| GetCounterValue<br />
|-<br />
| OS376 || OK<br />
| If the input parameter <CounterID> in a call of GetCounterValue() is not valid, GetCounterValue() shall return E_OS_ID.<br />
|-<br />
| OS377 || OK<br />
| If the input parameter <CounterID> in a call of GetCounterValue() is valid, GetCounterValue() shall return the current tick value of the counter via <Value> and return E_OK.<br />
|-<br />
| OS531 || OK (partials)<br />
| Caveats of GetCounterValue(): Note that for counters of OsCounterType = HARDWARE the real timer value (the – possibly adjusted – hardware value, see OS384) is returned, whereas for counters of OsCounterType = SOFTWARE the current “software” tick value is returned.<br />
|-<br />
| OS532 || OK<br />
| Availability of GetCounterValue(): Available in all Scalability Classes.<br />
|}<br />
<br />
=== GetElapsedValue ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS392 || OK<br />
| GetElapsedValue<br />
|-<br />
| OS381 || OK<br />
| If the input parameter <CounterID> in a call of GetElapsedValue() is not valid GetElapsedValue() shall return E_OS_ID.<br />
|-<br />
| OS391 || OK<br />
| If the <Value> in a call of GetElapsedValue() is larger than the max allowed value of the <CounterID>, GetElapsedValue() shall return E_OS_VALUE.<br />
|-<br />
| OS382 || OK<br />
| If the input parameters in a call of GetElapsedValue() are valid, GetElapsedValue() shall return the number of elapsed ticks since the given <Value> value via <ElapsedValue> and shall return E_OK.<br />
|-<br />
| OS460 || OK<br />
| GetElapsedValue() shall return the current tick value of the counter in the <Value> parameter.<br />
|-<br />
| OS533 || OK<br />
| Caveats of GetCounterValue():If the timer already passed the <Value> value a second (or multiple) time, the result returned is wrong. The reason is that the service can not detect such a relative overflow.<br />
|-<br />
| OS534 || OK<br />
| Availability of GetCounterValue(): Available in all Scalability Classes.<br />
|}<br />
<br />
== OSEK Requirements Extensions ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS304 || OK<br />
| If in a call to SetRelAlarm() the parameter “increment” is set to zero, the service shall return E_OS_VALUE in standard and extended status .<br />
|-<br />
| OS424 || OK<br />
| The first call to StartOS() (for starting the Operating System) shall not return.<br />
|-<br />
| OS425 || OK<br />
| If ShutdownOS() is called and ShutdownHook() returns then the operating system shall disable all interrupts and enter an endless loop.<br />
|-<br />
| OS299 || OK<br />
|The Operating System shall provide the services DisableAllInterrupts(), EnableAllInterrupts(), SuspendAllInterrupts(), ResumeAllInterrupts() prior to calling StartOS() and after calling ShutdownOS(). (It is assumed that the static variables of these functions are initialized).<br />
|-<br />
| OS051 || OK TriCore<br />
| If an invalid address (address is not writable by this OS-Application) is passed as an out-parameter to an OS service, the Operating System shall return the status code E_OS_ILLEGAL_ADDRESS.<br />
|-<br />
| OS088 || OK TriCore<br />
| If an OS-Application makes a service call from the wrong context AND is currently not inside a Category 1 OsIsr the Operating System shall not perform the requested action (the service call shall have no effect), and return E_OS_CALLEVEL or the “invalid value” of the service.<br />
|-<br />
| OS092 || OK<br />
| If EnableAllInterrupts() ResumeAllInterrupts() / ResumeOSInterrupts() are called and no corresponding DisableAllInterupts() / SuspendAllInterrupts() / SuspendOSInterrupts() was done before, the Operating System shall not perform this OS service.<br />
|-<br />
| OS093 || OK<br />
| If interrupts are disabled/suspended by a Task/OsIsr and the Task/OsIsr calls any OS service (excluding the interrupt services) then the Operating System shall ignore the service AND shall return E_OS_DISABLEDINT if the service returns a StatusType value.<br />
|-<br />
| OS054 || OK TriCore<br />
| The Operating System shall ignore calls to ShutdownOS() from non-trusted OS-Applications.<br />
|-<br />
| OS056 || OK TriCore<br />
| If an OS-object identifier is the parameter of a system service, and no sufficient access rights have been assigned at configuration time (Parameter Os[...]AccessingApplication) to the calling Task/Category 2 OsIsr, the system service shall return E_OS_ACCESS.<br />
|-<br />
| OS449 || OK<br />
| CheckTaskMemoryAccess and CheckIsrMemoryAccess check the memory access. Memory access checking is possible for all OS-Applications and from all OS- Applications and does not need granted rights (This is an exception to OS056).<br />
|-<br />
| OS450 || OK<br />
| CheckObjectAccess checks the access rights for OS objects. Checking object access is possible for all OS-Applications and from all OS-Applications and does not need granted rights (This is an exception to OS056).<br />
|-<br />
| OS439 || OK<br />
| The Operating System shall offer the OSEK error macros (OSError...()) to all configured error hooks AND there shall be two (like in OIL) global configuration parameter to switch these macros on or off.<br />
|-<br />
| OS367 || OK<br />
| Operating System services which do not return a StatusType shall not raise the error hook(s).<br />
|-<br />
| OS566 || OK<br />
| The Operating System API shall check in extended mode all pointer argument for NULL pointer and return OS_E_PARAMETER if such argument is NULL.<br />
|}<br />
<br />
= Minor Further Requirements =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS398 || OK<br />
| The OS shall not define the symbol LOCALMESSAGESONLY<br />
|-<br />
| OS242 || No scalability Classes support (But this will be prevented in Any AS configuration)<br />
| The Operating System shall only allow Alarm Callbacks in Scalability Class 1.<br />
|}<br />
<br />
= Memory protection =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS198 || Partial [[#Memory protection notes|<sup>[a]</sup>]]<br />
| The Operating System shall prevent write access to its own data sections and its own stack from non-trusted OS-Applications.<br />
|-<br />
| OS026 || OK (configurable)<br />
| The Operating System may prevent read access to an OS-Application’s data section attempted by other non-trusted OS-Applications.<br />
|-<br />
| OS086 || OK<br />
| The Operating System shall permit an OS-Application read and write access to that OS-Application’s own private data sections.<br />
|-<br />
| OS207 || OK<br />
| The Operating System shall prevent write access to the OS-Application’s private data sections from other non-trusted OS-Applications.<br />
|-<br />
| OS196 || OK<br />
| The Operating System shall permit a Task/Category 2 OsIsr read and write access to that Task’s/Category 2 OsIsr’s own private stack.<br />
|-<br />
| OS208 || OK (not prevented)<br />
| The Operating System may prevent write access to the private stack of Tasks/Category 2 OsIsrs of a non-trusted application from all other Tasks/OsIsrs in the same OS-Application.<br />
|-<br />
| OS355 || OK<br />
| The Operating System shall prevent write access to all private stacks of Tasks/Category 2 OsIsrs of an OS-Application from other non-trusted OS- Applications.<br />
|-<br />
| OS087 || OK<br />
| The Operating System shall permit a Task/Category 2 OsIsr read and write access to that Task’s/Category 2 OsIsr’s own private data sections.<br />
|-<br />
| OS195 || OK (not prevented)<br />
| The Operating System may prevent write access to the private data sections of a Task/Category 2 OsIsr of a non-trusted application from all other Tasks/OsIsrs in the same OS-Application.<br />
|-<br />
| OS356 || OK<br />
| The Operating System shall prevent write access to all private data sections of a Task/Category 2 OsIsr of an OS-Application from other non-trusted OS- Applications.<br />
|-<br />
| OS027 || OK (not protected)<br />
| The Operating System may provide an OS-Application the ability to protect its code sections against executing by non-trusted OS-Applications.<br />
|-<br />
| OS081 || OK (all code is shared)<br />
| The Operating System shall provide the ability to provide shared library code in sections that are executable by all OS-Applications.<br />
|-<br />
| OS209 || OK<br />
| The Operating System shall permit trusted OS-Applications read and write access to peripherals.<br />
|-<br />
| OS083 || Not done [[#Memory protection notes|<sup>[b]</sup>]]<br />
| The Operating System shall allow non-trusted OS-Applications to write to their assigned peripherals only (incl. reads that have the side effect of writing to a memory location).<br />
|-<br />
| OS044 || OK TriCore [[#Memory protection notes|<sup>[c]</sup>]]<br />
| If a memory access violation is detected, the Operating System shall call the Protection Hook with status code E_OS_PROTECTION_MEMORY.<br />
|}<br />
<br />
No timing and memory protection for alarm callbacks.<br />
<br />
== CheckISRMemoryAccess ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS512 || OK<br />
| CheckISRMemoryAccess<br />
|-<br />
| OS267 || OK<br />
| If the ISR reference <ISRID> in a call of CheckISRMemoryAccess() is valid, CheckISRMemoryAccess() shall return the access rights of the ISR on the specified memory area.<br />
|-<br />
| OS313 || OK [[#Memory protection notes|<sup>[d]</sup>]]<br />
| If an access right (e.g. “read”) is not valid for the whole memory area specified in a call of CheckISRMemoryAccess(), CheckISRMemoryAccess() shall yield no access regarding this right.<br />
|-<br />
| OS268 || OK<br />
| If the ISR reference <ISRID> is not valid, CheckISRMemoryAccess() shall yield no access rights.<br />
|-<br />
| OS517 || No scalability Classes support<br />
| Availability of CheckISRMemoryAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
== CheckTaskMemoryAccess ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS513 || OK<br />
| CheckTaskMemoryAccess<br />
|-<br />
| OS269 || OK<br />
| If the Task reference <TaskID> in a call of CheckTaskMemoryAccess() is valid, CheckTaskMemoryAccess() shall return the access rights of the task on the specified memory area.<br />
|-<br />
| OS314 || OK [[#Memory protection notes|<sup>[d]</sup>]]<br />
| If an access right (e.g. “read”) is not valid for the whole memory area specified in a call of CheckTaskMemoryAccess(), CheckTaskMemoryAccess() shall yield no access regarding this right.<br />
|-<br />
| OS270 || OK<br />
| If the Task reference <TaskID> in a call of CheckTaskMemoryAccess() is not valid, CheckTaskMemoryAccess() shall yield no access rights.<br />
|-<br />
| OS518 || No scalability Classes support<br />
| Availability of CheckTaskMemoryAccess(): Available in Scalability Classes 3 and 4<br />
|}<br />
<br />
== Memory protection notes ==<br />
* [a] - The OS shares the stack with tasks and ISRs. If SP is invalid when calling a system API, a fault may happen. If a context change happens inside a system call (e.g., ActivateTask() made on a task with higher priority), data from the OS remain saved on the stack of the calling task; other tasks or ISRs from the same OS-Application can overwrite those values. A solution for this problem is in testing on TriCore implementation, but since the kernel on AURIX never allocate stack (this is due to the special carateristic of TriCore Architecture and the compilers optimizations) the implementation cannot be proved until it will backported on PPC or on a new architecture with this pontential problem.<br />
* [b] - This is tricky. Currently, only trusted OS-Applications can access MCU registers. Probably the granularity of the MMU is not enough, and maybe the MPU is not suitable either.<br />
* [c] - In MPC5674F When a protection error occur, one of the IVOR routines is called, which jump to <code>__empty_handler</code>. In TriCore protection hook will be fully supported.<br />
* [d] - The current implementation is more restrictive. If the given memory range is not contained in a single memory section (e.g., it starts inside the stack section and ends inside BSS), no access is returned. This should not create problems, as crossing sections depends on the memory layout; relying on that would be very fragile and no application should do it.<br />
<br />
= Stack monitoring =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS067 || OK TriCore<br />
| The Operating System shall offer a stack monitoring which detects possible stack faults of Task(s)/Category 2 OsIsr(s).<br />
|-<br />
| OS068 || OK TriCore<br />
| If a stack fault is detected by stack monitoring AND the configured scalability class is 1 or 2, the Operating System shall call the ShutdownOS() service with the status E_OS_STACKFAULT.<br />
|-<br />
| OS396 || OK TriCore<br />
| If a stack fault is detected by stack monitoring AND the configured scalability class is 3 or 4, the Operating System shall call the ProtectionHook() with the status E_OS_STACKFAULT.<br />
|}<br />
<br />
= OS-Applications =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS445 || Partial [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| The Operating System shall support OS-Applications which are a composition of (at least one Task OR OsIsr) AND (zero or more Alarms, Schedule tables, Counters or Resources) AND (zero or one hooks for startup, error and shutdown).<br />
|-<br />
| OS446 || OK<br />
| The Operating System shall support the notion of trusted and not trusted OS-Applications.<br />
|-<br />
| OS464 || OK<br />
| Trusted OS-Applications may offer services (“trusted services”) to other (even non-trusted) OS-Applications.<br />
|-<br />
| OS016 || OK (see GetApplicationID())<br />
| The Operating System shall provide a service to determine the currently running OS-Application (a unique identifier shall be allocated to each application).<br />
|-<br />
| OS017 || OK (see CheckObjectOwnership())<br />
| The Operating System shall provide a service to determine to which OS-Application a given Task, OsIsr, Resource, Counter, Alarm or Schedule Table belongs.<br />
|-<br />
| OS256 || OK (see CheckObjectAccess())<br />
| The Operating System shall provide a service to determine which OS-Applications are allowed to use the IDs of a Task, OsIsr, Resource, Counter, Alarm or Schedule Table in API calls.<br />
|-<br />
| OS258 || OK (see TerminateApplication())<br />
| The Operating System shall provide a service to terminate the OS-Application to which the calling Task/Category 2 OsIsr/application specific error hook belongs. (This is an OS-Application level variant of the TerminateTask() service)<br />
|-<br />
| OS447 || OK<br />
| Terminating an OS-Application means to:<br />
* terminate all running, ready and waiting Tasks/OsIsrs of the OS-Application AND<br />
* disabling all interrupts of the OS-Application AND<br />
* stop all active alarms of the OS-Applications AND<br />
* stop all schedule tables of the OS-Application.<br />
|-<br />
| OS448 || OK TriCore<br />
| OS-Applications, trusted or non-trusted, shall by default have only access rights to objects belonging to this OS-Application. Access rights from other OS-Applications shall be granted explicitely by configuration.<br />
|-<br />
| OS060 || OK TriCore [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| If an application-specific startup hook is configured for an OS-Application <App>, the Operating System shall call StartupHook_<App> on startup of the OS.<br />
|-<br />
| OS110 || OK [[#OS-Applications notes|<sup>[c]</sup>]]<br />
| If the Operating System forcibly terminates an OS-Application, it:<br />
* forcibly terminates all Tasks/OsIsrs of the OS-Application AND<br />
* cancels all alarms of the OS-Application AND<br />
* stops schedule tables of the OS-Application AND<br />
* disables interrupt sources of Category 2 OsIsrs belonging to the OS-Application<br />
|-<br />
| OS111 || OK [[#OS-Applications notes|<sup>[c]</sup>]]<br />
| When the Operating System restarts an OS-Application it activates the configured OsRestartTask.<br />
|}<br />
<br />
== New Autosar API ==<br />
<br />
=== GetApplicationID ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS016 || OK<br />
| GetApplicationID<br />
|-<br />
| OS261 || OK TriCore [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| GetApplicationID() shall return the application identifier to which the executing Task/ISR/hook belongs.<br />
|-<br />
| OS262 || OK<br />
| If no OS-Application is running, GetApplicationID() shall return INVALID_OSAPPLICATION.<br />
|-<br />
| OS514 || No scalability Classes support<br />
| Availability of GetApplicationID(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== CheckObjectAccess ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS256 || OK TriCore<br />
| CheckObjectAccess<br />
|-<br />
| OS271 || OK TriCore<br />
| If the OS-Application <ApplID> in a call of CheckObjectAccess() has access to the queried object, CheckObjectAccess() shall return ACCESS.<br />
|-<br />
| OS272 || OK TriCore<br />
| If the OS-Application <ApplID> in a call of CheckObjectAccess() has no access to the queried object, CheckObjectAccess() shall return NO_ACCESS.<br />
|-<br />
| OS423 || OK TriCore<br />
| If in a call of CheckObjectAccess() the object to be examined is not a valid object OR <ApplID> is invalid OR <ObjectType> is invalid THEN CheckObjectAccess() shall return NO_ACCESS.<br />
|-<br />
| OS519 || No scalability Classes support<br />
| Availability of CheckObjectAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== CheckObjectOwnership ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS017 || OK TriCore<br />
| CheckObjectOwnership<br />
|-<br />
| OS273 || OK TriCore<br />
| If the object ObjectType specified in a call of CheckObjectOwnership() exists, CheckObjectOwnership() shall return the identifier of the OS-Application to which the object belongs.<br />
|-<br />
| OS274 || OK TriCore<br />
| If in a call of CheckObjectOwnership() the specified object ObjectType is invalid OR the argument of the type (the “...”) is invalid, CheckObjectOwnership() shall return INVALID_OSAPPLICATION.<br />
|-<br />
| OS520 || No scalability Classes support<br />
| Availability of CheckObjectOwnership():Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== TerminateApplication ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS258 || OK TriCore<br />
| TerminateApplication<br />
|-<br />
| OS493 || OK TriCore<br />
| If the input parameter <Application> in a call of TerminateApplication() is not valid TerminateApplication() shall return E_OS_ID.<br />
|-<br />
| OS459 || OK TriCore<br />
| If the <RestartOption> in a call of TerminateApplication() is invalid, TerminateApplication() shall return E_OS_VALUE.<br />
|-<br />
| OS494 || OK TriCore<br />
| If the input parameter <Application> in a call of TerminateApplication() is valid AND the caller belongs to a non-trusted OS-Application AND the caller does not belong to <Application> TerminateApplication() shall return E_OS_ACCESS.<br />
|-<br />
| OS507 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_TERMINATED TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS508 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_RESTARTING and the caller does not belong to the <Application> then TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS548 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_RESTARTING AND the caller does belong to the <Application> AND the <RestartOption> is equal RESTART then TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS287 || OK TriCore<br />
| If the parameters in a call of TerminateApplication() are valid and the above criteria are met TerminateApplication() shall terminate <Application> (i.e. to kill all tasks, disable the interrupt sources of those ISRs which belong to the OS-Application and free all other OS resources associated with the application) AND shall activate the configured OsRestartTask of <Application> if <RestartOption> equals RESTART. If the <Application> is restarted, its state is set to APPLICATION_RESTARTING otherwise to APPLICATION_TERMINATED. If the caller belongs to <Application> TerminateApplication() shall not return, otherwise it shall return E_OK.<br />
|-<br />
| OS535 || OK TriCore<br />
| Caveats of TerminateApplication():<br />
* If no applications are configured the implementation shall make sure that this service is not available.<br />
* Tasks and interrupts that are owned by a trusted application can terminate any OS-Application. Tasks and interrupts that are owned by a non-trusted application can only terminate their owning OS-Application.<br />
|-<br />
| OS536 || No scalability Classes support<br />
| Availability of TerminateApplication(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== AllowAccess ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS501 || OK TriCore<br />
| AllowAccess<br />
|-<br />
| OS497 || OK TriCore<br />
| If the state of the OS-Application of the caller of AllowAccess() is not APPLICATION_RESTARTING AllowAccess() shall return E_OS_STATE.<br />
|-<br />
| OS498 || OK TriCore<br />
| If the state of the OS-Application of the caller of AllowAccess() is APPLICATION_RESTARTING, AllowAccess() shall set the state to APPLICATION_ACCESSIBLE and allow other OS-Applications to access the configured objects of the callers OS-Application.<br />
|-<br />
| OS547 || No scalability Classes support<br />
| Availability of AllowAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== GetApplicationState ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS499 || OK TriCore<br />
| GetApplicationState<br />
|-<br />
| OS495 || OK TriCore<br />
| If the <Application> in a call of GetApplicationState() is not valid GetApplicationState() shall return E_OS_ID.<br />
|-<br />
| OS496 || OK TriCore<br />
| If the parameters in a call of GetApplicationState() are valid, GetApplicationState() shall return the state of OS-Application <Application> in <Value>.<br />
|-<br />
| OS537 || No scalability Classes support<br />
| Availability of GetApplicationState(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific StartupHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS539 || OK<br />
| Application specific StartupHook. The application specific StartupHook is always called after the standard StartupHook() (see OS236). If more than one OS-Application is configured which use startup hooks, the order of calls to the startup hooks of the different OS- Applications is not defined.<br />
|-<br />
| OS543 || No scalability Classes support<br />
| Availability of StartupHook_<App>(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific ErrorHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS540 || OK TriCore<br />
| Application specific ErrorHook. If the general ErrorHook() is configured, the general ErrorHook() is called before the application specific error hook is called (see OS246).<br />
|-<br />
| OS544 || OK TriCore<br />
| Availability of ErrorHook_<App>(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific ShutdownHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS541 || OK<br />
| Application specific ShutdownHook. If the general ShutdownHook() is configured, the general ShutdownHook() is called after all application specific shutdown hook(s) are called (see OS237). If more OS-Applications with an application specific shutdown hook exist the order of calls to these application specific shutdown hooks is not defined.<br />
|-<br />
| OS545 || No scalability Classes support<br />
| Availability of ShutdownHook_<App>(): Available in Scalability Classes 3 and 4. <br />
|}<br />
<br />
=== OS-Applications notes ===<br />
* [a] - Application-specific hook will be supported by TriCore full release.<br />
* [b] - Object protection will be introduced by TriCore full release, by now all objects are accessible by any OS-Application.<br />
* [c] - Termination of OS-Applications will be introduced by TriCore full release, is not supported yet.<br />
<br />
== Privileged mode ==<br />
<br />
Please see note [[#Privileged mode notes|<sup>[a]</sup>]].<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS058 || OK<br />
| If supported by hardware, the Operating System shall execute non-trusted OS-Applications in non-privileged mode.<br />
|-<br />
| OS096 || OK<br />
| As far as supported by hardware, the Operating System shall not allow non- trusted OS-Applications to access control registers managed by the Operating System.<br />
|-<br />
| OS245 || OK[[#Privileged mode notes|<sup>[b]</sup>]]<br />
| If an instruction exception occurs (e.g. division by zero) the operating system shall call the protection hook with E_OS_PROTECTION_EXCEPTION.<br />
|-<br />
| OS451 || OK<br />
| The Operating System shall allow to export services from trusted OS-Applications.<br />
|-<br />
| OS097 || OK<br />
| The Operating System shall provide a mechanism to call a trusted function from a (trusted or non-trusted) OS-Application.<br />
|-<br />
| OS100 || OK<br />
| If a called trusted function is not configured the Operating System shall call the ErrorHook with E_OS_SERVICEID.<br />
|-<br />
| OS226 || OK[[#Privileged mode notes|<sup>[b]</sup>]]<br />
| The Operating System shall execute an application-specific startup hook with the access rights of the associated OS-Application.<br />
|}<br />
<br />
=== CallTrustedFunction ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS097 || OK<br />
| CallTrustedFunction<br />
|-<br />
| OS265 || OK<br />
| If <FunctionIndex> is a defined function index, CallTrustedFunction() shall switch the processor into privileged mode AND shall call the function <FunctionIndex> out of a list of implementation specific trusted functions with disabled memory protection AND shall return E_OK after completion.<br />
|-<br />
| OS312 || OK<br />
| Caveats of CallTrustedFunction():<br />
* The called trusted function must conform to the following C prototype: void TRUSTED_<name_of_the_trusted_service>( TrustedFunctionIndexType,TrustedFunctionParameterRefType); (The arguments are the same as the arguments of CallTrustedFunction).<br />
* Normally, a user will not directly call this service, but it will be part of some standard interface, e.g. a standard I/O interface.<br />
* It is the duty of the called trusted function to check rights of passed parameters, especially if parameters are interpreted as out parameters.<br />
* It should be noted that the CallTrustedFunction() does not disable timing protection for the task which called the service. This may lead to timing faults (calls of the ProtectionHook()) even inside of a trusted OS-Application. It is therefore recommended to use CallTrustedFunction() only for stateless functions (e.g. functions which do not write or do not have internal states)<br />
|-<br />
| OS266 || OK [[#Privileged mode notes|<sup>[b]</sup>]]<br />
| When CallTrustedFunction() calls the function <FunctionIndex>, that function shall be executed with the same processor mode and memory protection boundaries as the OS-Application to which it belongs. It shall however retain the timing protection and service protection limitations of the calling Task or ISR, and the notion of "current application" shall remain that of the calling Task or Category 2 ISR.<br />
|-<br />
| OS364 || OK [[#Privileged mode notes|<sup>[b]</sup>]][[#Privileged mode notes|<sup>[c]</sup>]]<br />
| If CallTrustedFunction() calls the trusted function from a Category 2 ISR context, that function shall continue to run on the same interrupt priority and be allowed to call all system services defined for Category 2 ISR (see table in chapter 7.7.3.2).<br />
|-<br />
| OS365 || OK [[#Privileged mode notes|<sup>[b]</sup>]][[#Privileged mode notes|<sup>[c]</sup>]]<br />
| If CallTrustedFunction() calls the trusted function from a task context, that function shall continue to run on the same priority and be allowed to call all system services defined for tasks (see table in chapter 7.7.3.2).<br />
|}<br />
<br />
=== Privileged mode notes ===<br />
: [a] - In MPC5674F priviliged mode is enabled by the SC4 flag (This incomplete support of scalability classes have been removed in TriCore porting).<br />
: [b] - Supported only by TriCore implementation.<br />
: [c] - In MPC5674F a trusted function is executed in the security context of the calling function, although it runs in privileged mode.<br />
<br />
== Protection hook ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS099 || OK (See CheckTaskMemoryAccess() and CheckISRMemoryAccess())<br />
| The Operating System shall offer OS-Applications a service to check if a memory region is write/read/execute accessible from a Task/Category 2 OsIsr and also return information if the memory region is part of the stack space.<br />
|-<br />
| OS211 || OK TriCore<br />
| The Operating System shall execute the ProtectionHook() with the same permissions as the Operating System.<br />
|-<br />
| OS106 || OK TriCore<br />
| The Operating System shall perform one of the following reactions depending on the return value of the ProtectionHook():<br />
* Do nothing<br />
* Forcibly terminate the faulty Task/Category 2 OsIsr OR<br />
* Forcibly terminate the faulty OS-Application OR<br />
* Forcibly terminate the faulty OS-Application and restart the OS-Application. OR<br />
* Call ShutdownOS().<br />
|-<br />
| OS107 || OK TriCore<br />
| If no ProtectionHook() is configured and a protection error occurs, the Operating System shall call ShutdownOS().<br />
|-<br />
| OS475 || OK TriCore<br />
| If the reaction is to do nothing and the ProtectionHook() was not called with E_OS_PROTECTION_ARRIVAL then the Operating System shall call ShutdownOS()<br />
|-<br />
| OS243 || OK TriCore<br />
| If the reaction is to forcibly terminate the Task/Category 2 OsIsr and no Task or OsIsr can be associated with the error, the running OS-Application is forcibly terminated by the Operating System.<br />
|-<br />
| OS244 || OK TriCore<br />
| If the reaction is to forcibly terminate the faulty OS-Application and no OS- Application can be assigned, ShutdownOS()is called.<br />
|-<br />
| OS108 || OK TriCore<br />
| If the Operating System forcibly terminates a task, it terminates the task (no PostTaskHook() for the task will be called), releases all allocated OSEK resources and calls EnableAllInterrupts()/ / ResumeOSInterrupts() ResumeAllInterrupts() if the Task called DisableAllInterrupts() / / SuspendAllInterrupts() before without the SuspendOSInterrupts() EnableAllInterrupts()/ / corresponding ResumeOSInterrupts() ResumeAllInterrupts() call.<br />
|-<br />
| OS109 || OK TriCore<br />
| If the Operating System forcibly terminates an interrupt service routine, it clears the interrupt request, aborts the interrupt service routine (The interrupt source stays in the current state.) and releases all OSEK resources the interrupt service routine has allocated and calls EnableAllInterrupts() / ResumeOSInterrupts() / ResumeAllInterrupts() if the interrupt called DisableAllInterrupts() / / SuspendAllInterrupts() before without the SuspendOSInterrupts() corresponding EnableAllInterrupts()/ / ResumeOSInterrupts() ResumeAllInterrupts() call.<br />
|-<br />
| OS538 || OK TriCore<br />
| Protection Hook Depending on the return value the Operating System module will either:<br />
* forcibly terminate the Task/Category 2 ISR which causes the problem OR<br />
* forcibly terminate the OS-Application the Task/Category 2 ISR belong (optional with restart) OR<br />
* shutdown the system OR<br />
* do nothing (see 7.8.2)<br />
|-<br />
| OS308 || OK TriCore<br />
| If ProtectionHook() returns an invalid value, the Operating System module shall take the same action as if no protection hook is configured.<br />
|-<br />
| OS542 || No scalability Classes support<br />
| Availability of ProtectionHook(): Available in Scalability Classes 2, 3 and 4.<br />
|}<br />
<br />
= Other New Autosar APIs =<br />
<br />
=== GetISRID ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS511 || OK<br />
| GetISRID<br />
|-<br />
| OS263 || OK<br />
| If called from category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID() shall return the identifier of the currently executing ISR.<br />
|-<br />
| OS264 || partial<br />
| If its caller is not a category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID() shall return INVALID_ISR.<br />
|-<br />
| OS515 || OK (?)<br />
| Availability of GetISRID(): Available in all Scalability Classes.<br />
|}<br />
<br />
<br />
= Timing Protection =<br />
<br />
== General Requirement ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS028 || OK, but not Enforced by RT-Druid<br />
| In a non-trusted OS-Application, the Operating System module shall apply timing protection to every Task/Category 2 ISR of this non-trusted OS-Application<br />
|-<br />
| OS089 || OK<br />
| In a trusted OS-Application, the Operating System module shall provide the ability to apply timing protection to Tasks/Category 2 ISRs of this OS-Application.<br />
|-<br />
| OS397 || OK<br />
| If no OS-Application is configured, the Operating System module shall be able to apply timing protection to Tasks/Category 2 ISRs.<br />
|}<br />
<br />
= Multi-Core =<br />
<br />
== Basic Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS567 || OK (We have some doubts relates to this, but it should be OK)<br />
| The generated part of the OS is derived from a single configuration that contains the relevant information for all cores. This implies, that IDs (e.g. TASKID, RESOURCEID, …) are unique across cores. Every ID shall refer exactly to one entity independent from the core on which the entity is accessed. This applies also to objects that cannot be shared between cores. (BSW4080008)<br />
|-<br />
| OS568 || OK<br />
|Implementations shall be able to independently execute a TASK or an ISR on each started AUTOSAR OS core in parallel. (BSW4080001)<br />
|-<br />
| OS569 || OK<br />
|The scheduling strategy as defined in AUTOSAR OS shall apply for each individual core in a Multi-Core system, for the TASKs and ISR assigned to the core. (BSW4080001, BSW4080013)<br />
|-<br />
| OS570 || OK<br />
| All TASKs that are assigned to the same OS-Application shall execute on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS571 || OK<br />
| All ISRs that are assigned to the same OS-Application shall execute on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS572 || N.A. in Supported Architectures (PPC TriCore)<br />
| ISR balancing (if supported by the HW) shall be switched off at boot time by the OS. (BSW4080005, BSW4080006)<br />
|-<br />
| OS764 || No scalability classes support (OS-Applications are enabled when configurated).<br />
| The OS module shall support OS-Applications in case of Multi-Core also for SC1 and SC2.<br />
|-<br />
| OS763 || No scalability classes support (But we don't understend this requirement).<br />
| In an SC1 system standard mode shall be possible.<br />
|-<br />
| OS573 ||<br />
| The binding of OS-Applications to cores shall be configured within the OS-Application container. A new configuration item: OsApplicationCoreAssignment{CORE} within the OS-Application container shall be used to define the core to which the OS-Application is bound. The OS generator will map the configuration parameter “CORE” to a certain core, so that all OS-Applications with the same configuration parameter reside on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS623 || OK<br />
| The OS API function CallTrustedFunction shall return E_OS_ACCESS in extended status if the target trusted function is part of an OS-Application on another core. (BSW4080013)<br />
|-<br />
|}<br />
<br />
== Multi-Core start-up Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS574 || OK<br />
| The master core shall be able to activate cores. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS575 || OK<br />
| Any slave core shall be able to activate cores. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS576 || OK<br />
| It shall be allowed to use only a subset of the cores available on a μC for the AUTOSAR system. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS577 || OK (TriCore e PPC e200zx are naturally in Master-Slave configuration)<br />
| The cores shall boot in master-slave mode. If this is not supported by the hardware, it shall be that the cores boot in parallel and emulate the behavior of a master-slave system.. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS578 || N.A.<br />
| In case of an emulation a slave core (CoreS), which is controlled by the AUTOSAR OS (AUTOSAR core), shall not enter the main function before another<br />
core has activated the slave core by means of StartCore(CoreS). (BSW4080006)<br />
|-<br />
| OS579 || OK<br />
| All cores that belong to the AUTOSAR system shall be synchronized within the StartOS function before the scheduling is started and after the global<br />
StartupHook is called.. (BSW4080001, BSW4080006)<br />
|-<br />
| OS580 || OK<br />
| All cores that belong to the AUTOSAR system shall be synchronized within the StartOS function before the scheduling is started and after the global<br />
StartupHook is called.. (BSW4080006)<br />
|-<br />
| OS581 || OK TriCore<br />
| The global StartupHook shall be called on all cores immediately after the first synchronisation point (BSW4080006)<br />
|-<br />
| OS582 || OK TriCore<br />
| The OS-Application-specific StartupHooks shall be called after the global StartupHook but only on the cores to which the OS-Application is bound (BSW4080006, BSW4080008)<br />
|-<br />
| || OK TriCore<br />
| The AUTOSAR OS API provides a StartCore function to start the cores under its control. The StartCore function takes a scalar value parameter of type CoreIDType, specifying the core that shall be started. StartCore can be called more than once on the master core and also on slave cores. Each core can only be started once, however The StartOS function shall be called on all cores that have been activated by StartCore. It is not allowed to call StartCore from a core that has already called StartOS. Cores that belong to the AUTOSAR system shall be started by the designated AUTOSAR OS API service StartCore.<br />
|-<br />
| OS583 || OK TriCore<br />
| The number of cores that can be controlled by the AUTOSAR OS shall be configured offline. A new configuration item (OsNumberOfCores) within the “OsOS” container is used to specify the maximum number of cores that are controlled by the AUTOSAR OS. If no value for (OsNumberOfCores) has been specified the number of cores shall be one. (BSW4080001, BSW4080011) <br />
|-<br />
| OS584 || OK TriCore<br />
| The AUTOSAR OS shall provide a function called StartNonAutosarCore that can be used to start cores, which are not controlled by the AUTOSAR OS. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS585 || OK TriCore<br />
| It shall be possible to activate cores that are not controlled by the AUTOSAR OS before and after calling StartOS. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS606 || OK TriCore<br />
| The AUTOSAR specification does not support the activation of AUTOSAR cores after calling StartOS on that core. If StartCore is called after StartOS it shall return with E_OS_ACCESS in extended status. (BSW4080001)<br />
|-<br />
| OS607 || OK TriCore<br />
| StartOS shall start the OS on the core on which it is called. (BSW4080006, BSW4080013)<br />
|-<br />
| OS608 || OK TriCore<br />
| If more than one core calls StartOS with an AppMode other than “DONOTCARE”, the AppModes shall be the same. StartOS shall check this at the first synchronisation point. In case of violation, StartOS shall not start the scheduling, shall not call any StartupHooks, and shall enter an endless loop on every core. (BSW4080006)<br />
|-<br />
| OS609 || OK TriCore<br />
| If StartOS is called with the AppMode “DONOTCARE” the application mode of the other core(s) (differing from “DONOTCARE”) shall be used. (BSW4080006)<br />
|-<br />
| OS610 || OK TriCore<br />
| At least one core shall define an AppMode other than “DONOTCARE”. (BSW4080006)<br />
|-<br />
| OS611 || OK TriCore<br />
| If the IOC is configured, StartOS shall initialize the data structures of the IOC. (BSW4080020)<br />
|-<br />
| OS668 || OK<br />
| The AUTOSAR Operating System shall automatically activate all auto-start TASKs configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
| OS669 || OK<br />
| The AUTOSAR Operating System shall automatically activate all auto-start ALARMs configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
| OS670 || Not Schedule tables supported yet<br />
| The AUTOSAR Operating System shall automatically activate all auto-start schedule tables configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
|}<br />
<br />
== Multicore Shutdown Requirements ==<br />
<br />
AUTOSAR supports two shutdown concepts, the synchronized shutdown and the individual shutdown concept. While the synchronized shutdown is triggered by the new API function '''ShutdownAllCores()''', the individual shutdown is invoked by the existing API function '''ShutdownOS()'''.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS586 || OK TriCore<br />
| During the shutdown, the OS-Application specific ShutdownHook shall be called on the core on which the corresponding OS-Application is bound. (BSW4080007)<br />
|- <br />
| OS587 || OK TriCore (if ShutdownAllCores has been called)<br />
| Before calling the global ShutdownHook, all cores shall be synchronized. (BSW4080007)<br />
|- <br />
| OS588 || OK<br />
| The global ShutdownHook shall be called on all cores. (BSW4080007)<br />
|-<br />
| OS762 || OK TriCore (fullfilled by ProtectionHook implementation)<br />
| In cases where the OS detects a fatal internal error all cores shall be shutdown.<br />
|-<br />
| OS616 || OK<br />
| ShutdownOS shall be callable from each core running an AUTOSAR OS. (BSW4080001, BSW4080007)<br />
|-<br />
| OS617 || OK<br />
| ShutdownOS shall shutdown the core on which it was called. (BSW4080007)<br />
|-<br />
| OS618 || OK<br />
| The OS shall not start TASKs of an OS-Application once the shutdown procedure has been entered on a particular core. (BSW4080013)<br />
|-<br />
| OS619 || OK<br />
| The AUTOSAR OS function ShutdownOS shall be callable in parallel on multiple cores. (BSW4080013)<br />
|-<br />
| OS620 || OK TriCore<br />
| ShutdownOS shall release all spinlocks which are occupied by the calling core. (BSW4080021)<br />
|-<br />
| OS621 || OK TriCore<br />
| ShutdownAllCores shall be callable from each core running an AUTOSAR OS. (BSW4080007)<br />
|-<br />
|}<br />
<br />
== OS Other Services Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS589 || OK TriCore<br />
| All functions that are not allowed to operate cross core shall return E_OS_CORE in extended status if called with parameters that require a cross core operation. (BSW4080013)<br />
|-<br />
| OS590 || OK<br />
| The OS service “DisableAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS591 || OK<br />
| The OS service “EnableAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS592 || OK<br />
| The OS service “SuspendAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS593 || OK<br />
| The OS service “ResumeAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS594 || OK<br />
| The OS service “SuspendOSInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS595 || OK<br />
| The OS service “ResumeOSInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS596 || OK<br />
| It shall be possible to activate a TASK that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080001, BSW4080015)<br />
|-<br />
| OS598 || OK TriCore (RPC Dispactcher)<br />
| The call of ActivateTask across cores shall behave synchronously, i.e. a call returns after the task has been activated or an error has been detected. It shall not be possible to continue execution on the calling core before ActivateTask is accomplished on the remote core. (BSW4080015)<br />
|-<br />
| OS599 || OK TriCore (RPC Dispactcher)<br />
| In case of an error when calling ActivateTask across cores, the error handler shall be called on the core on which ActivateTask was originally called. (BSW4080015)<br />
|-<br />
| OS600 || OK<br />
| It shall be possible to chain a TASK that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080001, BSW4080015)<br />
|-<br />
| OS602 || OK<br />
| It shall be possible to set an EVENT that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080016)<br />
|-<br />
| OS604 || OK TriCore (RPC Dispactcher)<br />
| The call of SetEvent across cores shall behave synchronously, i.e. a call returns after the Event has been set or an error has been detected. It shall not be possible to continue execution on the calling core before SetEvent is accomplished on the remote core. (BSW4080016)<br />
|-<br />
| OS605 || OK TriCore (RPC Dispactcher [[#MultiCore notes|<sup>[a]</sup>]])<br />
| In case of an error when calling SetEvent across cores, the error handler shall be called on the core on which SetEvent was originally called. (BSW4080016)<br />
|-<br />
| OS612 || OK TriCore<br />
| In extended status TerminateTask / ChainTask shall return with an error (E_OS_SPINLOCK), which can be evaluated in the application. (BSW4080021)<br />
|-<br />
| OS613 || OK TriCore<br />
| Spinlocks occupied by TASKS that are terminated in response to a protection hook shall be automatically released. This applies also to the case in which an OS-Application is terminated. (BSW4080021)<br />
|-<br />
| OS614 || OK TriCore<br />
| TerminateApplication shall check if any of the TASKs in the OS-Application have occupied a spinlock. If so, the spinlocks shall be released.(BSW4080021)<br />
|-<br />
| OS615 ||<br />
| If TerminateApplication(A) is called in parallel from different cores, the OsApplication “A” is terminated by the first call, any subsequent calls will return with 'E_OK' in standard and extended status without doing anything, until the termination is completed.<br />
|-<br />
| OS622 || OK<br />
| The AUTOSAR Operating System WaitEvent API service shall check if it has been called while the calling TASK has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the TASK shall not enter the wait state. (BSW4080021)<br />
|-<br />
| OS624 || OK<br />
| The AUTOSAR Operating System Schedule API service shall check if it has been called while the calling TASK has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the scheduler shall not be called. (BSW4080021)<br />
|-<br />
| OS629 || OK<br />
| A COUNTER belonging to an OS-Application shall be incremented by the core on which the OS-Application resides. The COUNTER shall not be incremented by other cores. (BSW4080013)<br />
|-<br />
| OS630 || OK<br />
| It shall not be allowed to drive a schedule table from a COUNTER, which is assigned to a different core. (BSW4080013)<br />
|-<br />
| OS631 || OK<br />
| It shall not be allowed to drive an ALARM from a COUNTER, which is assigned to a different core. (BSW4080013)<br />
|-<br />
| OS632 || OK<br />
| If an ALARM expires, it shall be allowed to activate a TASK on a different core. (BSW4080018)<br />
|-<br />
| OS633 || OK<br />
| If an ALARM expires, it shall be allowed to set an EVENT on a different core. (BSW4080018)<br />
|-<br />
| OS634 || OK<br />
| The AUTOSAR Operating System shall process an ALARM on the core on which its corresponding OS-Application resides. (BSW4080018)<br />
|-<br />
| OS635 || OK<br />
| ALARM callbacks shall be executed on the core to which the ALARM is bound. This is only applicable to SC1 systems, because otherwise Alarm Callback<br />
are not allowed (OS242). (BSW4080013)<br />
|-<br />
| OS636 || OK<br />
| SetRelAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|-<br />
| OS637 || OK<br />
| SetAbsAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS638 || OK<br />
| CancelAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS639 || OK<br />
| GetAlarmBase shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS640 || OK<br />
| GetAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
|}<br />
<br />
== MultiCore notes ==<br />
: [a] - [[Infineon_Aurix#Multicore_Autosar_OS_Support|New RPC MultiCore dispatcher]]<br />
<br />
== Other AUTOSAR Multicore API ==<br />
<br />
=== GetCoreID ===<br />
<br />
Every HW assigns a unique physical Id to a core. The physical core Id is the only way to distinguish between cores. <br />
The physical core Ids of a μC are not necessarily consecutive and do not necessarily start with zero.<br />
The SW requires a mechanism to identify a core, e.g. to use core specific variables. Because the physical core Id usually can not be used as a direct array index for core specific variables, a logical CoreID is necessary to map physical core Ids to array indexes. In the SW it is not necessary to know the physical core Id, the logical CoreID is sufficient.<br />
The mapping of OSApplications and other SW objects to cores is specified in the configuration files. All such mappings shall be HW independent and therefore shall not be based on the physical core Id but on the logical CoreID. The function GetCoreID internally maps the physical core Id to the logical CoreID. The mapping is implementation specific. GetCoreID can be either a C function or a macro.<br />
<br />
'''N.B''' In Erika with code replication the core ID is not a real issue.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS625 || OK TriCore<br />
| The AUTOSAR Operating System API function GetCoreID shall be callable before StartOS. (BSW4080006)<br />
|-<br />
| OS626 || OK TriCore<br />
| An implementation shall offer a function GetNumberOfActivatedCores that returns the number of cores running the AUTOSAR OS. (BSW4080001)<br />
|-<br />
| OS627 || OK TriCore<br />
| An implementation shall define a set of constants OS_CORE_ID_<No> of the type CoreIDType with <No> a value from 0 to “OsNumberOfCores -1. (BSW4080001)<br />
|-<br />
| OS628 || OK TriCore<br />
| An implementation shall offer a constant OS_CORE_ID_MASTER of the type CoreIDType that refers to the master core. (BSW4080001)<br />
|}<br />
<br />
== Spinlocks ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS648 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a spinlock mechanism that works across cores. (BSW4080018, BSW4080021)<br />
|-<br />
| OS649 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a GetSpinlock function which occupies a spinlock. If the spinlock is already occupied, GetSpinlock shall<br />
keep on trying to occupy the spinlock until it succeeds. (BSW4080018, BSW4080021)<br />
|-<br />
| OS650 || OK TriCore<br />
| GetSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS651 || OK TriCore<br />
| GetSpinlock shall be callable from ISR2 level. The behavior of GetSpinlock is undefined if called from a category 1 ISR. (BSW4080021)<br />
|-<br />
| OS652 || OK TriCore (With Trivial spinlocks)<br />
| The AUTOSAR Operating System shall provide a TryToGetSpinlock function which occupies a spinlock. If the spinlock is already occupied by a TASK,<br />
TryToGetSpinlock shall return. (BSW4080018, BSW4080021)<br />
|-<br />
| OS653 || OK TriCore<br />
| TryToGetSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS654 || OK TriCore<br />
| TryToGetSpinlock shall be callable from ISR2 level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS655 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a ReleaseSpinlock function which releases an occupied spinlock. If the spinlock is not occupied an error<br />
shall be returned. (BSW4080018, BSW4080021)<br />
|-<br />
| OS656 || OK TriCore<br />
| ReleaseSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS657 || OK TriCore<br />
| ReleaseSpinlock shall be callable from ISR2 level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS658 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if a TASK tries to occupy a spinlock that is assigned to a TASK/ISR2 on the same core (including<br />
itself). (BSW4080018, BSW4080021)<br />
|-<br />
| OS659 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if an ISR2 tries to occupy a spinlock that is assigned to a TASK/ISR2 on the same core.<br />
(BSW4080018, BSW4080021)<br />
|-<br />
| OS660 || OK TriCore<br />
| A unique order in which multiple spinlocks can be occupied by a TASK/ISR2 should be configurable in the AUTOSAR Operating System. This might<br />
be realized by the configuration item (OsSpinlockSuccessor{NEXT_SPINLOCK}) where “NEXT_SPINLOCK” refers to the consecutive spinlock. (See chapter 10.2.5) (BSW4080018, BSW4080021)<br />
|-<br />
| OS661 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if a TASK/ISR2 that currently holds a spinlock tries to seize another spinlock that has not been<br />
configured as a direct or indirect successor of the latest acquired spinlock (by means of the OsSpinlockSuccessor configuration parameter) or if no successor is configured. (BSW4080018, BSW4080021)<br />
|-<br />
|}<br />
<br />
= Inter-OS-Application Communicator (IOC) Requirements =<br />
<br />
IOC stands for Inter OS-Application Communicator. The "IOC" is responsible for the communication between OS-Applications and in<br />
particular for the communication crossing core or memory protection boundaries. It's internal functionality is closely connected to the Operating System.<br />
<br />
Memory protection boundaries are a characteristic of OS-Applications and special communication mechanisms are needed to cross them.<br />
Multi-Core systems may also need additional measures to make communication between cores safe.<br />
<br />
The IOC provides communication services between OS-Applications and in particular over core boundaries in Multi-Core systems. Because the cross-core communication is always an inter-OS-Application communication, the two mechanisms are combined. An inter OS-Application communication may not necessarily require a cross core communication, however.<br />
<br />
In systems with only one core, the IOC can be omitted completely, if just one OS-Application is available, or if no OS-Application uses memory protection mechanisms.<br />
<br />
'''N.B''' Since a lot of Code of IOC is configurated and generated starting from RTE configuration, it doesn't make sense generate a whole IOC system without a complete RTE generator. But '''we choiced the cross-boundaries communication mechanism''' that is the heart of IOC. The same mechanism is employed to implement OS Services remote invocation.<br />
<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS671 ||<br />
| The IOC implementation shall be part of the Operating System The IOC is a third type of communication, in addition to:<br />
* Intra OS-Application communication: Always handled within the RTE<br />
* Inter ECU communication: already available via well defined interfaces to the communication stack (COM).<br />
(BSW4080020)<br />
|-<br />
|}</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=ERIKA_%26_Autosar_OS_RequirementsERIKA & Autosar OS Requirements2016-09-21T16:40:57Z<p>Eguidieri: /* Memory protection */</p>
<hr />
<div>= Introduction =<br />
Erika Enterprise is the first open-source Free RTOS that has been certified OSEK/VDX compliant and it's under current developtment to fulfil Autosar 4 OS Requirements too. In the following table are logged the AUTOSAR requirements already implemneted in ERIKA.<br />
<br />
* All the requirement tagged as OK are implemented in all supported Architectures.<br />
* All the requirements related to '''memory protection''' are available only for those MCU that have memory protection implmentented: currently only support for Freescale MPC5674F has been released.<br />
* All the requirements tagged as TriCore are implemented but will be realesed when the full support for TriCore AURIX will be released.<br />
<br />
Scalability Classes are not implemented yet, but each feature/API is activated only if required by the configuration.<br />
<br />
= Tasks =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS052 || OK<br />
| If a task returns from its entry function without making a TerminateTask() or ChainTask() call, the Operating System shall terminate the task (and call the PostTaskHook() if configured).<br />
|-<br />
| OS069 || OK<br />
| If a task returns from its entry function without making a TerminateTask() or ChainTask() call AND the error hook is configured, the Operating System shall call the ErrorHook() (this is done regardless of whether the task causes other errors, e.g. E_OS_RESOURCE) with status E_OS_MISSINGEND before the task leaves the RUNNING state.<br />
|-<br />
| OS070 || OK<br />
| If a task returns from the entry function without making a TerminateTask() or ChainTask() call and still holds OSEK Resources, the Operating System shall release them.<br />
|-<br />
| OS239 || OK<br />
| If a task returns from the entry function without making a TerminateTask() or ChainTask() call and interrupts are still disabled, the Operating System shall enable them.<br />
|-<br />
| OS071 || OK<br />
| If the PostTaskHook() is configured, the Operating System shall not call the hook if ShutdownOS() is called.<br />
|}<br />
<br />
= ISR2s =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS368 || OK<br />
| If a Category 2 OsIsr calls DisableAllInterupts() SuspendAllInterrupts() / SuspendOSInterrupts() and ends (returns) without calling the corresponding EnableAllInterrupts() / ResumeAllInterrupts() / ResumeOSInterrupts(), the Operating System shall perform the missing service and shall call the ErrorHook() (if configured) with the status E_OS_DISABLEDINT.<br />
|-<br />
| OS369 || OK<br />
| If a Category 2 OsIsr calls GetResource() and ends (returns) without calling the corresponding ReleaseResource(), the Operating System shall perform the ReleaseResource() call and shall call the ErrorHook() (if configured) with the status E_OS_RESOURCE.<br />
|}<br />
<br />
= Hooks =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS236 || OK TriCore<br />
| If both a system-specific and one (or more) application specific startup hook(s) are configured, the Operating System shall call the system-specific startup hook before the application-specific startup hook(s).<br />
|-<br />
| OS112 || OK TriCore<br />
| If an application-specific shutdown hook is configured for an OS-Application <App>, the Operating System shall call ShutdownHook_<App> on shutdown of the OS.<br />
|-<br />
| OS225 || OK TriCore<br />
| The Operating System shall execute an application-specific shutdown hook with the access rights of the associated OS-Application.<br />
|-<br />
| OS237 || OK TriCore<br />
| If both a system-specific and one (or more) application specific shutdown hook(s) are configured, the Operating System shall call the system-specific shutdown hook after the application-specific shutdown hook(s).<br />
|-<br />
| OS246 || OK TriCore<br />
| When an error occurs AND an application-specific error hook is configured for the faulty OS-Application <App>, the Operating System shall call that application- specific error hook ErrorHook_<App> after the system specific error hook is called (if configured).<br />
|-<br />
| OS085 || OK TriCore<br />
| The Operating System shall execute an application-specific error hook with the access rights of the associated OS-Application.<br />
|}<br />
<br />
= Timers and Counters =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS301 || OK<br />
| The Operating System shall provide the ability to increment a software counter as an alternative action on alarm expiry.<br />
|-<br />
| OS399 || OK<br />
| The OS shall provide an API call to increment a software counter.<br />
|-<br />
| OS374 || OK<br />
| The Operating System shall handle all the initialization and configuration of timers used directly by the OS and not handled by the GPT driver.<br />
|-<br />
| OS383 || OK (partials)<br />
| The Operating System shall provide a service to read the current count value of a counter (returning either the hardware timer ticks if counter is driven by hardware or the software ticks when user drives counter).<br />
|-<br />
| OS392 || OK<br />
| The Operating System shall provide a service to get the number of ticks between the current tick value and a previously read tick value.<br />
|-<br />
| OS384 ||<br />
| The Operating System shall adjust the read out values of hardware timers (which drive counters) in such that the lowest value is zero and consecutive reads return an increasing count value until the timer wraps at its modulus.<br />
|}<br />
<br />
== Autosar New API for Timers and Counters ==<br />
<br />
=== IncrementCounter ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS399 || OK<br />
| IncrementCounter<br />
|-<br />
| OS285 || OK<br />
| If the input parameter <CounterID> in a call of IncrementCounter() is not valid OR the counter is a hardware counter, IncrementCounter() shall return E_OS_ID.<br />
|-<br />
| OS286 || OK<br />
| If the input parameter of IncrementCounter() is valid, IncrementCounter() shall increment the counter <CounterID> by one (if any alarm connected to this counter expires, the given action, e.g. task activation, is done) and shall return E_OK.<br />
|-<br />
| OS321 || OK<br />
| If in a call of IncrementCounter() an error happens during the execution of an alarm action, e.g. E_OS_LIMIT caused by a task activation, IncrementCounter() shall call the error hook(s), but the IncrementCounter() service itself shall return E_OK.<br />
|-<br />
| OS529 || OK<br />
| Caveats of IncrementCounter(): If called from a task, rescheduling may take place.<br />
|-<br />
| OS530 || OK<br />
| Availability of IncrementCounter(): Available in all Scalability Classes.<br />
|}<br />
<br />
=== GetCounterValue ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS383 || OK<br />
| GetCounterValue<br />
|-<br />
| OS376 || OK<br />
| If the input parameter <CounterID> in a call of GetCounterValue() is not valid, GetCounterValue() shall return E_OS_ID.<br />
|-<br />
| OS377 || OK<br />
| If the input parameter <CounterID> in a call of GetCounterValue() is valid, GetCounterValue() shall return the current tick value of the counter via <Value> and return E_OK.<br />
|-<br />
| OS531 || OK (partials)<br />
| Caveats of GetCounterValue(): Note that for counters of OsCounterType = HARDWARE the real timer value (the – possibly adjusted – hardware value, see OS384) is returned, whereas for counters of OsCounterType = SOFTWARE the current “software” tick value is returned.<br />
|-<br />
| OS532 || OK<br />
| Availability of GetCounterValue(): Available in all Scalability Classes.<br />
|}<br />
<br />
=== GetElapsedValue ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS392 || OK<br />
| GetElapsedValue<br />
|-<br />
| OS381 || OK<br />
| If the input parameter <CounterID> in a call of GetElapsedValue() is not valid GetElapsedValue() shall return E_OS_ID.<br />
|-<br />
| OS391 || OK<br />
| If the <Value> in a call of GetElapsedValue() is larger than the max allowed value of the <CounterID>, GetElapsedValue() shall return E_OS_VALUE.<br />
|-<br />
| OS382 || OK<br />
| If the input parameters in a call of GetElapsedValue() are valid, GetElapsedValue() shall return the number of elapsed ticks since the given <Value> value via <ElapsedValue> and shall return E_OK.<br />
|-<br />
| OS460 || OK<br />
| GetElapsedValue() shall return the current tick value of the counter in the <Value> parameter.<br />
|-<br />
| OS533 || OK<br />
| Caveats of GetCounterValue():If the timer already passed the <Value> value a second (or multiple) time, the result returned is wrong. The reason is that the service can not detect such a relative overflow.<br />
|-<br />
| OS534 || OK<br />
| Availability of GetCounterValue(): Available in all Scalability Classes.<br />
|}<br />
<br />
== OSEK Requirements Extensions ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS304 || OK<br />
| If in a call to SetRelAlarm() the parameter “increment” is set to zero, the service shall return E_OS_VALUE in standard and extended status .<br />
|-<br />
| OS424 || OK<br />
| The first call to StartOS() (for starting the Operating System) shall not return.<br />
|-<br />
| OS425 || OK<br />
| If ShutdownOS() is called and ShutdownHook() returns then the operating system shall disable all interrupts and enter an endless loop.<br />
|-<br />
| OS299 || OK<br />
|The Operating System shall provide the services DisableAllInterrupts(), EnableAllInterrupts(), SuspendAllInterrupts(), ResumeAllInterrupts() prior to calling StartOS() and after calling ShutdownOS(). (It is assumed that the static variables of these functions are initialized).<br />
|-<br />
| OS051 || OK TriCore<br />
| If an invalid address (address is not writable by this OS-Application) is passed as an out-parameter to an OS service, the Operating System shall return the status code E_OS_ILLEGAL_ADDRESS.<br />
|-<br />
| OS088 || OK TriCore<br />
| If an OS-Application makes a service call from the wrong context AND is currently not inside a Category 1 OsIsr the Operating System shall not perform the requested action (the service call shall have no effect), and return E_OS_CALLEVEL or the “invalid value” of the service.<br />
|-<br />
| OS092 || OK<br />
| If EnableAllInterrupts() ResumeAllInterrupts() / ResumeOSInterrupts() are called and no corresponding DisableAllInterupts() / SuspendAllInterrupts() / SuspendOSInterrupts() was done before, the Operating System shall not perform this OS service.<br />
|-<br />
| OS093 || OK<br />
| If interrupts are disabled/suspended by a Task/OsIsr and the Task/OsIsr calls any OS service (excluding the interrupt services) then the Operating System shall ignore the service AND shall return E_OS_DISABLEDINT if the service returns a StatusType value.<br />
|-<br />
| OS054 || OK TriCore<br />
| The Operating System shall ignore calls to ShutdownOS() from non-trusted OS-Applications.<br />
|-<br />
| OS056 || OK TriCore<br />
| If an OS-object identifier is the parameter of a system service, and no sufficient access rights have been assigned at configuration time (Parameter Os[...]AccessingApplication) to the calling Task/Category 2 OsIsr, the system service shall return E_OS_ACCESS.<br />
|-<br />
| OS449 || OK<br />
| CheckTaskMemoryAccess and CheckIsrMemoryAccess check the memory access. Memory access checking is possible for all OS-Applications and from all OS- Applications and does not need granted rights (This is an exception to OS056).<br />
|-<br />
| OS450 || OK<br />
| CheckObjectAccess checks the access rights for OS objects. Checking object access is possible for all OS-Applications and from all OS-Applications and does not need granted rights (This is an exception to OS056).<br />
|-<br />
| OS439 || OK<br />
| The Operating System shall offer the OSEK error macros (OSError...()) to all configured error hooks AND there shall be two (like in OIL) global configuration parameter to switch these macros on or off.<br />
|-<br />
| OS367 || OK<br />
| Operating System services which do not return a StatusType shall not raise the error hook(s).<br />
|-<br />
| OS566 || OK<br />
| The Operating System API shall check in extended mode all pointer argument for NULL pointer and return OS_E_PARAMETER if such argument is NULL.<br />
|}<br />
<br />
= Minor Further Requirements =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS398 || OK<br />
| The OS shall not define the symbol LOCALMESSAGESONLY<br />
|-<br />
| OS242 || No scalability Classes support (But this will be prevented in Any AS configuration)<br />
| The Operating System shall only allow Alarm Callbacks in Scalability Class 1.<br />
|}<br />
<br />
= Memory protection =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS198 || Partial [[#Memory protection notes|<sup>[a]</sup>]]<br />
| The Operating System shall prevent write access to its own data sections and its own stack from non-trusted OS-Applications.<br />
|-<br />
| OS026 || OK (configurable)<br />
| The Operating System may prevent read access to an OS-Application’s data section attempted by other non-trusted OS-Applications.<br />
|-<br />
| OS086 || OK<br />
| The Operating System shall permit an OS-Application read and write access to that OS-Application’s own private data sections.<br />
|-<br />
| OS207 || OK<br />
| The Operating System shall prevent write access to the OS-Application’s private data sections from other non-trusted OS-Applications.<br />
|-<br />
| OS196 || OK<br />
| The Operating System shall permit a Task/Category 2 OsIsr read and write access to that Task’s/Category 2 OsIsr’s own private stack.<br />
|-<br />
| OS208 || OK (not prevented)<br />
| The Operating System may prevent write access to the private stack of Tasks/Category 2 OsIsrs of a non-trusted application from all other Tasks/OsIsrs in the same OS-Application.<br />
|-<br />
| OS355 || OK<br />
| The Operating System shall prevent write access to all private stacks of Tasks/Category 2 OsIsrs of an OS-Application from other non-trusted OS- Applications.<br />
|-<br />
| OS087 || OK<br />
| The Operating System shall permit a Task/Category 2 OsIsr read and write access to that Task’s/Category 2 OsIsr’s own private data sections.<br />
|-<br />
| OS195 || OK (not prevented)<br />
| The Operating System may prevent write access to the private data sections of a Task/Category 2 OsIsr of a non-trusted application from all other Tasks/OsIsrs in the same OS-Application.<br />
|-<br />
| OS356 || OK<br />
| The Operating System shall prevent write access to all private data sections of a Task/Category 2 OsIsr of an OS-Application from other non-trusted OS- Applications.<br />
|-<br />
| OS027 || OK (not protected)<br />
| The Operating System may provide an OS-Application the ability to protect its code sections against executing by non-trusted OS-Applications.<br />
|-<br />
| OS081 || OK (all code is shared)<br />
| The Operating System shall provide the ability to provide shared library code in sections that are executable by all OS-Applications.<br />
|-<br />
| OS209 || OK<br />
| The Operating System shall permit trusted OS-Applications read and write access to peripherals.<br />
|-<br />
| OS083 || Not done [[#Memory protection notes|<sup>[b]</sup>]]<br />
| The Operating System shall allow non-trusted OS-Applications to write to their assigned peripherals only (incl. reads that have the side effect of writing to a memory location).<br />
|-<br />
| OS044 || OK TriCore [[#Memory protection notes|<sup>[c]</sup>]]<br />
| If a memory access violation is detected, the Operating System shall call the Protection Hook with status code E_OS_PROTECTION_MEMORY.<br />
|}<br />
<br />
No timing and memory protection for alarm callbacks.<br />
<br />
== CheckISRMemoryAccess ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS512 || OK<br />
| CheckISRMemoryAccess<br />
|-<br />
| OS267 || OK<br />
| If the ISR reference <ISRID> in a call of CheckISRMemoryAccess() is valid, CheckISRMemoryAccess() shall return the access rights of the ISR on the specified memory area.<br />
|-<br />
| OS313 || OK [[#Memory protection notes|<sup>[d]</sup>]]<br />
| If an access right (e.g. “read”) is not valid for the whole memory area specified in a call of CheckISRMemoryAccess(), CheckISRMemoryAccess() shall yield no access regarding this right.<br />
|-<br />
| OS268 || OK<br />
| If the ISR reference <ISRID> is not valid, CheckISRMemoryAccess() shall yield no access rights.<br />
|-<br />
| OS517 || No scalability Classes support<br />
| Availability of CheckISRMemoryAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
== CheckTaskMemoryAccess ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS513 || OK<br />
| CheckTaskMemoryAccess<br />
|-<br />
| OS269 || OK<br />
| If the Task reference <TaskID> in a call of CheckTaskMemoryAccess() is valid, CheckTaskMemoryAccess() shall return the access rights of the task on the specified memory area.<br />
|-<br />
| OS314 || OK [[#Memory protection notes|<sup>[d]</sup>]]<br />
| If an access right (e.g. “read”) is not valid for the whole memory area specified in a call of CheckTaskMemoryAccess(), CheckTaskMemoryAccess() shall yield no access regarding this right.<br />
|-<br />
| OS270 || OK<br />
| If the Task reference <TaskID> in a call of CheckTaskMemoryAccess() is not valid, CheckTaskMemoryAccess() shall yield no access rights.<br />
|-<br />
| OS518 || No scalability Classes support<br />
| Availability of CheckTaskMemoryAccess(): Available in Scalability Classes 3 and 4<br />
|}<br />
<br />
== Memory protection notes ==<br />
* [a] - The OS shares the stack with tasks and ISRs. If SP is invalid when calling a system API, a fault may happen. If a context change happens inside a system call (e.g., ActivateTask() made on a task with higher priority), data from the OS remain saved on the stack of the calling task; other tasks or ISRs from the same OS-Application can overwrite those values. A solution for this problem is in testing on TriCore implementation, but since the kernel on AURIX never allocate stack (this is due to the special carateristic of TriCore Architecture and the compilers optimizations) the implementation cannot be proved until it will backported on PPC or on a new architecture with this pontential problem.<br />
* [b] - This is tricky. Currently, only trusted OS-Applications can access MCU registers. Probably the granularity of the MMU is not enough, and maybe the MPU is not suitable either.<br />
* [c] - In MPC5674F When a protection error occur, one of the IVOR routines is called, which jump to <code>__empty_handler</code>. In TriCore protection hook will be fully supported.<br />
* [d] - The current implementation is more restrictive. If the given memory range is not contained in a single memory section (e.g., it starts inside the stack section and ends inside BSS), no access is returned. This should not create problems, as crossing sections depends on the memory layout; relying on that would be very fragile and no application should do it.<br />
<br />
= Stack monitoring =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS067 || OK TriCore<br />
| The Operating System shall offer a stack monitoring which detects possible stack faults of Task(s)/Category 2 OsIsr(s).<br />
|-<br />
| OS068 || OK TriCore<br />
| If a stack fault is detected by stack monitoring AND the configured scalability class is 1 or 2, the Operating System shall call the ShutdownOS() service with the status E_OS_STACKFAULT.<br />
|-<br />
| OS396 || OK TriCore<br />
| If a stack fault is detected by stack monitoring AND the configured scalability class is 3 or 4, the Operating System shall call the ProtectionHook() with the status E_OS_STACKFAULT.<br />
|}<br />
<br />
= OS-Applications =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS445 || Partial [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| The Operating System shall support OS-Applications which are a composition of (at least one Task OR OsIsr) AND (zero or more Alarms, Schedule tables, Counters or Resources) AND (zero or one hooks for startup, error and shutdown).<br />
|-<br />
| OS446 || OK<br />
| The Operating System shall support the notion of trusted and not trusted OS-Applications.<br />
|-<br />
| OS464 || OK<br />
| Trusted OS-Applications may offer services (“trusted services”) to other (even non-trusted) OS-Applications.<br />
|-<br />
| OS016 || OK (see GetApplicationID())<br />
| The Operating System shall provide a service to determine the currently running OS-Application (a unique identifier shall be allocated to each application).<br />
|-<br />
| OS017 || OK (see CheckObjectOwnership())<br />
| The Operating System shall provide a service to determine to which OS-Application a given Task, OsIsr, Resource, Counter, Alarm or Schedule Table belongs.<br />
|-<br />
| OS256 || OK (see CheckObjectAccess())<br />
| The Operating System shall provide a service to determine which OS-Applications are allowed to use the IDs of a Task, OsIsr, Resource, Counter, Alarm or Schedule Table in API calls.<br />
|-<br />
| OS258 || OK (see TerminateApplication())<br />
| The Operating System shall provide a service to terminate the OS-Application to which the calling Task/Category 2 OsIsr/application specific error hook belongs. (This is an OS-Application level variant of the TerminateTask() service)<br />
|-<br />
| OS447 || OK<br />
| Terminating an OS-Application means to:<br />
* terminate all running, ready and waiting Tasks/OsIsrs of the OS-Application AND<br />
* disabling all interrupts of the OS-Application AND<br />
* stop all active alarms of the OS-Applications AND<br />
* stop all schedule tables of the OS-Application.<br />
|-<br />
| OS448 || OK TriCore<br />
| OS-Applications, trusted or non-trusted, shall by default have only access rights to objects belonging to this OS-Application. Access rights from other OS-Applications shall be granted explicitely by configuration.<br />
|-<br />
| OS060 || OK TriCore [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| If an application-specific startup hook is configured for an OS-Application <App>, the Operating System shall call StartupHook_<App> on startup of the OS.<br />
|-<br />
| OS110 || OK [[#OS-Applications notes|<sup>[c]</sup>]]<br />
| If the Operating System forcibly terminates an OS-Application, it:<br />
* forcibly terminates all Tasks/OsIsrs of the OS-Application AND<br />
* cancels all alarms of the OS-Application AND<br />
* stops schedule tables of the OS-Application AND<br />
* disables interrupt sources of Category 2 OsIsrs belonging to the OS-Application<br />
|-<br />
| OS111 || OK [[#OS-Applications notes|<sup>[c]</sup>]]<br />
| When the Operating System restarts an OS-Application it activates the configured OsRestartTask.<br />
|}<br />
<br />
== New Autosar API ==<br />
<br />
=== GetApplicationID ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS016 || OK<br />
| GetApplicationID<br />
|-<br />
| OS261 || OK TriCore [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| GetApplicationID() shall return the application identifier to which the executing Task/ISR/hook belongs.<br />
|-<br />
| OS262 || OK<br />
| If no OS-Application is running, GetApplicationID() shall return INVALID_OSAPPLICATION.<br />
|-<br />
| OS514 || No scalability Classes support<br />
| Availability of GetApplicationID(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== CheckObjectAccess ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS256 || OK TriCore<br />
| CheckObjectAccess<br />
|-<br />
| OS271 || OK TriCore<br />
| If the OS-Application <ApplID> in a call of CheckObjectAccess() has access to the queried object, CheckObjectAccess() shall return ACCESS.<br />
|-<br />
| OS272 || OK TriCore<br />
| If the OS-Application <ApplID> in a call of CheckObjectAccess() has no access to the queried object, CheckObjectAccess() shall return NO_ACCESS.<br />
|-<br />
| OS423 || OK TriCore<br />
| If in a call of CheckObjectAccess() the object to be examined is not a valid object OR <ApplID> is invalid OR <ObjectType> is invalid THEN CheckObjectAccess() shall return NO_ACCESS.<br />
|-<br />
| OS519 || No scalability Classes support<br />
| Availability of CheckObjectAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== CheckObjectOwnership ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS017 || OK TriCore<br />
| CheckObjectOwnership<br />
|-<br />
| OS273 || OK TriCore<br />
| If the object ObjectType specified in a call of CheckObjectOwnership() exists, CheckObjectOwnership() shall return the identifier of the OS-Application to which the object belongs.<br />
|-<br />
| OS274 || OK TriCore<br />
| If in a call of CheckObjectOwnership() the specified object ObjectType is invalid OR the argument of the type (the “...”) is invalid, CheckObjectOwnership() shall return INVALID_OSAPPLICATION.<br />
|-<br />
| OS520 || No scalability Classes support<br />
| Availability of CheckObjectOwnership():Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== TerminateApplication ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS258 || OK TriCore<br />
| TerminateApplication<br />
|-<br />
| OS493 || OK TriCore<br />
| If the input parameter <Application> in a call of TerminateApplication() is not valid TerminateApplication() shall return E_OS_ID.<br />
|-<br />
| OS459 || OK TriCore<br />
| If the <RestartOption> in a call of TerminateApplication() is invalid, TerminateApplication() shall return E_OS_VALUE.<br />
|-<br />
| OS494 || OK TriCore<br />
| If the input parameter <Application> in a call of TerminateApplication() is valid AND the caller belongs to a non-trusted OS-Application AND the caller does not belong to <Application> TerminateApplication() shall return E_OS_ACCESS.<br />
|-<br />
| OS507 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_TERMINATED TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS508 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_RESTARTING and the caller does not belong to the <Application> then TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS548 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_RESTARTING AND the caller does belong to the <Application> AND the <RestartOption> is equal RESTART then TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS287 || OK TriCore<br />
| If the parameters in a call of TerminateApplication() are valid and the above criteria are met TerminateApplication() shall terminate <Application> (i.e. to kill all tasks, disable the interrupt sources of those ISRs which belong to the OS-Application and free all other OS resources associated with the application) AND shall activate the configured OsRestartTask of <Application> if <RestartOption> equals RESTART. If the <Application> is restarted, its state is set to APPLICATION_RESTARTING otherwise to APPLICATION_TERMINATED. If the caller belongs to <Application> TerminateApplication() shall not return, otherwise it shall return E_OK.<br />
|-<br />
| OS535 || OK TriCore<br />
| Caveats of TerminateApplication():<br />
* If no applications are configured the implementation shall make sure that this service is not available.<br />
* Tasks and interrupts that are owned by a trusted application can terminate any OS-Application. Tasks and interrupts that are owned by a non-trusted application can only terminate their owning OS-Application.<br />
|-<br />
| OS536 || No scalability Classes support<br />
| Availability of TerminateApplication(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== AllowAccess ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS501 || OK TriCore<br />
| AllowAccess<br />
|-<br />
| OS497 || OK TriCore<br />
| If the state of the OS-Application of the caller of AllowAccess() is not APPLICATION_RESTARTING AllowAccess() shall return E_OS_STATE.<br />
|-<br />
| OS498 || OK TriCore<br />
| If the state of the OS-Application of the caller of AllowAccess() is APPLICATION_RESTARTING, AllowAccess() shall set the state to APPLICATION_ACCESSIBLE and allow other OS-Applications to access the configured objects of the callers OS-Application.<br />
|-<br />
| OS547 || No scalability Classes support<br />
| Availability of AllowAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== GetApplicationState ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS499 || OK TriCore<br />
| GetApplicationState<br />
|-<br />
| OS495 || OK TriCore<br />
| If the <Application> in a call of GetApplicationState() is not valid GetApplicationState() shall return E_OS_ID.<br />
|-<br />
| OS496 || OK TriCore<br />
| If the parameters in a call of GetApplicationState() are valid, GetApplicationState() shall return the state of OS-Application <Application> in <Value>.<br />
|-<br />
| OS537 || No scalability Classes support<br />
| Availability of GetApplicationState(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific StartupHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS539 || OK<br />
| Application specific StartupHook. The application specific StartupHook is always called after the standard StartupHook() (see OS236). If more than one OS-Application is configured which use startup hooks, the order of calls to the startup hooks of the different OS- Applications is not defined.<br />
|-<br />
| OS543 || No scalability Classes support<br />
| Availability of StartupHook_<App>(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific ErrorHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS540 || OK TriCore<br />
| Application specific ErrorHook. If the general ErrorHook() is configured, the general ErrorHook() is called before the application specific error hook is called (see OS246).<br />
|-<br />
| OS544 || OK TriCore<br />
| Availability of ErrorHook_<App>(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific ShutdownHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS541 || OK<br />
| Application specific ShutdownHook. If the general ShutdownHook() is configured, the general ShutdownHook() is called after all application specific shutdown hook(s) are called (see OS237). If more OS-Applications with an application specific shutdown hook exist the order of calls to these application specific shutdown hooks is not defined.<br />
|-<br />
| OS545 || No scalability Classes support<br />
| Availability of ShutdownHook_<App>(): Available in Scalability Classes 3 and 4. <br />
|}<br />
<br />
=== OS-Applications notes ===<br />
* [a] - Application-specific hook will be supported by TriCore full release.<br />
* [b] - Object protection will be introduced by TriCore full release, by now all objects are accessible by any OS-Application.<br />
* [c] - Termination of OS-Applications will be introduced by TriCore full release, is not supported yet.<br />
<br />
== Privileged mode ==<br />
<br />
Please see note [[#Privileged mode notes|<sup>[a]</sup>]].<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS058 || OK<br />
| If supported by hardware, the Operating System shall execute non-trusted OS-Applications in non-privileged mode.<br />
|-<br />
| OS096 || OK<br />
| As far as supported by hardware, the Operating System shall not allow non- trusted OS-Applications to access control registers managed by the Operating System.<br />
|-<br />
| OS245 || OK[[#Privileged mode notes|<sup>[b]</sup>]]<br />
| If an instruction exception occurs (e.g. division by zero) the operating system shall call the protection hook with E_OS_PROTECTION_EXCEPTION.<br />
|-<br />
| OS451 || OK<br />
| The Operating System shall allow to export services from trusted OS-Applications.<br />
|-<br />
| OS097 || OK<br />
| The Operating System shall provide a mechanism to call a trusted function from a (trusted or non-trusted) OS-Application.<br />
|-<br />
| OS100 || OK<br />
| If a called trusted function is not configured the Operating System shall call the ErrorHook with E_OS_SERVICEID.<br />
|-<br />
| OS226 || OK[[#Privileged mode notes|<sup>[b]</sup>]]<br />
| The Operating System shall execute an application-specific startup hook with the access rights of the associated OS-Application.<br />
|}<br />
<br />
=== CallTrustedFunction ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS097 || OK<br />
| CallTrustedFunction<br />
|-<br />
| OS265 || OK<br />
| If <FunctionIndex> is a defined function index, CallTrustedFunction() shall switch the processor into privileged mode AND shall call the function <FunctionIndex> out of a list of implementation specific trusted functions with disabled memory protection AND shall return E_OK after completion.<br />
|-<br />
| OS312 || OK<br />
| Caveats of CallTrustedFunction():<br />
* The called trusted function must conform to the following C prototype: void TRUSTED_<name_of_the_trusted_service>( TrustedFunctionIndexType,TrustedFunctionParameterRefType); (The arguments are the same as the arguments of CallTrustedFunction).<br />
* Normally, a user will not directly call this service, but it will be part of some standard interface, e.g. a standard I/O interface.<br />
* It is the duty of the called trusted function to check rights of passed parameters, especially if parameters are interpreted as out parameters.<br />
* It should be noted that the CallTrustedFunction() does not disable timing protection for the task which called the service. This may lead to timing faults (calls of the ProtectionHook()) even inside of a trusted OS-Application. It is therefore recommended to use CallTrustedFunction() only for stateless functions (e.g. functions which do not write or do not have internal states)<br />
|-<br />
| OS266 || OK [[#Privileged mode notes|<sup>[b]</sup>]]<br />
| When CallTrustedFunction() calls the function <FunctionIndex>, that function shall be executed with the same processor mode and memory protection boundaries as the OS-Application to which it belongs. It shall however retain the timing protection and service protection limitations of the calling Task or ISR, and the notion of "current application" shall remain that of the calling Task or Category 2 ISR.<br />
|-<br />
| OS364 || OK [[#Privileged mode notes|<sup>[b]</sup>]][[#Privileged mode notes|<sup>[c]</sup>]]<br />
| If CallTrustedFunction() calls the trusted function from a Category 2 ISR context, that function shall continue to run on the same interrupt priority and be allowed to call all system services defined for Category 2 ISR (see table in chapter 7.7.3.2).<br />
|-<br />
| OS365 || OK [[#Privileged mode notes|<sup>[b]</sup>]][[#Privileged mode notes|<sup>[c]</sup>]]<br />
| If CallTrustedFunction() calls the trusted function from a task context, that function shall continue to run on the same priority and be allowed to call all system services defined for tasks (see table in chapter 7.7.3.2).<br />
|}<br />
<br />
=== Privileged mode notes ===<br />
: [a] - In MPC5674F priviliged mode is enabled by the SC4 flag (This incomplete support of scalability classes have been removed in TriCore porting).<br />
: [b] - Supported only by TriCore implementation.<br />
: [c] - In MPC5674F a trusted function is executed in the security context of the calling function, although it runs in privileged mode.<br />
<br />
== Protection hook ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS099 || OK (See CheckTaskMemoryAccess() and CheckISRMemoryAccess())<br />
| The Operating System shall offer OS-Applications a service to check if a memory region is write/read/execute accessible from a Task/Category 2 OsIsr and also return information if the memory region is part of the stack space.<br />
|-<br />
| OS211 || OK TriCore<br />
| The Operating System shall execute the ProtectionHook() with the same permissions as the Operating System.<br />
|-<br />
| OS106 || OK TriCore<br />
| The Operating System shall perform one of the following reactions depending on the return value of the ProtectionHook():<br />
* Do nothing<br />
* Forcibly terminate the faulty Task/Category 2 OsIsr OR<br />
* Forcibly terminate the faulty OS-Application OR<br />
* Forcibly terminate the faulty OS-Application and restart the OS-Application. OR<br />
* Call ShutdownOS().<br />
|-<br />
| OS107 || OK TriCore<br />
| If no ProtectionHook() is configured and a protection error occurs, the Operating System shall call ShutdownOS().<br />
|-<br />
| OS475 || OK TriCore<br />
| If the reaction is to do nothing and the ProtectionHook() was not called with E_OS_PROTECTION_ARRIVAL then the Operating System shall call ShutdownOS()<br />
|-<br />
| OS243 || OK TriCore<br />
| If the reaction is to forcibly terminate the Task/Category 2 OsIsr and no Task or OsIsr can be associated with the error, the running OS-Application is forcibly terminated by the Operating System.<br />
|-<br />
| OS244 || OK TriCore<br />
| If the reaction is to forcibly terminate the faulty OS-Application and no OS- Application can be assigned, ShutdownOS()is called.<br />
|-<br />
| OS108 || OK TriCore<br />
| If the Operating System forcibly terminates a task, it terminates the task (no PostTaskHook() for the task will be called), releases all allocated OSEK resources and calls EnableAllInterrupts()/ / ResumeOSInterrupts() ResumeAllInterrupts() if the Task called DisableAllInterrupts() / / SuspendAllInterrupts() before without the SuspendOSInterrupts() EnableAllInterrupts()/ / corresponding ResumeOSInterrupts() ResumeAllInterrupts() call.<br />
|-<br />
| OS109 || OK TriCore<br />
| If the Operating System forcibly terminates an interrupt service routine, it clears the interrupt request, aborts the interrupt service routine (The interrupt source stays in the current state.) and releases all OSEK resources the interrupt service routine has allocated and calls EnableAllInterrupts() / ResumeOSInterrupts() / ResumeAllInterrupts() if the interrupt called DisableAllInterrupts() / / SuspendAllInterrupts() before without the SuspendOSInterrupts() corresponding EnableAllInterrupts()/ / ResumeOSInterrupts() ResumeAllInterrupts() call.<br />
|-<br />
| OS538 || OK TriCore<br />
| Protection Hook Depending on the return value the Operating System module will either:<br />
* forcibly terminate the Task/Category 2 ISR which causes the problem OR<br />
* forcibly terminate the OS-Application the Task/Category 2 ISR belong (optional with restart) OR<br />
* shutdown the system OR<br />
* do nothing (see 7.8.2)<br />
|-<br />
| OS308 || OK TriCore<br />
| If ProtectionHook() returns an invalid value, the Operating System module shall take the same action as if no protection hook is configured.<br />
|-<br />
| OS542 || No scalability Classes support<br />
| Availability of ProtectionHook(): Available in Scalability Classes 2, 3 and 4.<br />
|}<br />
<br />
= Other New Autosar APIs =<br />
<br />
=== GetISRID ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS511 || OK<br />
| GetISRID<br />
|-<br />
| OS263 || OK<br />
| If called from category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID() shall return the identifier of the currently executing ISR.<br />
|-<br />
| OS264 || partial<br />
| If its caller is not a category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID() shall return INVALID_ISR.<br />
|-<br />
| OS515 || OK (?)<br />
| Availability of GetISRID(): Available in all Scalability Classes.<br />
|}<br />
<br />
= Multi-Core =<br />
<br />
== Basic Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS567 || OK (We have some doubts relates to this, but it should be OK)<br />
| The generated part of the OS is derived from a single configuration that contains the relevant information for all cores. This implies, that IDs (e.g. TASKID, RESOURCEID, …) are unique across cores. Every ID shall refer exactly to one entity independent from the core on which the entity is accessed. This applies also to objects that cannot be shared between cores. (BSW4080008)<br />
|-<br />
| OS568 || OK<br />
|Implementations shall be able to independently execute a TASK or an ISR on each started AUTOSAR OS core in parallel. (BSW4080001)<br />
|-<br />
| OS569 || OK<br />
|The scheduling strategy as defined in AUTOSAR OS shall apply for each individual core in a Multi-Core system, for the TASKs and ISR assigned to the core. (BSW4080001, BSW4080013)<br />
|-<br />
| OS570 || OK<br />
| All TASKs that are assigned to the same OS-Application shall execute on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS571 || OK<br />
| All ISRs that are assigned to the same OS-Application shall execute on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS572 || N.A. in Supported Architectures (PPC TriCore)<br />
| ISR balancing (if supported by the HW) shall be switched off at boot time by the OS. (BSW4080005, BSW4080006)<br />
|-<br />
| OS764 || No scalability classes support (OS-Applications are enabled when configurated).<br />
| The OS module shall support OS-Applications in case of Multi-Core also for SC1 and SC2.<br />
|-<br />
| OS763 || No scalability classes support (But we don't understend this requirement).<br />
| In an SC1 system standard mode shall be possible.<br />
|-<br />
| OS573 ||<br />
| The binding of OS-Applications to cores shall be configured within the OS-Application container. A new configuration item: OsApplicationCoreAssignment{CORE} within the OS-Application container shall be used to define the core to which the OS-Application is bound. The OS generator will map the configuration parameter “CORE” to a certain core, so that all OS-Applications with the same configuration parameter reside on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS623 || OK<br />
| The OS API function CallTrustedFunction shall return E_OS_ACCESS in extended status if the target trusted function is part of an OS-Application on another core. (BSW4080013)<br />
|-<br />
|}<br />
<br />
== Multi-Core start-up Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS574 || OK<br />
| The master core shall be able to activate cores. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS575 || OK<br />
| Any slave core shall be able to activate cores. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS576 || OK<br />
| It shall be allowed to use only a subset of the cores available on a μC for the AUTOSAR system. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS577 || OK (TriCore e PPC e200zx are naturally in Master-Slave configuration)<br />
| The cores shall boot in master-slave mode. If this is not supported by the hardware, it shall be that the cores boot in parallel and emulate the behavior of a master-slave system.. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS578 || N.A.<br />
| In case of an emulation a slave core (CoreS), which is controlled by the AUTOSAR OS (AUTOSAR core), shall not enter the main function before another<br />
core has activated the slave core by means of StartCore(CoreS). (BSW4080006)<br />
|-<br />
| OS579 || OK<br />
| All cores that belong to the AUTOSAR system shall be synchronized within the StartOS function before the scheduling is started and after the global<br />
StartupHook is called.. (BSW4080001, BSW4080006)<br />
|-<br />
| OS580 || OK<br />
| All cores that belong to the AUTOSAR system shall be synchronized within the StartOS function before the scheduling is started and after the global<br />
StartupHook is called.. (BSW4080006)<br />
|-<br />
| OS581 || OK TriCore<br />
| The global StartupHook shall be called on all cores immediately after the first synchronisation point (BSW4080006)<br />
|-<br />
| OS582 || OK TriCore<br />
| The OS-Application-specific StartupHooks shall be called after the global StartupHook but only on the cores to which the OS-Application is bound (BSW4080006, BSW4080008)<br />
|-<br />
| || OK TriCore<br />
| The AUTOSAR OS API provides a StartCore function to start the cores under its control. The StartCore function takes a scalar value parameter of type CoreIDType, specifying the core that shall be started. StartCore can be called more than once on the master core and also on slave cores. Each core can only be started once, however The StartOS function shall be called on all cores that have been activated by StartCore. It is not allowed to call StartCore from a core that has already called StartOS. Cores that belong to the AUTOSAR system shall be started by the designated AUTOSAR OS API service StartCore.<br />
|-<br />
| OS583 || OK TriCore<br />
| The number of cores that can be controlled by the AUTOSAR OS shall be configured offline. A new configuration item (OsNumberOfCores) within the “OsOS” container is used to specify the maximum number of cores that are controlled by the AUTOSAR OS. If no value for (OsNumberOfCores) has been specified the number of cores shall be one. (BSW4080001, BSW4080011) <br />
|-<br />
| OS584 || OK TriCore<br />
| The AUTOSAR OS shall provide a function called StartNonAutosarCore that can be used to start cores, which are not controlled by the AUTOSAR OS. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS585 || OK TriCore<br />
| It shall be possible to activate cores that are not controlled by the AUTOSAR OS before and after calling StartOS. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS606 || OK TriCore<br />
| The AUTOSAR specification does not support the activation of AUTOSAR cores after calling StartOS on that core. If StartCore is called after StartOS it shall return with E_OS_ACCESS in extended status. (BSW4080001)<br />
|-<br />
| OS607 || OK TriCore<br />
| StartOS shall start the OS on the core on which it is called. (BSW4080006, BSW4080013)<br />
|-<br />
| OS608 || OK TriCore<br />
| If more than one core calls StartOS with an AppMode other than “DONOTCARE”, the AppModes shall be the same. StartOS shall check this at the first synchronisation point. In case of violation, StartOS shall not start the scheduling, shall not call any StartupHooks, and shall enter an endless loop on every core. (BSW4080006)<br />
|-<br />
| OS609 || OK TriCore<br />
| If StartOS is called with the AppMode “DONOTCARE” the application mode of the other core(s) (differing from “DONOTCARE”) shall be used. (BSW4080006)<br />
|-<br />
| OS610 || OK TriCore<br />
| At least one core shall define an AppMode other than “DONOTCARE”. (BSW4080006)<br />
|-<br />
| OS611 || OK TriCore<br />
| If the IOC is configured, StartOS shall initialize the data structures of the IOC. (BSW4080020)<br />
|-<br />
| OS668 || OK<br />
| The AUTOSAR Operating System shall automatically activate all auto-start TASKs configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
| OS669 || OK<br />
| The AUTOSAR Operating System shall automatically activate all auto-start ALARMs configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
| OS670 || Not Schedule tables supported yet<br />
| The AUTOSAR Operating System shall automatically activate all auto-start schedule tables configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
|}<br />
<br />
== Multicore Shutdown Requirements ==<br />
<br />
AUTOSAR supports two shutdown concepts, the synchronized shutdown and the individual shutdown concept. While the synchronized shutdown is triggered by the new API function '''ShutdownAllCores()''', the individual shutdown is invoked by the existing API function '''ShutdownOS()'''.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS586 || OK TriCore<br />
| During the shutdown, the OS-Application specific ShutdownHook shall be called on the core on which the corresponding OS-Application is bound. (BSW4080007)<br />
|- <br />
| OS587 || OK TriCore (if ShutdownAllCores has been called)<br />
| Before calling the global ShutdownHook, all cores shall be synchronized. (BSW4080007)<br />
|- <br />
| OS588 || OK<br />
| The global ShutdownHook shall be called on all cores. (BSW4080007)<br />
|-<br />
| OS762 || OK TriCore (fullfilled by ProtectionHook implementation)<br />
| In cases where the OS detects a fatal internal error all cores shall be shutdown.<br />
|-<br />
| OS616 || OK<br />
| ShutdownOS shall be callable from each core running an AUTOSAR OS. (BSW4080001, BSW4080007)<br />
|-<br />
| OS617 || OK<br />
| ShutdownOS shall shutdown the core on which it was called. (BSW4080007)<br />
|-<br />
| OS618 || OK<br />
| The OS shall not start TASKs of an OS-Application once the shutdown procedure has been entered on a particular core. (BSW4080013)<br />
|-<br />
| OS619 || OK<br />
| The AUTOSAR OS function ShutdownOS shall be callable in parallel on multiple cores. (BSW4080013)<br />
|-<br />
| OS620 || OK TriCore<br />
| ShutdownOS shall release all spinlocks which are occupied by the calling core. (BSW4080021)<br />
|-<br />
| OS621 || OK TriCore<br />
| ShutdownAllCores shall be callable from each core running an AUTOSAR OS. (BSW4080007)<br />
|-<br />
|}<br />
<br />
== OS Other Services Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS589 || OK TriCore<br />
| All functions that are not allowed to operate cross core shall return E_OS_CORE in extended status if called with parameters that require a cross core operation. (BSW4080013)<br />
|-<br />
| OS590 || OK<br />
| The OS service “DisableAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS591 || OK<br />
| The OS service “EnableAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS592 || OK<br />
| The OS service “SuspendAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS593 || OK<br />
| The OS service “ResumeAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS594 || OK<br />
| The OS service “SuspendOSInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS595 || OK<br />
| The OS service “ResumeOSInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS596 || OK<br />
| It shall be possible to activate a TASK that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080001, BSW4080015)<br />
|-<br />
| OS598 || OK TriCore (RPC Dispactcher)<br />
| The call of ActivateTask across cores shall behave synchronously, i.e. a call returns after the task has been activated or an error has been detected. It shall not be possible to continue execution on the calling core before ActivateTask is accomplished on the remote core. (BSW4080015)<br />
|-<br />
| OS599 || OK TriCore (RPC Dispactcher)<br />
| In case of an error when calling ActivateTask across cores, the error handler shall be called on the core on which ActivateTask was originally called. (BSW4080015)<br />
|-<br />
| OS600 || OK<br />
| It shall be possible to chain a TASK that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080001, BSW4080015)<br />
|-<br />
| OS602 || OK<br />
| It shall be possible to set an EVENT that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080016)<br />
|-<br />
| OS604 || OK TriCore (RPC Dispactcher)<br />
| The call of SetEvent across cores shall behave synchronously, i.e. a call returns after the Event has been set or an error has been detected. It shall not be possible to continue execution on the calling core before SetEvent is accomplished on the remote core. (BSW4080016)<br />
|-<br />
| OS605 || OK TriCore (RPC Dispactcher [[#MultiCore notes|<sup>[a]</sup>]])<br />
| In case of an error when calling SetEvent across cores, the error handler shall be called on the core on which SetEvent was originally called. (BSW4080016)<br />
|-<br />
| OS612 || OK TriCore<br />
| In extended status TerminateTask / ChainTask shall return with an error (E_OS_SPINLOCK), which can be evaluated in the application. (BSW4080021)<br />
|-<br />
| OS613 || OK TriCore<br />
| Spinlocks occupied by TASKS that are terminated in response to a protection hook shall be automatically released. This applies also to the case in which an OS-Application is terminated. (BSW4080021)<br />
|-<br />
| OS614 || OK TriCore<br />
| TerminateApplication shall check if any of the TASKs in the OS-Application have occupied a spinlock. If so, the spinlocks shall be released.(BSW4080021)<br />
|-<br />
| OS615 ||<br />
| If TerminateApplication(A) is called in parallel from different cores, the OsApplication “A” is terminated by the first call, any subsequent calls will return with 'E_OK' in standard and extended status without doing anything, until the termination is completed.<br />
|-<br />
| OS622 || OK<br />
| The AUTOSAR Operating System WaitEvent API service shall check if it has been called while the calling TASK has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the TASK shall not enter the wait state. (BSW4080021)<br />
|-<br />
| OS624 || OK<br />
| The AUTOSAR Operating System Schedule API service shall check if it has been called while the calling TASK has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the scheduler shall not be called. (BSW4080021)<br />
|-<br />
| OS629 || OK<br />
| A COUNTER belonging to an OS-Application shall be incremented by the core on which the OS-Application resides. The COUNTER shall not be incremented by other cores. (BSW4080013)<br />
|-<br />
| OS630 || OK<br />
| It shall not be allowed to drive a schedule table from a COUNTER, which is assigned to a different core. (BSW4080013)<br />
|-<br />
| OS631 || OK<br />
| It shall not be allowed to drive an ALARM from a COUNTER, which is assigned to a different core. (BSW4080013)<br />
|-<br />
| OS632 || OK<br />
| If an ALARM expires, it shall be allowed to activate a TASK on a different core. (BSW4080018)<br />
|-<br />
| OS633 || OK<br />
| If an ALARM expires, it shall be allowed to set an EVENT on a different core. (BSW4080018)<br />
|-<br />
| OS634 || OK<br />
| The AUTOSAR Operating System shall process an ALARM on the core on which its corresponding OS-Application resides. (BSW4080018)<br />
|-<br />
| OS635 || OK<br />
| ALARM callbacks shall be executed on the core to which the ALARM is bound. This is only applicable to SC1 systems, because otherwise Alarm Callback<br />
are not allowed (OS242). (BSW4080013)<br />
|-<br />
| OS636 || OK<br />
| SetRelAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|-<br />
| OS637 || OK<br />
| SetAbsAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS638 || OK<br />
| CancelAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS639 || OK<br />
| GetAlarmBase shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS640 || OK<br />
| GetAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
|}<br />
<br />
== MultiCore notes ==<br />
: [a] - [[Infineon_Aurix#Multicore_Autosar_OS_Support|New RPC MultiCore dispatcher]]<br />
<br />
== Other AUTOSAR Multicore API ==<br />
<br />
=== GetCoreID ===<br />
<br />
Every HW assigns a unique physical Id to a core. The physical core Id is the only way to distinguish between cores. <br />
The physical core Ids of a μC are not necessarily consecutive and do not necessarily start with zero.<br />
The SW requires a mechanism to identify a core, e.g. to use core specific variables. Because the physical core Id usually can not be used as a direct array index for core specific variables, a logical CoreID is necessary to map physical core Ids to array indexes. In the SW it is not necessary to know the physical core Id, the logical CoreID is sufficient.<br />
The mapping of OSApplications and other SW objects to cores is specified in the configuration files. All such mappings shall be HW independent and therefore shall not be based on the physical core Id but on the logical CoreID. The function GetCoreID internally maps the physical core Id to the logical CoreID. The mapping is implementation specific. GetCoreID can be either a C function or a macro.<br />
<br />
'''N.B''' In Erika with code replication the core ID is not a real issue.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS625 || OK TriCore<br />
| The AUTOSAR Operating System API function GetCoreID shall be callable before StartOS. (BSW4080006)<br />
|-<br />
| OS626 || OK TriCore<br />
| An implementation shall offer a function GetNumberOfActivatedCores that returns the number of cores running the AUTOSAR OS. (BSW4080001)<br />
|-<br />
| OS627 || OK TriCore<br />
| An implementation shall define a set of constants OS_CORE_ID_<No> of the type CoreIDType with <No> a value from 0 to “OsNumberOfCores -1. (BSW4080001)<br />
|-<br />
| OS628 || OK TriCore<br />
| An implementation shall offer a constant OS_CORE_ID_MASTER of the type CoreIDType that refers to the master core. (BSW4080001)<br />
|}<br />
<br />
== Spinlocks ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS648 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a spinlock mechanism that works across cores. (BSW4080018, BSW4080021)<br />
|-<br />
| OS649 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a GetSpinlock function which occupies a spinlock. If the spinlock is already occupied, GetSpinlock shall<br />
keep on trying to occupy the spinlock until it succeeds. (BSW4080018, BSW4080021)<br />
|-<br />
| OS650 || OK TriCore<br />
| GetSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS651 || OK TriCore<br />
| GetSpinlock shall be callable from ISR2 level. The behavior of GetSpinlock is undefined if called from a category 1 ISR. (BSW4080021)<br />
|-<br />
| OS652 || OK TriCore (With Trivial spinlocks)<br />
| The AUTOSAR Operating System shall provide a TryToGetSpinlock function which occupies a spinlock. If the spinlock is already occupied by a TASK,<br />
TryToGetSpinlock shall return. (BSW4080018, BSW4080021)<br />
|-<br />
| OS653 || OK TriCore<br />
| TryToGetSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS654 || OK TriCore<br />
| TryToGetSpinlock shall be callable from ISR2 level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS655 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a ReleaseSpinlock function which releases an occupied spinlock. If the spinlock is not occupied an error<br />
shall be returned. (BSW4080018, BSW4080021)<br />
|-<br />
| OS656 || OK TriCore<br />
| ReleaseSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS657 || OK TriCore<br />
| ReleaseSpinlock shall be callable from ISR2 level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS658 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if a TASK tries to occupy a spinlock that is assigned to a TASK/ISR2 on the same core (including<br />
itself). (BSW4080018, BSW4080021)<br />
|-<br />
| OS659 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if an ISR2 tries to occupy a spinlock that is assigned to a TASK/ISR2 on the same core.<br />
(BSW4080018, BSW4080021)<br />
|-<br />
| OS660 || OK TriCore<br />
| A unique order in which multiple spinlocks can be occupied by a TASK/ISR2 should be configurable in the AUTOSAR Operating System. This might<br />
be realized by the configuration item (OsSpinlockSuccessor{NEXT_SPINLOCK}) where “NEXT_SPINLOCK” refers to the consecutive spinlock. (See chapter 10.2.5) (BSW4080018, BSW4080021)<br />
|-<br />
| OS661 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if a TASK/ISR2 that currently holds a spinlock tries to seize another spinlock that has not been<br />
configured as a direct or indirect successor of the latest acquired spinlock (by means of the OsSpinlockSuccessor configuration parameter) or if no successor is configured. (BSW4080018, BSW4080021)<br />
|-<br />
|}<br />
<br />
= Inter-OS-Application Communicator (IOC) Requirements =<br />
<br />
IOC stands for Inter OS-Application Communicator. The "IOC" is responsible for the communication between OS-Applications and in<br />
particular for the communication crossing core or memory protection boundaries. It's internal functionality is closely connected to the Operating System.<br />
<br />
Memory protection boundaries are a characteristic of OS-Applications and special communication mechanisms are needed to cross them.<br />
Multi-Core systems may also need additional measures to make communication between cores safe.<br />
<br />
The IOC provides communication services between OS-Applications and in particular over core boundaries in Multi-Core systems. Because the cross-core communication is always an inter-OS-Application communication, the two mechanisms are combined. An inter OS-Application communication may not necessarily require a cross core communication, however.<br />
<br />
In systems with only one core, the IOC can be omitted completely, if just one OS-Application is available, or if no OS-Application uses memory protection mechanisms.<br />
<br />
'''N.B''' Since a lot of Code of IOC is configurated and generated starting from RTE configuration, it doesn't make sense generate a whole IOC system without a complete RTE generator. But '''we choiced the cross-boundaries communication mechanism''' that is the heart of IOC. The same mechanism is employed to implement OS Services remote invocation.<br />
<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS671 ||<br />
| The IOC implementation shall be part of the Operating System The IOC is a third type of communication, in addition to:<br />
* Intra OS-Application communication: Always handled within the RTE<br />
* Inter ECU communication: already available via well defined interfaces to the communication stack (COM).<br />
(BSW4080020)<br />
|-<br />
|}</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=ERIKA_%26_Autosar_OS_RequirementsERIKA & Autosar OS Requirements2016-09-21T16:33:37Z<p>Eguidieri: /* Memory protection */</p>
<hr />
<div>= Introduction =<br />
Erika Enterprise is the first open-source Free RTOS that has been certified OSEK/VDX compliant and it's under current developtment to fulfil Autosar 4 OS Requirements too. In the following table are logged the AUTOSAR requirements already implemneted in ERIKA.<br />
<br />
* All the requirement tagged as OK are implemented in all supported Architectures.<br />
* All the requirements related to '''memory protection''' are available only for those MCU that have memory protection implmentented: currently only support for Freescale MPC5674F has been released.<br />
* All the requirements tagged as TriCore are implemented but will be realesed when the full support for TriCore AURIX will be released.<br />
<br />
Scalability Classes are not implemented yet, but each feature/API is activated only if required by the configuration.<br />
<br />
= Tasks =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS052 || OK<br />
| If a task returns from its entry function without making a TerminateTask() or ChainTask() call, the Operating System shall terminate the task (and call the PostTaskHook() if configured).<br />
|-<br />
| OS069 || OK<br />
| If a task returns from its entry function without making a TerminateTask() or ChainTask() call AND the error hook is configured, the Operating System shall call the ErrorHook() (this is done regardless of whether the task causes other errors, e.g. E_OS_RESOURCE) with status E_OS_MISSINGEND before the task leaves the RUNNING state.<br />
|-<br />
| OS070 || OK<br />
| If a task returns from the entry function without making a TerminateTask() or ChainTask() call and still holds OSEK Resources, the Operating System shall release them.<br />
|-<br />
| OS239 || OK<br />
| If a task returns from the entry function without making a TerminateTask() or ChainTask() call and interrupts are still disabled, the Operating System shall enable them.<br />
|-<br />
| OS071 || OK<br />
| If the PostTaskHook() is configured, the Operating System shall not call the hook if ShutdownOS() is called.<br />
|}<br />
<br />
= ISR2s =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS368 || OK<br />
| If a Category 2 OsIsr calls DisableAllInterupts() SuspendAllInterrupts() / SuspendOSInterrupts() and ends (returns) without calling the corresponding EnableAllInterrupts() / ResumeAllInterrupts() / ResumeOSInterrupts(), the Operating System shall perform the missing service and shall call the ErrorHook() (if configured) with the status E_OS_DISABLEDINT.<br />
|-<br />
| OS369 || OK<br />
| If a Category 2 OsIsr calls GetResource() and ends (returns) without calling the corresponding ReleaseResource(), the Operating System shall perform the ReleaseResource() call and shall call the ErrorHook() (if configured) with the status E_OS_RESOURCE.<br />
|}<br />
<br />
= Hooks =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS236 || OK TriCore<br />
| If both a system-specific and one (or more) application specific startup hook(s) are configured, the Operating System shall call the system-specific startup hook before the application-specific startup hook(s).<br />
|-<br />
| OS112 || OK TriCore<br />
| If an application-specific shutdown hook is configured for an OS-Application <App>, the Operating System shall call ShutdownHook_<App> on shutdown of the OS.<br />
|-<br />
| OS225 || OK TriCore<br />
| The Operating System shall execute an application-specific shutdown hook with the access rights of the associated OS-Application.<br />
|-<br />
| OS237 || OK TriCore<br />
| If both a system-specific and one (or more) application specific shutdown hook(s) are configured, the Operating System shall call the system-specific shutdown hook after the application-specific shutdown hook(s).<br />
|-<br />
| OS246 || OK TriCore<br />
| When an error occurs AND an application-specific error hook is configured for the faulty OS-Application <App>, the Operating System shall call that application- specific error hook ErrorHook_<App> after the system specific error hook is called (if configured).<br />
|-<br />
| OS085 || OK TriCore<br />
| The Operating System shall execute an application-specific error hook with the access rights of the associated OS-Application.<br />
|}<br />
<br />
= Timers and Counters =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS301 || OK<br />
| The Operating System shall provide the ability to increment a software counter as an alternative action on alarm expiry.<br />
|-<br />
| OS399 || OK<br />
| The OS shall provide an API call to increment a software counter.<br />
|-<br />
| OS374 || OK<br />
| The Operating System shall handle all the initialization and configuration of timers used directly by the OS and not handled by the GPT driver.<br />
|-<br />
| OS383 || OK (partials)<br />
| The Operating System shall provide a service to read the current count value of a counter (returning either the hardware timer ticks if counter is driven by hardware or the software ticks when user drives counter).<br />
|-<br />
| OS392 || OK<br />
| The Operating System shall provide a service to get the number of ticks between the current tick value and a previously read tick value.<br />
|-<br />
| OS384 ||<br />
| The Operating System shall adjust the read out values of hardware timers (which drive counters) in such that the lowest value is zero and consecutive reads return an increasing count value until the timer wraps at its modulus.<br />
|}<br />
<br />
== Autosar New API for Timers and Counters ==<br />
<br />
=== IncrementCounter ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS399 || OK<br />
| IncrementCounter<br />
|-<br />
| OS285 || OK<br />
| If the input parameter <CounterID> in a call of IncrementCounter() is not valid OR the counter is a hardware counter, IncrementCounter() shall return E_OS_ID.<br />
|-<br />
| OS286 || OK<br />
| If the input parameter of IncrementCounter() is valid, IncrementCounter() shall increment the counter <CounterID> by one (if any alarm connected to this counter expires, the given action, e.g. task activation, is done) and shall return E_OK.<br />
|-<br />
| OS321 || OK<br />
| If in a call of IncrementCounter() an error happens during the execution of an alarm action, e.g. E_OS_LIMIT caused by a task activation, IncrementCounter() shall call the error hook(s), but the IncrementCounter() service itself shall return E_OK.<br />
|-<br />
| OS529 || OK<br />
| Caveats of IncrementCounter(): If called from a task, rescheduling may take place.<br />
|-<br />
| OS530 || OK<br />
| Availability of IncrementCounter(): Available in all Scalability Classes.<br />
|}<br />
<br />
=== GetCounterValue ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS383 || OK<br />
| GetCounterValue<br />
|-<br />
| OS376 || OK<br />
| If the input parameter <CounterID> in a call of GetCounterValue() is not valid, GetCounterValue() shall return E_OS_ID.<br />
|-<br />
| OS377 || OK<br />
| If the input parameter <CounterID> in a call of GetCounterValue() is valid, GetCounterValue() shall return the current tick value of the counter via <Value> and return E_OK.<br />
|-<br />
| OS531 || OK (partials)<br />
| Caveats of GetCounterValue(): Note that for counters of OsCounterType = HARDWARE the real timer value (the – possibly adjusted – hardware value, see OS384) is returned, whereas for counters of OsCounterType = SOFTWARE the current “software” tick value is returned.<br />
|-<br />
| OS532 || OK<br />
| Availability of GetCounterValue(): Available in all Scalability Classes.<br />
|}<br />
<br />
=== GetElapsedValue ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS392 || OK<br />
| GetElapsedValue<br />
|-<br />
| OS381 || OK<br />
| If the input parameter <CounterID> in a call of GetElapsedValue() is not valid GetElapsedValue() shall return E_OS_ID.<br />
|-<br />
| OS391 || OK<br />
| If the <Value> in a call of GetElapsedValue() is larger than the max allowed value of the <CounterID>, GetElapsedValue() shall return E_OS_VALUE.<br />
|-<br />
| OS382 || OK<br />
| If the input parameters in a call of GetElapsedValue() are valid, GetElapsedValue() shall return the number of elapsed ticks since the given <Value> value via <ElapsedValue> and shall return E_OK.<br />
|-<br />
| OS460 || OK<br />
| GetElapsedValue() shall return the current tick value of the counter in the <Value> parameter.<br />
|-<br />
| OS533 || OK<br />
| Caveats of GetCounterValue():If the timer already passed the <Value> value a second (or multiple) time, the result returned is wrong. The reason is that the service can not detect such a relative overflow.<br />
|-<br />
| OS534 || OK<br />
| Availability of GetCounterValue(): Available in all Scalability Classes.<br />
|}<br />
<br />
== OSEK Requirements Extensions ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS304 || OK<br />
| If in a call to SetRelAlarm() the parameter “increment” is set to zero, the service shall return E_OS_VALUE in standard and extended status .<br />
|-<br />
| OS424 || OK<br />
| The first call to StartOS() (for starting the Operating System) shall not return.<br />
|-<br />
| OS425 || OK<br />
| If ShutdownOS() is called and ShutdownHook() returns then the operating system shall disable all interrupts and enter an endless loop.<br />
|-<br />
| OS299 || OK<br />
|The Operating System shall provide the services DisableAllInterrupts(), EnableAllInterrupts(), SuspendAllInterrupts(), ResumeAllInterrupts() prior to calling StartOS() and after calling ShutdownOS(). (It is assumed that the static variables of these functions are initialized).<br />
|-<br />
| OS051 || OK TriCore<br />
| If an invalid address (address is not writable by this OS-Application) is passed as an out-parameter to an OS service, the Operating System shall return the status code E_OS_ILLEGAL_ADDRESS.<br />
|-<br />
| OS088 || OK TriCore<br />
| If an OS-Application makes a service call from the wrong context AND is currently not inside a Category 1 OsIsr the Operating System shall not perform the requested action (the service call shall have no effect), and return E_OS_CALLEVEL or the “invalid value” of the service.<br />
|-<br />
| OS092 || OK<br />
| If EnableAllInterrupts() ResumeAllInterrupts() / ResumeOSInterrupts() are called and no corresponding DisableAllInterupts() / SuspendAllInterrupts() / SuspendOSInterrupts() was done before, the Operating System shall not perform this OS service.<br />
|-<br />
| OS093 || OK<br />
| If interrupts are disabled/suspended by a Task/OsIsr and the Task/OsIsr calls any OS service (excluding the interrupt services) then the Operating System shall ignore the service AND shall return E_OS_DISABLEDINT if the service returns a StatusType value.<br />
|-<br />
| OS054 || OK TriCore<br />
| The Operating System shall ignore calls to ShutdownOS() from non-trusted OS-Applications.<br />
|-<br />
| OS056 || OK TriCore<br />
| If an OS-object identifier is the parameter of a system service, and no sufficient access rights have been assigned at configuration time (Parameter Os[...]AccessingApplication) to the calling Task/Category 2 OsIsr, the system service shall return E_OS_ACCESS.<br />
|-<br />
| OS449 || OK<br />
| CheckTaskMemoryAccess and CheckIsrMemoryAccess check the memory access. Memory access checking is possible for all OS-Applications and from all OS- Applications and does not need granted rights (This is an exception to OS056).<br />
|-<br />
| OS450 || OK<br />
| CheckObjectAccess checks the access rights for OS objects. Checking object access is possible for all OS-Applications and from all OS-Applications and does not need granted rights (This is an exception to OS056).<br />
|-<br />
| OS439 || OK<br />
| The Operating System shall offer the OSEK error macros (OSError...()) to all configured error hooks AND there shall be two (like in OIL) global configuration parameter to switch these macros on or off.<br />
|-<br />
| OS367 || OK<br />
| Operating System services which do not return a StatusType shall not raise the error hook(s).<br />
|-<br />
| OS566 || OK<br />
| The Operating System API shall check in extended mode all pointer argument for NULL pointer and return OS_E_PARAMETER if such argument is NULL.<br />
|}<br />
<br />
= Minor Further Requirements =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS398 || OK<br />
| The OS shall not define the symbol LOCALMESSAGESONLY<br />
|-<br />
| OS242 || No scalability Classes support (But this will be prevented in Any AS configuration)<br />
| The Operating System shall only allow Alarm Callbacks in Scalability Class 1.<br />
|}<br />
<br />
= Memory protection =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS198 || Partial [[#Memory protection notes|<sup>[a]</sup>]]<br />
| The Operating System shall prevent write access to its own data sections and its own stack from non-trusted OS-Applications.<br />
|-<br />
| OS026 || OK (not prevented)<br />
| The Operating System may prevent read access to an OS-Application’s data section attempted by other non-trusted OS-Applications.<br />
|-<br />
| OS086 || OK<br />
| The Operating System shall permit an OS-Application read and write access to that OS-Application’s own private data sections.<br />
|-<br />
| OS207 || OK<br />
| The Operating System shall prevent write access to the OS-Application’s private data sections from other non-trusted OS-Applications.<br />
|-<br />
| OS196 || OK<br />
| The Operating System shall permit a Task/Category 2 OsIsr read and write access to that Task’s/Category 2 OsIsr’s own private stack.<br />
|-<br />
| OS208 || OK (not prevented)<br />
| The Operating System may prevent write access to the private stack of Tasks/Category 2 OsIsrs of a non-trusted application from all other Tasks/OsIsrs in the same OS-Application.<br />
|-<br />
| OS355 || OK<br />
| The Operating System shall prevent write access to all private stacks of Tasks/Category 2 OsIsrs of an OS-Application from other non-trusted OS- Applications.<br />
|-<br />
| OS087 || OK<br />
| The Operating System shall permit a Task/Category 2 OsIsr read and write access to that Task’s/Category 2 OsIsr’s own private data sections.<br />
|-<br />
| OS195 || OK (not prevented)<br />
| The Operating System may prevent write access to the private data sections of a Task/Category 2 OsIsr of a non-trusted application from all other Tasks/OsIsrs in the same OS-Application.<br />
|-<br />
| OS356 || OK<br />
| The Operating System shall prevent write access to all private data sections of a Task/Category 2 OsIsr of an OS-Application from other non-trusted OS- Applications.<br />
|-<br />
| OS027 || OK (not protected)<br />
| The Operating System may provide an OS-Application the ability to protect its code sections against executing by non-trusted OS-Applications.<br />
|-<br />
| OS081 || OK (all code is shared)<br />
| The Operating System shall provide the ability to provide shared library code in sections that are executable by all OS-Applications.<br />
|-<br />
| OS209 || OK<br />
| The Operating System shall permit trusted OS-Applications read and write access to peripherals.<br />
|-<br />
| OS083 || Not done [[#Memory protection notes|<sup>[b]</sup>]]<br />
| The Operating System shall allow non-trusted OS-Applications to write to their assigned peripherals only (incl. reads that have the side effect of writing to a memory location).<br />
|-<br />
| OS044 || OK TriCore [[#Memory protection notes|<sup>[c]</sup>]]<br />
| If a memory access violation is detected, the Operating System shall call the Protection Hook with status code E_OS_PROTECTION_MEMORY.<br />
|}<br />
<br />
No timing and memory protection for alarm callbacks.<br />
<br />
== CheckISRMemoryAccess ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS512 || OK<br />
| CheckISRMemoryAccess<br />
|-<br />
| OS267 || OK<br />
| If the ISR reference <ISRID> in a call of CheckISRMemoryAccess() is valid, CheckISRMemoryAccess() shall return the access rights of the ISR on the specified memory area.<br />
|-<br />
| OS313 || OK [[#Memory protection notes|<sup>[d]</sup>]]<br />
| If an access right (e.g. “read”) is not valid for the whole memory area specified in a call of CheckISRMemoryAccess(), CheckISRMemoryAccess() shall yield no access regarding this right.<br />
|-<br />
| OS268 || OK<br />
| If the ISR reference <ISRID> is not valid, CheckISRMemoryAccess() shall yield no access rights.<br />
|-<br />
| OS517 || No scalability Classes support<br />
| Availability of CheckISRMemoryAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
== CheckTaskMemoryAccess ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS513 || OK<br />
| CheckTaskMemoryAccess<br />
|-<br />
| OS269 || OK<br />
| If the Task reference <TaskID> in a call of CheckTaskMemoryAccess() is valid, CheckTaskMemoryAccess() shall return the access rights of the task on the specified memory area.<br />
|-<br />
| OS314 || OK [[#Memory protection notes|<sup>[d]</sup>]]<br />
| If an access right (e.g. “read”) is not valid for the whole memory area specified in a call of CheckTaskMemoryAccess(), CheckTaskMemoryAccess() shall yield no access regarding this right.<br />
|-<br />
| OS270 || OK<br />
| If the Task reference <TaskID> in a call of CheckTaskMemoryAccess() is not valid, CheckTaskMemoryAccess() shall yield no access rights.<br />
|-<br />
| OS518 || No scalability Classes support<br />
| Availability of CheckTaskMemoryAccess(): Available in Scalability Classes 3 and 4<br />
|}<br />
<br />
== Memory protection notes ==<br />
* [a] - The OS shares the stack with tasks and ISRs. If SP is invalid when calling a system API, a fault may happen. If a context change happens inside a system call (e.g., ActivateTask() made on a task with higher priority), data from the OS remain saved on the stack of the calling task; other tasks or ISRs from the same OS-Application can overwrite those values. A solution for this problem is in testing on TriCore implementation, but since the kernel on AURIX never allocate stack (this is due to the special carateristic of TriCore Architecture and the compilers optimizations) the implementation cannot be proved until it will backported on PPC or on a new architecture with this pontential problem.<br />
* [b] - This is tricky. Currently, only trusted OS-Applications can access MCU registers. Probably the granularity of the MMU is not enough, and maybe the MPU is not suitable either.<br />
* [c] - In MPC5674F When a protection error occur, one of the IVOR routines is called, which jump to <code>__empty_handler</code>. In TriCore protection hook will be fully supported.<br />
* [d] - The current implementation is more restrictive. If the given memory range is not contained in a single memory section (e.g., it starts inside the stack section and ends inside BSS), no access is returned. This should not create problems, as crossing sections depends on the memory layout; relying on that would be very fragile and no application should do it.<br />
<br />
= Stack monitoring =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS067 || OK TriCore<br />
| The Operating System shall offer a stack monitoring which detects possible stack faults of Task(s)/Category 2 OsIsr(s).<br />
|-<br />
| OS068 || OK TriCore<br />
| If a stack fault is detected by stack monitoring AND the configured scalability class is 1 or 2, the Operating System shall call the ShutdownOS() service with the status E_OS_STACKFAULT.<br />
|-<br />
| OS396 || OK TriCore<br />
| If a stack fault is detected by stack monitoring AND the configured scalability class is 3 or 4, the Operating System shall call the ProtectionHook() with the status E_OS_STACKFAULT.<br />
|}<br />
<br />
= OS-Applications =<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS445 || Partial [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| The Operating System shall support OS-Applications which are a composition of (at least one Task OR OsIsr) AND (zero or more Alarms, Schedule tables, Counters or Resources) AND (zero or one hooks for startup, error and shutdown).<br />
|-<br />
| OS446 || OK<br />
| The Operating System shall support the notion of trusted and not trusted OS-Applications.<br />
|-<br />
| OS464 || OK<br />
| Trusted OS-Applications may offer services (“trusted services”) to other (even non-trusted) OS-Applications.<br />
|-<br />
| OS016 || OK (see GetApplicationID())<br />
| The Operating System shall provide a service to determine the currently running OS-Application (a unique identifier shall be allocated to each application).<br />
|-<br />
| OS017 || OK (see CheckObjectOwnership())<br />
| The Operating System shall provide a service to determine to which OS-Application a given Task, OsIsr, Resource, Counter, Alarm or Schedule Table belongs.<br />
|-<br />
| OS256 || OK (see CheckObjectAccess())<br />
| The Operating System shall provide a service to determine which OS-Applications are allowed to use the IDs of a Task, OsIsr, Resource, Counter, Alarm or Schedule Table in API calls.<br />
|-<br />
| OS258 || OK (see TerminateApplication())<br />
| The Operating System shall provide a service to terminate the OS-Application to which the calling Task/Category 2 OsIsr/application specific error hook belongs. (This is an OS-Application level variant of the TerminateTask() service)<br />
|-<br />
| OS447 || OK<br />
| Terminating an OS-Application means to:<br />
* terminate all running, ready and waiting Tasks/OsIsrs of the OS-Application AND<br />
* disabling all interrupts of the OS-Application AND<br />
* stop all active alarms of the OS-Applications AND<br />
* stop all schedule tables of the OS-Application.<br />
|-<br />
| OS448 || OK TriCore<br />
| OS-Applications, trusted or non-trusted, shall by default have only access rights to objects belonging to this OS-Application. Access rights from other OS-Applications shall be granted explicitely by configuration.<br />
|-<br />
| OS060 || OK TriCore [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| If an application-specific startup hook is configured for an OS-Application <App>, the Operating System shall call StartupHook_<App> on startup of the OS.<br />
|-<br />
| OS110 || OK [[#OS-Applications notes|<sup>[c]</sup>]]<br />
| If the Operating System forcibly terminates an OS-Application, it:<br />
* forcibly terminates all Tasks/OsIsrs of the OS-Application AND<br />
* cancels all alarms of the OS-Application AND<br />
* stops schedule tables of the OS-Application AND<br />
* disables interrupt sources of Category 2 OsIsrs belonging to the OS-Application<br />
|-<br />
| OS111 || OK [[#OS-Applications notes|<sup>[c]</sup>]]<br />
| When the Operating System restarts an OS-Application it activates the configured OsRestartTask.<br />
|}<br />
<br />
== New Autosar API ==<br />
<br />
=== GetApplicationID ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS016 || OK<br />
| GetApplicationID<br />
|-<br />
| OS261 || OK TriCore [[#OS-Applications notes|<sup>[a]</sup>]]<br />
| GetApplicationID() shall return the application identifier to which the executing Task/ISR/hook belongs.<br />
|-<br />
| OS262 || OK<br />
| If no OS-Application is running, GetApplicationID() shall return INVALID_OSAPPLICATION.<br />
|-<br />
| OS514 || No scalability Classes support<br />
| Availability of GetApplicationID(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== CheckObjectAccess ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS256 || OK TriCore<br />
| CheckObjectAccess<br />
|-<br />
| OS271 || OK TriCore<br />
| If the OS-Application <ApplID> in a call of CheckObjectAccess() has access to the queried object, CheckObjectAccess() shall return ACCESS.<br />
|-<br />
| OS272 || OK TriCore<br />
| If the OS-Application <ApplID> in a call of CheckObjectAccess() has no access to the queried object, CheckObjectAccess() shall return NO_ACCESS.<br />
|-<br />
| OS423 || OK TriCore<br />
| If in a call of CheckObjectAccess() the object to be examined is not a valid object OR <ApplID> is invalid OR <ObjectType> is invalid THEN CheckObjectAccess() shall return NO_ACCESS.<br />
|-<br />
| OS519 || No scalability Classes support<br />
| Availability of CheckObjectAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== CheckObjectOwnership ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS017 || OK TriCore<br />
| CheckObjectOwnership<br />
|-<br />
| OS273 || OK TriCore<br />
| If the object ObjectType specified in a call of CheckObjectOwnership() exists, CheckObjectOwnership() shall return the identifier of the OS-Application to which the object belongs.<br />
|-<br />
| OS274 || OK TriCore<br />
| If in a call of CheckObjectOwnership() the specified object ObjectType is invalid OR the argument of the type (the “...”) is invalid, CheckObjectOwnership() shall return INVALID_OSAPPLICATION.<br />
|-<br />
| OS520 || No scalability Classes support<br />
| Availability of CheckObjectOwnership():Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== TerminateApplication ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS258 || OK TriCore<br />
| TerminateApplication<br />
|-<br />
| OS493 || OK TriCore<br />
| If the input parameter <Application> in a call of TerminateApplication() is not valid TerminateApplication() shall return E_OS_ID.<br />
|-<br />
| OS459 || OK TriCore<br />
| If the <RestartOption> in a call of TerminateApplication() is invalid, TerminateApplication() shall return E_OS_VALUE.<br />
|-<br />
| OS494 || OK TriCore<br />
| If the input parameter <Application> in a call of TerminateApplication() is valid AND the caller belongs to a non-trusted OS-Application AND the caller does not belong to <Application> TerminateApplication() shall return E_OS_ACCESS.<br />
|-<br />
| OS507 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_TERMINATED TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS508 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_RESTARTING and the caller does not belong to the <Application> then TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS548 || OK TriCore<br />
| If the state of <Application> in a call of TerminateApplication() is APPLICATION_RESTARTING AND the caller does belong to the <Application> AND the <RestartOption> is equal RESTART then TerminateApplication() shall return E_OS_STATE.<br />
|-<br />
| OS287 || OK TriCore<br />
| If the parameters in a call of TerminateApplication() are valid and the above criteria are met TerminateApplication() shall terminate <Application> (i.e. to kill all tasks, disable the interrupt sources of those ISRs which belong to the OS-Application and free all other OS resources associated with the application) AND shall activate the configured OsRestartTask of <Application> if <RestartOption> equals RESTART. If the <Application> is restarted, its state is set to APPLICATION_RESTARTING otherwise to APPLICATION_TERMINATED. If the caller belongs to <Application> TerminateApplication() shall not return, otherwise it shall return E_OK.<br />
|-<br />
| OS535 || OK TriCore<br />
| Caveats of TerminateApplication():<br />
* If no applications are configured the implementation shall make sure that this service is not available.<br />
* Tasks and interrupts that are owned by a trusted application can terminate any OS-Application. Tasks and interrupts that are owned by a non-trusted application can only terminate their owning OS-Application.<br />
|-<br />
| OS536 || No scalability Classes support<br />
| Availability of TerminateApplication(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== AllowAccess ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS501 || OK TriCore<br />
| AllowAccess<br />
|-<br />
| OS497 || OK TriCore<br />
| If the state of the OS-Application of the caller of AllowAccess() is not APPLICATION_RESTARTING AllowAccess() shall return E_OS_STATE.<br />
|-<br />
| OS498 || OK TriCore<br />
| If the state of the OS-Application of the caller of AllowAccess() is APPLICATION_RESTARTING, AllowAccess() shall set the state to APPLICATION_ACCESSIBLE and allow other OS-Applications to access the configured objects of the callers OS-Application.<br />
|-<br />
| OS547 || No scalability Classes support<br />
| Availability of AllowAccess(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== GetApplicationState ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS499 || OK TriCore<br />
| GetApplicationState<br />
|-<br />
| OS495 || OK TriCore<br />
| If the <Application> in a call of GetApplicationState() is not valid GetApplicationState() shall return E_OS_ID.<br />
|-<br />
| OS496 || OK TriCore<br />
| If the parameters in a call of GetApplicationState() are valid, GetApplicationState() shall return the state of OS-Application <Application> in <Value>.<br />
|-<br />
| OS537 || No scalability Classes support<br />
| Availability of GetApplicationState(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific StartupHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS539 || OK<br />
| Application specific StartupHook. The application specific StartupHook is always called after the standard StartupHook() (see OS236). If more than one OS-Application is configured which use startup hooks, the order of calls to the startup hooks of the different OS- Applications is not defined.<br />
|-<br />
| OS543 || No scalability Classes support<br />
| Availability of StartupHook_<App>(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific ErrorHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS540 || OK TriCore<br />
| Application specific ErrorHook. If the general ErrorHook() is configured, the general ErrorHook() is called before the application specific error hook is called (see OS246).<br />
|-<br />
| OS544 || OK TriCore<br />
| Availability of ErrorHook_<App>(): Available in Scalability Classes 3 and 4.<br />
|}<br />
<br />
=== Application specific ShutdownHook ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS541 || OK<br />
| Application specific ShutdownHook. If the general ShutdownHook() is configured, the general ShutdownHook() is called after all application specific shutdown hook(s) are called (see OS237). If more OS-Applications with an application specific shutdown hook exist the order of calls to these application specific shutdown hooks is not defined.<br />
|-<br />
| OS545 || No scalability Classes support<br />
| Availability of ShutdownHook_<App>(): Available in Scalability Classes 3 and 4. <br />
|}<br />
<br />
=== OS-Applications notes ===<br />
* [a] - Application-specific hook will be supported by TriCore full release.<br />
* [b] - Object protection will be introduced by TriCore full release, by now all objects are accessible by any OS-Application.<br />
* [c] - Termination of OS-Applications will be introduced by TriCore full release, is not supported yet.<br />
<br />
== Privileged mode ==<br />
<br />
Please see note [[#Privileged mode notes|<sup>[a]</sup>]].<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS058 || OK<br />
| If supported by hardware, the Operating System shall execute non-trusted OS-Applications in non-privileged mode.<br />
|-<br />
| OS096 || OK<br />
| As far as supported by hardware, the Operating System shall not allow non- trusted OS-Applications to access control registers managed by the Operating System.<br />
|-<br />
| OS245 || OK[[#Privileged mode notes|<sup>[b]</sup>]]<br />
| If an instruction exception occurs (e.g. division by zero) the operating system shall call the protection hook with E_OS_PROTECTION_EXCEPTION.<br />
|-<br />
| OS451 || OK<br />
| The Operating System shall allow to export services from trusted OS-Applications.<br />
|-<br />
| OS097 || OK<br />
| The Operating System shall provide a mechanism to call a trusted function from a (trusted or non-trusted) OS-Application.<br />
|-<br />
| OS100 || OK<br />
| If a called trusted function is not configured the Operating System shall call the ErrorHook with E_OS_SERVICEID.<br />
|-<br />
| OS226 || OK[[#Privileged mode notes|<sup>[b]</sup>]]<br />
| The Operating System shall execute an application-specific startup hook with the access rights of the associated OS-Application.<br />
|}<br />
<br />
=== CallTrustedFunction ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS097 || OK<br />
| CallTrustedFunction<br />
|-<br />
| OS265 || OK<br />
| If <FunctionIndex> is a defined function index, CallTrustedFunction() shall switch the processor into privileged mode AND shall call the function <FunctionIndex> out of a list of implementation specific trusted functions with disabled memory protection AND shall return E_OK after completion.<br />
|-<br />
| OS312 || OK<br />
| Caveats of CallTrustedFunction():<br />
* The called trusted function must conform to the following C prototype: void TRUSTED_<name_of_the_trusted_service>( TrustedFunctionIndexType,TrustedFunctionParameterRefType); (The arguments are the same as the arguments of CallTrustedFunction).<br />
* Normally, a user will not directly call this service, but it will be part of some standard interface, e.g. a standard I/O interface.<br />
* It is the duty of the called trusted function to check rights of passed parameters, especially if parameters are interpreted as out parameters.<br />
* It should be noted that the CallTrustedFunction() does not disable timing protection for the task which called the service. This may lead to timing faults (calls of the ProtectionHook()) even inside of a trusted OS-Application. It is therefore recommended to use CallTrustedFunction() only for stateless functions (e.g. functions which do not write or do not have internal states)<br />
|-<br />
| OS266 || OK [[#Privileged mode notes|<sup>[b]</sup>]]<br />
| When CallTrustedFunction() calls the function <FunctionIndex>, that function shall be executed with the same processor mode and memory protection boundaries as the OS-Application to which it belongs. It shall however retain the timing protection and service protection limitations of the calling Task or ISR, and the notion of "current application" shall remain that of the calling Task or Category 2 ISR.<br />
|-<br />
| OS364 || OK [[#Privileged mode notes|<sup>[b]</sup>]][[#Privileged mode notes|<sup>[c]</sup>]]<br />
| If CallTrustedFunction() calls the trusted function from a Category 2 ISR context, that function shall continue to run on the same interrupt priority and be allowed to call all system services defined for Category 2 ISR (see table in chapter 7.7.3.2).<br />
|-<br />
| OS365 || OK [[#Privileged mode notes|<sup>[b]</sup>]][[#Privileged mode notes|<sup>[c]</sup>]]<br />
| If CallTrustedFunction() calls the trusted function from a task context, that function shall continue to run on the same priority and be allowed to call all system services defined for tasks (see table in chapter 7.7.3.2).<br />
|}<br />
<br />
=== Privileged mode notes ===<br />
: [a] - In MPC5674F priviliged mode is enabled by the SC4 flag (This incomplete support of scalability classes have been removed in TriCore porting).<br />
: [b] - Supported only by TriCore implementation.<br />
: [c] - In MPC5674F a trusted function is executed in the security context of the calling function, although it runs in privileged mode.<br />
<br />
== Protection hook ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS099 || OK (See CheckTaskMemoryAccess() and CheckISRMemoryAccess())<br />
| The Operating System shall offer OS-Applications a service to check if a memory region is write/read/execute accessible from a Task/Category 2 OsIsr and also return information if the memory region is part of the stack space.<br />
|-<br />
| OS211 || OK TriCore<br />
| The Operating System shall execute the ProtectionHook() with the same permissions as the Operating System.<br />
|-<br />
| OS106 || OK TriCore<br />
| The Operating System shall perform one of the following reactions depending on the return value of the ProtectionHook():<br />
* Do nothing<br />
* Forcibly terminate the faulty Task/Category 2 OsIsr OR<br />
* Forcibly terminate the faulty OS-Application OR<br />
* Forcibly terminate the faulty OS-Application and restart the OS-Application. OR<br />
* Call ShutdownOS().<br />
|-<br />
| OS107 || OK TriCore<br />
| If no ProtectionHook() is configured and a protection error occurs, the Operating System shall call ShutdownOS().<br />
|-<br />
| OS475 || OK TriCore<br />
| If the reaction is to do nothing and the ProtectionHook() was not called with E_OS_PROTECTION_ARRIVAL then the Operating System shall call ShutdownOS()<br />
|-<br />
| OS243 || OK TriCore<br />
| If the reaction is to forcibly terminate the Task/Category 2 OsIsr and no Task or OsIsr can be associated with the error, the running OS-Application is forcibly terminated by the Operating System.<br />
|-<br />
| OS244 || OK TriCore<br />
| If the reaction is to forcibly terminate the faulty OS-Application and no OS- Application can be assigned, ShutdownOS()is called.<br />
|-<br />
| OS108 || OK TriCore<br />
| If the Operating System forcibly terminates a task, it terminates the task (no PostTaskHook() for the task will be called), releases all allocated OSEK resources and calls EnableAllInterrupts()/ / ResumeOSInterrupts() ResumeAllInterrupts() if the Task called DisableAllInterrupts() / / SuspendAllInterrupts() before without the SuspendOSInterrupts() EnableAllInterrupts()/ / corresponding ResumeOSInterrupts() ResumeAllInterrupts() call.<br />
|-<br />
| OS109 || OK TriCore<br />
| If the Operating System forcibly terminates an interrupt service routine, it clears the interrupt request, aborts the interrupt service routine (The interrupt source stays in the current state.) and releases all OSEK resources the interrupt service routine has allocated and calls EnableAllInterrupts() / ResumeOSInterrupts() / ResumeAllInterrupts() if the interrupt called DisableAllInterrupts() / / SuspendAllInterrupts() before without the SuspendOSInterrupts() corresponding EnableAllInterrupts()/ / ResumeOSInterrupts() ResumeAllInterrupts() call.<br />
|-<br />
| OS538 || OK TriCore<br />
| Protection Hook Depending on the return value the Operating System module will either:<br />
* forcibly terminate the Task/Category 2 ISR which causes the problem OR<br />
* forcibly terminate the OS-Application the Task/Category 2 ISR belong (optional with restart) OR<br />
* shutdown the system OR<br />
* do nothing (see 7.8.2)<br />
|-<br />
| OS308 || OK TriCore<br />
| If ProtectionHook() returns an invalid value, the Operating System module shall take the same action as if no protection hook is configured.<br />
|-<br />
| OS542 || No scalability Classes support<br />
| Availability of ProtectionHook(): Available in Scalability Classes 2, 3 and 4.<br />
|}<br />
<br />
= Other New Autosar APIs =<br />
<br />
=== GetISRID ===<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS511 || OK<br />
| GetISRID<br />
|-<br />
| OS263 || OK<br />
| If called from category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID() shall return the identifier of the currently executing ISR.<br />
|-<br />
| OS264 || partial<br />
| If its caller is not a category 2 ISR (or Hook routines called inside a category 2 ISR), GetISRID() shall return INVALID_ISR.<br />
|-<br />
| OS515 || OK (?)<br />
| Availability of GetISRID(): Available in all Scalability Classes.<br />
|}<br />
<br />
= Multi-Core =<br />
<br />
== Basic Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS567 || OK (We have some doubts relates to this, but it should be OK)<br />
| The generated part of the OS is derived from a single configuration that contains the relevant information for all cores. This implies, that IDs (e.g. TASKID, RESOURCEID, …) are unique across cores. Every ID shall refer exactly to one entity independent from the core on which the entity is accessed. This applies also to objects that cannot be shared between cores. (BSW4080008)<br />
|-<br />
| OS568 || OK<br />
|Implementations shall be able to independently execute a TASK or an ISR on each started AUTOSAR OS core in parallel. (BSW4080001)<br />
|-<br />
| OS569 || OK<br />
|The scheduling strategy as defined in AUTOSAR OS shall apply for each individual core in a Multi-Core system, for the TASKs and ISR assigned to the core. (BSW4080001, BSW4080013)<br />
|-<br />
| OS570 || OK<br />
| All TASKs that are assigned to the same OS-Application shall execute on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS571 || OK<br />
| All ISRs that are assigned to the same OS-Application shall execute on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS572 || N.A. in Supported Architectures (PPC TriCore)<br />
| ISR balancing (if supported by the HW) shall be switched off at boot time by the OS. (BSW4080005, BSW4080006)<br />
|-<br />
| OS764 || No scalability classes support (OS-Applications are enabled when configurated).<br />
| The OS module shall support OS-Applications in case of Multi-Core also for SC1 and SC2.<br />
|-<br />
| OS763 || No scalability classes support (But we don't understend this requirement).<br />
| In an SC1 system standard mode shall be possible.<br />
|-<br />
| OS573 ||<br />
| The binding of OS-Applications to cores shall be configured within the OS-Application container. A new configuration item: OsApplicationCoreAssignment{CORE} within the OS-Application container shall be used to define the core to which the OS-Application is bound. The OS generator will map the configuration parameter “CORE” to a certain core, so that all OS-Applications with the same configuration parameter reside on the same core. (BSW4080003, BSW4080005)<br />
|-<br />
| OS623 || OK<br />
| The OS API function CallTrustedFunction shall return E_OS_ACCESS in extended status if the target trusted function is part of an OS-Application on another core. (BSW4080013)<br />
|-<br />
|}<br />
<br />
== Multi-Core start-up Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS574 || OK<br />
| The master core shall be able to activate cores. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS575 || OK<br />
| Any slave core shall be able to activate cores. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS576 || OK<br />
| It shall be allowed to use only a subset of the cores available on a μC for the AUTOSAR system. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS577 || OK (TriCore e PPC e200zx are naturally in Master-Slave configuration)<br />
| The cores shall boot in master-slave mode. If this is not supported by the hardware, it shall be that the cores boot in parallel and emulate the behavior of a master-slave system.. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS578 || N.A.<br />
| In case of an emulation a slave core (CoreS), which is controlled by the AUTOSAR OS (AUTOSAR core), shall not enter the main function before another<br />
core has activated the slave core by means of StartCore(CoreS). (BSW4080006)<br />
|-<br />
| OS579 || OK<br />
| All cores that belong to the AUTOSAR system shall be synchronized within the StartOS function before the scheduling is started and after the global<br />
StartupHook is called.. (BSW4080001, BSW4080006)<br />
|-<br />
| OS580 || OK<br />
| All cores that belong to the AUTOSAR system shall be synchronized within the StartOS function before the scheduling is started and after the global<br />
StartupHook is called.. (BSW4080006)<br />
|-<br />
| OS581 || OK TriCore<br />
| The global StartupHook shall be called on all cores immediately after the first synchronisation point (BSW4080006)<br />
|-<br />
| OS582 || OK TriCore<br />
| The OS-Application-specific StartupHooks shall be called after the global StartupHook but only on the cores to which the OS-Application is bound (BSW4080006, BSW4080008)<br />
|-<br />
| || OK TriCore<br />
| The AUTOSAR OS API provides a StartCore function to start the cores under its control. The StartCore function takes a scalar value parameter of type CoreIDType, specifying the core that shall be started. StartCore can be called more than once on the master core and also on slave cores. Each core can only be started once, however The StartOS function shall be called on all cores that have been activated by StartCore. It is not allowed to call StartCore from a core that has already called StartOS. Cores that belong to the AUTOSAR system shall be started by the designated AUTOSAR OS API service StartCore.<br />
|-<br />
| OS583 || OK TriCore<br />
| The number of cores that can be controlled by the AUTOSAR OS shall be configured offline. A new configuration item (OsNumberOfCores) within the “OsOS” container is used to specify the maximum number of cores that are controlled by the AUTOSAR OS. If no value for (OsNumberOfCores) has been specified the number of cores shall be one. (BSW4080001, BSW4080011) <br />
|-<br />
| OS584 || OK TriCore<br />
| The AUTOSAR OS shall provide a function called StartNonAutosarCore that can be used to start cores, which are not controlled by the AUTOSAR OS. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS585 || OK TriCore<br />
| It shall be possible to activate cores that are not controlled by the AUTOSAR OS before and after calling StartOS. (BSW4080006, BSW4080026, BSW4080027)<br />
|-<br />
| OS606 || OK TriCore<br />
| The AUTOSAR specification does not support the activation of AUTOSAR cores after calling StartOS on that core. If StartCore is called after StartOS it shall return with E_OS_ACCESS in extended status. (BSW4080001)<br />
|-<br />
| OS607 || OK TriCore<br />
| StartOS shall start the OS on the core on which it is called. (BSW4080006, BSW4080013)<br />
|-<br />
| OS608 || OK TriCore<br />
| If more than one core calls StartOS with an AppMode other than “DONOTCARE”, the AppModes shall be the same. StartOS shall check this at the first synchronisation point. In case of violation, StartOS shall not start the scheduling, shall not call any StartupHooks, and shall enter an endless loop on every core. (BSW4080006)<br />
|-<br />
| OS609 || OK TriCore<br />
| If StartOS is called with the AppMode “DONOTCARE” the application mode of the other core(s) (differing from “DONOTCARE”) shall be used. (BSW4080006)<br />
|-<br />
| OS610 || OK TriCore<br />
| At least one core shall define an AppMode other than “DONOTCARE”. (BSW4080006)<br />
|-<br />
| OS611 || OK TriCore<br />
| If the IOC is configured, StartOS shall initialize the data structures of the IOC. (BSW4080020)<br />
|-<br />
| OS668 || OK<br />
| The AUTOSAR Operating System shall automatically activate all auto-start TASKs configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
| OS669 || OK<br />
| The AUTOSAR Operating System shall automatically activate all auto-start ALARMs configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
| OS670 || Not Schedule tables supported yet<br />
| The AUTOSAR Operating System shall automatically activate all auto-start schedule tables configured for the current AppMode, with respect to the core, before the initial start of the scheduling. (BSW4080006)<br />
|-<br />
|}<br />
<br />
== Multicore Shutdown Requirements ==<br />
<br />
AUTOSAR supports two shutdown concepts, the synchronized shutdown and the individual shutdown concept. While the synchronized shutdown is triggered by the new API function '''ShutdownAllCores()''', the individual shutdown is invoked by the existing API function '''ShutdownOS()'''.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS586 || OK TriCore<br />
| During the shutdown, the OS-Application specific ShutdownHook shall be called on the core on which the corresponding OS-Application is bound. (BSW4080007)<br />
|- <br />
| OS587 || OK TriCore (if ShutdownAllCores has been called)<br />
| Before calling the global ShutdownHook, all cores shall be synchronized. (BSW4080007)<br />
|- <br />
| OS588 || OK<br />
| The global ShutdownHook shall be called on all cores. (BSW4080007)<br />
|-<br />
| OS762 || OK TriCore (fullfilled by ProtectionHook implementation)<br />
| In cases where the OS detects a fatal internal error all cores shall be shutdown.<br />
|-<br />
| OS616 || OK<br />
| ShutdownOS shall be callable from each core running an AUTOSAR OS. (BSW4080001, BSW4080007)<br />
|-<br />
| OS617 || OK<br />
| ShutdownOS shall shutdown the core on which it was called. (BSW4080007)<br />
|-<br />
| OS618 || OK<br />
| The OS shall not start TASKs of an OS-Application once the shutdown procedure has been entered on a particular core. (BSW4080013)<br />
|-<br />
| OS619 || OK<br />
| The AUTOSAR OS function ShutdownOS shall be callable in parallel on multiple cores. (BSW4080013)<br />
|-<br />
| OS620 || OK TriCore<br />
| ShutdownOS shall release all spinlocks which are occupied by the calling core. (BSW4080021)<br />
|-<br />
| OS621 || OK TriCore<br />
| ShutdownAllCores shall be callable from each core running an AUTOSAR OS. (BSW4080007)<br />
|-<br />
|}<br />
<br />
== OS Other Services Requirements ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS589 || OK TriCore<br />
| All functions that are not allowed to operate cross core shall return E_OS_CORE in extended status if called with parameters that require a cross core operation. (BSW4080013)<br />
|-<br />
| OS590 || OK<br />
| The OS service “DisableAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS591 || OK<br />
| The OS service “EnableAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS592 || OK<br />
| The OS service “SuspendAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS593 || OK<br />
| The OS service “ResumeAllInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS594 || OK<br />
| The OS service “SuspendOSInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS595 || OK<br />
| The OS service “ResumeOSInterrupts” shall only affect the core on which it is called. (BSW4080013)<br />
|-<br />
| OS596 || OK<br />
| It shall be possible to activate a TASK that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080001, BSW4080015)<br />
|-<br />
| OS598 || OK TriCore (RPC Dispactcher)<br />
| The call of ActivateTask across cores shall behave synchronously, i.e. a call returns after the task has been activated or an error has been detected. It shall not be possible to continue execution on the calling core before ActivateTask is accomplished on the remote core. (BSW4080015)<br />
|-<br />
| OS599 || OK TriCore (RPC Dispactcher)<br />
| In case of an error when calling ActivateTask across cores, the error handler shall be called on the core on which ActivateTask was originally called. (BSW4080015)<br />
|-<br />
| OS600 || OK<br />
| It shall be possible to chain a TASK that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080001, BSW4080015)<br />
|-<br />
| OS602 || OK<br />
| It shall be possible to set an EVENT that is part of an OS-Application located on another core, as long as the assigned access rights allow it. (BSW4080016)<br />
|-<br />
| OS604 || OK TriCore (RPC Dispactcher)<br />
| The call of SetEvent across cores shall behave synchronously, i.e. a call returns after the Event has been set or an error has been detected. It shall not be possible to continue execution on the calling core before SetEvent is accomplished on the remote core. (BSW4080016)<br />
|-<br />
| OS605 || OK TriCore (RPC Dispactcher [[#MultiCore notes|<sup>[a]</sup>]])<br />
| In case of an error when calling SetEvent across cores, the error handler shall be called on the core on which SetEvent was originally called. (BSW4080016)<br />
|-<br />
| OS612 || OK TriCore<br />
| In extended status TerminateTask / ChainTask shall return with an error (E_OS_SPINLOCK), which can be evaluated in the application. (BSW4080021)<br />
|-<br />
| OS613 || OK TriCore<br />
| Spinlocks occupied by TASKS that are terminated in response to a protection hook shall be automatically released. This applies also to the case in which an OS-Application is terminated. (BSW4080021)<br />
|-<br />
| OS614 || OK TriCore<br />
| TerminateApplication shall check if any of the TASKs in the OS-Application have occupied a spinlock. If so, the spinlocks shall be released.(BSW4080021)<br />
|-<br />
| OS615 ||<br />
| If TerminateApplication(A) is called in parallel from different cores, the OsApplication “A” is terminated by the first call, any subsequent calls will return with 'E_OK' in standard and extended status without doing anything, until the termination is completed.<br />
|-<br />
| OS622 || OK<br />
| The AUTOSAR Operating System WaitEvent API service shall check if it has been called while the calling TASK has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the TASK shall not enter the wait state. (BSW4080021)<br />
|-<br />
| OS624 || OK<br />
| The AUTOSAR Operating System Schedule API service shall check if it has been called while the calling TASK has occupied a spinlock. In extended status an error E_OS_SPINLOCK shall be returned and the scheduler shall not be called. (BSW4080021)<br />
|-<br />
| OS629 || OK<br />
| A COUNTER belonging to an OS-Application shall be incremented by the core on which the OS-Application resides. The COUNTER shall not be incremented by other cores. (BSW4080013)<br />
|-<br />
| OS630 || OK<br />
| It shall not be allowed to drive a schedule table from a COUNTER, which is assigned to a different core. (BSW4080013)<br />
|-<br />
| OS631 || OK<br />
| It shall not be allowed to drive an ALARM from a COUNTER, which is assigned to a different core. (BSW4080013)<br />
|-<br />
| OS632 || OK<br />
| If an ALARM expires, it shall be allowed to activate a TASK on a different core. (BSW4080018)<br />
|-<br />
| OS633 || OK<br />
| If an ALARM expires, it shall be allowed to set an EVENT on a different core. (BSW4080018)<br />
|-<br />
| OS634 || OK<br />
| The AUTOSAR Operating System shall process an ALARM on the core on which its corresponding OS-Application resides. (BSW4080018)<br />
|-<br />
| OS635 || OK<br />
| ALARM callbacks shall be executed on the core to which the ALARM is bound. This is only applicable to SC1 systems, because otherwise Alarm Callback<br />
are not allowed (OS242). (BSW4080013)<br />
|-<br />
| OS636 || OK<br />
| SetRelAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|-<br />
| OS637 || OK<br />
| SetAbsAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS638 || OK<br />
| CancelAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS639 || OK<br />
| GetAlarmBase shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
| OS640 || OK<br />
| GetAlarm shall also work on an ALARM that is bound to another core. (BSW4080013)<br />
|- <br />
|}<br />
<br />
== MultiCore notes ==<br />
: [a] - [[Infineon_Aurix#Multicore_Autosar_OS_Support|New RPC MultiCore dispatcher]]<br />
<br />
== Other AUTOSAR Multicore API ==<br />
<br />
=== GetCoreID ===<br />
<br />
Every HW assigns a unique physical Id to a core. The physical core Id is the only way to distinguish between cores. <br />
The physical core Ids of a μC are not necessarily consecutive and do not necessarily start with zero.<br />
The SW requires a mechanism to identify a core, e.g. to use core specific variables. Because the physical core Id usually can not be used as a direct array index for core specific variables, a logical CoreID is necessary to map physical core Ids to array indexes. In the SW it is not necessary to know the physical core Id, the logical CoreID is sufficient.<br />
The mapping of OSApplications and other SW objects to cores is specified in the configuration files. All such mappings shall be HW independent and therefore shall not be based on the physical core Id but on the logical CoreID. The function GetCoreID internally maps the physical core Id to the logical CoreID. The mapping is implementation specific. GetCoreID can be either a C function or a macro.<br />
<br />
'''N.B''' In Erika with code replication the core ID is not a real issue.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS625 || OK TriCore<br />
| The AUTOSAR Operating System API function GetCoreID shall be callable before StartOS. (BSW4080006)<br />
|-<br />
| OS626 || OK TriCore<br />
| An implementation shall offer a function GetNumberOfActivatedCores that returns the number of cores running the AUTOSAR OS. (BSW4080001)<br />
|-<br />
| OS627 || OK TriCore<br />
| An implementation shall define a set of constants OS_CORE_ID_<No> of the type CoreIDType with <No> a value from 0 to “OsNumberOfCores -1. (BSW4080001)<br />
|-<br />
| OS628 || OK TriCore<br />
| An implementation shall offer a constant OS_CORE_ID_MASTER of the type CoreIDType that refers to the master core. (BSW4080001)<br />
|}<br />
<br />
== Spinlocks ==<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS648 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a spinlock mechanism that works across cores. (BSW4080018, BSW4080021)<br />
|-<br />
| OS649 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a GetSpinlock function which occupies a spinlock. If the spinlock is already occupied, GetSpinlock shall<br />
keep on trying to occupy the spinlock until it succeeds. (BSW4080018, BSW4080021)<br />
|-<br />
| OS650 || OK TriCore<br />
| GetSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS651 || OK TriCore<br />
| GetSpinlock shall be callable from ISR2 level. The behavior of GetSpinlock is undefined if called from a category 1 ISR. (BSW4080021)<br />
|-<br />
| OS652 || OK TriCore (With Trivial spinlocks)<br />
| The AUTOSAR Operating System shall provide a TryToGetSpinlock function which occupies a spinlock. If the spinlock is already occupied by a TASK,<br />
TryToGetSpinlock shall return. (BSW4080018, BSW4080021)<br />
|-<br />
| OS653 || OK TriCore<br />
| TryToGetSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS654 || OK TriCore<br />
| TryToGetSpinlock shall be callable from ISR2 level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS655 || OK TriCore<br />
| The AUTOSAR Operating System shall provide a ReleaseSpinlock function which releases an occupied spinlock. If the spinlock is not occupied an error<br />
shall be returned. (BSW4080018, BSW4080021)<br />
|-<br />
| OS656 || OK TriCore<br />
| ReleaseSpinlock shall be callable from TASK level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS657 || OK TriCore<br />
| ReleaseSpinlock shall be callable from ISR2 level. (BSW4080018, BSW4080021)<br />
|-<br />
| OS658 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if a TASK tries to occupy a spinlock that is assigned to a TASK/ISR2 on the same core (including<br />
itself). (BSW4080018, BSW4080021)<br />
|-<br />
| OS659 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if an ISR2 tries to occupy a spinlock that is assigned to a TASK/ISR2 on the same core.<br />
(BSW4080018, BSW4080021)<br />
|-<br />
| OS660 || OK TriCore<br />
| A unique order in which multiple spinlocks can be occupied by a TASK/ISR2 should be configurable in the AUTOSAR Operating System. This might<br />
be realized by the configuration item (OsSpinlockSuccessor{NEXT_SPINLOCK}) where “NEXT_SPINLOCK” refers to the consecutive spinlock. (See chapter 10.2.5) (BSW4080018, BSW4080021)<br />
|-<br />
| OS661 || OK TriCore<br />
| The AUTOSAR Operating System shall generate an error if a TASK/ISR2 that currently holds a spinlock tries to seize another spinlock that has not been<br />
configured as a direct or indirect successor of the latest acquired spinlock (by means of the OsSpinlockSuccessor configuration parameter) or if no successor is configured. (BSW4080018, BSW4080021)<br />
|-<br />
|}<br />
<br />
= Inter-OS-Application Communicator (IOC) Requirements =<br />
<br />
IOC stands for Inter OS-Application Communicator. The "IOC" is responsible for the communication between OS-Applications and in<br />
particular for the communication crossing core or memory protection boundaries. It's internal functionality is closely connected to the Operating System.<br />
<br />
Memory protection boundaries are a characteristic of OS-Applications and special communication mechanisms are needed to cross them.<br />
Multi-Core systems may also need additional measures to make communication between cores safe.<br />
<br />
The IOC provides communication services between OS-Applications and in particular over core boundaries in Multi-Core systems. Because the cross-core communication is always an inter-OS-Application communication, the two mechanisms are combined. An inter OS-Application communication may not necessarily require a cross core communication, however.<br />
<br />
In systems with only one core, the IOC can be omitted completely, if just one OS-Application is available, or if no OS-Application uses memory protection mechanisms.<br />
<br />
'''N.B''' Since a lot of Code of IOC is configurated and generated starting from RTE configuration, it doesn't make sense generate a whole IOC system without a complete RTE generator. But '''we choiced the cross-boundaries communication mechanism''' that is the heart of IOC. The same mechanism is employed to implement OS Services remote invocation.<br />
<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
!ID !! State !! Description<br />
|-<br />
| OS671 ||<br />
| The IOC implementation shall be part of the Operating System The IOC is a third type of communication, in addition to:<br />
* Intra OS-Application communication: Always handled within the RTE<br />
* Inter ECU communication: already available via well defined interfaces to the communication stack (COM).<br />
(BSW4080020)<br />
|-<br />
|}</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=Erika_AUTOSAR_OSErika AUTOSAR OS2015-07-24T09:29:10Z<p>Eguidieri: /* TRSUTED OS-Application & Trusted Services (TRUSTED_FUNCTION) */</p>
<hr />
<div>= Multicore Autosar OS Support =<br />
<br />
ERIKA support multicore environments a way before than the first Autosar Multicore OS Release. So it happened that the historical [[ERIKA multicore support]] addresses some of the same requiremets of AUTOSAR Multicore OS with a completely different policy.<br />
<br />
In detail all the primitives calls on other core, with traditional implementation, called '''Remote Notifications''' or '''RN''', are done '''asynchronously''' with a fire and forget policy. This approach reduce latency to minimun, but, on the other hand, don't give the opportunity to check for errors in the call site.<br />
<br />
Autosar, that take into account a way more code consistency and reliability than efficiency, requires that all the primitives calls on others cores are '''synchronous''' giving the opportunity to caller code to correctly handle errors.<br />
<br />
To implements Autosar OS requirements a completly new multicore dispatcher have been implemented. This have been called<br />
'''ERIKA Autosar RPC''' (Remote Procedure Call).<br />
<br />
== Difference between the traditional RN implementation and the new RPC implementation ==<br />
The '''RN''' implementation is the original implementation done in 2002 of the MSRP protocol proposed in the paper<br />
<br />
Minimizing memory utilization of real-time task sets in single and multi-processor systems-on-a-chip<br />
P Gai, G Lipari, M Di Natale<br />
Real-Time Systems Symposium, 2001.(RTSS 2001). Proceedings. 22nd IEEE, 73-83<br />
<br />
which included the following features:<br />
<br />
* ASYNCHRONOUS remote activation of tasks. Activations are queued for later processing. Spin lock time is minimized. Local primitives returns E_OK despite the result of the remote activation (errors must be caught using ErrorHook!)<br />
* Queuing spin lock implemented using the algorithm presented in<br />
G. Graunke and S. Thakkar, Synchronization algorithms for shared memory multiprocessors. IEEE Computer, 23(6):60-69, June 1990<br />
* automatic detection from the OIL file whether resources are global or local. That is, GetResource and ReleaseResource where implementing an additional spin-lock when the resource was global. The idea was that the system allowed migration of tasks from one CPU to another without changing the OS code.<br />
<br />
All those points have been partially dropped on some architectures due to some of the requirements of AUTOSAR. In particular, spin-locks have a separate API (so GetResource and ReleaseResource cannot call implicitly a spinlock), and queuing spin-lock is not in the standard and is also quite difficult to implement in an efficient way considering that in some situazion a task can be removed from spinning.<br />
<br />
As for the first point, AUTOSAR mandates the fact that priomitives should return the status of the execution of the primitive, ALSO if the execution happens on the remote core. This implies that the remote activations must be SYNCHRONOUS. That is the reason why we created the '''RPC''' implementation, which has the following features:<br />
<br />
* SYNCHRONOUS remote activation of tasks<br />
* Normal (no protocol) spin-locks to comply with AUTOSAR<br />
* no detection of remote resources, which... does not exist in AUTOSAR<br />
<br />
Final note on interprocessor interrupt priorities:<br />
* the interprocessor IRQ must be an ISR2<br />
* on RN, the interprocessor IRQ can be the LOWEST priority interrupt, as the requests are queued and since the spin lock time is independent of the priority of the IRQ.<br />
* on RPC, the spin-lock time highly depends on the interprocessor IRQ RESPONSE TIME, which is affected by its priority. Therefore, the interprocessor Interrupt should have a HIGH priority, and this means that mopre and more IRQs must become ISR2 (remember ISR1 must have highet priority than ISR2), making the implementation more and more inefficient.<br />
<br />
<br />
== How to select the traditional RN implementation and the new RPC implementation ==<br />
Both traditional and the new dispatcher are available for Infineon AURIX and Freescale PowerPC (MPC5777C). You can switch between them in OIL with the REMOTENOTIFICATION oil field.<br />
<br />
REMOTENOTIFICATION = USE_RN;<br />
<br />
Enable traditional '''Remote Notification''' dispatcher. It's the default value, so you don't need to write this.<br />
<br />
REMOTENOTIFICATION = USE_RPC;<br />
<br />
Enable the new '''AUTOSAR Remote Procedure Call''' dispatcher.<br />
<br />
Currently with the new RPC dispatcher you can execute on remote cores all the following primitives:<br />
<br />
* ActivateTask<br />
* ChainTask (Terminate local TASK but can schedule on remote core)<br />
* GetTaskState<br />
* SetEvent<br />
* GetAlarmBase<br />
* GetAlarm<br />
* SetRelAlarm<br />
* SetAbsAlarm<br />
* CancelAlarm<br />
* GetCounterValue<br />
* GetElapsedValue<br />
* ShutdownOS ( with new ShutdownAllCores API )<br />
<br />
So in addition to TASK and EVENT primitives, the new muticore dispatcher support Counters and Alarms as required by Autosar specifications. Multicore awareness have been added to ShutdownOS to fulfill multicore AUTOSAR shutdown sequence. <br />
<br />
== New Multicore API ==<br />
<br />
AUTOSAR expect a master/slaves multicore enviroment that naturally fit AURIX architecture.<br />
New API to start and stops slave cores specified in AUTOSAR v4.0 rev 3.0 have been added:<br />
<br />
*'''StartCore''': This function starts the core specified by the parameter CoreID. The OUT parameter allows the caller to check whether the operation was successful or not. If a core is started by means of this function '''StartOS''' shall be called on the core. It is not supported to call this function after '''StartOS()'''.<br />
*'''StartNonAutosarCore''': The function starts the core specified by the parameter CoreID. It '''is allowed''' to call this function after '''StartOS()'''. The OUT parameter allows the caller to check whether the operation was successful or not. It is '''not allowed to call StartOS''' on cores activated by '''StartNonAutosarCore'''.<br />
*'''GetNumberOfActivatedCores''': returns the number of cores activated by the StartCore function. This function might be a macro<br />
*'''GetCoreID''': The function returns a unique core identifier.<br />
*'''ShutdownAllCores''' : After this service the OS on all AUTOSAR cores is shut down. Allowed at TASK level and ISR level and also internally by the OS. The function will never return. The function will force other cores into a shutdown.<br />
<br />
== New Spinlocks API ==<br />
<br />
Support for AUTOSAR Spinlock API have been added. OIL implementation have been extended to support Spinlocks configuration.<br />
<br />
There's two spinlocks behaviour modes: '''SINGLE''' and '''ORDERED'''. If '''SINGLE''' mode is configured a core get an error if, holding a spinlock, try to get access to another one. If '''ORDERED''' mode is configurated the core get this error only if it try to get spinlocks out of the order (see AUTOSAR documentation paragraph 7.9.29 The spinlock mechanism).<br />
<br />
To configure spinlocks in '''SINGLE''' mode, just don't provide any order:<br />
<br />
SPINLOCK spinlock_1 { };<br />
SPINLOCK spinlock_2 { };<br />
SPINLOCK spinlock_3 { };<br />
<br />
To configure spinlocks in '''ORDERED''' mode provide a '''complete ordering''':<br />
<br />
SPINLOCK spinlock_1 { NEXT_SPINLOCK=spinlock_2; };<br />
SPINLOCK spinlock_2 { NEXT_SPINLOCK=spinlock_3; };<br />
SPINLOCK spinlock_3 { };<br />
<br />
<br />
Provided AUTOSAR API to interact with Spinlocks are:<br />
<br />
*'''GetSpinlock ''': Tries to occupy a spin-lock variable. If the function returns, either the lock is successfully taken or an error has occurred. The spinlock mechanism is an active polling mechanism. The function does not cause a de-scheduling.<br />
*'''ReleaseSpinlock''': Releases a spinlock variable that was occupied before. Before terminating a TASK all spinlock variables that have been occupied with GetSpinlock() shall be released. Before calling WaitEVENT all Spinlocks shall be released.<br />
*'''TryToGetSpinlock''': Has the same functionality as GetSpinlock with the difference that if the spinlock is already occupied by a TASK on a different core the function sets the OUT parameter to TRYTOGETSPINLOCK_NOSUCCESS and returns with E_OK.<br />
<br />
Two spinlocks implementation are provided. The '''trivial''' one that does not guarentee upper bond wait, but that can implement the try-to-get behaviour. And the '''queued''' one that prevent from starvation queuing requests, but cannot implement try-to-get behaviour (TryToGetSpinlock API is mapped into GetSpinlock).<br />
<br />
To enable '''queued spinlocks''' just add to the OIL:<br />
<br />
SPINLOCKS = QUEUED;<br />
<br />
IMPORTANT: QUEUED spinlocks are not available for Erika on PowerPC.<br />
<br />
= Autosar Schedule Tables =<br />
<br />
Autosar Specification add to OSEK Alarms, another activities schedulator called Schedule Tables.<br />
It is possible to implement a statically defined activities schedulator, that activate TASKs and set EVENTs, using an<br />
OSEK counter and a series of auto started alarms. In the simple case, this can be achieved by specifying that the alarms are not modified once started. Run-time modifications can only be made if relative synchronization between alarms can be<br />
guaranteed.This typically means modifying the alarms while associated counter tick interrupts are disabled.<br />
Schedule Tables address the synchronization issue by providing an encapsulation of a statically defined set of expiry points. Each expiry point defines:<br />
<br />
* One or more actions that must occur when it is processed where an action is the activation of a task or the setting of an event.<br />
* An offset in ticks from the start of the schedule table.<br />
<br />
Each schedule table has a duration in ticks. The duration is measured from zero and<br />
defines the modulus of the schedule table.<br />
<br />
At runtime, the Operating System module will iterate over the schedule table, processing each expiry point in turn. The iteration is driven by an OSEK counter. It therefore follows that the properties of the counter have an impact on what is possible to configure on the schedule table.<br />
<br />
== Schedule Table APIs ==<br />
<br />
All the Schedule Table API not related to the schedule table syncronization are implemented (see [[Erika_AUTOSAR_OS#Schedule_Table_Synchronization |Schedule Table Synchronization]]).<br />
<br />
* '''StartScheduleTableRel( ScheduleTableType ScheduleTableID, TickType Offset )''': This service starts the processing of a schedule table at "Offset" relative to the "Now" value on the underlying counter.<br />
<br />
* '''StartScheduleTableAbs( ScheduleTableType ScheduleTableID, TickType Start )''': This service starts the processing of a schedule table at an absolute value "Start" on the underlying counter.<br />
<br />
* '''StopScheduleTable( ScheduleTableType ScheduleTableID )''': This service cancels the processing of a schedule table immediately at any point while the schedule table is running.<br />
<br />
* '''GetScheduleTableStatus( ScheduleTableType ScheduleTableID, ScheduleTableStatusRefType ScheduleStatus )''': This service queries the state of a schedule table (also with respect to synchronization).<br />
<br />
* '''NextScheduleTable(ScheduleTableType ScheduleTableID_From, ScheduleTableType ScheduleTableID_To)''': This service switches the processing from one schedule table to another schedule table.<br />
<br />
'''N.B.''' The best place to start to understand how schedule tables API works is:<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Schedule Tables/Schedule Table example''<br />
<br />
== Schedule Table OIL Configuration ==<br />
<br />
This is an OIL example to how configure a Schedule Table with OIL<br />
<br />
SCHEDULETABLE SchedTab1 {<br />
COUNTER = system_timer;<br />
DURATION = 400;<br />
REPEATING = FALSE;<br />
AUTOSTART = TRUE {<br />
TYPE = ABSOLUTE;<br />
START_VALUE = 0;<br />
};<br />
EXPIRE_POINT = ACTION {<br />
EXPIRE_VALUE = 100;<br />
ACTION = ACTIVATETASK { TASK = Task2; };<br />
ACTION = SETEVENT { TASK = Task1; EVENT = ButtonEvent; };<br />
SYNC_ADJUSTMENT = FALSE;<br />
};<br />
EXPIRE_POINT = ACTION {<br />
EXPIRE_VALUE = 300;<br />
ACTION = SETEVENT { TASK = Task1; EVENT = TimerEvent; };<br />
SYNC_ADJUSTMENT = FALSE;<br />
};<br />
LOCAL_TO_GLOBAL_TIME_SYNCHRONIZATION = FALSE;<br />
};<br />
<br />
Following the SCHEDULETABLE field explaination<br />
* '''COUNTER''': The Schedule Table '''driving counter'''<br />
* '''DURATION''': The Schedule Table duration (in counter ticks), MUST be greater or equal to the last EXPIRE_POINT.EXPIRE_VALUE<br />
* '''REPEATING''': Flag if the Schedule Table is one shot or have to be restarted when it terminated (after DURATION ticks).<br />
* '''AUTOSTART''': Flag if the Schedule Table have to be started automatically during ''StartOs'', in which way '''TYPE''': (ABSOLUTE, RELATIVE) and with wich Start Value of the counter (or Offset if the TYPE is RELATIVE). In ERIKA where, all the counters are software the two autostartig type generate the same result. <br />
* '''EXPIRE_POINT''': '''List of EXPIRY_POINT''' that represent the Schedule Table, any of which is composed by an '''EXPIRE_VALUE''' in ticks (when the expiry points happens) a '''list of ACTIONS''' (''equals to ALARMs Actions'') and by a flag that enable synchronization not yet supported (SYNC_ADJUSTMENT. Only FALSE value is supported, that is the default so the field can be omitted).<br />
'''LOCAL_TO_GLOBAL_TIME_SYNCHRONIZATION''': Flag that enable External Syncronization, not supported yet. (Only FALSE value is supported, that is the default so the field can be omitted).<br />
<br />
'''N.B.''' The best place to start to understand how schedule tables OIL configuration works is:<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Schedule Tables/Schedule Table example''<br />
<br />
== Schedule Table Synchronization ==<br />
<br />
The absolute time at which the Initial Expiry Point on a schedule table is processed is under user control. However, if the schedule table repeats then it is not guaranteed that the absolute count value at which the initial expiry point was first processed is the same count value at which it is subsequently processed. This is because the duration of the schedule table need not be equal to the counter modulus.<br />
In many cases it may be important that schedule table expiry points are processed at specific absolute values of the underlying counter. This is called synchronization. Typical use-cases include:<br />
<br />
* Synchronization of expiry points to degrees of angular rotation for motor management<br />
* Synchronizing the computation to a global (network) time base.<br />
<br />
Note that in AUTOSAR, the Operating System does not provide a global (network) time source because<br />
<br />
* 1. A global time may not be needed in many cases<br />
* 2. Other AUTOSAR modules, most notably FlexRay, provide this independently to the Operating System<br />
* 3. If the Operating System is required to synchronize to multiple global (network) time sources (for example when building a gateway between two time-triggered networks) the Operating System cannot be the source of a unique global time. AUTOSAR OS provides support for synchronization in two ways:<br />
<br />
* 1. Implicit Synchronization – The counter driving the schedule table is the counter with which synchronization is required. This is typically how synchronization with time-triggered networking technologies (e.g. FlexRay, TTP) is achieved – the underlying hardware manages network time synchronization and simply presents time as an output/compare timer interface to the Operating System.<br />
* 2. Explicit Synchronization – The schedule table is driven by an Operating System counter which is not the counter with which synchronization is required. The Operating System provides additional functionality to keep schedule table processing driven by the Operating System counter synchronized with the synchronization counter. This is typically how synchronization with periodically broadcast global times works.<br />
<br />
'''N.B.''' Explicity synchronization is not fully supported yet. ('''SyncScheduleTable''' have been implemented but not yet tested. '''StartScheduleTableSynchron''' and '''SetScheduleTableAsync''' are not implemented at all).<br />
<br />
= Autosar OSApplication and Protection Support =<br />
<br />
AUTOSAR specifications introduce OS-Applications as entities containers (TASKs, ISR2s, COUNTERs, ALARMS, Schedule Tables), that could resemble to processes (without memory virtualization).<br />
<br />
The Operating System module is responsible for scheduling the available processing resource between the OS-Applications that share the processor. If OS-Application(s) are used, all TASKs, ISRs, COUNTERs, ALARMs and Schedule tables must belong to an OS-Application. All objects which belong to the same OS-Application have access to each other. The right to access objects from other OS-Applications may be granted during configuration. An event is accessible if the TASK for which the EVENT can be set is accessible. Access means that these Operating System objects are allowed as parameters to API services.<br />
<br />
The above are the foundamentals of [[Erika_AUTOSAR_OS#Service_Protection | Service Protection]].<br />
<br />
There are two classes of OS-Application:<br />
<br />
* 1 '''Trusted OS-Applications''': Are allowed to run with monitoring or protection features disabled at runtime. They may have unrestricted access to memory, the Operating System module’s API, and NEED NOT have their timing behaviour enforced at runtime. They are allowed to run in privileged mode when supported by the processor.<br />
<br />
* 2 '''Non-Trusted OS-Applications''': Are not allowed to run with monitoring or protection features disabled at runtime. They have restricted access to memory, restricted access to the Operating System module’s API and have their timing behaviour enforced at runtime. They are not allowed to run in privileged mode when supported by the processor.<br />
<br />
Operating System module itself is a TRUSTED OS-Application.<br />
<br />
The running OS-Application is defined as the OS-Application to which the currently running Task or ISR belongs. In case of a hook routine the Task or ISR which caused the call of the hook routine defines the running OS-Application.<br />
<br />
There are services offered by the AUTOSAR OS which give the caller information about the access rights and the membership of objects and memory variables. These services are intended to be used in case of an inter-OS-Application call for checking access rights and arguments.<br />
<br />
OS-Applications have a state which defines the scope of accessability of its Operating System objects from other OS-Applications. Each OS-Application is always in one of the following states:<br />
<br />
* '''Active and accessible''' (APPLICATION_ACCESSIBLE): Operating System objects may be accessed from other OS-Applications. This is the default state at startup.<br />
* '''Currently in restart phase''' (APPLICATION_RESTART): Operating System objects can not be accessed from other OS-Applications. State is valid until the OSApplication calls AllowAccess().<br />
* '''Terminated and not accessible''' (APPLICATION_TERMINATED): Operating System objects can not be accessed from other OS-Applications. State will not change.<br />
<br />
Protection is only possible for Operating System managed objects. This means that:<br />
<br />
* It is not possible to provide protection during runtime of Category 1 ISRs, because the operating system is not aware of any Category 1 ISRs being invoked. Therefore, if any protection is required, Category 1 ISRs have to be avoided. If Category 1 interrupts AND OS-Applications are used together then all Category 1 ISR must belong to a trusted OS-Application.<br />
* It is not possible to provide protection between functions called from the body of the same Task/Category 2 ISR.<br />
<br />
Autosar specify four protection features:<br />
<br />
* '''Service Protection''': Protect the Object Access (TASK, ALARMs, Schedule Table, Resources) between OS-Application, if the permission is not explicitly granted.<br />
* '''Memory Protection''': Protect '''Global Data''' and '''Stacks''' of an OS-Application from possible corruption by Non-Trusted OS-Application.<br />
* '''Stack Monitoring''': On processors that do not provide any memory protection hardware it may still be necessary to provide a “best effort with available resources” scheme for detectable classes of memory faults. Stack monitoring will identify where a task or ISR has exceeded a specified stack usage at context switch time.<br />
* '''Timing Protection''': A timing fault in a real-time system occurs when a task or interrupt misses its deadline at runtime. Autosar OS supply a mechanism based on budget that let the software understand which TASK or ISR2 is causing a deadline missing<br />
<br />
== OS-Application API & OIL Configuration ==<br />
<br />
The OS-Applications life-cycle is controlled by two APIs '''TerminateApplication''' and '''AllowAccess'''. TerminateApplication '''stops''' OS-Applications' '''active and ready''' instances of '''TASKs and ISR2s''' and won't schedule them more as long as the application is possibly restarted, plus make all the its objects inaccessible, this means, for example, that won't be possible to read a counter or set an alarm of the given OS-Application.<br />
<br />
This is useful to stop a faulty portion of the firmware (this usually can happens automatically when ProtectionHook is configured) or to change the configuration of the application it self in case of, for example, power saving mode.<br />
<br />
When '''TerminateApplication''' is called with '''RESTART''' as restart option just one istance of a pre-configured terminated OS-Application's TASK is activated and schedulated. This and only this TASK can put OS-Application's data in a consitent configuration and then call '''AllowAccess''' API to actually Restart the OS-Application.<br />
<br />
Following the list of the API that directly interact with OS-Application.<br />
<br />
*'''TerminateApplication'''( ApplicationType Application, RestartType RestartOption ): Restart OS-Application "Application", if RestartOption is equal to RESTART, or completly terminate it, if RestartOption is equal to NO_RESTART. Restart an OS-Application is a termination with the automatic schedulation of OIL APPLICATION.RESTARTTASK that can reset OS-Application to a consistent status and call AllowAccess to actually restart the application. So only OS-Application that have OIL APPLICATION.RESTARTTASK field configurated can be effectively restarted.<br />
*'''AllowAccess'''( void ): Can be called only by an OS-Application Restarting TASK and only when the OS-Application is effectively restarting, to reset OS-Application status to accessibile.<br />
<br />
The '''OIL configuartion container''':<br />
<br />
'''N.B.''' Remember that if OS-Application are used EVERY SINGLE OBJECT have to belong to an OS-Application, but RESOURCEs, EVENTs and those that impicitly belong to OS, like SYSTEM_TIMER COUNTER.<br />
<br />
APPLICATION App1 {<br />
TRUSTED = FALSE;<br />
TASK = App1Task1;<br />
TASK = App1Task2;<br />
TASK = App1Task3;<br />
COUNTER = App1Counter1;<br />
COUNTER = App1Counter2;<br />
ALARM = App1Alarm1;<br />
ALARM = App1Alarm2;<br />
SCHEDULETABLE = App1ScheduleTable;<br />
SCHEDULETABLE = App1ScheduleTable;<br />
//MEMORY_SIZE = 0x1000;<br />
SHARED_STACK_SIZE = 256;<br />
IRQ_STACK_SIZE = 256;<br />
RESTARTTASK = App1Task3;<br />
};<br />
<br />
*'''TRUSTED''': Flag if the OS-Application is Trusted or not. BE AWARE TO REDUCE TO MINIMUM THE USE OF TRUSTED OS-APPLICATIONS, BECAUSE THEY BYPASS MEMORY PROTECTION (if enabled).<br />
*'''TASK''': '''List''' of all the TASKs that belong to the OS-Application.<br />
*'''COUNTER''': '''List''' of all the COUNTERs that belong to the OS-Application.<br />
*'''ALARM''': '''List''' of all the COUNTERs that belong to the OS-Application.<br />
*'''SCHEDULETABLE''': '''List''' of all the SCHEDULETABLEs that belong to the OS-Application.<br />
*'''MEMORY_SIZE''': This Parameter is an ERIKA's extension to AUTOSAR. When this parameter is set enable an ASSERTION test in ELF linkin tha assure that the RAM used by the application (DATA + STACKs) is less or equal of MEMORY_SIZE.<br />
*'''SHARED_STACK_SIZE''': Stack's size for all the OS-Application's TASKs configured to share the stack (Container TASK field STACK = SHARED).<br />
*'''IRQ_STACK_SIZE''': Stack's size for all the OS-Application's ISR2s.<br />
<br />
== Service Protection ==<br />
<br />
As OS-Applications can interact with the Operating System module through services, it is essential that the service calls will not corrupt the Operating System module itself. '''Service Protection guards against such corruption at runtime'''.<br />
<br />
There are a number of cases to consider with '''Service Protection:'''<br />
<br />
'''An OS-Application makes an API call'''<br />
<br />
*'''(1) with an invalid handle or out of range value.'''<br />
*'''(2) in the wrong context, e.g. calling ActivateTask() in the StartupHook().'''<br />
*'''(3) or fails to make an API call that results in the OSEK OS being left in an undefined state, e.g. it terminates without a ReleaseResource() call'''<br />
*'''(4) that impacts on the behaviour of every other OS-Application in the system, e.g. ShutdownOS()'''<br />
*'''(5) to manipulate Operating System objects that belong to another OS-Application (to which it does not have the necessary permissions), e.g. an OS-Application tries to execute ActivateTask() on a task it does not own.'''<br />
<br />
The OSEK OS already provides some service protection through the status codes returned from service calls and this will provide the basis for service protection. This means that service protection will only apply for the extended status of OSEK OS.<br />
However, OSEK OS does not cover all the cases outlined above.<br />
<br />
The '''Service Protection''' sit on top of OS-Application configuration. So Service Protection '''CANNOT BE ENABLED WITHOUT PROVIDING A FULL OS-Applications CONFIGUARTION'''<br />
<br />
To enable Service Protection the following OIL field can be specified:<br />
<br />
SERVICE_PROTECTION = TRUE;<br />
<br />
With this flag enabled and without accessing rules specified, TASK and ISR2 can access only the objects that belong to its own OS-Application. <br />
<br />
If accessing rules for OBJECTS are explicitly provided (see below) the Service Protection OIL flag is optional.<br />
<br />
'''N.B.: Enabling Service protection (explicitly, with OIL SERVICE_PROTECTION flag, or implicitly, providing Objects accessing rules) with OSEK STATUS configured as standard (STATUS=STANDARD) is considered an incongruent configuration according AUTOSAR specification and should be avoided (RT-Druid will complain with a warning).'''<br />
<br />
To explicitly provide access privileges to objects to other OS-Application, accessing fields have to be added to specified objects:<br />
<br />
TASK Task1 {<br />
....<br />
ACCESSING_APPLICATION = App2;<br />
};<br />
<br />
COUNTER Counter2 {<br />
...<br />
ACCESSING_APPLICATION = App1;<br />
ACCESSING_APPLICATION = App3;<br />
};<br />
<br />
ALARM Alarm2 {<br />
COUNTER = Counter2;<br />
...<br />
ACCESSING_APPLICATION = App1;<br />
ACCESSING_APPLICATION = App3;<br />
ACCESSING_APPLICATION = App4;<br />
};<br />
<br />
SCHEDULETABLE ScheduleTable2 {<br />
COUNTER = CounterSlave2;<br />
... <br />
ACCESSING_APPLICATION = App1;<br />
ACCESSING_APPLICATION = App4;<br />
};<br />
<br />
== Memory Protection ==<br />
<br />
Memory protection will only be possible on processors that provide hardware support for memory protection.<br />
AUTOSAR memory protection scheme is based on the (data, code and stack) sections of the executable program. ERIKA's implementation take AUTOSAR requirements in the following way:<br />
<br />
*'''Stack:''' To keep context change still efficient and let the ERIKA's Stack sharing optimizzation still usable. All the stack space is accessible by all the OS-Application's TASK and ISR2 (In particualr ISR2s supports only stack sharing policy, so it's not possible specify a private stack for a ISR2).<br />
*'''Data:''' There is no TASK's or ISR2's private global data space, only OS-Application's globa ldata space is implemented.<br />
*'''Code:''' All the code is Shared. Data protection protect from data structures corruption.<br />
<br />
The '''Memory Protection''' sit on top of OS-Application configuration. So Memory Protection '''CANNOT BE ENABLED WITHOUT PROVIDING A FULL OS-Applications CONFIGURATION'''<br />
<br />
To enable Memory Protectionion the following OIL field can be specified:<br />
<br />
MEMORY_PROTECTION = TRUE;<br />
<br />
'''TASKs and and ISR2s of a NON-TRUSTED OS-Application can only access global data that belong to OS-Application global data space.'''<br />
<br />
To locate a variable in the right section, MemMap.h header file feature should be used.<br />
<br />
=== MemMap.h header file Rationale and Use ===<br />
<br />
'''MemMap.h''' file is the standar AUTOSAR tool to be used to handle the problem to locate data e code of an application in a compiler agnostic way. ERIKA's build chain, Starting from OIL OS-Application's configuration, will generate a '''MemMap.h''' that contains.<br />
<br />
For each OS-Application are reserved three sections:<br />
<br />
*'''ee_${APP_NAME}_bss''': To locate OS-Application's uninitialized variables.<br />
*'''ee_${APP_NAME}_data''': To locate OS-Application's initialized variables.<br />
*'''ee_${APP_NAME}_text''': To locate OS-Application's code (it is a predisposition to Code protection, not effectively used yet).<br />
<br />
With parameter substitution of ${APP_NAME} with the real OIL OSAPPLICATION Field Name.<br />
<br />
The sum of '''ee_${APP_NAME}_bss''' and '''ee_${APP_NAME}_data''' section will compose the '''OS-Application private data space'''.<br />
<br />
To add some variables or code to a OS-Application you have to use the following ''commands'' Macro defined right before <br />
the MemMap inclusion:<br />
<br />
*'''APP_${APP_NAME}_START_SEC_VAR_NOINIT/APP_${APP_NAME}_STOP_SEC_VAR_NOINIT'''<br />
*'''APP_${APP_NAME}_START_SEC_DATA/APP_${APP_NAME}_STOP_SEC_DATA'''<br />
*'''APP_${APP_NAME}_START_SEC_CODE/APP_${APP_NAME}_STOP_SEC_CODE'''<br />
<br />
As the following example:<br />
<br />
'''#define APP_App1_START_SEC_VAR_NOINIT'''<br />
'''#include "MemMap.h"'''<br />
<br />
EE_UREG app1_noinit1;<br />
EE_UREG app1_noinit2;<br />
<br />
'''#define APP_App1_STOP_SEC_VAR_NOINIT'''<br />
'''#include "MemMap.h"'''<br />
<br />
'''#define APP_App1_START_SEC_VAR_DATA'''<br />
'''#include "MemMap.h"'''<br />
<br />
EE_UREG app1_data1 = 1U;<br />
EE_UREG app1_data2 = 2U;<br />
<br />
'''#define APP_App1_STOP_SEC_VAR_DATA'''<br />
'''#include "MemMap.h"'''<br />
<br />
For Communication between OS-Application AUTOSAR introduce '''IOC''' (Inter OS-Applications Communication) '''Mechanism'''. An experimental support of '''IOC''' is provided by ERIKA, but RT-Druid cannot yet configure it, and since the IOC configuration is hard to be done correctly by hand, some special sections are providded that are accessible by ALL OS-Application by default. (It's suggested to reduce at the minimun the data shared between OS-Applications, to not frustrate Memory Protection). These sections are usable with the following MemMap.h ''commands'' Macros:<br />
<br />
*'''API_START_SEC_VAR_NOINIT/API_STOP_SEC_VAR_NOINIT'''<br />
*'''API_START_SEC_DATA/API_STOP_SEC_DATA'''<br />
<br />
=== TRSUTED OS-Application & Trusted Services (TRUSTED_FUNCTION) ===<br />
<br />
An OS-Appilcation, to bypass it's own bounduaries in a "controlled" way, can invoke a Trusted Function provided by (another) trusted OS-Application. That can require a switch from non-privileged to privileged mode. This is typically achieved by these operations:<br />
* (1) Each trusted OS-Application may export services which are callable from other OS-Applications.<br />
* (2) During configuration these trusted services must be configured to be called from a non-trusted OS-Application.<br />
* (3) The call from the non-trusted OS-Application to the trusted service is using a mechanism (e.g. trap/software interrupt) provided by the Operating System. The service is passed as an identifier that is used to determine, in the trusted environment, if the service can be called.<br />
* (4) The Operating System offers services to check if a memory region is write/read/execute accessible from an OS-Application. It also returns information if the memory region is part of the stack space.<br />
<br />
This is an example of TRUSTED function interface and OIL Configuration.<br />
<br />
'''N.B.''' If a '''"Service Interface"''' will be provided (a '''Service Interface''' is a function that wrap the ERIKA's '''CallTrustedService''' OS API call), as AUTOSAR coding style dictate; this '''must be added to the API code section''' with the use of '''MemMap.h and the ''commands'' API_START_SEC_CODE/API_STOP_SEC_CODE'''. (The use of the Code API Section it's not optinal because, even though Code protection is not implemented yet, inside the ERIKA's syscall handler, the call site address is checked, against Kernel and API boundaries, before to accept the call).<br />
<br />
TRUSTED Service Declaration Header File<br />
<br />
#define APP_App2Trusted_START_SEC_CODE<br />
#include "MemMap.h"<br />
'''/* TRUSTED Service */'''<br />
'''StatusType TRUSTED_TrustedService1 (TrustedFunctionIndexType index, TrustedFunctionParameterRefType ref);'''<br />
#define APP_App2Trusted_STOP_SEC_CODE<br />
#include "MemMap.h"<br />
<br />
#define API_START_SEC_CODE<br />
#include "MemMap.h"<br />
'''/* User inteface */'''<br />
'''StatusType CallTrustedService1 ( void );'''<br />
#define API_STOP_SEC_CODE<br />
#include "MemMap.h"<br />
<br />
TRUSTED Service Definition File<br />
<br />
'''/* User inteface */ '''<br />
StatusType CallTrustedService1 ( void )<br />
{<br />
'''/* User inteface Implementation */'''<br />
'''return CallTrustedService(EE_ID_TRUSTED_TrustedService1, NULL);'''<br />
}<br />
<br />
'''/* TRUSTED Service Implementation */'''<br />
StatusType TRUSTED_TrustedService1 (TrustedFunctionIndexType index,<br />
TrustedFunctionParameterRefType ref)<br />
{<br />
'''/* TRUSTED Service Implementation */'''<br />
}<br />
<br />
The OIL to configure a TRUSTED services for an Trusted OS-Application<br />
<br />
APPLICATION App2Trusted {<br />
TRUSTED = TRUE { '''/* <-- OS-Application have to be TRUSTED to have a TRUSTED_FUNCTION''' */<br />
'''TRUSTED_FUNCTION = TRUE {'''<br />
'''NAME = "TrustedService1";'''<br />
'''};'''<br />
TRUSTED_FUNCTION = TRUE {<br />
NAME = "TrustedService2";<br />
};<br />
...<br />
};<br />
<br />
== Timing Protection ==<br />
<br />
A timing fault in a real-time system occurs when a task or interrupt misses its deadline at runtime.<br />
AUTOSAR OS does not offer deadline monitoring for timing protection. Deadline monitoring is insufficient to correctly identify the Task/ISR causing a timing fault in an AUTOSAR system. When a deadline is violated this may be due to a timing fault introduced by an unrelated Task/ISR that interferes/blocks for too long. The fault in this case lies with the unrelated Task/ISR and this will propagate through the system until a Task/ISR misses its deadline. The Task/ISR that misses a deadline is therefore not necessarily the Task/ISR that has failed at runtime, it is simply the earliest point that a timing fault is detected.<br />
<br />
AUTOSAR use a budget mechanism to locate the violating entity. The following budgets can be configured:<br />
<br />
* '''Execution Budget for TASK and ISR2''': This is the ammount of time that a TASK/ISR2 can be executing (RUNNING status for a TASK). '''The budget is paused when a TASK/ISR2 is preempted'''. The budget is '''refilled''' when a '''TASK/ISR2 terminate''' or a '''TASK block on a WaitEvent'''.<br />
* '''Resource Lock Time''': This is the ammount of time that a TASK/ISR2 can lock a specific resource (with the call of '''GetResource'''). Can be specified for each resource that a TASK can access.<br />
* '''OS Interrupts Lock Time''': This is the ammount of time that a TASK/ISR2 can suspend OS Interrupts (with '''SupendOSInterrupts''').<br />
* '''All Interrupts Lock Time''': This is the ammount of time that a TASK/ISR2 can suspend/disable All Interrupts (with '''SupendAllInterrupts''' '''DisableAllInterrupts''').<br />
<br />
'''Autosar Timing Protection do NOT use OS-Application configuration but is done on schedulable entities (TASKs and ISR2).'''<br />
<br />
An example of '''timing protection budgets''' configuration:<br />
<br />
TASK Task1 {<br />
...<br />
'''TIMING_PROTECTION = TRUE {'''<br />
'''EXECUTIONBUDGET = 0.0025;'''<br />
'''MAXALLINTERRUPTLOCKTIME = 0.0001;'''<br />
'''RESOURCE = RESOURCELOCK {'''<br />
'''RESOURCELOCKTIME = 0.0002;'''<br />
'''RESOURCE = RES_SCHEDULER;'''<br />
'''};'''<br />
'''RESOURCE = RESOURCELOCK {'''<br />
'''RESOURCELOCKTIME = 0.0003;'''<br />
'''RESOURCE = RESOURCE1;'''<br />
'''};'''<br />
};<br />
};<br />
<br />
ISR ISR1 {<br />
'''CATEGORY = 2;'''<br />
...<br />
'''TIMING_PROTECTION = TRUE {'''<br />
'''EXECUTIONTIME = 0.0055;'''<br />
'''MAXALLINTERRUPTLOCKTIME = 0.0001;'''<br />
};<br />
};<br />
<br />
Timing Protection, can be configured to protect from too frequents TASKs' activations and ISR2s' preemptions. This mechanism is called '''inter-arrival''' time protection.<br />
<br />
An example of '''inter-arrival time protection''' configuration.<br />
<br />
TASK TaskPrio2 {<br />
...<br />
TIMING_PROTECTION = TRUE {<br />
'''TIMEFRAME = 0.0025;''' /* Two Activation of this TASK have to be separated by 250us to be acceptated. (Provided that TASK's number activation is respected) */<br />
EXECUTIONBUDGET = 0.0005;<br />
MAXALLINTERRUPTLOCKTIME = 0.0001;<br />
};<br />
};<br />
<br />
ISR Button_ISR2 {<br />
CATEGORY = 2;<br />
... <br />
TIMING_PROTECTION = TRUE {<br />
'''TIMEFRAME = 0.001;''' /* Two interrupts of this type have to be separated by 1ms to be acceptated */<br />
EXECUTIONTIME = 0.0055;<br />
MAXALLINTERRUPTLOCKTIME = 0.0001;<br />
};<br />
};<br />
<br />
'''N.B.''' Check following examples: <br />
* tricore/infineon_TriBoard-TC2X5_V2.0/Timing Protection automatic tests/Timing Protection budgets automatic tests<br />
* tricore/infineon_TriBoard-TC2X5_V2.0/Timing Protection automatic tests/Timing Protection inter-arrival protection automatic tests<br />
for configuration examples.<br />
<br />
== Stack Monitoring ==<br />
<br />
On processors that do not provide any memory protection hardware it may still be necessary to provide a “best effort with available resources” scheme for detectable classes of memory faults. Stack monitoring will identify where a task or ISR has exceeded a specified stack usage at context switch time.<br />
This may mean that there is considerable time between the system being in error and that fault being detected. Similarly, the error may have been cleared at the point the fault is notified (the stack may be less than the specified size when the context switch occurs).<br />
Note that if Memory Protection is enabled a stack overflow may cause a memory exception before the stack monitoring is able to detect the fault.<br />
<br />
= Architetures that support full AUTOSAR Features =<br />
* [[Infineon_Aurix]]<br />
<br />
= Note on Autosar Scalabilty Classes =<br />
<br />
'''ERIKA's kernel now implement all the features specified in Autosar OS specification''', but do not support scalability classes yet.<br />
Autosar Scalability Classes declare subsets of Autosar features and a set of checks that have to be done on configuration to guarantee that the subset is not overflowed. RT-Druid do not implement thsse checks (yet).<br />
<br />
'''Instead if a valid configuration is given to RT-Druid it enables all the features needed to support that configuration'''.</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=Erika_AUTOSAR_OSErika AUTOSAR OS2015-01-12T16:52:52Z<p>Eguidieri: /* Note on Autosar Scalabilty Classes */</p>
<hr />
<div>= Multicore Autosar OS Support =<br />
<br />
ERIKA support multicore environments a way before than the first Autosar Multicore OS Release. So it happened that the historical [[ERIKA multicore support]] addresses some of the same requiremets of AUTOSAR Multicore OS with a completely different policy.<br />
<br />
In detail all the primitives calls on other core, with traditional implementation, called '''Remote Notifications''' or '''RN''', are done '''asynchronously''' with a fire and forget policy. This approach reduce latency to minimun, but, on the other hand, don't give the opportunity to check for errors in the call site.<br />
<br />
Autosar, that take into account a way more code consistency and reliability than efficiency, requires that all the primitives calls on others cores are '''synchronous''' giving the opportunity to caller code to correctly handle errors.<br />
<br />
To implements Autosar OS requirements a completly new multicore dispatcher have been implemented. This have been called<br />
'''ERIKA Autosar RPC''' (Remote Procedure Call).<br />
<br />
== Difference between the traditional RN implementation and the new RPC implementation ==<br />
The '''RN''' implementation is the original implementation done in 2002 of the MSRP protocol proposed in the paper<br />
<br />
Minimizing memory utilization of real-time task sets in single and multi-processor systems-on-a-chip<br />
P Gai, G Lipari, M Di Natale<br />
Real-Time Systems Symposium, 2001.(RTSS 2001). Proceedings. 22nd IEEE, 73-83<br />
<br />
which included the following features:<br />
<br />
* ASYNCHRONOUS remote activation of tasks. Activations are queued for later processing. Spin lock time is minimized. Local primitives returns E_OK despite the result of the remote activation (errors must be caught using ErrorHook!)<br />
* Queuing spin lock implemented using the algorithm presented in<br />
G. Graunke and S. Thakkar, Synchronization algorithms for shared memory multiprocessors. IEEE Computer, 23(6):60-69, June 1990<br />
* automatic detection from the OIL file whether resources are global or local. That is, GetResource and ReleaseResource where implementing an additional spin-lock when the resource was global. The idea was that the system allowed migration of tasks from one CPU to another without changing the OS code.<br />
<br />
All those points have been partially dropped on some architectures due to some of the requirements of AUTOSAR. In particular, spin-locks have a separate API (so GetResource and ReleaseResource cannot call implicitly a spinlock), and queuing spin-lock is not in the standard and is also quite difficult to implement in an efficient way considering that in some situazion a task can be removed from spinning.<br />
<br />
As for the first point, AUTOSAR mandates the fact that priomitives should return the status of the execution of the primitive, ALSO if the execution happens on the remote core. This implies that the remote activations must be SYNCHRONOUS. That is the reason why we created the '''RPC''' implementation, which has the following features:<br />
<br />
* SYNCHRONOUS remote activation of tasks<br />
* Normal (no protocol) spin-locks to comply with AUTOSAR<br />
* no detection of remote resources, which... does not exist in AUTOSAR<br />
<br />
Final note on interprocessor interrupt priorities:<br />
* the interprocessor IRQ must be an ISR2<br />
* on RN, the interprocessor IRQ can be the LOWEST priority interrupt, as the requests are queued and since the spin lock time is independent of the priority of the IRQ.<br />
* on RPC, the spin-lock time highly depends on the interprocessor IRQ RESPONSE TIME, which is affected by its priority. Therefore, the interprocessor Interrupt should have a HIGH priority, and this means that mopre and more IRQs must become ISR2 (remember ISR1 must have highet priority than ISR2), making the implementation more and more inefficient.<br />
<br />
<br />
== How to select the traditional RN implementation and the new RPC implementation ==<br />
Both traditional and the new dispatcher are available for Infineon AURIX and Freescale PowerPC (MPC5777C). You can switch between them in OIL with the REMOTENOTIFICATION oil field.<br />
<br />
REMOTENOTIFICATION = USE_RN;<br />
<br />
Enable traditional '''Remote Notification''' dispatcher. It's the default value, so you don't need to write this.<br />
<br />
REMOTENOTIFICATION = USE_RPC;<br />
<br />
Enable the new '''AUTOSAR Remote Procedure Call''' dispatcher.<br />
<br />
Currently with the new RPC dispatcher you can execute on remote cores all the following primitives:<br />
<br />
* ActivateTask<br />
* ChainTask (Terminate local TASK but can schedule on remote core)<br />
* GetTaskState<br />
* SetEvent<br />
* GetAlarmBase<br />
* GetAlarm<br />
* SetRelAlarm<br />
* SetAbsAlarm<br />
* CancelAlarm<br />
* GetCounterValue<br />
* GetElapsedValue<br />
* ShutdownOS ( with new ShutdownAllCores API )<br />
<br />
So in addition to TASK and EVENT primitives, the new muticore dispatcher support Counters and Alarms as required by Autosar specifications. Multicore awareness have been added to ShutdownOS to fulfill multicore AUTOSAR shutdown sequence. <br />
<br />
== New Multicore API ==<br />
<br />
AUTOSAR expect a master/slaves multicore enviroment that naturally fit AURIX architecture.<br />
New API to start and stops slave cores specified in AUTOSAR v4.0 rev 3.0 have been added:<br />
<br />
*'''StartCore''': This function starts the core specified by the parameter CoreID. The OUT parameter allows the caller to check whether the operation was successful or not. If a core is started by means of this function '''StartOS''' shall be called on the core. It is not supported to call this function after '''StartOS()'''.<br />
*'''StartNonAutosarCore''': The function starts the core specified by the parameter CoreID. It '''is allowed''' to call this function after '''StartOS()'''. The OUT parameter allows the caller to check whether the operation was successful or not. It is '''not allowed to call StartOS''' on cores activated by '''StartNonAutosarCore'''.<br />
*'''GetNumberOfActivatedCores''': returns the number of cores activated by the StartCore function. This function might be a macro<br />
*'''GetCoreID''': The function returns a unique core identifier.<br />
*'''ShutdownAllCores''' : After this service the OS on all AUTOSAR cores is shut down. Allowed at TASK level and ISR level and also internally by the OS. The function will never return. The function will force other cores into a shutdown.<br />
<br />
== New Spinlocks API ==<br />
<br />
Support for AUTOSAR Spinlock API have been added. OIL implementation have been extended to support Spinlocks configuration.<br />
<br />
There's two spinlocks behaviour modes: '''SINGLE''' and '''ORDERED'''. If '''SINGLE''' mode is configured a core get an error if, holding a spinlock, try to get access to another one. If '''ORDERED''' mode is configurated the core get this error only if it try to get spinlocks out of the order (see AUTOSAR documentation paragraph 7.9.29 The spinlock mechanism).<br />
<br />
To configure spinlocks in '''SINGLE''' mode, just don't provide any order:<br />
<br />
SPINLOCK spinlock_1 { };<br />
SPINLOCK spinlock_2 { };<br />
SPINLOCK spinlock_3 { };<br />
<br />
To configure spinlocks in '''ORDERED''' mode provide a '''complete ordering''':<br />
<br />
SPINLOCK spinlock_1 { NEXT_SPINLOCK=spinlock_2; };<br />
SPINLOCK spinlock_2 { NEXT_SPINLOCK=spinlock_3; };<br />
SPINLOCK spinlock_3 { };<br />
<br />
<br />
Provided AUTOSAR API to interact with Spinlocks are:<br />
<br />
*'''GetSpinlock ''': Tries to occupy a spin-lock variable. If the function returns, either the lock is successfully taken or an error has occurred. The spinlock mechanism is an active polling mechanism. The function does not cause a de-scheduling.<br />
*'''ReleaseSpinlock''': Releases a spinlock variable that was occupied before. Before terminating a TASK all spinlock variables that have been occupied with GetSpinlock() shall be released. Before calling WaitEVENT all Spinlocks shall be released.<br />
*'''TryToGetSpinlock''': Has the same functionality as GetSpinlock with the difference that if the spinlock is already occupied by a TASK on a different core the function sets the OUT parameter to TRYTOGETSPINLOCK_NOSUCCESS and returns with E_OK.<br />
<br />
Two spinlocks implementation are provided. The '''trivial''' one that does not guarentee upper bond wait, but that can implement the try-to-get behaviour. And the '''queued''' one that prevent from starvation queuing requests, but cannot implement try-to-get behaviour (TryToGetSpinlock API is mapped into GetSpinlock).<br />
<br />
To enable '''queued spinlocks''' just add to the OIL:<br />
<br />
SPINLOCKS = QUEUED;<br />
<br />
IMPORTANT: QUEUED spinlocks are not available for Erika on PowerPC.<br />
<br />
= Autosar Schedule Tables =<br />
<br />
Autosar Specification add to OSEK Alarms, another activities schedulator called Schedule Tables.<br />
It is possible to implement a statically defined activities schedulator, that activate TASKs and set EVENTs, using an<br />
OSEK counter and a series of auto started alarms. In the simple case, this can be achieved by specifying that the alarms are not modified once started. Run-time modifications can only be made if relative synchronization between alarms can be<br />
guaranteed.This typically means modifying the alarms while associated counter tick interrupts are disabled.<br />
Schedule Tables address the synchronization issue by providing an encapsulation of a statically defined set of expiry points. Each expiry point defines:<br />
<br />
* One or more actions that must occur when it is processed where an action is the activation of a task or the setting of an event.<br />
* An offset in ticks from the start of the schedule table.<br />
<br />
Each schedule table has a duration in ticks. The duration is measured from zero and<br />
defines the modulus of the schedule table.<br />
<br />
At runtime, the Operating System module will iterate over the schedule table, processing each expiry point in turn. The iteration is driven by an OSEK counter. It therefore follows that the properties of the counter have an impact on what is possible to configure on the schedule table.<br />
<br />
== Schedule Table APIs ==<br />
<br />
All the Schedule Table API not related to the schedule table syncronization are implemented (see [[Erika_AUTOSAR_OS#Schedule_Table_Synchronization |Schedule Table Synchronization]]).<br />
<br />
* '''StartScheduleTableRel( ScheduleTableType ScheduleTableID, TickType Offset )''': This service starts the processing of a schedule table at "Offset" relative to the "Now" value on the underlying counter.<br />
<br />
* '''StartScheduleTableAbs( ScheduleTableType ScheduleTableID, TickType Start )''': This service starts the processing of a schedule table at an absolute value "Start" on the underlying counter.<br />
<br />
* '''StopScheduleTable( ScheduleTableType ScheduleTableID )''': This service cancels the processing of a schedule table immediately at any point while the schedule table is running.<br />
<br />
* '''GetScheduleTableStatus( ScheduleTableType ScheduleTableID, ScheduleTableStatusRefType ScheduleStatus )''': This service queries the state of a schedule table (also with respect to synchronization).<br />
<br />
* '''NextScheduleTable(ScheduleTableType ScheduleTableID_From, ScheduleTableType ScheduleTableID_To)''': This service switches the processing from one schedule table to another schedule table.<br />
<br />
'''N.B.''' The best place to start to understand how schedule tables API works is:<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Schedule Tables/Schedule Table example''<br />
<br />
== Schedule Table OIL Configuration ==<br />
<br />
This is an OIL example to how configure a Schedule Table with OIL<br />
<br />
SCHEDULETABLE SchedTab1 {<br />
COUNTER = system_timer;<br />
DURATION = 400;<br />
REPEATING = FALSE;<br />
AUTOSTART = TRUE {<br />
TYPE = ABSOLUTE;<br />
START_VALUE = 0;<br />
};<br />
EXPIRE_POINT = ACTION {<br />
EXPIRE_VALUE = 100;<br />
ACTION = ACTIVATETASK { TASK = Task2; };<br />
ACTION = SETEVENT { TASK = Task1; EVENT = ButtonEvent; };<br />
SYNC_ADJUSTMENT = FALSE;<br />
};<br />
EXPIRE_POINT = ACTION {<br />
EXPIRE_VALUE = 300;<br />
ACTION = SETEVENT { TASK = Task1; EVENT = TimerEvent; };<br />
SYNC_ADJUSTMENT = FALSE;<br />
};<br />
LOCAL_TO_GLOBAL_TIME_SYNCHRONIZATION = FALSE;<br />
};<br />
<br />
Following the SCHEDULETABLE field explaination<br />
* '''COUNTER''': The Schedule Table '''driving counter'''<br />
* '''DURATION''': The Schedule Table duration (in counter ticks), MUST be greater or equal to the last EXPIRE_POINT.EXPIRE_VALUE<br />
* '''REPEATING''': Flag if the Schedule Table is one shot or have to be restarted when it terminated (after DURATION ticks).<br />
* '''AUTOSTART''': Flag if the Schedule Table have to be started automatically during ''StartOs'', in which way '''TYPE''': (ABSOLUTE, RELATIVE) and with wich Start Value of the counter (or Offset if the TYPE is RELATIVE). In ERIKA where, all the counters are software the two autostartig type generate the same result. <br />
* '''EXPIRE_POINT''': '''List of EXPIRY_POINT''' that represent the Schedule Table, any of which is composed by an '''EXPIRE_VALUE''' in ticks (when the expiry points happens) a '''list of ACTIONS''' (''equals to ALARMs Actions'') and by a flag that enable synchronization not yet supported (SYNC_ADJUSTMENT. Only FALSE value is supported, that is the default so the field can be omitted).<br />
'''LOCAL_TO_GLOBAL_TIME_SYNCHRONIZATION''': Flag that enable External Syncronization, not supported yet. (Only FALSE value is supported, that is the default so the field can be omitted).<br />
<br />
'''N.B.''' The best place to start to understand how schedule tables OIL configuration works is:<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Schedule Tables/Schedule Table example''<br />
<br />
== Schedule Table Synchronization ==<br />
<br />
The absolute time at which the Initial Expiry Point on a schedule table is processed is under user control. However, if the schedule table repeats then it is not guaranteed that the absolute count value at which the initial expiry point was first processed is the same count value at which it is subsequently processed. This is because the duration of the schedule table need not be equal to the counter modulus.<br />
In many cases it may be important that schedule table expiry points are processed at specific absolute values of the underlying counter. This is called synchronization. Typical use-cases include:<br />
<br />
* Synchronization of expiry points to degrees of angular rotation for motor management<br />
* Synchronizing the computation to a global (network) time base.<br />
<br />
Note that in AUTOSAR, the Operating System does not provide a global (network) time source because<br />
<br />
* 1. A global time may not be needed in many cases<br />
* 2. Other AUTOSAR modules, most notably FlexRay, provide this independently to the Operating System<br />
* 3. If the Operating System is required to synchronize to multiple global (network) time sources (for example when building a gateway between two time-triggered networks) the Operating System cannot be the source of a unique global time. AUTOSAR OS provides support for synchronization in two ways:<br />
<br />
* 1. Implicit Synchronization – The counter driving the schedule table is the counter with which synchronization is required. This is typically how synchronization with time-triggered networking technologies (e.g. FlexRay, TTP) is achieved – the underlying hardware manages network time synchronization and simply presents time as an output/compare timer interface to the Operating System.<br />
* 2. Explicit Synchronization – The schedule table is driven by an Operating System counter which is not the counter with which synchronization is required. The Operating System provides additional functionality to keep schedule table processing driven by the Operating System counter synchronized with the synchronization counter. This is typically how synchronization with periodically broadcast global times works.<br />
<br />
'''N.B.''' Explicity synchronization is not fully supported yet. ('''SyncScheduleTable''' have been implemented but not yet tested. '''StartScheduleTableSynchron''' and '''SetScheduleTableAsync''' are not implemented at all).<br />
<br />
= Autosar OSApplication and Protection Support =<br />
<br />
AUTOSAR specifications introduce OS-Applications as entities containers (TASKs, ISR2s, COUNTERs, ALARMS, Schedule Tables), that could resemble to processes (without memory virtualization).<br />
<br />
The Operating System module is responsible for scheduling the available processing resource between the OS-Applications that share the processor. If OS-Application(s) are used, all TASKs, ISRs, COUNTERs, ALARMs and Schedule tables must belong to an OS-Application. All objects which belong to the same OS-Application have access to each other. The right to access objects from other OS-Applications may be granted during configuration. An event is accessible if the TASK for which the EVENT can be set is accessible. Access means that these Operating System objects are allowed as parameters to API services.<br />
<br />
The above are the foundamentals of [[Erika_AUTOSAR_OS#Service_Protection | Service Protection]].<br />
<br />
There are two classes of OS-Application:<br />
<br />
* 1 '''Trusted OS-Applications''': Are allowed to run with monitoring or protection features disabled at runtime. They may have unrestricted access to memory, the Operating System module’s API, and NEED NOT have their timing behaviour enforced at runtime. They are allowed to run in privileged mode when supported by the processor.<br />
<br />
* 2 '''Non-Trusted OS-Applications''': Are not allowed to run with monitoring or protection features disabled at runtime. They have restricted access to memory, restricted access to the Operating System module’s API and have their timing behaviour enforced at runtime. They are not allowed to run in privileged mode when supported by the processor.<br />
<br />
Operating System module itself is a TRUSTED OS-Application.<br />
<br />
The running OS-Application is defined as the OS-Application to which the currently running Task or ISR belongs. In case of a hook routine the Task or ISR which caused the call of the hook routine defines the running OS-Application.<br />
<br />
There are services offered by the AUTOSAR OS which give the caller information about the access rights and the membership of objects and memory variables. These services are intended to be used in case of an inter-OS-Application call for checking access rights and arguments.<br />
<br />
OS-Applications have a state which defines the scope of accessability of its Operating System objects from other OS-Applications. Each OS-Application is always in one of the following states:<br />
<br />
* '''Active and accessible''' (APPLICATION_ACCESSIBLE): Operating System objects may be accessed from other OS-Applications. This is the default state at startup.<br />
* '''Currently in restart phase''' (APPLICATION_RESTART): Operating System objects can not be accessed from other OS-Applications. State is valid until the OSApplication calls AllowAccess().<br />
* '''Terminated and not accessible''' (APPLICATION_TERMINATED): Operating System objects can not be accessed from other OS-Applications. State will not change.<br />
<br />
Protection is only possible for Operating System managed objects. This means that:<br />
<br />
* It is not possible to provide protection during runtime of Category 1 ISRs, because the operating system is not aware of any Category 1 ISRs being invoked. Therefore, if any protection is required, Category 1 ISRs have to be avoided. If Category 1 interrupts AND OS-Applications are used together then all Category 1 ISR must belong to a trusted OS-Application.<br />
* It is not possible to provide protection between functions called from the body of the same Task/Category 2 ISR.<br />
<br />
Autosar specify four protection features:<br />
<br />
* '''Service Protection''': Protect the Object Access (TASK, ALARMs, Schedule Table, Resources) between OS-Application, if the permission is not explicitly granted.<br />
* '''Memory Protection''': Protect '''Global Data''' and '''Stacks''' of an OS-Application from possible corruption by Non-Trusted OS-Application.<br />
* '''Stack Monitoring''': On processors that do not provide any memory protection hardware it may still be necessary to provide a “best effort with available resources” scheme for detectable classes of memory faults. Stack monitoring will identify where a task or ISR has exceeded a specified stack usage at context switch time.<br />
* '''Timing Protection''': A timing fault in a real-time system occurs when a task or interrupt misses its deadline at runtime. Autosar OS supply a mechanism based on budget that let the software understand which TASK or ISR2 is causing a deadline missing<br />
<br />
== OS-Application API & OIL Configuration ==<br />
<br />
The OS-Applications life-cycle is controlled by two APIs '''TerminateApplication''' and '''AllowAccess'''. TerminateApplication '''stops''' OS-Applications' '''active and ready''' instances of '''TASKs and ISR2s''' and won't schedule them more as long as the application is possibly restarted, plus make all the its objects inaccessible, this means, for example, that won't be possible to read a counter or set an alarm of the given OS-Application.<br />
<br />
This is useful to stop a faulty portion of the firmware (this usually can happens automatically when ProtectionHook is configured) or to change the configuration of the application it self in case of, for example, power saving mode.<br />
<br />
When '''TerminateApplication''' is called with '''RESTART''' as restart option just one istance of a pre-configured terminated OS-Application's TASK is activated and schedulated. This and only this TASK can put OS-Application's data in a consitent configuration and then call '''AllowAccess''' API to actually Restart the OS-Application.<br />
<br />
Following the list of the API that directly interact with OS-Application.<br />
<br />
*'''TerminateApplication'''( ApplicationType Application, RestartType RestartOption ): Restart OS-Application "Application", if RestartOption is equal to RESTART, or completly terminate it, if RestartOption is equal to NO_RESTART. Restart an OS-Application is a termination with the automatic schedulation of OIL APPLICATION.RESTARTTASK that can reset OS-Application to a consistent status and call AllowAccess to actually restart the application. So only OS-Application that have OIL APPLICATION.RESTARTTASK field configurated can be effectively restarted.<br />
*'''AllowAccess'''( void ): Can be called only by an OS-Application Restarting TASK and only when the OS-Application is effectively restarting, to reset OS-Application status to accessibile.<br />
<br />
The '''OIL configuartion container''':<br />
<br />
'''N.B.''' Remember that if OS-Application are used EVERY SINGLE OBJECT have to belong to an OS-Application, but RESOURCEs, EVENTs and those that impicitly belong to OS, like SYSTEM_TIMER COUNTER.<br />
<br />
APPLICATION App1 {<br />
TRUSTED = FALSE;<br />
TASK = App1Task1;<br />
TASK = App1Task2;<br />
TASK = App1Task3;<br />
COUNTER = App1Counter1;<br />
COUNTER = App1Counter2;<br />
ALARM = App1Alarm1;<br />
ALARM = App1Alarm2;<br />
SCHEDULETABLE = App1ScheduleTable;<br />
SCHEDULETABLE = App1ScheduleTable;<br />
//MEMORY_SIZE = 0x1000;<br />
SHARED_STACK_SIZE = 256;<br />
IRQ_STACK_SIZE = 256;<br />
RESTARTTASK = App1Task3;<br />
};<br />
<br />
*'''TRUSTED''': Flag if the OS-Application is Trusted or not. BE AWARE TO REDUCE TO MINIMUM THE USE OF TRUSTED OS-APPLICATIONS, BECAUSE THEY BYPASS MEMORY PROTECTION (if enabled).<br />
*'''TASK''': '''List''' of all the TASKs that belong to the OS-Application.<br />
*'''COUNTER''': '''List''' of all the COUNTERs that belong to the OS-Application.<br />
*'''ALARM''': '''List''' of all the COUNTERs that belong to the OS-Application.<br />
*'''SCHEDULETABLE''': '''List''' of all the SCHEDULETABLEs that belong to the OS-Application.<br />
*'''MEMORY_SIZE''': This Parameter is an ERIKA's extension to AUTOSAR. When this parameter is set enable an ASSERTION test in ELF linkin tha assure that the RAM used by the application (DATA + STACKs) is less or equal of MEMORY_SIZE.<br />
*'''SHARED_STACK_SIZE''': Stack's size for all the OS-Application's TASKs configured to share the stack (Container TASK field STACK = SHARED).<br />
*'''IRQ_STACK_SIZE''': Stack's size for all the OS-Application's ISR2s.<br />
<br />
== Service Protection ==<br />
<br />
As OS-Applications can interact with the Operating System module through services, it is essential that the service calls will not corrupt the Operating System module itself. '''Service Protection guards against such corruption at runtime'''.<br />
<br />
There are a number of cases to consider with '''Service Protection:'''<br />
<br />
'''An OS-Application makes an API call'''<br />
<br />
*'''(1) with an invalid handle or out of range value.'''<br />
*'''(2) in the wrong context, e.g. calling ActivateTask() in the StartupHook().'''<br />
*'''(3) or fails to make an API call that results in the OSEK OS being left in an undefined state, e.g. it terminates without a ReleaseResource() call'''<br />
*'''(4) that impacts on the behaviour of every other OS-Application in the system, e.g. ShutdownOS()'''<br />
*'''(5) to manipulate Operating System objects that belong to another OS-Application (to which it does not have the necessary permissions), e.g. an OS-Application tries to execute ActivateTask() on a task it does not own.'''<br />
<br />
The OSEK OS already provides some service protection through the status codes returned from service calls and this will provide the basis for service protection. This means that service protection will only apply for the extended status of OSEK OS.<br />
However, OSEK OS does not cover all the cases outlined above.<br />
<br />
The '''Service Protection''' sit on top of OS-Application configuration. So Service Protection '''CANNOT BE ENABLED WITHOUT PROVIDING A FULL OS-Applications CONFIGUARTION'''<br />
<br />
To enable Service Protection the following OIL field can be specified:<br />
<br />
SERVICE_PROTECTION = TRUE;<br />
<br />
With this flag enabled and without accessing rules specified, TASK and ISR2 can access only the objects that belong to its own OS-Application. <br />
<br />
If accessing rules for OBJECTS are explicitly provided (see below) the Service Protection OIL flag is optional.<br />
<br />
'''N.B.: Enabling Service protection (explicitly, with OIL SERVICE_PROTECTION flag, or implicitly, providing Objects accessing rules) with OSEK STATUS configured as standard (STATUS=STANDARD) is considered an incongruent configuration according AUTOSAR specification and should be avoided (RT-Druid will complain with a warning).'''<br />
<br />
To explicitly provide access privileges to objects to other OS-Application, accessing fields have to be added to specified objects:<br />
<br />
TASK Task1 {<br />
....<br />
ACCESSING_APPLICATION = App2;<br />
};<br />
<br />
COUNTER Counter2 {<br />
...<br />
ACCESSING_APPLICATION = App1;<br />
ACCESSING_APPLICATION = App3;<br />
};<br />
<br />
ALARM Alarm2 {<br />
COUNTER = Counter2;<br />
...<br />
ACCESSING_APPLICATION = App1;<br />
ACCESSING_APPLICATION = App3;<br />
ACCESSING_APPLICATION = App4;<br />
};<br />
<br />
SCHEDULETABLE ScheduleTable2 {<br />
COUNTER = CounterSlave2;<br />
... <br />
ACCESSING_APPLICATION = App1;<br />
ACCESSING_APPLICATION = App4;<br />
};<br />
<br />
== Memory Protection ==<br />
<br />
Memory protection will only be possible on processors that provide hardware support for memory protection.<br />
AUTOSAR memory protection scheme is based on the (data, code and stack) sections of the executable program. ERIKA's implementation take AUTOSAR requirements in the following way:<br />
<br />
*'''Stack:''' To keep context change still efficient and let the ERIKA's Stack sharing optimizzation still usable. All the stack space is accessible by all the OS-Application's TASK and ISR2 (In particualr ISR2s supports only stack sharing policy, so it's not possible specify a private stack for a ISR2).<br />
*'''Data:''' There is no TASK's or ISR2's private global data space, only OS-Application's globa ldata space is implemented.<br />
*'''Code:''' All the code is Shared. Data protection protect from data structures corruption.<br />
<br />
The '''Memory Protection''' sit on top of OS-Application configuration. So Memory Protection '''CANNOT BE ENABLED WITHOUT PROVIDING A FULL OS-Applications CONFIGURATION'''<br />
<br />
To enable Memory Protectionion the following OIL field can be specified:<br />
<br />
MEMORY_PROTECTION = TRUE;<br />
<br />
'''TASKs and and ISR2s of a NON-TRUSTED OS-Application can only access global data that belong to OS-Application global data space.'''<br />
<br />
To locate a variable in the right section, MemMap.h header file feature should be used.<br />
<br />
=== MemMap.h header file Rationale and Use ===<br />
<br />
'''MemMap.h''' file is the standar AUTOSAR tool to be used to handle the problem to locate data e code of an application in a compiler agnostic way. ERIKA's build chain, Starting from OIL OS-Application's configuration, will generate a '''MemMap.h''' that contains.<br />
<br />
For each OS-Application are reserved three sections:<br />
<br />
*'''ee_${APP_NAME}_bss''': To locate OS-Application's uninitialized variables.<br />
*'''ee_${APP_NAME}_data''': To locate OS-Application's initialized variables.<br />
*'''ee_${APP_NAME}_text''': To locate OS-Application's code (it is a predisposition to Code protection, not effectively used yet).<br />
<br />
With parameter substitution of ${APP_NAME} with the real OIL OSAPPLICATION Field Name.<br />
<br />
The sum of '''ee_${APP_NAME}_bss''' and '''ee_${APP_NAME}_data''' section will compose the '''OS-Application private data space'''.<br />
<br />
To add some variables or code to a OS-Application you have to use the following ''commands'' Macro defined right before <br />
the MemMap inclusion:<br />
<br />
*'''APP_${APP_NAME}_START_SEC_VAR_NOINIT/APP_${APP_NAME}_STOP_SEC_VAR_NOINIT'''<br />
*'''APP_${APP_NAME}_START_SEC_DATA/APP_${APP_NAME}_STOP_SEC_DATA'''<br />
*'''APP_${APP_NAME}_START_SEC_CODE/APP_${APP_NAME}_STOP_SEC_CODE'''<br />
<br />
As the following example:<br />
<br />
'''#define APP_App1_START_SEC_VAR_NOINIT'''<br />
'''#include "MemMap.h"'''<br />
<br />
EE_UREG app1_noinit1;<br />
EE_UREG app1_noinit2;<br />
<br />
'''#define APP_App1_STOP_SEC_VAR_NOINIT'''<br />
'''#include "MemMap.h"'''<br />
<br />
'''#define APP_App1_START_SEC_VAR_DATA'''<br />
'''#include "MemMap.h"'''<br />
<br />
EE_UREG app1_data1 = 1U;<br />
EE_UREG app1_data2 = 2U;<br />
<br />
'''#define APP_App1_STOP_SEC_VAR_DATA'''<br />
'''#include "MemMap.h"'''<br />
<br />
For Communication between OS-Application AUTOSAR introduce '''IOC''' (Inter OS-Applications Communication) '''Mechanism'''. An experimental support of '''IOC''' is provided by ERIKA, but RT-Druid cannot yet configure it, and since the IOC configuration is hard to be done correctly by hand, some special sections are providded that are accessible by ALL OS-Application by default. (It's suggested to reduce at the minimun the data shared between OS-Applications, to not frustrate Memory Protection). These sections are usable with the following MemMap.h ''commands'' Macros:<br />
<br />
*'''API_START_SEC_VAR_NOINIT/API_STOP_SEC_VAR_NOINIT'''<br />
*'''API_START_SEC_DATA/API_STOP_SEC_DATA'''<br />
<br />
=== TRSUTED OS-Application & Trusted Services (TRUSTED_FUNCTION) ===<br />
<br />
An OS-Appilcation, to bypass it's own bounduaries in a "controlled" way, can invoke a Trusted Function provided by (another) trusted OS-Application. That can require a switch from non-privileged to privileged mode. This is typically achieved by these operations:<br />
* (1) Each trusted OS-Application may export services which are callable from other OS-Applications.<br />
* (2) During configuration these trusted services must be configured to be called from a non-trusted OS-Application.<br />
* (3) The call from the non-trusted OS-Application to the trusted service is using a mechanism (e.g. trap/software interrupt) provided by the Operating System. The service is passed as an identifier that is used to determine, in the trusted environment, if the service can be called.<br />
* (4) The Operating System offers services to check if a memory region is write/read/execute accessible from an OS-Application. It also returns information if the memory region is part of the stack space.<br />
<br />
This is an example of TRUSTED function interface and OIL Configuration.<br />
<br />
'''N.B.''' If a '''"Service Interface"''' will be provided (a '''Service Interface''' is a function that wrap the ERIKA's '''CallTrustedService''' OS API call), as AUTOSAR coding style dictate; this '''must be added to the API code section''' with the use of '''MemMap.h and the ''commands'' API_START_SEC_CODE/API_STOP_SEC_CODE'''. (The use of the Code API Section it's not optinal because, even though Code protection is not implemented yet, inside the ERIKA's syscall handler, the call site address is checked, against Kernel and API boundaries, before to accept the call).<br />
<br />
TRUSTED Service Declaration Header File<br />
<br />
#define APP_App2Trusted_START_SEC_CODE<br />
#include "MemMap.h"<br />
'''/* TRUSTED Service */'''<br />
'''StatusType TRUSTED_TrustedService1 (TrustedFunctionIndexType index, TrustedFunctionParameterRefType ref);'''<br />
#define APP_App2Trusted_STOP_SEC_CODE<br />
#include "MemMap.h"<br />
<br />
#define API_START_SEC_CODE<br />
#include "MemMap.h"<br />
'''/* User inteface */'''<br />
'''StatusType CallTrustedService1 ( void );'''<br />
#define API_STOP_SEC_CODE<br />
#include "MemMap.h"<br />
<br />
TRUSTED Service Definition File<br />
<br />
'''/* User inteface */ '''<br />
StatusType CallSignalShutdown ( void )<br />
{<br />
'''/* User inteface Implementation */'''<br />
'''return CallTrustedService(EE_ID_TRUSTED_TrustedService1, NULL);'''<br />
}<br />
<br />
'''/* TRUSTED Service Implementation */'''<br />
StatusType TRUSTED_TrustedService1 (TrustedFunctionIndexType index,<br />
TrustedFunctionParameterRefType ref)<br />
{<br />
'''/* TRUSTED Service Implementation */'''<br />
}<br />
<br />
The OIL to configure a TRUSTED services for an Trusted OS-Application<br />
<br />
APPLICATION App2Trusted {<br />
TRUSTED = TRUE { '''/* <-- OS-Application have to be TRUSTED to have a TRUSTED_FUNCTION''' */<br />
'''TRUSTED_FUNCTION = TRUE {'''<br />
'''NAME = "TrustedService1";'''<br />
'''};'''<br />
TRUSTED_FUNCTION = TRUE {<br />
NAME = "TrustedService2";<br />
};<br />
...<br />
};<br />
<br />
== Timing Protection ==<br />
<br />
A timing fault in a real-time system occurs when a task or interrupt misses its deadline at runtime.<br />
AUTOSAR OS does not offer deadline monitoring for timing protection. Deadline monitoring is insufficient to correctly identify the Task/ISR causing a timing fault in an AUTOSAR system. When a deadline is violated this may be due to a timing fault introduced by an unrelated Task/ISR that interferes/blocks for too long. The fault in this case lies with the unrelated Task/ISR and this will propagate through the system until a Task/ISR misses its deadline. The Task/ISR that misses a deadline is therefore not necessarily the Task/ISR that has failed at runtime, it is simply the earliest point that a timing fault is detected.<br />
<br />
AUTOSAR use a budget mechanism to locate the violating entity. The following budgets can be configured:<br />
<br />
* '''Execution Budget for TASK and ISR2''': This is the ammount of time that a TASK/ISR2 can be executing (RUNNING status for a TASK). '''The budget is paused when a TASK/ISR2 is preempted'''. The budget is '''refilled''' when a '''TASK/ISR2 terminate''' or a '''TASK block on a WaitEvent'''.<br />
* '''Resource Lock Time''': This is the ammount of time that a TASK/ISR2 can lock a specific resource (with the call of '''GetResource'''). Can be specified for each resource that a TASK can access.<br />
* '''OS Interrupts Lock Time''': This is the ammount of time that a TASK/ISR2 can suspend OS Interrupts (with '''SupendOSInterrupts''').<br />
* '''All Interrupts Lock Time''': This is the ammount of time that a TASK/ISR2 can suspend/disable All Interrupts (with '''SupendAllInterrupts''' '''DisableAllInterrupts''').<br />
<br />
'''Autosar Timing Protection do NOT use OS-Application configuration but is done on schedulable entities (TASKs and ISR2).'''<br />
<br />
An example of '''timing protection budgets''' configuration:<br />
<br />
TASK Task1 {<br />
...<br />
'''TIMING_PROTECTION = TRUE {'''<br />
'''EXECUTIONBUDGET = 0.0025;'''<br />
'''MAXALLINTERRUPTLOCKTIME = 0.0001;'''<br />
'''RESOURCE = RESOURCELOCK {'''<br />
'''RESOURCELOCKTIME = 0.0002;'''<br />
'''RESOURCE = RES_SCHEDULER;'''<br />
'''};'''<br />
'''RESOURCE = RESOURCELOCK {'''<br />
'''RESOURCELOCKTIME = 0.0003;'''<br />
'''RESOURCE = RESOURCE1;'''<br />
'''};'''<br />
};<br />
};<br />
<br />
ISR ISR1 {<br />
'''CATEGORY = 2;'''<br />
...<br />
'''TIMING_PROTECTION = TRUE {'''<br />
'''EXECUTIONTIME = 0.0055;'''<br />
'''MAXALLINTERRUPTLOCKTIME = 0.0001;'''<br />
};<br />
};<br />
<br />
Timing Protection, can be configured to protect from too frequents TASKs' activations and ISR2s' preemptions. This mechanism is called '''inter-arrival''' time protection.<br />
<br />
An example of '''inter-arrival time protection''' configuration.<br />
<br />
TASK TaskPrio2 {<br />
...<br />
TIMING_PROTECTION = TRUE {<br />
'''TIMEFRAME = 0.0025;''' /* Two Activation of this TASK have to be separated by 250us to be acceptated. (Provided that TASK's number activation is respected) */<br />
EXECUTIONBUDGET = 0.0005;<br />
MAXALLINTERRUPTLOCKTIME = 0.0001;<br />
};<br />
};<br />
<br />
ISR Button_ISR2 {<br />
CATEGORY = 2;<br />
... <br />
TIMING_PROTECTION = TRUE {<br />
'''TIMEFRAME = 0.001;''' /* Two interrupts of this type have to be separated by 1ms to be acceptated */<br />
EXECUTIONTIME = 0.0055;<br />
MAXALLINTERRUPTLOCKTIME = 0.0001;<br />
};<br />
};<br />
<br />
'''N.B.''' Check following examples: <br />
* tricore/infineon_TriBoard-TC2X5_V2.0/Timing Protection automatic tests/Timing Protection budgets automatic tests<br />
* tricore/infineon_TriBoard-TC2X5_V2.0/Timing Protection automatic tests/Timing Protection inter-arrival protection automatic tests<br />
for configuration examples.<br />
<br />
== Stack Monitoring ==<br />
<br />
On processors that do not provide any memory protection hardware it may still be necessary to provide a “best effort with available resources” scheme for detectable classes of memory faults. Stack monitoring will identify where a task or ISR has exceeded a specified stack usage at context switch time.<br />
This may mean that there is considerable time between the system being in error and that fault being detected. Similarly, the error may have been cleared at the point the fault is notified (the stack may be less than the specified size when the context switch occurs).<br />
Note that if Memory Protection is enabled a stack overflow may cause a memory exception before the stack monitoring is able to detect the fault.<br />
<br />
= Architetures that support full AUTOSAR Features =<br />
* [[Infineon_Aurix]]<br />
<br />
= Note on Autosar Scalabilty Classes =<br />
<br />
'''ERIKA's kernel now implement all the features specified in Autosar OS specification''', but do not support scalability classes yet.<br />
Autosar Scalability Classes declare subsets of Autosar features and a set of checks that have to be done on configuration to guarantee that the subset is not overflowed. RT-Druid do not implement thsse checks (yet).<br />
<br />
'''Instead if a valid configuration is given to RT-Druid it enables all the features needed to support that configuration'''.</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=Infineon_AurixInfineon Aurix2015-01-12T16:51:00Z<p>Eguidieri: /* Build Multicore Application Single ELF with HighTec GCC Compiler */</p>
<hr />
<div>[[Category:Supported Devices]]<br />
= Infineon Aurix support =<br />
<br />
ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid will be released soon.<br />
Currently only the TC27x AURIX family have been fully ported: <br />
<br />
# Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers:<br />
** HIGHTEC GCC Compiler v4.6.3.1 (for both Single and Multicore). '''NOTE Version 4.6.3.0 DOES NOT WORK!!!''' (it has a problem on Tricore header files)<br />
** TASKING VX-toolset for TriCore v4.0r1 (only for Singlecore).<br />
** WIND RIVER DIAB Compiler Rel. 5.9.2.0 (only for Singlecore). <br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: It follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ 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.<br />
<br />
=== MCU & Board ===<br />
* The porting have been completly developed on top of:<br />
** TriBoard TC2x5 v2.0 equiped with a TC275TE MCU<br />
<br />
= Target Configuration and Programming =<br />
<br />
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]. Here are listed, after the information to set compiler path, the OIL fields customized for Tricore Aurix architecture.<br />
<br />
=== Compiler Path ===<br />
<br />
It is possible to choose the path of the compiler in three different ways:<br />
<br />
* ''PATH enviornment variable'': You can put compilers bin directories in PATH and the environmet can use them from here. <br />
* ''Compiler specific environment variables'':<br />
** '''HIGHTEC GCC toolchain''': You can specify the compiler path for HIGHTEC GCC with the '''TRICORE_GCCDIR'''.<br />
** '''Altium TASKING toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_TASKINGDIR'''.<br />
** '''Wind River Diab toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_DIABDIR'''.<br />
* ''RT-Druid configuration file'' see [[RT-Druid configuration#Compiler paths]]:<br />
** '''preference_tricore__path_for_gnu_compiler''' set HIGHTEC gcc compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_tasking_compiler''' set Altium TASKING compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_diab_compiler''' set Wind River Diab compiler path for Tricore AURIX[[#Compilers Notes|<sup>[a]</sup>]]<br />
<br />
Here is an [[Common oil.pref example|example of RT-Druid configuration file]].<br />
<br />
==== Compilers Notes ====<br />
* [a] RT-Druid support for Diab will be released ASAP.<br />
<br />
=== CPU ===<br />
<br />
'''CPU_DATA''' must be set to '''TRICORE'''.<br />
The compiler is specificed with the '''COMPILER_TYPE''' item, supported values are '''GNU''' (the default value) and '''TASKING'''.<br />
<br />
On multicore systems, one '''CPU_DATA''' instance can exist for each core. They must have different '''ID'''s. 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.<br />
<br />
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.<br />
We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value.<br />
In any case max declared CPU clock value (i.e. 200 Mhz for TC27x family), is guaranteed to be perfectly matched.<br />
<br />
'''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.<br />
<br />
Moreover a new field to declare a custom linker script have been added to CPU_DATA block: '''LINKERSCRIPT = "fake.ld";'''<br />
<br />
Example of a CPU_DATA section:<br />
<br />
CPU_DATA = TRICORE {<br />
CPU_CLOCK = 200.0;<br />
APP_SRC = "code.c";<br />
COMPILER_TYPE = GNU;<br />
MULTI_STACK = TRUE {<br />
IRQ_STACK = TRUE {<br />
SYS_SIZE = 128;<br />
};<br />
};<br />
};<br />
=== MCU ===<br />
<br />
'''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).<br />
<br />
MCU_DATA = TRICORE {<br />
MODEL = TC27x;<br />
COMPILER_TYPE = GNU;<br />
};<br />
<br />
=== BOARD ===<br />
<br />
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.<br />
<br />
BOARD_DATA = TRIBOARD_TC2X5;<br />
<br />
=== Interrupt Handling ===<br />
<br />
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.<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
HANDLER = "isr_low"; <br />
};<br />
<br />
The mean of the fields are:<br />
*'''CATEGORY''': the type of ISR as specified by OSEK. <br />
*'''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.<br />
*'''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).<br />
<br />
=== Trap Handling ===<br />
<br />
With TriCore AURIX, for the first time, we support the options to register handler for TRAP/Exceptions. OSEK OIL do not provide any field for trap handling: it suppose that all the handling is done inside the Kernel. Usually that's what happens, but sometime can be useful have some mechanism to attach an handler for a particular class of TRAPs.<br />
<br />
We decide to exetend ISR entry with the field '''TRAP''' that can be set to TRUE to enable TRAP handling. In this case you have to choose the TRAP class with the field LEVEL (or ENTRY). The only valid values for this configuration are:<br />
<br />
*'''TRAP_MMU''' (Actually useless because TC27x family don't have MMU, just a place holder)<br />
*'''TRAP_PROT''' (Handler for protection traps)<br />
*'''TRAP_INST''' (Handler for instructions traps)<br />
*'''TRAP_CONT''' (Handler for context traps) <br />
*'''TRAP_BUS''' (Handler forn bus traps)<br />
*'''TRAP_ASS''' (Handler for assertion traps) (please don't be silly :))<br />
*'''TRAP_SYS''' (Handler for system calls)<br />
*'''TRAP_NMI''' (Handler for NMI trap)<br />
<br />
OIL TRAP configuration example:<br />
<br />
ISR trap_context {<br />
LEVEL = "TRAP_CONT";<br />
HANDLER = "EE_trap_context"; //Trap handler<br />
TRAP = TRUE;<br />
};<br />
<br />
To define the handler in your code, you have to use the following syntax:<br />
<br />
TRAP(EE_CLASS_TRAPCONT, EE_trap_context) {<br />
while(1) {<br />
; /* dummy */<br />
}<br />
}<br />
<br />
TRAP class identifiers are the following:<br />
<br />
*EE_CLASS_TRAPMMU<br />
*EE_CLASS_TRAPPROT<br />
*EE_CLASS_TRAPINST<br />
*EE_CLASS_TRAPCONT<br />
*EE_CLASS_TRAPBUS<br />
*EE_CLASS_TRAPASS<br />
*EE_CLASS_TRAPSYS<br />
*EE_CLASS_TRAPNMI<br />
<br />
Inside the TRAP handler TIN (Trap Identification Number) value can be accessed with '''EE_tc_get_TIN()''' function or, for HIGHTEC GNUC Compiler, with the local variable '''tin'''. For more information you can check the '''$(ee)/pkg/cpu/tricore/inc/ee_tc_trap.h''' file.<br />
<br />
=== EEOPT ===<br />
<br />
EEOPT is a way to specify configuration flags to the Erika build environment.<br />
EEOPTs can be specified as strings in the OS section of the OIL file. Examples:<br />
<br />
EE_OPT = "EE_DEBUG";<br />
EE_OPT = "__ASSERT__";<br />
<br />
Please notice that spelling inside the OIL file includes an underscore: EE_OPT.<br />
<br />
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.<br />
<br />
The following EEOPTs are specific of AURIX Architecture:<br />
* '''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.<br />
* '''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.<br />
* '''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'''.<br />
* '''EE_ICACHE_ENABLED''': Enable the instruction cache in start-up code.<br />
* '''EE_DCACHE_ENABLED''': Enable data cache in start-up code<br />
<br />
= OSEK/VDX Extensions =<br />
<br />
This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.<br />
<br />
=== Resource Managament at ISR level ===<br />
<br />
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:<br />
<br />
TASK Task1 {<br />
...<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
ISR <SYMBOL> {<br />
PRIORITY = <PRIORITY_LEVEL>;<br />
CATEGORY = <ISR_TYPE>;<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };<br />
<br />
=== System Timer ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive '''IncrementCounter'''.<br />
<br />
The following is an example OIL definition for a System Counter:<br />
<br />
CPU_DATA = TRICORE{<br />
CPU_CLOCK = 200.0;<br />
...<br />
};<br />
<br />
COUNTER SystemTimer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM_SR0";<br />
SYSTEM_TIMER = TRUE;<br />
PRIORITY = 1;<br />
};<br />
SECONDSPERTICK = 0.001;<br />
};<br />
<br />
The meaning of the various attributes is as follows:<br />
* '''CPU_DATA/CPU_CLOCK''' is used to declare the clock frequency (in MHZ).<br />
* '''COUNTER/TYPE''' must be set to '''HARDWARE''', and '''SYSTEM_TIMER''' must be set to true.<br />
* '''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'''<br />
* '''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'''.<br />
* '''COUNTER/SECONDSPERTICK''' is used to declare the wanted time duration of one hardware tick in seconds.<br />
<br />
The System Timer can be attached to ALARMs as usual, as in the following example:<br />
<br />
ALARM AlarmExample {<br />
COUNTER = SystemTimer;<br />
ACTION = ACTIVATETASK{<br />
TASK = TaskExample;<br />
};<br />
};<br />
<br />
= CPU MCU & BOARD API =<br />
<br />
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'''.<br />
<br />
=== CPU API ===<br />
<br />
CPU layer represent all the behaviour shared between all the families of AURIX MCUs. 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.<br />
<br />
* '''void EE_tc_endint_disable( void )''': Temporary disable ENDINT protection.<br />
* '''void EE_tc_endint_enable( void )''': Re-enable ENDINT protection.<br />
<br />
* '''void EE_tc_safety_endinit_disable( void )''': Temporary disable SAFETY_ENDINIT protection.<br />
* '''void EE_tc_safety_endinit_enable( void )''': Re-enable SAFETY_ENDINIT protection.<br />
<br />
=== MCU API ===<br />
<br />
MCU layer represent the behaviour tied to an specific AURIX family of MCUs. For now only family TC27x is supported.<br />
Most part of the utilities belong to this layer:<br />
<br />
* '''void EE_tc27x_get_clock ( void )''': Return CPU clock frequency in HZ.<br />
* '''void EE_tc27x_configure_clock( EE_UREG fclock )''': Make the best effort to set CPU clock frequency to fclock value. It's the function used by '''StartOS''' when a '''CPU_CLOCK''' is configured in '''CPU_DATA'''.<br />
* '''void EE_tc27x_delay ( EE_UREG usec )''': Implement a busy loop wait of '''usec''' micorseconds.<br />
* '''void EE_tc27x_stm_set_sr0( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 0''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr0_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 0 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
* '''void EE_tc27x_stm_set_sr1( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 1''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr1_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 1 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
<br />
'''SR0''' and '''SR1''' API are both available to the user if '''System Timer''' is '''not''' configured. Otherwise only the one not used by system timer will be available.<br />
<br />
=== Board API ===<br />
<br />
BOARD layer represent the specific board support. There is only aminimal support for TriBoard TC2x5 v2.0 equiped with a TC275TE MCU:<br />
<br />
* '''void EE_tc2x5_leds_init( void )''': Initialize the 8 boards leds.<br />
* '''void EE_tc2x5_leds_on( void )''': Turns all the 8 leds.<br />
* '''void EE_tc2x5_leds_off( void )''': Turns off all the 8 leds.<br />
* '''void EE_tc2x5_turn_led(enum EE_tc2x5_led_id led_id, enum EE_tc2x5_led_status onoff)''': Turn the status of the led '''led_id''' (led IDs are collected in an enum in the form: '''EE_TRIBOARD_2X5_LED_{x}''' with {x}=[1..8]) on (onoff == '''EE_TRIBOARD_2X5_LED_ON''') or off (onoff == '''EE_TRIBOARD_2X5_LED_OFF''').<br />
* '''EE_BIT EE_tc2x5_read_button( void ): read external button value<br />
* '''void EE_tc2x5_button_irq_init( EE_TYPEISR2PRIO intvec )''': Configure the external button has an interrupt source and tie it to '''intvec''' priority handler.<br />
* '''void EE_tc2x5_button_irq_clear_request( void )''': Clear external button interrupt request.<br />
<br />
External button have to be connected to pin P15.8 on TC275TE corrisponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector of TriBoard TC2x5.<br />
<br />
= Debugger support =<br />
<br />
== Lauterbach Trace32 and ORTI support ==<br />
<br />
The ERIKA build system for Infineon AURIX produces a Lauterbach Trace32 configuration file ('''t32.cmm''') and a ORTI description file ('''system.orti''') inside the output directory. The ORTI file is produced only if ORTI support is enabled in the OIL configuration file. To launch the Trace32 debugger for singlecore projects, please issue '''t32mtc''' from the output directory. The ERIKA build system honors the '''T32SYS''' environment variable, if set (default ''T32SYS ?= C:/T32'')<br />
<br />
=== Muticore Projects ===<br />
<br />
For multicore projects, the files mentioned above are produced inside the core directories for each core, and a startup script (named '''tc27x_mc_start.sh''' under cygwin and linux or '''tc27x_mc_start.bat''' for Windows cmd) is produced in the output directory. If the build targeted AURIX Flash (the default behaviour), before executing debug you need to flash multicore images.<br />
To do that simply execute '''tc27x_mc_flash.sh''' (under Linux or Cygwin environment) or '''tc27x_mc_flash.bat''' (in Windows environment) scripts.<br />
<br />
To run the debugger, please issue ''tc27x_mc_start.[sh,bat]'' from the output directory. The script creates up to three instances of the debugger, one for each core. Slave cores cannot be started until master core (Core 0) enable them, thing that is made early in start-up code. Nonetheless, the startup script loads all the code and the debug symbols for each core and each debugger instances. The barrier inside '''StartOS()''' comes handy to synchronize the code running on the different cores.<br />
<br />
'''N.B.''' To let know the build system for wich Trace32 architecture (windows, windows64, pc_linux ecc.) it have to generate script for, set '''T32ARCH''' environment variable/pass it as make parameter with the right value (default ''T32ARCH ?= windows64'').<br />
<br />
== iSYSTEM winIDEA support ==<br />
<br />
ERIKA Enterprise is supported by iSYSTEM winIDEA. For more information about the ERIKA Enterprise support please chek the [http://www.isystem.com/supported-rtos/erika iSYSTEM - Erika webpage].<br />
<br />
For applications, based on an AUTOSAR/OSEK compliant OS such as ERIKA Enterprise, the OSEK Run-Time Interface (ORTI) file is a method for describing the structure of the RTOS to the debugger. By reading in the ORTI file generated by the RTDRUID when building an ERIKA-based application, the winIDEA debugger becomes ERIKA Enterprise OS-aware.<br />
<br />
ERIKA Enterprise OS awareness provides the following features:<br />
<br />
- Display of OS Resources and Status<br />
<br />
- Run-Time Analysis (Profiler Timeline) of Tasks and Interrupts (ISR Category 1 and 2)<br />
<br />
- Analysis of CPU Utilization (Profiler Statistics) of Tasks and Interrupts (ISR Category 1 and 2)<br />
<br />
=== Usage of NOP to prevent FIFO Full in the trace buffers ===<br />
<br />
(This note thanks to Armin Stingl, iSystem)<br />
<br />
You can use the following code to make the background task more trace-friendly:<br />
<br />
File: EE_oo_start_os() in pkg/kernel/oo/src/ee_startos.c<br />
<br />
<pre><br />
static void EE_oo_start_os(void)<br />
{<br />
/*<br />
* This assignment prevents from MISRA 14.2/FlexeLint 522:<br />
* lacks side-effects<br />
*/<br />
EE_oo_started = 1U;<br />
for(;;) {<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
;<br />
}<br />
}<br />
</pre><br />
<br />
In this way, the background forever loop will not loop continuously filling the trace buffer FIFO of the AURIX core.<br />
<br />
= Multicore Autosar OS Support =<br />
<br />
For details please see the following page: [[Erika AUTOSAR OS]]<br />
<br />
=== Build Multicore Application Single ELF with HighTec GCC Compiler ===<br />
<br />
The conventional ERIKA multicore build chain generate an ELF file for each core and the real application image is loaded on the device by Lauterbach, trought scripts. This approach is not straightforwardly portable on other programmer tools. Fortunately HighTec GCC Compiler has some peculiar features that have allowed us to change this approach, and for TriCore is possible to compile a Multicore Application contained in a single ELF.<br />
<br />
To enable this new build method add the following '''EEOPT=EE_BUILD_SINGLE_ELF''' to the project OIL file.<br />
<br />
To export some symbols from a core an '''HighTec GCC export file''' is needed. An HighTec export file looks like this:<br />
<br />
EXPORT FUNCTION _START ;<br />
EXPORT FUNCTION ErrorHook ;<br />
EXPORT FUNCTION StartupHook ;<br />
EXPORT FUNCTION ShutdownHook ;<br />
<br />
EXPORT OBJECT EE_oo_ErrorHook_ServiceID ;<br />
EXPORT OBJECT EE_oo_ErrorHook_data ;<br />
<br />
...<br />
<br />
To inform the build system to use an export file for a given core change the '''COMPILER_TYPE''' field of '''CPU_DATA''' OIL container, in the following way:<br />
<br />
CPU_DATA = TRICORE {<br />
ID = "master";<br />
...<br />
COMPILER_TYPE = GNU {<br />
EXPORT_FILE = "<relative path to the export file>";<br />
};<br />
...<br />
}; <br />
<br />
If this is done add explicitly '''EEOPT=EE_BUILD_SINGLE_ELF''' is no more needed.<br />
<br />
'''N.B:''' When used this approach an export files for the master core have to be provided always. The file can be empty if no symbols have to be exported by master core.<br />
<br />
This build approach is showed on following RT-Druid TriCore templates:<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test''<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore Spinlocks test''<br />
<br />
= Additional Notes =<br />
<br />
Since ERIKA 2.4.0 full AUTOSAR SC4 OS support for AURIX is publically released: you can find all the information about the implemented features and how to configure them at this page: [[Erika AUTOSAR OS]].</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=Infineon_AurixInfineon Aurix2014-11-14T15:37:07Z<p>Eguidieri: /* Additional Notes */</p>
<hr />
<div>[[Category:Supported Devices]]<br />
= Infineon Aurix support =<br />
<br />
ERIKA Enterprise supports the Infineon AURIX family microcontrollers. The support for RT-Druid will be released soon.<br />
Currently only the TC27x AURIX family have been fully ported: <br />
<br />
# Support for the HIGHTEC GCC Compiler (form both single and multicore) and TASKING compiler (only for singlecore).<br />
# Support for single- and multi-stack configurations.<br />
# ISR Type 1 and Type 2.<br />
# ORTI support.<br />
# Full Lauterbach support.<br />
<br />
* Supported compilers:<br />
** HIGHTEC GCC Compiler v4.6.3.1 (for both Single and Multicore). '''NOTE Version 4.6.3.0 DOES NOT WORK!!!''' (it has a problem on Tricore header files)<br />
** TASKING VX-toolset for TriCore v4.0r1 (only for Singlecore).<br />
** WIND RIVER DIAB Compiler Rel. 5.9.2.0 (only for Singlecore). <br />
<br />
* Mode of operation<br />
** Monostack: The Monostack configuration of the ERIKA Kernel models the fact that all tasks and ISRs in the system share the same stack.<br />
** Multistack: Every thread can have its private stack, or it can share it with other threads. <br />
** Multicore: It follows the same philosophy used by [[ERIKA multicore support|ERIKA on other multicore systems]] and specified by [http://www.autosar.org/ 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.<br />
<br />
=== MCU & Board ===<br />
* The porting have been completly developed on top of:<br />
** TriBoard TC2x5 v2.0 equiped with a TC275TE MCU<br />
<br />
= Target Configuration and Programming =<br />
<br />
ERIKA Enterprise is configured through [[Tutorial: RT-Druid and OIL basics | RT-Druid and an OIL file]]. Here are listed, after the information to set compiler path, the OIL fields customized for Tricore Aurix architecture.<br />
<br />
=== Compiler Path ===<br />
<br />
It is possible to choose the path of the compiler in three different ways:<br />
<br />
* ''PATH enviornment variable'': You can put compilers bin directories in PATH and the environmet can use them from here. <br />
* ''Compiler specific environment variables'':<br />
** '''HIGHTEC GCC toolchain''': You can specify the compiler path for HIGHTEC GCC with the '''TRICORE_GCCDIR'''.<br />
** '''Altium TASKING toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_TASKINGDIR'''.<br />
** '''Wind River Diab toolchain''': You can specify the compiler path for Altium TASKING with the '''TRICORE_DIABDIR'''.<br />
* ''RT-Druid configuration file'' see [[RT-Druid configuration#Compiler paths]]:<br />
** '''preference_tricore__path_for_gnu_compiler''' set HIGHTEC gcc compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_tasking_compiler''' set Altium TASKING compiler path for Tricore AURIX<br />
** '''preference_tricore__path_for_diab_compiler''' set Wind River Diab compiler path for Tricore AURIX[[#Compilers Notes|<sup>[a]</sup>]]<br />
<br />
Here is an [[Common oil.pref example|example of RT-Druid configuration file]].<br />
<br />
==== Compilers Notes ====<br />
* [a] RT-Druid support for Diab will be released ASAP.<br />
<br />
=== CPU ===<br />
<br />
'''CPU_DATA''' must be set to '''TRICORE'''.<br />
The compiler is specificed with the '''COMPILER_TYPE''' item, supported values are '''GNU''' (the default value) and '''TASKING'''.<br />
<br />
On multicore systems, one '''CPU_DATA''' instance can exist for each core. They must have different '''ID'''s. 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.<br />
<br />
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.<br />
We kept the algorithm to avaluate PLL parameters simple, so it implements a best effort approach to set the right value.<br />
In any case max declared CPU clock value (i.e. 200 Mhz for TC27x family), is guaranteed to be perfectly matched.<br />
<br />
'''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.<br />
<br />
Moreover a new field to declare a custom linker script have been added to CPU_DATA block: '''LINKERSCRIPT = "fake.ld";'''<br />
<br />
Example of a CPU_DATA section:<br />
<br />
CPU_DATA = TRICORE {<br />
CPU_CLOCK = 200.0;<br />
APP_SRC = "code.c";<br />
COMPILER_TYPE = GNU;<br />
MULTI_STACK = TRUE {<br />
IRQ_STACK = TRUE {<br />
SYS_SIZE = 128;<br />
};<br />
};<br />
};<br />
=== MCU ===<br />
<br />
'''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).<br />
<br />
MCU_DATA = TRICORE {<br />
MODEL = TC27x;<br />
COMPILER_TYPE = GNU;<br />
};<br />
<br />
=== BOARD ===<br />
<br />
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.<br />
<br />
BOARD_DATA = TRIBOARD_TC2X5;<br />
<br />
=== Interrupt Handling ===<br />
<br />
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.<br />
<br />
ISR IsrLow {<br />
CATEGORY = 2;<br />
PRIORITY = 1;<br />
HANDLER = "isr_low"; <br />
};<br />
<br />
The mean of the fields are:<br />
*'''CATEGORY''': the type of ISR as specified by OSEK. <br />
*'''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.<br />
*'''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).<br />
<br />
=== Trap Handling ===<br />
<br />
With TriCore AURIX, for the first time, we support the options to register handler for TRAP/Exceptions. OSEK OIL do not provide any field for trap handling: it suppose that all the handling is done inside the Kernel. Usually that's what happens, but sometime can be useful have some mechanism to attach an handler for a particular class of TRAPs.<br />
<br />
We decide to exetend ISR entry with the field '''TRAP''' that can be set to TRUE to enable TRAP handling. In this case you have to choose the TRAP class with the field LEVEL (or ENTRY). The only valid values for this configuration are:<br />
<br />
*'''TRAP_MMU''' (Actually useless because TC27x family don't have MMU, just a place holder)<br />
*'''TRAP_PROT''' (Handler for protection traps)<br />
*'''TRAP_INST''' (Handler for instructions traps)<br />
*'''TRAP_CONT''' (Handler for context traps) <br />
*'''TRAP_BUS''' (Handler forn bus traps)<br />
*'''TRAP_ASS''' (Handler for assertion traps) (please don't be silly :))<br />
*'''TRAP_SYS''' (Handler for system calls)<br />
*'''TRAP_NMI''' (Handler for NMI trap)<br />
<br />
OIL TRAP configuration example:<br />
<br />
ISR trap_context {<br />
LEVEL = "TRAP_CONT";<br />
HANDLER = "EE_trap_context"; //Trap handler<br />
TRAP = TRUE;<br />
};<br />
<br />
To define the handler in your code, you have to use the following syntax:<br />
<br />
TRAP(EE_CLASS_TRAPCONT, EE_trap_context) {<br />
while(1) {<br />
; /* dummy */<br />
}<br />
}<br />
<br />
TRAP class identifiers are the following:<br />
<br />
*EE_CLASS_TRAPMMU<br />
*EE_CLASS_TRAPPROT<br />
*EE_CLASS_TRAPINST<br />
*EE_CLASS_TRAPCONT<br />
*EE_CLASS_TRAPBUS<br />
*EE_CLASS_TRAPASS<br />
*EE_CLASS_TRAPSYS<br />
*EE_CLASS_TRAPNMI<br />
<br />
Inside the TRAP handler TIN (Trap Identification Number) value can be accessed with '''EE_tc_get_TIN()''' function or, for HIGHTEC GNUC Compiler, with the local variable '''tin'''. For more information you can check the '''$(ee)/pkg/cpu/tricore/inc/ee_tc_trap.h''' file.<br />
<br />
=== EEOPT ===<br />
<br />
EEOPT is a way to specify configuration flags to the Erika build environment.<br />
EEOPTs can be specified as strings in the OS section of the OIL file. Examples:<br />
<br />
EE_OPT = "EE_DEBUG";<br />
EE_OPT = "__ASSERT__";<br />
<br />
Please notice that spelling inside the OIL file includes an underscore: EE_OPT.<br />
<br />
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.<br />
<br />
The following EEOPTs are specific of AURIX Architecture:<br />
* '''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.<br />
* '''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.<br />
* '''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'''.<br />
* '''EE_ICACHE_ENABLED''': Enable the instruction cache in start-up code.<br />
* '''EE_DCACHE_ENABLED''': Enable data cache in start-up code<br />
<br />
= OSEK/VDX Extensions =<br />
<br />
This Section contains information about the OSEK/VDX Extensions (or optional features) that have been implemented for the AURIX support.<br />
<br />
=== Resource Managament at ISR level ===<br />
<br />
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:<br />
<br />
TASK Task1 {<br />
...<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
ISR <SYMBOL> {<br />
PRIORITY = <PRIORITY_LEVEL>;<br />
CATEGORY = <ISR_TYPE>;<br />
RESOURCE = "ResourceA";<br />
};<br />
<br />
RESOURCE ResourceA { RESOURCEPROPERTY = STANDARD; };<br />
<br />
=== System Timer ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
A Counter which is not a System Counter must be incremented explicitly using the Autosar primitive '''IncrementCounter'''.<br />
<br />
The following is an example OIL definition for a System Counter:<br />
<br />
CPU_DATA = TRICORE{<br />
CPU_CLOCK = 200.0;<br />
...<br />
};<br />
<br />
COUNTER SystemTimer {<br />
MINCYCLE = 1;<br />
MAXALLOWEDVALUE = 2147483647;<br />
TICKSPERBASE = 1;<br />
TYPE = HARDWARE {<br />
DEVICE = "STM_SR0";<br />
SYSTEM_TIMER = TRUE;<br />
PRIORITY = 1;<br />
};<br />
SECONDSPERTICK = 0.001;<br />
};<br />
<br />
The meaning of the various attributes is as follows:<br />
* '''CPU_DATA/CPU_CLOCK''' is used to declare the clock frequency (in MHZ).<br />
* '''COUNTER/TYPE''' must be set to '''HARDWARE''', and '''SYSTEM_TIMER''' must be set to true.<br />
* '''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'''<br />
* '''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'''.<br />
* '''COUNTER/SECONDSPERTICK''' is used to declare the wanted time duration of one hardware tick in seconds.<br />
<br />
The System Timer can be attached to ALARMs as usual, as in the following example:<br />
<br />
ALARM AlarmExample {<br />
COUNTER = SystemTimer;<br />
ACTION = ACTIVATETASK{<br />
TASK = TaskExample;<br />
};<br />
};<br />
<br />
= CPU MCU & BOARD API =<br />
<br />
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'''.<br />
<br />
=== CPU API ===<br />
<br />
CPU layer represent all the behaviour shared between all the families of AURIX MCUs. 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.<br />
<br />
* '''void EE_tc_endint_disable( void )''': Temporary disable ENDINT protection.<br />
* '''void EE_tc_endint_enable( void )''': Re-enable ENDINT protection.<br />
<br />
* '''void EE_tc_safety_endinit_disable( void )''': Temporary disable SAFETY_ENDINIT protection.<br />
* '''void EE_tc_safety_endinit_enable( void )''': Re-enable SAFETY_ENDINIT protection.<br />
<br />
=== MCU API ===<br />
<br />
MCU layer represent the behaviour tied to an specific AURIX family of MCUs. For now only family TC27x is supported.<br />
Most part of the utilities belong to this layer:<br />
<br />
* '''void EE_tc27x_get_clock ( void )''': Return CPU clock frequency in HZ.<br />
* '''void EE_tc27x_configure_clock( EE_UREG fclock )''': Make the best effort to set CPU clock frequency to fclock value. It's the function used by '''StartOS''' when a '''CPU_CLOCK''' is configured in '''CPU_DATA'''.<br />
* '''void EE_tc27x_delay ( EE_UREG usec )''': Implement a busy loop wait of '''usec''' micorseconds.<br />
* '''void EE_tc27x_stm_set_sr0( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 0''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr0_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 0 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
* '''void EE_tc27x_stm_set_sr1( EE_UINT32 usec, EE_TYPEISR2PRIO intvec )''': Programs '''STM compare register 1''' to trigger an IRQ after '''usec''' microseconds. '''intvec''' is the priority tied to this source, in other words it is the Interrupt Vector Table entry that will handle STM interrupt. With intvec == 0, the correponding service request node is left unprogrammed or resetted.<br />
* '''void EE_tc27x_stm_set_sr1_next_match( EE_UINT32 usec )''': Change '''previous programmed''' STM compare register 1 to trigger next IRQ after usec microseconds. To mantain fixed interrupt interval, it have to been called at the beginning of '''intvec''' handler.<br />
<br />
'''SR0''' and '''SR1''' API are both available to the user if '''System Timer''' is '''not''' configured. Otherwise only the one not used by system timer will be available.<br />
<br />
=== Board API ===<br />
<br />
BOARD layer represent the specific board support. There is only aminimal support for TriBoard TC2x5 v2.0 equiped with a TC275TE MCU:<br />
<br />
* '''void EE_tc2x5_leds_init( void )''': Initialize the 8 boards leds.<br />
* '''void EE_tc2x5_leds_on( void )''': Turns all the 8 leds.<br />
* '''void EE_tc2x5_leds_off( void )''': Turns off all the 8 leds.<br />
* '''void EE_tc2x5_turn_led(enum EE_tc2x5_led_id led_id, enum EE_tc2x5_led_status onoff)''': Turn the status of the led '''led_id''' (led IDs are collected in an enum in the form: '''EE_TRIBOARD_2X5_LED_{x}''' with {x}=[1..8]) on (onoff == '''EE_TRIBOARD_2X5_LED_ON''') or off (onoff == '''EE_TRIBOARD_2X5_LED_OFF''').<br />
* '''EE_BIT EE_tc2x5_read_button( void ): read external button value<br />
* '''void EE_tc2x5_button_irq_init( EE_TYPEISR2PRIO intvec )''': Configure the external button has an interrupt source and tie it to '''intvec''' priority handler.<br />
* '''void EE_tc2x5_button_irq_clear_request( void )''': Clear external button interrupt request.<br />
<br />
External button have to be connected to pin P15.8 on TC275TE corrisponding to pin 71 of PERIPHERALS (Xx02,Xx02) connector of TriBoard TC2x5.<br />
<br />
= Debugger support =<br />
<br />
== Lauterbach Trace32 and ORTI support ==<br />
<br />
The ERIKA build system for Infineon AURIX produces a Lauterbach Trace32 configuration file ('''t32.cmm''') and a ORTI description file ('''system.orti''') inside the output directory. The ORTI file is produced only if ORTI support is enabled in the OIL configuration file. To launch the Trace32 debugger for singlecore projects, please issue '''t32mtc''' from the output directory. The ERIKA build system honors the '''T32SYS''' environment variable, if set (default ''T32SYS ?= C:/T32'')<br />
<br />
=== Muticore Projects ===<br />
<br />
For multicore projects, the files mentioned above are produced inside the core directories for each core, and a startup script (named '''tc27x_mc_start.sh''' under cygwin and linux or '''tc27x_mc_start.bat''' for Windows cmd) is produced in the output directory. If the build targeted AURIX Flash (the default behaviour), before executing debug you need to flash multicore images.<br />
To do that simply execute '''tc27x_mc_flash.sh''' (under Linux or Cygwin environment) or '''tc27x_mc_flash.bat''' (in Windows environment) scripts.<br />
<br />
To run the debugger, please issue ''tc27x_mc_start.[sh,bat]'' from the output directory. The script creates up to three instances of the debugger, one for each core. Slave cores cannot be started until master core (Core 0) enable them, thing that is made early in start-up code. Nonetheless, the startup script loads all the code and the debug symbols for each core and each debugger instances. The barrier inside '''StartOS()''' comes handy to synchronize the code running on the different cores.<br />
<br />
'''N.B.''' To let know the build system for wich Trace32 architecture (windows, windows64, pc_linux ecc.) it have to generate script for, set '''T32ARCH''' environment variable/pass it as make parameter with the right value (default ''T32ARCH ?= windows64'').<br />
<br />
== iSYSTEM winIDEA support ==<br />
<br />
ERIKA Enterprise is supported by iSYSTEM winIDEA. For more information about the ERIKA Enterprise support please chek the [http://www.isystem.com/supported-rtos/erika iSYSTEM - Erika webpage].<br />
<br />
For applications, based on an AUTOSAR/OSEK compliant OS such as ERIKA Enterprise, the OSEK Run-Time Interface (ORTI) file is a method for describing the structure of the RTOS to the debugger. By reading in the ORTI file generated by the RTDRUID when building an ERIKA-based application, the winIDEA debugger becomes ERIKA Enterprise OS-aware.<br />
<br />
ERIKA Enterprise OS awareness provides the following features:<br />
<br />
- Display of OS Resources and Status<br />
<br />
- Run-Time Analysis (Profiler Timeline) of Tasks and Interrupts (ISR Category 1 and 2)<br />
<br />
- Analysis of CPU Utilization (Profiler Statistics) of Tasks and Interrupts (ISR Category 1 and 2)<br />
<br />
=== Usage of NOP to prevent FIFO Full in the trace buffers ===<br />
<br />
(This note thanks to Armin Stingl, iSystem)<br />
<br />
You can use the following code to make the background task more trace-friendly:<br />
<br />
File: EE_oo_start_os() in pkg/kernel/oo/src/ee_startos.c<br />
<br />
<pre><br />
static void EE_oo_start_os(void)<br />
{<br />
/*<br />
* This assignment prevents from MISRA 14.2/FlexeLint 522:<br />
* lacks side-effects<br />
*/<br />
EE_oo_started = 1U;<br />
for(;;) {<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
__asm("NOP");<br />
;<br />
}<br />
}<br />
</pre><br />
<br />
In this way, the background forever loop will not loop continuously filling the trace buffer FIFO of the AURIX core.<br />
<br />
= Multicore Autosar OS Support =<br />
<br />
For details please see the following page: [[Erika AUTOSAR OS]]<br />
<br />
=== Build Multicore Application Single ELF with HighTec GCC Compiler ===<br />
<br />
The conventional ERIKA multicore build chain generate an ELF file for each core and the real application image is loaded on the device by Lauterbach, trought scripts. This approach is not straightforwardly portable on other programmer tools. Fortunately HighTec GCC Compiler has some peculiar features that have allowed us to change this approach, and for TriCore is possible to compile a Multicore Application contained in a single ELF.<br />
<br />
To enable this new build method add the following '''EEOPT=EE_BUILD_SINGLE_ELF''' to the project OIL file.<br />
<br />
To export some symbols from a core an '''HighTec GCC export file''' is needed. An HighTec export file looks like this:<br />
<br />
EXPORT FUNCTION _START ;<br />
EXPORT FUNCTION ErrorHook ;<br />
EXPORT FUNCTION StartupHook ;<br />
EXPORT FUNCTION ShutdownHook ;<br />
<br />
EXPORT OBJECT EE_oo_ErrorHook_ServiceID ;<br />
EXPORT OBJECT EE_oo_ErrorHook_data ;<br />
<br />
...<br />
<br />
To inform the build system to use an export file for a given core change the '''COMPILER_TYPE''' field of '''CPU_DATA''' OIL container, in the following way:<br />
<br />
CPU_DATA = TRICORE {<br />
ID = "master";<br />
...<br />
COMPILER_TYPE = GNU {<br />
EXPORT_FILE = "<relative path to the export file>";<br />
};<br />
...<br />
}; <br />
<br />
If this is done add explicitly '''EEOPT=EE_BUILD_SINGLE_ELF''' is no more needed.<br />
<br />
'''N.B:''' When used this approach an export files for the master core have to be provided always. The file can be empty if no symbols have to be exported by master core.<br />
<br />
This build approach is showed on following RT-Druid TriCore templates:<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore System StartUp test''<br />
<br />
''tricore/infineon_TriBoard-TC2X5_V2.0/Multicore automatic tests/Multicore Spinlocks test''<br />
<br />
'''WARNING:''' For the release '''2.3.0''' the default configuration of project don't let you build the project as single .elf. To do that you need to change the target called by build system makefile.<br />
To do that open project '''properties->C/C++ Build->behaviour''' and '''delete the 'all' target''' from ''Build (Incremental build)''.<br />
<br />
= Additional Notes =<br />
<br />
Since ERIKA 2.4.0 full AUTOSAR SC4 OS support for AURIX is publically released: you can find all the information about the implemented features and how to configure them at this page: [[Erika AUTOSAR OS]].</div>Eguidierihttp://erika.tuxfamily.org/wiki/index.php?title=PeoplePeople2014-09-19T08:53:55Z<p>Eguidieri: </p>
<hr />
<div>This is a probably incomplete list of the various contributors to the ERIKA Enterprise Project:<br />
<br />
(in alphabetical order)<br />
<br />
* Alessandro Colantonio<br />
** initial ARM7TDMI porting<br />
* Antonio Romano<br />
** AVR port<br />
* Bernardo Dal Seno<br />
** Mico32 porting<br />
** Support for CodeWarrior compiler for PowerPC e200<br />
** Multicore support for PowerPC e200<br />
** Improvements to makefiles<br />
* Christian Nastasi<br />
** Microchip PIC32 porting<br />
** uWireless stack (IEEE 802.15.4 compliant)<br />
** support for various boards, MCUs and contribs <br />
* Daniele Alessandrelli<br />
* Dario Di Stefano<br />
** Scilab/Scicos blocks, Amazing Ball blocks<br />
** S12XS porting<br />
* Errico Guidieri<br />
** Kernel refactoring for code readability and MISRA-C:2004 conformance<br />
** TriCore 1.6.x (AURIX) Porting<br />
** AUTOSAR OS Multicore API & Service Dispatching<br />
** AUTOSAR OS Full Support (OS-Applications, Schedule Tables, Memory Protection, Timing Protection, ProtectionHook, Stack Monitoring) <br />
* Fabio Checconi<br />
** PowerPC e200 porting<br />
* Francesco Prosperi<br />
** Scilab scicos blocks<br />
* Francesco Esposito<br />
* Gianluca Franchino<br />
** uWireless stack support for MRF24J40 and CC2420<br />
** Microchip MiWiP2P porting<br />
** MRF24J40 and CC2420 drivers<br />
** Demos and Application Notes for the Flex Board<br />
** Renesas RX200 porting<br />
** Cortex M0 porting<br />
**OSEK COM update and support <br />
* Giorgio Buttazzo<br />
* Giuseppe Lipari<br />
* Jan C. Kleinsorge<br />
** Tricore1 porting<br />
* Mauro Marinoni<br />
* Marco Di Natale<br />
* Marco Ghibaudi<br />
* Martin Hoffmann<br />
** X86 porting<br />
* Nicola Serreli<br />
** RT-Druid<br />
* Paolo Gai<br />
** FP, EDF, FRSH, OO Kernel, various architecture portings, examples, testcases, manuals, website<br />
* Paolo Pagano<br />
* Roberto Bucher<br />
** Scilab/Scicos support<br />
* Simone Mannori<br />
** Scilab/Scicos support<br />
* [[user:steve|Steve Langstaff]], Pebble Bay Consulting Ltd <br />
** EnSilica eSi-RISC porting<br />
** MSP430 LaunchPad Board Support Package<br />
** MSP430 RT-Druid transforms</div>Eguidieri