This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

OS

1 - MicrosarOS_RH850_SafeContext_SafetyManual

MICROSAR OS SafeContext

3 - MicrosarOS_RH850_SafeContext_SafetyManuals

Safety Manual MICROSAR OS SafeContext 
 
 
 
 
 
 
 
 
 
 
 
MICROSAR OS SafeContext 
Safety Manual 
 
RH850 with Green Hills Compiler 
 
 
 
 
 
 
 
 
 
 
 
Authors 
Senol Cendere, Yohan Humbert 
Version 
1.05 
Status 
Released 
Document ID  OS03.00124.10 
 
 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           1 / 80 

Safety Manual MICROSAR OS SafeContext 
Document Information 
History 
Author 
Date 
Version  Remarks 
Senol Cendere  
2014-02-17  1.00 
Creation for RH850 
Senol Cendere 
2014-02-26  1.01 
Updated the Requirement IDs 
Senol Cendere 
2014-05-09  1.02 
Adaption for RH850 P1M 
Senol Cendere 
2014-08-18  1.03 
Reworked after Safety Manual Review 
Senol Cendere 
2014-09-22  1.04 
Added reference for Renesas Electronics RH850/P1M  
Safety Application Note 
Removed CPU derivative specification  
Removed compiler options (both are specified in safety 
case) 
Yohan Humbert 
2014-12-03  1.05 
Added level support 
 
[END OF HIST ORY]
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           2 / 80 

Safety Manual MICROSAR OS SafeContext 
 
2015, Vector Informatik GmbH 
Version: 1.05                           3 / 80 

Safety Manual MICROSAR OS SafeContext 
Reference Documents 
No.  Source 
Title 
Version 
[1]     
AUTOSAR Operating System Specification1 
3.x - 
4.x 
[2]     
OSEK/VDX Operating System Specification2 
2.2.3 
[3]    Vector Informatik GmbH  User manual of Vector MICROSAR OS 
6.03 
TechnicalReference_Microsar_Os.pdf 
[4]    Vector Informatik GmbH  User manual of Vector MICROSAR OS RH850,   1.04 
hardware specific part 
TechnicalReference_MICROSAROS_RH850_S
afeContext.pdf 
[5]     
International Organization for Standardization, 
 
Draft International Standard ISO/DIS 26262 
Road Vehicles - Functional Safety (all parts), 
2009 
[6]    Renesas Electronics 
V850E3v5 Architecture Specifications 
(4th edition) 
[7]    Renesas Electronics  
RH850 G3M User’s Manual: Software 
Rev. 0.10 
 
r01us0042ej0020_rh850g3m.pdf 
Oct. 2012 
[8]    Renesas Electronics 
RH850/P1x Group User’s Manual: Hardware 
Rev. 0.60 
r01uh0436ej0041_rh850p1x.pdf 
Jul. 2014 
[9]    Green Hills Software 
MULTI: Building Applications for Embedded 
PubID: 
V850 and RH850 build_v800.pdf 
build_v800-
472243 
Date: 
September 12, 
2012 
[10]   Vector Informatik GmbH  Vector MICROSAR OS SafeContext Concept 
1.03 
[11]   Renesas Electronics 
RH850/P1M Safety Application Note 
Rev.0.20 
September 1, 
2014 
                                            
1 This document is available in PDF-format on the Internet at the Autosar homepage: http://www.Autosar.org 
2 This document is available in PDF-format on the Internet at the OSEK/VDX homepage: http://www.osek-vdx.org 
2015, Vector Informatik GmbH 
Version: 1.05                           4 / 80 

Safety Manual MICROSAR OS SafeContext 
Contents 
1 
Purpose ......................................................................................................................... 9 
1.1 

Safety Element out of Context (SEooC) ............................................................. 9 
1.2 
Standards and Legal requirements .................................................................... 9 
2 
Concept ....................................................................................................................... 10 
2.1 

SafeContext Is One Part of a Whole ................................................................ 10 
2.2 
Safety Goal ...................................................................................................... 10 
2.3 
Safety Requirements ....................................................................................... 10 
2.4 
SafeContext Functionality ................................................................................ 11 
2.4.1 
Safety Part ....................................................................................... 13 
2.4.2 
Detailed List of Functionality ............................................................ 15 
2.4.2.1 

Safety ............................................................................ 15 
2.4.2.2 
Silent ............................................................................. 16 
2.4.2.3 
Not provided .................................................................. 17 
2.5 
Safe State ........................................................................................................ 19 
3 
Overview of Requirements to the OS User ............................................................... 20 
4 
General SafeContext Assumptions ........................................................................... 22 
4.1 
Context Definition............................................................................................. 23 
5 
OS Source Checksum ................................................................................................ 24 
6 
Patching the Configuration Block ............................................................................. 26 
6.1 

Using ElfConverter ........................................................................................... 26 
6.2 
Using ConfigBlockCRCPatch ........................................................................... 27 
7 
General Configuration Guidelines ............................................................................. 28 
8 
Review General Part of Configuration Block ............................................................ 30 
8.1 

How to Read Back the Configuration ............................................................... 30 
8.1.1 
Using HexConverter ......................................................................... 31 
8.1.2 
Using ConfigViewer .......................................................................... 31 
8.2 
General Configuration Information ................................................................... 32 
9 
Review Generated Code ............................................................................................. 33 
9.1 

Manual Reviews .............................................................................................. 33 
9.1.1 

Review generated file tcb.h .............................................................. 33 
2015, Vector Informatik GmbH 
Version: 1.05                           5 / 80 

Safety Manual MICROSAR OS SafeContext 
10  Qualifying Silent OS Part ........................................................................................... 34 
10.1 
Using MICROSAR Safe Silence Verifier (MSSV) ............................................. 34 
11  Review User Software ................................................................................................ 36 
12  Hardware Specific Part ............................................................................................... 39 
12.1 
Interrupt Vector Table ....................................................................................... 42 
12.1.1 

Header Include Section .................................................................... 42 
12.1.2 
Core Exception Vector Table ............................................................ 43 
12.1.3 
EIINT Vector Table ........................................................................... 44 
12.1.4 
CAT2 ISR Wrappers ......................................................................... 45 
12.2 
Configuration Block .......................................................................................... 46 
12.2.1 

How to read back the ConfigBlock ................................................... 46 
12.2.2 
Additional Information ...................................................................... 47 
12.2.3 
How to start the review ..................................................................... 48 
12.2.3.1 
Indexes of applications, task , ISRs, trusted and non-
trusted functions ............................................................ 49 

12.2.3.2 
Review against User’s Design ....................................... 49 
12.2.4 
How to review the general information (block 0) ............................... 50 
12.2.5 
How to review the task start addresses (block 1) ............................. 52 
12.2.6 
How to review the task trusted information (block 2) ........................ 53 
12.2.7 
How to review the task preemptive information (block 3) .................. 54 
12.2.8 
How to review the task stack start and end addresses (block 4 and 
5) ..................................................................................................... 55 

12.2.9 
How to review the task ownership information (block 6) ................... 56 
12.2.10  How to review the category 2 ISR start addresses (block 7) ............. 57 
12.2.11  How to review the CAT2 ISR trusted information (block 8) ............... 58 
12.2.12  How to review the CAT2 ISR nested information (block 9) ............... 59 
12.2.13  How to review CAT2 ISR stack start and end addresses (block 10 
and 11) ............................................................................................. 60 
12.2.14  How to review the CAT2 ISR ownership information (block 12) ........ 62 
12.2.15  How to review the trusted functions start addresses (block 13) ........ 63 
12.2.16  How to review the non-trusted functions start addresses (block 14) . 64 
12.2.17  How to review the non-trusted functions ownership information 
(block 15) ......................................................................................... 65 
12.2.18  How to review the application dynamic MPU settings (block 16) ...... 66 
12.2.19  How to review the interrupt channel index (block 17) ....................... 67 
12.2.20  How to review the ISR interrupt priority level (block 18) ................... 68 
12.2.21  How to review the peripheral regions configuration (block 19) .......... 69 
12.2.22  How to review the static MPU regions configuration (block 20) ........ 70 
12.2.23  How to review the application trusted information (block 21) ............ 71 
2015, Vector Informatik GmbH 
Version: 1.05                           6 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.24  How to review the core control block address information (block 
22) ................................................................................................... 72 
12.3 
Linker Memory Sections ................................................................................... 73 
12.4 
Linker Include Files .......................................................................................... 75 
12.4.1 

Review File osdata.dld ..................................................................... 75 
12.4.2 
Review File ossdata.dld ................................................................... 76 
12.4.3 
Review File osstacks.dld .................................................................. 77 
12.4.4 
Review File osrom.dld ...................................................................... 78 
12.4.5 
Review File ostdata.dld .................................................................... 78 
12.5 
Stack Size Configuration .................................................................................. 79 
12.6 
Stack Monitoring .............................................................................................. 79 
12.7 
Usage of MPU Regions.................................................................................... 80 
12.8 
Usage of Peripheral Interrupt API ..................................................................... 80 
 
2015, Vector Informatik GmbH 
Version: 1.05                           7 / 80 

Safety Manual MICROSAR OS SafeContext 
Illustrations 
Figure 2-1 
Quality Levels of SafeContext Functionalities ........................................... 12 
Figure 2-2 
Stored and active contexts ........................................................................ 14 
Figure 3-1 
Strategy for safety configuration ............................................................... 21 
Figure 7-1 
Linking example ........................................................................................ 29 
 
Tables 
Table 2-1  
Safety Functionality .................................................................................. 15 
Table 2-2  
Silent Functionality.................................................................................... 16 
Table 2-3  
Functionality – Not provided ..................................................................... 17 
Table 4-1  
General SafeContext Assumptions ........................................................... 23 
Table 6-1  
ElfConverter parameters ........................................................................... 26 
Table 8-1  
HexConverter parameters......................................................................... 31 
Table 8-2  
ConfigViewer parameters ......................................................................... 31 
 
 
 
 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           8 / 80 

Safety Manual MICROSAR OS SafeContext 

Purpose 
1.1 
Safety Element out of Context (SEooC) 
MICROSAR OS SafeContext is a Safety Element out of Context (SEooC). It is developed 
based  on  assumptions  on  the  intended  functionality,  use  and  context,  including  external 
interfaces.  To  have  a  complete  safety  case,  the  validity  of  these  assumptions  has  to  be 
checked in the context of the actual item after integration of the SEooC. 
The application conditions for SEooC provide the assumptions made on the requirements 
(including  safety  requirements)  that  are  placed on the  SEooC by  higher  levels  of design 
and also on the design external to the SEooC and the assumed safety requirements and 
assumptions related to the design of the SEooC. 
Information  given  by  this  document  helps  to  check  whether  the  SEooC  fulfills  the  item 
requirements,  or  whether  a  change  to  the  SEooC  is  necessary  in  accordance  with  the 
requirements of ISO 26262. 
1.2 
Standards and Legal requirements 
Standards followed by the development of MICROSAR OS SafeContext: 
>  ISO 262623 
>  OSEK OS4 
>  AUTOSAR OS5 
 
                                            
3 International Standard ISO 26262 Road Vehicles - Functional Safety (all parts), 2011 
4 OSEK/VDX Operating System, v2.2.3 
5 AUTOSAR Specification of Operating  System 
2015, Vector Informatik GmbH 
Version: 1.05                           9 / 80 

Safety Manual MICROSAR OS SafeContext 

Concept 
This  chapter  provides  a  description  of  the  assumed  safety  requirements  and  the  main 
concept. 
2.1 
SafeContext Is One Part of a Whole 
SafeContext  is  part  of  Vector  SafeExecution.  SafeExecution  consists  of  SafeContext  for 
prevention from corrupted data and SafeWatchdog for supervision of timing behavior. This 
document covers SafeContext only. [SPMF92:0050] 
2.2 
Safety Goal 
The safety goal is to ensure context integrity for all safety critical parts. Whenever a safety 
critical  code  is  executed,  it  is  guaranteed  that  the  code  is  executed  with  the  correct 
context. After  pre-emption  or  interruption,  execution  is  resumed  with  the  correct  context. 
The  integrity  of  the  memory  is  ensured  by  usage  of  hardware  (e.g.  MPU)  and  software 
measures. 
2.3 
Safety Requirements 
To  achieve  this  safety  goal,  the  following  assumed  safety  requirements  are  provided  by 
SafeContext: 
ASA_OS_1:  Non-trusted  software  must  be  prevented  from  overwriting  data  of  safety 
relevant software. 
ASA_OS_2: runtime context (Task, Hook, (Non-)Trusted-Function and ISR) must not be 
destroyed by a switch (to another runtime context). 
ASA_OS_3:  A  runtime  context  shall  be  set  up  according  to  compiler  and  processor 
specifications. 
ASA_OS_4:  Services  to  prevent  data  inconsistencies  by  racing  conditions  shall  be 
provided. 
ASA_OS_5: The OS never writes to unintended memory locations. 
 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           10 / 80 


Safety Manual MICROSAR OS SafeContext 
 
2.4 
SafeContext Functionality 
MICROSAR OS SafeContext implements the AUTOSAR OS and OSEK OS standards of a 
real-time operating system with some restrictions. 
The functionality provided by MICROSAR OS is task switching, interrupt handling, memory 
protection handling, timer services and others. SafeContext provides an efficient solution 
also in respect of safety. Therefore the OSEK/AUTOSAR OS functionality is divided into 3 
groups: 
1.  Functionality implemented according ISO 26262 to achieve ASIL. 
2.  Functionality implemented according to “Silent” principle to prevent from safety data 
overwritten by OS code. 
3.  Functionality  which  is  not  supported  in  SafeContext.  It  is  assumed  that  this 
functionality  is  not  needed  by  a  safety  related ECU  or  it  can  be  reached by  other 
existing means. 
 
This chapter describes which of the groups certain functionality falls into. 
 
 
 
Basic Knowledge 
The idea of “Silent” code is not to disturb other software by means of unintended 
  memory writes. To provide high performance, this is not achieved by a hardware 
protection mechanism (which would require MPU reconfiguration for each API call) but 
by analysis of the OS code. 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           11 / 80 

Safety Manual MICROSAR OS SafeContext 
Dispatcher
Scheduler
MPU management
Task management
Interrupt management
Alarm management
Event management
Resource management
Configuration (ASIL)
Configuration (QM)
ASIL
Silent
OS  
Figure 2-1  Quality Levels of SafeContext Functionalities 
AUTOSAR OS is a statically configured operating system. The configuration uses 
configuration editors and code generators to configure the OS. To ease the safety 
development the configuration is divided into two parts. 
1.  Configuration of Safety relevant functionality. The configuration is stored in the ECU 
in a separate configuration block. 
2.  Configuration  of  silent  functionality:  This  configuration  is  generated  and  compiled 
into the OS code. 
Additionally  some  safety  relevant  configuration  parameters  are  generated  and  compiled 
into  the  OS  code.  Those  have  to  be  reviewed  by  the  user  according  the  rules  in  this 
document. 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           12 / 80 


Safety Manual MICROSAR OS SafeContext 
 
 
2.4.1  Safety Part 
SafeContext provides the following functionality safely: 
1.  context switching 
2.  MPU management 
3.  Interrupt API 
4.  no unintended overwriting of memory 
 
The context is defined as: 
>  The set of registers, which is used by the compiler 
>  The stack pointer 
>  CPU mode (including interrupt state and privilege mode) 
>  Memory Access Rights 
 
Explanations: 
>  A context switch occurs in several situations. These are: Task start/switch, ISR 
entry/exit, call of OS services, call of (Non-)Trusted Functions and Hook routines. 
Conclusions: 
>  If a user program is executed, it will always be executed with the correct context 
>  After interruptions it is guaranteed that execution is resumed with the correct context 
>  Freedom from interference with respect to memory will be achieved by using memory 
protection hardware (e.g. MPU) for non-trusted code. 
>  Data inconsistency due to race conditions can be prevented by using the interrupt 
API. 
 
 
 
Note 
Other OS functionality follows the silent principle. For example the sequence of task 
  executions (scheduling) including the Task pre-emption is provided on QM level. 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           13 / 80 

Safety Manual MICROSAR OS SafeContext 
The  operating  system  provides  safe  switching  of  memory  access  rights  during  context 
switches to ensure that non-trusted code does not modify data of other OS-Applications (if 
not explicitly allowed). In addition the OS interrupts Tasks or ISRs to execute higher priority 
ISRs. By switching to another context the correct context is set up. By switching back to an 
interrupted Task or ISR, the correct and unchanged context is restored. To avoid change of 
a saved context of an interrupted or waiting task, memory protecting hardware is used. 
All points in the OS where context switches are performed or are necessary to perform are 
identified and developed according the safety standard. 
At each point in time only one context is active. All other contexts are saved and protected 
by hardware against accidental alterations. 
 
 
inactive 
inactive 
active 
inactive 
inactive 
inactive 
time 
MPU Protection 
now 
MPU Protection 
Register 
Register 
Register 
Register 
Register 
Register 
Context 
Context 
Context 
Context 
Context 
Context 
Stack 
Stack 
Stack 
Stack 
Stack 
Stack 
 
Figure 2-2  Stored and active contexts 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           14 / 80 

Safety Manual MICROSAR OS SafeContext 
2.4.2  Detailed List of Functionality 
2.4.2.1  Safety 
The following OS services and there functionality is developed according to ASIL. 
Class 
Description 
OS Service APIs 
StartOS 
osInitialize 
osInitINTC 
ShutdownOS 
DisableAllInterrupts 
EnableAllInterrupts  
SuspendAllInterrupts 
ResumeAllInterrupts 
SuspendOSInterrupts 
ResumeOSInterrupts 
CallTrustedFunction 
CallNonTrustedFunction 
osReadPeripheral8 
osReadPeripheral16 
osReadPeripheral32 
osWritePeripheral8 
osWritePeripheral16 
osWritePeripheral32 
osModifyPeripheral8 
osModifyPeripheral16 
osModifyPeripheral32 
osCheckMPUAccess 
osGetConfigBlockVersion 
GetApplicationID 
GetISRID  
GetTaskID  
osGetStackUsage 
osGetSystemStackUsage 
osGetISRStackUsage 
OS System Hooks 
StartupHook 
ErrorHook 
ProtectionHook 
ShutdownHook 
Table 2-1   Safety Functionality 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           15 / 80 

Safety Manual MICROSAR OS SafeContext 
2.4.2.2  Silent 
The  following  API  functions  are  developed  according  to  Silent  principle.  SafeContext 
ensures that they do not violate the assumed safety goal mentioned.  Exceptions may be 
possible, if one of these features has been explicitly ordered as safety relevant. Read the 
hardware specific part of this document if so. 
Class 
Description 
OS service API 
ActivateTask  
TerminateTask 
ChainTask 
Schedule 
GetTaskState 
GetResource 
ReleaseResource 
SetEvent  
ClearEvent  
GetEvent  
WaitEvent  
GetAlarm  
SetRelAlarm  
SetAbsAlarm  
CancelAlarm  
GetActiveApplicationMode 
CheckObjectAccess  
CheckObjectOwnership  
StartScheduleTableRel 
StartScheduleTableAbs  
StopScheduleTable  
NextScheduleTable  
GetScheduleTableStatus  
IncrementCounter 
GetElapsedValue/GetElapsedCounterValue 
GetCounterValue  
Timer handling 
The handling of timer hardware is realized as QM software. 
Scheduling 
The correct sequence of processing application programs is realized with 
QM-Software (priority handling, including Resources). 
ORTI 
ORTI is only supported in Silent part of the OS. 
Table 2-2   Silent Functionality 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           16 / 80 

Safety Manual MICROSAR OS SafeContext 
2.4.2.3  Not provided 
The  features  listed  in  the  following  table  are  not  supported  in  SafeContext  per  default. 
Exceptions may be possible, if one of these features has been explicitly ordered. Read the 
hardware specific part of this document if so. 
Class 
Description 
OS service API 
TerminateApplication 
CheckISRMemoryAccess 
CheckTaskMemoryAccess 
>  For ShutdownOS the AUTOSAR OS requirement OS054 is not 
supported, i.e. non-trusted OS-Applications may successfully call 
ShutdownOS. 
StartScheduleTableSynchron 
SyncScheduleTable  
SetScheduleTableAsync 
COM 
OSEK COM inter task communication with messages is not supported 
Interrupt resources  Resources are only available at task level. 
Protection Reaction  The only allowed protection reaction in the ProtectionHook is 
PRO_SHUTDOWN. Other reactions will be interpreted as PRO_SHUTDOWN.  
[SPMF92:0020] 
Killing 
Forcible terminating Tasks or Applications is not supported. 
OS Hooks 
PreTaskHook (only for debugging!) 
PostTaskHook (only for debugging!) 
ISRHook 
PreAlarmHook 
OS Application 
StartupHook<ApplName> 
specific Hooks 
ErrorHook<ApplName> 
ShutdownHook<ApplName> 
Address Parameter  In case API functions with out-parameters are called with illegal address, 
Check 
they do not return with the error code E_OS_ILLEGAL_ADDRESS as 
required by the AUTOSAR specification. Instead the out parameter is 
written with the access rights of the caller, which may lead to a memory 
protection violation in case the given pointer is invalid.  
Stack optimization 
Single stack model is not supported. 
Internal Resources  Internal Resources are not supported. 
Configuration 
The following hooks must be enabled: 
Aspects 
StartupHook 
ErrorHook 
ShutdownHook 
ProtectionHook 
Only SCALABILITYCLASS SC3 or SC4 is supported. Memory protection 
must be active. 
STACKMONITORING must be enabled. 
OSInternalChecks must be configured to Additional. 
ORTIVersion = 2.0 is not supported. 
ErrorInfoLevel = Modulenames is not supported. 
Table 2-3   Functionality – Not provided 
2015, Vector Informatik GmbH 
Version: 1.05                           17 / 80 

Safety Manual MICROSAR OS SafeContext 
 
2015, Vector Informatik GmbH 
Version: 1.05                           18 / 80 

Safety Manual MICROSAR OS SafeContext 
2.5 
Safe State 
The  safe  state  in  SafeContext  is  shutdown  (endless  loop  with  interrupts  disabled).  The 
safe  state  is  entered  whenever  the  OS  detects  a  violation  of  its  safety  goal  or  even  an 
attempt.  Before  the  safe  state  is  entered,  the  ShutdownHook  is  called.  The 
ShutdownHook may contain user code which is necessary to reach the defined safe state 
of the system. This might lead to a reset in combination with a watchdog.  
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           19 / 80 


Safety Manual MICROSAR OS SafeContext 

Overview of Requirements to the OS User 
For  integration  of  the  SafeContext  into  a  particular  context,  the  user  has  the  following 
requirements to be fulfilled. They can be seen as steps to integrate the SEooC in the ECU 
without harming the assumed safety goal.  
The top level requirements are listed in the following table. They are considered in more 
detail later. If all sub-requirements are checked, you can check the according top level 
requirement too. 
 
Description of requirements to the OS user 
Fulfilled 
Check that all assumptions made by SafeContext are valid  
 
(see chapter “General SafeContext Assumptions”) 
Check code integrity of the used OS sources 
 
(see chapter “OS Source Checksum”) 
Add CRC into the configuration block after linkage 
 
(see chapter “Patching the Configuration Block”) 
Check general configuration guidelines 
 
(see chapter “General Configuration Guidelines”) 
Review the safety relevant configuration data 
 
(see chapter “Review General Part of Configuration Block”) 
Review the generated code  
 
(see chapter “Review Generated Code”) 
Review your software  
 
(see chapter “Review User Software”) 
Execute MICROSAR Safe Silence Verifier (MSSV) on silent OS part 
 
(see chapter “Qualifying Silent OS Part”) 
Check specific requirements to the user 
 
(see chapter “Hardware Specific Part”) 
 
 
 
Caution 
All requirements listed in this document must be checked and fulfilled by the user! 
 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           20 / 80 

Safety Manual MICROSAR OS SafeContext 
OS Configuration 
(OIL or ECUC) 
OS Generator 
Static OS 
Generated OS 
Sources 
Sources 
  
ConfigBlock 
OS Source 
Checksum 
Qualify generated 
Sources 
Application 
(MSSV) 
Sources 
User Review 
Review User 
Software 
Compiling + 
Configuration in 
Linking 
XML 
  
Executable 
Intermediate 
Read Back 
Format 
ConfigBlock 
 
In Human 
Patching the 
Readable 
Configuration Block 
Hex Converter 
ConfigBlock 
Executable 
Hex File 
Verify ConfigBlock 
Flashing 
Read Back 
ECU 
 
Figure 3-1  Strategy for safety configuration 
2015, Vector Informatik GmbH 
Version: 1.05                           21 / 80 

Safety Manual MICROSAR OS SafeContext 

General SafeContext Assumptions 
All  assumptions  must  be  checked  to  be  true.  Assumptions  concerning  the  focus  of 
SafeContext  are  given  by  the  safety  goals  and  related  safety  requirements  described  in 
the safety case. Assumptions about the environment are described in this chapter. 
 
Description of requirements to the OS user 
Fulfilled 
Know the SafeContext concept 
 
The system safety concept must not rely on OS functionality developed according to 
the Silent principle. A complete list of API functions and the guarantees they give is 
provided in chapter “Detailed List of Functionality”. [SPMF92:0075] 
Know your memory configuration  

 
Setup of memory sections must be planned by the system designer. Whether or not 
the planned setup is configured correctly must be verified by reading the configuration 
back from the ECU and reviewing it against system design and hardware manuals. 
Know the OS specifications 
 
The user shall read the OS specifications for OSEK OS and AUTOSAR OS. 
Know how to use the OS 
 
The user shall read the OS manuals: 
>  General Technical Reference Manual 
>  Specific Technical Reference Manual 
Versions are listed in the delivered safety case. 
Correctness of processor  

 
The  processor  provides  its  functionality  with  sufficient  safety,  so  that  the  OS  needs 
not take care about potential hardware failure. This might be assured by usage of a 
lockstep processor. 
Correctness of memory 
 
The memory works with sufficient safety, so that the OS needs not to take care about 
potential hardware failure. 
Correctness of MPU 
 
The  MPU  provides  its  functionality  with  sufficient  safety,  so  that  the  OS  needs  not 
take care about potential hardware failure. 
The  OS  provides  an API  (osCheckMPUAccess)  which  can  be  used  by  the  user  to 
check the MPU. 
Correctness of hardware manuals 
 
The Hardware manuals and the compiler manuals are sufficiently reliable, so that the 
OS  needs  not  take  care  about  potential  deviations  between  hardware  functionality 
and its description in the manuals. 
Versions of the used hardware manuals are listed in the delivered safety case. 
[SPMF92:0017] 
Correctness of compiler tool chain 
 
SafeContext assumes that the compiler, assembler and linker generate code with the 
required safety level. 
Correctness of compiler version and options 
 
2015, Vector Informatik GmbH 
Version: 1.05                           22 / 80 

Safety Manual MICROSAR OS SafeContext 
Description of requirements to the OS user 
Fulfilled 
The  used  compiler  version  and  options  are  identical  to  them  which  are  used  during 
development. 
Used compiler version and options are listed in the delivered safety case. 
Code integrity 

 
The source code and generated configuration of MICROSAR OS SafeContext is 
compiled, linked and downloaded to the ECU correctly and not modified afterwards. 
[SPMF92:0043] 
Context definition 
 
The user shall not rely on registers, which are not part of the context of the OS. 
 The context definition is listed in chapter 4.1 
Hardware handled by the OS shall not be manipulated by user code 
 
User code shall not handle hardware which is handled by the OS. This may include: 
>  Interrupt Controller [SPMF92:0083] 
>  MPU [SPMF92:0085] 
>  Timer 
Don't manipulate short addressing base registers 
 
Do not manipulate registers which are used by the compiler for relative addressing of 
code or data. [SPMF92:0084] 
Table 4-1   General SafeContext Assumptions 
4.1 
Context Definition 
The context which is used by the OS consists of the following registers: 
Register 
Size in Byte 
R1 

R2 

R4 
28 * 4 = 112 
R5 
… 
R30 
R31 
EIPC 

EIPSW 

CTPC 

CTPSW 

MPLA0 

MPUA0 

 
2015, Vector Informatik GmbH 
Version: 1.05                           23 / 80 

Safety Manual MICROSAR OS SafeContext 

OS Source Checksum 
The OS is delivered as source code. To assure that source code files are not altered after 
the testing and release a checksum is calculated. The user shall calculate the checksum to 
verify the correctness of the source code he is using. [SPMF92:0042] 
A checksum calculation program (CCodeSafe.exe) is provided to the user. It is called with 
the following argument: 
  CCodeSafe <config.ini> 
 
This tool calculates a CRC32 checksum over a given list of files given in <config.ini>. 
 
Description of requirements to the OS user 
Fulfilled 
Use the delivered source files from Vector! Do not use changed copies in a productive   
system! Also consider header include order of the compiler. 
The <config.ini> shall contain the OS sources listed in the safety case. 
 
The calculated checksum returned by CCodeSafe is identical to the checksum given   
in the safety case. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           24 / 80 


Safety Manual MICROSAR OS SafeContext 
 
 
Example 
An example for a <config.ini> file: 
 
# src directory: 
<INSTALLATION_DIRECTORY>\BSW\Os\atosappl.c 
<INSTALLATION_DIRECTORY>\BSW\Os\atostime.c 
<INSTALLATION_DIRECTORY>\BSW\Os\osek.c 
<INSTALLATION_DIRECTORY>\BSW\Os\osekasm.c 
<INSTALLATION_DIRECTORY>\BSW\Os\osekalrm.c 
<INSTALLATION_DIRECTORY>\BSW\Os\osekerr.c 
<INSTALLATION_DIRECTORY>\BSW\Os\osekevnt.c 
<INSTALLATION_DIRECTORY>\BSW\Os\osekrsrc.c 
<INSTALLATION_DIRECTORY>\BSW\Os\oseksched.c 
<INSTALLATION_DIRECTORY>\BSW\Os\osekstart.c 
<INSTALLATION_DIRECTORY>\BSW\Os\osektask.c 
<INSTALLATION_DIRECTORY>\BSW\Os\osektime.c 
<INSTALLATION_DIRECTORY>\BSW\Os\osSysCallTable.c 
 
# include directory: 
<INSTALLATION_DIRECTORY>\BSW\Os\Os.h 
<INSTALLATION_DIRECTORY>\BSW\Os\Os_cfg.h 
<INSTALLATION_DIRECTORY>\BSW\Os\osek.h 
<INSTALLATION_DIRECTORY>\BSW\Os\osekasrt.h 
<INSTALLATION_DIRECTORY>\BSW\Os\osekcov.h 
<INSTALLATION_DIRECTORY>\BSW\Os\osekerr.h 
<INSTALLATION_DIRECTORY>\BSW\Os\osekext.h 
<INSTALLATION_DIRECTORY>\BSW\Os\osekasm.h 
<INSTALLATION_DIRECTORY>\BSW\Os\oseksched.h 
<INSTALLATION_DIRECTORY>\BSW\Os\emptymac.h 
<INSTALLATION_DIRECTORY>\BSW\Os\testmac1.h 
<INSTALLATION_DIRECTORY>\BSW\Os\vrm.h 
<INSTALLATION_DIRECTORY>\BSW\Os\osSysCallTable.dld 
 
 
 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           25 / 80 

Safety Manual MICROSAR OS SafeContext 

Patching the Configuration Block 
Configuration  information  which  is  relevant  to  reach  the  safety  goal  is  stored  in  a  data 
structure  called  the  configuration  block.  The  integrity  of  this  information  is  checked  in 
StartOS using a CRC checksum. 
The CRC must be calculated after compiling and linking the application. There are two 
programs provided to calculate and apply the CRC to the binary file: 
 
>  ElfConverter 
For patching the CRC into an ELF file and optionally create an 
intermediate file for reading back the configuration block. 
>  ConfigBlockCRCPatch  For patching the CRC into an Intel Hex or Motorola SREC file. 
 
The following steps are necessary to patch the configuration block: 
 
1.  Compile and link your application 
2.  Run CRC patch software 
3.  Write modified executable into flash memory 
 
 
Description of requirements to the OS user 
Fulfilled 
Check  that  CRC  is  non-zero.  If  so,  change  user  configuration  version  to  avoid  zero   
CRC. [SPMF92:0071] 
 
 
6.1 
Using ElfConverter 
The program ElfConverter.exe is called with the following parameters: 
ElfConverter <ELF File> <ConfigBlock Symbol> --out <Intermediate File> 
 
 
Parameter 
Description 
--out <file>        Dump the configuration block in intermediate format 
--patch_crc        Calculate the configuration block's CRC and write it into the ELF file 
--print_header     Print ELF header 
--print_sections    Print ELF sections 
--print_symbols     Print ELF symbols 
--print_hexdump 
Print a hex dump of the configuration block 
--help 
Show help 
Table 6-1   ElfConverter parameters 
2015, Vector Informatik GmbH 
Version: 1.05                           26 / 80 



Safety Manual MICROSAR OS SafeContext 
 
 
Example 
Patching the configuration block in ELF file testappl.out: 
 
ElfConverter.exe testappl.out _osConfigBlock --out testcfg.hex 
--patch_crc 
 
 
 
 
6.2 
Using ConfigBlockCRCPatch 
The program ConfigBlockCRCPatch.exe is called with the following parameters: 
ConfigBlockCRCPatch <HEX File> <Output file> <ConfigBlock Address> 
 
 
 
Example 
Example (convert ELF file prj.out into prj.hex with modified CRC): 
 
ConfigBlockCRCPatch prj.out prj.hex 0x00800000 
 
 
 
The address of the configuration block may be taken from symbol osConfigBlock in the 
linker generated map file. [SPMF92:0016] 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           27 / 80 

Safety Manual MICROSAR OS SafeContext 

General Configuration Guidelines 
Description of requirements to the OS user 
Fulfilled 
Non-ASIL user code shall be part of Non-Trusted Applications 
 
All non-ASIL user code must be executed by Non-Trusted Applications with no write 
access  to  safety  relevant  data  (including  stacks)  and  no  read  or  write  access  to 
safety relevant peripherals. [SPMF92:02.0034] 
ASIL user code shall not violate the SafeContext safety goal 
 
All user code, which has access to safety relevant data (including stacks, and OS 
data) or peripherals, must be implemented on ASIL level. This code shall never 
violate the safety goals of SafeContext. [SPMF92:0011] 
Code which typically has access to safety relevant data (depending on user 
configuration): 
>  Trusted Functions [SPMF92:0080] [SPMF92:03.0008] 
>  Trusted Tasks 
>  Trusted ISRs 
>  System Hooks 
>  StartupHook [SPMF92:0040] [SPMF92:03.0007] 
>  ErrorHook [SPMF92:0012] [SPMF92:03.0006] 
>  ProtectionHook [SPMF92:0009] [SPMF92:03.0005] 
>  ShutdownHook [SPMF92:0013] [SPMF92:03.0009] 
>  Reset handler / Startup Code [SPMF92:0005] [SPMF92:03.0001] 
>  Exception Handlers [SPMF92:0087] 
>  Category 1 ISRs [SPMF92:0054] [SPMF92:03.0004] 
Alignment of data sections 
 
All data sections shall be linked with MPU alignment granularity (e.g. 32 bytes). See 
the  controller’s  reference  manual  to  know  what  your  MPU  granularity  is. 
[SPMF92:0065] 
Consider category 1 ISRs 
 
Category 1 ISRs are completely transparent to the OS. The OS does not perform 
stack switching for category 1 ISRs! Consider this during configuration of stack 
sizes. [SPMF92:0086] 
NMIs shall be category 1 ISRs 
 
Non-maskable Interrupts (NMI) shall be configured to be category 1 ISRs. 
[SPMF92:0053] [SPMF92:03.0002] 
Link global safety data considering stack growing direction 
 
Link global safety data (all OS data and at least ASIL relevant application data) so 
that it cannot be corrupted by stack overflows (see Figure “Linking example” below 
for an example). [SPMF92:0091] 
 
2015, Vector Informatik GmbH 
Version: 1.05                           28 / 80 


Safety Manual MICROSAR OS SafeContext 
 
Figure 7-1  Linking example 
2015, Vector Informatik GmbH 
Version: 1.05                           29 / 80 

Safety Manual MICROSAR OS SafeContext 

Review General Part of Configuration Block 
The configuration of MICROSAR OS SafeContext is generated into C-code. The generator 
itself  has  not  been  developed  in  accordance  to  ASIL.  Therefore,  the  generated 
configuration  information  needs  to  be  reviewed.  The  safety  relevant  configuration  is 
generated  into  a  structure  called  configuration  block  (or  ConfigBlock).  This  chapter 
describes  how  to  review  this  ConfigBlock. As  the  ConfigBlock  is  simply  a  constant  data 
structure in the flash memory of an ECU, humans will have difficulties to read it. Therefore, 
the configuration viewer is able to transform the ECU internal representation into a human 
readable  format.  The  process  of  reading  the  ConfigBlock  and  transforming  it  into  the 
human readable format is described in the following subchapter. [SPMF92:0038] 
The setup of the memory protecting hardware depends on the correct configuration of the 
OS.  All  configuration  parameters,  which  are  necessary  to  ensure  the  safety  goal,  are 
stored in a contiguous memory block (configuration block). The configuration block can be 
located  to  a  fix  address  and  can  be  read  back  from  the  ECU,  e.g.  by  XCP  or  a  debug 
interface. [SPMF92:0034]  
The configuration block is secured by a 16 bit CRC. The way how the configuration block 
is read back does not need to be safe. The configuration block is translated into a human 
readable format to allow a review against the intended configuration. 
8.1 
How to Read Back the Configuration 
The configuration is read back in two steps: 
1.  Create intermediate ConfigBlock file format, by either using  
>  ElfConverter with parameter –out 
>  Or read back the ECU binary and convert it into the intermediate format (using the 
HexConverter) 
2.  Conversion of the intermediate format into human readable output (using the 
ConfigViewer) 
The  configuration  block  format  is  platform  dependent.  Also  this  information  may  be 
retrieved in different ways, e.g. as the HEX output of the linker or as an upload from the 
ECU via a protocol like XCP. As this may result in various file formats a conversion into an 
intermediate format is required. 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           30 / 80 

Safety Manual MICROSAR OS SafeContext 
 
8.1.1  Using HexConverter 
The program HexConverter.exe is called with the following parameters: 
HexConverter –i <Input File> -o <Output File> -b <Base Address>  
-s <ConfigBlock Size> 
 
All parameters are mandatory. 
Parameter  Value 
Description 
-i 
Input File Path & Name 
File containing the HEX data produced by the linker 
-o 
Output File Path & Name 
File with intermediate format generated by 
HexConverter 
-b 
Base Address 
Base address of the configuration block as defined in 
the linker map file. 
It is the address of the symbol ‘osConfigBlock’. 
Value has to be given as HEX (e.g. 0x8001f000). 
-s 
0xFFFF 
This value must be at least the size of the configuration 
block in byte. Bigger values are also allowed. 
E.g. this value can be set to 0xFFFF 
Table 8-1   HexConverter parameters 
 
8.1.2  Using ConfigViewer 
The program ConfigViewer.exe is called with the following parameters: 
ConfigViewer –i <Input File> -o <Output File> -c <XML File> 
 
Parameter  Value 
Description 
-i 
Input File Path & Name 
File containing the intermediate data produced by the 
HexConverter  
-o 
Output File Path & Name 
File with human readable configuration  description 
generated by ConfigViewer 
-c 
XML-ConfigFile 
XML file, generated by the OS generator describing the 
OS configuration 
Table 8-2   ConfigViewer parameters 
The configuration viewer expects the intermediate format to contain nothing else than the  
configuration block. 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           31 / 80 

Safety Manual MICROSAR OS SafeContext 
8.2 
General Configuration Information 
The  following  subchapters  concentrate  on  the  output  of  the  configuration  viewer  and  on 
the  rules  to  review  it.  The  configuration  viewer  and  the  format  converters  are  described 
separately. 
To minimize  variants  in  code,  the  OS  generator  introduces dummies for  each  OS  object 
type. These dummies can be identified by the prefix “osSystem” and are handled the same 
way like other OS objects. None of these objects is active at runtime. 
Description of requirements to the OS user 
Fulfilled 
Check that the listed configuration block address and length is correct and matches   
the map file. 
Check that the listed configuration block format is 2.00 
 
Check  that  the  listed  version  of  MICROSAR  OS  SafeContext  matches  your   
delivered version. 
If  you  are  using  the  user  configuration  version,  check  that  the  listed  one  matches   
your configured value. 
Check  that the  listed  number  of  OS  objects matches  your  configuration.  (Consider   
that dummy OS objects are generated, to minimize variants in the OS code.) 
Check  number  of  listed  OS  objects  matches  the  elements  in  the  sub  containers.   
[SPMF92:0074] 
Check that the listed specific stack start and end addresses match your 
 
configuration. (The stack end addresses in the configuration block point to the first 
address outside the stack.) 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           32 / 80 

Safety Manual MICROSAR OS SafeContext 

Review Generated Code 
MICROSAR OS is a massively configurable software component. As a result, the analysis 
of the OS modules cannot be completely performed until the user’s configuration data is 
available.  The  user  shall  use  MICROSAR  Safe  Silence  Verifier  (MSSV)  to  qualify  the 
generated part of the OS, which depends on user’s configuration.  MSSV is a Vector tool, 
which performs checks of potential dangerous code constructs. [SPMF92:0049] For more 
information about MSSV see the Technical Reference Manual of MSSV6. 
Description of requirements to the OS user 
Fulfilled 
The user must not modify a generated module configuration code file manually 
 
unless explicitly required by the technical reference manual or explicitly direction 
formulated by Vector. 
All generated files of a software project shall be generated based on the same 
 
configuration. Generated files of several configurations must not be mixed up unless 
explicitly allowed by Vector. 
The user shall apply steps for qualifying the generated sources on the final 
 
configuration which is used for the production. If the configuration changes, source 
qualification steps shall be reapplied. 
 
9.1 
Manual Reviews 
Some generated code parts currently cannot be checked automatically. Therefore the user 
has to check them manually. 
 
9.1.1  Review generated file tcb.h 
Description of requirements to the OS user 
Fulfilled 
If interrupt level support is supported in your delivery, you shall review the system 
 
level (osdSystemLevel) to be the maximum of all category 2 ISR priorities and 
osdSystemLevelMask to be the corresponding value, which has to be stored in 
PMR register to mask (disable) all category 2 interrupts.  [SPMF92:02.0019] 
[SPMF92:04.0017]  [SPMF92:02.0033] 
#define osdSystemLevel <MAXIMUM_OF_ALL_CAT2_ISR_PRIORITIES> 
#define osdSystemLevelMask <PMR_VALUE_MASK_ALL_CAT2_ISR> 
 
Check that osdExceptionDetails is defined = 1  
 
#define osdExceptionDetails 1 
 
 
                                            
6 TechnicalReference_MSSV.pdf, v1.3 
2015, Vector Informatik GmbH 
Version: 1.05                           33 / 80 

Safety Manual MICROSAR OS SafeContext 
10  Qualifying Silent OS Part 
MICROSAR OS is a massively configurable software component. As a result, the analysis 
of the OS modules cannot be completely performed until the user’s configuration data is 
available.  The  user  shall  use  MICROSAR  Safe  Silence  Verifier  (MSSV)  to  qualify  the 
generated part of the OS, which dependent on user’s configuration. MSSV is a Vector tool, 
which performs checks of potential dangerous code constructs inside BSW modules which 
depend on user configuration data. [SPMF92:0049] For more information about MSSV see 
the Technical Reference Manual of MSSV7. [SPMF92:0088] 
 
10.1  Using MICROSAR Safe Silence Verifier (MSSV) 
The following chapter tells how you shall apply MSSV on the OS sources.  
MSSV is called with the following parameters: 
MSSV.exe --inputDir <PATH_TO_TCB> --inputDir <PATH_TO_OS_INCLUDE>  
--reportFile <REPORT.html>  --define osdNOASM 
 
Parameter 
Description 
<PATH_TO_TCB> 
Path to generated OS files (typically contained in the tcb folder). 
<PATH_TO_OS_INCLUDE>  Path to OS header files (typically contained in the implementation 
folder). 
<REPORT.html> 
File name which shall be used to save the MSSV report. 
--define osdNOASM 
Disable assembler parts. 
 
Description of requirements to the OS user 
Fulfilled 
The MICROSAR Safe Silence Verifier shall only be executed on Windows XP SP3+   
(32Bit) or Windows 7 (32Bit or 64Bit). 
The user must not modify the MICROSAR Safe Silence Verifier report. 
 
The user shall verify that the used OS sources are checked by verifying the names 
 
and paths of the modules within the report. 
The user shall verify that the evaluated report matches to the execution of the 
 
MICROSAR Safe Silence Verifier by verifying the name, creation date and time, 
path and folder of the report. 
Check that MSSV returns with no errors, no warnings and the final verdict of the 
 
report is “pass”. If MSSV did not pass contact OS support. [SPMF92:0088] 
 
                                            
7 TechnicalReference_MSSV.pdf, v1.3 
2015, Vector Informatik GmbH 
Version: 1.05                           34 / 80 


Safety Manual MICROSAR OS SafeContext 
 
 
Example 
An example for qualifying generated OS sources: 
 
MSSV.exe -i "tcb" -i"..\..\include" --define osdNOASM 
The output of MSSV should look like: 
note: MICROSAR Safe Silence Verifier Version 1.01.02 
note: Copyright (C) 2012-2013 Vector Informatik GmbH 
note: License <CBD0900253> VDO AUTOMOTIVE AG 
 
note: MSSV.exe started at 09:39:55 2014-02-19 
… 
note: MSSV.exe finished at 09:39:57 2014-02-19 
note: 0 Errors 
note: 0 Warnings 
note: the final verdict of the report is 'pass' 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           35 / 80 

Safety Manual MICROSAR OS SafeContext 
11  Review User Software 
Some  code  parts  run  in  supervisor  mode  without  any  memory  protection  active  or  with 
high memory access granted. Therefore, freedom from interference is not  guaranteed by 
the OS and the hardware. Trusted software has to guarantee freedom from interference on 
its  own.  The  application  programmer  typically  knows  best,  what  is  to  do  in  order  to 
guarantee  freedom  from  interference.  Anyhow,  there  are  few  additional  points  to  be 
covered when an OS is used. 
The  following  requirements  shall  generally  be  fulfilled  by  trusted  software  (also  valid  for 
software which runs in supervisor mode or with access to safety relevant memory areas): 
Description of requirements to the OS user 
Fulfilled 
OS code coverage shall be disabled 
 
Check  that  osdEnableCoverage  is  not  defined  when  you  compile  the  OS. 
[SPMF92:0077] 
FPU usage shall be disabled 
 
Check that osdRH850_FPU is not defined via compiler option –DosdRH850_FPU 
Check that osdRH850_FPU is only defined in file osekext.h 
Unhandled exception details shall be enabled 
 
Check that osdExceptionDetails is defined = 1 (see tcb.h) 
Check that OS attribute EnumeratedUnhandledISRs is set TRUE 
No usage of system call instructions in the user software 
 
Any system call causes the CPU to change into supervisor mode. Therefore, the 
application (trusted and non-trusted parts) shall not use system calls directly. 
Instead, system calls shall only be used by using OS APIs. 
User header usrostyp.h 
 
If trusted functions are configured, ensure that usrostyp.h does not endanger 
SafeContext safety requirements. 
Enabling interrupts where it is not allowed 
 
Interrupts  shall  not  be  enabled  by  the  application  where  Category  2  ISRs  are 
disabled by default (e.g. in Hooks). This applies not to ISRs. In ISRs it is allowed to 
enable interrupts. [SPMF92:0066] 
Use only documented APIs 
 
Trusted  software  shall  only  call  documented  API  functions,  which  are  listed  in 
chapter “Detailed List of Functionality”. [SPMF92:0068] 
Stack usage measurement is not exact 
 
Stack  usage  measurement  is  implemented  by  counting  magic  patterns 
(osdStackCheckPattern)  on  the  stack  which  have  been  written  there  during 
startup. The returned value may not be correct, if the magic pattern did not change 
(e.g. the user application uses the same value). [SPMF92:0072] 
Usage of osCheckMPUAccess API 
 
If  you  are  using  the  osCheckMPUAccess API,  the  destination  address  parameter 
shall  point  to  an  address,  where  reading  and  writing  does  not  produce  other 
exceptions than MPU exceptions. 
2015, Vector Informatik GmbH 
Version: 1.05                           36 / 80 

Safety Manual MICROSAR OS SafeContext 
Description of requirements to the OS user 
Fulfilled 
Usage of osCheckMPUAccess API 
 
If  you  are using the  osCheckMPUAccess API,  Check  that the API function  is  only 
called  with  addresses  which,  reading  and  writing  does  not  have  any  side  effects 
(e.g. potentially not true for peripheral registers). [SPMF92:02.0017]. 
If you have write access to stacks, stack overflows cannot be detected by hardware  
 
The OS cannot safely detect stack overflows in software which has write access to 
all stacks. If write access to all stacks is really needed (e.g. for RAM checking), the 
user  has  to  ensure  that  the  software  does  not  produce  a  stack  overflow! 
[SPMF92:0078] 
APIs in exception handlers 
 
Exception handlers must not call any OS API function beside: 
>  DisableAllInterrupts 
>  EnableAllInterrupts 
>  SuspendAllInterrupts 
>  ResumeAllInterrupts 
>  SuspendOSInterrupts 
>  ResumeOSInterrupts 
[SPMF92:0067] 
Category 1 ISRs shall be transparent 

 
All  ISRs  of  category  1  must  be  implemented  such  that  they  are  transparent  with 
respect  to  the  processor  state  for  the  code  they  interrupt.  This  includes  core 
registers, MPU settings and the current interrupt priority. 
APIs in category 1 ISRs 

 
Category 1 ISRs shall not call any OS API function beside: 
>  DisableAllInterrupts 
>  EnableAllInterrupts 
>  SuspendAllInterrupts 
>  ResumeAllInterrupts 
 [SPMF92:0067] [SPMF92:02.0018] 
Check out-parameters in Trusted Functions 

 
Trusted functions which get a pointer shall check the pointer address to be in an 
expected range before they write to the pointer address. This shall prevent 
overwriting of safety relevant data when writing to the pointer address. 
[SPMF92:0001] 
Check caller in Trusted Functions 

 
Trusted functions shall validate whether they are called by an authorized caller only. 
This may be done by using the API function GetApplicationID. 
[SPMF92:0047] 
No (Non-)Trusted Functions in Hooks 

 
Hook routines shall not call any trusted function or non-trusted function. 
No APIs in NMIs 

 
Non-maskable interrupts shall not use any OS APIs.  
2015, Vector Informatik GmbH 
Version: 1.05                           37 / 80 

Safety Manual MICROSAR OS SafeContext 
Description of requirements to the OS user 
Fulfilled 
[SPMF92:0019], [SPMF92:0067] 
Using Interrupt API before calling StartOS 
 
If the user needs to use the interrupt API before he calls StartOS, he shall call 
osInitialize and osInitINTC.  
After calling these functions interrupt API works only for the straight forward case. 
OS error handling and MPU won’t be initialized, so the OS won’t be able to handle 
any user errors or detect stack overflows. 
2015, Vector Informatik GmbH 
Version: 1.05                           38 / 80 

Safety Manual MICROSAR OS SafeContext 
12  Hardware Specific Part 
For RH850 SafeContext the following safety relevant requirements must be checked by the user: 
 
  All assembly code (outside the SafeContext) shall be reviewed, not to change the content 
of registers of R4 and R5 after StartOS is called  [SPMF92:04.0001]. Check in list files that 
only the startup module and the OS modules do modify registers R4 and R5. 
  The user has to review that each ISR is called at least once (coverage of application). The 
tests shall cover the activation of all ISRs and verify that the correct ISR was started. This 
measure  shall  prevent  the  activation  of  wrong  ISRs  because  of  a  mix  up  in  the  interrupt 
vector table [SPMF92:0008]. 
  The user has to review the configuration by means of the ConfigBlock in accordance  to the 
review rules which are defined in chapter 12.2 [SPMF92:0014],[SPMF92:05.0008]. 
  The  user  has to  review  that  all  libraries fit to the  used  compiler  options. All  used  libraries 
need  to  be  checked  for  using  the  correct  compiler  options  (e.g.  SDA  usage  need  to  be 
identical to the specified options for the OS) [SPMF92:0010]. 
  The  PreTaskHook  and  the  PostTaskHook  must  not  be  used  in  safety  code  which  is 
released for serial production. Pre/PostTaskHook shall only be used for debugging or test 
purposes.  Absence  of  Pre/PostTaskHook  must  be  reviewed  in  generated  file  tcb.h: 
[SPMF92:02.0022],[SPMF92:02.0023],[SPMF92:05.0011] 
The user must check that the following defines are set in the generated file tcb.h: 
#define osdPreTaskHook 0 
#define osdPostTaskHook 0 

  The  complete  config  block  content  must  be  reviewed  by  the  means  of  the  BackReader 
[SPMF92:04.0002], [SPMF92:04.0006]. 
  The address value of the application specific linker symbols for MPU region start and end 
address  must  be  checked  that  between  them  only  the  corresponding  application  data 
sections are mapped [SPMF92:04.0004], [SPMF92:04.0010], [SPMF92:04.0011]. 
  The  address  value  of  the  linker  symbols  _osGlobalShared_StartAddr  and 
_osGlobalShared_EndAddr  must  be  checked  that  between  them  only  the  global  shared  
data sections are mapped [SPMF92:04.0013]. 
  The CPU must run in supervisor mode when StartOS is called [SPMF92:04.0007]. 
  The  application  shall  check  the  config  block  version  by  using  OS  API  function 
osGetConfigBlockVersion [SPMF92:0045],[SPMF92:05.0010]. 
  The user has to review that all task stacks, all ISR stacks and the system stack have 4 Byte 
alignment [SPMF92:04.0008]. 
  The user has to review the generated linker include files osdata.dld, osrom.dld, ossdata.dld 
osstacks.dld and ostdata.dld if they are used for serial production [SPMF92:04.0014]. See 
chapter 12.4. 
2015, Vector Informatik GmbH 
Version: 1.05                           39 / 80 

Safety Manual MICROSAR OS SafeContext 
  The user has to review that coverage is disabled [SPMF92:04.0015]. osdEnableCoverage 
shall  not  be  defined  in  header  and  source  files  and  it  shall  not  be  defined  via  compiler 
option –DosdEnableCoverage. 
  The  user  has  to  consider  DMA  controller  usage.  The  RH850  P1M  series  incorporates  a 
DMA controller (DMAC). The DMA controller has direct access to the data bus. Therefore 
DMA access to memory is not  controlled  by  MPU  protection.  This  must  be  considered  
especially  for  safety  OS systems if any DMA access is wanted. [SPMF92:01.0002] 
  The user has to review that osInitialize and osInitINTC are called before StartOS is called if 
OS interrupt API functions or OS peripheral interrupt API functions are used before StartOS 
[SPMF92:0058], [SPMF92:0070]. 
  Interrupt priority level ceiling is not supported by MICROSAR OS RH850 SafeContext. The 
user  has  to  check  that  before  StartOS  is  called  the  interrupt  priority  mask  register  PMR 
must  have  the  value  0x00000000  and  it  shall  not  be  changed  after  StartOS. 
[SPMF92:0059],[SPMF92:0060]. This is not checked by RH850 SafeContext. 
  The  user  has  to  review  that  all  generated  files  belong  together  [SPMF92:0064].  Each 
generated header and source file must start with the following comment block: 
/* file: <file_path><file_name> */ 
/* automatically generated by genRH850SCTX.exe, Version: 6.11 */ 
/* from: <configuration_file_name> */ 
/* Generation time: <date> <time> <year> */ 
/* <license_and_licensee_information> */ 
/* Implementation: RenesasRH850_P1M */ 
/* Version of general code: 6.16 */ 
/* Dcf-file semantic version: 2.00 */ 
/* Dcf-file content version: 2.01 */ 
 

  The user has to review that all generated files are compiled and linked [SPMF92:0064]: 
-  intvect.c 
-  osConfigBlock.c 
-  osStacks.c 
-  tcb.c 
-  trustfct.c 
  The  user  has  to  check  that  the  application  does  not  modify  interrupt  controller  registers 
EBASE, INTBP, INTCFG, SCBP and SCCFG after StartOS is called [SPMF92:0069]. 
  The  application  shall  not  modify  any  register  in  interrupt  controller  unit  INTC  by  own 
functions  or  routines  after  StartOS  is  called.  The  application  shall  only  use  the  OS  API 
functions for changing registers in unit INTC. [SPMF92:0083] 
  The  user  has  to  check  validity  and  type  of  the  reference  parameter  when  calling  the 
following OS API functions [SPMF92:05.0001]: 
-  GetTaskID 
-  GetTaskState 
-  GetEvent 
-  GetAlarm 
-  GetScheduleTableStatus 
-  GetCounterValue 
-  GetElapsedValue/GetElapsedCounterValue 
2015, Vector Informatik GmbH 
Version: 1.05                           40 / 80 

Safety Manual MICROSAR OS SafeContext 
  The  user  has  to  review  that  the  size  of  array  oskAlarmHeaps  is  same  as  
osdNumberOfCounters 
and 
that 
each 
entry 
of 
the 
array 
looks 
like   
[SPMF92:05.0002],[SPMF92:05.0004]: 
  { 
    os<CounterName>Heap, 
    &osAlarmHeapCount[<CounterName>] 
  }, 

  The user has to review that the values of the counter defines are an adjoining set from zero 
to osdNumberOfCounters-1 in the generated file tcbpost.h [SPMF92:05.0003]: 
example 
tcb.h: 
#define osdNumberOfCounters 8 
tcbpost.h: 
#define <CounterName0> ((CounterType) 0) 
#define <CounterName1> ((CounterType) 1) 
#define <CounterName2> ((CounterType) 2) 
... 
#define <CounterName7> ((CounterType) 7) 
 
  The user has to review that the size of the heap arrays  os<CounterName>Heap[ ]  must be 
equal to 1 plus the number of alarms that are related to the counter <CounterName> plus 
the  number  of  schedule  tables  that  are  related  to  the  counter  <CounterName>. 
[SPMF92:05.0005] 
  The  user  has  to  review  that  the  first  parameter  of  all  calls  of  osSysSetEvent  in  tcb.c  is  a 
task identifier which must be defined in tcbpost.h and that the value of the define is smaller 
than osdNumberOfExtendedTasks. [SPMF92:05.0006] 
  The  user  has  to  review  that  all  calls  of  osWorkHeap  in  Timer  ISR  look  like  followed: 
[SPMF92:05.0007] 
osWorkHeap(&oskAlarmHeaps[<CounterDefineName>], <CounterDefineName>); 
  The user has to review  that the parameter of each call of osSysActivateTask in tcb.c is a 
task identifier which must be defined in tcbpost.h [SPMF92:05.0009].  
  The user has to review  that the values of the task defines are adjoining set from zero to 
osdNumberOfAllTasks-1 in the generated file tcbpost.h [SPMF92:05.0010].  
  The  user  has  to  review  that  the  size  of  the  task  activation  arrays 
osQTaskActivation_<index> which are listed in oskQActivationQueues is the same value as  
oskQMaxActivations+1 [SPMF92:05.0012]. 
  The user has to review that the values of the Alarm defines are adjoining set from zero to 
osdNumberOfAlarms-1 in the generated file tcbpost.h [SPMF92:05.0013]. 
  The  user  has  to  review  that  the  array  oskAlarmCounterRef[]  contains  exactly 
osdNumberOfAlarms  elements  and  that  each  element  contains  the  index  of  the  counter 
related to that alarm [SPMF92:05.0014]. 
  The  user  has  to  review  that  the  PMR  register  is  not  manipulated  by  his  code 
[SPMF92:04.0018].  
2015, Vector Informatik GmbH 
Version: 1.05                           41 / 80 

Safety Manual MICROSAR OS SafeContext 
12.1  Interrupt Vector Table 
Basically the interrupt vector tables must be provided by the application. An example vector table is 
generated into file intvect.c. This file is generated by QM software and must not be used directly as 
ASIL code. It must be reviewed carefully for compliance to the description below because the code 
which  is  called  by  the  interrupt  vector  table  runs  automatically  in  supervisor  mode  and  therefore 
this  code  must  be  developed  according  to  ASIL  level  [SPMF92:0004],  [SPMF92:02.0020], 
[SPMF92:02.0021], [SPMF92:04.0012]. 
The file intvect.c consists of the following parts: 
  Header Include Section 
  Core Exception Vector Table 
  EIINT Vector Table 
  CAT2 ISR Wrappers 
The following subchapters describe these parts and do intentionally not describe any comments. 
12.1.1 Header Include Section 
This part of the code must be exactly like: 
#if defined USE_QUOTE_INCLUDES 
 #include "vrm.h" 
#else 
 #include <vrm.h> 
#endif 
#define osdVrmGenMajRelNum 6 
#define osdVrmGenMinRelNum 11 
#if defined USE_QUOTE_INCLUDES 
 #include "vrm.h" 
#else 
 #include <vrm.h> 
#endif 
 
#if defined USE_QUOTE_INCLUDES 
#include "Os.h" 
#else 
#include <Os.h> 
#endif 
 
#if defined USE_QUOTE_INCLUDES 
#include "osekext.h" 
#else 
#include <osekext.h> 
#endif 
 
2015, Vector Informatik GmbH 
Version: 1.05                           42 / 80 

Safety Manual MICROSAR OS SafeContext 
12.1.2 Core Exception Vector Table 
The core exception vector table section starts exactly with the following lines: 
#pragma asm 
.align 512 
.section ”.osExceptionVectortable”, ax 
.globl _osExceptionVectorTable 

_osExceptionVectorTable: 
 
That part is followed by 32 vector table entries: 
.offset  <offset_addr> 
.globl   _osCoreException_<offset_addr> 

_osCoreException_<offset_addr>: 
 

jr   
 <handler_function> 
 
<offset_addr> is the hexadecimal address offset for each exception interrupt vector.  
The valid range is 0x0000, 0x0010, 0x0020 ... 0x01F0 
 
<handler_function> is the name of the function which is called when an exception occurs.  
If no handler function is configured then osUnhandledCoreException is called. 
The sequence of vector table entries starts at vector address 0x0000, increases in steps of 0x0010 
and ends with vector address 0x01F0. 
 
The core exception vector table section ends exactly  with the following lines: 
.globl _osExceptionVectorTableEnd 
_osExceptionVectorTableEnd: 
#pragma endasm 
 
2015, Vector Informatik GmbH 
Version: 1.05                           43 / 80 

Safety Manual MICROSAR OS SafeContext 
12.1.3 EIINT Vector Table 
The EIINT vector table section starts exactly with the following lines: 
#pragma asm 
.align 512 
.section ”.osEIINTVectortable”, ax 
.globl _osEIINTVectorTable 
_osEIINTVectorTable: 
 
For each unused interrupt source the following table entry must be generated: 
.word 
 _osUnhandledEIINT_<index> 
<index> is the channel index of the corresponding interrupt source. The valid range is 0 ... 383. 
 
For each interrupt source used as category 1 ISR the following table entry must be generated: 
.word 
 _<cat1_EIINT_handler> 
<cat1_EIINT_handler> is the name of the application specific EIINT handler which is called when 
an interrupt on the corresponding source occurs. 
 
For each interrupt source used as category 2 ISR the following table entry must be generated: 
.word 
 _<cat2_EIINT_handler>_CAT2 
<cat2_EIINT_handler> is the name of the OS ISR wrapper which is called when an interrupt on the 
corresponding source occurs. The CAT2 ISR wrapper section is described in the next chapter. 
 
The EIINT vector table section ends exactly with the following lines: 
.globl _osExceptionVectorTableEnd 
_osExceptionVectorTableEnd: 
#pragma endasm 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           44 / 80 

Safety Manual MICROSAR OS SafeContext 
12.1.4 CAT2 ISR Wrappers 
The category 2 ISR wrapper section starts exactly with the following line: 
#pragma ghs section text=".os_text" 
 
Each category 2 ISR handler must be generated exactly like the following line [SPMF92:0044]: 
osCAT2ISR(<ISR_Function_Name>, <ISR_Priority_Level>) 
This macro is defined in osek.h. It defines the CAT2 ISR prologue for each interrupt priority level. 
<ISR_Function_Name> is the unique name of the ISR function. This must be the same name as 
used in the EIINT vector table at the corresponding channel index position with postfix _CAT2. 
<ISR_Priority_Level>  is  the  value  of  the  interrupt  priority  level  which  is  configured  for  the 
corresponding ISR. The valid range of <ISR_Priority_Level> is 0 ... 15 
 
The category 2 ISR wrapper section ends exactly with the following line: 
#pragma ghs section text=default 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           45 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2  Configuration Block 
This chapter defines the rules to review and interpret the entries of the configuration block.  
The configuration of MICROSAR OS RH850 SafeContext is generated into C-Code. The generator 
itself  has  not  been  developed  in  accordance  to  safety  requirements.  Therefore,  the  generated 
configuration information needs to be reviewed. The safety relevant configuration is generated into 
a  structure  called  ConfigBlock.  This  chapter  describes  how  to  review  the  ConfigBlock.  As  the 
ConfigBlock is simply a constant structure in the memory of an ECU, users will have difficulties to 
read it. Therefore, the configuration viewer is able to transform the ECU internal representation into 
a user readable format. The process of reading the ConfigBlock and transforming it into the user 
readable format is described in the following subchapter. 
 
12.2.1 How to read back the ConfigBlock 
The  ConfigBlock  is  internal  information  of  a  program  to  control  an  ECU.  It  might  be  available  in 
different formats. Therefore it is difficult to provide one single configuration viewer program to read 
the information and transform it into a human readable format. 
So the configuration viewer is a console application which reads configuration information from a 
proprietary intermediate file and writes it into a text file. Different reader programs are available to 
transform  the  ConfigBlock  from  standard  formats  into  the  intermediate  format.  In  addition,  the 
intermediate  format  is  quite  simple,  so  it  may  also  be  produced  by  manual  adaptation  of  a 
debugger output (hex dump) with any text editor. 
The  configuration  viewer  expects  the  intermediate  format  to  contain  nothing  else  than  the 
ConfigBlock. Therefore, the transformation programs need the information, where the ConfigBlock 
is located. That information is passed to the transformation program by means of the parameter ‘–
b’. 
The  address  of  the  ConfigBlock is  easily  taken  out  of the  linker  map file.  It  is the  address  of the 
constant osConfigBlock [SPMF92:0016]. 
The following subchapters concentrate on the output of the configuration viewer and on the rules to 
review it. The configuration viewer and the format converters are described separately. 
2015, Vector Informatik GmbH 
Version: 1.05                           46 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.2 Additional Information 
The  operating  system  and  therefore  also  the  ConfigBlock  typically  use  indexes  instead  of  the 
names of tasks, ISRs, applications and so on. Each index value is related to exactly one object in 
the  configuration  of  the  OS.  However,  the  relation  to  the  configured  object  is  typically  not  so 
obvious. 
Therefore,  the  configuration  viewer  provides  the  possibility  to  add  the  names  of  configuration 
objects to its output. That information is taken from the so called XML config-file. The OS-generator 
produces this file together with the source files it generates. 
The  configuration  viewer  outputs  the  object  names  in  case  a  parameter  is  set  to  use  the 
information from the XML config-file. All information taken from the XML config-file is represented 
between ‘(‘ and ‘)’ to mark it as unsafe additional information. 
The reviewer of the ConfigBlock has the possibility to make use of the information taken from the 
XML  config-file  or  to  skip  that  information  completely.  The  review  rules  in  the  chapters  below 
describe for both cases how the review shall be performed. The examples of configuration viewer 
output below always contain the information from XML config-file. 
Although the information taken from the XML config-file (information in parentheses) is unsafe, the 
relation  between  index  and  name  of  an  object  is  guaranteed  to  be  fix.  This  means,  once  the 
configuration  viewer  has  read  in  the  object  names  from  the  XML  config-file,  it  always  translates 
each certain index to the exact same object name. So the relation between object index and object 
name  needs  to  be  reviewed  only  once  and  can  be  seen  as  reliable  everywhere  else  in  the 
configuration viewer output. 
The review rules below already contain rules to validate the information taken from XML config-file, 
so that information can safely be used although it is taken from an unsafe source. 
 
2015, Vector Informatik GmbH 
Version: 1.05                           47 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.3 How to start the review 
The configuration viewer starts the output with something like [SPMF92:0063]: 
OS Configuration Viewer V3.00 (General) V1.02 (HW Specific) (Apr 24 2014 15:42:59) 
(c) 2013 Vector Informatik GmbH 
 
Started at:Tue May 13 16:23:24 2014 
 
Remark: Text between '(' and ')' shall be treated as unsafe additional information
 
 
=================================================== 
Start of Config Block                   0x00002000   
Length                                  588          
CRC                                     0x9622       
Config Block Format Version             02.00        
MICROSAR OS RH850  SafeContext Version  06.05        
User Config Version                     2         
=================================================== 
 
The user should start with some consistency checks like: 
  Is the date (Started at) equal to the date/time when the configuration viewer was started 
  Do the start address (Start of configuration block), length (Length) and CRC fit to the 
configuration block which shall be reviewed 
  Check  that  the  listed  version  of  MICROSAR  OS  RH850 SafeContext  matches  your 
delivered version. 
  Review that the user config version represents the number which was configured by means 
of the configuration attribute UserConfigurationVersion [SPMF92:0045]. 
  Is the output complete (see below)? 
 
The output is complete when it ends on: 
======================================================= 
          End of configuration block reached            
======================================================= 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           48 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.3.1 Indexes of applications, task , ISRs, trusted and non-trusted functions 
 
Check indexes of listed applications: 
The indexes must begin with 0 
The indexes must be consecutive. Gaps are not allowed 
The indexes must end at <Number of applications>-1 
 
Check indexes of listed tasks: 
The indexes must begin with 0 
The indexes must be consecutive. Gaps are not allowed 
The indexes must end at <Number of tasks>-1 
 
Check indexes of listed category 2 ISRs: 
The indexes must begin with 0 
The indexes must be consecutive. Gaps are not allowed 
The indexes must end at <Number of category 2 ISRs> - 1 
 
Check indexes of listed trusted functions: 
The indexes must begin with 0 
The indexes must be consecutive. Gaps are not allowed 
The indexes must end at <Number of trusted functions> - 1 
 
Check indexes of listed non-trusted functions: 
The indexes must begin with 0 
The indexes must be consecutive. Gaps are not allowed 
The indexes must end at <Number of non-trusted functions> - 1 
 
Note: The table items in the configuration viewer output may not be sorted by index. 
 
 
12.2.3.2 Review against User’s Design 
The  chapters  below  describe,  how  the  configuration  viewer  output  can  be  reviewed  against  the 
OS-configuration. However, the review shall be performed against the user’s design of the system.  
The reason is that OS developers can only describe, where the respective information can be 
found in the configuration but have only limited knowledge about the system design. 
2015, Vector Informatik GmbH 
Version: 1.05                           49 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.4 How to review the general information (block 0) 
The configuration viewer generates the general information as followed [SPMF92:0063]: 
0. General Information 
------------------------------------------------------ 
Property                         Value       Checked?  
------------------------------------------------------ 
Number of Tasks                  4             [  ]    
Number of Cat2 ISRs              3             [  ]    
Number of All ISRs               4             [  ]    
Number of Trusted Functions      1             [  ]    
Number of Non-Trusted Functions  0             [  ]    
Number of Applications           3             [  ]    
Number of Peripheral Regions     0             [  ]    
Stack Usage Measurement          Yes           [  ]    
Number of MPU Regions            12            [  ]    
Number of Dynamic MPU Regions    2             [  ]    
Number of Static MPU Regions     4             [  ]    
Number of Available Cores        1             [  ]    
System Stack Start-Address       0xfedf04b0    [  ]    
System Stack End-Address         0xfedf0640    [  ]    
------------------------------------------------------ 
 
The review shall be performed like this: 
  Count the number of configured tasks and compare it against the number of tasks 
presented by the configuration viewer in the part about general information 
  Check the number of Cat2 ISRs: 
o  Count the number of configured ISRs with CATEGORY = 2 and compare it against 
the number of Cat2 ISRs presented by the configuration viewer in the part about 
general information. 
o  Consider that the OS internally uses a further Cat2 ISR for alarm and schedule table 
handling. That ISR is only available in case at least one alarm or a schedule table 
has been configured that uses the system timer. 
  Check the number of all ISRs: 
o  Count the number of configured EIINT ISRs with CATEGORY = 1 and 2 and 
compare it against the number of all ISRs presented by the configuration viewer in 
the part about general information. 
  Count the number of configured trusted functions and compare it against the number of 
trusted functions presented by the configuration viewer in the part about general 
information. Trusted function configurations may be found in the configuration of any OS-
applications with TRUSTED = TRUE. 
  Count the number of configured non-trusted functions and compare it against the number of 
non-trusted functions presented by the configuration viewer in the part about general 
information. Non-trusted function configurations may be found in the configuration of any 
OS-applications with TRUSTED = FALSE. 
  Count the number of configured OS-applications and compare it against the number of OS-
applications presented by the configuration viewer in the chapter about general information. 
  Count the number of peripheral regions configured over all non-trusted applications and 
compare it against the number of peripheral regions presented by the configuration viewer. 
  Compare the configuration of stack usage measurement against the respective output of 
the configuration viewer in the chapter about general information. The configuration of stack 
usage measurement is found in the general configuration of the OS. 
2015, Vector Informatik GmbH 
Version: 1.05                           50 / 80 

Safety Manual MICROSAR OS SafeContext 
  Check the number of MPU regions which are provided by the used CPU derivative. 
  Check the number of dynamic MPU regions which must be same as the number of MPU 
regions configured in the application with most dynamic MPU regions. 
  Check the number of static MPU regions configured for the OS. 
  Check the number of CPU cores which are provided by the used CPU derivative. 
  Review of system stack addresses  [SPMF92:0056],[SPMF92:04.0003]: 
o  Compare the system stack start address in the configuration viewer output against 
the label  _osSystemStack_StartAddr in the linker map-file.  
o  Compare the system stack end address in the configuration viewer output against 
the label _osSystemStack_EndAddr in the linker map-file. 
o  Check that both labels are 4 Byte aligned [SPMF92:04.0002]. This prevents that any 
data of other sections is accessible by the same MPU region. 
o  Check that only the array variable osSystemStack is located between the labels 
described above.  
o  Check the difference between the system stack start- and end-address against the 
designed (and therefore also configured) system stack size. 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           51 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.5 How to review the task start addresses (block 1) 
The configuration viewer generates the task start addresses as followed [SPMF92:0063]: 
1. Task start addresses: 
------------------------------------------------------ 
Task-ID  Task-Name               Value       Checked?   
------------------------------------------------------ 
0        (eTask1)                0x000030cc    [  ]     
1        (osSystemExtendedTask)  0x000059a2    [  ]     
2        (bTask1)                0x00003052    [  ]     
3        (osSystemBasicTask)     0x000059a0    [  ]     
------------------------------------------------------ 
 

The review shall be performed like this: 
  Check  the  linker-map-file  of  the  project  for  a  function  called  <TaskName>func.  This 
function must be linked to the address value as specified in the configuration viewer output 
[SPMF92:02.0025].  
 
2015, Vector Informatik GmbH 
Version: 1.05                           52 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.6 How to review the task trusted information (block 2) 
The configuration viewer generates the task trusted information as followed: 
[SPMF92:0061],[SPMF92:0063], [SPMF92:02.0027] 
2. Task trustedness information: 
------------------------------------------------------- 
Task-ID  Task-Name               Value        Checked?  
------------------------------------------------------- 
0        (eTask1)                non-trusted    [  ]    
1        (osSystemExtendedTask)  trusted        [  ]    
2        (bTask1)                non-trusted    [  ]    
3        (osSystemBasicTask)     trusted        [  ]    
------------------------------------------------------- 
 
The review shall be performed like this: 
  Check for each task, that the setting of the attribute TRUSTED of the owner application fits 
to the value of the task trustedness information. In case the owner application has the 
configuration TRUSTED=TRUE, the task must be trusted. In case the owner application 
has the configuration TRUSTED=FALSE, the task must be non-trusted. 
  osSystemExtendedTask and osSystemBasicTask must always be trusted. 
 
2015, Vector Informatik GmbH 
Version: 1.05                           53 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.7 How to review the task preemptive information (block 3) 
The configuration viewer generates the task preemptive information as followed [SPMF92:0063]: 
3. Task preemptiveness information: 
------------------------------------------------------------- 
Task-ID  Task-Name               Value              Checked?  
------------------------------------------------------------- 
0        (eTask1)                fully-preemptible    [  ]    
1        (osSystemExtendedTask)  fully-preemptible    [  ]    
2        (bTask1)                fully-preemptible    [  ]    
3        (osSystemBasicTask)     non-preemptible      [  ]    
------------------------------------------------------------- 
 
The review shall be performed like this: 
  Take the task name (as printed) and check whether this respective task preemptive setting 
was really configured as printed. If preemptive is printed here, the task configuration must 
contain SCHEDULE = FULL, if non-preemptive is printed here, the task configuration must 
contain SCHEDULE=NON. The OS generator assures that each task has the attribute 
SCHEDULE exactly once with possible values FULL or NON. 
2015, Vector Informatik GmbH 
Version: 1.05                           54 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.8 How to review the task stack start and end addresses (block 4 and 5) 
The configuration viewer generates the task stack start addresses as followed [SPMF92:0063]: 
4. Task stack lower boundary addresses: 
------------------------------------------------------ 
Task-ID  Task-Name               Value       Checked?  
------------------------------------------------------ 
0        (eTask1)                0xfedf0640    [  ]    
1        (osSystemExtendedTask)  0x00000010    [  ]    
2        (bTask1)                0xfedf07d0    [  ]    
3        (osSystemBasicTask)     0x00000010    [  ]    
------------------------------------------------------
 
 
The configuration viewer generates the task stack end addresses as followed: 
5. Task stack upper boundary addresses: 
------------------------------------------------------ 
Task-ID  Task-Name               Value       Checked?  
------------------------------------------------------ 
0        (eTask1)                0xfedf07d0    [  ]    
1        (osSystemExtendedTask)  0x00000000    [  ]    
2        (bTask1)                0xfedf0960    [  ]    
3        (osSystemBasicTask)     0x00000000    [  ]    
------------------------------------------------------ 
 
The review shall be performed like this [SPMF92:0056]: 
  Check that the difference between stack start and stack end address fits to the configured 
size of the task stack 
  Check that the stacks do not overlap 
  Compare printed address value of each stack with the address given in the linker map file. 
  Check that all task stack sizes are a multiple of 4 Bytes [SPMF92:04.0008]. This prevents 
that any data of another section is accessible in the same MPU region. 
  Check that each defined address region (task stack start address, task stack end address) 
only covers exactly one array variable named osTaskStack<StackIndex>. 
 
2015, Vector Informatik GmbH 
Version: 1.05                           55 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.9 How to review the task ownership information (block 6) 
The configuration viewer generates the task ownership information as followed [SPMF92:0063]: 
6. Task to application mapping: 
------------------------------------------------------------------------------- 
Task-ID  Task-Name               Appl-ID  Appl-Name                   Checked?  
------------------------------------------------------------------------------- 
0        (eTask1)                2        (xyzAppl)                     [  ]    
1        (osSystemExtendedTask)  1        (osSystemApplicationCore0)    [  ]    
2        (bTask1)                2        (xyzAppl)                     [  ]    
3        (osSystemBasicTask)     1        (osSystemApplicationCore0)    [  ]    
------------------------------------------------------------------------------- 
 
The review shall be performed like this [SPMF92:0062]: 
  The configuration of each application contains a list of the tasks which it owns. Check for 
each of the named applications that it owns exactly those tasks listed in the configuration 
viewer output. The OS generator assures that each task has exactly one owner application. 
2015, Vector Informatik GmbH 
Version: 1.05                           56 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.10  How to review the category 2 ISR start addresses (block 7) 
The configuration viewer generates category 2 ISR start addresses as followed [SPMF92:0063]: 
7. Category 2 ISR function start address: 
------------------------------------------------- 
ISR-ID  ISR-Name            Value       Checked?  
------------------------------------------------- 
0       (ISR1)              0x000030f4    [  ]    
1       (osSystemCat2ISR)   0x000059a4    [  ]    
2       (osTimerInterrupt)  0x00009b9c    [  ]    
------------------------------------------------- 
 
The review shall be performed like this: 
  Check the linker map file of the project for symbol _<ISRName>func. This ISR function 
must be linked to the address value as specified in the configuration viewer output 
[SPMF92:02.0026].  
  In case the ISR has a configured SpecialFunctionName, search for the symbol 
_<SpecialFunctionName>func instead, which is located at the address, shown in the 
configuration block. 
 
2015, Vector Informatik GmbH 
Version: 1.05                           57 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.11  How to review the CAT2 ISR trusted information (block 8) 
The  configuration  viewer  generates  CAT2  ISR  trusted  information  as  followed: 
[SPMF92:0061],[SPMF92:0063], [SPMF92:02.0027] 
8. Category 2 ISR trustedness: 
-------------------------------------------------- 
ISR-ID  ISR-Name            Value        Checked?  
-------------------------------------------------- 
0       (ISR1)              non-trusted    [  ]    
1       (osSystemCat2ISR)   trusted        [  ]    
2       (osTimerInterrupt)  trusted        [  ]    
-------------------------------------------------- 
 
The review shall be performed like this: 
  Check for each cat2 ISR, that the setting of the attribute TRUSTED of the owner application 
fits to the value of the ISR trusted information. In case the owner application has the 
configuration TRUSTED=TRUE, the ISR must be trusted. In case the owner application has 
the configuration TRUSTED=FALSE, the ISR must be non-trusted. The trustedness of the 
system timer ISR osTimerInterrupt cannot be configured and is always a trusted ISR. 
2015, Vector Informatik GmbH 
Version: 1.05                           58 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.12  How to review the CAT2 ISR nested information (block 9) 
The configuration viewer generates the CAT2 ISR nested information as followed [SPMF92:0063]: 
9. Category 2 ISR nesting: 
------------------------------------------------- 
ISR-ID  ISR-Name            Value       Checked?  
------------------------------------------------- 
0       (ISR1)              nested        [  ]    
1       (osSystemCat2ISR)   non-nested    [  ]    
2       (osTimerInterrupt)  nested        [  ]    
------------------------------------------------- 
 
The review shall be performed like this: 
  Check for each cat2 ISR, that the setting of the attribute EnableNesting fits to the value of 
the ISR nested information [SPMF92:02.0031]. In case the cat2 ISR has the configuration 
EnableNesting =TRUE, the ISR must be nested. In case the cat2 ISR has the configuration 
EnableNesting =FALSE, the ISR must be not nested. This setting for the system timer ISR 
osTimerInterrupt is configured via OS attribute SystemTimerNestable. Check that the 
setting of attribute SystemTimerNestable fits to the ISR nested information of ISR 
osTimerInterrupt. 
 
2015, Vector Informatik GmbH 
Version: 1.05                           59 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.13  How to review CAT2 ISR stack start and end addresses (block 10 and 11) 
The  configuration  viewer  generates  the  CAT2  ISR  stack  start  addresses  as  followed 
[SPMF92:0063]: 
10. Category 2 ISR stack start address: 
---------------------------- 
Level  Value       Checked?   
---------------------------- 
0      0x00000000    [  ]     
1      0x00000000    [  ]     
2      0x00000000    [  ]     
3      0x00000000    [  ]     
4      0x00000000    [  ]     
5      0x00000000    [  ]     
6      0x00000000    [  ]     
7      0x00000000    [  ]     
8      0x00000000    [  ]     
9      0x00000000    [  ]     
10     0xfedf0000    [  ]     
11     0x00000000    [  ]     
12     0xfedf0320    [  ]     
13     0x00000000    [  ]     
14     0x00000000    [  ]     
15     0x00000000    [  ]     
---------------------------- 
 

The  configuration  viewer  generates  the  CAT2  ISR  stack  end  addresses  as  followed 
[SPMF92:0063]: 
11. Category 2 ISR stack end address: 
---------------------------- 
Level  Value       Checked?   
---------------------------- 
0      0x00000000    [  ]     
1      0x00000000    [  ]     
2      0x00000000    [  ]     
3      0x00000000    [  ]     
4      0x00000000    [  ]     
5      0x00000000    [  ]     
6      0x00000000    [  ]     
7      0x00000000    [  ]     
8      0x00000000    [  ]     
9      0x00000000    [  ]     
10     0xfedf0320    [  ]     
11     0x00000000    [  ]     
12     0xfedf04b0    [  ]     
13     0x00000000    [  ]     
14     0x00000000    [  ]     
15     0x00000000    [  ]     
---------------------------- 
 
The review shall be performed like this [SPMF92:0056]: 
  Check that the difference between stack start and stack end address fits to the configured 
size of the ISR stack 
  Check that the stacks do not overlap 
  Compare printed address value of each stack with the address given in the linker map file. 
2015, Vector Informatik GmbH 
Version: 1.05                           60 / 80 

Safety Manual MICROSAR OS SafeContext 
  Check that all ISR stack sizes are a multiple of 4 Bytes [SPMF92:04.0008]. This prevents 
that any data of another section is accessible in the same MPU region. 
  Check that each defined address region (ISR stack start address, ISR stack end address) 
only covers exactly one array variable named osIntStackLevel<PriorityLevel>. 
 
2015, Vector Informatik GmbH 
Version: 1.05                           61 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.14  How to review the CAT2 ISR ownership information (block 12) 
The  configuration  viewer  generates  the  CAT2  ISR  ownership  information  as  followed 
[SPMF92:0063]: 
12. Category 2 ISR to application assignment: 
-------------------------------------------------------------------------- 
ISR-ID  ISR-Name            Appl-ID  Appl-Name                   Checked?   
-------------------------------------------------------------------------- 
0       (ISR1)              2        (xyzAppl)                     [  ]     
1       (osSystemCat2ISR)   1        (osSystemApplicationCore0)    [  ]     
2       (osTimerInterrupt)  1        (osSystemApplicationCore0)    [  ]     
-------------------------------------------------------------------------- 
 
The review shall be performed like this: 
  The configuration of each application contains a list of the cat2 ISRs which it owns. Check 
for each of the named applications that it owns exactly those ISRs listed in the configuration 
viewer output [SPMF92:02.0028]. The OS generator assures that each ISR has exactly one 
owner application. The owner of the ISR osTimerInterrupt is the OS itself.  
  Check that category 1 ISRs are not listed in the configuration block. [SPMF92:0055] 
 
2015, Vector Informatik GmbH 
Version: 1.05                           62 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.15  How to review the trusted functions start addresses (block 13) 
The configuration viewer generates trusted functions start addresses as followed [SPMF92:0063]: 
13. Trusted function start address: 
---------------------------------------------------------- 
Tfunc-ID  Tfunc-Name                 Value       Checked?  
---------------------------------------------------------- 
0         (StartTestStep)            0x000039d8    [  ]    
1         (GetTestStep)              0x000039aa    [  ]    
2         (SetCheckPoint)            0x000039c2    [  ]    
3         (TF1)                      0x00003006    [  ]    
4         (TriggerISR1)              0x000039ee    [  ]    
5         (TriggerISR2)              0x00003a06    [  ]    
6         (osSystemTrustedFunction)  0x00005982    [  ]    
---------------------------------------------------------- 
 
The review shall be performed like this: 
  Check the linker map file of the project for symbol TRUSTED_<FuncName>. This function 
must be linked to the address value as specified in the configuration viewer output 
[SPMF92:0048],[SPMF92:0057]. 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           63 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.16  How to review the non-trusted functions start addresses (block 14) 
The  configuration  viewer  generates  non-trusted  functions  start  addresses  as  followed 
[SPMF92:0063]: 
14. Non-trusted function start address: 
----------------------------------------- 
NTfunc-ID NTfunc-Name Value      Checked?  
----------------------------------------- 
0         (NTF1)      0x00002e6a   [ ]     

1         (NTF2)      0x00003de0   [ ]     
----------------------------------------- 
 
The review shall be performed like this: 
  Check  the  linker  map  file  of  the  project  for  symbol  NONTRUSTED_<FuncName>.  This 
function must be linked to the address value as specified in the configuration viewer output  
[SPMF92:02.0024].  
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           64 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.17  How to review the non-trusted functions ownership information (block 15) 
The  configuration  viewer  generates  the  non-trusted  functions  ownership  as  followed 
[SPMF92:0063]: 
15. Non-trusted function to application assignment: 
-------------------------------------------------------- 
NTfunc-ID NTfunc-Name Appl-ID Appl-Name         Checked?  
-------------------------------------------------------- 
0         (NTF1)      1       (NonTrustedApplA)   [ ]    

1         (NTF2)      2       (NonTrustedApplB)   [ ]  
-------------------------------------------------------- 
 
The review shall be performed like this: 
  The configuration of each application contains a list of the functions which it owns. Check 
for each of the named applications that it owns exactly those functions listed in the 
configuration viewer output [SPMF92:02.0029]. The OS generator assures that each 
function has exactly one owner application. 
 
2015, Vector Informatik GmbH 
Version: 1.05                           65 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.18  How to review the application dynamic MPU settings (block 16) 
It is necessary to refer the Renesas Electronics user’s manual architecture [6] for exactly 
understanding of the Memory Protection Unit (MPU). 
The configuration viewer generates the dynamic MPU settings as followed [SPMF92:0063]: 
16. Application MPU configuration (dynamic): 
------------------------------------------------------------------------------ 
Appl-ID  Appl-Name                   Region  Start-Addr  End-Addr    Checked?  
------------------------------------------------------------------------------ 
0        (AppTrusted)                1       0x00000010  0x00000000    [  ]    
                                     2       0x00000010  0x00000000    [  ]    
------------------------------------------------------------------------------ 
1        (NonTrustedApplA)           1       0xffe50000  0xffe5fffc    [  ]    
                                     2       0xfedf0a80  0xfedf0a7f    [  ]    
------------------------------------------------------------------------------ 
2        (NonTrustedApplB)           1       0xffe50000  0xffe5fffc    [  ]    
                                     2       0xfedf0a80  0xfedf0b7f    [  ]    
------------------------------------------------------------------------------ 
3        (TraceAppl)                 1       0x00000010  0x00000000    [  ]    
                                     2       0x00000010  0x00000000    [  ]    
------------------------------------------------------------------------------ 
4        (osSystemApplicationCore0)  1       0x00000010  0x00000000    [  ]    
                                     2       0x00000010  0x00000000    [  ]    
------------------------------------------------------------------------------ 
 
The review shall be performed like this  [SPMF92:0052],[SPMF92:04.0003],[SPMF92:04.0005]: 
  Each application must have the same number of rows. 
  The number of rows for each application must be same as shown in the output of 
configuration block 0: Number of Dynamic MPU Regions  
  Trusted applications must always have Start-Addr = 0x00000010 
  Trusted applications must always have End-Addr = 0x00000000 
  Unused MPU regions in non-trusted applications must have Start-Addr = 0x00000010 
  Unused MPU regions in non-trusted applications must have End-Addr = 0x00000000 
  Check that values of Start-Addr and End-Addr in row of non-trusted applications are same 
as configured in the applications settings 
  Check that used MPU regions in non-trusted applications have Start-Addr value smaller 
than the End-Addr value 
  Check that all trusted and non-trusted applications are listed. 
  Check that all Start-Addr values are aligned to 4 Byte boundary [SPMF92:04.0009] 
  Check that all End-Addr values point to the last valid byte in the specified area. 
  Overlapping of memory regions is not allowed [SPMF92:04.0010]. 
  The next region after the end address must be aligned at to a 4 Byte boundary. 
  Compare  Start-Addr of non-trusted applications that the address value fits to address of 
the application specific linker symbol used in configuration settings [SPMF92:0052]  
  Compare  End-Addr of non-trusted applications that the address value fits to address of the 
application specific linker symbol used in configuration settings [SPMF92:0052]  
  If a linker section for application data memory region is empty then the end address is 
below the start address. The start or end address may then overlap with other linker 
sections. This can be ignored because it does not harm the MPU functionality. 
 
2015, Vector Informatik GmbH 
Version: 1.05                           66 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.19  How to review the interrupt channel index (block 17) 
The configuration viewer generates the interrupt channel index for CAT1 and CAT2 ISRs as 
followed [SPMF92:0063]: 
 
17. Category 2 ISR interrupt channel index: 
---------------------------------------------- 
ISR-ID  ISR-Name            Channel  Checked?  
---------------------------------------------- 
0       (ISR1)              137        [  ]    
1       (osSystemCat2ISR)   0          [  ]    
2       (osTimerInterrupt)  74         [  ]    
3       (TestTimer1)        134        [  ]    
---------------------------------------------- 
 
The review shall be performed like this: 
  Check for each cat1 and cat2 ISR that the number is corresponding to the default priority 
number listed in the hardware user manual of the used processor derivative (look for 
symbol EIINT<Number>). 
  Check that the biggest listed number is not greater than 383. 
  Channel index of ISR osSystemCat2ISR can be ignored because it is not used at all. 
 
2015, Vector Informatik GmbH 
Version: 1.05                           67 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.20  How to review the ISR interrupt priority level (block 18) 
The configuration viewer generates the interrupt priority level for CAT1 and CAT2 ISRs as followed 
[SPMF92:0063]: 
 
18. Category 2 ISR priority level: 
----------------------------------------------- 
ISR-ID  ISR-Name            Priority  Checked?  
----------------------------------------------- 
0       (ISR1)              10          [  ]    
1       (osSystemCat2ISR)   128         [  ]    
2       (osTimerInterrupt)  12          [  ]    
3       (TestTimer1)        7           [  ]    
----------------------------------------------- 
 
The review shall be performed like this [SPMF92:02.0032]: 
  Check for each category 1 and category 2 ISR that the setting of the attribute 
InterruptPriority fits to the value of the printed ISR information “Priority” from configuration 
viewer. 
  Interrupt priority level of osSystemCat2ISR can be ignored because it is not used at all. The 
priority value must always be 128. 
   
 
2015, Vector Informatik GmbH 
Version: 1.05                           68 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.21  How to review the peripheral regions configuration (block 19) 
The configuration viewer generates the application peripheral regions as followed [SPMF92:0063]: 
 
19. Peripheral Regions Configuration: 
----------------------------------------------------- 
Region  Appl-Mask   Start-Addr  End-Addr    Checked?  
----------------------------------------------------- 
0       0x00000005  0xfede0000  0xfede1fff    [  ]    
1       0x0000000c  0xfede4000  0xfede4fff    [  ]    
----------------------------------------------------- 
 
The review shall be performed like this: 
  Check that the listed peripheral region access rights match your configuration 
[SPMF92:02.0030] 
  Check for each row that Appl-Mask fits to the accessing applications. Each bit which is set 
means that the corresponding application has access rights to this region. E.g. if bit 0 is set 
then application with ID=0 has permission to access the region, if bit 1 is set then 
application with ID=1 has permission to access the region etc. 
  Check that the listed peripheral region start and end addresses matches your configuration 
[SPMF92:02.0030] 
  Check for each row that Start-Addr fits to the start address value of the configured 
peripheral region. Start-Addr must point to the first valid byte in the region. 
  Check for each row that End-Addr fits to the end address value of the configured peripheral 
region. End-Addr must point to the last valid byte in the region. 
  Check that the peripheral region index starts with 0 
  Check that the peripheral region index is consecutive with no gaps 
  Check that the peripheral region belongs to the printed application. 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           69 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.22  How to review the static MPU regions configuration (block 20) 
The configuration viewer generates the static MPU regions configuration as followed: 
 
20. MPU configuration (static): 
----------------------------------------------------- 
Region  Start-Addr  End-Addr    Attributes  Checked?  
----------------------------------------------------- 
1       0x00000010  0x00000000  0x000000db    [  ]    
2       0x00000010  0x00000000  0x000000db    [  ]    
3       0x00000000  0x000ffffc  0x000000fd    [  ]    
4       0xff000000  0xfffffffc  0x000000d8    [  ]    
5       0xfedf0960  0xfee00000  0x000000d9    [  ]    
6       0xfedf0000  0xfedf0960  0x000000c9    [  ]    
7       0x00000000  0x00000000  0x00000000    [  ]    
8       0x00000000  0x00000000  0x00000000    [  ]    
9       0x00000000  0x00000000  0x00000000    [  ]    
10      0x00000000  0x00000000  0x00000000    [  ]    
11      0x00000000  0x00000000  0x00000000    [  ]    
----------------------------------------------------- 
 
Start-Addr are the values which are written to MPU registers MPLAn 
End-Addr are the values which are written to MPU registers MPUAn 
Attributes are the values which are written to MPU registers MPATn 
 
The review shall be performed like this: 
  Check that all regions 1 … 11 are listed. 
  If Start-Addr=0x00000010, End-Addr=0x00000000 and Attributes=0x000000db then the 
MPU region is used dynamic, i.e. it is reprogrammed when the context is switched. 
  If Start-Addr=0x00000000, End-Addr=0x00000000 and Attributes=0x00000000 then the 
MPU region is not used at all. 
  All other regions are user specific MPU region settings. 
  Check the user specific MPU region settings that Start-Addr, End-Addr and Attributes fit to 
the corresponding configurations. 
  Check each user specific MPU region setting that Start-Addr is lower than End-Addr.  
  Check each user specific MPU region setting that Attributes contains correct application ID. 
 
2015, Vector Informatik GmbH 
Version: 1.05                           70 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.23  How to review the application trusted information (block 21) 
The configuration viewer generates the application trusted information as followed:  
21. Application trustedness information: 
----------------------------------------------------------- 
Appl-ID  Appl-Name                   Value        Checked?  
----------------------------------------------------------- 
0        (NTAppl)                    non-trusted    [  ]    
1        (abcAppl)                   trusted        [  ]    
2        (osSystemApplicationCore0)  trusted        [  ]    
3        (xyzAppl)                   non-trusted    [  ]    
----------------------------------------------------------- 
 
The review shall be performed like this: 
  Check for each application, that the setting of the attribute TRUSTED fits to the value of the 
application trustedness information. 
  If the application has attribute TRUSTED=TRUE, then Value must be trusted. 
  If application has attribute TRUSTED=FALSE, then Value must be non-trusted. 
  OS system application osSystemApplicationCore0 must always be trusted. 
 
2015, Vector Informatik GmbH 
Version: 1.05                           71 / 80 

Safety Manual MICROSAR OS SafeContext 
12.2.24  How to review the core control block address information (block 22) 
The configuration viewer generates the core control block information as followed:  
22. Core control block address: 
------------------------------ 
Core-ID  Address     Checked?   
------------------------------ 
0        0xfedf0c40    [  ]     
------------------------------ 
 
The review shall be performed like this: 
  Check that Address value is the same value for linker symbol _osCtrlVarsCore0 in the 
project map file which is generated by the linker. 
2015, Vector Informatik GmbH 
Version: 1.05                           72 / 80 

Safety Manual MICROSAR OS SafeContext 
12.3  Linker Memory Sections 
The OS uses specific memory section names for the linker. Check that these section names are 
used in the linker file and check that they are used in the assigned area. 
The OS uses the linker memory section names described in the following table: 
Section Name and Type 
Description and Link Requirements 
.osExceptionVectorTable 
Contains the core exception vector table. It is generated into 
section type .text 
file intvect.c 
.osEIINTVectorTable 
Contains the EIINT exception vector table. It is generated into 
section type .text 
file intvect.c 
.os_text 
Contains the interrupt handler for category 2 ISRs. It is 
section type .text 
generated into file intvect.c 
Must be linked to program code section. 
.os_text 
Contains all OS program code, except those which must be 
section type .text 
placed in special sections (e.g. vector table). 
Must be linked to program code section. 
.os_rodata 
Contains the OS constant data, except those which must be 
section type .rodata 
placed in special sections (e.g. configuration block 
osConfigBlock). 
Must be linked to constant data section. 
.os_rosdata 
Contains all OS constants which are placed in ROSDA area, 
section type .rosdata 
except those which must be placed in special sections (e.g. 
configuration block osConfigBlock). 
Must be linked to the constant data in ROSDA section 
.osConfigBlock_rodata 
Contains the configuration block if SDA optimization is 
section type .rodata 
disabled. 
Must be linked to constant data section. 
.osConfigBlock_rosdata 
Contains the configuration block if SDA optimization is enabled 
section type .rosdata 
Must be linked to constant data in ROSDA section. 
.os_bss 
Contains the uninitialized OS variables 
section type .bss 
Optional initialized to zero by system startup code. 
Must be linked to the data section. 
.os_data 
Contains the initialized OS variables which must be copied 
section type .data 
from ROM to RAM by system startup code.  
Must be linked to the data section. This section must be empty! 
.os_sbss 
Contains uninitialized OS variables which are placed in SDA 
section type .sbss 
area if SDA optimization is enabled. 
Optional initialized to zero by system startup code. 
Must be linked to the SDA section. 
.os_sdata 
Contains initialized OS variables which are placed in SDA area 
section type .sdata 
if SDA optimization is enabled. 
Must be linked to the SDA section. This section must be empty! 
2015, Vector Informatik GmbH 
Version: 1.05                           73 / 80 

Safety Manual MICROSAR OS SafeContext 
Section Name and Type 
Description and Link Requirements 
.osTaskStack<TaskIndex> 
Contains the uninitialized task specific stack. 
section type .bss 
Must be linked to the data section. 
.osSystemStack 
Contains the uninitialized OS system stack. 
section type .bss 
Must be linked to the data section. 
.osIntStackLevel<Priority> 
Contains the uninitialized ISR specific stack. 
section type .bss 
Must be linked to the data section. 
.osAppl_<ApplName>_bss 
Contains uninitialized application data. 
section type .bss 
Optional initialized to zero by system startup code. 
Must be linked to the data section. 
.osAppl_<ApplName>_sbss 
Contains uninitialized application data in SDA area if SDA 
section type .sbss 
optimization is enabled. 
Optional initialized to zero by system startup code. 
Must be linked to SDA section. 
.osAppl_<ApplName>_data 
Contains initialized application data. 
section type .data 
Must be linked to data section. 
.osAppl_<ApplName>_sdata 
Contains initialized application data in SDA area if SDA 
section type .sdata 
optimization is enabled. 
Must be linked to SDA section. 
.osGlobalShared_bss 
Contains uninitialized global shared data. 
section type .bss 
Optional initialized to zero by system startup code. 
Must be linked to data section. 
.osGlobalShared_sbss 
Contains uninitialized shared data in SDA area if SDA 
section type .sbss 
optimization is enabled. 
Optional initialized to zero by system startup code. 
Must be linked to SDA section. 
.osGlobalShared_data 
Contains initialized shared global data. 
section type .data 
Must be linked to data section. 
.osGlobalShared_sdata 
Contains initialized shared data in SDA area if SDA 
section type .sdata 
optimization is enabled. 
Must be linked to SDA section. 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           74 / 80 

Safety Manual MICROSAR OS SafeContext 
12.4  Linker Include Files 
The generated linker include files shall be reviewed if they are used for serial production.  
 
12.4.1 Review File osdata.dld 
File osdata.dld contains mapping of section types .bss and .data for trusted applications. 
 
For each trusted application the generated lines must look like: 
/* trusted application <ApplName> */ 
.osAppl_<ApplName>_bss   align(4) :>. 
.osAppl_<ApplName>_data  align(4) :>. 
 
The linker include file ends with the section mapping for OS data which must look like: 
.os_bss    align(4) :>. 
.os_data   align(4) :>. 
 

2015, Vector Informatik GmbH 
Version: 1.05                           75 / 80 

Safety Manual MICROSAR OS SafeContext 
12.4.2 Review File ossdata.dld 
 
The generated example file ossdata.dld contains the mapping of section types .sbss and 
.sdata for trusted and non-trusted applications. 
For non-trusted applications it also contains the mapping of section types .bss and .data.  
This is necessary due to optimization for MPU region settings. 
 
For each trusted application the generated lines must look like: 
/* trusted application <ApplName> */ 
.osAppl_<ApplName>_sbss        align(4) :>. 
.osAppl_<ApplName>_sdata       align(4) :>. 
 
For each non-trusted application the generated lines must look like: 
/* non-trusted application <ApplName> */ 
.osAppl_<ApplName>_bss         align(4) :>. 
.osAppl_<ApplName>_data        align(4) :>. 
.osAppl_<ApplName>_sbss        align(4) :>. 
.osAppl_<ApplName>_sdata       align(4) :>. 
_<Appl_Section_StartAddr> = addr(.osAppl_<ApplName>_bss); 
_<Appl_Section_EndAddr>   = endaddr(.osAppl_<ApplName>_sdata)-1; 
 
After the mapping of the application sections the mapping for OS SDA sections must be 
generated like the following lines: 
.os_sbss    align(4) :>. 
.os_sdata   align(4) :>. 
 
After the mapping of the OS SDA sections the mapping for global shared sections must be 
generated like the following lines: 
.osGlobalShared_sbss    align(4) :>. 
.osGlobalShared_sdata   align(4) :>. 
.osGlobalShared_bss     align(4) :>. 
.osGlobalShared_data    align(4) :>. 
_osGlobalShared_StartAddr = addr(.osGlobalShared_sbss); 
_osGlobalShared_EndAddr   = endaddr(.osGlobalShared_data)-1; 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           76 / 80 

Safety Manual MICROSAR OS SafeContext 
12.4.3 Review File osstacks.dld 
File osstacks.dld contains mapping of all stack sections. 
 
Each stack section mapping for used interrupt priority levels must look like: 
.osIntStackLevel<PrioLevel> align(4) :>. 
_osIntStackLevel<PrioLevel>_StartAddr = addr(.osIntStackLevel<PrioLevel>); 
_osIntStackLevel<PrioLevel>_EndAddr = endaddr(.osIntStackLevel<PrioLevel>); 
 
<PrioLevel> is the interrupt priority level 0 … 15 
 
The mapping for the system stack section must look like: 
.osSystemStack align(4)  :>. 
_osSystemStack_StartAddr = addr(.osSystemStack); 
_osSystemStack_EndAddr = endaddr(.osSystemStack); 
 

The system stack section is followed by the OS task stack sections which must look like: 
 
.osTaskStackosSystemApplicationCore00 align(4) :>. 
_osTaskStackosSystemApplicationCore00_StartAddr = 

  addr(.osTaskStackosSystemApplicationCore00); 
_osTaskStackosSystemApplicationCore00_EndAddr = 
endaddr(.osTaskStackosSystemApplicationCore00); 
 
.osTaskStackosSystemApplicationCore01 align(4) :>. 
_osTaskStackosSystemApplicationCore01_StartAddr = 

addr(.osTaskStackosSystemApplicationCore01); 
_osTaskStackosSystemApplicationCore01_EndAddr = 
endaddr(.osTaskStackosSystemApplicationCore01); 
 
 
The OS task stack sections are followed by the application task stack sections. 
Each application task stack section mapping must look like: 
.osTaskStack<applname><index>  align(4)  :>. 
_osTaskStack<applname><index>_StartAddr = addr(.osTaskStack<applname><index>); 
_osTaskStack<applname><index>_EndAddr = endaddr(.osTaskStack<applname><index>); 
 
<applname> is the name of the owner application 
<index> is the index number of the task stack: 0 … number of tasks per application 
 
 

2015, Vector Informatik GmbH 
Version: 1.05                           77 / 80 

Safety Manual MICROSAR OS SafeContext 
12.4.4 Review File osrom.dld 
File osrom.dld contains the sections used for initialized variables.  
 
For each application which has data to be initialized during startup code the following lines must be 
generated: 
.ROM_osAppl_<ApplName>_data   ROM(.osAppl_<ApplName>_data)  :>. 
.ROM_osAppl_<ApplName>_sdata  ROM(.osAppl_<ApplName>_sdata) :>. 
.ROM_osAppl_<ApplName>_tdata  ROM(.osAppl_<ApplName>_tdata) :>. 
 
File osrom.dld ends with the global shared initialized data sections which must look like: 
.ROM_GlobalShared_data   ROM(.osGlobalShared_data)  :>. 
.ROM_GlobalShared_sdata  ROM(.osGlobalShared_sdata) :>. 
.ROM_GlobalShared_tdata  ROM(.osGlobalShared_tdata) :>. 
 
 

12.4.5 Review File ostdata.dld 
File ostada.dld contains the mapping for application data in TDA section. 
 
For each application which has data in TDA section the following line must be generated: 
.osAppl_<ApplName>_tdata  align(4) MAX_SIZE(0x0100) :>. 
 
File ostdata.dld ends with the mapping for global shared data in TDA section which must look like: 
.osGlobalShared_tdata  align(4) MAX_SIZE(0x0100) :>. 
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           78 / 80 

Safety Manual MICROSAR OS SafeContext 
12.5  Stack Size Configuration 
The size of task stacks, ISR stacks and the system stack is configured by the user. The application 
code  must  not  use  more  stack  then  configured.  Before  trusted  or  non-trusted  application  code 
(tasks,  ISRs,  trusted  and  non-trusted  functions)  is  executed  the  OS  always  reprogramms  MPU 
region 0 in order to protect the stack memory areas. 
The following table provides an overview of the stacks and which code parts need to be considered 
for the analysis of the required stack sizes. 
Stack 
Usage 
System Stack 
StartupHook 
ErrorHook 
ProtectionHook [SPMF92:0082] 
ShutdownHook [SPMF92:0081] 
Task Stacks 
the corresponding task function and its call tree 
ISRs of category 1 (when interrupting a task) 
ErrorHook 
Storing a context (144 Byte) 
ISR Stacks 
the corresponding category 2 ISR function and its call tree 
ISRs of category 1 (when interrupting an ISR) 
ErrorHook 
Storing a context (144 Byte) 
 
If  no  static  analysis  for  the  stack  requirement  is  made,  the  stack  usage  may  be  measured  by 
means 
of 
the 
API 
functions 
osGetStackUsage, 
osGetISRStackUsage 
and 
osGetSystemStackUsage,  when  StackUsageMeasurement  is  configured.  Measurement  has  to 
consider  the  maximum  stack  usage  of  the  code  under  measure.  It  has  to  be  ensured,  that  all 
directly and indirectly called functions are executed and use the maximum possible stack. 
Stack  Usage  measurement  is  implemented  by  filling  the  stack  with  a  pattern  on  startup  and 
counting the number of continuous patterns which have not been overwritten with another value. 
This may lead to a too small measured value in case the function under measure uses this pattern 
as value on its stack. 
As  the  hardware  allows  to  enable  interrupts  even  in  non-trusted  code,  any  non-trusted  ISR  may 
enable  nesting.  Therefore,  the  user  shall  expect  that  interrupt  nesting  can  always  occur  when 
defining the system stack size [SPMF92:0089]. 
The  stack  usage  must  be  measured  after  the  maximum  call  depth  has  been  reached 
[SPMF92:0090]. 
12.6  Stack Monitoring 
The stack memory area is write protected via MPU region 0. Trusted and non-trusted applications 
and the OS cannot write to stack areas which belong to other applications. 
This  hardware  based  stack  monitoring  does  not  detect  all  stack  errors  [SPMF92:0076].  Stack 
overflow  cannot  be  detected  if  the  task  or  ISR  stack  is  mapped  immediately  after  the 
corresponding application data or global shared section. Stack underflow cannot be detected if the 
task  or  ISR  stack  is  mapped  immediately  before  the  corresponding  application  data  or  global 
shared section. 
 
2015, Vector Informatik GmbH 
Version: 1.05                           79 / 80 

Safety Manual MICROSAR OS SafeContext 
12.7  Usage of MPU Regions 
MPU region 0 is always used for stack area protection. It is always reprogrammed when 
the context is switched. Therefore MPU region 0 cannot be configured by the user.  
Each MPU region 1 … 11 can be configured for static or dynamic usage: 
  If a MPU region is configured for static usage, then it is initialized in StartOS and not 
changed any more. For static MPU regions the user must specify the access attributes. 
  If a MPU region is configured for dynamic usage, then it is initialized in StartOS and not 
always reprogrammed when the context is switched. The access attributes for dynamic 
MU regions are configured by the OS. 
All  stack  sections  must  be  mapped  to  a  consecutive  memory  area. A  static  MPU  region 
must be configured for this memory area so that trusted and non-trusted application have 
only read access to it. That means in supervisor and in user mode only reading is possible. 
Write access to dedicated stack is achieved at runtime via reprogrammed MPU region 0 
when a task or ISR is started. 
A static MPU region must be configured for the applications data area so that in supervisor 
mode read and write is possible and in user mode only reading is possible. Write access to 
the dedicated application data  area  is  achieved  via  dynamic  MPU  region  which  must  be 
configured for each non-trusted application.  
A static MPU region must be configured for the code and const area (i.e. ROM/FLASH) so 
that  in  supervisor  mode  (trusted applications)  read,  write  and  execute  is  possible  and  in 
user mode (non-trusted applications) only read and execute is possible in that area. 
 
12.8  Usage of Peripheral Interrupt API 
The OS provides functions which allow write access to EI level interrupt control registers 
EICn and to EI level interrupt mask registers IMRn in user mode. Non-trusted applications 
can enable or disable peripheral interrupt sources by means of this functions. Call of the 
OS peripheral interrupt API functions must be checked in every application that only valid 
interrupt sources are modified [SPMF92:04.0016].  
 
 
2015, Vector Informatik GmbH 
Version: 1.05                           80 / 80 

Document Outline


4 - Os Integration Manual

Integration Manual

For

Os

VERSION: 1

DATE: 01/08/16

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA

Location: The official version of this document is stored in the Nexteer Configuration Management System.

Revision History

Sl. No.DescriptionAuthorVersionDate
1Initial versionLucas Wendling1.001/08/16

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

3.2 Global Functions(Non RTE) to be provided to Integration Project 6

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

AbbreviationDescription

References

This section lists the title & version of all the documents that are referred for development of this document

Sr. No.TitleVersion

Dependencies

SWCs

ModuleRequired Feature

Note : Referencing the external components should be avoided in most cases. Only in unavoidable circumstance external components should be referred. Developer should track the references.

Global Functions(Non RTE) to be provided to Integration Project

API usage and scheduling of BSW components expected to be captured at a project architectural level and is beyond the scope of this document. Third party documentation can be referenced as needed.

void NxtrOsErrHndlg(StatusType Error)

This function is expected to be called in both the Os Error Hook (ErrorHook) and the Os Protection Hook (ProtectionHook). The Os will generate these stub functions in the generated file “OS_Callout_Stubs.c”. The integrator will need to add the appropriate call to NxtrOsErrHndlg in these stub functions.

Configuration REQUIREMeNTS

Configuration of BSW components expected to be captured at a project architectural level and is beyond the scope of this document. Third party documentation can be referenced as needed.

Build Time Config

ModulesNotes

Configuration Files to be provided by Integration Project

N/A

Da Vinci Parameter Configuration Changes

ParameterNotesSWC

DaVinci Interrupt Configuration Changes

ISR NameNotes

Manual Configuration Changes

ConstantNotesSWC

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Required Global Data Outputs

Specific Include Path present

Yes

Runnable Scheduling

API usage and scheduling of BSW components expected to be captured at a project architectural level and is beyond the scope of this document. Third party documentation can be referenced as needed.

InitScheduling RequirementsTrigger
RunnableScheduling RequirementsTrigger
NxtrOsErrHndlgSee section 3.2Os Error and Protection Hooks

.

Memory Map REQUIREMENTS

Mapping

Memory SectionContentsNotes

* Each …START_SEC… constant is terminated by a …STOP_SEC… constant as specified in the AUTOSAR Memory Mapping requirements.

Usage

FeatureRAMROM

NvM Blocks

Compiler Settings

Preprocessor MACRO

Optimization Settings

Appendix

<This section is for appendix>

5 - Os Module Design Document

Module Design Document

For

Os

1/6/16

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA
Change History

DescriptionAuthorVersionDate
Initial VersionLucas Wendling11/6/16


Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 Os & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of Os 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: Os_Init<n> 9

5.1.1.1 Design Rationale 9

5.1.1.2 Module Outputs 9

5.1.2 Per: Os_Per<n> 9

5.1.2.1 Design Rationale 9

5.1.2.2 Store Module Inputs to Local copies 9

5.1.2.3 (Processing of function)……… 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.2 Server Runables 9

5.2.1 <Server Runable Name> 9

5.2.1.1 Design Rationale 9

5.2.1.2 (Processing of function)……… 10

5.3 Interrupt Functions 10

5.3.1 Interrupt Function Name 10

5.3.1.1 Design Rationale 10

5.3.1.2 (Processing of the ISR function)….. 10

5.4 Module Internal (Local) Functions 10

5.4.1 Local Function #1 10

5.4.1.1 Design Rationale 10

5.4.1.2 Processing 10

5.5 GLOBAL Function/Macro Definitions 10

5.5.1 GLOBAL Function #1 10

5.5.1.1 Design Rationale 11

5.5.1.2 processing 11

6 Known Limitations with Design 12

7 UNIT TEST CONSIDERATION 13

Appendix A Abbreviations and Acronyms 14

Appendix B Glossary 15

Appendix C References 16

Introduction

Purpose

This design document will capture the design of the Nexteer Os Error Handling (NxtrOsErrHndlg) functionality. This is the only portion of this component that is designed by Nexteer rather than a 3rd party.

Scope

The following definitions are used throughout this document:

  • Shall: indicates a mandatory requirement without exception in compliance.

  • Should: indicates a mandatory requirement; exceptions allowed only with documented justification.

  • May: indicates an optional action.

High-Level Description

The Nexteer designed portions of the Os component consist of the Os error processing. This Nexteer specific design was embedded within the Os component itself since this functionality is specifically tied to the errors and names that this particular Os supports. This error handling is expected to be called by the Os protection and error callout functions in any given project. It interfaces with the Exception Handler that is created to react to the different categories of Os errors.

Design details of software module

<The Data Flow Diagrams should be created in the absence of this representation with the FDD.>

Graphical representation of NxtrOsErrHndlg (Expected External Intefaces)

Data Flow Diagram

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant NameResolutionUnitsValue
None

Software Component Implementation

Sub-Module Functions

Init:

None

Per:

None

Server Runables

NxtrOsErrHndlg

Design Rationale

This runnable will parse through the different Os errors that can be detected and interface into the Exception Handler component for handling of the different categories of errors. This runnable is expected to be called by both the Os ErrorHook and the Os ProtectionHook as it handles all categories of Os errors.

Processing

switch (OSErrorGetosCANError())

case osdErrUEUnhandledException:

case osdErrUEUnhandledCoreException:

case osdErrUEUnhandledDirectBranch:

/* Unhandled Exceptions */

ProcUkwnExcpnErr(OSErrorGetosCANError())

break

case osdErrEXMemoryViolation:

/* MPU Violations */

ProcMpuExcpnErr(OSErrorGetosCANError());

break

case osdErrEXPrivilegedInstruction:

/* Privileged Instruction Exceptions */

ProcPrvlgdInstrExcpnErr(OSErrorGetosCANError());

break

case osdErrATWrongTaskPrio:

case osdErrTTNotActivated:

case osdErrTTNoImmediateTaskSwitch:

case osdErrTTWrongActiveTaskID:

case osdErrHTNotActivated:

case osdErrHTNoImmediateTaskSwitch:

case osdErrHTWrongActiveTaskID:

case osdErrSHScheduleNotAllowed:

case osdErrSHWrongActiveTaskID:

case osdErrGSOddInvocation:

case osdErrGIOddInvocation:

case osdErrMTMissingTerminateTask:

case osdErrEAIntAPIWrongSequence:

case osdErrDAIntAPIDisabled:

case osdErrSDWrongCounter:

case osdErrREWrongCounter:

case osdErrSGWrongCounter:

case osdErrRGWrongCounter:

case osdErrGRPriorityOccupied:

case osdErrGRNoAccessRights:

case osdErrGRWrongTaskID:

case osdErrRRCeilingPriorityNotSet:

case osdErrRRWrongTask:

case osdErrRRNoReadyTaskFound:

case osdErrRRWrongTaskID:

case osdErrRRWrongHighRdyPrio:

case osdErrSEWrongTaskPrio:

case osdErrGEOddInvocation:

case osdErrCAAlarmInternal:

case osdErrWAWrongIDonHeap:

case osdErrWAHeapOverflow:

case osdErrWAUnknownAction:

case osdErrWAWrongCounterID:

case osdErrSOStackOverflow:

case osdErrSUWrongTaskID:

case osdErrCLWrongLibrary:

case osdErrEHInterruptsEnabled:

case osdErrSTMemoryError:

case osdErrSTNoImmediateTaskSwitch:

case osdErrSTWrongAppMode:

case osdErrSTConfigCRCError:

case osdErrSTConfigMagicNrError:

case osdErrSTInvalidMajorVersion:

case osdErrSTInvalidMinorVersion:

case osdErrSTInvalidSTCfg:

case osdErrQIWrongTaskPrio:

case osdErrQRInterruptsEnabled:

case osdErrQRWrongTaskID:

case osdErrQRWrongTaskPrio:

case osdErrQRWrongHighRdyPrio:

case osdErrQSInterruptsEnabled:

case osdErrQSNoReadyTaskFound:

case osdErrQSWrongPriority:

case osdErrQOWrongTaskID:

case osdErrSPUnknownCase:

case osdErrSGOddInvocation:

case osdErrWSUnknownAction:

case osdErrWSUnknownReaction:

case osdErrWSWrongID:

case osdErrGCOddInvocation:

case osdErrBMResAlreadyMeasured:

case osdErrBMInvalidProcessInStart:

case osdErrBMInvalidProcessInStop:

case osdErrBMInvalidResource:

case osdErrETNoCurrentProcess:

case osdErrASOddInvocation:

case osdErrTAInvalidTaskState:

case osdErrRSWrongTaskPrio:

case osdErrPAInvalidAreaIndex:

case osdErrPANoAccessRight:

case osdErrPAInvalidAddress:

case osdErrYOSystemStackOverflow:

case osdErrYOTaskStackOverflow:

case osdErrYOISRStackOverflow:

case osdErrSCWrongSysCallParameter:

case osdErrDPStartValidContext:

case osdErrDPResumeInvalidContext:

case osdErrDPInvalidTaskIndex:

case osdErrDPInvalidApplicationID:

case osdErrSUInvalidTaskIndex:

case osdErrSUInvalidIsrIndex:

case osdErrSUInvalidIsrPrioLevel:

case osdErrCIInvalidIsrIndex:

case osdErrCIInvalidIsrPrioLevel:

case osdErrCIInvalidApplicationID:

case osdErrCIMissingIntRequest:

case osdErrCIInterruptIsMasked:

case osdErrCIWrongIntPriority:

case osdErrPIGetIMRInvalidIndex:

case osdErrPISetIMRInvalidIndex:

case osdErrPIClearIMRInvalidIndex:

case osdErrPIWriteIMR8InvalidAddr:

case osdErrPIWriteIMR16InvalidAddr:

case osdErrPIWriteIMR32InvalidAddr:

case osdErrPISetICRMaskInvalidAddr:

case osdErrPIClearICRMaskInvalidAddr:

case osdErrPISetICRReqInvalidAddr:

case osdErrPIClearICRReqInvalidAddr:

case osdErrPIWriteICR8InvalidAddr:

case osdErrPIWriteICR16InvalidAddr:

case osdErrPIWriteICRxLoInvalidIndex:

case osdErrPIWriteICRxHiInvalidIndex:

case osdErrPIWriteICRx16InvalidIndex:

case osdErrCRInvalidSettingOSTM:

case osdErrCRInvalidSettingMPU:

/* Fatal OS fault for assertion / syscheck errors - set data for reset cause */

ProcPrmntOsErr(OSErrorGetosCANError())

break

default:

/* Assumed to be a non-fatal OSEK fault - Set data for periodic sweep up */

ProcNonCritOsErr(OSErrorGetosCANError())

break

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function NameTypeMinMax
Arguments Passed
Return Value

Design Rationale

Processing

GLOBAL Function/Macro Definitions

GLOBAL Function #1

Function NameTypeMinMax
Arguments Passed
Return Value

Design Rationale

Processing

Known Limitations with Design

<Any known limitations with the design shall be documented clearly in this section.>

UNIT TEST CONSIDERATION

Abbreviations and Acronyms

Abbreviation or AcronymDescription

Glossary

Note: Terms and definitions from the source “Nexteer Automotive” take precedence over all other definitions of the same term. Terms and definitions from the source “Nexteer Automotive” are formulated from multiple sources, including the following:

  • ISO 9000

  • ISO/IEC 12207

  • ISO/IEC 15504

  • Automotive SPICE® Process Reference Model (PRM)

  • Automotive SPICE® Process Assessment Model (PAM)

  • ISO/IEC 15288

  • ISO 26262

  • IEEE Standards

  • SWEBOK

  • PMBOK

  • Existing Nexteer Automotive documentation

TermDefinitionSource
MDDModule Design Document
DFDData Flow Diagram

References

Ref. #TitleVersion
1AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)v1.3.0 R4.0 Rev 2
2MDD GuidelineEA4 01.00.00
3Software Naming Conventions.doc1.0
4Software Design and Coding Standards.doc2.0

6 - Os Peer Review Checklists


Overview

Summary Sheet
Synergy Project
Source Code
MDD
PolySpace


Sheet 1: Summary Sheet
























Rev 1.28-Jun-15

Peer Review Summary Sheet


























Synergy Project Name:


kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. Os
Revision / Baseline:


kzshz2: Intended Use: Identify which Synergy revision of this component is being reviewed Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. Os_Vector_Ar4.0.3_01.06.00_0

























Change Owner:


kzshz2: Intended Use: Identify the developer who made the change(s) Rationale: A change request may have more than one resolver, this will help identify who made what change. Change owner identification may be required by indusrty standards. Lucas Wendling
Work CR ID:


EA4#3175





























kzshz2: Intended Use: Intended to identify at a high level to the reviewers which areas of the component have been changed. Rationale: This will be good information to know when ensuring appropriate reviews have been completed. Modified File Types:















































































































































































kzshz2: Intended Use: Identify who where the reviewers, what they reviewed, and if the reviewed changes have been approved to release the code for testing. Comments here should be at a highlevel, the specific comments should be present on the specific review form sheet. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. ADD DR Level Move reviewer and approval to individual checklist form Review Checklist Summary:






















































Reviewed:































YesMDD


YesSource Code


N/APolySpace









































N/AIntegration Manual


N/ADavinci Files








































































Comments:

3rd Party BSW component. Only reviewed 3rd party files for correctness to delivery and any Nexteer created






source files and documentation



















































































General Guidelines:
- The reviews shall be performed over the portions of the component that were modified as a result of the Change Request.
- New components should include FDD Owner and Integrator as apart of the Group Review Board (Source Code, Integration Manual, and Davinci Files)
- Enter any rework required into the comment field and select No. When the rework is complete, review again using this same review sheet and select Yes. Add date and additional comment stating that the rework is completed.
- To review a component with multiple source code files use the "Add Source" button to create a Source code tab for each source file.
- .h file should be reviewed with the source file as part of the source file.





















Sheet 2: Synergy Project

Peer Review Meeting Log (Component Synergy Project Review)



















































Quality Check Items:




































Rationale is required for all answers of No










New baseline version name from Summary Sheet follows








Yes
Comments:

Follows convention created for
naming convention











BSW components
























Project contains necessary subprojects








Yes
Comments:










































Project contains the correct version of subprojects








Yes
Comments:










































Design subproject is correct version








N/A
Comments:











































General Notes / Comments:



























































LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























Change Owner:

Lucas Wendling


Review Date :

01/20/16
































Lead Peer Reviewer:


Jared Julien


Approved by Reviewer(s):



Yes































Other Reviewer(s):










































































Sheet 3: Source Code






















Rev 1.28-Jun-15
Peer Review Meeting Log (Source Code Review)

























Source File Name:


NxtrOsErrHndlg.c

Source File Revision:


1
Header File Name:


NxtrOsErrHndlg.h

Header File Revision:


kzshz2: Intended Use: Identify which version of the source file is being review. Rationale: Required for traceability between source code and review. Auditors will likely require this. 1

























MDD Name:

Os Module Design Document.docx

Revision:
1

























FDD/SCIR/DSR/FDR/CM Name:




N/A

Revision:
N/A


























Quality Check Items:



































Rationale is required for all answers of No









Working EA4 Software Naming Convention followed:















































for variable names







N/A
Comments:

















































for constant names







N/A
Comments:

















































for function names







Yes
Comments:

















































for other names (component, memory







Yes
Comments:










mapping handles, typedefs, etc.)




































All paths assign a value to outputs, ensuring








N/A
Comments:









all outputs are initialized prior to being written





































Requirements Tracability tags in code match the requirements tracability in the FDD








N/A
Comments:









requirements tracability in the FDD





































All variables are declared at the function level.








N/A
Comments:
























Synergy version matches change history





kzshz2: Intended Use: Indicate that the the versioning was confirmed by the peer reviewer(s). Rationale: There have been many occassions where versions were not updated in files and as a result Unit Test were referencing wrong versions. This often time leads to the need to re-run of batch tests.


Yes
Comments:



and Version Control version in file comment block





































Change log contains detailed description of changes








Yes
Comments:

Initial version
and Work CR number





































Code accurately implements FDD (Document or Model)








N/A
Comments:










































Verified no Compiler Errors or Warnings


KMC: Intended Use: To confirm no compiler errors or warnings exist for the code under review (warnings from contract header files may be ignored). Rationale: This is needed to ensure there will be no errors discovered at the time of integration. A Sandox project should be used; QAC can find compiler errors but not warnings.





Yes
Comments:

No sandbox available for BSW components



















Test was done manually on an integration project.
























Component.h is included








Yes
Comments:
























All other includes are actually needed. (System includes








Yes
Comments:









only allowed in Nexteer library components)





































Software Design and Coding Standards followed:











Version:

























Code comments are clear, correct, and adequate







Yes
Comments:










and have been updated for the change: [N40] and













all other rules in the same section as rule [N40],






















plus [N75], [N12], [N23], [N33], [N37], [N38],






















[N48], [N54], [N77], [N79], [N72]














































Source file (.c and .h) comment blocks are per







Yes
Comments:










standards and contain correct information: [N41], [N42]





































Function comment blocks are per standards and







Yes
Comments:










contain correct information: [N43]





































Code formatting (indentation, placement of







Yes
Comments:










braces, etc.) is per standards: [N5], [N55], [N56],













[N57], [N58], [N59]














































Embedded constants used per standards; no







Yes
Comments:










"magic numbers": [N12]





































Memory mapping for non-RTE code







No
Comments:










is per standard





































All execution-order-dependent code can be







N/A
Comments:










recognized by the compiler: [N80]





































All loops have termination conditions that ensure







N/A
Comments:










finite loop iterations: [N63]





































All divides protect against divide by zero







N/A
Comments:










if needed: [N65]





































All integer division and modulus operations







N/A
Comments:










handle negative numbers correctly: [N76]





































All typecasting and fixed point arithmetic,







N/A
Comments:










including all use of fixed point macros and













timer functions, is correct and has no possibility






















of unintended overflow or underflow: [N66]














































All float-to-unsiged conversions ensure the.







N/A
Comments:










float value is non-negative: [N67]





































All conversions between signed and unsigned







N/A
Comments:










types handle msb==1 as intended: [N78]





































All pointer dereferencing protects against







N/A
Comments:










null pointer if needed: [N70]





































Component outputs are limited to the legal range







N/A
Comments:










defined in the FDD DataDict.m file : [N53]





































All code is mapped with FDD (all FDD







N/A
Comments:










subfunctions and/or model blocks identified













with code comments; all code corresponds to






















some FDD subfunction and/or model block): [N40]













































Review did not identify violations of other








Yes
Comments:









coding standard rules





































Anomaly or Design Work CR created








N/A
Comments: List Anomaly or CR numbers









for any FDD corrections needed































































General Notes / Comments:

















































































LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























Change Owner:

Lucas Wendling


Review Date :

01/20/16
































Lead Peer Reviewer:


Jared Julien


Approved by Reviewer(s):



Yes































Other Reviewer(s):










































































Sheet 4: MDD






















Rev 1.28-Jun-15
Peer Review Meeting Log (MDD Review)


























MDD Name:

Os Module Design Document.docx
MDD Revision:

1


























Source File Name:


NxtrOsErrHndlg.cSource File Revision:


1

Source File Name:















Source File Revision:





Source File Name:















Source File Revision:






























Quality Check Items:




































Rationale is required for all answers of No










Synergy version matches document








Yes
Comments:













































Change log contains detailed description of changes








Yes
Comments:













































Changes Highlighted (for Unit Tester)








N/A
Comments:

Initial Version










































Diagrams have been included per MDD Guideline








Yes
Comments:











and reviewed






































All Design Exceptions and Limitations are listed








Yes
Comments:



















































Design rationale given for all global








N/A
Comments:











data not communicated through RTE ports, per














Design and Coding Standards rules [N9] and [N10].















































All implementation details that differ from the FDD are








N/A
Comments:

No FDD








noted and explained in Design Rationale






































All Unit Test Considerations have been described








Yes
Comments:



















































General Notes / Comments:



























































LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























Change Owner:

Lucas Wendling


Review Date :

01/20/16
































Lead Peer Reviewer:


Jared Julien


Approved by Reviewer(s):



Yes































Other Reviewer(s):










































































Sheet 5: PolySpace






















Rev 1.28-Jun-15
Peer Review Meeting Log (QAC/PolySpace Review)


























Source File Name:


NxtrOsErrHndlg.cSource File Revision:


1

Source File Name:















Source File Revision:





Source File Name:















Source File Revision:






























EA4 Static Analysis Compliance Guideline version:







01.01.00














Poly Space version:


Windows User: eg. 2013b 2013B
Polyspace sub project version:




Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 NA

QAC version:


Windows User: eg 8.1.1-R N/A
QAC sub project version:




Windows User: eg. TL108a_PolyspaceSuprt_1.0.0 NA


























Quality Check Items:




































Rationale is required for all answers of No



































Contract Folder's header files are appropriate and





kzshz2: Intended Use: Identify that the contract folder contains only the information required for this component. All other variables, constants, function prototypes, etc. should be removed. Rationale: This will help avoid unit testers having to considers object not used. It will also avoid having other files required for QAC.


Yes
Comments:

Copy of NxtrOsErrHndlg.h moved

function prototypes match the latest component version











to contract folder to avoid analysis of 3rd party headers


























100% Compliance to the EA4 Static AnalysisYes
Comments:





Compliance Guideline





























Are previously added justification and deviation








Yes
Comments:





comments still appropriate






































Do all MISRA deviation comments use approved








N/A
Comments:





deviation tags






































Cyclomatic complexity and Static path count OK






Creager, Kathleen: use Browse Function Metrics, STCYC and STPTH

Yes
Comments:





for all functions in the component per Design














and Coding Standards rule [N47]

































































































General Notes / Comments:



























































LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:


























Change Owner:

Lucas Wendling


Review Date :

01/20/16
































Lead Peer Reviewer:


Jared Julien


Approved by Reviewer(s):



Yes































Other Reviewer(s):









































































7 - ProductInformation_2_Restrictions-for-MSR-OS-SafeContext-SC3

Restrictions for MICROSAR OS SafeContext

8 - ProductInformation_2_Restrictions-for-MSR-OS-SafeContext-SC3_ind

Outline
Page 1
Page 2

9 - ProductInformation_2_Restrictions-for-MSR-OS-SafeContext-SC3s

Product Information Restrictions for MICROSAR OS SafeContext 
1  Purpose 
This document  describes  the  restrictions  of  MICROSAR  OS  SafeContext  compared  with 
the AUTOSAR specification and the Vector OS feature set. 
2  Application area 
All projects with operating system  MICROSAR OS SC3 or MICROSAR OS SafeContext. 
Normally these projects are safety relevant ECUs (ISO 26262). 
3  Target 
Due  to  safety  aspects,  not  all  requirements  of  the  AUTOSAR  specification  are 
implemented. This document describes the restrictions. 
4  Supported Use Cases 
Only applications based on OS scalability class SC3 or SC4 will be supported. 
5  Features not supported 
Class 
Description 
OS service API 
TerminateApplication 
CheckISRMemoryAccess 
CheckTaskMemoryAccess 
GetAlarmBase 
StartScheduleTableSynchron 
SyncScheduleTable  
SetScheduleTableAsync 
Internal Resources  Internal Resources are not supported. 
Killing 
“Killing” of Tasks or Applications is not supported. 
The only allowed protection reaction in the ProtectionHook is 
PRO_SHUTDOWN. Other reactions will be interpreted as PRO_SHUTDOWN. 
A missing TerminateTask error always causes shutdown. 
OS Hooks 
ISRHook 
PreAlarmHook 
OS Application 
StartupHook<Applicationname
specific Hooks
ErrorHook<Applicationname
 
ShutdownHook<Applicationname
2014, Vector Informatik GmbH 
Version: 1.0.0 
1 / 2 
based on template version 4.7.2 

Product Information Restrictions for MICROSAR OS SafeContext 
Class 
Description 
Address Parameter  In case API functions with out-parameters (parameter passed by 
Check 
reference, e.g. GetEvent, GetAlarm, …) are called with illegal address-
parameter, they do not return with the error code 
E_OS_ILLEGAL_ADDRESS as required by the AUTOSAR 
specification. Instead the out-parameter is written with the access 
rights of the caller, which may lead to a memory protection violation in 
case the given pointer is invalid.  
Stack optimization 
Stack sharing is not supported.  
Single stack model is not supported. 
Internal trace 
The “Internal Trace” feature is not supported. 
COM 
OSEK COM inter task communication with messages is not supported. 
ORTI 
ORTIVersion = 2.0 is not supported. 
Error Hook 
ErrorInfoLevel = Modulenames is not supported. 
Table 5-1   Not supported Features 
6  Features with restricted usage 
Class 
Description 
Interrupt resources  Resources are only available at task level, not in interrupt service 
routines. 
OS Hooks 
The following hook functions are limited: 
PreTaskHook is available for debugging only and must not be used in 
final code. 
PostTaskHook is available for debugging only and must not be used 
in final code. 
Address Parameter  In case API functions with out-parameters (parameter passed by 
Check 
reference, e.g. GetEvent, GetAlarm, …) are called with illegal address-
parameter, they do not return with the error code 
E_OS_ILLEGAL_ADDRESS as required by the AUTOSAR 
specification. Instead the out-parameter is written with the access 
rights of the caller, which may lead to a memory protection violation in 
case the given pointer is invalid.  
Configuration 
The following hooks must be always enabled: 
Aspects 
StartupHook 
ErrorHook 
ShutdownHook 
ProtectionHook 
For SCALABILITYCLASS only the settings SC3 or SC4 are supported.  
Memory protection must be active always. 
STACKMONITORING must be enabled. 
OSInternalChecks must be configured to Additional. 
Table 6-1   Supported Features with restricted usage 
2014, Vector Informatik GmbH 
Version: 1.0.0 
2 / 2 
based on template version 4.7.2 

Document Outline


10 - TechnicalReference_MICROSAROS_RH850

MICROSAR OS RH850

12 - TechnicalReference_MICROSAROS_RH850s

 
 
 
 
 
 
 
 
 
 
 
 
MICROSAR OS RH850 
Technical Reference 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Authors 
Senol Cendere, Yohan Humbert 
Version 
1.09 
Status 
Released 
 
 
 
 

Technical Reference MICROSAR OS RH850 
Document Information 
History 
Author 
Date 
Version  Remarks 
S. Cendere 
2014-01-21  1.00 
Creation 
S. Cendere 
2014-02-03  1.01 
Release for RH850 SafeContext 
S. Cendere 
2014-04-24  1.02 
Release for RH850 P1M 
S. Cendere 
2014-09-30  1.03 
Added error numbers for interrupt consistency checks 
Y. Humbert 
2014-10-14  1.04 
Update 
Y. Humbert 
2015-01-29  1.05 
Added ASID support 
Y. Humbert 
2015-02-26  1.06 
Added D1M, E1L, E1M and F1M 
Y. Humbert 
2015-06-10  1.07 
Added Multicore chapter 
S. Cendere 
2015-06-29  1.08 
Added Timing Protection chapter 
S. Cendere 
2015-08-20  1.09 
Removed core exception attributes 
 
Reference Documents 
Ref.  Source 
Title 
Version 
[1] 
AUTOSAR 
AUTOSAR Operating System Specification 
3.0.x 
(downloadable from www.Autosar.org) 
4.0.x 
4.1.x 
[2] 
OSEK 
OSEK/VDX Operating System Specification 
2.2.3 
(downloadable from www.osek-vdx.org) 
[3] 
Vector Informatik GmbH 
Technical Reference MICROSAR OS 
8.00 
 
2015, Vector Informatik GmbH 
Version: 1.09                                2 / 57 
 


Technical Reference MICROSAR OS RH850 
Scope of the Document 
This  technical  reference  describes  the  specific  use  of  the  MICROSAR  OS  for  Renesas 
RH850. It supplements the general technical reference for MICROSAR OS [3]. 
 
 
 
Caution 
We have configured the programs in accordance with your specifications in the 
  questionnaire. Whereas the programs do support other configurations than the one 
specified in your questionnaire, Vector´s release of the programs delivered to your 
company is expressly restricted to the configuration you have specified in the 
questionnaire. 
 
 
Overview 
This  document  describes  the  implementation  specific  part  of  the  AUTOSAR  operating 
system for the Renesas RH850 microcontroller family. In this document a processor of the 
family may be referred as RH850. 
The common part of all MICROSAR OS implementations is described in document [3]. 
The implementation is based on the OSEK-OS-specification 2.2.3 and on AUTOSAR OS 
specifications 3.0.x/4.0.x/4.1.x. This document assumes that the reader is familiar with the 
OSEK and AUTOSAR OS specifications. 
OSEK/VDX  is  a  registered  trademark  of  Continental  Automotive  GmbH  (until  2007: 
Siemens AG). 
2015, Vector Informatik GmbH 
Version: 1.09                                3 / 57 
 

Technical Reference MICROSAR OS RH850 
Contents 
1 
Overview of MICROSAR OS ......................................................................................... 8 
1.1 

Overview of Properties ....................................................................................... 8 
2 
Installation ..................................................................................................................... 9 
2.1 

OIL-Configurator ................................................................................................ 9 
2.1.1 

OIL-Implementation Files ................................................................... 9 
3 
Configuration .............................................................................................................. 10 
3.1 

XML Configuration ........................................................................................... 10 
3.2 
OIL Configuration ............................................................................................. 10 
3.3 
OS Attributes .................................................................................................... 11 
3.3.1 
MpuRegion Sub-Attributes (SC3 and SC4) ...................................... 13 
3.3.2 
PeripheralRegion Sub-Attributes (SC3 and SC4) ............................. 14 
3.4 
Counter Attributes ............................................................................................ 15 
3.4.1 

OSTM Sub-Attributes ....................................................................... 15 
3.4.2 
OSTM_HIRES Sub-Attributes .......................................................... 15 
3.5 
ISR Attributes ................................................................................................... 16 
3.5.1 

ExceptionType Sub-Attributes .......................................................... 16 
3.6 
Application Attributes ....................................................................................... 17 
3.6.1 

Attribute MpuRegion ........................................................................ 17 
3.7 
Event Attributes ................................................................................................ 18 
3.8 
Linker Include Files (SC3 and SC4) ................................................................. 18 
4 
System Generation ..................................................................................................... 19 
4.1 
Code Generator ............................................................................................... 20 
5 
Stack Handling ............................................................................................................ 21 
5.1 

Task Stacks ...................................................................................................... 21 
5.2 
ISR Stacks ....................................................................................................... 21 
5.3 
System Stack ................................................................................................... 21 
5.4 
Startup Stack .................................................................................................... 21 
5.5 
Stack Usage Size ............................................................................................. 21 
5.5.1 
Task Stack Usage ............................................................................ 22 
5.5.2 
System Stack Usage ........................................................................ 22 
5.5.3 
ISR Stack Usage .............................................................................. 22 
6 
Interrupt Handling ....................................................................................................... 23 
6.1 

Interrupt Vectors .............................................................................................. 23 
6.1.1 

Reset Vector .................................................................................... 23 
2015, Vector Informatik GmbH 
Version: 1.09                                4 / 57 
 

Technical Reference MICROSAR OS RH850 
6.1.2 
Level Initialization ............................................................................. 23 
6.2 
Interrupt Level and Category ............................................................................ 24 
6.3 
Interrupt Category 1 ......................................................................................... 24 
6.3.1 

Interrupt Processing in C .................................................................. 24 
6.3.2 
Unhandled Exception Determination ................................................ 24 
6.4 
Interrupt Category 2 ......................................................................................... 25 
6.4.1 

Interrupt Entry .................................................................................. 25 
6.4.2 
Interrupt Exit .................................................................................... 25 
6.4.3 
CAT2 ISR Function .......................................................................... 25 
6.5 
Disabling Interrupts .......................................................................................... 25 
7 
MPU Handling (SC3 and SC4) .................................................................................... 26 
7.1 

MPU Region Usage ......................................................................................... 26 
7.1.1 

MPU Region 0 .................................................................................. 26 
7.1.2 
Static MPU Regions ......................................................................... 26 
7.1.3 
Dynamic MPU Regions .................................................................... 27 
8 
RH850 Peripherals ...................................................................................................... 28 
8.1 

Supported System Timer .................................................................................. 28 
8.2 
Supported Time Monitoring Timer .................................................................... 28 
8.3 
Initialization ...................................................................................................... 28 
9 
Implementation Specifics ........................................................................................... 29 
9.1 

API Functions .................................................................................................. 29 
9.1.1 

DisableAllInterrupts .......................................................................... 29 
9.1.2 
EnableAllInterrupts ........................................................................... 29 
9.1.3 
SuspendAllInterrupts ........................................................................ 29 
9.1.4 
ResumeAllInterrupts ......................................................................... 29 
9.1.5 
SuspendOSInterrupts ....................................................................... 29 
9.1.6 
ResumeOSInterrupts ....................................................................... 29 
9.1.7 
GetResource .................................................................................... 30 
9.1.8 
ReleaseResource ............................................................................ 30 
9.1.9 
GetAlarmBase .................................................................................. 30 
9.1.10 
osInitialize ........................................................................................ 30 
9.1.11 
osInitINTC ........................................................................................ 30 
9.2 
Peripheral Region API ...................................................................................... 31 
9.2.1.1 
Read Functions .............................................................. 31 
9.2.1.2 
Write Functions .............................................................. 32 
9.2.1.3 
Modify Functions ............................................................ 33 
9.3 
Peripheral Interrupt API Functions (SC3 and SC4) ........................................... 34 
9.3.1 
Write to Interrupt Control Register .................................................... 35 
2015, Vector Informatik GmbH 
Version: 1.09                                5 / 57 
 

Technical Reference MICROSAR OS RH850 
9.3.2 
Set or Clear Mask Flag .................................................................... 37 
9.3.3 
Set or Clear ICR Request Flag ......................................................... 38 
9.3.4 
Read, Set or Clear Mask Bit in Registers IMRm ............................... 39 
9.3.5 
Write to Registers IMRm .................................................................. 40 
9.4 
Hook Routines ................................................................................................. 41 
9.4.1 

ErrorHook ........................................................................................ 41 
9.4.2 
StartupHook ..................................................................................... 41 
9.4.3 
ShutdownHook ................................................................................. 41 
9.4.4 
PreTaskHook.................................................................................... 41 
9.4.5 
PostTaskHook .................................................................................. 41 
9.4.6 
PreAlarmHook (SC1 only) ................................................................ 41 
9.4.7 
ISRHooks (SC1 only) ....................................................................... 42 
9.4.8 
Callbacks (SC1 only) ........................................................................ 42 
9.4.9 
ProtectionHook (SC3 and SC4) ....................................................... 42 
9.5 
Functions for MPU functionality checks ............................................................ 43 
9.5.1 

Function osCheckMPUAccess ......................................................... 43 
9.5.2 
Function osCheckAndRefreshMPU .................................................. 44 
10  Non-Trusted Functions (SC3 and SC4) ..................................................................... 45 
10.1 
Functionality ..................................................................................................... 45 
10.2 
API ................................................................................................................... 46 
10.3 
Call Context ..................................................................................................... 47 
10.3.1 
Example ........................................................................................... 48 
11  Multicore ..................................................................................................................... 49 
11.1 
Configuration ................................................................................................... 49 
11.1.1 

Core IDs ........................................................................................... 49 
11.2 
Multi-Core start-up ........................................................................................... 49 
11.2.1 
Both PEs controlled by OS ............................................................... 50 
11.2.2 
Only PE1 controlled by OS ............................................................... 50 
11.2.3 
Only PE2 controlled by OS ............................................................... 51 
12  Timing Protection (SC4) ............................................................................................. 52 
12.1 
Configuration Attributes .................................................................................... 52 
12.2 
Restrictions for SC4 Configurations ................................................................. 52 
13  Error Handling ............................................................................................................ 53 
13.1 
MICROSAR OS RH850 Error Numbers ........................................................... 53 
13.1.1 

RH850 specific Error Numbers ......................................................... 53 
14  Modules ....................................................................................................................... 55 
14.1 
Source Files ..................................................................................................... 55 
2015, Vector Informatik GmbH 
Version: 1.09                                6 / 57 
 

Technical Reference MICROSAR OS RH850 
14.2 
Header Files .................................................................................................... 56 
15  Contact ........................................................................................................................ 57 
 
2015, Vector Informatik GmbH 
Version: 1.09                                7 / 57 
 

Technical Reference MICROSAR OS RH850 
1  Overview of MICROSAR OS 
1.1 
Overview of Properties 
Property Class 
Version / Range / Support 
AUTOSAR OS specification 
3.0.x, 4.0.x, 4.1.x 
SC1 
Scalability Classes supported 
SC3 (SafeContext) 
SC4 (SafeContext) 
SC1: BCC1, BCC2, ECC1, ECC2 
Conformance Classes supported 
SC3 and SC4: ECC2 
SC1: full-, non- and mixed-preemptive 
Scheduling policy 
SC3 and SC4: full- and mixed-preemptive 
Scheduling points 
depending on scheduling policy 
Maximum number of tasks 
65535 
Maximum number of events per task 
32 
Maximum number of activations per task  255 
Maximum number of priorities 
8192 
Maximum number of counters 
256 
Maximum number of alarms 
32767 
Maximum number of resources 
8192 
Maximum number of resources locked 
255 
simultaneously 
Maximum number of schedule tables 
65535 
65535 (cyclical expiry points counted by their 
Maximum number of expiry points 
multiplicity) 
Maximum number of ISRs 
depending on derivative 
SC1: STANDARD and EXTENDED 
Status Levels 
SC3: EXTENDED 
SC4: EXTENDED 
Nested Interrupts 
supported 
SC1: supported 
Interrupt level resource handling 
SC3: not supported 
SC4: not supported 
SC1: 2.1 Standard and 2.1 Additional 
         2.2 Standard and 2.2 Additional 
ORTI support 
SC3: 2.2 Additional 
SC4: 2.2 Additional 
Library Version 
not supported 
FPU support 
supported (if provided by derivative) 
Table 1  
OS Properties 
2015, Vector Informatik GmbH 
Version: 1.09                                8 / 57 
 

Technical Reference MICROSAR OS RH850 
2  Installation  
The general installation is described in the common document [3]. 
The RH850 specific files are described below. 
2.1 
OIL-Configurator 
The  OIL-configurator  is  a  general  tool  for  different  AUTOSAR  implementations.  The 
implementation specific parts are the code generator and the OIL-implementation files for 
the code generator. 
  OIL-Configurator            root\OILTOOL 
  OIL-Implementation files    root\OILTOOL\GEN 
  Code Generator             root\OILTOOL\GEN 
 
2.1.1  OIL-Implementation Files 
The implementation specific files will be copied onto the local hard disk. The OIL-tool has 
knowledge  about  these  files  through  the  file  OILGEN.INI  (the  correct  path  is  set  by  the 
installation program). 
CPU 
Implementation file 
Standard object file 
Description 
D1L 
RH850_D1L.i41 
RH850_D1L.s41 
Source code version 
D1M 
RH850_D1M.i41 
RH850_D1M.s41 
Source code version 
E1L 
RH850_E1L.i41 
RH850_E1L.s41 
Source code version 
E1M 
RH850_E1M.i41 
RH850_E1M.s41 
Source code version 
F1H 
RH850_F1H.i41 
RH850_F1H.s41 
Source code version 
F1L 
RH850_F1L.i41 
RH850_F1L.s41 
Source code version 
F1M 
RH850_F1M.i41 
RH850_F1M.s41 
Source code version 
P1M 
RH850_P1M.i41 
RH850_P1M.s41 
Source code version 
Table 2  
OIL implementation Files 
 
2015, Vector Informatik GmbH 
Version: 1.09                                9 / 57 
 

Technical Reference MICROSAR OS RH850 
3  Configuration 
Before an application can be compiled all static MICROSAR OS objects have to be defined 
in  a  configuration  file.  The  OS  generator  generates  code  in  accordance  to  this 
configuration file. 
The  configuration  can  be  done  either  in  XML  language  (AUTOSAR  ECU  configuration 
format) or in OIL (OSEK implementation language). 
Chapter 4 shows the program flow of a configuration / generation / compilation process in 
detail. 
There  are  configuration  attributes  which  are  standard  for  all  MICROSAR  OS 
implementations. These are described in [3]. 
Platform  specific  attributes  (which  only  apply  to  this  implementation  of  MICROSAR  OS) 
are described hereafter. 
3.1 
XML Configuration 
An XML configuration of the OS must conform to the AUTOSAR XML schema. To edit such 
a configuration the DaVinci configurator of Vector Informatik GmbH can be used. 
3.2 
OIL Configuration 
MICROSAR OS systems for RH850 can also be described using OIL. The OIL configurator 
tool is capable of reading and writing OIL files. The finished OIL file is passed to the code 
generator which generates the configuration files of the OS. 
2015, Vector Informatik GmbH 
Version: 1.09                                10 / 57 
 

Technical Reference MICROSAR OS RH850 
3.3 
OS Attributes 
The OS object controls general aspects of the operating system. The following attributes 
are provided for scalability class SC1, SC3 and SC4: 
Attribute Name 
Values 
Description 
Default  value  is 
OIL 
XML 
written in bold 
Compiler 
OsOSCompiler 
GHS 
Selects the supported compiler. 
SystemStackSize 
OsOSSystemStackSize 
0 … 0xFFFC  Size of the system stack in bytes. 
EnumeratedUnhandl
OsOSEnumeratedUnhandl
TRUE 
This attribute determines handling 
edISRs 
edISRs 
FALSE 
of unused interrupt sources. 
If set TRUE then variable 
ossUnhandledExceptionDetail is 
set to the exception number before 
calling osUnhandledException. 
ORTIDebugSupport 
OsOSORTIDebugSupport 
TRUE 
The RH850 implementation 
FALSE 
supports ORTI debug information if 
this attribute is selected. 
ORTIDebugLevel 
OsOSORTIDebugLevel 
ORTI_22_Ad
Support ORTI 2.2 with additional 
ditional 
features which require some 
additional runtime and memory. 
UserConfigurationVe
OsOSUserConfigurationVer
0 ... 0xFFFF 
This value specifies the current 
rsion 
sion 
user specific version of the OS 
configuration. It can be read back 
by the user for validation. 
SupportFPU 
OsOSSupportFPU 
TRUE 
Switches on the support for FPU. 
FALSE 
(if provided by derivative) 
TimingProtectionTim
OsOSTimingProtectionTime 0 … 999999 
Only SC4: peripheral clock of timer 
erClock 
rClock 
No default 
unit TAUJ0 specified in [kHz] 
Table 1: RH850 specific attributes of OS 
 
2015, Vector Informatik GmbH 
Version: 1.09                                11 / 57 
 

Technical Reference MICROSAR OS RH850 
For scalability class SC3 and SC4 the following additional attributes are provided: 
Attribute Name 
Values 
Description 
Default  value 
OIL 
XML 
is  written  in 
bold 
CheckIntAPIStatus 
OsOSCheckIntAPIStatus 
TRUE 
If set to TRUE then the OS API functions 
FALSE 
CallTrustedFunction and 
CallNonTrustedFunction do not 
check the interrupt status. 
PeripheralRegion 
OsOSPeripheralRegion 
No default 
List of peripheral regions. 
A peripheral region defines an address 
range where access is allowed for 
selected applications (trusted or non-
trusted). 
The access is granted by means of the 
API functions. 
MemoryProtection 
OsOSMemoryProtection 
TRUE 
Enables memory protection via MPU. 
FALSE 
Mandatory for SC3 and SC4. 
MpuRegion 
OsOSMpuRegion 
Enable 
Configures static MPU regions 
 
2015, Vector Informatik GmbH 
Version: 1.09                                12 / 57 
 

Technical Reference MICROSAR OS RH850 
3.3.1  MpuRegion Sub-Attributes (SC3 and SC4) 
If a static MPU region is enabled then the memory area is specified by the following sub-
attributes: 
Sub-Attribute Name 
Values 
Description 
(default value is 
OIL 
XML 
written in bold) 
StartAddr 
OsOSStartAddr 
string 
Start address of static MPU region 
No default 
hexadecimal value: 
StartAddr = 0x… 
or 
memory area specific linker symbol: 
StartAddr = <linker_start_symbol> 
EndAddr 
OsOSEndAddr 
string 
End address of static MPU region 
No default 
hexadecimal value: 
EndAddr = 0x… 
or 
memory area specific linker symbol: 
EndAddr = <linker_end_symbol> 
AccessRights 
OsOSAccessRights  uint32 
MPU region access configuration 
No default 
ASID 
OsOSASID 
TRUE 
Specifies, whether ASID matching is enabled 
FALSE 
for this MPU region. 
Identifier 
OsOSIdentifier 
0 ... 0x3FE 
ASID value to be used as area match 
0x3FF 
condition. The maximum value 0x3FF is used 
as default value. 
 
Value of StartAddr must always point to the first valid Byte in the specified memory area. 
Value of EndAddr must always point to the last valid Byte in the specified memory area. 
Up to 11 static MPU regions can be configured: 
MpuRegion = Enable 

 
StartAddr  = 0x... ; 
 
EndAddr  = 0x… ; 
 
AccessRights = 0x…; 
 
ASID = TRUE; 
 
Identifier = 0x01; 
}; 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                13 / 57 
 


Technical Reference MICROSAR OS RH850 
3.3.2  PeripheralRegion Sub-Attributes (SC3 and SC4) 
Sub-Attribute Name 
Values 
Description 
(default value 
OIL 
XML 
is written in 
bold) 
StartAddress 
OsOSStartAddress 
uint32 
Numeric value. 
No default 
Specifies the start address of the peripheral region 
which shall be configured. 
Any 32 bit value can be used. 
EndAddress 
OsOSEndAddress 
uint32 
Numeric value. 
No default 
Specifies the end address of the peripheral region 
which shall be configured. 
Any 32 bit value can be used. 
Identifier 
OsOSIdentifier 
string 
C-String 
No default 
Must be a unique C Identifier which can be used in 
an application or BSW module to access the 
peripheral region. 
ACCESSING_
OsOSAccessing 
Application 
Application reference. 
APPLICATION  Application 
Type 
Defines access rights of an application for this 
PeripheralRegion. 
This attribute can be defined multiple times, so that 
different applications might have access right to the 
same PeripheralRegion. 
 
 
 
Caution 
The application is allowed to access memory addresses in the interval of StartAddress 
  <= memory to be accessed <= EndAddress 
The “EndAddress” value is included! All bytes of a peripheral access must fit into the 
peripheral region. 
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                14 / 57 
 

Technical Reference MICROSAR OS RH850 
3.4 
Counter Attributes 
Platform specific attributes are located within the container “DRIVER”. 
Sub-Attribute Name 
Values 
Description 
(default value is 
OIL 
XML 
written in bold) 
Timer 
OsCounterTimer  OSTM 
Selects the timer hardware which drives the 
OSTM_HIRES  hardware counter. 
No default 
OSTM: OSTM timer is used and generates cyclic 
interrupts. 
OSTM_HIRES: OSTM timer is used and runs in 
high resolution timer mode. 
Which interrupt channel is used for a specific 
derivative can be found in chapter 8.1. 
 
3.4.1  OSTM Sub-Attributes 
Sub-Attribute Name 
Values 
Description 
(default value is 
OIL 
XML 
written in bold) 
EnableNesting 
OsCounterEnabl
TRUE 
Specifies whether the timer interrupt which drives 
eNesting 
FALSE 
the hardware counter can be interrupted by 
No default 
higher priority interrupts. 
InterruptPriority 
OsCounterInterr
0 ... 15 
The priority of the timer ISR which drives the 
uptPriority 
0 ... (F1L) 
hardware counter. 
StackSize 
OsCounterStack
0 … 0xFFFC 
Stack size of the timer ISR which drives the 
Size 
hardware counter. 
 
3.4.2  OSTM_HIRES Sub-Attributes 
Sub-Attribute Name 
Values 
Description 
(default value is 
OIL 
XML 
written in bold) 
EnableNesting 
OsCounterEnabl
TRUE 
Specifies whether the timer interrupt which drives 
eNesting 
FALSE 
the hardware counter can be interrupted by 
No default 
higher priority interrupts. 
InterruptPriority 
OsCounterInterr
0 ... 15 
The priority of the timer ISR which drives the 
uptPriority 
0 ... (F1L) 
hardware counter. 
StackSize 
OsCounterStack
0 … 0xFFFC 
Stack size of the timer ISR which drives the 
Size 
hardware counter. 
MinTimeBetween
OsCounterMinTi
uint32 
Defines the number of timer ticks which at least 
TimerIrqs 
meBetweenTim

must be between two timer interrupts (shortest 
erIrqs 
possible time between two timer interrupts). 
 
Detailed description how to configure software and hardware counter can be found in [3]. 
 
2015, Vector Informatik GmbH 
Version: 1.09                                15 / 57 
 

Technical Reference MICROSAR OS RH850 
3.5 
ISR Attributes 
Attribute Name 
Values 
Description 
Default value is written in bold 
OIL 
XML 
ExceptionType 
OsOSExceptionType  GENERAL_EXCEPTION 
Select EIINT for EI level interrupts. 
EIINT 
Select GENERAL_EXCEPTION for 
core exceptions. 
EnableNesting 
OsOSEnableNesting 
TRUE 
Must be set FALSE if the  
FALSE 
configured CAT2 ISR shall not be 
interrupted by CAT1 or CAT2 ISRs 
with higher priority level. This 
attribute is ignored for CAT1 ISRs. 
UseSpecialFunc
OsOSUseSpecialFun
TRUE 
This is a feature for mapping 
tionName 
ctionName 
FALSE 
different interrupt / exception 
sources to one interrupt handler. 
This feature is supported as 
described in [3]. 
Table 2: RH850 specific ISR attributes 
 
3.5.1  ExceptionType Sub-Attributes 
 
ExceptionType = GENERAL_EXCEPTION 

Attribute Name 
Values 
Description 
OIL 
XML 
ExceptionAddress 
OsOSExceptionAddress 
No default 
Interrupt vector address offset. 
Table 3: Sub-attributes of ExceptionType=GENERAL_EXCEPTION 
 
ExceptionType = EIINT 

Attribute Name 
Values 
Description 
OIL 
XML 
IntChannel 
OsOSIntChannel 
0 … 511  
Channel index of EI level 
No default 
interrupt. 
Max channel number depends 
on used CPU derivative. 
InterruptPriority 
OsOSInterruptPriority 
SC1 and SC3: 0…15  
Defines the interrupt priority  
SC4: 1…15 
level of the ISR. Lower value 
No default 
means higher priority. 
InterruptStackSize 
OsOSInterruptStackSize 
0 … 0xFFFC 
Size of the ISR stack 
No default 
Table 4: Sub-attributes of ExceptionType=EIINT 
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                16 / 57 
 

Technical Reference MICROSAR OS RH850 
3.6 
Application Attributes 
The following specific attributes are provided for SC3 and SC4: 
Attribute Name 
Values 
Description 
Default  value  is 
OIL 
XML 
written in bold 
ASID 
OsApplicationASID 
0 … 0x3FE 
Value to be written to ASID register 
0x3FF 
on application switch. The 
maximum value 0x3FF is used as 
default value. 
MpuRegion 
OsApplicationMpuRegion 
Enable 
Configures application specific 
dynamic MPU region 
Table 5: RH850: Application specific attributes 
3.6.1  Attribute MpuRegion 
Attribute  MpuRegion  must  be  configured  for  non-trusted  applications  which  need  write 
access to application specific memory areas. If dynamic MPU region is enabled then the 
memory area is specified by following sub-attributes: 
Sub-Attribute Name 
Values 
Description 
(default value 
OIL 
XML 
is written in 
bold) 
StartAddr 
OsApplication
string 
Start address of application specific MPU region 
StartAddr 
No default 
hexadecimal value: 
StartAddr = 0x… 
or application specific linker symbol: 
StartAddr = <appl_linker_start_symbol> 
EndAddr 
OsApplication
string 
End address of application specific MPU region 
EndAddr 
No default 
hexadecimal value: 
EndAddr = 0x… 
or application specific linker symbol: 
EndAddr = <appl_linker_end_symbol> 
Value of StartAddr must always point to the first valid Byte in the specified memory area. 
Value of EndAddr must always point to the last valid Byte in the specified memory area. 
MpuRegion = Enable 

 
StartAddr  = 0x... ; 
 
EndAddr  = 0x... ; 
}; 
 
The total number of used dynamic MPU regions depends on the application which has the 
most number of dynamic regions.  
Example:  if  an  application  has  3  dynamic  regions  and  other  application  has  5  dynamic 
regions then the total number of used dynamic MPU regions is 5. 
2015, Vector Informatik GmbH 
Version: 1.09                                17 / 57 
 

Technical Reference MICROSAR OS RH850 
3.7 
Event Attributes 
Events in the MICROSAR OS operating system are always implemented as bits in bit 
fields. The user could use bit masks like ‘0x00000001’ but to achieve portability between 
different MICROSAR OS implementation he should use event names which are mapped 
by the code generator to the defined bits. The MICROSAR OS RH850 implementation 
allows up to 32 events per task. The required size of the event masks is calculated 
automatically by the code generator. Possible event mask sizes are 8, 16 and 32 Bits. 
3.8 
Linker Include Files (SC3 and SC4) 
The  generated  linker  include  files  osdata.dld,  osrom.dld,  ossdata.dld,  osstacks.dld  and 
ostdata.dld are example files which can be used for mapping the OS and application data. 
osdata.dld 
Include file osdata.dld contains mapping for application and OS data. It should be included 
immediately after the default .data section. 
osrom.dld 
Include osrom.dld contains the mapping of initialized data which is copied by the  start-up 
code from ROM to RAM area. It should be included at end of ROM section. 
ossdata.dld 
Include file ossdata.dld contains the mapping of application and OS data in SDA section. 
Due to limited number of MPU protection areas the SDA section of non-trusted application 
contain SDA and non-SDA data. This affects also the global shared data sections. This file 
must be included after the .sdata section. 
osstacks.dld 
Include file osstacks.dld contains the mapping of system stack, all task and all ISR stacks. 
This file should be included before application specific data sections. 
ostdata.dld 
Include  file  ostdata.dld  contains  mapping  for  application  data  in  TDA  section.  This  file 
should be included after the .zdata section. 
2015, Vector Informatik GmbH 
Version: 1.09                                18 / 57 
 

Technical Reference MICROSAR OS RH850 
4  System Generation 
The system generation process is described in the document  [3] which  is common to all 
implementation. The following section describes the RH850 specific parts of the generating 
process.  
 
Code
AUTOSAR XML
XML
generator
Configuration Tool
OIL
alternative
Configuration
OIL
Files *.c, *.h
Configurator
Compile   and
link
Application
OS source Files *.c, *.h
+
Files *.c, *.h
executable
 
Figure 4-1  System Generation 
2015, Vector Informatik GmbH 
Version: 1.09                                19 / 57 
 

Technical Reference MICROSAR OS RH850 
4.1 
Code Generator 
The following files are generated by the code generator genRH850SCTX.exe 
  config.xml          configuration information in XML-format 
  intvect_c0.c        interrupt vector tables 
  tcb.c                applications and OS configuration 
  tcb.h 
  tcbpost.h 
  trustfct.h             
  trustfct.c            trusted function stubs 
  osConfigBlock.c    contains the configuration block 
  osStacks.h 
  osStacks.c          stack definitions 
  Os_MemMap.h    contains definitions for MemMap usage 
  OILFileName.ort 
  OILFileName.htm 
 
For SC3 and SC4 the following additional files are generated: 
  osdata.dld             example linker include file for application data 
  osrom.dld          example linker include file for application data initialization 
  ossdata.dld         example linker include file for application data in SDA 
  osstacks.dld        example linker include file for stacks 
  ostdata.dld         example linker include file for application data in TDA 
  nontrustfct.h         
 
For multicore systems the following additional files are generated: 
 ioc.h           Header for IOC related functions 
 ioc.c            IOC related functions 
 ccb.h          Header for multicore related attributes 
 ccb.c           Multicore related attributes 
 intvect_c1.c    Interrupt vector tables for second core 
 
The files tcb.c, tcb.h, trustfct.c, trustfct.h and nontrustfct.h are described in document [3]. 
The module intvect_c0.c contains the interrupt vector tables for the Green Hills compiler.  
The module OILFileName.ort is only generated if the configuration attribute 
ORTIDebugSupport is selected. 
OILFileName.htm is containing information about the configuration settings. 
2015, Vector Informatik GmbH 
Version: 1.09                                20 / 57 
 

Technical Reference MICROSAR OS RH850 
5  Stack Handling 
5.1 
Task Stacks 
Each task runs on an own separate task stack. Tasks might share a stack as described in 
[3]. The PreTaskHook function always uses the system stack. The PostTaskHook function 
uses the system stack or in case of a task termination, it uses the task stack of the task 
that is terminated. Note that all task stacks must provide sufficient size for the maximum 
nesting  level  of  ISR  category  1.  Therefore  it  is  recommended  to  use  ISR  category  2  if 
possible. 
The size of  each task stack is determined by the configuration attribute StackSize of  the 
configuration object TASK. 
5.2 
ISR Stacks 
An interrupt stack is defined for each interrupt priority level which is assigned to a CAT2 
ISR. Each CAT2 ISR runs on the interrupt stack which is assigned to its priority level. 
5.3 
System Stack 
The system stack is used by the dispatcher and by the hook wrappers. 
5.4 
Startup Stack 
In function osStartOSasm the stack pointer is initialized to point to the system stack. 
The system stack can be used as start-up stack. 
The following linker symbol is provided to use the system stack as start-up stack: 
_osSystemStack_EndAddr 
5.5 
Stack Usage Size 
The OS offers the possibility to determine the maximum stack usage of the OS stacks. 
Please be aware, that the function stack usage determination for system stacks depends 
heavily on the positions in the code, where an ISR is interrupted by another ISR. 
In the single stack model, the measured value for the system stack usage also depends 
heavily on the position in the code, where a basic task is preempted by another task. For 
this  reason,  it  is  extremely  difficult,  to  find  a  conclusion  for  the  worst  case  system  stack 
usage from the measured stack usage. 
NOTE: The API functions for determination of the stack usage are only available with the 
following configuration settings: 
STACKMONITORING = TRUE 
StackUsageMeasurement = TRUE 
 
2015, Vector Informatik GmbH 
Version: 1.09                                21 / 57 
 

Technical Reference MICROSAR OS RH850 
5.5.1  Task Stack Usage 
API function osGetStackUsage is described in [3]. 
 
5.5.2  System Stack Usage 
The usage of the system stack since the start of the OS can be determined by using the 
function osGetSystemStackUsage
Prototype: 
typedef osuint16 osStackUsageType; 
 
osStackUsageType osGetSystemStackUsage(void); 

 
Argument: 
  none 
Return value:   Maximum stack usage (bytes) of the system stack since StartOS(). 
 
5.5.3  ISR Stack Usage 
The  usage  of  the  ISR  stacks  since  the  start  of  the  OS  can  be  determined  by  using  the 
function osGetISRStackUsage
Prototype: 
typedef osuint16 osStackUsageType; 
 
osStackUsageType osGetISRStackUsage(ISRType IsrIndex); 

 
Argument: 
    Index of the ISR  
Return value:     Maximum stack usage (bytes) of the ISR stack since StartOS(). 
2015, Vector Informatik GmbH 
Version: 1.09                                22 / 57 
 


Technical Reference MICROSAR OS RH850 
6  Interrupt Handling 
 
 
Note 
This implementation supports interrupt handling according to the RH850 “expanded 
  specifications” with a separate vector table for EIINT interrupts. 
 
 
6.1 
Interrupt Vectors 
The code generator generates the interrupt vector tables. Therefore, all interrupt-service-
routines have to be defined in the configuration. The interrupt vector tables are generated 
into the file intvect_c<X>.c for the Green Hills compiler, where X is the corresponding core 
ID. 
The interrupt vector tables are generated into three sections: 
  ". osExceptionVectorTable_c<X>" 
contains the core exception vector table 
 
  ". osEIINTVectorTable_c<X>" 
contains the EIINT exceptions vector table 
 
  ".os_text" 
Contains the ISR prologue for CAT2 ISR wrappers 
 
The length of the mentioned vector tables depends on the concrete derivative. 
 

6.1.1  Reset Vector 
The user can specify an own reset vector. For this the user must configure a category 1 
ISR which has the vector address 0x0, i.e. attribute ExceptionAddress=0x0. 
If a category 1 ISR is configured for vector 0x0, this vector is generated as a jump to the 
specified address. 
If this vector is not configured in the configuration, the vector 0x0 is generated as a jump to 
the startup code, delivered with the compiler.  
Please note that all examples use the start-up module which is delivered with the compiler. 
For the Green Hills compiler this module is crt0.o 
6.1.2  Level Initialization 
The user has to configure an interrupt priority level for all ISRs. MICROSAR OS initializes 
the  appropriate  interrupt  control  register  with  the  level,  configured  by  the  user.  The 
application is not allowed to change the interrupt priority level after StartOS is called. 
2015, Vector Informatik GmbH 
Version: 1.09                                23 / 57 
 

Technical Reference MICROSAR OS RH850 
6.2 
Interrupt Level and Category 
The  RH850  controllers  support  interrupt  levels.  ISRs  with  lower  level  have  priority  over 
those with higher level. ISRs of lower level might therefore be nested into ISRs of higher 
level. Interrupt levels cannot be chosen independently from the category. 
Because ISRs of category 2 can activate tasks, the exit code  of a non-nested category 2 
ISR has to check, if a task has been activated by the ISR itself or by any nested ISRs. If 
so, a task switch has to be set off. As category 1 ISRs have no such exit code, they must 
not  be  interrupted  by  category  2  ISRs.  For  this  reason,  MICROSAR  OS  checks,  that  all 
category 1 ISRs have lower or equal level value than the category 2 ISR with lowest level. 
Note: Scalability class SC4 does not allow use of category 2 ISRs with priority level 0 
6.3 
Interrupt Category 1 
For interrupts of category 1 no MICROSAR OS API functions can be used. Note that the 
category 1 ISR with highest priority value must have lower or equal priority value than the 
category 2 ISR with lowest priority value. 
Example: if category 2 ISRs have priority levels  8, 10, 11 and 12 then category 1 cannot 
use priority levels 8 ... 15. Category 1 ISRs must then use priority levels 0 ... 7 
Note: Scalability class SC4 does not allow use of category 1 ISRs for EIINT exceptions 
6.3.1  Interrupt Processing in C 
Using  the  Green  Hills  compiler,  category  1  interrupt  functions  written  in  C  must  be  
implemented as described in the compiler manual: 
You can use either of the following methods to declare a function as an interrupt routine: 
 
Place #pragma ghs interrupt immediately before the function. 
 
Prepend the __interrupt keyword to the function definition. 
Independently from the compiler, the user should not provide the interrupt vector number 
to the compiler, as the compiler would generate an interrupt vector in this case. Interrupt 
vector generation is always done by the operating system. 
6.3.2  Unhandled Exception Determination 
If an unexpected interrupt occurs which is caused by an unused interrupts source then the 
ErrorHook and ShutdownHook are called and the system shutdown is requested. 
The error type is reported to the application via error code E_OS_SYS_ABORT. 
If  an  unhandled    core  exception  has  occurred  then  the  error  reason  is  reported  to  the 
application  via  error  number  osdErrUEUnhandledCoreException.  The  global  variable 
ossUnhandledCoreExceptionDetail  contains  the  content  of  register  FEIC  and  the  global 
variable ossUnhandledExceptionDetail contains the offset of the core exception. 
If  an  unhandled    EIINT  exception  has  occurred  then  the  error  reason  is  reported  to  the 
application  via  error  number  osdErrUEUnhandledEIINTException.  The  global  variable 
ossUnhandledEIINTDetail  contains  the  content  of  register  EIIC  and  the  global  variable 
ossUnhandledExceptionDetail contains the index of the EIINT exception. 
2015, Vector Informatik GmbH 
Version: 1.09                                24 / 57 
 


Technical Reference MICROSAR OS RH850 
6.4 
Interrupt Category 2 
6.4.1  Interrupt Entry 
The  entry  code  of  category  2  ISRs  is  automatically  generated  by  MICROSAR  OS.  This 
code stores the GPR registers onto stack and calls the CAT2 ISR wrapper.  
SC1  and  SC3:  The  CAT2  ISR  wrapper  clears  the  global  interrupt  disable  flag  if  the 
attribute EnableNesting is set for this ISR before calling the corresponding ISR function. If 
this  attribute  is  not  set  then  the  CAT2  ISR  wrapper  does  not  clear  the  global  interrupt 
disable flag. 
SC4:  The  CAT2  ISR  wrapper  sets  register  PMR  to  system  level  and  clears  the  global 
interrupt  disable  flag  if  the  attribute  EnableNesting  is  set  for  this  ISR  before  calling  the 
corresponding  ISR  function.  If  this  attribute  is  not  set  then  the  CAT2  ISR  wrapper  sets 
register PMR to task level and then clears the global interrupt disable. 
 
6.4.2  Interrupt Exit 
The necessary return from exception is implemented in the CAT2 ISR wrapper exit code. 
The application is not allowed to issue a return from exception instruction.  
 
6.4.3  CAT2 ISR Function 
For category 2 ISRs, the user has to use the ISR-macro provided by MICROSAR OS. The 
name which is given to this macro must be identical to the name in the configuration. 
ISR( myISR ) 

   … /* ISR function body */ 

6.5 
Disabling Interrupts 
 
 
Caution 
It is not allowed to disable interrupts longer than the tick time SECONDSPERTICK of the 
  hardware counter (timer). If interrupts are disabled longer than the tick time the alarm 
management  could  be  handled  wrong.  This  error  is  not  detected  by  the  operating 
system. 
 
 
Only  when  compiling  the  operating  system  with  the  extended  status  additional  error 
checking is performed. 
 
2015, Vector Informatik GmbH 
Version: 1.09                                25 / 57 
 

Technical Reference MICROSAR OS RH850 
7  MPU Handling (SC3 and SC4) 
7.1 
MPU Region Usage 
MPU  region  0  is  used  for  stack  area  protection  and  all  other  MPU  regions  can  be 
configured by the user to be static or dynamic (reprogrammed). 
The total number of available MPU regions depends on the derivative group: 
Derivative group 
Number of MPU regions 
D1L and D1M 
12 
E1L and E1M 
12 
F1H and F1M 
16 
F1L 

P1M 
12 
 
 
7.1.1  MPU Region 0 
MPU region 0 is used for stack area protection and cannot be configured by the user. It is 
always reprogrammed by the OS when the context is switched. Therefore trusted and non-
trusted  applications  can  only  write  to  the  task  and  ISR  stacks  which  belong  to  the 
application. 
 
7.1.2  Static MPU Regions 
If a MPU region shall be static, i.e. it is only initialized in StartOS and not reprogrammed 
when  context  is  switched  then  it  has  to  be  configured  in  the  OS  specific  section.  The 
region  number  is  not  required.  The  OS  generator  assigns  a  region  number  for  each 
configured static MPU region. 
The  user  must  specify  start  address,  end  address  and  region  attributes  of  the  memory 
area. 
If a MPU region is configured to be static then it is initialized in StartOS with settings from 
the configuration block. 
 
2015, Vector Informatik GmbH 
Version: 1.09                                26 / 57 
 

Technical Reference MICROSAR OS RH850 
7.1.3  Dynamic MPU Regions 
If a MPU region shall be dynamic, i.e. it is always reprogrammed when context is switched 
then  it  has  to  be  configured  in  each  corresponding  non-trusted  application  section.  The 
region  number  is  not  required.  The  OS  generator  assigns  a  region  number  for  each 
configured  dynamic  MPU  region.  Trusted  applications  cannot  be  configured  with  MPU 
regions.  
The user must specify start and end address of the memory area. The region attributes are 
configured by the OS.  
If a MPU region is configured to be dynamic then it is initialized in StartOS to be unused. 
After  StartOS  it  is  always  reprogrammed  when  a  non-trusted  application  is  started  or 
terminated. 
Non-trusted applications can have different number of MPU regions. The total number of 
reprogrammed  MPU  regions  depends  on  the  application  which  has  the  most  dynamic 
regions.  Example:  If  a system has 2 non-trusted applications,  one  application  configured 
with 2 MPU regions and the other application configured with 3 MPU regions, then the total 
number  of  dynamic  MPU  regions  is  3.  During  runtime  when  context  is  switched  then 
always 3 MPU regions are reprogrammed.  
Non-trusted application Appl1: 
 MPU region 1 used 
 MPU region 2 used 
Non-trusted application Appl2: 
 MPU region 1 used 
 MPU region 2 used 
 MPU region 3 used 
When  application  Appl1  is  started  then  MPU  regions  1  and  2  are  reprogrammed  with 
application specific settings and MPU region 3 is set to unused. 
When  application Appl2  is  started  then  MPU  regions  1,  2  and  3  are  reprogrammed  with 
application specific settings. 
2015, Vector Informatik GmbH 
Version: 1.09                                27 / 57 
 

Technical Reference MICROSAR OS RH850 
8  RH850 Peripherals 
8.1 
Supported System Timer 
MICROSAR  OS  RH850  uses  the  timer  unit  OSTM  as  driver  for  a  configured  hardware 
counter (see 3.4). The corresponding interrupt channel depends on the derivative group: 
Derivative 
Used Interrupt Channel 
Used Hardware Unit 
group 
D1L / D1M 
125 
OSTM0 
E1L / E1M 
25 
OSTM0 
F1H / F1M 
84 
OSTM0 
 
OSTM5 for second core in multicore system 
F1L 
76 
OSTM0 
P1M 
74 
OSTM0 
Table 3  
RH850 driver for hardware counter 
8.2 
Supported Time Monitoring Timer 
MICROSAR OS RH850 uses the timer unit TAUJ0 for SC4 timing protection: 
Derivative 
Used Interrupt Channels 
Used Hardware Unit 
group 
D1L / D1M 
121, 122, 123 
TAUJ0 
E1L / E1M 
Timing Protection not supported 

F1H / F1M 
80, 81, 82 
TAUJ0 
F1L 
72, 73, 74 
TAUJ0 
P1M 
133, 134, 135 
TAUJ0 
Table 4  
RH850 timer units for timing protection 
8.3 
Initialization 
The OS initializes the interrupt controller INTC before the StartupHook is called.  
Register SCBASE and SCCFG are initialized to use the OS syscall table (SC3 and SC4). 
The OS initializes the timer OSTM after the StartupHook is called. 
In  case  of  SC3  and  SC4,  the  OS  initializes  the  memory  protection  unit  MPU  before  the 
StartupHook is called. 
In case of SC4, the OS initializes the timer unit TAUJ0 before the StartupHook is called. 
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                28 / 57 
 

Technical Reference MICROSAR OS RH850 
9  Implementation Specifics  
9.1 
API Functions 
9.1.1  DisableAllInterrupts 
SC1 and SC3: 
The function DisableAllInterrupts disables all interrupts. This is achieved by 
setting the ID-Bit in register PSW. The old value of the ID-Bit is stored for later restore.  
SC4: The function DisableAllInterrupts disables interrupts up to priority level 1. Interrupts 
with priority level 0 stay enabled. This is performed by setting bits 1…15 in register PMR. 
The  old  value  of  the  register  is  stored  for  later  restore.  Interrupts  of  priority  level  0  stay 
enabled so that timing protection exceptions can still occur. 
Remark: Nested calls are not possible. 
9.1.2  EnableAllInterrupts 
SC1  and  SC3:  
The  function  EnableAllInterrupts  restores  the  content  of  the  ID-Bit  which 
was stored by DisableAllInterrupts.  
SC4:  The  function  EnableAllInterrupts  restores  the  content  of  register  PMR  which  was 
stored by DisableAllInterrupts.  
Remark: Nested calls are not possible. 
9.1.3  SuspendAllInterrupts 
SC1 and SC3: 
The function SuspendAllInterrupts disables all interrupts. This is achieved 
by setting the ID-Bit in register PSW. The old value of the ID-Bit is stored for later restore.  
SC4: The function SuspendAllInterrupts disables interrupts up to priority level 1. Interrupts 
with priority level 0 stay enabled. This is performed by setting bits 1…15 in register PMR. 
The  old  value  of  the  register  is  stored  for  later  restore.  Interrupts  of  priority  level  0  stay 
enabled so that timing protection exceptions can still occur. 
Remark: Nested calls are possible. 
9.1.4  ResumeAllInterrupts 
SC1 and SC3: 
The function ResumeAllInterrupts restores the content of the ID-Bit which 
was stored by SuspendAllInterrupts
SC4:  The  function  ResumeAllInterrupts  restores  the  content  of  register  PMR  which  was 
stored by SuspendAllInterrupts.  
Remark: Nested calls are possible. 
9.1.5  SuspendOSInterrupts 
The function SuspendOSInterrupts disables all category 2 interrupts. This is  achieved by 
setting  the  PMR  register  to  system  level  (highest  interrupt  priority  of  all  category  2 
interrupts). The old value of the PMR register is stored for later restore.  
Remark: Nested calls are possible. 
9.1.6  ResumeOSInterrupts 
The function ResumeOSInterrupts restores the content of register PMR which was stored 
by SuspendOSInterrupts
Remark: Nested calls are possible. 
2015, Vector Informatik GmbH 
Version: 1.09                                29 / 57 
 

Technical Reference MICROSAR OS RH850 
9.1.7  GetResource 
MICROSAR OS RH850 SC3/SC4 does not support the extension of the resource concept 
for interrupt levels. 
9.1.8  ReleaseResource 
MICROSAR OS RH850 SC3/SC4 does not support the extension of the resource concept 
for interrupt levels. 
9.1.9  GetAlarmBase 
MICROSAR OS RH850 SC3/SC4 does not support API function GetAlarmBase. 
9.1.10  osInitialize 
Function  osInitialize  is  used  for  initializing  OS  global  variables  which  are  used  by 
osDispatcher and interrupt handling API. It is called by the OS in StartOS.  
Prototype: void osInitialize(void) 
9.1.11  osInitINTC 
Function osInitINTC initializes the interrupt controller INTC and some core registers: 
 
EBASE = &osExceptionVectorTable 
 
INTBP = &osEIINTVectorTable 
 
INTCFG = 0 
 
SCBP = &osSysCallTable (SC3 and SC4) 
 
SCCFG = osdNumberOfSysCallFunctions (SC3 and SC4) 
 
set table mode and priority level for each configured EIINT interrupt source 
osInitINTC is called by the OS in StartOS.  
Prototype: void osInitINTC(void) 
Remark:  If  OS  API  functions  are  used  before  StartOS  then  osInitialize  and  osInitINTC 
must be called before any OS API function is called. 
 
2015, Vector Informatik GmbH 
Version: 1.09                                30 / 57 
 

Technical Reference MICROSAR OS RH850 
9.2 
Peripheral Region API 
In  a  safety  application  there  is  the  need  to  access  peripheral  components  from  QM 
software (non-trusted). 
For  QM  software,  which  runs  in  restricted  mode  (e.g.  user  mode)  the  peripheral  access 
must be granted by the MPU. Sometimes there are peripheral registers which cannot be 
written at all in restricted mode. 
Therefore the OS offers the concept of the peripheral region API. 
The peripheral regions are defined in the configuration. Access rights are also configured 
on application level. 
With an API any Software (also non trusted) is capable to write to peripheral registers even 
if the access is not granted by the MPU. 
9.2.1.1 
Read Functions 
There are three reading functions. 
Prototype 
osuint8  osReadPeripheral8 ( osuint16 area, osuint32 address ) 
osuint16 osReadPeripheral16( osuint16 area, osuint32 address ) 
osuint32 osReadPeripheral32( osuint16 area, osuint32 address ) 
Parameter 
area 
Identifier of peripheral regions to the read from 
address 
Address to be read from 
Return code 
 
The content of “address” interpreted as 8 bit, 16 bit or 32 bit value 
Functional Description 
>  reads either an 8 bit, or a 16 bit or a 32 bit value from “address” 
>  The function performs accessing checks (whether the caller has accessing rights to the 
peripheral region and whether the address to be read from is within the configured range of 
the peripheral region) 
>  The error hook is raised in case of an error 
>  A shutdown is not issued in case of an error 
Particularities and Limitations 
>  These functions may not be called from OS hooks 
Call context 
>  These functions may be called from Task context 
>  These functions may be called from category 2 ISR context 
>  These functions can be called with interrupts enabled or with interrupts disabled 
 
2015, Vector Informatik GmbH 
Version: 1.09                                31 / 57 
 

Technical Reference MICROSAR OS RH850 
9.2.1.2 
Write Functions 
There are three writing functions. 
Prototype 
void osWritePeripheral8 ( osuint16 area, osuint32 address, osuint8 value) 
void osWritePeripheral16( osuint16 area, osuint32 address, osuint16 value) 
void osWritePeripheral32( osuint16 area, osuint32 address, osuint32 value) 
Parameter 
area 
Identifier of peripheral regions to the read from 
address 
Address to write to 
value 
Value to be written 
Return code 
None 
 
Functional Description 
>  Writes to either an 8 bit, or a 16 bit or a 32 bit value 
>  The function performs accessing checks (whether the caller has accessing rights to the 
peripheral region and whether the address to be read from is within the configured range of 
the peripheral region) 
>  The error hook is raised in case of an error 
>  A shutdown is not issued in case of an error 
Particularities and Limitations 
>  These functions may not be called from OS hooks 
Call context 
>  These functions may be called from Task context 
>  These functions may be called from category 2 ISR context 
>  These functions can be called with interrupts enabled or with interrupts disabled 
 
2015, Vector Informatik GmbH 
Version: 1.09                                32 / 57 
 

Technical Reference MICROSAR OS RH850 
 
9.2.1.3 
Modify Functions 
There are three modifying functions. 
Prototype 
void osModifyPeripheral8 ( osuint16 area, osuint32 address, osuint8 clearmask, 
osuint8 setmask) 
void osModifyPeripheral16( osuint16 area, osuint32 address, osuint16 clearmask, 
osuint16 setmask) 
void osModifyPeripheral32( osuint16 area, osuint32 address, osuint32 clearmask, 
osuint32 setmask) 
Parameter 
area 
Identifier of peripheral regions to the read from 
address 
Address to be modified 
clearmask 
Bitmask which is bitwise “ANDed” to “address” 
setmask 
Bitmask which is bitwise “ORed” to “address” 
Return code 
None 
 
Functional Description 
>  The function performs accessing checks (whether the caller has accessing rights to the 
peripheral region and whether the address to be read from is within the configured range of 
the peripheral region) 
>  The error hook is raised in case of an error 
>  A shutdown is not issued in case of an error 
>  After the access checks has passed first the “clearmask” is ANDed to “address” and 
afterwards the “setmask” is ORed to it. 
Particularities and Limitations 
>  These functions may not be called from OS hooks 
Call context 
>  These functions may be called from Task context 
>  These functions may be called from category 2 ISR context 
>  These functions can be called with interrupts enabled or with interrupts disabled 
 
2015, Vector Informatik GmbH 
Version: 1.09                                33 / 57 
 

Technical Reference MICROSAR OS RH850 
9.3 
Peripheral Interrupt API Functions (SC3 and SC4) 
The  OS  provides  functions  which  can  be  used  to  perform  write  access  to  the  interrupt 
controller INTC control registers in user mode. 
If read access to SFR registers is enabled in user mode then the following macros can be 
used to read from interrupt controller INTC registers. 
#define osReadICR8(addr)   (*((osuint8*)(addr))) 
#define osReadICR16(addr)  (*((osuint16*)(addr))) 
 
This chapter describes API functions which can be used to access the interrupt control 
registers within the corresponding address range: 
 
Derivative group  Address range 
D1L/D1M 

FFFE EA00 - FFFE EA3E (EIC0 to EIC31) 
FFFF B040 - FFFF B1FE (EIC32 to EIC255) 

E1L/E1M 
FFFE EA00 - FFFE EA3E (EIC0 to EIC31) 
FFFF B040 - FFFF B3FE (EIC32 to EIC511) 

F1H 
FFFE EA00 - FFFE EA3E (EIC0 to EIC31) 
FFFF B040 - FFFF B2BC (EIC32 to EIC350) 

F1L 
FFFF 9000 - FFFF 903E (EIC0- EIC31) 
FFFF A040 - FFFF A232 (EIC32- EIC281) 

F1M 
FFFE EA00 - FFFE EA3E (EIC0 to EIC31) 
FFFF B040 - FFFF B25C (EIC32 to EIC297) 

P1M 
FFFE EA00 - FFFE EA3E (EIC0 to EIC31) 
FFFF B040 - FFFF B2FE (EIC32 to EIC383) 

 
 

2015, Vector Informatik GmbH 
Version: 1.09                                34 / 57 
 

Technical Reference MICROSAR OS RH850 
9.3.1  Write to Interrupt Control Register 
Writing 1 or 2 Byte to the interrupt controller INTC control register is achieved by 
osWriteICR8/osWriteICR16 and osWriteICRxLo/ osWriteICRxHi/ osWriteICRx16: 
 
 
osWriteICR8 
This function writes 1 Byte at specified destination address. Before writing the address 
parameter is checked to be in valid range. 
Prototype 
void osWriteICR8(uint32 addr, uint8 val); 
Parameter 
addr 

destination address 
val 
value to be written at destination address 
Return Code 
void 


Functional Description 
*(uint8*)addr = (uint8)val;
 
 
osWriteICR16 
This function writes 2 Bytes at specified destination address. Before writing the address 
parameter is checked to be in valid range. 
Prototype 
void osWriteICR16(uint32 addr, uint16 val); 
Parameter 
addr 

destination address 
val 
value to be written at destination address 
Return Code 
void 


Functional Description 
*(uint16*)addr = (uint16)val;
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                35 / 57 
 

Technical Reference MICROSAR OS RH850 
osWriteICRxLo 
This function writes the lower Byte of the control register of the specified interrupt number. 
Before writing the index is checked to be in valid range. 
Prototype 
void osWriteICRxLo(uint32 index, uint8 val); 
Parameter 
index 

interrupt number 
val 
value to be written to control register 
Return Code 
void 


Functional Description 
*(uint8*)addr = (uint8)val;
 
osWriteICRxHi 
This function writes the upper Byte of the control register of the specified interrupt number. 
Before writing the index is checked to be in valid range. 
Prototype 
void osWriteICRxHi(uint32 index, uint8 val); 
Parameter 
index 

interrupt number 
val 
value to be written to control register 
Return Code 
void 


Functional Description 
*(uint8*)addr = (uint8)val;
 
osWriteICRx16 
This function writes both Bytes of the control register of the specified interrupt number. 
Before writing the index is checked to be in valid range. 
Prototype 
void osWriteICRx16(uint32 index, uint16 val); 
Parameter 
index 

interrupt number 
val 
value to be written to control register 
Return Code 
void 


Functional Description 
*(uint8*)addr = (uint8)val;
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                36 / 57 
 

Technical Reference MICROSAR OS RH850 
9.3.2  Set or Clear Mask Flag 
The mask flag of the interrupt control register can be set or cleared by osSetICRMask and 
osClearICRMask. 
osSetICRMask 
This function sets the mask flag at specified destination address which must be even. 
Before writing the address parameter is checked to be in valid range. The address 
parameter is not checked to be even. The user must take care about it. 
Prototype 
void osSetICRMask(uint32 addr); 
Parameter 
addr 

destination address 
Return Code 
void 


Functional Description 
*(uint8*)addr |= (uint8)0x80;
 
osClearICRMask 
This function clears the mask flag at specified destination address which must be even. 
Before writing the address parameter is checked to be in valid range. The address 
parameter is not checked to be even. The user must take care about it. 
Prototype 
void osClearICRMask(uint32 addr); 
Parameter 
addr 

destination address 
Return Code 
void 


Functional Description 
*(uint8*)addr &= (uint8)0x7F;
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                37 / 57 
 

Technical Reference MICROSAR OS RH850 
9.3.3  Set or Clear ICR Request Flag 
The request flag of the interrupt control register can be set and cleared by calling the 
functions osSetICRReq and osClearICRReq:  
 
osSetICRReq 
This function sets the interrupt request flag at specified destination address. Before writing 
the address parameter is checked to be in valid range. The destination address is 
automatically made an odd address by the function. 
Prototype 
void osSetICRReq(uint32 addr); 
Parameter 
addr 

destination address 
Return Code 
void 


Functional Description 
*(uint8*)(addr | 0x01) |= (uint8)0x10;
 
 
osClearICRReq 
This function clears the interrupt request flag at specified destination address. Before 
writing the address parameter is checked to be in valid range. The destination address is 
automatically made an odd address by the function. 
Prototype 
void osClearICRReq(uint32 addr); 
Parameter 
addr 

destination address 
Return Code 
void 


Functional Description 
*(uint8*)(addr | 0x01) &= (uint8)0xEF;
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                38 / 57 
 

Technical Reference MICROSAR OS RH850 
9.3.4  Read, Set or Clear Mask Bit in Registers IMRm 
The mask bits in IMRm registers can be read, set and cleared by calling functions 
osGetIMRmEI, osSetIMRmEI and osClearIMRmEI. 
osGetIMRmEI 
This function returns the current value of the mask bit specified by index (interrupt 
number). Before read access the index parameter is checked to be in the valid range. 
Prototype 
void osGetIMRmEI(uint16 index); 
Parameter 
index 

mask register index 
Return Code 
uint8 

return mask flag IMRmEIMK<index> 
Functional Description 
return (uint8)(IMRmEIMK<index>);
 
osSetIMRmEI 
This function sets the mask bit specified by index (interrupt numer).  Before write access 
the index parameter is checked to be in the valid range. 
Prototype 
void osSetIMRmEI(uint16 index); 
Parameter 
index 

mask register index 
Return Code 
void 


Functional Description 
IMRmEIMK<index> = 1;
 
osClearIMRmEI 
This function clears the mask bit specified by index (interrupt number). Before write access 
the index parameter is checked to be in the valid range. 
Prototype 
void osClearIMRmEI(uint16 index); 
Parameter 
index 

mask register index 
Return Code 
void 


Functional Description 
IMRmEIMK<index> = 0;
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                39 / 57 
 

Technical Reference MICROSAR OS RH850 
9.3.5  Write to Registers IMRm 
The registers IMRm can be written with 1 Byte, 2 Byte and 4 Byte value by calling functions 
osWriteIMR8, osWriteIMR16 and osWriteIMR32. 
osWriteIMR8 
Function osWriteIMR8 writes 1 Byte to register IMRm specified by address. Before write access 
the address parameter is checked to be in the valid range. 
Prototype 
void osWriteIMR8(uint32 addr, uint8 val); 
Parameter 
addr 

destination address 
val 
value to be written at destination address 
Return Code 
void 


Functional Description 
*(uint8*)addr = (uint8)val; 

osWriteIMR16 
This function writes 2 Bytes to register IMRm specified by address. Before write access the 
address parameter is checked to be in the valid range. 
Prototype 
void osWriteIMR16(uint32 addr, uint16 val); 
Parameter 
addr 

destination address 
val 
value to be written at destination address 
Return Code 
void 


Functional Description 
*(uint16*)addr = (uint16)val; 

osWriteIMR32 
This function writes 4 Bytes to register IMRm specified by address. Before write access the 
address parameter is checked to be in the valid range. 
Prototype 
void osWriteIMR32(uint32 addr, uint32 val); 
Parameter 
addr 

destination address 
val 
value to be written at destination address 
Return Code 
void 


Functional Description 
*(uint32*)addr = (uint32)val; 

 
2015, Vector Informatik GmbH 
Version: 1.09                                40 / 57 
 

Technical Reference MICROSAR OS RH850 
9.4 
Hook Routines 
The MICROSAR OS specification [3] allows implementation specific additional parameters 
in hook routines. The prototypes of the hook routines are described in [1]. 
The  contexts  where  hook  routines  are  called  are  implementation  specific  and  are 
described below. All hook routines are called with disabled interrupts. 
9.4.1  ErrorHook 
The ErrorHook is called if an error is detected in an API-function and if a system error is 
detected. The  ErrorHook  runs on  the  task  or  ISR  stack  if  an API  error  is  reported  and  it 
runs  on  the  system  stack  if  an  unrecoverable  system  error  is  reported.  Interrupts  are 
disabled and CPU runs in supervisor mode. 
9.4.2  StartupHook 
The StartupHook runs always on the system stack. Interrupts are disabled and CPU runs 
in supervisor mode. 
9.4.3  ShutdownHook 
SC1:  The  ShutdownHook  runs  on  the  stack  of  the  task  or  ISR  which  has  called 
ShutdownOS(). EI level interrupts are disabled. 
SC3 and SC4: The ShutdownHook runs always on the system stack. EI level interrupts are 
disabled and the CPU runs in supervisor mode. 
9.4.4  PreTaskHook 
The PreTaskHook runs always on the system stack. Interrupts are disabled and CPU runs 
in supervisor mode. 
9.4.5  PostTaskHook 
The PostTaskHook runs on the task stack or on the system stack. Interrupts are disabled 
and CPU runs in supervisor mode. 
9.4.6  PreAlarmHook (SC1 only) 
When  entering  the  ISR  “osTimerInterrupt”  there  is  a  call  of  the  PreAlarmHook  when  the 
corresponding configuration switch is set. The user has to take care for the implementation 
of this routine. Please implement this hook routine as follows: 
void PreAlarmHook(void) 

   /* user specific code */ 

The Hook Routine is called before incrementing the system counter and before handling 
all alarms! The Hook Routine runs on system stack. 
2015, Vector Informatik GmbH 
Version: 1.09                                41 / 57 
 

Technical Reference MICROSAR OS RH850 
9.4.7  ISRHooks (SC1 only) 
The  ISRHooks  –  UserPreISRHook  and  UserPostISRHook  –  run  on  the  system  stack.  If 
EnableNesting  is  set  to  TRUE  for  the  respective  ISR,  these  hooks  run  with  interrupts 
enabled;  otherwise  they  run  with  interrupts  disabled..  For  a  more  detailed  description  of 
these hooks see [3]. 
 
9.4.8  Callbacks (SC1 only) 
Callbacks run on the stack of the entity that led to their activation. E.g. if an alarm callback 
is activated through a call to IncrementCounter() by a task, it runs on this tasks stack.  If  
IncrementCounter()    was    called    by    an    interrupt    (for    example    the    system    timer 
interrupt), the Callback runs onthe corresponding ISR stack. 
9.4.9  ProtectionHook (SC3 and SC4) 
The ProtectionHook is called if a memory protection or privileged instruction violation was 
detected.  It  runs  always  on  the  system  stack.  Interrupts  are  disabled  and  CPU  runs  in 
supervisor mode. 
 
 
 
 
 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                42 / 57 
 

Technical Reference MICROSAR OS RH850 
9.5 Functions for MPU functionality checks 
The OS provides 2 functions which can be called to check the functionality of the MPU. 
 
9.5.1  Function osCheckMPUAccess 
Function osCheckMPUAccess can be called to check the current MPU protection settings. 
Prototype 
uint8 osCheckMPUAccess(const uint8* addr) 
Parameter 
addr 
The address to be checked for read and write access 
Return Type 
0 = E_OK: read and write access to given address is possible 
uint8 
1 = E_OS_ACCESS: access to given address has caused memory protection violation 
Functional Description 
  disable interrupts 
  call internal function osAsmCheckMPU to check read and write access to destination address  
  store the return value of internal function osAsmCheckMPU into local variable 
  restore previous interrupt state 
  return with given return value 
Particularities and Limitations 
The internal function osAsmCheckMPU first reads 1 byte from the destination address and then writes 
this value back to the destination address. If read and write access is possible the value on the given 
destination address is not changed. If read or write access is not possible then an access violation is 
detected by the MPU and a protection exception occurs. The protection exception handler returns to 
internal function osAsmCheckMPU with return value = 1. This return value is returned to the caller of 
function osCheckMPUAccess to signal the access violation. 
Call Context 
Not allowed before call of StartOS() 
Table 5: Function osCheckMPUAccess 
 
2015, Vector Informatik GmbH 
Version: 1.09                                43 / 57 
 

Technical Reference MICROSAR OS RH850 
9.5.2  Function osCheckAndRefreshMPU 
Function  osCheckAndRefreshMPU  can  be  called  to  check  and  re-initialize  all  MPU 
registers which are not reprogrammed during runtime. 
Prototype 
StatusType osCheckAndRefreshMPU(void) 
Parameter 


Return Type 
StatusType  E_OK:                                   all MPU registers have expected content  
E_OS_SYS_API_ERROR:   invalid content was detected in MPU registers 
Functional Description 
  checks all MPU registers which are not reprogrammed 
  re-initialize all MPU registers which are not reprogrammed 
  returns E_OK if all MPU registers have expected content 
  returns E_OS_SYS_API_ERROR if invalid content was detected in MPU registers 
Particularities and Limitations 
-   
Call Context 
  Call is only allowed after StartOS() 
  Call is only allowed by trusted applications 
Table 6: Function osCheckAndRefreshMPU 
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                44 / 57 
 

Technical Reference MICROSAR OS RH850 
10  Non-Trusted Functions (SC3 and SC4) 
Non-trusted functions are a VECTOR extension to the AUTOSAR OS specification. This concept 
allows  non-trusted  applications to provide  interface functions  which might  be  called  by  trusted  or 
non-trusted tasks and ISRs. 
10.1  Functionality 
Non-trusted functions can be used to provide service functions by non-trusted applications. Non-
trusted functions are called with memory access rights and service protection rights of the owner 
application, independent from the access rights of the caller. These functions can access local data 
of the owner application without the possibility to overwrite data of other applications. 
The  caller  might  be  a  task  of  a  trusted  application  with  global  memory  access,  developed 
according to high safety standards. The called non-trusted function might be developed according 
to lower standards but is not able to access any other memory than limited accessible memory of 
the  non-trusted  owner  application.  During  the  call,  the  non-trusted  function  is  executed  on  a 
separate stack, isolated from the caller stack by the MPU. 
2015, Vector Informatik GmbH 
Version: 1.09                                45 / 57 
 


Technical Reference MICROSAR OS RH850 
10.2  API 
Prototype 
StatusType osCallNonTrustedFunction(NonTrustedFunctionIndexType FunctionIndex, 
NonTrustedFunctionParameterRefType FunctionParams); 
Parameter 
FunctionIndex 
Index of the function to be called. 
FunctionParams 
Pointer to the parameters for the function to be called. If no parameters are provided, 
a NULL pointer has to be passed. 
Return code 
E_OK 
No error 
E_OS_SERVICEID  No function defined for this index 
Functional Description 
Executes the non-trusted function referenced by FunctionIndex and passes argument FunctionParams. 
The non-trusted function must conform to the following C prototype: 
void NONTRUSTED_<name of the non-trusted function(NonTrustedFunctionIndexType, 
NonTrustedFunctionParameterRefType); 
The arguments are the same as the arguments of CallNonTrustedFunction. 
Particularities and Limitations 
>  The non-trusted function is called in user mode with memory protection enabled 
>  The function has memory access rights of the owner application 
>  The function has the service protection rights of the owner application 
Call context 
>  Task, CAT2 ISR, trusted function, non-trusted function 
Table 7 API CallNonTrustedFunction 
 
 
 
Note 
Vector MICROSAR OS implementations offer the possibility of stub function generation 
  for trusted functions. This mechanism is not available for non-trusted functions. 
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                46 / 57 
 

Technical Reference MICROSAR OS RH850 
10.3  Call Context 
The following table shows the API functions callable from non-trusted functions. 
API Functions 
Call allowed 
API Functions 
Call allowed 
ActivateTask 

GetTaskID 

TerminateTask 
DC 
GetTaskState 

ChainTask 
DC 
StartOS 

Schedule 
DC 
ShutdownOS 

DisableAllInterrupts 

GetApplicationID 

EnableAllInterrupts 

GetActiveApplicationMode 

SuspendAllInterrupts 

GetISRID 

ResumeAllInterrupts 

CallTrustedFunction 

SuspendOSInterrupts 

CallNonTrustedFunction 

ResumeOSInterrupts 

CheckObjectAccess 

GetResource 

CheckObjectOwnership 

ReleaseResource 

StartScheduleTableRel 

SetEvent 

StartScheduleTableAbs 

ClearEvent 
DC 
StopScheduleTable 

GetEvent 

NextScheduleTable 

WaitEvent 
DC 
StartScheduleTableSynchron 

GetAlarm 

SyncScheduleTable 

SetRelAlarm 

GetScheduleTableStatus 

SetAbsAlarm 

SetScheduleTableAsync 

CancelAlarm 

IncrementCounter 

 
Abbreviations: 
 
X: 
Allowed 
 
DC:  Dependent on caller. Allowed if called from task, not allowed from ISR 
  P: 
Pairwise,  when  interrupts  are  disabled  within  the  (trusted/non-trusted)  function, 
they need to be re-enabled within the same function 
2015, Vector Informatik GmbH 
Version: 1.09                                47 / 57 
 

Technical Reference MICROSAR OS RH850 
10.3.1  Example 
Non-trusted functions have to be defined and called as followed: 
 
Example for calling a non-trusted function (configured function name = MyNTF used as index 
number): 
 
TASK(Task1) 
{   
   MyNTFParametersStruct callArg; 
   callArg.a = 2; 
   CallNonTrustedFunction( MyNTF, (NonTrustedFunctionParameterRefType) 
(&callArg)); 

 
Definition and prototype of the non-trusted function must have the prefix NONTRUSTED_ 
 
void NONTRUSTED_MyNTF (NonTrustedFunctionIndexType idx, 
NonTrustedFunctionParameterRefType  param) 

    if( ((MyNTFParametersStruct *) param)->a == 2) 
    { 
         /* do something */ 
    }  

 
 
The non-trusted function parameters must be declared via typedef struct: 
 
typedef struct 

     unsigned char a; 
} MyNTFParametersStruct; 
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                48 / 57 
 


Technical Reference MICROSAR OS RH850 
11  Multicore 
This OS implements the Autosar OS Multi Core feature according to Autosar specification 
4.0.3. 
11.1  Configuration 
Each application has to be assigned to a core. This is done with the application attribute 
“CORE”. 
Since each configuration object has to be assigned to an application the core assignment 
of the object is implicitly done with the application assignment. 
 
11.1.1  Core IDs 
The  physical  core  ID  which  is  provided  in  hardware  register  HTCFG0  differs  from  the 
logical core ID used by the OS internally, which is returned by GetCoreID(). 
 
CPU1 (PE1)  CPU2 (PE2) 
Physical core ID 


Logical core ID 


Table 8: Mapping of physical and logical core ID 
 
11.2  Multi-Core start-up 
As immediately after reset both cores begin execution, the master-slave startup behavior is 
emulated  in  software.  Therefore,  a  handshake  synchronization  is  performed  by  calling 
osInitMultiCoreOS()  on  PE1  and  calling  osInitSlaveCore()  on  PE2.  It  is  not 
allowed to use any other API function before this initial synchronization step is done. 
By calling osInitMultiCoreOS() PE1 initializes the multi-core OS related variables and 
synchronizes with PE2. By calling osInitSlaveCore() PE2 synchronizes with PE1 and 
resides  in  a  busy  waiting  state,  until  it  is  started  by  StartCore()  or 
StartNonAutosarCore(). If only PE2 should be controlled by the OS, then PE2 has to 
call osInitMultiCoreOS() after osInitSlaveCore(). 
 
 
Caution 
The hardware register OSTM0_CMP  is used for synchronization purpose. 
  Therefore, OSTM0_CMP must not be modified before initial synchronization. 
 
 
 The following chapters provide code examples for the multi-core startup. 
2015, Vector Informatik GmbH 
Version: 1.09                                49 / 57 
 

Technical Reference MICROSAR OS RH850 
11.2.1  Both PEs controlled by OS 
void main() 

 
[…] 
 
switch(GetCoreID()) 
 

 
 
case OS_CORE_ID_0: 
 
 
 
[…] 
 
 
 
osInitMultiCoreOS(); 
 
 
 
StartCore(OS_CORE_ID_1); 
 
 
 
StartOS(OSDEFAULTAPPMODE); 
 
 
 
break
 
 
case OS_CORE_ID_1: 
 
 
 
[…] 
 
 
 
osInitSlaveCore(); 
 
 
 
StartOS(OSDEFAULTAPPMODE); 
 
 
 
break
 
 
default
 
 
 
[…] 
 
 
 
break
 

 
[…] 

 
11.2.2  Only PE1 controlled by OS 
void main() 

 
[…] 
 
switch(GetCoreID()) 
 

 
 
case OS_CORE_ID_0: 
 
 
 
[…] 
 
 
 
osInitMultiCoreOS(); 
 
 
 
StartNonAutosarCore(OS_CORE_ID_1);    /* may be called later */ 
 
 
 
StartOS(OSDEFAULTAPPMODE); 
 
 
 
break
 
 
case OS_CORE_ID_1: 
 
 
 
[…] 
 
 
 
osInitSlaveCore(); 
 
 
 
[…] 
 
 
 
break
 
 
default
 
 
 
[…] 
 
 
 
break
 

 
[…] 

 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                50 / 57 
 

Technical Reference MICROSAR OS RH850 
11.2.3  Only PE2 controlled by OS 
void main() 

 
[…] 
 
switch(GetCoreID()) 
 

 
 
case OS_CORE_ID_0: 
 
 
 
[…] 
 
 
 
osInitMultiCoreOS(); 
 
 
 
StartCore(OS_CORE_ID_1); 
 
 
 
[…] 
 
 
 
break
 
 
case OS_CORE_ID_1: 
 
 
 
[…] 
 
 
 
osInitSlaveCore(); 
 
 
 
osInitMultiCoreOS(); 
 
 
 
StartNonAutosarCore(OS_CORE_ID_0);    /* adjusts the state of PE1*/ 
 
 
 
StartOS(OSDEFAULTAPPMODE); 
 
 
 
break
 
 
default
 
 
 
[…] 
 
 
 
break
 

 
[…] 

 
2015, Vector Informatik GmbH 
Version: 1.09                                51 / 57 
 

Technical Reference MICROSAR OS RH850 
12  Timing Protection (SC4) 
MICROSAR OS RH850 SC4 provides timing protection by using timer unit TAUJ0: 
TAUJ0  timer channel 0 is used for inter arrival time monitoring. 
TAUJ0 timer channel 1 is used for execution time monitoring. 
TAUJ0 timer channel 2 is used for blocking time monitoring. 
TAUJ0 timer channel 3 is not used and therefore disabled. 
TAUJ0 timer channels 0, 1 and 2 are initialized with interrupt priority level 0. 
 
12.1  Configuration Attributes 
The common SC4 attributes are described in the general MICROSAR OS manual. 
RH850 specific SC4 attributes 
OS attribute TimingProtectionTimerClock must be specified in [kHz] by user:  
Example: If the peripheral clock of TAUJ0 is 20 MHz then set 
TimingProtectionTimerClock = 20000 
 
12.2  Restrictions for SC4 Configurations 
MICROSAR OS RH850 has the following restrictions for SC configurations: 
 
It is not allowed to use category 1 ISRs 
 
It is not allowed to configure category 2 ISRs with priority level 0 
 
It is not allowed to modify any register of unit TAUJ0 after calling StartOS 
 
 
 
2015, Vector Informatik GmbH 
Version: 1.09                                52 / 57 
 

Technical Reference MICROSAR OS RH850 
13  Error Handling 
13.1  MICROSAR OS RH850 Error Numbers 
In  addition  to  the  AUTOSAR  OS  error  numbers  all  MICROSAR  OS  implementations 
provide unique error numbers for an exact error description. All error numbers are defined 
as  a  16  bit  value.  The  error  numbers  are  defined  in  the  header  file  osekerr.h  and  are 
defined according to the following syntax: 
0xgfee 
  ||+--- consecutive error number 
  |+---- number of function in the function group 
  +----- number of function group  
 
Error numbers common for all MICROSAR OS implementations are described in [3].  
 
13.1.1  RH850 specific Error Numbers 
The RH850 implementation specific error numbers have a function group number starting 
at 0xA101 and are described in the following table: 
Name 
Error 
Type 
Reason 
osdErrYOSystemStackOverflow 
0xA101  SysCheck  system stack overflow is detected 
osdErrYOTaskStackOverflow 
0xA102  SysCheck  task stack overflow is detected 
osdErrYOISRStackOverflow 
0xA103  SysCheck  ISR stack overflow is detected 
osdErrSCWrongSysCallParameter 
0xA201  SysCheck  invalid syscall parameter is  used 
osdErrDPStartValidContext    
0xA401  SysCheck  new task is started with valid 
context 
osdErrDPResumeInvalidContext 
0xA402  SysCheck  preempted task is resumed with 
invalid context 
osdErrDPInvalidTaskIndex 
0xA403  SysCheck  invalid active task index 
osdErrDPInvalidApplicationID 
0xA404  SysCheck  invalid active application ID 
osdErrEXMemoryViolation         
0xA501  SysCheck  memory protection violation  
osdErrEXPrivilegedInstruction                0xA502  SysCheck  privileged instruction violation 
osdErrSUInvalidTaskIndex 
0xA601  SysCheck  invalid task index used in 
osGetStackUsage 
osdErrSUInvalidIsrIndex 
0xA602  SysCheck  invalid ISR index used in 
osGetISRStackUsage 
osdErrSUInvalidIsrPrioLevel 
0xA603  SysCheck  invalid ISR priority level used in 
osGetISRStackUsage 
osdErrCIInvalidIsrIndex 
0xA701  SysCheck  CAT2 ISR wrapper called with 
invalid ISR ID 
osdErrCIInvalidIsrPrioLevel 
0xA702  SysCheck  invalid ISR priority level used in 
CAT2 ISR wrapper 
osdErrCIInvalidApplicationID 
0xA703  SysCheck  invalid application ID used in 
CAT2 ISR wrapper 
2015, Vector Informatik GmbH 
Version: 1.09                                53 / 57 
 

Technical Reference MICROSAR OS RH850 
Name 
Error 
Type 
Reason 
osdErrCIMissingIntRequest 
0xA704  SysCheck  Missing interrupt request 
osdErrCIInterruptIsMasked 
0xA705  SysCheck  Interrupt is masked 
osdErrCIWrongIntPriority 
0xA706  SysCheck  Wrong interrupt priority 
osdErrPIGetIMRInvalidIndex 
0xA801  SysCheck  invalid IMR index used in 
osGetIMR 
osdErrPISetIMRInvalidIndex   
0xA802  SysCheck  invalid IMR index used in 
osSetIMR 
osdErrPIClearIMRInvalidIndex 
0xA803  SysCheck  invalid IMR index used in 
osClearIMR 
osdErrPIWriteIMR8InvalidAddr    
0xA804  SysCheck  invalid IMR address used in 
 
osWriteIMR8 
osdErrPIWriteIMR16InvalidAddr   
0xA805  SysCheck  invalid IMR address used in 
 
osWriteIMR16 
osdErrPIWriteIMR32InvalidAddr 
0xA806  SysCheck  invalid IMR address used in 
osWriteIMR32 
osdErrPISetICRMaskInvalidAddr 
0xA807  SysCheck  invalid ICR address used in 
osSetICRMask 
osdErrPIClearICRMaskInvalidAddr 
0xA808  SysCheck  invalid ICR address used in 
osClearICRMask 
osdErrPISetICRReqInvalidAddr 
0xA809  SysCheck  invalid ICR address used in 
osSetICRReq 
osdErrPIClearICRReqInvalidAddr 
0xA80A  SysCheck  invalid ICR address used in 
osClearICRReq 
osdErrPIWriteICR8InvalidAddr 
0xA80B  SysCheck  invalid ICR address used in 
osWriteICR8 
osdErrPIWriteICR16InvalidAddr   
0xA80C  SysCheck  invalid ICR address used in 
osWriteICR16 
osdErrPIWriteICRxLoInvalidIndex 
0xA80D  SysCheck  invalid ICR index used in 
osWriteICRxLo 
osdErrPIWriteICRxHiInvalidIndex 
0xA80E  SysCheck  invalid ICR index used in 
osWriteICRxHi 
osdErrPIWriteICRx16InvalidIndex 
0xA80F  SysCheck  invalid ICR index used in 
osWriteICRx16 
osdErrCRInvalidSettingOSTM 
0xA901  SysCheck  invalid register content found in 
osCheckAndRefreshTimer 
osdErrCRInvalidSettingMPU 
0xA902  SysCheck  invalid register content found in 
osCheckAndRefreshMPU 
osdErrUEUnhandledCoreException 
0xAA01  SysCheck  unhandled core exception 
occurred 
osdErrUEUnhandledDirectBranch 
0xAA02  SysCheck  unhandled direct branch 
exception occurred 
Table 9  
RH850 specific Error Numbers 
2015, Vector Informatik GmbH 
Version: 1.09                                54 / 57 
 

Technical Reference MICROSAR OS RH850 
14  Modules 
MICROSAR OS RH850 source and header files depend on the scalability class:  
14.1  Source Files 
Module Name 
Description 
SC1 
SC3 
SC4 
atosappl.c 
Memory protection related functions 
 
 
 
atostime.c 
Schedule table related functions 
 
 
 
atosTProt.c 
Timing protection related functions 
 
 
● 
osek.c 
System initialisation, scheduler, interrupt control 
 
 
 
osekalrm.c 
Alarm related functions 
 
 
 
osekasm.c 
Compiler specific assembler functions and syscalls 
 
 
 
osekerr.c 
Error handling 
 
 
 
osekevnt.c 
Event handling 
 
 
 
osekrsrc.c 
Resource handling 
 
 
 
oseksched.c 
Schedule table related functions 
 
 
 
osekstart.c 
OS start-up related functions 
 
 
 
osektask.c 
Task management 
 
 
 
osektime.c 
Timer interrupt routine and alarm management 
 
 
 
osSysCall.c 
Compiler specific syscall table 
 
 
 
osOstmHiRes.c 
Timer specific functions 
 
● 
● 
osMultiCore.c 
Multicore related functions 
MC 1 
 
 
Table 10  
List of source files 
                                            
1 Only for multi core systems 
2015, Vector Informatik GmbH 
Version: 1.09                                55 / 57 
 

Technical Reference MICROSAR OS RH850 
14.2  Header Files 
Module Name 
Description 
SC1  SC3  SC4 
Os.h 
This header has to be included by the application 
 
 
 
Included by Os.h, includes the Autosar Header files if 
Os_Cfg.h 
 
 
 
selected by the attribute TypeHeaderInclude 
osek.h 
Included by Os_cfg.h, basic OS header 
 
 
 
osekasm.h 
Compiler specific header for assembler code 
 
 
 
Included by osek.h, macro-definitions for assertion-
osekasrt.h 
 
 
 
handling 
osekcov.h 
Coverage macros 
 
 
 
osekerr.h 
Included by osek.h, definitions of all error-numbers 
 
 
 
osekext.h 
Header file for OS internal functions 
 
 
 
oseksched.h 
Header for schedule table related functions 
 
 
 
emptymac.h 
Empty API hook macros 
 
 
 
User API hook macros (contains macros for ORTI 
testmac1.h 
 
 
 
debug support) 
User API hook macros (contains macros for ORTI 
testmac3.h 
 
 
 
debug support) 
testmac4.h 
User API hook macros (contains macros for ORTI 
 
 
 
debug support) 
Included by all headers and system modules, Vector 
vrm.h 
 
 
 
release management 
Linker specific symbols for the syscall table. This file 
osSysCallTable.dld 
 
 
 
must be included into the global project linker file. 
File for including the necessary derivative dependent 
osDerivatives.h 
● 
● 
● 
header. 
osRH850_D1L.h 
RH850 D1L specific header file. 
● 
● 
● 
osRH850_D1M.h 
RH850 D1M specific header file. 
● 
● 
● 
osRH850_E1L.h 
RH850 E1L specific header file. 
● 
● 
 
osRH850_E1M.h 
RH850 E1M specific header file. 
● 
● 
 
osRH850_F1H.h 
RH850 F1H specific header file. 
● 
● 
● 
osRH850_F1L.h 
RH850 F1L specific header file. 
● 
● 
● 
osRH850_F1M.h 
RH850 F1M specific header file. 
● 
● 
● 
osRH850_P1M.h 
RH850 P1M specific header file. 
● 
● 
● 
osINTC2.h 
Contains specific code for the interrupt controller. 
● 
● 
● 
osMultiCore.h 
Header for multicore related functions 
MC 
 
 
Table 11  
List of header files 
2015, Vector Informatik GmbH 
Version: 1.09                                56 / 57 
 

Technical Reference MICROSAR OS RH850 
15  Contact 
Visit our website for more information on 
 
  News 
  Products 
  Demo software 
  Support 
  Training data 
  Addresses 
 
www.vector.com 
 
In case of OSEK / MICROSAR OS related problems you may write an email to 
osek-support@vector.com 
2015, Vector Informatik GmbH 
Version: 1.09                                57 / 57 
 

Document Outline


13 - TechnicalReference_Os

YourTopic

15 - TechnicalReference_Oss


 
 
 
 
 
 
 
 
 
 
 
 
 
MICROSAR OS SafeContext 
Technical Reference 
 
 
Version 9.01 
 
 
 
 
 
 
 
 
 
Status 
Released 
Document ID 
OS01.0280 
 
 
 
 
 


Technical Reference MICROSAR OS SafeContext  
 
Document Information 
History 
Author 
Date 
Version 
Remarks 
Rmk 
2012-06-26 
6.00 
creation based on AUTOSAR 3.0 version 
Shk 
2013-09-18 
6.01 
SingleSource template applied and 
variants for ASR3.x, ASR4.x, SafeContext 
and non-SafeContext prepared 
Biv 
2014-02-04 
6.02 
MultiCore references corrected 
Zfa 
2014-05-05 
6.03 
Updated timer description 
Asl 
2014-08-14 
8.00 
Examples chapter excluded 
TimingAnalyzer removed 
Updated counter related macros and 
configuration  
Asl 
2014-10-16 
8.01 
Added PeripheralRegion API 
Added Non-Trusted Function API 
Added CheckMPUAccess API 
Asl 
2015-01-29 
9.00 
Updated interpretation of 
OsSecondsPerTick and 
OsCounterTicksPerBase 
Rk 
2015-06-17 
9.01 
Added MICROSAR OS Timing Hooks 
Added table of terms to the glossary 
Added the information that forcible 
termination is currently not supported 
 
2015, Vector Informatik GmbH 
Version: 9.01 
2 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Reference Documents 
No. 
Title 
Version 
[1]   AUTOSAR_SWS_OS.pdf 
V5.0.0 
AUTOSAR OS specification; This document is available in PDF-format on the 
internet a the AUTOSAR homepage (http://www.autosar.org) 
[2]   AUTOSAR_TR_BSWModuleList.pdf 
1.6.0 
[3]   OSEK/VDX Operating System Specification 
2.2.3 
This document is available in PDF-format on the Internet at the OSEK/VDX 
homepage (http://www.osek-vdx.org) 
[4]   TechincalReference_Microsar_Os_Multicore.pdf 
1.00 
[5]   TechnicalReference_MicrosarOS_xxxx.pdf 
-- 
Technical reference of Vector MICROSAR OS; Hardware specific part 
[6]   OIL: OSEK Implementation Language 
2.3 
This document is available in PDF-format on the Internet at the OSEK/VDX 
homepage (http://www.osek-vdx.org) 
[7]   Tutorial_osCAN.pdf 
1.00 
Tutorial for the MICROSAR OS OSEK/AUTOSAR Realtime Operating System 
[8]   autosar.xsd 
4.0.3 
AUTOSAR XML schema 
[9]   MicrosarOS_xxxx_SafeContext_SafetyManual.pdf 
-- 
Application Conditions for SEooC; Implementation specific document 
Scope of the Document 
MICROSAR  OS  is  an  operating  system,  compliant  with  the  AUTOSAR  OS  and  OSEK 
standards. The  general  aspects  of  all  SafeContext  implementations  are  described  in  this 
document. For each implementation, the hardware specific part is described in a separate 
document [4]. 
The implementation is based on the AUTOSAR OS specification [1]. 
It is also based on the OSEK OS specification 2.2 described in the document [3]. 
As a SEooC, it is further based on assumptions regarding safety requirements. Details can 
be found in [9]. 
This  documentation  assumes  that  the  reader  is  familiar  with  both  the  OSEK  OS 
specification and the AUTOSAR OS specification. 
This documentation describes only the operating system and the code generation tool. 
OSEK  is  a  registered  trademark  of  Continental  Automotive  GmbH  (until  2007:  Siemens 
AG). 
2015, Vector Informatik GmbH 
Version: 9.01 
3 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
 
 
 
Caution 
We have configured the programs in accordance with your specifications in the 
  questionnaire. Whereas the programs do support other configurations than the one 
specified in your questionnaire, Vector´s release of the programs delivered to your 
company is expressly restricted to the configuration you have specified in the 
questionnaire. 
 
 
 
2015, Vector Informatik GmbH 
Version: 9.01 
4 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Contents 
1  Component History ...................................................................................................... 14 
2  Introduction .................................................................................................................. 15 
2.1 
Architecture Overview ................................................................................... 15 
3  Functional Description ................................................................................................ 17 
3.1 
Features ........................................................................................................ 17 
3.2 
Main Functions .............................................................................................. 17 
3.2.1 
Timer and Alarms .......................................................................................... 18 
3.2.1.1 
Time Base ..................................................................................................... 19 
3.2.1.1.1  Counter Macros ............................................................................................. 19 
3.2.1.1.2  Temporal Range of Alarms ............................................................................ 19 
3.2.1.2 
Timer Interrupt Routine .................................................................................. 19 
3.2.1.2.1  Counter API ................................................................................................... 19 
3.2.2 
Stack Handling .............................................................................................. 20 
3.2.2.1 
Task Stack ..................................................................................................... 20 
3.2.2.2 
Interrupt Stack ............................................................................................... 20 
3.2.2.3 
Stack Monitoring ............................................................................................ 21 
3.2.2.4 
Stack Usage .................................................................................................. 21 
3.2.3 
Interrupt Handling .......................................................................................... 21 
3.2.3.1 
Interrupt Categories....................................................................................... 22 
3.2.3.1.1  Category 1: ................................................................................................... 22 
3.2.3.1.2  Category 2: ................................................................................................... 22 
3.2.3.2 
Usage of the Interrupt API before StartOS ..................................................... 23 
3.2.4 
Timing Protection .......................................................................................... 24 
3.2.4.1 
Reaction on Protection Failure ...................................................................... 24 
3.2.4.2 
Timing Measurement ..................................................................................... 24 
3.2.4.2.1  Timing measurement configuration for a specific task/ISR ............................ 25 
3.2.4.2.2  Global configuration of timing measurement ................................................. 25 
3.2.4.3 
Hook functions .............................................................................................. 26 
3.2.5 
Memory Protection ........................................................................................ 26 
3.2.6 
Schedule Tables ............................................................................................ 27 
3.2.6.1 
Synchronization ............................................................................................. 27 
3.2.6.1.1  Starting a synchronizable Schedule Table ..................................................... 27 
3.2.6.1.2  Autostart ........................................................................................................ 27 
3.2.6.1.3  Suspending a Schedule Table and keeping its Synchronization .................... 28 
3.2.6.1.4  Providing a Global Time ................................................................................ 28 
3.2.6.1.5  Exact Synchronization ................................................................................... 28 
2015, Vector Informatik GmbH 
Version: 9.01 
5 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
3.2.6.1.6  Limits of the Synchronization Algorithm ......................................................... 29 
3.2.6.1.7  Details about using NextScheduleTable ........................................................ 30 
3.2.6.1.8  Concurrent Actions ........................................................................................ 30 
3.2.6.2 
High-Resolution Schedule Tables .................................................................. 30 
3.2.6.2.1  Setup ............................................................................................................ 31 
3.2.6.3 
Cyclical Expiry Point Actions ......................................................................... 31 
3.2.7 
Trusted Functions .......................................................................................... 31 
3.2.7.1 
Generated Stub Functions ............................................................................. 31 
3.3 
Error Handling ............................................................................................... 33 
3.3.1 
Error Messages ............................................................................................. 33 
3.3.2 
OSEK / AUTOSAR OS Error Numbers .......................................................... 33 
3.3.3 
MICROSAR OS Error Numbers .................................................................... 34 
3.3.3.1 
Error Numbers of Group Task Management / (1) ........................................... 35 
3.3.3.2 
Error Numbers of Group Interrupt Handling / (2) ............................................ 37 
3.3.3.3 
Error Numbers of Group Resource Management / (3) ................................... 39 
3.3.3.4 
Error Numbers of Group Event Control / (4) .................................................. 40 
3.3.3.5 
Error Numbers of Group Alarm Management / (5) ......................................... 42 
3.3.3.6 
Error Numbers of Group Operating System Execution Control / (6) ............... 44 
3.3.3.7 
Error Numbers of Schedule Table Control / (7) .............................................. 46 
3.3.3.8 
Error Numbers of Group Counter API / (8) ..................................................... 49 
3.3.3.9 
Error Numbers of Group Timing Protection and Timing Measurement / (9) .... 51 
3.3.3.10  Platform specific error codes (A) ................................................................... 53 
3.3.3.11  Error Numbers of Group Application API (B) .................................................. 53 
3.3.3.12  Error Numbers of Group Semaphores (C) ..................................................... 54 
3.3.3.13  Error Numbers of Group MultiCore related functions (D) ............................... 55 
3.3.3.14  Error Numbers of Group (Non-)TrustedFunctions (E) .................................... 55 
3.3.3.15  Error Numbers of Group IOC (F) ................................................................... 56 
3.3.4 
Reactions on Error Situations ........................................................................ 56 
4  Installation .................................................................................................................... 57 
4.1 
Installation Requirements .............................................................................. 57 
4.2 
Installation Disk ............................................................................................. 57 
4.3 
OIL Configurator ............................................................................................ 58 
4.3.1 
INI Files of the OIL Tool ................................................................................. 58 
4.3.2 
OIL Implementation Files ............................................................................... 58 
4.3.3 
Code Generator ............................................................................................ 58 
4.4 
OSEK Operating System ............................................................................... 58 
4.4.1 
Installation Paths ........................................................................................... 58 
4.5 
XML Configurations ....................................................................................... 59 
4.5.1 
Parameter Definition Files ............................................................................. 59 
2015, Vector Informatik GmbH 
Version: 9.01 
6 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
5  Integration .................................................................................................................... 60 
5.1 
Scope of Delivery .......................................................................................... 60 
5.1.1 
Static Files ..................................................................................................... 60 
5.1.2 
Dynamic Files................................................................................................ 60 
5.1.2.1 
Code Generator GENxxxx ............................................................................. 60 
5.1.2.1.1  Generated file libconf .................................................................................... 60 
5.1.2.2 
Application Template Generator GENTMPL .................................................. 61 
5.2 
Include Structure ........................................................................................... 61 
6  API Description ............................................................................................................ 62 
6.1 
Standard API - Overview ............................................................................... 62 
6.2 
API Functions defined by Vector - Overview .................................................. 65 
6.3 
Timing Measurement API .............................................................................. 66 
6.3.1 
GetTaskMaxExecutionTime ........................................................................... 66 
6.3.2 
GetISRMaxExecutionTime ............................................................................ 67 
6.3.3 
GetTaskMaxBlockingTime ............................................................................. 67 
6.3.4 
GetISRMaxBlockingTime .............................................................................. 68 
6.3.5 
GetTaskMinInterArrivalTime .......................................................................... 69 
6.3.6 
GetISRMinInterArrivalTime ............................................................................ 70 
6.4 
Implementation specific Behavior .................................................................. 70 
6.4.1 
Interrupt Handling .......................................................................................... 70 
6.4.1.1 
EnableAllInterrupts ........................................................................................ 71 
6.4.1.2 
DisableAllInterrupts ....................................................................................... 72 
6.4.1.3 
ResumeAllInterrupts ...................................................................................... 72 
6.4.1.4 
SuspendAllInterrupts ..................................................................................... 73 
6.4.1.5 
ResumeOSInterrupts ..................................................................................... 74 
6.4.1.6 
SuspendOSInterrupts .................................................................................... 75 
6.4.2 
Resource Management ................................................................................. 76 
6.4.2.1 
GetResource ................................................................................................. 76 
6.4.2.2 
ReleaseResource .......................................................................................... 77 
6.4.3 
Execution Control .......................................................................................... 78 
6.4.3.1 
StartOS ......................................................................................................... 78 
6.4.3.2 
ShutdownOS ................................................................................................. 79 
6.5 
Hook Routines ............................................................................................... 80 
6.5.1 
Standard Hooks ............................................................................................. 80 
6.5.1.1 
StartupHook .................................................................................................. 80 
6.5.1.2 
PreTaskHook ................................................................................................. 81 
6.5.1.3 
PostTaskHook ............................................................................................... 81 
6.5.1.4 
ErrorHook ...................................................................................................... 82 
6.5.1.5 
ShutdownHook .............................................................................................. 82 
6.5.1.6 
ProtectionHook .............................................................................................. 83 
2015, Vector Informatik GmbH 
Version: 9.01 
7 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
6.5.2 
ISR Hooks ..................................................................................................... 83 
6.5.2.1 
UserPreISRHook ........................................................................................... 83 
6.5.2.2 
UserPostISRHook ......................................................................................... 84 
6.5.3 
Alarm Hook ................................................................................................... 85 
6.5.3.1 
PreAlarmHook (currently not supported) ....................................................... 85 
6.5.4 
MICROSAR OS Timing Hooks ...................................................................... 85 
6.5.4.1 
Hooks for arrival ............................................................................................ 86 
6.5.4.1.1  OS_VTH_ACTIVATION ................................................................................. 86 
6.5.4.1.2  OS_VTH_SETEVENT ................................................................................... 86 
6.5.4.1.3  OS_VTH_TRANSFER_SEMA ....................................................................... 87 
6.5.4.2 
Hook for context switch ................................................................................. 88 
6.5.4.2.1  OS_VTH_SCHEDULE .................................................................................. 88 
6.5.4.3 
Hooks for locking ........................................................................................... 89 
6.5.4.3.1  OS_VTH_GOT_RES ..................................................................................... 89 
6.5.4.3.2  OS_VTH_REL_RES...................................................................................... 90 
6.5.4.3.3  OS_VTH_REQ_SPINLOCK .......................................................................... 90 
6.5.4.3.4  OS_VTH_GOT_SPINLOCK .......................................................................... 91 
6.5.4.3.5  OS_VTH_REL_SPINLOCK ........................................................................... 92 
6.5.4.3.6  OS_VTH_TOOK_SEMA ................................................................................ 93 
6.5.4.3.7  OS_VTH_REL_SEMA ................................................................................... 93 
6.5.4.3.8  OS_VTH_DISABLEDINT .............................................................................. 94 
6.5.4.3.9  OS_VTH_ENABLEDINT ............................................................................... 95 
6.6 
Non-Trusted Functions .................................................................................. 95 
6.6.1 
Functionality .................................................................................................. 95 
6.6.2 
API ................................................................................................................ 96 
6.7 
MPU Access Checking API............................................................................ 96 
6.8 
Peripheral Regions ........................................................................................ 97 
6.8.1 
Reading functions ......................................................................................... 97 
6.8.2 
Writing functions ............................................................................................ 98 
6.8.3 
Modifying functions ....................................................................................... 99 
7  Configuration.............................................................................................................. 100 
7.1 
Configuration and generation process ......................................................... 100 
7.1.1 
XML Configuration ....................................................................................... 100 
7.1.2 
OIL Configurator .......................................................................................... 101 
7.2 
Configuration Variants ................................................................................. 101 
7.3 
Configuration of the XML / OIL Attributes ..................................................... 101 
7.3.1 
OS ............................................................................................................... 102 
7.3.1.1 
ProtectionHookReaction / OsOSProtectionHookReaction ........................... 105 
7.3.1.2 
TimingMeasurement / OsOSTimingMeasurement ....................................... 106 
7.3.1.3 
PeripheralRegion / OsOSPeripheralRegion ................................................. 107 
2015, Vector Informatik GmbH 
Version: 9.01 
8 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
7.3.2 
Task ............................................................................................................ 107 
7.3.2.1 
AUTOSTART / OsTaskAutostart .................................................................. 109 
7.3.2.2 
TIMING_PROTECTION / OsTaskTimingProtection ..................................... 109 
7.3.2.3 
Task attributes concerning the timing analyzer ............................................ 110 
7.3.3 
Counter ........................................................................................................ 111 
7.3.4 
Alarm .......................................................................................................... 112 
7.3.4.1 
ACTION / OsAlarmAction ............................................................................ 113 
7.3.4.2 
AUTOSTART / OsAlarmAutostart ................................................................ 114 
7.3.5 
Resource ..................................................................................................... 115 
7.3.6 
Event ........................................................................................................... 116 
7.3.7 
ISR .............................................................................................................. 116 
7.3.7.1 
UseSpecialFunctionName / OsIsrUseSpecialFunctionName ....................... 117 
7.3.7.2 
TIMING_PROTECTION / OsIsrTimingProtection ......................................... 118 
7.3.7.2.1  LOCKINGTIME / OsIsrResourceLock ......................................................... 119 
7.3.7.3 
ISR Attributes concerning the Timing Analyzer ............................................ 119 
7.3.8 
COM ........................................................................................................... 120 
7.3.9 
NM .............................................................................................................. 120 
7.3.10 
APPMODE / OsAppMode............................................................................ 120 
7.3.11 
Application / OsApplication .......................................................................... 121 
7.3.11.1  Trusted Functions ........................................................................................ 122 
7.3.12 
Scheduletable ............................................................................................. 123 
7.3.12.1  AUTOSTART / OsScheduleTableAutostart .................................................. 123 
7.3.12.2  EXPIRY_POINT / OsScheduleTableExpiryPoint .......................................... 124 
7.3.12.3  Expiry point action ADJUST ........................................................................ 125 
7.3.12.4  Expiry point action ACTIVATETASK ............................................................ 125 
7.3.12.5  Expiry point action SETEVENT ................................................................... 126 
7.3.12.6  LOCAL_TO_GLOBAL_TIME_SYNCHRONIZATION / 
OsScheduleTableSync ................................................................................ 126 
8  System Generation .................................................................................................... 128 
8.1 
Code Generator .......................................................................................... 128 
8.1.1 
Generated Files ........................................................................................... 128 
8.1.2 
Automatic Documentation ........................................................................... 128 
8.1.3 
Conditional Generation ................................................................................ 129 
8.1.4 
Generated files backup ............................................................................... 129 
8.2 
Application Template Generator .................................................................. 129 
8.3 
Compiler ...................................................................................................... 129 
8.3.1 
Include Paths .............................................................................................. 129 
9  AUTOSAR Standard Compliance .............................................................................. 130 
9.1 
Deviations ................................................................................................... 130 
2015, Vector Informatik GmbH 
Version: 9.01 
9 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
9.2 
Limitations ................................................................................................... 130 
9.2.1 
API Function OS_GetVersionInfo ................................................................ 130 
9.2.2 
Forcible Termination .................................................................................... 130 
9.2.3 
AUTOSAR Debug support ........................................................................... 130 
9.2.4 
Port Interface............................................................................................... 130 
9.2.5 
NULL Pointer Checks .................................................................................. 130 
9.2.6 
SafeContext specific limitations ................................................................... 130 
10  Debugging Support .................................................................................................... 132 
10.1 
Kernel aware Debugging ............................................................................. 132 
10.2 
Version and Variant Coding ......................................................................... 132 
11  Glossary and Abbreviations ...................................................................................... 134 
11.1 
Abbreviations .............................................................................................. 134 
11.2 
Terms .......................................................................................................... 135 
12  Contact ........................................................................................................................ 136 
 
2015, Vector Informatik GmbH 
Version: 9.01 
10 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Illustrations 
Figure 2-1 
AUTOSAR 3.x Architecture Overview ....................................................... 15 
Figure 2-2 
AUTOSAR architecture ............................................................................. 15 
Figure 3-1 
Functional parts ........................................................................................ 18 
Figure 3-2 
Counter Macros ........................................................................................ 19 
Figure 7-1 
System overview of software parts .......................................................... 100 
Figure 7-2 
Relation between Physical Units, Counter Units and Driver Units ........... 112 
 
Tables 
Table 3-1  
Supported SWS features .......................................................................... 17 
Table 3-2  
Not supported SWS features .................................................................... 17 
Table 3-3  
Interdependence between the OS attribute TimingMeasurement and 
the task/ISR attribute TIMING_PROTECTION ........................................... 26 

Table 3-4  
OSEK/AUTOSAR OS error numbers ........................................................ 33 
Table 3-5  
Implementation specific error numbers ..................................................... 34 
Table 3-6  
Error types ................................................................................................ 35 
Table 3-7  
API functions of group Task Management / (1) ......................................... 35 
Table 3-8  
Error numbers of group Task Management / (1) ........................................ 37 
Table 3-9  
API functions of group Interrupt Handling / (2) .......................................... 38 
Table 3-10  
Error numbers of group Interrupt Handling / (2) ........................................ 38 
Table 3-11  
API functions of group Resource Management / (3) ................................. 39 
Table 3-12  
Error numbers of group Resource Management / (3) ................................ 40 
Table 3-13  
API functions of group Event Control / (4) ................................................. 40 
Table 3-14  
Error numbers of group Event Control / (4) ............................................... 42 
Table 3-15  
API functions of group Alarm Management / (5) ........................................ 42 
Table 3-16  
Error numbers of group Alarm Management / (5) ...................................... 44 
Table 3-17  
API functions of group Operating System Execution Control / (6) ............. 44 
Table 3-18  
Error numbers of group Operating System Execution Control / (6) ........... 45 
Table 3-19  
API functions of group Schedule Table Control / (7) .................................. 46 
Table 3-20  
Error numbers of group Schedule Table Control / (7) ................................ 49 
Table 3-21  
API functions of group Counter API / (8) ................................................... 49 
Table 3-22  
Error numbers of group Counter API / (8) ................................................. 50 
Table 3-23  
API functions of group Timing Protection and Timing Measurement / (9) .. 51 
Table 3-24  
Error numbers of group Timing Protection and Timing Measurement / (9)  53 
Table 3-25  
API functions of group Application API / (B) .............................................. 53 
Table 3-26  
Error numbers of group Application API / (B)............................................. 54 
Table 3-27  
API functions of group Semaphores / (C) .................................................. 54 
Table 3-28  
Error numbers of group Semaphores / (C) ................................................ 55 
Table 3-29  
API functions of group (Non-)TrustedFunctions (E) ................................... 55 
Table 3-30  
Error numbers of group (Non-)TrustedFunctions (E) ................................. 56 
Table 4-1  
Installed components ................................................................................ 57 
Table 4-2  
System configuration and generation tools ............................................... 58 
Table 5-1  
Files generated by code generator GENxxxx ............................................ 60 
Table 5-2  
Variables generated into the file libconf ..................................................... 61 
Table 6-1  
Standard API functions ............................................................................. 65 
Table 6-2  
Vector API functions .................................................................................. 66 
Table 6-3  
GetTaskMaxExecutionTime ...................................................................... 67 
Table 6-4  
GetISRMaxExecutionTime ........................................................................ 67 
Table 6-5  
GetTaskMaxBlockingTime ........................................................................ 68 
Table 6-6  
GetISRMaxBlockingTime .......................................................................... 69 
2015, Vector Informatik GmbH 
Version: 9.01 
11 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Table 6-7  
GetTaskMinInterArrivalTime ...................................................................... 70 
Table 6-8  
GetISRMinInterArrivalTime ....................................................................... 70 
Table 6-9  
EnableAllInterrupts ................................................................................... 71 
Table 6-10  
DisableAllInterrupts ................................................................................... 72 
Table 6-11  
ResumeAllInterrupts ................................................................................. 73 
Table 6-12  
SuspendAllInterrupts ................................................................................ 74 
Table 6-13  
ResumeOSInterrupts ................................................................................ 75 
Table 6-14  
SuspendOSInterrupts ............................................................................... 76 
Table 6-15  
GetResource ............................................................................................ 77 
Table 6-16  
ReleaseResource ..................................................................................... 78 
Table 6-17  
StartOS ..................................................................................................... 79 
Table 6-18  
ShutdownOS ............................................................................................ 80 
Table 6-19  
StartupHook .............................................................................................. 80 
Table 6-20  
PreTaskHook ............................................................................................ 81 
Table 6-21  
PostTaskHook ........................................................................................... 81 
Table 6-22  
ErrorHook ................................................................................................. 82 
Table 6-23  
ShutdownHook ......................................................................................... 83 
Table 6-24  
ProtectionHook ......................................................................................... 83 
Table 6-25  
UserPreISRHook ...................................................................................... 84 
Table 6-26  
UserPostISRHook .................................................................................... 84 
Table 6-27  
PreAlarmHook .......................................................................................... 85 
Table 6-28  
OS_VTH_ACTIVATION ............................................................................ 86 
Table 6-29  
OS_VTH_SETEVENT .............................................................................. 87 
Table 6-30  
OS_VTH_TRANSFER_SEMA .................................................................. 88 
Table 6-31  
OS_VTH_SCHEDULE .............................................................................. 89 
Table 6-32  
OS_VTH_GOT_RES ................................................................................ 90 
Table 6-33  
OS_VTH_REL_RES ................................................................................. 90 
Table 6-34  
OS_VTH_REQ_SPINLOCK ...................................................................... 91 
Table 6-35  
OS_VTH_GOT_SPINLOCK ...................................................................... 92 
Table 6-36  
OS_VTH_REL_SPINLOCK ...................................................................... 92 
Table 6-37  
OS_VTH_TOOK_SEMA ........................................................................... 93 
Table 6-38  
OS_VTH_REL_SEMA .............................................................................. 94 
Table 6-39  
OS_VTH_DISABLEDINT .......................................................................... 95 
Table 6-40  
OS_VTH_ENABLEDINT ........................................................................... 95 
Table 6-41 API osCallNonTrustedFunction ........................................................................... 96 
Table 6-42  
osCheckMPUAccess API .......................................................................... 97 
Table 6-43  
ReadPeripheral API .................................................................................. 98 
Table 6-44  
WritePeripheral API .................................................................................. 99 
Table 6-45  
ModifyPeripheral API ................................................................................ 99 
Table 7-1  
OS attributes........................................................................................... 105 
Table 7-2  
Sub-attributes of ProtectionHookReaction = SELECTED ........................ 105 
Table 7-3  
Sub-attributes of TimingMeasurement = TRUE .................................... 107 
Table 7-4  
Sub-attributes of PeripheralRegion .................................................. 107 
Table 7-5  
Task attributes ........................................................................................ 109 
Table 7-6  
Sub-attributes of TASK->AUTOSTART=TRUE ......................................... 109 
Table 7-7  
Sub-attributes of TASK-> TIMING_PROTECTION=TRUE ......................... 110 
Table 7-8  
Task attributes concerning the timing analyzer ......................................... 111 
Table 7-9  
Attributes of COUNTER .......................................................................... 112 
Table 7-10  
Attributes of ALARM ............................................................................... 113 
Table 7-11  
Sub-attributes of ACTION = ACTIVATETASK .......................................... 114 
Table 7-12  
Sub-attributes of ACTION = SETEVENT ................................................ 114 
Table 7-13  
Sub-attributes of ACTION = ALARMCALLBACK ..................................... 114 
Table 7-14  
Sub-attributes of AUTOSTART = TRUE ................................................... 115 
2015, Vector Informatik GmbH 
Version: 9.01 
12 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Table 7-15  
Attributes of RESOURCE ....................................................................... 116 
Table 7-16  
Sub-attributes of EVENT ........................................................................ 116 
Table 7-17  
Attributes of ISR ..................................................................................... 117 
Table 7-18  
Sub-attributes of UseSpecialFunctionname / 
OsIsrUseSpecialFunctionName .............................................................. 117 

Table 7-19  
Sub-attributes of TIMING_PROTECTION / OsIsrTimingProtection ........... 119 
Table 7-20  
Sub-attributes of LOCKINGTIME / OsIsrResourceLock .......................... 119 
Table 7-21  
ISR attributes concerning the timing analyzer ......................................... 120 
Table 7-22  
Attributes of Appmode / OsAppMode ...................................................... 121 
Table 7-23  
Attributes of Application / OsApplication .................................................. 122 
Table 7-24  
Sub-attributes for trusted functions ......................................................... 122 
Table 7-25  
Attributes of SCHEDULETABLE ............................................................. 123 
Table 7-26  
Sub-attributes for auto start of a schedule table ...................................... 124 
Table 7-27  
Sub-attributes of expiry points................................................................. 125 
Table 7-28  
Sub-attributes of expiry point action ADJUST ......................................... 125 
Table 7-29  
Sub-attributes of expiry point action ACTIVATETASK ............................. 125 
Table 7-30  
Sub-attributes of expiry point action SETEVENT .................................... 126 
Table 7-31  
Sub-attributes SCHEDULETABLE-> 
LOCAL_TO_GLOBAL_TIME_SYNCHRONIZATION = TRUE .................. 127 

Table 10-1  
Bit-definitions of the variant coding, ucSysVariant1 ................................. 133 
Table 10-2  
Bit-definitions of the variant coding, osSysVariant2 ................................. 133 
Table 10-3  
Bit definitions of the variant coding, osOrtiVariant ................................... 133 
Table 11-1  
Abbreviations .......................................................................................... 134 
Table 11-2  
Terms ..................................................................................................... 135 
2015, Vector Informatik GmbH 
Version: 9.01 
13 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
1  Component History 
The  component  history  gives  an  overview  over  the  important  milestones  that  are 
supported in the different versions of the component. 
This  chapter  is  included  in  any  MICROSAR  component  documentation.  For  the  OS,  the 
history on the intended level is not relevant as MICROSAR OS implements all mandatory 
requirements of AUTOSAR OS. 
2015, Vector Informatik GmbH 
Version: 9.01 
14 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
2  Introduction 
This document describes the functionality, API and configuration of the general part of the 
AUTOSAR BSW module OS as specified in [1]. 
 
Supported AUTOSAR Release: 
4.0.3 
Supported Configuration Variants: 
pre-compile 
Vendor ID: 
OS_VENDOR_ID 
30  decimal  (= Vector-
Informatik,  according  to 
HIS) 
Module ID: 
OS_MODULE_ID   
1 decimal  (according to 
ref. [2]) 
 
2.1  Architecture Overview 
The following figure shows where the OS is located in the AUTOSAR architecture. 
 
Figure 2-1 
AUTOSAR 3.x Architecture Overview   
Figure 2-2 
AUTOSAR architecture 
2015, Vector Informatik GmbH 
Version: 9.01 
15 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
 
The MICROSAR OS is an operating system based on the AUTOSAR OS standard V5.0.0 
(ref. [1]) and on OSEK OS standard 2.2.3 (ref. [3]). 
This  MICROSAR  OS  operating  system  is  a  real  time  operating  system,  which  was 
specified  for  the  usage  in  electronic  control  units  on  a  range  of  small  to  large 
microprocessors.  MICROSAR  OS  has  attributes  which  differ  from  commonly  known 
operating systems and which  allow a very  efficient  implementation even on systems with 
low resources of RAM and ROM. 
As a requirement, there is no dynamic creation of new tasks at runtime; all tasks have to 
be  defined  before  compilation.  The  operating  system  has  no  dynamic  memory 
management and there is no shell for the control of tasks by hand. 
The  operating  system  and  the  application  are  compiled  and  linked  together  to  one  file, 
which is loaded into an emulator or is burned into an EPROM or Flash EEPROM. 
 
2015, Vector Informatik GmbH 
Version: 9.01 
16 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
3  Functional Description 
3.1 
Features 
The features listed in this chapter cover the complete functionality specified in [1]. 
The  "supported"  and  "not  supported"  features  are  presented  in  the  following  two  tables. 
For further information of not supported features, also see chapter 9. 
 
The following features described in [1] are supported: 
Supported Feature 
The Vector MICROSAR OS implements all mandatory features described in the chapter about 
System Scalability within [1]. However, some minor restrictions apply, see chapter 9 in this 
document. 
Table 3-1  
Supported SWS features 
The  following  features  described  in  [1]  are  supported  in  MultiCore  implementations. 
However,  they  are  currently  not  described  in  this  document,  but  in  the  additional 
documentation [4]. 
Conditionally Supported Feature 
MultiCore 
Inter OSApplication Communication (IOC) 
Table 3-2  
Not supported SWS features 
The  OSEK  /  AUTOSAR  OS  specifications  leave  many  points  open  on  implementation. 
Every  OSEK  / AUTOSAR  OS  implementation  for  a  specific  microcontroller  has  to  define 
the open points to achieve an optimal solution for the processor. The operating system has 
to  fit  the  target  microprocessor  and  the  C-compiler.  The  programming  model  of  the  C-
compiler is as important as the hardware of the processor. 
3.2 
Main Functions 
The operating system is started by the application. The startup module (which is not part of 
the operating system) calls the function main. In the main function, the user has to call the 
API  function  StartOS.  StartOS  will  initialize  the  operating  system,  install  the  interrupt 
routine  for  the  alarm  handling,  and  then  call  the  scheduler.  StartOS  will  never  return  to 
the main function. 
The function of the scheduler is to evaluate the task with the highest priority in the  READY 
state  and  call  this  task.  If  the  task  was  previously  pre-empted  by  another  higher  priority 
task, the scheduler resumes the task. 
2015, Vector Informatik GmbH 
Version: 9.01 
17 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
The operating system is controlled by external events. External events can be events from 
interrupt  routines,  from  the  alarm  management,  or  from  schedule  tables  (Alarms  and 
schedule  tables  are  also  driven  by  interrupt  service  routines).  Therefore,  any  external 
event will result in the change of task states. 
 
Figure 3-1 
Functional parts 
Interrupt routines are under the control of the application programmer. An OSEK operating 
system  allows  a  fast  and  efficient  interrupt  handling,  so  interrupts  have  a  short  latency 
time.  It is possible  to call certain  system functions from interrupt  routines.  It is necessary 
that the operating system has knowledge of any existing interrupt routines. 
3.2.1 
Timer and Alarms 
All  time-based  actions  are  performed  in  OSEK  using  counters,  alarms,  and  schedule 
tables.  Counters  are  part  of  the  kernel  and  are  incremented  by  a  specific  hardware 
resource  or  by  means  of  the  system  service  IncrementCounter.  In  case  of  a  time-
based  counter,  the  counter  is  incremented  periodically. Alarms and  schedule  tables  have 
fixed references to counters. MICROSAR OS supports up to 256 counters. 
An  alarm,  if  activated,  has  a  certain  value.  If  the  referenced  counter  reaches  the  given 
value,  a  defined  action  is  performed.  The  action  to  each  alarm  is  defined  by  the  OIL 
Configurator and is compiled into the ROM. The alarm value is passed as a parameter to 
the functions SetRelAlarm or SetAbsAlarm. 
A schedule table, if activated, has a certain starting value. If the referred counter reaches 
the  given  value,  the  first  defined  action  is  performed.  The  further  actions  are  defined 
relative to this first action. These relative starting times are defined together with the action 
by  the  OIL  Configurator  and  compiled  into  ROM.  The  starting  value  is  passed  as  a 
parameter to the functions StartScheduleTableRel or StartScheduleTableAbs. 
2015, Vector Informatik GmbH 
Version: 9.01 
18 / 136 
based on template version 4.3 




Technical Reference MICROSAR OS SafeContext  
 
3.2.1.1 
Time Base 
3.2.1.1.1 
Counter Macros 
To  support  the  portability  of  OSEK,  application  alarm  related  functions,  for  example 
SetRelAlarm,  should  be  called  using  macros  for  the  calculation  of  ticks  based  on 
millisecond or seconds: 
SetRelAlarm (Alarm1, OS_xx2TICKS_<CounterName> (1200), OS_xx2TICKS_<CounterName> 
(1200));  
The macros OS_TICKS2xx_<CounterName>() (whereas xx denotes NS, US, MS or SEC; 
described by the AUTOSAR standard) may be used to convert tick values (as returned for 
example  by  GetElapsedTime()  and  GetCounterValue()  )  to  into  a  second  based 
timer 
unit. 
Additionally, 
MICROSAR 
OS 
provides 
the 
inverse 
macros 
OS_xx2TICKS_<CounterName>() for conversion into the opposite direction (see Figure 
2-2)
.  
 
 
Figure 3-2 
Counter Macros 
 
 
 
Caution 
Depending on the hardware settings, certain nanosecond times may not be 
  representable accurately. 
 
Therefore, if large times, very small times or very high precision is needed, use 
AUTOSAR OS OsTimeConstant instead (see 7.3.3)
 
 
 
 
3.2.1.1.2 
Temporal Range of Alarms 
The  temporal  range  of  an  alarm  depends  on  the  Counter,  which  drives  the  alarm.  The 
important 
configuration 
attributes 
here 
are 
OsSecondsPerTick 
and 
OsCounterMaxAllowedValue (see 7.3.3)
3.2.1.2 
Timer Interrupt Routine 
The timer interrupt routines are category 2 ISRs and are part of the operating system. The 
configuration is done automatically by the OS using  information that has to be defined in 
the OIL Configurator. 
3.2.1.2.1 
Counter API 
To  obtain  the  counter  specific  limits  (e.g.  maxallowedvalue)  the  function 
GetAlarmBase can be used. 
2015, Vector Informatik GmbH 
Version: 9.01 
19 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
1.1.1.1.1.1 Initialization 
Former versions of osCAN and MICROSAR OS provided the API functions: 
StatusType InitCounter<CounterName>(TickType ticks); 
These functions have been removed, as they do not conform  to the standardized counter 
API described in [1]. Instead, counters are always initialized to 0 during StartOS(). 
1.1.1.1.1.2 Read Counter 
MICROSAR  OS  provides  the  API  functions  GetCounterValue  and  GetElapsedValue  as 
defined by [1]. 
Former versions of osCAN and MICROSAR OS provided the API functions: 
TickType GetCounterValue<CounterName>(void); 
These functions have been removed, as they do not conform to the standardized counter 
API described in [1]. It is recommended to use the API function GetCounterValue defined 
by AUTOSAR Standard instead. 
1.1.1.1.1.3 Increment Counter 
StatusType IncrementCounter(CounterType CounterName); 
This function is the AUTOSAR OS standardized function to trigger a counter. 
 
Example 
The ISR that triggers the counter must be of category 2. 
  ISR(MyCounterISR) 

   IncrementCounter(MyCounter); 

 
 
Former versions of osCAN and MICROSAR OS provided the API function 
void CounterTrigger<CounterName>(void); 
These functions have been removed, as they do not conform to the standardized counter 
API described in [1]. It is recommended to use the API function IncrementCounter defined 
by AUTOSAR Standard instead. 
3.2.2 
Stack Handling 
3.2.2.1 
Task Stack 
Each task  has  its own  stack. The  task  stack  holds  all  local data  and  return  addresses of 
the task.  In addition,  the register context  of the task is saved onto the stack if  the task is 
preempted.  If  the  task  is  transferred  to  the  running  state  again,  the  register  context  is 
removed from the task stack to restore the previously saved registers. 
3.2.2.2 
Interrupt Stack 
The implementation of interrupt stacks depends on the hardware, and is described in ref. 
[4].  
2015, Vector Informatik GmbH 
Version: 9.01 
20 / 136 
based on template version 4.3 




Technical Reference MICROSAR OS SafeContext  
 
3.2.2.3 
Stack Monitoring 
MICROSAR OS SafeContext always initializes the last useable bytes of each stack with an 
indicator value. 
This indicator is then checked with each task switch or ISR exit. A change of the element 
value  indicates  a  stack  overflow  by  the  task  or  ISR.  In  this  case,  the  system  calls  the 
ErrorHook (if configured), the ShutdownHook (if configured) and enters the shutdown 
state. 
 
 
 
Note 
MICROSAR OS checks the indicator value only at task switches and on a return from 
  an ISR. Therefore, stack overflows are not detected immediately. Detection might be 
delayed arbitrary in case of a stack overflow in a hook routine. Some implementations 
of MICROSAR OS implement additional checks of the indicator value, see [4]. If 
memory protection is configured, stack overflows in tasks and ISRs of non-trusted 
applications are found immediately by the memory protection if the stack is followed by 
an area with no access rights. 
 
 
In case a  stack fault is detected by memory protection,  the ProtectionHook is called with 
parameter  E_OS_PROTECTION_MEMORY.  If  a  stack  fault  is  detected  by  stack 
monitoring, MICROSAR OS goes into shutdown after the ProtectionHook. 
 
3.2.2.4 
Stack Usage 
If  StackUsageMeasurement  is  set  to  TRUE,  the  OS  fills  all  available  stacks  with  the 
indicator value 0xAA during StartOS (startup times will be slower). This allows measuring 
the  amount  of  stack  used  since  StartOS  by  counting  the  amount  of  bytes  that  have  not 
been overwritten yet.  
The following function is available to determine the amount of used stack: 
osuint16 osGetStackUsage(TaskType taskId) 
>  Argument: Task number 
>  Return value:  Maximum stack usage (bytes) by task since call of StartOS() 
Additional implementations specific functions may be available. Please see the hardware 
specific part of the documentation of this implementation [4]. 
 
 
 
Caution 
Dependent on the stack size, the measurement operation can take a long time. 
 
 
 
 
3.2.3 
Interrupt Handling 
Implementation  specific  details  about  interrupt  handling  are  described  in  the  hardware 
specific part of this implementation [4]. 
2015, Vector Informatik GmbH 
Version: 9.01 
21 / 136 
based on template version 4.3 




Technical Reference MICROSAR OS SafeContext  
 
 
 
Caution 
Knowledge about the interrupt handling is very important. If interrupt routines are used 
  it is essential to read this chapter. 
 
 
3.2.3.1 
Interrupt Categories 
The OSEK OS specification defines two groups of interrupts.  
3.2.3.1.1 
Category 1: 
Interrupts  of  category  1  are  in  general  not  allowed  to  use API  functions;  as  such,  these 
routines can be programmed without restrictions and are completely independent from the 
kernel. The programming conventions depend on the utilized compiler and assembler. 
Category 1 interrupts can be enabled before call of StartOS(). If interrupts of category 1 
and 2 cannot be disabled separately, all interrupts must be disabled. 
Interrupts  of  category  1  are  allowed  to  call  the  interrupt API  as  an  exception  to  the  rule 
presented  above.  If  the  interrupt  API  is  used  and  the  category  1  interrupts  are  enabled 
before  the  call  of  StartOS,  the  user  has  to  take  care  about  variable  initialization  of  the 
interrupt API, as described in chapter 3.2.3.2. 
1.1.1.1.1.4 Exceptions and SC2, SC3, SC4 
According to the AUTOSAR-Standard,  category 1 interrupts should be avoided with SC2, 
SC3  and  SC4.  MICROSAR  OS  does  not  allow  category  1  interrupts  with 
TimingProtection.  Because  non-maskable  interrupts  need  to  be  configured  to 
category  1,  some  MICROSAR  OS  implementations  allow  exceptions  even  with  timing 
protection.  
The  user  may  write  "normal"  interrupt  code  in  an  exception  routine,  which  returns  to  the 
application.  Please  note  that  this  sort  of  exception  routines  will  cause  the  exception 
handler to add runtime to the account of the interrupted task or ISR. 
3.2.3.1.2 
Category 2: 
Interrupts  of  category  2 may  use  certain  restricted API functions.  Interrupts of  category  2 
can be programmed as normal C functions using the macro  ISR(name). The C function 
is  called  by  the  operating  system.  The  necessary  preparation  for  the  interrupt  routine  is 
done automatically by a generated function. 
ISR (AnInterruptRoutine) 

 
   /* code with API calls */ 
 

 
 
 
Caution 
Category 2 interrupts must be disabled until call of StartOS()! This also applies for 
  the timer interrupts, i.e. this interrupt must be stopped by the user at a software reset. 
2015, Vector Informatik GmbH 
Version: 9.01 
22 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
To ensure data consistency, the operating system needs to disable category 2 
interrupts during critical sections of code. Therefore, applications must not use non-
maskable interrupts as category 2 interrupts. 
 
 
3.2.3.2 
Usage of the Interrupt API before StartOS 
The usage of the interrupt API functions is in general allowed before the operating system 
is started. The affected functions are:  
>  DisableAllInterupts, EnableAllInterrupts 
>  SuspendAllInterrupts, ResumeAllInterrupts 
>  SuspendOSInterrupts, ResumeOSInterrupts 
However,  these  functions  use  some  internal  variables  that  have  to  be  initialized  to  zero 
before  the  first  call  of  the  interrupt  API.  Typically,  this  initialization  is  performed  by  the 
startup code (which might be delivered with the compiler). In case no startup code is used, 
the  function  osInitialize()  needs  to  be  called.  osInitialize  initializes  the 
variables which are used in the interrupt API. 
2015, Vector Informatik GmbH 
Version: 9.01 
23 / 136 
based on template version 4.3 





Technical Reference MICROSAR OS SafeContext  
 
3.2.4 
Timing Protection 
The  timing  protection  is  implemented  in  the  Scalability  Classes  2  and  4.  This  chapter 
provides some hints on the functionality according to the AUTOSAR OS standard [1] and 
describes additional functionality provided by Vector MICROSAR OS. To enable the timing 
protection of a task or ISR, the OIL-attribute TIMING_PROTECTION of the respective task 
or ISR needs to be configured, as described in chapters  7.3.2.2 and 7.3.7.2 . (AUTOSAR 
XML: OsTaskTimingProtection/OsIsrTimingProtection). 
 
 
Caution 
The runtime of all tasks and ISRs is observed, however parts of the time for task switch 
  and interrupt entry/exit cannot be monitored by the timing protection. Therefore, some 
extra time for task switches and interrupt entry/exit needs to be considered in the 
configuration of the timing protection. 
 
 
 
 
 
Caution 
Timing Protection is implemented with interrupts. If the application manually disables 
  interrupts anywhere, the timing protection cannot work as expected. In order to enable 
and disable interrupts, the application must use the following API functions: 
>  DisableAllInterupts, EnableAllInterrupts 
>  SuspendAllInterrupts, ResumeAllInterrupts 
>  SuspendOSInterrupts, ResumeOSInterrupts  
 
 
 
 
Caution 
The timing protection works very precise. However, if an OS API function is called by a 
  task/ISR, the OS may enter a critical section; if a timing protection violation is detected 
while the system is in a critical section, the call of the protection hook may be delayed 
until the end of the critical section. Note, that critical sections in AUTOSAR OS are very 
short. 
 
 
3.2.4.1 
Reaction on Protection Failure 
The AUTOSAR  specification  describes  different  possibilities  how  to  react  to  a  protection 
violation.  In  SafeContext  implementations,  reaction  to  such  a  situation  is  limited  to 
Shutdown. 
3.2.4.2 
Timing Measurement 
MICROSAR  OS  is  not  only  able  to  provide  timing  protection  but  allows  using  the  same 
functionality  for  timing  measurement.  If  timing  measurement  is  performed  for  a  specific 
task or ISR, the OS measures the following times for that task or ISR: 
>  the maximum run time since StartOS 
>  the maximum locking times for resources and interrupts since StartOS 
2015, Vector Informatik GmbH 
Version: 9.01 
24 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
>  the minimum time distance between two arrivals since StartOS  
The debugger can read the result of the timing measurement  via  ORTI. Alternatively,  the 
application may use the timing measurement API as described in chapter 6.4. 
The OS attribute TimingMeasurement and the task/ISR attribute TIMING_PROTECTION 
are provided to setup timing protection and measurement. 
The  hardware  timers  and  internal  data  structures  to  store  measured  times  are  limited  in 
size.  When  this  limit  is  exceeded  by  any  measured  time  (e.g.  of  a  resource  or  interrupt 
lock), the ErrorHook function is called and the system goes into shutdown state. 
3.2.4.2.1 
Timing measurement configuration for a specific task/ISR 
Timing  measurement  can  be  configured  individually  for  each  task  and  ISR.  As  timing 
protection  requires  the  OS  to  measure  the  timing  values,  timing  measurement  is 
performed  for  all  tasks  and  ISRs  that  have  timing  protection  configured  by  means  of  the 
attribute  TIMING_PROTECTION.  By  selecting  the  sub  attribute  OnlyMeasure,  the  OS 
disables  the  timing  protection  but  still  measures  the  timing  values.  Please  note  that  this 
configuration  might  be  overridden  by  means  of  the  global  configuration,  described  in  the 
next chapter. 
3.2.4.2.2 
Global configuration of timing measurement 
In order to save configuration time, the timing measurement can be configured globally for 
all  tasks  and  ISRs.  MICROSAR  OS  provides  the  OIL-attribute  TimingMeasurement 
(AUTOSAR  XML:  OsOSTimingMeasurement)  for  that  purpose.  That  attribute  provides 
the possibilities to: 
>  Disable the timing measurement globally. This is an optimization to save memory and 
runtime of the timing measurement. Please set the attribute TimingMeasurement to 
FALSE (deselect it) for this configuration. 
>  Collect timing data for all tasks and ISRS. The collected timing values can be used to 
perform scheduleability analysis and to set up the timing protection later on. For this 
configuration, please set the attribute TimingMeasurement to TRUE (select it) and 
choose OnlyMeasureAll for the value of the sub attribute GlobalConfig.  
>  Perform timing measurement as configured for the task or ISR. Set the attribute 
TimingMeasurement to TRUE (select it) and select AsSelected for the value of the 
subattribute GlobalConfig to achieve this. 
>  Ignore the task/ISR attribute OnlyMeasure (perform timing measurement and protection 
as if this attribute was set to FALSE). For this configuration, please set the attribute 
TimingMeasurement to TRUE (select the attribute) and select 
ProtectAndMeasureAll for the value of the subattribute GlobalConfig. 
The chapter 7.3.2.2 provides a description of the attribute TIMING_PROTECTION for tasks 
while  chapter  7.3.7.2  provides  the  respective  description  for  ISRs.  Chapter  7.3.1.4 
provides a description of the attribute TimingMeasurement. The table below documents 
the  interdependence  between  the  OS-attribute  TimingMasurement  and  the  task/ISR-
Attribute TIMING_PROTECTION. 
2015, Vector Informatik GmbH 
Version: 9.01 
25 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
 
OS 
TASK/ISR 
 
                   TIMING_PROTECTION 
Timing-
Global-
FALSE 
TRUE 
Measuremen
Config 
 
OnlyMeasure 

 
FALSE 
TRUE 
FALSE1 
 
No timing protection, 
Timing protection but no 
Timing protection but no 
no timing 
timing measurement 
timing measurement, warning 
measurement, 
as the sub attribute 
OnyMeasure is overridden 
TRUE 
Only-
No timing protection 
No timing protection but 
No timing protection but 
Measure-
but timing 
timing measurement, 
timing measurement 
All 
measurement 
warning as the sub 
attribute OnlyMeasure is 
overridden 
AsSelecte No timing protection 
Timing protection and 
No Timing protection but 

and no timing 
measurement 
timing measurement 
measurement 
ProtectAn No timing protection 
Timing protection and 
Timing protection and 
d-
but timing 
measurement 
measurement, warning as the 
MeasureAl measurement 
sub attribute OnlyMeasure is 
overridden. 

Table 3-3  
Interdependence between the OS attribute TimingMeasurement and the task/ISR attribute TIMING_PROTECTION 
3.2.4.3 
Hook functions 
The  runtime  of  the  hook  functions  PreTaskHook  and  PostTaskHook  (Chapters  6.6.2  and 
6.6.3) is considered to belong to the runtime of the currently active task. 
 
 
 
Caution 
Depending on the implementation, the execution of the ProtectionHook might be 
  delayed until the PreTaskHook or PostTaskHook has finished. In case of a protection 
violation during the PostTaskHook while a task state change into the states 
SUSPENDED or WAITING, the call of the ProtectionHook gets lost. 
Therefore, the PreTaskHook and the PostTaskHook are allowed for debugging 
purposes only. They must be disabled in production code, see [9]. 
 
 
The  runtime  of  the  hook functions  UserPreIsrHook  and  UserPostIsrHook  (Chapters  6.6.7 
and 6.6.8) is considered to belong to the runtime of the currently active ISR. 
3.2.5 
Memory Protection 
MICROSAR OS uses the MPU of the microcontroller to implement memory protection as 
described  in  [1].  Former  versions  of  MICROSAR  OS  fulfilled  the AUTOSAR  requirement 
OS195  and  prevented  write  access  to  Task/ISR  private  data  areas  even  within  an 
                                            
1 Optimization: The timing measurement API is unavailable 
2015, Vector Informatik GmbH 
Version: 9.01 
26 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
OSApplication. This behaviour is defined as optional by AUTOSAR and not implemented in 
most current versions of MICROSAR OS. It is explicitly mentioned in [5] if supported. 
3.2.6 
Schedule Tables 
MICROSAR  OS  implements  schedule  tables  as  defined  by  the AUTOSAR  standard. The 
document  [1]  provides  the  base  description  of  schedule  tables  and  their  usage.  This 
chapter is meant as an extension that clarifies and corrects some points, provides details 
about points left open and describes corrections and extensions by MICROSAR OS.  
AUTOSAR  defines  schedule  tables  for  all  scalability  classes,  but  synchronization  to  a 
global time only for SC2 and SC4. MICROSAR OS offers some additional error checking 
to the AUTOSAR standard. 
3.2.6.1 
Synchronization 
In  SC2  and  SC4  or  the  High-Resolution  Schedule  Tables  option,  it  is  possible  to 
synchronize a schedule table to a global time source. The schedule table must be marked 
with the OIL attribute LOCAL_TO_GLOBAL_TIME_SYNCHRONIZATION.  
3.2.6.1.1 
Starting a synchronizable Schedule Table 
One  way  to  start  a  synchronizable  schedule  table  is  to  use  the  functions 
StartScheduleTableRel(Tablename, TimeOffset) 
and 
StartScheduleTableAbs(Tablename, Time). The time parameters refer to the local 
time and not to the global time. It is assumed that the schedule table will not have an offset 
to  global  time:  when  synchronization  starts,  the  start  of  the  schedule  table  is  moved  to 
global time zero. Note that the schedule table always starts at the stated start time. A call 
of  SyncScheduleTable  does  not  influence  this  start  time.  Synchronization  starts  after 
execution of the first expiry point. 
The recommended way to start a synchronizable schedule table is to use the combination 
of StartScheduleTableSynchron(Tablename) and SyncScheduleTable(). The 
first expiry point is executed at global time 0. The schedule table starts execution after a 
global time is available, i.e. after calling SyncScheduleTable() for the schedule table. If 
SyncScheduleTable() is never called for the schedule table, the schedule table is 
never executed. The following algorithm describes a possibility to set up a timeout:  
Set 
up 
an 
alarm 
to 
the 
timeout 
time. 
When 
the 
alarm 
expires 
and 
GetScheduleTableStatus()  indicates  that  the  schedule  table  is  still  waiting,  call 
SyncScheduleTable() 
with 
an 
arbitrary 
time. 
Note: 
if 
the 
call 
to 
SyncScheduleTable() is done in an interrupt, it may occur between the two API calls, 
and thus gets overridden by the arbitrary time. 
3.2.6.1.2 
Autostart 
For an automatic start of a schedule table on startup of the OS, the attribute AUTOSTART 
must  be  set. The  sub-attribute  TYPE  defines  how  the  start  is  performed. The possibilities 
are:  ABSOLUT,  RELATIVE  and  SYNCHRON.  These  types  of  autostart  are  similar  to  the 
normal 
start 
of 

schedule 
table 
using 
StartScheduleTableAbs, 
StartScheduleTableRel  or  StartScheduleTableSynchron.  For  ABSOLUT  and 
RELATIVE, an absolute or relative start time needs to be provided. In case of SYNCHRON, 
2015, Vector Informatik GmbH 
Version: 9.01 
27 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
the schedule table starts after SynchScheduleTable has been called and the global time 
reaches zero.  
Note,  that  just  like for  StartScheduleTableSynchron(),  the  schedule  table  will  wait 
forever if SyncScheduleTable() is never called.  
3.2.6.1.3 
Suspending a Schedule Table and keeping its Synchronization 
The AUTOSAR  standard  does  not  define  a  way  to  suspend  the  execution  of  a  schedule 
table  and  keep  its  synchronization  for  later  restart.  The  suggested  approach  is  to  use 
NextScheduleTable() to append a schedule table that effectively does nothing.  
Currently,  AUTOSAR  does  not  define  a  way  to  retrieve  the  internal  schedule  table  time 
(neither the currently estimated global time nor the time relative to the first expiry point of 
the schedule table).  
3.2.6.1.4 
Providing a Global Time 
The current global time is handed to the schedule table via SyncScheduleTable(). If a 
deviation  of  the  schedule  table  to  the  global  time  is  found,  the  schedule  table  starts  to 
synchronize at the next expiry point that allows synchronization. 
The  global  time  must  be  a  continuous  range  of  integers:  So  e.g.  FlexRay’s  time  tuple 
(cycle, macroticks) cannot directly be used as global time, but must be converted. 
The  provided  global  time must  have  the  same  resolution as  the  local  time and  the  same 
period as the schedule table time (i.e. the LENGTH of the schedule table). If this is not the 
case, it must be converted before being handed to SyncScheduleTable(). 
 
Example 
Converting the FlexRay time: 
  Be gMacroPerCycle the number of macroticks per cycle, cycle the current 
cycle number, macroticks the current macrotick number and f is the factor to 
convert the FlexRay tick length the HW counter tick length: 
 
GlobalTime = (gMacroPerCycle * cycle + macroticks) * f 
 
 
3.2.6.1.5 
Exact Synchronization 
There  is  always  a  time  span  between  reading  the  global  time  and  handing  it  to  the 
operating system. Therefore, synchronization is never absolutely exact.  
If  an  interrupt  interferes,  the  time  span  may  be  unexpectedly  large.  While  this  may  be 
ignorable  if  the  resolution  is  large  compared  with  the  interrupt  running  times,  it  is 
noticeable  when  using  a  fine  grained  global  time,  for  example  in  conjunction  with  High-
Resolution Schedule Tables, or if some (higher prior) interrupts have long running times. It 
is desirable to be undisturbed by (higher prior) interrupts during synchronization.  
The  AUTOSAR  Standard  demands,  that  calling  any  API  functions  is  not  allowed  in 
between function pairs 
2015, Vector Informatik GmbH 
Version: 9.01 
28 / 136 
based on template version 4.3 




Technical Reference MICROSAR OS SafeContext  
 
DisableAllInterrupts/EnableAllInterrupts, 
SuspendAllInterrupts/ResumeAllInterrupts, 
SuspendOSInterrupts/ResumeOSInterrupts. 
MICROSAR 
OS 
makes 
an 
exception 
from 
the 
standard 
in 
this 
point: 
SyncScheduleTable() can be called in between these function pairs. 
Therefore, a Sync procedure may look like the following example: 
DisableAllInterrupts(); 
now=getCurrentGlobalTime(); 
SyncScheduleTable(MyScheduleTable, now); 
EnableAllInterrupts(); 
 
 
Caution 
This is unnecessary if SyncScheduleTable() is called from an interrupt which does 
  not allow nesting.  
Also note, that SuspendAllInterrupts()/DisableAllInterrupts() still allow 
timing protection interrupts (if timing protection is used). 
 
 
3.2.6.1.6 
Limits of the Synchronization Algorithm 
The  synchronization  algorithm  as  described  by  the  AUTOSAR  standard  only  corrects 
deviations of the past – it does not make assumptions about deviations of the present or 
the  future.  Differences  in  clock  speed  (between  local  time  and  global  time)  are  not 
completely compensated. 
Simplified  synchronization  algorithm:  When  SyncScheduleTable  is  called,  the 
difference between the local schedule table time and the provided global time is computed 
and stored internally. Nothing more happens until an expiry point expires. Then, the times 
between subsequent expiry points are adapted. The adaptation stops once the computed 
deviation  is  compensated  or  a  new  global  time  is  provided.  In  case  new  deviations 
between  the  global  and  local  time  occur,  they  are  considered  after  the  next  call  of 
SyncScheduleTable in the same way as just described. 
As a result of this algorithm, a permanent deviation in the speed of global and local clock 
might not be compensated completely.  
 
Example 
The local schedule table time2 runs 10 % slower then the global time. Whenever the 
  global time reaches a multiple of 100, the function SyncScheduleTable is called to 
provide the global time to the schedule table. Both times start simultaneously at zero. 
When the global time reaches 100, the local time is 90 because of the 10 % difference. 
SyncScheduleTable is called, and computes a difference of 10. We assume now 
that the difference is compensated until the next call of SyncScheduleTable occurs. 
The local time is then: 90+10+90=190 while the global time is 200. Again we have the 
same difference, so 10 needs to be corrected. The same occurs for all subsequent 
calls of SyncScheduleTable, too. 
                                            
2 The local time is based on the MCU’s internal clock. 
2015, Vector Informatik GmbH 
Version: 9.01 
29 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
 
 
Although the computed difference between current time values of global and local time is 
corrected,  the  same  difference  occurs  in  the  next  synchronization  step.  However,  using 
synchronization  the  deviation  stays  constant.  Without  synchronization,  it  would 
accumulate.  
3.2.6.1.7 
Details about using NextScheduleTable 
The AUTOSAR standard leaves open certain details of using  NextScheduleTable with 
synchronizable  schedule  tables.  The  following  describes  the  implementation  of 
NextScheduleTable MICROSAR OS.  
If  two  schedule  tables  are  chained  using  the API  function  NextScheduleTable(),  the 
second  schedule  table  takes  over  the  synchronized  schedule  table  time  of  the 
predecessor3.  
When  switching  to  a  schedule  table  that  does  not  allow  synchronization,  the  remaining 
difference  to  the  global  time  is  saved:  upon  switching  to  a  schedule  table  that  allows 
synchronization it will immediately start to synchronize. 
3.2.6.1.8 
Concurrent Actions 
If a task is activated at an expiry point, and an event for this task is set at the same expiry 
point,  always  all  tasks  will  be  activated  before  events  are  set.  However,  if  two  schedule 
tables are using the same counter; one of these schedule tables activates a task and the 
other  schedule  table  sets  an  event  for  this  task  at  the  same  time,  the  behaviour  is 
undefined. 
3.2.6.2 
High-Resolution Schedule Tables  
AUTOSAR schedule tables are driven by a counter (hardware or software), and thus offer 
the  same  resolution.  While  it  is  possible  to  configure  a  higher  resolution  for  the  counter, 
this  increases  also  the  interrupt  load.  High-Resolution  Schedule  Tables  offer  a 
microsecond  resolution  or  better4  without  unnecessary  additional  interrupt  load:  At  each 
expiry  point,  a  timer  interrupt  is  reprogrammed  so  it  will  be  reactivated  exactly  at  the 
following expiry point5.  
Note  that  high  resolution  schedule  tables  are  not  supported  by  all  MICROSAR  OS 
implementations. 
It is possible to use standard schedule tables and High-Resolution Schedule Tables at the 
same  time.  High-Resolution  Schedule  Tables  support  the  full  AUTOSAR  API,  including 
synchronization (see 3.2.5.1) and are particularly suited for FlexRay. 
                                            
3 Therefore, if the two schedule tables have a different LENGTH, switching from one to the other is undefined: it may work, but may 
also lead to unexpected results. This is not checked at runtime (and cannot be checked at generation time). 
4 The actually achievable best resolution depends on the hardware, hardware settings and application 
5 while the activation of the schedule table handler is done as exact as the underlying counter (the hardware) allows it, a certain time 
span will expire until the expiry point is actually processed. Interrupts, non-preemptive tasks and interrupt disabling times impose 
an additional jitter. 
2015, Vector Informatik GmbH 
Version: 9.01 
30 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
3.2.6.2.1 
Setup 
To  create  a  High-Resolution  Schedule  Table,  create  a  Schedule  Table  and  choose  any 
High-Resolution Counter as the underlying counter. This counter is available only on the 
MICROSAR  OS  implementations  that  support  high  resolution  schedule  tables;  it  is 
automatically available if supported. 
3.2.6.3 
Cyclical Expiry Point Actions 
Cyclical expiry point actions are a Vector specific extension of the AUTOSAR Standard to 
ease  the  configuration  of  schedule  table  actions.  In  case  an  expiry  point  action  shall  be 
executed  cyclicly  within  a  schedule  table,  the  user  may  select  the  sub-attribute  Cyclic. 
This  allows  him  to  define  a  cycle  time  in  the  sub-attribute  CycleTime.  This  informs  the 
generator that the expiry point action shall occur repeatedly with the configured cycle time 
starting at the offset of the expiriy point, the action belongs to. 
In case, the sub-attributes Cyclic and CycleTime have been configured, the generator 
of  the  OS  copies  the  expiry  point  actions  to  the  configured  locations  within  the  schedule 
table before it generates the schedule table. In case, there is already an expiry point at a 
location where a cyclical expiry point action shall occur, the cyclical action is simply added 
to the actions of that expiry point. In case there is no expiry point configured at the location 
where  a  cyclical  expiry  point  action  schall  occur,  the  generator  invents  an  expiry  point. 
Please note that generator invented expiry points do not allow synchronization as there is 
no configuration of the synchronization step width possible. 
 
3.2.7 
Trusted Functions 
MICROSAR  OS  OSEK/AUTOSAR  provides  two  possibilities  to  call  trusted  functions:  by 
direct call of API function CallTrustedFunction or by using generated stub functions. 
It  is  possible  to  mix  applications using  direct  calls  and  applications  using  generated  stub 
functions. 
 
 
Caution 
Inside trusted functions there is full access to all memory. Therefore, each trusted 
  function with address arguments for return values must check the access rights of the 
caller before writing results through an address argument. The API provides the 
functions CheckTaskMemoryAccess and CheckISRMemoryAccess for address 
checking. 
 
 
3.2.7.1 
Generated Stub Functions 
The  generation  of  stubs  for  trusted  functions  is  a  Vector  specific  extension  of  the 
AUTOSAR OS standard to ease the usage of trusted functions. 
To enable stub generation for an application, the TRUSTED attribute of this application and 
the sub-attribute GenerateStub must be set to TRUE. 
In  this  case,  a  caller  stub  with  the  name  Call_<name>  is  generated  for  each  trusted 
function  of  the  application,  where  <name>  is  the  name  of  the  trusted  function.  The 
generated stub function Call_<name> packs its parameters into a structure as needed by 
2015, Vector Informatik GmbH 
Version: 9.01 
31 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
the  standard  API  function  CallTrustedFunction  and  calls  that  API  function.  Another 
generated  stub  function  performs  an  unpacking  of  the  parameters  so  that  the  user's 
trusted function does not need to get all the parameters via one pointer, but can have a set 
of parameters and a return value like any legal C-function. 
In  case  the  sub-attribute  GenerateStub  is  set  to  TRUE,  the  user  has  to  define  the 
parameters and the return value of the trusted function as well. The sub-attribute Params 
shall contain a comma-separated list of type and parameter name (as they would occur in 
a  function  definition  in  C).  The  sub-attribute  ReturnType  shall  define  the  return  type  of 
the function. 
The stubs are generated into the file trustfct.c. 
See 10.8 for an example using generated stub functions for trusted applications. 
 
 
 
Caution 
The generator does not produce prototypes for the trusted functions to be called by the 
  trusted function stubs. The prototypes shall be provided by the writer of these functions 
and included into the file usrostyp.h. Parameter types and the return type need to be 
defined there also in case they are no simple types of the C-language. The file 
usrostyp.h is described in chapter 5.2. 
 
 
 
2015, Vector Informatik GmbH 
Version: 9.01 
32 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
3.3 
Error Handling 
3.3.1 
Error Messages 
If  the  kernel  detects  errors,  the  OSEK  error  handling  is  called.  The  hook  routine 
ErrorHook is called if selected. 
Depending on the situation in which an error was detected the error handling will return to 
the current active task or the system will be shut down. 
3.3.2 
OSEK / AUTOSAR OS Error Numbers 
 
The  OSEK  specification  defines  several  error  numbers  that  are  returned  by  the  API 
functions. A  certain  error  number  has  different  meanings  for  different API  functions.  The 
user has to know the API function to interpret the error number correctly. 
With  the  AUTOSAR  OS  specification,  the  range  of  error  numbers  was  extended.  The 
following table shows all specified error numbers. 
Error Code 
Description 

E_OK 
Service executed successfully 

E_OS_ACCESS   
Several APIs: general access of object failure 

E_OS_CALLEVEL   
Several APIs: service accessed from wrong context  

E_OS_ID       
Several APIs: service called with wrong ID 

E_OS_LIMIT     
Several APIs: service called too often 

E_OS_NOFUNC    
Several APIs: (warning) service not executed 

E_OS_RESOURCE   
Several APIs: service called with occupied resource 

E_OS_STATE   
Several APIs: object is in wrong state 

E_OS_VALUE    
Several APIs: passed parameter has wrong value 

E_OS_SERVICEID  
Several APIs: service can not be called 
10 
E_OS_ILLEGAL_ADDRESS  
Several APIs: invalid address passed 
11 
E_OS_MISSINGEND  
Several APIs: task terminated without TerminatTask 
12 
E_OS_DISABLEDINT  
Several APIs: service called with disabled interrupts 
13 
E_OS_STACKFAULT  
Stack monitoring detected fault 
14 
E_OS_PROTECTION_MEMORY  
Memory access violation 
15 
E_OS_PROTECTION_TIME 
Execution time budget exceeded 
16 
E_OS_PROTECTION_ARRIVAL  
Arrival before the timeframe expired 
17 
E_OS_PROTECTION_LOCKED  
Task/ISR blocked too long (e.g. by disabled interrupts) 
18 
E_OS_PROTECTION_EXCEPTION  A trap occurred 
Table 3-4  
OSEK/AUTOSAR OS error numbers 
The additional implementation specific error numbers are defined as: 
2015, Vector Informatik GmbH 
Version: 9.01 
33 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
20 
E_OS_SYS_ASSERTION 
This error is generated if the kernel detects an 
internal inconsistency. The reason and an exact 
explanation is described below. 
21 
E_OS_SYS_ABORT 
This error is generated if the kernel has to shut down 
the system but the reason was not an API function. 
22 
E_OS_SYS_DIS_INT 
This error number is no longer used. It is replaced by 
the AUTOSAR OS conformant number 
E_OS_DISABLEDINT. 
23 
E_OS_SYS_API_ERROR  
This error is generated if an error occurs in an API 
function and there is no error code specified in the 
OSEK specification. The reason and an exact 
explanation is described below. 
24 
E_OS_SYS_ALARM_MANAGEMENT  A general warning issued in certain cases involving 
the alarm management. Detailed description 
in the implementation specific manual  
25 
E_OS_SYS_WARNING 
A general warning issued in certain cases. Detailed 
description in the implementation specific manual. 
Table 3-5  
Implementation specific error numbers 
 
More implementation specific errors may be described in ref. [4]. 
3.3.3 
MICROSAR OS Error Numbers 
In  addition  to  the  OSEK  error  numbers,  all  MICROSAR  OS  implementations  provide 
unique error numbers for an exact error description. All error numbers are defined as a 16-
bit  value.  The  error  numbers  are  defined  in  the  header  file  osekerr.h  and  are  defined 
according to the following syntax: 
0xgfee 
  ||+--- consecutive error number 
  |+---- number of function in the function group 
  +----- number of function group  
The error numbers common to all MICROSAR OS implementations are described below. 
The implementation specific error numbers have a function group number >= 0xA000 and 
are described in the document [4].  
To access these error numbers the ERRORHOOK has to be enabled. The numbers are then 
accessible via the macro OSErrorGetosCANError(). 
Error Types: 
Error Type 
Description 
OSEK 
OSEK / AUTOSAR error. After calling the ErrorHook, the program is 
continued. 
assertion 
System assertion error. After calling the ErrorHook the operating system 
is shut down. Assertion checking is always enabled in SafeContext 
implementations. 
2015, Vector Informatik GmbH 
Version: 9.01 
34 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Type 
Description 
syscheck 
System error. After calling the ErrorHook the operating system is shut 
down. Refer to the specific error for a description how to enable or disable 
error checking. 
Table 3-6  
Error types 
3.3.3.1 
Error Numbers of Group Task Management / (1) 
Group (1) contains the functions: 
API Function 
Abbreviation  Function 
Number 
ActivateTask 
AT 

TerminateTask 
TT 

ChainTask 
HT 

Schedule 
SH 

GetTaskState 
GS 

GetTaskID 
GI 

osMissingTerminateError 
MT 

Table 3-7  
API functions of group Task Management / (1) 
Error numbers of group (1): 
Error Code 
Description 
 
Error Type  Reason 
0x1101 
osdErrATWrongTaskID 
OSEK 
Called with invalid task ID 
0x1102 
osdErrATWrongTask 
assertion 
Task has wrong priority level  
Prio 
0x1103 
osdErrATMultiple 
OSEK 
number of activation of activated task 
Activation 
exceeds limit 
0x1104 
osdErrATIntAPI 
OSEK 
Interrupts are disabled with functions 
Disabled 
provided by OSEK 
0x1105 
osdErrATAlarm 
OSEK 
Number of activation of activated task 
MultipleActivation 
exceeds limit (task activation is performed 
by alarm-expiration or expiry point action)  
0x1106 
osdErrATNoAccess 
OSEK 
Calling application has no access rights for 
this task 
0x1107 
osdErrATCallContext 
OSEK 
Called from invalid call context 
0x1108 
osdErrATWrongAppState  OSEK 
Referenced object is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x1201 
osdErrTTDisabled 
OSEK 
TerminateTask called with disabled 
Interrupts 
interrupts 
0x1202 
osdErrTTResources 
OSEK 
TerminateTask called with occupied 
2015, Vector Informatik GmbH 
Version: 9.01 
35 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error Type  Reason 
Occupied 
resources 
0x1203 
osdErrTTNotActivated  assertion 
TerminateTask attempted for a task with 
activation counter == 0 (not activated) 
0x1204 
osdErrTTOnInterrupt 
OSEK 
TerminateTask called from an interrupt 
Level 
service routine 
0x1205 
osdErrTTNoImmediate 
assertion 
TerminateTask has tried to start the 
TaskSwitch  
Scheduler without success. 
0x1206 
osdErrTTCallContext 
OSEK 
Called from invalid call context 
0x1208 
osdErrTTWrongActiveTa assertion 
Task index is not valid during call of 
skID 
TerminateTask 
0x1301 
osdErrHTInterrupts 
OSEK 
ChainTask called with disabled interrupts 
Disabled 
0x1302 
osdErrHTResources 
OSEK 
ChainTask called with occupied 
Occupied 
resources 
0x1303 
osdErrHTWrongTaskID 
OSEK 
New task has invalid ID 
0x1304 
osdErrHTNotActivated  assertion 
Tried to terminate a task which have an 
activation counter which is zero 
0x1305 
osdErrHTMultiple 
OSEK 
Number of activation of new task exceeds 
Activation 
limit 
0x1306 
osdErrHTOnInterrupt 
OSEK 
ChainTask called on interrupt level 
Level 
0x1307 
osdErrHTWrongTask 
assertion 
ChainTask was called from wrong priority 
Prio 
level 
0x1308 
osdErrHTNoImmediate 
assertion 
ChainTask has tried to activate the 
TaskSwitch 
Scheduler without success. 
0x1309 
osdErrHTCallContext 
OSEK 
Called from invalid call context 
0x130A  osdErrHTNoAccess 
OSEK 
Calling application has no access rights for 
this task 
0x130B  osdErrHTWrongAppState  OSEK 
Referenced object is owned by an 
OSApplication which was terminated. 
0x130D  osdErrHTWrongActiveTa assertion 
Task index is not valid during call of 
skID 
ChainTask 
0x1401 
osdErrSHInterrupts 
OSEK 
Schedule called with disabled interrupts 
Disabled 
0x1402 
osdErrSHOnInterrupt 
OSEK 
Schedule called on interrupt level 
Level 
0x1403 
osdErrSHScheduleNot 
assertion 
Schedule called from task with enabled 
Allowed 
stack sharing by setting 
NotUsingSchedule in the OIL 
Configurator 
0x1405 
osdErrSHResources 
OSEK 
Called with an occupied resource 
Occupied 
2015, Vector Informatik GmbH 
Version: 9.01 
36 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error Type  Reason 
0x1406 
osdErrSHCallContext 
OSEK 
Called from invalid call context 
0x1409 
osdErrSHWrongActiveTa assertion 
Task index is not valid during call of 
skID 
Schedule 
0x1501 
osdErrGSWrongTaskID 
OSEK 
Called with invalid task ID 
0x1502 
osdErrGSIntAPI 
OSEK 
Interrupts are disabled with functions 
Disabled 
provided by OSEK 
0x1503 
osdErrGSIllegalAddr 
OSEK 
Caller has no write access rights for 
address argument 
0x1504 
osdErrGSCallContext 
OSEK 
Called from invalid call context 
0x1505 
osdErrGSNoAccess 
OSEK 
Calling application has no access rights for 
this task 
0x1506 
osdErrGSWrongAppState  OSEK 
Referenced object is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x1507 
osdErrGSOddInvocation  assertion 
Invocation of internal function  
osGetTaskState detected although 
ReducedStatusChecks was enabled 
0x1601 
osdErrGIIntAPI 
OSEK 
Interrupts are disabled with functions 
Disabled 
provided by OSEK 
0x1602 
osdErrGIIllegalAddr 
OSEK 
Caller has no write access rights for 
address argument. 
0x1603 
osdErrGICallContext 
OSEK 
Called from invalid call context 
0x1604 
osdErrGIOddInvocation  assertion 
Invocation of internal function  
osGetTaskID detected although 
ReducedStatusChecks was enabled 
0x1701 
osdErrMTMissing 
syscheck 
Exit of task without the call of 
TerminateTask 
TerminateTask or ChainTask. This 
error is detected in EXTENDED STATUS 
only. 
Table 3-8  
Error numbers of group Task Management / (1) 
3.3.3.2 
Error Numbers of Group Interrupt Handling / (2) 
Group (2) contains the functions: 
API Function 
Abbreviation  Function 
Number 
EnableAllInterrupts 
EA 

DisableAllInterrupts 
DA 

ResumeOSInterrupts 
RI 

SuspendOSInterrupts 
SI 

osUnhandledException 
UE 

2015, Vector Informatik GmbH 
Version: 9.01 
37 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
API Function 
Abbreviation  Function 
Number 
osSaveDisableLevelNested 
SD 

osRestoreEnableLevelNested 
RE 

osSaveDisableGlobalNested 
SG 

osRestoreEnableGlobalNested  RG 

ResumeAllInterrupts 
RA 

SuspendAllInterrupts 
SA 

GetISRID 
II 

Interrupt Exit (SC3 only) 
IX 

Table 3-9  
API functions of group Interrupt Handling / (2) 
Error numbers of group (2): 
Error Code 
Description 
 
Error Type  Reason 
0x2401 
osdErrEAIntAPIWrong 
assertion 
DisableAllInterrupts not called 
Sequence         
before 
0x2501 
osdErrDAIntAPI 
assertion 
Interrupts are disabled with functions 
Disabled         
provided by OSEK 
 
0x2801 
osdErrUEUnhandled 
syscheck 
An unhandled exception or interrupt was 
Exception 
detected. This error check is always 
enabled. 
0x2901 
osdErrSDWrongCounter  assertion 
Wrong counter value detected 
0x2A01  osdErrREWrongCounter  assertion 
Wrong counter value detected 
0x2B01  osdErrSGWrongCounter   assertion 
Wrong counter value detected 
0x2C01  osdErrRGWrongCounter   assertion 
Wrong counter value detected 
0x2201 
osdErrIIIntAPI 
OSEK 
GetISRID was called with interrupts 
Disabled 
disabled. 
0x2202 
osdErrIICallContext 
OSEK 
Called from invalid call context 
0x2301 
osdErrIXResources 
OSEK 
An ISR of category 2 was left with 
Occupied 
resources still occupied. 
0x2302 
osdErrIXIntAPI 
OSEK 
An ISR of category 2 was left with 
Disabled 
interrupts disabled by 
DisableAllInterrupts, 
SuspendAllInterrupts or 
SuspendOSInterrupts 
Table 3-10   Error numbers of group Interrupt Handling / (2) 
 
2015, Vector Informatik GmbH 
Version: 9.01 
38 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
3.3.3.3 
Error Numbers of Group Resource Management / (3) 
Group (3) contains the functions: 
API Function 
Abbreviation  Function 
Number 
GetResource 
GR 

ReleaseResource 
RR 

Table 3-11   API functions of group Resource Management / (3) 
Error numbers of group (3): 
Error Code 
Description 
 
Error Type  Reason 
0x3101 
osdErrGRWrongResource OSEK 
Invalid resource ID 
ID 
0x3102 
osdErrGRPriority 
assertion 
Ceiling priority of the specified resource 
Occupied 
already in use 
0x3103 
osdErrGRResource 
OSEK 
Resource already occupied 
Occupied 
0x3104 
osdErrGRNoAccess 
assertion 
Task has no access to the specified 
Rights 
resource 
0x3105 
osdErrGRWrongPrio 
OSEK 
Specified resource has a wrong priority. 
Possible reason: the task has no access 
rights to this resource.  
0x3106 
osdErrGRIntAPI 
OSEK 
Interrupts are disabled with functions 
Disabled 
provided by OSEK 
0x3107 
osdErrGRNoAccess 
OSEK 
Calling application has no access rights for 
this resource 
0x3108 
osdErrGRCallContext 
OSEK 
Called from invalid call context 
0x3109 
osdErrGRISRNoAccess 
OSEK 
Calling ISR has no access rights for this 
Rights 
resource 
0x310B  osdErrGRWrongTaskID 
assertion 
Task index is not valid during call of 
GetResource 
0x3201 
osdErrRRWrongResource OSEK 
Invalid resource ID 
ID 
0x3202 
osdErrRRCeiling 
assertion 
Ceiling priority of the resource not found in 
PriorityNotSet 
the ready bit field 
0x3203 
osdErrRRWrongTask 
assertion 
Resource occupied by a different task 
0x3204 
osdErrRRWrongPrio 
OSEK 
Specified resource has a wrong priority. 
Possible reason: the task has no access 
rights to this resource.  
0x3206 
osdErrRRNotOccupied 
OSEK 
The specified resource is not occupied by 
the task 
0x3207 
osdErrRRWrongSequence  OSEK 
At least one other resource must be 
released before 
2015, Vector Informatik GmbH 
Version: 9.01 
39 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error Type  Reason 
0x3208 
osdErrRRIntAPI 
OSEK 
Interrupts are disabled with functions 
Disabled 
provided by OSEK 
0x3209 
osdErrRRNoAccess 
OSEK 
Calling application has no access rights for 
this resource 
0x320A  osdErrRRCallContext 
OSEK 
Called from invalid call context 
0x320B  osdErrRRISRNoAccess 
OSEK 
Calling ISR has no access rights for this 
Rights 
resource 
0x320D  osdErrRRNoReadyTaskFo assertion 
No valid priority found when calling 
und 
ReleaseResource 
0x320E  osdErrRRWrongTaskID 
assertion 
Task index is not valid during call of 
ReleaseResource 
0x320F  osdErrRRWrongHighRdyP assertion 
No valid high ready priority task index 
rio 
during call of ReleaseResource 
Table 3-12   Error numbers of group Resource Management / (3) 
 
3.3.3.4 
Error Numbers of Group Event Control / (4) 
Group (4) contains the functions: 
API Function 
Abbreviation  Function 
Number 
SetEvent 
SE 

ClearEvent 
CE 

GetEvent 
GE 

WaitEvent 
WE 

Table 3-13   API functions of group Event Control / (4) 
Error numbers of group (4): 
Error Code 
Description 
 
Error Type  Reason 
0x4101 
osdErrSEWrongTaskID 
OSEK 
Invalid task ID 
0x4102 
osdErrSENotExtended 
OSEK 
Cannot SetEvent to basic task 
Task 
0x4103 
osdErrSETaskSuspended  OSEK 
Cannot SetEvent to task in SUSPENDED 
state. The error code might occur in case 
of API call SetEvent or in case of 
alarm/schedule table action to set an 
event. 
0x4104 
osdErrSEWrongTask 
assertion 
Wrong task priority detected 
Prio 
2015, Vector Informatik GmbH 
Version: 9.01 
40 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error Type  Reason 
0x4105 
osdErrSEIntAPI 
OSEK 
Interrupts are disabled with functions 
Disabled 
provided by OSEK 
0x4106 
osdErrSECallContext 
OSEK 
Called from invalid call context 
0x4107 
osdErrSENoAccess 
OSEK 
Calling application has no access rights for 
this task 
0x4108 
osdErrSEWrongAppState  OSEK 
Referenced task is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x4201 
osdErrCENotExtended 
OSEK 
A basic task cannot clear an event 
Task 
0x4202 
osdErrCEOnInterrupt 
OSEK 
ClearEvent called on interrupt level 
Level 
0x4203 
osdErrCEIntAPI 
OSEK 
Interrupts are disabled with functions 
Disabled 
provided by OSEK 
0x4204 
osdErrCECallContext 
OSEK 
Called from invalid call context 
0x4301 
osdErrGEWrongTaskID 
OSEK 
Invalid task ID 
0x4302 
osdErrGENotExtended 
OSEK 
Cannot GetEvent from basic task 
Task 
0x4303 
osdErrGETaskSuspended  OSEK 
Cannot GetEvent from a task in 
SUSPENDED state 
0x4304 
osdErrGEIntAPI 
OSEK 
Interrupts are disabled with functions 
Disabled 
provided by OSEK 
0x4305 
osdErrGEIllegalAddr 
OSEK 
Caller has no write access rights for 
address argument 
0x4306 
osdErrGECallContext 
OSEK 
Called from invalid call context 
0x4307 
osdErrGENoAccess 
OSEK 
Calling application has no access rights for 
this task 
0x4308 
osdErrGEWrongAppState  OSEK 
Referenced task is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x4309 
osdErrGEOddInvocation  assertion 
Invocation of internal function  
osGetEvent detected although 
ReducedStatusChecks was enabled  
0x4401 
osdErrWENotExtended 
OSEK 
WaitEvent called by basic task 
Task 
0x4402 
osdErrWEResources 
OSEK 
WaitEvent called with occupied 
Occupied 
resources 
0x4403 
osdErrWEInterrupts 
OSEK 
WaitEvent called with disabled interrupts 
Disabled 
0x4404 
osdErrWEOnInterrupt 
OSEK 
WaitEvent called on interrupt level 
Level 
0x4405 
osdErrWECallContext 
OSEK 
Called from invalid call context 
2015, Vector Informatik GmbH 
Version: 9.01 
41 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Table 3-14   Error numbers of group Event Control / (4) 
 
3.3.3.5 
Error Numbers of Group Alarm Management / (5) 
Group (5) contains the functions: 
API Function 
Abbreviation  Function 
Number 
GetAlarmBase 
GB 

GetAlarm 
GA 

SetRelAlarm 
SA 

SetAbsAlarm 
SL 

CancelAlarm 
CA 

osWorkAlarm 
WA 

Table 3-15   API functions of group Alarm Management / (5) 
Error numbers of group (5): 
Error Code 
Description 
 
Error Type  Reason 
0x5101 
osdErrGBWrongAlarmID  OSEK 
Invalid alarm ID 
0x5102 
osdErrGBIntAPI 
OSEK 
Interrupts are disabled with functions 
Disabled 
provided by OSEK 
0x5103 
osdErrGBIllegalAddr 
OSEK 
Caller has no write access rights for 
address argument 
0x5104 
osdErrGBCallContext 
OSEK 
Called from invalid call context 
0x5105 
osdErrGBNoAccess 
OSEK 
Calling application has no access rights for 
this alarm 
0x5106 
osdErrGBWrongAppState  OSEK 
Referenced object is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x5201 
osdErrGAWrongAlarmID  OSEK 
Invalid alarm ID 
0x5202 
osdErrGANotActive 
OSEK 
Alarm not active 
0x5203 
osdErrGAIntAPI 
OSEK 
Interrupts are disabled with functions 
Disabled 
provided by OSEK 
0x5204 
osdErrGAIllegalAddr 
OSEK 
Caller has no write access rights for 
address argument 
0x5205 
osdErrGACallContext 
OSEK 
Called from invalid call context 
0x5206 
osdErrGANoAccess 
OSEK 
Calling application has no access rights for 
this alarm 
0x5207 
osdErrGAWrongAppState  OSEK 
Referenced alarm is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
2015, Vector Informatik GmbH 
Version: 9.01 
42 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error Type  Reason 
0x5301 
osdErrSAWrongAlarmID  OSEK 
Invalid alarm id 
0x5302 
osdErrSAAlreadyActive  OSEK 
Alarm already active 
0x5303 
osdErrSAWrongCycle 
OSEK 
Specified cycle is out of range 
0x5304 
osdErrSAWrongDelta 
OSEK 
Specified delta is out of range 
0x5305 
osdErrSAIntAPI 
OSEK 
Interrupts are disabled with functions 
Disabled 
provided by OSEK 
0x5306 
osdErrSAZeroIncrement  OSEK 
SetRelAlarm was called with the 
parameter increment set to zero. (This is 
no longer allowed with AUTOSAR OS) 
0x5307 
osdErrSACallContext 
OSEK 
Called from invalid call context 
0x5308 
osdErrSANoAccess 
OSEK 
Calling application has no access rights for 
this alarm 
0x5309 
osdErrSAWrongAppState  OSEK 
Referenced alarm is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x5401 
osdErrSLWrongAlarmID  OSEK 
Invalid alarm ID 
0x5402 
osdErrSLAlreadyActive  OSEK 
Alarm already active 
0x5403 
osdErrSLWrongCycle 
OSEK 
Specified cycle is out of range 
0x5404 
osdErrSLWrongStart 
OSEK 
Specified start is out of range 
0x5405 
osdErrSLIntAPI 
OSEK 
Interrupts are disabled with functions 
Disabled 
provided by OSEK 
0x5406 
osdErrSLCallContext 
OSEK 
Called from invalid call context 
0x5407 
osdErrSLNoAccess 
OSEK 
Calling application has no access rights for 
this alarm 
0x5408 
osdErrSLWrongAppState  OSEK 
Referenced alarm is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x5501 
osdErrCAWrongAlarmID  OSEK 
Invalid alarm ID 
0x5502 
osdErrCANotActive 
OSEK 
Alarm not active 
0x5503 
osdErrCAIntAPI 
OSEK 
Interrupts are disabled with functions 
Disabled 
provided by OSEK 
0x5504 
osdErrCAAlarmInternal  syscheck 
Internal error detected while alarm was 
cancelled. This error is only detected when 
OSInternalChecks is set to 
Additional. 
0x5505 
osdErrCACallContext 
OSEK 
Called from invalid call context 
0x5506 
osdErrCANoAccess 
OSEK 
Calling application has no access rights for 
this alarm 
0x5507 
osdErrCAWrongAppState  OSEK 
Referenced alarm is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
2015, Vector Informatik GmbH 
Version: 9.01 
43 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error Type  Reason 
0x5601 
osdErrWAWrongIDonHeap  assertion 
Wrong alarm ID in heap data structure for 
alarm management 
0x5602 
osdErrWAHeapOverflow  assertion 
Overflow in internal data structure for 
alarm management 
0x5603 
osdErrWAUnknownAction  assertion 
Invalid alarm action type during processing 
of an expired alarm 
0x5604 
osdErrWAWrongCounterI assertion 
Invalid counter ID during processing of an 

expired alarm with 
OsAlarmAction=OsAlarmIncrementC
ounter. 
Table 3-16   Error numbers of group Alarm Management / (5) 
 
3.3.3.6 
Error Numbers of Group Operating System Execution Control / (6) 
Group (6) contains the functions: 
API Function 
Abbreviation  Function 
Number 
osCheckStackOverflow 
SO 

osSchedulePrio 
SP 

osGetStackUsage 
SU 

osCheckLibraryVersionAndVariant  CL 

osErrorHook 
EH 

StartOS 
ST 

osSchedInsertTask 
QI 

osSchedRemoveRunningTask 
QR 

osSchedOnHomePrio 
QS 

osSchedOccupyInternalResource 
QO 

Table 3-17   API functions of group Operating System Execution Control / (6) 
Error numbers of group (6): 
Error Code 
Description 
 
Error Type  Reason 
0x6101 
osdErrSOStackOverflow  syscheck 
Task stack overflow detected. This error is 
only detected when the OIL attribute 
WithStackCheck is set to TRUE. 
0x6201 
osdErrSPInterrupts 
assertion 
Scheduler called with enabled interrupts 
Enabled 
0x6301 
osdErrSUWrongTaskID 
assertion 
Called with invalid task ID 
2015, Vector Informatik GmbH 
Version: 9.01 
44 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error Type  Reason 
0x6401 
osdErrCLWrongLibrary  syscheck 
Wrong library linked to application. This 
error check is always enabled. 
0x6501 
osdErrEHInterrupts 
assertion 
ErrorHook called with enabled interrupts 
Enabled 
0x6601 
osdErrSTMemoryError 
assertion 
StartOS failed while initializing memory. 
0x6602 
osdErrSTNoImmediate 
assertion 
StartOS tried to activate the Scheduler 
TaskSwitch 
without success. 
0x6603 
osdErrSTWrongAppMode  syscheck 
StartOS was called with an invalid 
parameter value. This error is only 
detected if the attribute STATUS is set to 
EXTENDED. 
0x6604 
osdErrSTConfigCRCErro assertion 
Configuration CRC mismatch detected 

during StartOS 
0x6606 
osdErrSTConfigMagicNr assertion 
Error reading the magic number from 
Error 
config block during StartOS 
0x6607 
osdErrSTInvalidMajorV assertion 
Error reading the major version number 
ersion 
from config block during StartOS 
0x6608 
osdErrSTInvalidMinorV assertion 
Error reading the minor version number 
ersion 
from config block during StartOS 
0x6609 
osdErrSTInvalidSTCfg  assertion 
Schedule table has an invalid autostart 
type value. 
0x6701 
osdErrQIWrongTaskPrio  assertion 
Wrong Task Priority in 
osSchedInsertTask 
0x6801 
osdErrQRInterruptsEna assertion 
Interrupts are enabled during 
bled 
osSchedRemoveRunningTask 
0x6802 
osdErrQRWrongTaskID 
assertion 
Task index not valid in 
osSchedRemoveRunningTask 
0x6803 
osdErrQRWrongTaskPrio  assertion 
Priority not valid in 
osSchedRemoveRunningTask 
0x6804 
osdErrQRWrongHighRdyP assertion 
High ready task priority not valid in 
rio 
osSchedRemoveRunningTask 
0x6901 
osdErrQSInterruptsEna assertion 
Interrupts are enabled during 
bled 
osSchedOnHomePrio 
0x6902 
osdErrQSNoReadyTaskFo assertion 
No High ready task has been found in 
und 
osSchedOnHomePrio 
0x6903 
osdErrQSWrongPriority  assertion 
Priority not valid in osSchedOnHomePrio 
0x6A01  osdErrQOWrongTaskID 
assertion 
Task index not valid in 
osSchedOccupyInternalResource 
Table 3-18   Error numbers of group Operating System Execution Control / (6) 
 
2015, Vector Informatik GmbH 
Version: 9.01 
45 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
3.3.3.7 
Error Numbers of Schedule Table Control / (7) 
Group (7) contains the functions: 
API Function 
Abbreviation  Function 
Number 
StartScheduleTableRel 
SR 

StartScheduleTableAbs 
SS 

StopScheduleTable 
SP 

GetScheduleTableStatus 
SG 

NextScheduleTable 
SN 

osWorkScheduleTable 
WS 

SyncScheduleTable (SC2 and SC4) 
SY 

SetScheduleTableAsync (SC2 and SC4) 
AY 

StartScheduleTableSynchron (SC2 and SC4)  TS 

Table 3-19   API functions of group Schedule Table Control / (7) 
Error numbers of group (7): 
Error Code 
Description 
 
Error Type  Reason 
0x7101 
osdErrSRWrongID 
OSEK 
StartScheduleTableRel was called 
with an invalid schedule table ID. 
0x7102 
osdErrSRAlready 
OSEK 
StartScheduleTableRel was called for 
RunningOrNext 
a schedule table that is already running or 
next. 
0x7103 
osdErrSRZeroOffset 
OSEK 
StartScheduleTableRel was called 
with the parameter Offset set to zero. 
0x7104 
osdErrSROffsetTooBig  OSEK 
StartScheduleTableRel was called 
with the parameter Offset bigger than 
MAXALLOWEDVALUE of the respective 
counter. 
0x7105 
osdErrSRIntAPI 
OSEK 
StartScheduleTableRel was called 
Disabled 
with disabled interrupts. 
0x7106 
osdErrSRCallContext 
OSEK 
Called from invalid call context 
0x7107 
osdErrSRNoAccess 
OSEK 
Calling application has no access rights for 
this schedule table 
0x7109 
osdErrSRImplicite 
OSEK 
StartScheduleTableRel was called for 
Sync 
an implicitly synchronized ScheduleTable 
0x710a 
osdErrSRWrongAppState  OSEK 
Referenced schedule table is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x7201 
osdErrSSWrongID 
OSEK 
StartScheduleTableAbs was called 
with an invalid schedule table ID. 
0x7202 
osdErrSSAlready 
OSEK 
StartScheduleTableAbs was called for 
2015, Vector Informatik GmbH 
Version: 9.01 
46 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error Type  Reason 
RunningOrNext 
a schedule table, which is already running 
or next. 
0x7203 
osdErrSSTickvalueToo   OSEK 
StartScheduleTableAbs was called 
Big 
with the parameter TickValue bigger than 
MAXALLOWEDVALUE of the respective 
counter. 
0x7204 
osdErrSSIntAPI 
OSEK 
StartScheduleTableAbs was called 
Disabled 
with disabled interrupts. 
0x7205 
osdErrSSCallContext 
OSEK 
Called from invalid call context 
0x7206 
osdErrSSNoAccess 
OSEK 
Calling application has no access rights for 
this schedule table 
0x7207 
osdErrSSWrongAppState  OSEK 
Referenced schedule table is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x7301 
osdErrSPWrongID 
OSEK 
StopScheduleTable was called with an 
invalid schedule table ID. 
0x7302 
osdErrSPNotRunning 
OSEK 
StopScheduleTable was called for a 
schedule table, which is in stopped or next 
state. 
0x7303 
osdErrSPIntAPI 
OSEK 
StopScheduleTable was called with 
Disabled 
disabled interrupts. 
0x7304 
osdErrSPCallContext 
OSEK 
Called from invalid call context 
0x7305 
osdErrSPNoAccess 
OSEK 
Calling application has no access rights for 
this schedule table 
0x7306 
osdErrSPUnknownCase 
Assertion 
An internal error occured 
0x7307 
osdErrSPWrongAppState  OSEK 
Referenced schedule table is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x7401 
osdErrSGWrongID 
OSEK 
GetScheduleTableStatus was called 
with an invalid schedule table ID. 
0x7402 
osdErrSGIntAPI 
OSEK 
GetScheduleTableStatus was called 
Disabled 
with disabled interrupts 
0x7403 
osdErrSGCallContext 
OSEK 
Called from invalid call context 
0x7404 
osdErrSGNoAccess 
OSEK 
Calling application has no access rights for 
this schedule table 
0x7405 
osdErrSGIllegalAddr 
OSEK 
Caller has no write access rights for 
address argument 
0x7406 
osdErrSGWrongAppState  OSEK 
Referenced schedule table is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x7407 
osdErrSGOddInvocation  assertion 
Invocation of internal function  
osGetScheduleTableStatus detected 
although ReducedStatusChecks was 
2015, Vector Informatik GmbH 
Version: 9.01 
47 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error Type  Reason 
enabled 
0x7501 
osdErrSNWrongCurrent  OSEK 
NextScheduleTable was called with an 
ID 
invalid schedule table ID for the parameter 
ScheduleTableID_current. 
0x7502 
osdErrSNWrongNextID 
OSEK 
NextScheduleTable was called with an 
invalid schedule table ID for the parameter 
ScheduleTableID_next. 
0x7503 
osdErrSNNotRunning 
OSEK 
NextScheduleTable was called to chain 
a schedule table after another schedule 
table, that is currently not running. 
0x7504 
osdErrSNAlready 
OSEK 
NextScheduleTable was called to chain 
RunningOrNext 
a running schedule table after another 
schedule table. 
0x7505 
osdErrSNDifferent 
OSEK 
NextScheduleTable was called to chain 
Counters 
two schedule tables, which are driven by 
different counters. 
0x7506 
osdErrSNIntAPI 
OSEK 
NextScheduleTable was called with 
Disabled 
interrupts disabled. 
0x7507 
osdErrSNCallContext 
OSEK 
Called from invalid call context 
0x7508 
osdErrSNNoAccess 
OSEK 
Calling application has no access rights for 
this schedule table 
0x7509 
osdErrSNWrongAppState  OSEK 
Referenced schedule table is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x7601 
osdErrWSUnknownAction  assertion 
An invalid action was found in a schedule 
table 
0x7602 
osdErrWSUnknown 
assertion 
An internal error occured 
Reaction 
0x7603 
osdErrWSWrongID 
assertion 
No valid schedule table index in 
osWorkScheduleTable 
0x7701 
osdErrSYCallContext 
OSEK 
Called from invalid call context 
0x7702 
osdErrSYWrongID 
OSEK 
Called with wrong schedule table ID 
0x7703 
osdErrSYNoAccess 
OSEK 
Calling application has no access rights for 
this schedule table 
0x7704 
osdErrSYIntAPI 
OSEK 
Called with interrupts disabled 
Disabled 
0x7705 
osdErrSYSTNotRunning  OSEK 
The Schedule table is currently not running 
0x7706 
osdErrSYGlobalTimeToo OSEK 
The Global Time is larger than the LENGTH 
Big 
of the schedule table 
0x7707 
osdErrSYSyncKindNot 
OSEK 
SyncScheduleTable was called for a 
Explicit 
Schedule table that is not explicitly 
synchronized. 
2015, Vector Informatik GmbH 
Version: 9.01 
48 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error Type  Reason 
0x7708 
osdErrSYWrongAppState  OSEK 
Referenced schedule table is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x7801 
osdErrAYCallContext 
OSEK 
Called from invalid call context 
0x7802 
osdErrAYWrongID 
OSEK 
Called with wrong schedule table ID 
0x7803 
osdErrAYNoAccess 
OSEK 
Calling application has no access rights for 
this schedule table 
0x7804 
osdErrAYIntAPI 
OSEK 
Called with interrupts disabled 
Disabled 
0x7805 
osdErrAYWrongAppState  OSEK 
Referenced schedule table is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x7C01  osdErrTSCallContext             
OSEK 
 Called from invalid call context 
0x7C02  osdErrTSWrongID                
OSEK 
  Called with invalid schedule table id. 
0x7C03  osdErrTSNoAccess               
OSEK 
  Calling application has no access rights for 
this schedule table 
0x7C04  osdErrTSIntAPI 
OSEK 
Called with interrupts disabled 
Disabled          
0x7C05  osdErrTSSTAlready 
OSEK 
The schedule table is already running or 
Running        
scheduled to run after a currently running 
schedule table 
0x7C06  osdErrTSGlobalTimeToo OSEK 
The offset to Global Time is larger than the 
Big  
LENGTH of the schedule table 
0x7C08  osdErrTSSyncKindNot 
OSEK 
StartScheduleTableSynchron was 
Explicit 
called for a Schedule table that is not 
explicitly synchronized. 
0x7C09  osdErrTSWrongAppState  OSEK 
Referenced schedule table is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
Table 3-20   Error numbers of group Schedule Table Control / (7) 
3.3.3.8 
Error Numbers of Group Counter API / (8) 
Group (8) contains the functions: 
API Function 
Abbreviation  Function 
Number 
IncrementCounter 
IC 

GetCounterValue  
GC 

GetElapsedValue 
GV 

Table 3-21   API functions of group Counter API / (8) 
Error numbers of group (8): 
2015, Vector Informatik GmbH 
Version: 9.01 
49 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error Type  Reason 
0x8101 
osdErrICWrongCounter  OSEK 
IncrementCounter was called for an 
ID 
invalid counter or a hardware counter. 
0x8102 
osdErrICIntAPI 
OSEK 
IncrementCounter was called with 
Disabled 
interrupts disabled. 
0x8103 
osdErrICCallContext 
OSEK 
Called from invalid call context 
0x8104 
osdErrICNoAccess 
OSEK 
Calling application has no access rights for 
this counter 
0x8105 
osdErrICWrongAppState  OSEK 
Referenced counter is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x8301 
osdErrGCCallContext 
OSEK 
Called from invalid call context. 
0x8302 
osdErrGCIntAPIDisabled  OSEK 
Called with disabled interrupts 
0x8303 
osdErrGCWrongID 
OSEK 
Parameter CounterID is invalid 
0x8304 
osdErrGCNoAccess 
OSEK 
Counter not accessible by the caller 
0x8305 
osdErrGCIllegalAddr 
OSEK 
Location the reference parameter Value 
points to is not writable for the calling 
application 
0x8306 
osdErrGCWrongAppState  OSEK 
Referenced ISR is owned by an 
OSApplication that is not in state 
APPLICATION_ACCESSIBLE 
0x8307 
osdErrGCOddInvocation  assertion  Invocation of internal function  
osGetCounterValue detected although 
ReducedStatusChecks was enabled  
0x8401 
osdErrGVCallContext 
OSEK 
Called from invalid call context. 
0x8402 
osdErrGVIntAPIDisabled  OSEK 
Called with disabled interrupts 
0x8403 
osdErrGVWrongID 
OSEK 
Parameter CounterID is invalid 
0x8404 
osdErrGVNoAccess 
OSEK 
Counter not accessible by the caller 
0x8405 
osdErrGVIllegalAddr 
OSEK 
Location a reference parameter points to is 
not writable for the calling application 
0x8406 
osdErrGVWrongAppState  OSEK 
Referenced ISR is owned by an 
OSApplication that is not in state 
APPLICATION_ACCESSIBLE 
0x8407 
osdErrGVIllegalValue 
OSEK 
The passed value is illegal 
0x8408 
osdErrGVIllegalPointer OSEK 
The pointers for out parameters Value and 

Elapsed Value are identical. 
0x8409 
osdErrGVOddInvocation  assertion  Invocation of internal function  
osGetElapsedValue detected although 
ReducedStatusChecks was enabled 
Table 3-22   Error numbers of group Counter API / (8) 
 
2015, Vector Informatik GmbH 
Version: 9.01 
50 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
3.3.3.9 
Error Numbers of Group Timing Protection and Timing Measurement / (9) 
Group (9) contains the functions: 
API Function 
Abbreviation 
Function 
Number 

GetTaskMinInterArrivalTime 
TM 

BlockingTimeMonitoring 
BM 

GetTaskMaxExecutionTime 
TE 

GetISRMaxExecutionTime 
IE 

GetTaskMaxBlockingTime 
TB 

GetISRMaxBlockingTime 
IB 

ExecutionTimeMonitoring 
ET 

GetISRMinInterArrivalTime 
MI 

Table 3-23   API functions of group Timing Protection and Timing Measurement / (9) 
 
 
Error numbers of group (9): 
Error Code 
Description 
 
Error Type  Reason 
0x9001 
osdErrTMWrongTaskID 
OSEK 
Called with wrong TASK ID 
0x9002 
osdErrTMNoAccess 
OSEK 
The calling application has no access 
rights for the TASK 
0x9003 
osdErrTMIllegalAddr 
OSEK 
The caller has no access rights for the 
memory region 
0x9004 
osdErrTMWrongAppState  OSEK 
Referenced task is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x9702 
osdErrBMResAlready 
assertion 
A blocking time measurement was started 
Measured 
that is already running. This might happen 
if timing protection is active and 
SuspendAllInterrupts is called after 
DisableAllInterrupts has already 
been called. 
0x9703 
osdErrBMInvalidProces assertion 
Internal error: attempt to start Block Timing 
sInStart 
Protection with an invalid task or ISR 
0x9704 
osdErrBMInvalidProces assertion 
Internal error: attempt to stop Block Timing 
sInStop 
Protection with an invalid task or ISR 
0x9705 
osdErrBMInvalidResour assertion 
Attempt to monitor blocking time for an 
ce 
invalid resource detected. 
0x9801 
osdErrTEWrongTaskID 
OSEK 
GetTaskMaxExecutionTime was called 
with an invalid task identifier 
0x9802 
osdErrTENoAccess 
OSEK 
The calling application has no access 
2015, Vector Informatik GmbH 
Version: 9.01 
51 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error Type  Reason 
rights for this task 
0x9803 
osdErrTEIllegalAddr 
OSEK 
The caller has no access rights for this 
memory region 
0x9804 
osdErrTEWrongAppState  OSEK 
Referenced task is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x9901 
osdErrIEWrongISRID 
OSEK 
GetISRMaxExecutionTime was called 
with an invalid ISR identifier 
0x9902 
osdErrIENoAccess 
OSEK 
The calling application has no access 
rights for this ISR 
0x9903 
osdErrIEIllegalAddr 
OSEK 
The caller has no access rights for this 
memory region. 
0x9904 
osdErrIEWrongAppState  OSEK 
Referenced ISR is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x9A01  osdErrTBWrongTaskID 
OSEK 
Called with wrong Task ID 
0x9A02  osdErrTBWrongBlock 
OSEK 
Called with wrong blocking type 
Type 
0x9A03  osdErrTBWrongResource OSEK 
Called with wrong resource ID 
ID 
0x9A04  osdErrTBNoAccessTo 
OSEK 
The calling application has no access 
Task 
rights for the task 
0x9A05  osdErrTBNoAccessTo 
OSEK 
The calling application has no access 
Resource 
rights for the resource 
0x9A06  osdErrTBIllegalAddr 
OSEK 
The caller has no access rights for this 
memory region 
0x9A07  osdErrTBWrongAppState  OSEK 
Referenced task is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
0x9B01  osdErrIBWrongISRID 
OSEK 
Called with wrong ISR ID 
0x9B02  osdErrIBWrongBlock 
OSEK 
Called with wrong blocking type 
Type 
0x9B03  osdErrIBWrongResource OSEK 
Called with wrong resource ID 
ID 
0x9B04  osdErrIBNoAccessToISR  OSEK 
The calling application has no access 
rights for the ISR 
0x9B05  osdErrIBNoAccessTo 
OSEK 
The calling application has no access 
Resource 
rights for the resource 
0x9B06  osdErrIBIllegalAddr 
OSEK 
The caller has no access rights for the 
memory region 
0x9B07  osdErrIBWrongAppState  OSEK 
Referenced ISR is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
2015, Vector Informatik GmbH 
Version: 9.01 
52 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error Type  Reason 
0x9D01  osdErrETNoCurrent 
assertion 
Execution Time Monitoring has detected 
Process 
an invalid process ID 
0x9F01  osdErrMIWrongISRID 
OSEK 
Called with wrong ISR ID 
0x9F02  osdErrMINoAccess 
OSEK 
The calling application has no access 
rights for the ISR 
0x9F03  osdErrMIIllegalAddr 
OSEK 
The caller has no access rights for the 
memory region 
0x9F04  osdErrMIWrongAppState  OSEK 
Referenced ISR is owned by an 
OSApplication which is not in state 
APPLICATION_ACCESSIBLE 
Table 3-24   Error numbers of group Timing Protection and Timing Measurement / (9) 
3.3.3.10  Platform specific error codes (A) 
Group (A) contains platform specific error numbers. Please refer to [5] for further detail. 
3.3.3.11  Error Numbers of Group Application API (B) 
Group (B) contains the functions: 
API Function 
Abbreviation  Function 
Number 
GetApplicationState 
AS 

AllowAccess 
AA 

TerminateApplication 
TA 

Table 3-25   API functions of group Application API / (B) 
Error numbers of group (B): 
Error Code 
Description 
 
Error 
Reason 
Type 
0xB101  osdErrASCallContext 
OSEK 
Called from invalid call context. 
0xB102  osdErrASIntAPIDisabled  OSEK 
Called with disabled interrupts 
0xB103  osdErrASWrongAppID 
OSEK 
Called with invalid OSApplication ID 
0xB104  osdErrASOddInvocation 
assertion  Invocation of internal function  
osGetApplicationState detected 
although ReducedStatusChecks was 
enabled 
0xB201  osdErrAACallContext 
OSEK 
Called from invalid call context. 
0xB202  osdErrAAIntAPIDisabled  OSEK 
Called with disabled interrupts 
0xB203  osdErrAAWrongState 
OSEK 
Currently active application is not in state 
APPLICATION_RESTARTING 
2015, Vector Informatik GmbH 
Version: 9.01 
53 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error 
Reason 
Type 
0xB401  osdErrTAWrongRestart 
OSEK 
Invalid restart option 
Option 
0xB402  osdErrTACallContext 
OSEK 
Called from invalid call context 
0xB403  osdErrTAIntAPI 
OSEK 
Called with interrupts disabled 
Disabled 
0xB404  osdErrTAWrongAppID 
OSEK 
Called with wrong OSApplication ID. 
0xB405  osdErrTANoAccess 
OSEK 
Caller has not sufficient access rights to 
terminate the given OSApplication. 
0xB406  osdErrTAWrongAppState 
OSEK 
Referenced application is in wrong state. 
0xB407  osdErrTAInvalidTaskSta
assertion  Task state corrupt in TerminateApplication 
te 
Table 3-26   Error numbers of group Application API / (B) 
3.3.3.12  Error Numbers of Group Semaphores (C) 
 
 
 
Note 
This group is only available for implementations that have been ordered with the 
  feature Semaphores. 
 
 
 
Group (C) contains the functions: 
API Function 
Abbreviation  Function 
Number 
osGetSemaphore 
GM 

osReleaseSemaphore 
RS 

Table 3-27   API functions of group Semaphores / (C) 
Error numbers of group (C): 
Error Code 
Description 
 
Error 
Reason 
Type 
0xC101  osdErrGMWrongSemaphore
OSEK 
GetSemaphore called with wrong 
ID 
Semaphore ID 
0xC102  osdErrGMOnInterruptLev
OSEK 
Called on Interrupt Level 
el 
0xC103  osdErrGMNotExtendedTas
OSEK 
Called from a Basic Task 

0xC104  osdErrGMResourcesOccup
OSEK 
Called while resources are occupied 
2015, Vector Informatik GmbH 
Version: 9.01 
54 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error 
Reason 
Type 
ied 
0xC105  osdErrGMInterruptsDisa
OSEK 
Interrupts are disabled with functions 
bled 
provided by OSEK 
0xC201  osdErrRSWrongSemaphore
OSEK 
ReleaseSemaphore called with wrong 
ID 
Semaphore ID 
0xC203  osdErrRSAlreadyRelease
OSEK 
Tried to release a semaphore that is not 

occupied 
0xC204  osdErrRSWrongTaskPrio 
assertion  Task has wrong priority level 
0xC205  osdErrRSInterruptsDisa
OSEK 
Interrupts are disabled with functions 
bled 
provided by OSEK 
Table 3-28   Error numbers of group Semaphores / (C) 
3.3.3.13  Error Numbers of Group MultiCore related functions (D) 
Group (D) is reserved for MultiCore implementations. MultiCore specific detail is currently 
contained in the additional documentation. Please refer to [4] for further detail. 
3.3.3.14  Error Numbers of Group (Non-)TrustedFunctions (E) 
Group (E) contains the functions: 
API Function 
Abbreviation  Function 
Number 
CallTrustedFunction 
CT 

CallNonTrustedFunction 
NT 

PeripheralAPI functions 
PA 

Table 3-29   API functions of group (Non-)TrustedFunctions (E) 
Error numbers of group (E): 
Error Code 
Description 
 
Error 
Reason 
Type 
0xE301  osdErrCTWrongFctIdx 
OSEK 
Invalid function index for trusted function 
0xE302  osdErrCTCallContext 
OSEK 
Called from invalid call context 
0xE303  osdErrCTIntAPI 
OSEK 
Called with interrupts disabled 
Disabled 
0xE404  osdErrNTWrongFctIdx 
OSEK 
Invalid function index for non-trusted 
function 
0xE405  osdErrNTCallContext 
OSEK 
Called from invalid call context 
0xE406  osdErrNTIntAPI 
OSEK 
Called with interrupts disabled 
Disabled 
2015, Vector Informatik GmbH 
Version: 9.01 
55 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Error Code 
Description 
 
Error 
Reason 
Type 
0xE501  osdErrPAInvalidAreaInd
assertion  Not a valid peripheral region ID used within 
ex 
the API 
0xE502  osdErrPANoAccessRight 
assertion  The current caller does not have access 
rights to the peripheral region 
0xE503  osdErrPAInvalidAddress  assertion  The address which is accessed is not 
included within the passed peripheral 
region 
Table 3-30   Error numbers of group (Non-)TrustedFunctions (E) 
3.3.3.15  Error Numbers of Group IOC (F) 
Group (F) is reserved for implementations supporting IOC. IOC specific detail is currently 
contained in the platform specific documentation. Please refer to [5] for further detail. 
3.3.4 
Reactions on Error Situations 
Depending on the error that has occurred, different reactions are performed: 
>  Errors detected from wrong usage of API functions: Call of ErrorHook and return to 
the calling task or interrupt routine. 
>  Errors detected in the kernel: Call of ErrorHook and call of ShutdownOS (which calls 
ShutdownHook). 
 
2015, Vector Informatik GmbH 
Version: 9.01 
56 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
4  Installation 
The  MICROSAR  OS  package  might  be  delivered  together  with  other  MICROSAR 
embedded software. In this case, the OS is already included in the delivered package, and 
no separate installation is necessary. If MICROSAR OS is delivered stand alone, it comes 
up  with  an  installation  program,  which  installs  the  operating  system  source  files  and  the 
OIL  Configurator.  To  use  the  OS  with  ARXML  configurations,  the  DaVinci  configurator 
must be installed in addition. 
4.1 
Installation Requirements 
The installation program and the OIL Configurator are 32-bit Windows programs.  
Requirements: 
>  Microsoft Windows95, Windows98, Windows NT, Windows 2000, Windows XP, 
Windows Vista, Windows 7 
>  64 MByte of free disk space (for a complete installation) 
4.2 
Installation Disk 
All parts of the OSEK system, the OIL Configurator, and the code generator are delivered 
with a Windows installation program. The installation program copies all files onto the local 
hard disk and sets all paths in the INI files. The installation program asks the user for an 
installation path; this path is the root path for all installed components. The selected path is 
referred to in the following as root. The delivered installation uses the path  C:\OSEK as 
the default root path. 
There are two possible installation styles than can be selected: 
>  MICROSAR style: compatible with Vector AUTOSAR stack 
>  osCAN style: compatible with osCAN 
The installation paths are determined depending on the selected style 
The installed components are: 
 
Components 
osCAN style 
MICROSAR style 
OIL Configurator 
root\OILTOOL 
root\Generators\Tools\OilTool 
OSEK system 
root\HwPlatform 
root\BSW\Os 
Table 4-1  
Installed components 
2015, Vector Informatik GmbH 
Version: 9.01 
57 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
4.3 
OIL Configurator 
 
 
Info 
Please note that 'OIL Configurator' and 'OIL Tool' are used as synonyms in this 
  document. 
 
 
The  OIL  Configurator  is  a  common  tool  for  different  OSEK  implementations.  The 
implementation specific parts are the code generator and the OIL implementation files for 
the code generator. 
 
Components 
osCAN style 
MICROSAR style 
OIL Configurator 
root\OILTOOL 
root\Generators\Tools\OilTool 
OIL implementation files 
root\OILTOOL\GEN 
root\Generators\Os 
Code generator 
root\OILTOOL\GEN 
root\Generators\Os 
Table 4-2  
System configuration and generation tools 
4.3.1 
INI Files of the OIL Tool 
The OIL Configurator has two INI files, which are in the directory of the OIL Configurator: 
>  OILGEN.INI 
>  OILCFG.INI 
4.3.2 
OIL Implementation Files 
The  implementation  files  are  copied  onto  the  local  hard  disk  by  the  installation  program. 
The OIL tool has knowledge about these files through the INI file OILGEN.INI (the correct 
path is set by the installation program). 
The implementation files are described in the hardware specific part of this manual [4]. 
4.3.3 
Code Generator 
The  code  generator  GENxxxx.EXE  is  copied  onto  the  local  hard  disk  by  the  installation 
program.  The  code  generator  is  defined  in  the  INI-file  OILGEN.INI.  (‘xxxx’  has  to  be 
replaced by a hardware dependent abbreviation)   
4.4 
OSEK Operating System 
4.4.1 
Installation Paths 
The delivered operating system parts are organized in different subdirectories.  
The following structure is used by osCAN style installations: 
>  root\HwPlatform\APPL\Compiler\Derivative 
Sample applications 
>  root\HwPlatform\BIN 
executable files (e.g. make tool) 
>  root\HwPlatform\bswmd_files 
XML parameter descrption files 
2015, Vector Informatik GmbH 
Version: 9.01 
58 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
>  root\HwPlatform\DOC 
Documentation 
>  root\HwPlatform\INCLUDE 
OSEK include files 
>  root\HwPlatform\LIB 
OSEK library  (only if a library is available)  
>  root\HwPlatform\SRC 
OSEK sources (C and Assembler) 
 
The following structure is used by MICROSAR style installations: 
>  root\Demo\Os 
Sample applications 
>  root\Generators\Os 
executable files (e.g. make tool) 
>  root\Generators\Components\_Schemes\ 
XML parameter descrption files 
Os_<platform and derivate>_bswmd \bswmd 
>  root\Doc\TechnicalReferences 
Documentation 
>  root \Doc\UserManuals 
>  root\BSW\Os 
OSEK include files 
>  root\BSW\Os 
OSEK library  (only if a library is available)  
>  root\BSW\Os 
OSEK sources (C and Assembler) 
 
4.5 
XML Configurations 
AUTOSAR uses for configuration files the XML format. An XML Schema (ref. [8]) defines 
the structure. For each derivative there is an ECU Parameter Definition File (file extension 
is  arxml)  which  defines  all  attributes  (standard  attribute  and  vendor/platform  specific 
attributes). 
The  Vector  implementation  of AUTOSAR  OS  uses  the OIL  [6]  configuration file format or 
ECU Configuration files. A conversion of ECUC files to OIL, as it was necessary in former 
versions of MICROSAR OS, is not required any more. 
4.5.1 
Parameter Definition Files 
Parameter  Definition  Files  for  the  implementation  can  be  found  in  the  directory 
root\HwPlatform\BSWMD_files (osCAN style) or 
root\Generators\Components\_Schemes\Os_<platform and 
derivate>_bswmd\bswmd (MICROSAR style). 
The files have the name OS_<platform and derivate>_bswmd.arxml. 
2015, Vector Informatik GmbH 
Version: 9.01 
59 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
5  Integration 
This chapter gives necessary information for the integration of the MICROSAR OS into an 
application environment of an ECU. 
5.1  Scope of Delivery 
The delivery of the OS contains the files that are described in the chapters 5.1.1 and 5.1.2: 
5.1.1 
Static Files 
The static file list is described in the platform specific technical reference [4] 
5.1.2 
Dynamic Files 
The  dynamic  files  are  generated  by  the  code  generator  GENxxxx  (xxxx  is  replaced  by 
hardware platform name).  
5.1.2.1 
Code Generator GENxxxx 
File Name 
Description 
tcb.c 
tcb contains the task control block and other OS object  
tcb.h 
task and other OS object related information, like task Ids – definitions 
required by static include files (e.g. array sizes) 
tcbpost.h 
task and other OS object related information, like task Ids – declarations 
that require static include files (e.g. typedef's) 
trustfct.h 
Header containing trusted function information 
trustfct.c 
Trusted function data and generated stubs 
libconf 
Information for usage in makefiles, not available on all platforms, see 
chapter 5.1.2.1.1 
<OILFileName>.ort  Generated if kernel aware debugging with the ORTI interface is enabled, 
Table 5-1  
Files generated by code generator GENxxxx 
In  addition  to  the  files  listed  in  Table  5-1,  some  hardware  dependent  files  are  generated 
which are described in the hardware specific technical reference [4]. 
5.1.2.1.1 
Generated file libconf 
The  file  libconf  is  meant  for  the  inclusion  into  makefiles.  It  sets  some  variables  in 
accordance  to  general  configuration  settings  of  MICROSAR  OS  to  inform  the  make 
process about them. Dependent on the platform, the file may contain more information or 
be even unavailable, so please see the hardware specific technical reference [4].  
The table below describes the generated variables. 
 
 
2015, Vector Informatik GmbH 
Version: 9.01 
60 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Variable 
Meaning 
LIB 
Always 0, because MICROSAR OS SafeContext cannot be configured to library 
variant. 
STATUS_LEVEL 
Reflects the setting of the configuration attribute STATUS of MICROSAR OS. 
Possible values: 
EXTENDED_STATUS = 1 
DEBUG_SUPPORT 
Always 1, because ORTIDebugSupport is always enabled for MICROSAR OS 
SafeContext. 
Table 5-2  
Variables generated into the file libconf 
 
 
5.1.2.2 
Application Template Generator GENTMPL 
Former  versions  of  MICROSAR  OS  and  osCAN  came  with  a  template  code  generator 
which generates a main.c template file with empty implementations for the objects defined 
in the configuration. This is not supported any more in newer implementations. 
5.2  Include Structure 
The  header  files  tcb.h  and  tcbpost.h  are  included  into  the  file  os.h.  The  user  must 
include os.h in every module of his application. The headers tcb.h and tcbpost.h are 
included  automatically.  Always  recompile  all  files  after  a  new  generation  of  tcb.h  and 
tcbpost.h. 
If  an  application  is  using  trusted  functions  and  the  Vector  extension  “GenerateStubs”,  an 
include file named usrostyp.h must be present in the include path. This file must contain 
all user specific data types used for trusted functions. 
2015, Vector Informatik GmbH 
Version: 9.01 
61 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
6  API Description 
6.1  Standard API - Overview 
This  chapter  gives  an  overview  of  all  standard  API  functions  defined  for  the  OS.  The 
following synonyms present the standard specifications: 
>  ASR: AUTOSAR standard, reference [1] 
>  OSEK: OSEK standard, reference [3] 
These standard specifications contain the detailed API descriptions. In case part of an API 
function  is  implementation  specific,  the  detailed  API  description  is  given  in  a  further 
subchapter in this document. 
API Function Prototype 
Standard 
Scalability 
Specification  Class 
OSEK  ASR 
1  2  3  4 
Task Handling 
StatusType ActivateTask  (TaskType TaskID) 
 
 
       
StatusType TerminateTask (void) 
 
 
       
StatusType ChainTask      (TaskType TaskID) 
 
 
       
StatusType Schedule       (void) 
 
 
       
StatusType GetTaskID      (TaskRefType TaskID) 
 
 
       
StatusType GetTaskState  (TaskType TaskID, 
 
 
       
                                  TaskStateRefType State) 
Event Control 
StatusType SetEvent   (TaskType TaskID, 
 
 
       
                              EventMaskType Mask) 
StatusType ClearEvent (EventMaskType Mask) 
 
 
       
StatusType GetEvent   (TaskType TaskID, 
 
 
       
                              EventMaskRefType Mask) 
StatusType WaitEvent  (EventMaskType Mask) 
 
 
       
Interrupt Handling 
The behavior of the interrupt handling functions is implementation specific. For a detailed 
description see hardware specific technical reference [4]. 
void EnableAllInterrupts   (void) 
 
 
       
void DisableAllInterrupts (void) 
 
 
       
void ResumeAllInterrupts   (void) 
 
 
       
void SuspendAllInterrupts (void) 
 
 
       
void ResumeOSInterrupts    (void) 
 
 
       
void SuspendOSInterrupts   (void) 
 
 
       
2015, Vector Informatik GmbH 
Version: 9.01 
62 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
API Function Prototype 
Standard 
Scalability 
Specification  Class 
OSEK  ASR 
1  2  3  4 
Resource Management 
The behaviour of the resource management functions is implementation specific 
StatusType GetResource       (ResourceType ResID) 
 
 
       
StatusType ReleaseResource  (ResourceType ResID) 
 
 
       
Alarms 
StatusType GetAlarmBase  (AlarmType AlarmID, 
 
 
       
                                AlarmBaseRefType Info) 
StatusType GetAlarm       (AlarmType AlarmID, 
 
 
       
                                TickRefType Tick) 
StatusType SetRelAlarm   (AlarmType AlarmID, 
 
 
       
                                TickType Increment, 
                                TickType cycle) 
StatusType SetAbsAlarm   (AlarmType AlarmID, 
 
 
       
                                TickType Start, 
                                TickType cycle) 
StatusType CancelAlarm   (AlarmType AlarmID) 
 
 
       
Execution Control 
void           StartOS     (AppModeType Mode) 
 
 
       
void           ShutdownOS (StatusType Error) 
 
 
       
ISRType       GetISRID   (void) 
 
 
       
AppModeType GetActiveApplicationMode(void) 
 
 
       
ApplicationType  GetApplicationID     (void) 
 
 
 
 
   
StatusType   CallTrustedFunction 
 
 
 
 
   
  (TrustedFunctionIndexType FunctionIndex, 
  TrustedFunctionParameterRefType FunctionParams) 
StatusType   GetApplicationState 
 
 
 
 
   
  (ApplicationType Application, 
ApplicationStateRefType Value) 
Hook Routines 
The context for called hook routines is implementation specific. For a detailed description see 
see hardware specific technical reference [4]. 
void   ErrorHook              (StatusType Error) 
 
 
 
 
 
 
void   PreTaskHook           (void) 
 
 
 
 
 
 
void   PostTaskHook          (void) 
 
 
 
 
 
 
void   StartupHook           (void) 
 
 
 
 
 
 
void   ShutdownHook          (StatusType Error) 
 
 
 
 
 
 
ProtectionReturnType ProtectionHook 
 
 
 
     
                                  (StatusType Fatalerror) 
2015, Vector Informatik GmbH 
Version: 9.01 
63 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
API Function Prototype 
Standard 
Scalability 
Specification  Class 
OSEK  ASR 
1  2  3  4 
Schedule Tables 
StatusType   StartScheduleTableRel 
 
 
       
      (ScheduleTableType ScheduleTableID, 
        TickType Offset) 
StatusType   StartScheduleTableAbs 
 
 
       
      (ScheduleTableType ScheduleTableID, 
        TickType Start) 
StatusType   StopScheduleTable 
 
 
       
      (ScheduleTableType ScheduleTableID) 
StatusType   NextScheduleTable 
 
 
       
      (ScheduleTableType ScheduleTableID_From, 
        ScheduleTableType ScheduleTableID_To) 
StatusType   StartScheduleTableSynchron 
 
 
 
     
      (ScheduleTableType ScheduleTableID) 
StatusType   SyncScheduleTable 
 
 
 
     
      (ScheduleTableType ScheduleTableID, 
        TickType Value) 
StatusType   SetScheduleTableAsync 
 
 
 
     
      (ScheduleTableType ScheduleTableID) 
StatusType   GetScheduleTableStatus 
 
 
       
      (ScheduleTableType ScheduleTableID, 
        ScheduleTableStatusRefType ScheduleStatus) 
Counters 
StatusType   IncrementCounter 
 
 
       
      (CounterType CounterID) 
StatusType   GetCounterValue 
 
 
       
      (CounterType CounterID, TickRefType Value) 
StatusType   GetElapsedValue 
 
 
       
      (CounterType CounterID, TickRefType Value, 
        TickRefType ElapsedValue) 
Access Rights Management 
AccessType   CheckISRMemoryAccess 
 
 
 
 
   
      (ISRType ISRID, 
        MemoryStartAddressType Address, 
        MemorySizeType Size) 
AccessType   CheckTaskMemoryAccess 
 
 
 
 
   
      (TaskType TaskID, 
        MemoryStartAddressType Address, 
        MemorySizeType Size) 
ObjectAccessType CheckObjectAccess 
 
 
 
 
   
      (ApplicationType ApplID, 
        ObjectTypeType ObjectType, …) 
2015, Vector Informatik GmbH 
Version: 9.01 
64 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
API Function Prototype 
Standard 
Scalability 
Specification  Class 
OSEK  ASR 
1  2  3  4 
ApplicationType CheckObjectOwnership 
 
 
 
 
   
      (ObjectTypeType ObjectType, …) 
Table 6-1  
Standard API functions 
6.2  API Functions defined by Vector - Overview 
This chapter gives an overview of all API functions defined for the OS by Vector.  Further 
chapters contain detailed descriptions of these API functions. 
API Function Prototype 
Scalability 
Class 

1  2  3  4 
Measurement API 
For a detailed description see chapter 6.4. 
StatusType   GetTaskMaxExecutionTime 
 
     
        (TaskType TaskID, osTPTimeRefType MaxTime) 
StatusType   GetISRMaxExecutionTime 
 
     
        (ISRType TaskID, osTPTimeRefType MaxTime) 
StatusType   GetTaskMaxBlockingTime 
 
     
        (TaskType TaskID, BlockTypeType BlockType, 
          ResourceType ResourceID, osTPTimeRefType MaxTime) 
StatusType   GetISRMaxBlockingTime 
 
     
        (ISRType ISRID, BlockTypeType BlockType, 
          ResourceType ResourceID, osTPTimeRefType MaxTime) 
StatusType osGetISRMinInterArrivalTime 
 
     
         (ISRType ISRID, osTPTimeStampRefType MinTime) 
StatusType osGetTaskMinInterArrivalTime 
 
     
         (TaskType ISRID, osTPTimeStampRefType MinTime) 
Non-Trusted Functions 
Calling service functions from Non-Trusted Applications. The complement part of the AUTOSAR 
API CallTrustedFunction. 
StatusType   osCallNonTrustedFunction 
 
 
   
  (NonTrustedFunctionIndexType FunctionIndex, 
  NonTrustedFunctionParameterRefType FunctionParams) 
Peripheral Region API 
 
 
 
 
API to access memory mapped hardware registers, which are only accessible in 
privileged mode. 
osuint8  osReadPeripheral8(osuint16 area, osuint32 address) 
 
 
   
osuint16 osReadPeripheral16(osuint16 area, osuint32 address) 
 
 
   
osuint32 osReadPeripheral32(osuint16 area, osuint32 address) 
 
 
   
2015, Vector Informatik GmbH 
Version: 9.01 
65 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
API Function Prototype 
Scalability 
Class 

1  2  3  4 
void osWritePeripheral8(osuint16 area, osuint32 address, osuint8 
 
 
   
value) 
void osWritePeripheral16(osuint16 area, osuint32 address, osuint16 
 
 
   
value) 
void osWritePeripheral32(osuint16 area, osuint32 address, osuint32 
 
 
   
value) 
void osModifyPeripheral8(osuint16 area, osuint32 address, osuint8 
 
 
   
clearmask, osuint8 setmask) 
void osModifyPeripheral16(osuint16 area, osuint32 address, osuint16   
 
   
clearmask, osuint16 setmask) 
void osModifyPeripheral32(osuint16 area, osuint32 address, osuint32   
 
   
clearmask, osuint32 setmask) 
MPU Access Checking API 
 
 
 
 
Check whether you have read/write access to a given address. 
uint8 osCheckMPUAccess(uint8* DestinationAddress) 
 
 
   
Table 6-2  
Vector API functions 
6.3 
Timing Measurement API 
6.3.1 
GetTaskMaxExecutionTime 
Prototype 
StatusType GetTaskMaxExecutionTime ( TaskType TaskID, osTPTimeRefType MaxTime ) 
Parameter 
TaskID 
The task to be questioned 
MaxTime 
Maximum execution time, measured in all finished time frames. 
Return code 
E_OK 
No errors 
E_OS_ID 
The TaskID is not valid. 
Functional Description 
The maximum execution time of finished executions of the questioned task since StartOS. The value is in 
ticks of the ExecutionTime hardware timer. The number of ticks per ms of this timer is printed into the HTML 
list file.  
Particularities and Limitations 
>  Available in Scalability Classes 2 and 4. 
>  This function is synchronous. 
>  This function is reentrant. 
>  This function is only available if the attribute TimingMeasurement is set to TRUE (is selected) 
2015, Vector Informatik GmbH 
Version: 9.01 
66 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Expected Caller Context 
>  task  or cat2 ISR 
Table 6-3  
GetTaskMaxExecutionTime 
6.3.2 
GetISRMaxExecutionTime 
Prototype 
StatusType GetISRMaxExecutionTime ( ISRType  TaskID, osTPTimeRefType MaxTime ) 
Parameter 
TaskID 
The task to be questioned 
MaxTime 
Maximum execution time of the respective ISR for all finished ISR activations. 
Return code 
E_OK 
No errors 
E_OS_ID 
The ISRID is not valid. 
Functional Description 
The maximum execution time of finished executions of the questioned ISR since StartOS. The value is in 
ticks of the ExecutionTime hardware timer. The number of ticks per ms of this timer is printed into the HTML 
list file.  
Particularities and Limitations 
>  Available in Scalability Classes 2 and 4. 
>  This function is synchronous. 
>  This function is reentrant.  
>  This function is only available if the attribute TimingMeasurement is set to TRUE (is selected) 
Expected Caller Context 
>  task  or cat2 ISR 
Table 6-4  
GetISRMaxExecutionTime 
6.3.3 
GetTaskMaxBlockingTime 
Prototype 
StatusType GetTaskMaxBlockingTime 
    TaskType  TaskID, 
    BlockTypeType BlockType, 
    ResourceType  ResourceID, 
    osTPTimeRefType MaxTime ) 
Parameter 
TaskID 
The task to be questioned 
BlockType 
OS_ALL_INTERRUPTS, OS_OS_INTERRUPTS or OS_RESOURCE 
ResourceID 
If BlockType == OS_RESOURCE, ResourceID specifies the Resource 
2015, Vector Informatik GmbH 
Version: 9.01 
67 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
MaxTime 
Maximum of all measured times. 
Return code 
E_OK 
No errors 
E_OS_ID 
The TaskID, the BlockType or the ResourceID are invalid. 
Functional Description 
The maximum blocking time of finished locking sequences of the questioned task and the resource or 
interrupt lock type since StartOS. The value is in ticks of the BlockingTime hardware timer. The number of 
ticks per ms of this timer is printed into the HTML list file. 
Particularities and Limitations 
>  Available in Scalability Classes 2 and 4. 
>  This function is synchronous. 
>  This function is reentrant.  
>  This function is only available if the attribute TimingMeasurement is set to TRUE (is selected) 
Expected Caller Context 
>  task  or cat2 ISR 
Table 6-5  
GetTaskMaxBlockingTime 
6.3.4 
GetISRMaxBlockingTime 
Prototype 
StatusType GetISRMaxBlockingTime 
    ISRType  ISRID, 
    BlockTypeType BlockType, 
    ResourceType  ResourceID, 
    osTPTimeRefType MaxTime ) 
Parameter 
ISRID 
The ISR to be questioned 
BlockType 
OS_ALL_INTERRUPTS, OS_OS_INTERRUPTS or OS_RESOURCE 
ResourceID 
If BlockType == OS_RESOURCE, ResourceID specifies the Resource 
MaxTime 
Maximum of all measured times. 
Return code 
E_OK 
No errors 
E_OS_ID 
The TaskID, the BlockType or the ResourceID are invalid. 
Functional Description 
The maximum blocking time of finished locking sequences of the questioned ISR and the resource or 
interrupt lock type since StartOS. The value is in ticks of the BlockingTime hardware timer. The number of 
ticks per ms of this timer is printed into the HTML list file. 
Particularities and Limitations 
2015, Vector Informatik GmbH 
Version: 9.01 
68 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
>  Available in Scalability Classes 2 and 4. 
>  This function is synchronous. 
>  This function is reentrant.  
>  This function is only available if the attribute TimingMeasurement is set to TRUE (is selected) 
Expected Caller Context 
>  task  or cat2 ISR 
Table 6-6  
GetISRMaxBlockingTime 
6.3.5 
GetTaskMinInterArrivalTime 
Prototype 
StatusType GetTaskMinInterArrivalTime( TaskType TaskID, osTPTimeStampRefType 
MinTime ) 
Parameter 
TaskID 
The task to be questioned 
MinTime 
Minimum time between two task arrivals  
Return code 
E_OK 
No errors 
E_OS_ID 
The TaskID is not valid. 
E_OS_ACCESS 
No access rights to task (SC4 only) 
E_OS_ILLEGAL_ADDRESS  Memory address of MinTime not writeable (SC4 only) 
Functional Description 
Returns the minimum time span between two arrivals of a task (see [1]) as measured since StartOS. The 
value is in ticks of the InterArrivalTime hardware timer. The number of ticks per ms of this timer is printed 
into the HTML list file. 
Particularities and Limitations 
>  Available in Scalability Classes 2 and 4. 
>  This function is synchronous. 
>  This function is reentrant.  
>  This function is only available if the attribute TimingMeasurement is set to TRUE (is selected) 
2015, Vector Informatik GmbH 
Version: 9.01 
69 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Expected Caller Context 
>  task  or cat2 ISR 
Table 6-7  
GetTaskMinInterArrivalTime 
6.3.6 
GetISRMinInterArrivalTime 
Prototype 
StatusType GetISRMinInterArrivalTime ( ISRType IsrID, osTPTimeStampRefType 
MinTime ) 
Parameter 
IsrID 
The ISR to be questioned 
MinTime 
Minimum time between two ISR arrivals 
Return code 
E_OK 
No errors 
E_OS_ID 
The ISRID is not valid. 
E_OS_ACCESS 
No access rights for this ISR (SC4 only) 
E_OS_ILLEGAL_ADDRESS 
Memory address of MinTime not writeable (SC4 only) 
Functional Description 
Returns the minimum time span between two arrivals of an ISR (see [1]) as measured since StartOS. The 
value is in ticks of the InterArrivalTime hardware timer. The number of ticks per ms of this timer is printed 
into the HTML list file. 
Particularities and Limitations 
>  Available in Scalability Classes 2 and 4. 
>  This function is synchronous. 
>  This function is reentrant.  
>  This function is only available if the attribute TimingMeasurement is set to TRUE (is selected) 
Expected Caller Context 
>  task or cat2 ISR 
Table 6-8  
GetISRMinInterArrivalTime 
6.4 
Implementation specific Behavior 
The behaviour of the functions listed in this chapter is implementation specific.  
6.4.1 
Interrupt Handling  
In general the usage of the interrupt API functions is allowed before the operating system 
is started. The affected functions are:  
>  DisableAllInterupts 
>  EnableAllInterrupts 
2015, Vector Informatik GmbH 
Version: 9.01 
70 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
>  SuspendAllInterrupts 
>  ResumeAllInterrupts 
>  SuspendOSInterrupts 
>  ResumeOSInterrupts 
The implementation specific behaviour is of these functions is described in [5]. 
6.4.1.1 
EnableAllInterrupts 
Prototype 
void EnableAllInterrupts ( void ) 
Parameter 
-- 
-- 
Return code 
void 
-- 
Functional Description 
This service restores the state saved by DisableAllInterrupts. 
 
This service is a counterpart of DisableAllInterrupts service, which has to be called before, and its 
aim is the completion of the critical section of code. No API service calls are allowed within this critical 
section. 
 
The implementation should adapt this service to the target hardware providing a minimum overhead. 
Usually, this service enables recognition of interrupts by the central processing unit. 
 
This function might be implemented using a global interrupt flag or an interrupt level register. 
Particularities and Limitations 
>  When using before StartOS, the function osInitialize must be called first to initialize the variables 
which are used in the interrupt API. 
>  The function must not be used within handlers of non-maskable interrupts as this can violate the 
consistancy of internal variables. 
Expected Caller Context 
>  -- 
Table 6-9  
EnableAllInterrupts 
 
2015, Vector Informatik GmbH 
Version: 9.01 
71 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
6.4.1.2 
DisableAllInterrupts 
Prototype 
void DisableAllInterrupts ( void ) 
Parameter 
-- 
-- 
Return code 
Void 
-- 
Functional Description 
This service disables all interrupts for which the hardware supports disabling. The state before is saved for 
the EnableAllInterrupts call.  
This service is intended to start a critical section of the code. This section shall be finished by calling the 
EnableAllInterrupts service. No API service calls are allowed within this critical section. 
The implementation should adapt this service to the target hardware providing a minimum overhead. 
Usually, this service disables recognition of interrupts by the central processing unit. 
Note that this service does not support nesting. If nesting is needed for critical sections e.g. for libraries 
SuspendOSInterrupts/ResumeOSInterrupts or SuspendAllInterrupt/ResumeAllInterrupts 
should be used. 
This function might be implemented using a global interrupt flag or an interrupt level register. 
Particularities and Limitations 
>  When using before StartOS, the function osInitialize must be called first to initialize the variables 
which are used in the interrupt API. 
>  The function must not be used within handlers of non-maskable interrupts as this can violate the 
consistancy of internal variables. 
Expected Caller Context 
>  -- 
Table 6-10   DisableAllInterrupts 
6.4.1.3 
ResumeAllInterrupts 
Prototype 
void ResumeAllInterrupts ( void ) 
Parameter 
-- 
-- 
Return code 
void 
-- 
2015, Vector Informatik GmbH 
Version: 9.01 
72 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Functional Description 
This service restores the recognition status of all interrupts saved by the SuspendAllInterrupts 
service.  
 
This service is the counterpart of SuspendAllInterrupts service, which has to have been called 
before, and its aim is the completion of the critical section of code. No API service calls beside 
SuspendAllInterrupts/ResumeAllInterrupts pairs and 
SuspendOSInterrupts/ResumeOSInterrupts pairs are allowed within this critical section. 
 
The implementation should adapt this service to the target hardware providing a minimum overhead. 
SuspendAllInterrupts/ResumeAllInterrupts can be nested. In case of nesting pairs of the calls 
SuspendAllInterrupts and ResumeAllInterrupts the interrupt recognition status saved by the first 
call of SuspendAllInterrupts is restored by the last call of the ResumeAllInterrupts service. 
 
This function might be implemented using a global interrupt flag or an interrupt level register. 
Particularities and Limitations 
>  When using before StartOS, the function osInitialize must be called first to initialize the variables 
which are used in the interrupt API. 
>  The function must not be used within handlers of non-maskable interrupts as this can violate the 
consistancy of internal variables. 
Expected Caller Context 
>  -- 
Table 6-11   ResumeAllInterrupts 
6.4.1.4 
SuspendAllInterrupts 
Prototype 
void SuspendAllInterrupts ( void ) 
Parameter 
-- 
-- 
Return code 
void 
-- 
2015, Vector Informatik GmbH 
Version: 9.01 
73 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Functional Description 
This service saves the recognition status of all interrupts and disables all interrupts for which the hardware 
supports disabling. 
 
This service is intended to protect a critical section of code from interruptions of any kind. This section shall 
be finished by calling the ResumeAllInterrupts service. No API service calls beside 
SuspendAllInterrupts/ResumeAllInterrupts pairs and 
SuspendOSInterrupts/ResumeOSInterrupts pairs are allowed within this critical section. 
The implementation should adapt this service to the target hardware providing a minimum overhead. 
 
This function might be implemented using a global interrupt flag or an interrupt level register. 
Particularities and Limitations 
>  When using before StartOS, the function osInitialize must be called first to initialize the variables 
which are used in the interrupt API. 
>  The function must not be used within handlers of non-maskable interrupts as this can violate the 
consistancy of internal variables. 
Expected Caller Context 
>  -- 
Table 6-12   SuspendAllInterrupts 
6.4.1.5 
ResumeOSInterrupts 
Prototype 
void ResumeOSInterrupts ( void ) 
Parameter 
-- 
-- 
Return code 
void 
-- 
Functional Description 
This service restores the recognition status of interrupts saved by the SuspendOSInterrupts service. 
 
This service is the counterpart of SuspendOSInterrupts service, which has to have been called before, 
and its aim is the completion of the critical section of code. No API service calls beside 
SuspendAllInterrupts/ResumeAllInterrupts pairs and 
SuspendOSInterrupts/ResumeOSInterrupts pairs are allowed within this critical section. 
The implementation should adapt this service to the target hardware providing a minimum overhead. 
SuspendOSInterrupts/ResumeOSInterrupts can be nested. In case of nesting pairs of the calls 
SuspendOSInterrupts and ResumeOSInterrupts the interrupt recognition status saved by the first 
call of SuspendOSInterrupts is restored by the last call of the ResumeOSInterrupts service. 
 
This function might be implemented using a global interrupt flag or an interrupt level register 
2015, Vector Informatik GmbH 
Version: 9.01 
74 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Particularities and Limitations 
>  When using before StartOS, the function osInitialize must be called first to initialize the variables 
which are used in the interrupt API. 
>  The function must not be used within handlers of non-maskable interrupts as this can violate the 
consistancy of internal variables. 
Expected Caller Context 
>  -- 
Table 6-13   ResumeOSInterrupts 
6.4.1.6 
SuspendOSInterrupts 
Prototype 
void SuspendOSInterrupts ( void ) 
Parameter 
-- 
-- 
Return code 
void 
-- 
Functional Description 
This service saves the recognition status of interrupts of category 2 and disables the recognition of these 
interrupts. 
 
This service is intended to protect a critical section of code. This section shall be finished by calling the 
ResumeOSInterrupts service. No API service calls beside 
SuspendAllInterrupts/ResumeAllInterrupts pairs and 
SuspendOSInterrupts/ResumeOSInterrupts pairs are allowed within this critical section. 
 
The implementation should adapt this service to the target hardware providing a minimum overhead. 
It is intended only to disable interrupts of category 2. However, if this is not possible in an efficient way 
more interrupts may be disabled. 
 
This function might be implemented using a global interrupt flag or an interrupt level register. 
Particularities and Limitations 
>  When using before StartOS, the function osInitialize must be called first to initialize the variables 
which are used in the interrupt API. 
>  The function must not be used within handlers of non-maskable interrupts as this can violate the 
consistancy of internal variables. 
2015, Vector Informatik GmbH 
Version: 9.01 
75 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Expected Caller Context 
>  -- 
Table 6-14   SuspendOSInterrupts 
6.4.2 
Resource Management 
The affected functions are: 
>  GetResource 
>  ReleaseResource 
The implementation specific behaviour is of these functions is described in [4]. 
6.4.2.1 
GetResource 
Prototype 
StatusType GetResource ( ResourceType ResID ) 
Parameter 
ResID 
Reference to resource 
Return code 
E_OK 
No error 
E_OS_ID 
Resource ResID is invalid 
E_OS_ACCESS 
Attempt to get a resource which is already occupied by any task or ISR, or the 
statically assigned priority of the calling task or interrupt routine is higher than 
the calculated ceiling priority. 
2015, Vector Informatik GmbH 
Version: 9.01 
76 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Functional Description 
This call serves to enter critical sections in the code that are assigned to the resource referenced by 
ResID. A critical section shall always be left using ReleaseResource. 
 
Nested resource occupation is only allowed if the inner critical sections are completely executed within the 
surrounding critical section (strictly stacked, Restrictions when using resources). Nested occupation of one 
and the same resource is also forbidden!  
 
It is recommended that corresponding calls to GetResource and ReleaseResource appear within the 
same function.  
 
It is not allowed to use services which are points of rescheduling for non preemptable tasks 
(TerminateTask, ChainTask, Schedule and WaitEvent) in critical sections. Additionally, critical 
sections are to be left before completion of an interrupt service routine.  
 
Generally speaking, critical sections should be short.  
The service may be called from an ISR and from task level. 
 
Depending on the possibility to manipulate interrupt levels, this function may be used on interrupt level or 
not and may be implemented differently. 
If used on task level, the behavior and functionality is always the same (according to the specification). 
Particularities and Limitations 
>  -- 
Expected Caller Context 
>  Task level or cat2 ISR 
Table 6-15   GetResource 
6.4.2.2 
ReleaseResource 
Prototype 
StatusType ReleaseResource ( ResourceType ResID ) 
Parameter 
ResID 
Reference to resource 
Return code 
E_OK 
No error 
E_OS_ID 
Resource ResID is invalid 
E_OS_NOFUNC 
Attempt to release a resource which is not occupied by any task or ISR, or 
another resource shall be released before. 
E_OS_ACCESS 
Attempt to release a resource that has a lower ceiling priority than the 
statically assigned priority of the calling task or interrupt routine. 
2015, Vector Informatik GmbH 
Version: 9.01 
77 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Functional Description 
ReleaseResource is the counterpart of GetResource and serves to leave critical sections in the code that 
are assigned to the resource referenced by ResID. 
 
For information on nesting conditions, see particularities of GetResource. 
 
The service may be called from an ISR and from task level. 
 
Depending on the possibility to manipulate interrupt levels, this function may be used on interrupt level or 
not and may be implemented differently. 
If used on task level, the behavior and functionality is always the same (according to the specification). 
Particularities and Limitations 
>  -- 
Expected Caller Context 
>  Task level or cat2 ISR 
Table 6-16   ReleaseResource 
6.4.3 
Execution Control 
The affected functions are: 
>  StartOS 
>  ShutdownOS 
The implementation specific behavior is of these functions is described in [4]. 
6.4.3.1 
StartOS 
Prototype 
void StartOS ( AppModeType Mode ) 
Parameter 
Mode 
application mode 
Return code 
void 
-- 
Functional Description 
The user can call this system service to start the operating system in a specific mode. 
 
Only allowed outside of the operating system, therefore implementation specific restrictions may apply. 
 
After calling StartOS the program never returns to the call level of StartOS. 
Particularities and Limitations 
>  -- 
2015, Vector Informatik GmbH 
Version: 9.01 
78 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Expected Caller Context 
>  C main function 
Table 6-17   StartOS 
 
6.4.3.2 
ShutdownOS 
Prototype 
void ShutdownOS ( StatusType Error ) 
Parameter 
Error 
error occurred 
Return code 
void 
-- 
Functional Description 
The user can call this system service to abort the overall system (e.g. emergency off). The operating 
system also calls this function internally, if it has reached an undefined internal state and is no longer ready 
to run. 
 
If a ShutdownHook is configured the hook routine ShutdownHook is always called (with Error as 
argument) before shutting down the operating system. 
 
If ShutdownHook returns, further behaviour of ShutdownOS is implementation specific. 
 
In case of a system where OSEK OS and OSEKtime OS coexist, ShutdownHook has to return. 
 
Error needs to be a valid error code supported by OSEK OS. In case of a system where OSEK OS and 
OSEKtime OS coexist, Error might also be a value accepted by OSEKtime OS. In this case, if enabled by 
an OSEKtime configuration parameter, OSEKtime OS will be shut down after OSEK OS shutdown. 
 
After this service the operating system is shut down. 
Allowed at task level, ISR level, in ErrorHook and StartupHook, and also called internally by the 
operating system. 
If the operating system calls ShutdownOS it never uses E_OK as the passed parameter value. 
 
After the call of ShutdownHook MICROSAR OS disables all interrupts and will never return to the call 
level. The ShutdownHook is called with disabled interrupts. 
Particularities and Limitations 
>  -- 
2015, Vector Informatik GmbH 
Version: 9.01 
79 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Expected Caller Context 
>  -- 
Table 6-18   ShutdownOS 
6.5 
Hook Routines 
MICROSAR OS calls several hook routines. These may be hook routines as described in 
the  OSEK  or Autosar  standard. Additionally,  MICROSAR  provides  Hook  routines  for  ISR 
entry/exit, Alarm time and timing supervision (MICROSAR OS Timing Hooks). 
These hook routines are described in the subchapters below. 
The  subchapters  describe  the  prototypes  of  the  called  hook  routines  and  their  calling 
contexts. The current stack in the hook routines is  implementation specific and described 
in [4]. 
6.5.1 
Standard Hooks 
The  hook  routines  described  in  the  subchapters  are  defined  by  the  OSEK  and  Autosar 
standards. 
All  these  hook  routines  need  to  be  implemented  by  the  user  if  they  are  enabled  in  the 
configuration.  The  OS  calls  these  hook  routines  with  interrupts  disabled  (if  not  stated 
otherwise). 
6.5.1.1 
StartupHook 
Prototypes 
void StartupHook ( void ) /* general startup hook */ 
void StartupHook_<App> ( void ) /* application specific startup hook */ 
Parameter 
-- 
-- 
Return code 
void 
-- 
Functional Description 
The user may call the initialization routines for hardware drivers. 
Particularities and Limitations 
>  -- 
Call Context 
>  interrupt or task context 
>  The StartupHook routine is called while the operating system is initialized. 
Table 6-19   StartupHook 
2015, Vector Informatik GmbH 
Version: 9.01 
80 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
6.5.1.2 
PreTaskHook 
Prototype 
void PreTaskHook ( void ) 
Parameter 
-- 
-- 
Return code 
void 
-- 
Functional Description 
The user can use the API function GetTaskID to determine the new task. 
Particularities and Limitations 
>  The PreTaskHook may only be configured for debugging purpose in MICROSAR OS SafeContext, see 
[9]. 
Call Context 
>  interrupt or task context 
>  PreTaskHook is called after a task is set into the RUNNING state (not into the READY state). 
>  For particularities of using PreTaskHook when using timing protection, please see [4] 
Table 6-20   PreTaskHook 
6.5.1.3 
PostTaskHook 
Prototype 
void PostTaskHook ( void ) 
Parameter 
-- 
-- 
Return code 
void 
-- 
Functional Description 
The user can use the API function GetTaskID to determine the currently left task. 
Particularities and Limitations 
>  The PostTaskHook may only be configured for debugging purpose in MICROSAR OS SafeContext, see 
[9]. 
Call Context 
>  interrupt or task context 
>  PostTaskHook is called before a task is taken out of the RUNNING state. 
>  For particularities of using the PostTaskHook when using timing protection, please see [4] 
Table 6-21   PostTaskHook 
 
2015, Vector Informatik GmbH 
Version: 9.01 
81 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
6.5.1.4 
ErrorHook 
Prototype 
void ErrorHook ( StatusType ErrorCode ) /* general error hook */ 
void ErrorHook_<App> ( StatusType ErrorCode ) /* appl. spec. error hook */ 
Parameter 
ErrorCode 
Error code of API which detected the error and called the error hook 
Return code 
void 
-- 
Functional Description 
The user may use the error number parameter to decide how to react on the error. 
 
Additional error information is available in the error hook if the attributes USEGETSERVICEID and 
USEPARAMETERACCESS are set to TRUE. This information can be accessed by access macros; for details 
refer to the OSEK specification [3]. All possible access macros are supported by MICROSAR OS. 
 
If EXTENDED_STATUS is enabled and ErrorInfoLevel is set to Modulnames, additional error 
information is available in the ErrorHook. The variable osActiveTaskModule is a pointer to the module 
name and the variable osActiveTaskLineNumber is the line number in the C module where the API 
function was called. Inspecting these two variables allows the user to locate the source code that caused 
the error message. 
 
Particularities and Limitations 
>  -- 
Call Context 
>  interrupt or task context 
>  ErrorHook is called every time an API function is called with wrong parameters or if the system detects 
an error (e.g. stack overflow). 
Table 6-22   ErrorHook 
6.5.1.5 
ShutdownHook 
Prototype 
void ShutdownHook ( StatusType ErrorCode ) /* general shutdown hook */ 
void ShutdownHook_<App> (StatusType ErrorCode) /* appl. spec. shutdown hook */ 
Parameter 
ErrorCode 
Error code of API that detected the error and called the shutdown hook, or the 
parameter that was passed to ShutdownOS. 
Return code 
void 
-- 
2015, Vector Informatik GmbH 
Version: 9.01 
82 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Functional Description 
The ShutdownHook is called by ShutdownOS 
Particularities and Limitations 
>  -- 
Call Context 
>  interrupt or task context 
>  The system calls the ShutdownHook routine if the function ShutdownOS was called. 
Table 6-23   ShutdownHook 
6.5.1.6 
ProtectionHook 
Prototype 
ProtectionReturnType ProtectionHook ( StatusType Fatalerror ) 
Parameter 
Fatalerror 
depending on the detected protection error 
Return code 
ProtectionReturnType 
The return value determines the strategy of further operation 
Functional Description 
Called on occurrence of a protection error. The application code has to decide about the recovery strategy 
and pass an appropriate return value to the OS. 
Particularities and Limitations 
>  In the scalability class SC1, no call of the ProtectionHook is supported. 
Call Context 
>  interrupt or task context 
>  The ProtectionHook is called if a TimingProtection failure (SC2, SC4), a memory protection failure 
(SC3, SC4), or processor exception (e.g. division by zero, illegal instruction etc.) is detected by 
MICROSAR OS.  
Table 6-24   ProtectionHook 
6.5.2 
ISR Hooks 
6.5.2.1 
UserPreISRHook 
Prototype 
Void UserPreISRHook ( ISRType isr ) 
Parameter 
Isr 
The identifier of the ISR that is about to be entered 
Return code 
Void 
-- 
2015, Vector Informatik GmbH 
Version: 9.01 
83 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Functional Description 
Called just before entering an ISR routine of a category 2 interrupt. 
This Hook is intended to be used as a development aid. For example, it may be used to measure interrupt 
run times. 
This Hook is only available if the attribute CallISRHooks is set to TRUE. Note that this is allowed only for 
debugging purpose in MICROSAR OS SafeContext, see [9]. 
Particularities and Limitations 
>  Only API functions that are allowed in cat2 ISRs are allowed to be called in the UserPreISRHook. 
Call Context 
>  The UserPreISRHook runs in the exact same context as the ISR that is executed afterwards. This 
includes settings for interrupt nesting, timing protection, timing measurement and memory protection. 
>  All OS API functions, incl. GetISRID(), GetApplicationID(), CheckObjectAccess() etc, work just as if 
called from within the ISR 
Table 6-25   UserPreISRHook 
6.5.2.2 
UserPostISRHook 
Prototype 
Void UserPostISRHook ( ISRType isr ) 
Parameter 
Isr 
The identifier of the ISR that was just left 
Return code 
Void 
-- 
Functional Description 
Called just after leaving an ISR routine of a category 2 interrupt. 
This Hook is intended to be used as a development aid. For example, it may be used to measure interrupt 
run times. 
This Hook is only available if the attribute CallISRHooks is set to TRUE. Note that this is allowed only for 
debugging purpose in MICROSAR OS SafeContext, see [9]. 
Particularities and Limitations 
The UserPostISRHook is called only after a regular return from the ISR routine. In particular: 
>  If an ISR is interrupted by a higher priority ISR, the UserPostISRHook is not called before entering the 
new ISR.  
>  If an ISR is killed, the UserPostISRHook is not called. 
>  Only API functions that are allowed in cat2 ISRs are allowed to be called in the UserPostISRHook. 
Call Context 
>  The UserPreISRHook runs in the exact same context as the ISR that was just executed. This includes 
settings for interrupt nesting, timing protection, timing measurement and memory protection. 
>  All OS API functions, incl. GetISRID(), GetApplicationID(), CheckObjectAccess() etc, work just as if 
called from within the ISR 
Table 6-26   UserPostISRHook 
2015, Vector Informatik GmbH 
Version: 9.01 
84 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
6.5.3 
Alarm Hook 
6.5.3.1 
PreAlarmHook (currently not supported) 
Prototype 
void PreAlarmHook_<CounterName> (void) 
Parameter 
void 
-- 
Return code 
void 
-- 
Functional Description 
Called in the timer ISR just before the alarm handling of the OS. 
This Hook is only available if the timer attribute PreAlarmHook is set to TRUE 
Particularities and Limitations 
>  Note that this feature is currently not supported. It will be available in future releases. 
>  Only API functions that are allowed in cat2 ISRs are allowed to be called in the PreAlarmHook. 
>  The execution time of the PreAlarmHook is not considered by the timing protection. 
Call Context 
>  The PreAlarmHook runs in the same context as the system timer ISR. If an owner application is 
configured, the system timer ISR and the PreAlarmHook is executed with the application rights of this 
owner application. 
>  Interrupts of category 2 are disabled during the execution of the PreAlarmHook. 
Table 6-27   PreAlarmHook 
6.5.4 
MICROSAR OS Timing Hooks 
MICROSAR  OS  supports  timing  measurement  and  analysis  by  external  tools. Therefor  it 
provides timing hooks. Timing hooks inform the external tools about  several events within 
the OS: 
 
Activation (arrival) of a task or ISR 
 
Context switch 
 
Locking of interrupts, resources or spinlocks 
This documentation presents the respective hook routines in separate subchapters below. 
The OS calls Timing hooks only if the user has configured them as described in Table 7-1, 
attribute  TimingHooks.  The  user  shall  implement  the  hooks  as  macros  in  the  configured 
header file. The OS provides empty definitions of these hooks. It uses the empty definition 
of a hook in case of an unavailable definition by the user. Because of the empty definition, 
the user needs not to implement all hooks. 
2015, Vector Informatik GmbH 
Version: 9.01 
85 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
6.5.4.1 
Hooks for arrival 
MICROSAR OS prvides hooks that allow an external tool to trace all activations of task as 
well  as  further  arrivals  like  the  setting  of  an  event  or  the  release  of  a  semaphore  with 
transfer to another task. 
This shall allow the external tool to visualize the arrivals and to measure the time between 
them in order to allow a schedulability analysis.  
Mind that  schedulability analysis requires  the minimum time between arrivals while these 
hooks only provide measured values. 
6.5.4.1.1 
OS_VTH_ACTIVATION 
Prototype 
OS_VTH_ACTIVATION( TaskId, DestCoreId, CallerCoreId) 
Parameter 
TaskId 
Identifier of the task which is activated 
DestCoreId 
Identifier of the core on which the task is activated 
CallerCoreId 
Identifier of the core which performs the activation (has called ActivateTask, 
has called TerminateTask or has performed an alarm/schedule table action to 
activate a task) 
Return code 


Functional Description 
This hook is called on the caller core when that core has successfully performed the activation of TaskId on 
the destination core. On single core systems both core IDs are always identical. 
Particularities and Limitations 
>  The hook is expected to be implemented as a macro. 
>  Reentrancy is possible on multicore systems with different caller core IDs 
>  Call of any operating system API function is prohibited in this hook routine 
Call context 
>  The hook routine is called from within operating system API functions with interrupts disabled. 
Table 6-28   OS_VTH_ACTIVATION 
6.5.4.1.2 
OS_VTH_SETEVENT 
Prototype 
OS_VTH_SETEVENT( TaskId, EventMask, StateChange, DestCoreId, CallerCoreId) 
Parameter 
TaskId 
Identifier of the task which receives this event 
EventMask 
A bit mask with the events which shall be set 
2015, Vector Informatik GmbH 
Version: 9.01 
86 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
StateChange 
TRUE: The task state has changed from WAITING to READY 
FALSE: The task state hasn’t changed 
DestCoreId 
Identifier of the core on which the task receives the event 
CallerCoreId 
Identifier of the core which performs the event setting (has called SetEvent or 
performed an alarm/schedule table action to set an event) 
Return code 


Functional Description 
This hook is called on the caller core when that core has successfully performed the event setting on the 
destination core. On single core systems both core IDs are always identical. 
Particularities and Limitations 
>  The hook is expected to be implemented as a macro. 
>  Reentrancy is possible on multicore systems with different caller core IDs 
>  Call of any operating system API function is prohibited in this hook routine 
Call context 
>  The hook routine is called from within operating system API functions with interrupts disabled. 
Table 6-29   OS_VTH_SETEVENT 
6.5.4.1.3 
OS_VTH_TRANSFER_SEMA 
Prototype 
OS_VTH_TRANSFER_SEMA( FromThreadId, ToTaskId, SemaId, DestCoreId, CallerCoreId) 
Parameter 
FromThreadId 
Identifier of the thread (task; ISR) which releases the semaphore 
ToTaskId 
Identifier ot the task which receives the semaphore 
SemaId 
Identifier of the semaphore to be transferred 
DestCoreId 
Identifier of the core on which the task igets the semaphore 
CallerCoreId 
Identifier of the core which releases the semaphore 
Return code 


Functional Description 
This hook is called on the caller core when that core has successfully performed release of the semaphore 
while a task was waiting for that semaphore. On single core systems both core IDs are always identical. 
2015, Vector Informatik GmbH 
Version: 9.01 
87 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Particularities and Limitations 
>  The hook is expected to be implemented as a macro. 
>  Reentrancy is possible on multicore systems with different caller core IDs 
>  Call of any operating system API function is prohibited in this hook routine 
>  The semaphore feature is optional, so this macro may not be necessary on all implementations of 
MICROSAR OS. 
Call context 
>  The hook routine is called from within operating system API functions with interrupts disabled. 
Table 6-30   OS_VTH_TRANSFER_SEMA 
6.5.4.2 
Hook for context switch 
MICROSAR  OS  provides  a  hook  routine  allowing  external  tools  to  trace  all  context 
switches  from  task  to  ISR  and  back  as  well  as  between  tasks.  So  external  tools  may 
visualize the information or measure the execution time of tasks and ISRs. 
Mind that measured values may not reflect the worst case, which would be necessary for 
schedulability analysis. 
6.5.4.2.1 
OS_VTH_SCHEDULE 
Prototype 
OS_VTH_SCHEDULE( FromThreadId, FromThreadReason,  
                 ToThreadId,   ToThreadReason,  
                 CallerCoreId                      ) 
Parameter 
FromThreadId 
Identifier of the thread (task, ISR) which has run on the caller core before the 
switch took place 
FromThreadReason 
OS_VTHP_TASK_TERMINATION: The thread is a task, which has just been 
terminated. 
OS_VTHP_ISR_END: The thread is an ISR, which has reached its end. 
OS_VTHP_TASK_WAITEVENT: The thread is a task, which waits for an 
event. 
OS_VTHP_TASK_WAITSEMA: The thread is a task, which waits tor the 
release of a semaphore. 
OS_VTHP_THREAD_PREEMPT: The thread is interrupted by another one, 
which has higher priority. 
ToThreadId 
The identifier of the thread, which will run from now on 
2015, Vector Informatik GmbH 
Version: 9.01 
88 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
ToThreadReason 
OS_VTHP_TASK_ACTIVATION: The thread is a task, which was activated. 
OS_VTHP_ISR_START: The thread is an ISR, which will now start execution. 
OS_VTHP_TASK_SETEVENT: The thread is a task, which has just received 
an event it was waiting for. It resumes execution right behind the call of 
WaitEvent. 
OS_VTHP_GOTSEMA: The thread is a task, which has just got the 
semaphore it was waiting for. 
OS_VTHP_THREAD_RESUME: The thread is a task or ISR, which was 
preempted before and becomes running again as all higher priority tasks and 
ISRs do not run anymore. 
CallerCoreId 
Identifier of the core which performs the thread switch 
Return code 


Functional Description 
This hook is called on the caller core when that core in case it performs a thread switch (from one task or 
ISR to another task or ISR). On single core systems both core IDs are always identical. 
Particularities and Limitations 
>  The hook is expected to be implemented as a macro. 
>  Reentrancy is possible on multicore systems with different caller core IDs 
>  Call of any operating system API function is prohibited in this hook routine 
Call context 
>  The hook routine is called from within operating system internal functions with interrupts disabled. 
Table 6-31   OS_VTH_SCHEDULE 
 
6.5.4.3 
Hooks for locking 
MICROSAR  OS  provides  hooks,  which  allow  an  external  tool  to  trace  locks.  This  is 
important  as  locking  times  of  tasks  and  ISRs  influence  the  exectution  of  other  tasks  and 
ISRs.  The  kind  of  influence  is  different  for  different  locks  and  is  presented  below  in  the 
functional description of the respective hooks.  
Please keep in mind that measured times for locking may not reflect the worst case. 
6.5.4.3.1 
OS_VTH_GOT_RES 
Prototype 
OS_VTH_GOT_RES( ResId, CallerCoreId) 
Parameter 
ResId 
Identifier of the resource which has been taken 
CallerCoreId 
Identifier of the core where GetResorce was called 
2015, Vector Informatik GmbH 
Version: 9.01 
89 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Return code 


Functional Description 
The OS calls this hook on a successful call of the API function GetResource. The priority of the calling task 
or ISR has been increased so that other tasks and ISRs on the same core may need to wait until they can 
be executed. 
Particularities and Limitations 
>  The hook is expected to be implemented as a macro. 
>  Reentrancy is possible on multicore systems with different caller core IDs 
>  Call of any operating system API function is prohibited in this hook routine 
Call context 
>  The hook routine is called from within operating system API functions with interrupts disabled. 
Table 6-32   OS_VTH_GOT_RES 
6.5.4.3.2 
OS_VTH_REL_RES 
Prototype 
OS_VTH_REL_RES( ResId, CallerCoreId) 
Parameter 
ResId 
Identifier of the resource which has been released 
CallerCoreId 
Identifier of the core where ReleaseResorce was called 
Return code 


Functional Description 
The OS calls this hook on a successful call of the API function ReleaseResource. The priority of the calling 
task or ISR has been decreased so that other tasks and ISRs on the same core may become running as a 
result. 
Particularities and Limitations 
>  The hook is expected to be implemented as a macro. 
>  Reentrancy is possible on multicore systems with different caller core IDs 
>  Call of any operating system API function is prohibited in this hook routine 
Call context 
>  The hook routine is called from within operating system API functions with interrupts disabled. 
Table 6-33   OS_VTH_REL_RES 
6.5.4.3.3 
OS_VTH_REQ_SPINLOCK 
Prototype 
OS_VTH_REQ_SPINLOCK( SpinlockId, CallerCoreId) 
2015, Vector Informatik GmbH 
Version: 9.01 
90 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Parameter 
SpinlockId 
Identifier of the spinlock which has been requested 
CallerCoreId 
Identifier of the core where GetSpinlock was called 
Return code 


Functional Description 
The OS calls this hook on an unsuccessfull attempt to get a spinlock. The calling task or ISR enters a busy 
waiting state. Tasks or ISRs of lower priority have to wait until this task or ISR has taken and released the 
spinlock. 
Particularities and Limitations 
>  The hook is expected to be implemented as a macro. 
>  Reentrancy is possible on multicore systems with different caller core IDs 
>  Call of any operating system API function is prohibited in this hook routine 
>  The hook is not called for optimized spinlocks 
>  The hook is not called for operating system internal spinlocks 
>  The hook is called only on multicore operating system implementations 
Call context 
>  The hook routine is called from within operating system API functions with interrupts disabled. 
Table 6-34   OS_VTH_REQ_SPINLOCK 
 
6.5.4.3.4 
OS_VTH_GOT_SPINLOCK 
Prototype 
OS_VTH_GOT_SPINLOCK( SpinlockId, CallerCoreId) 
Parameter 
SpinlockId 
Identifier of the spinlock which has been taken 
CallerCoreId 
Identifier of the core where GetSpinlock or TryToGetSpinlock were called 
Return code 


Functional Description 
The OS calls this hook whenever a spinlock has successfully been taken. If the task or ISR was not 
successful immediately (entered busy waiting state), this hook means that it leaves the busy waiting state. 
From now on no other task or ISR may get the spinlock until the current task or ISR has released it.  
2015, Vector Informatik GmbH 
Version: 9.01 
91 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Particularities and Limitations 
>  The hook is expected to be implemented as a macro. 
>  Reentrancy is possible on multicore systems with different caller core IDs 
>  Call of any operating system API function is prohibited in this hook routine 
>  The hook is not called for optimized spinlocks 
>  The hook is not called for operating system internal spinlocks 
>  The hook is called only on multicore operating system implementations 
Call context 
>  The hook routine is called from within operating system API functions with interrupts disabled. 
Table 6-35   OS_VTH_GOT_SPINLOCK 
 
6.5.4.3.5 
OS_VTH_REL_SPINLOCK 
Prototype 
OS_VTH_REL_SPINLOCK( SpinlockId, CallerCoreId) 
Parameter 
SpinlockId 
Identifier of the spinlock which has been released 
CallerCoreId 
Identifier of the core where ReleaseSpinlock was called 
Return code 


Functional Description 
The OS calls this hook on a release of a spinlock. Other tasks and ISR may take the spinlock now. 
Particularities and Limitations 
>  The hook is expected to be implemented as a macro. 
>  Reentrancy is possible on multicore systems with different caller core IDs 
>  Call of any operating system API function is prohibited in this hook routine 
>  The hook is not called for optimized spinlocks 
>  The hook is not called for operating system internal spinlocks 
>  The hook is called only on multicore operating system implementations 
Call context 
>  The hook routine is called from within operating system API functions with interrupts disabled. 
Table 6-36   OS_VTH_REL_SPINLOCK 
2015, Vector Informatik GmbH 
Version: 9.01 
92 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
6.5.4.3.6 
OS_VTH_TOOK_SEMA 
Prototype 
OS_VTH_TOOK_SEMA( TaskId, SemaId, CallerCoreId) 
Parameter 
TaskId 
Identifier of the task which has taken the semaphore 
SemaId 
Identifier of the semaphore which has been taken 
CallerCoreId 
Identifier of the core where GetSemaphore was called 
Return code 


Functional Description 
The OS calls this hook in the API function GetSemaphore if the semaphore was free before the call. If the 
semaphore was held by another task, the current task is transferred to the waiting state, which is signaled 
to the external tool by means of the OS_VTH_SCHEDULE hook as described in chapter 6.5.4.2.1. 
Particularities and Limitations 
>  The hook is expected to be implemented as a macro. 
>  Reentrancy is possible on multicore systems with different caller core IDs 
>  Call of any operating system API function is prohibited in this hook routine 
>  The semaphore feature is optional, so this macro may not be necessary on all implementations of 
MICROSAR OS. 
Call context 
>  The hook routine is called from within operating system API functions with interrupts disabled. 
Table 6-37   OS_VTH_TOOK_SEMA 
 
6.5.4.3.7 
OS_VTH_REL_SEMA 
Prototype 
OS_VTH_REL_SEMA( ThreadId, SemaId, CallerCoreId) 
Parameter 
ThreadId 
Identifier of the task or ISR which has released the semaphore 
SemaId 
Identifier of the semaphore which has been released 
CallerCoreId 
Identifier of the core where ReleaseSemaphore was called 
Return code 


2015, Vector Informatik GmbH 
Version: 9.01 
93 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Functional Description 
The OS calls this hook in the API function ReleaseSemaphore if the semaphore becomes free after the 
call. If a task is currently waiting for the semaphore, the API function GetSemaphore calls 
OS_VTH_TRANFER_SEMA instead, as described in chapter 6.5.4.1.3. 
Particularities and Limitations 
>  The hook is expected to be implemented as a macro. 
>  Reentrancy is possible on multicore systems with different caller core IDs 
>  Call of any operating system API function is prohibited in this hook routine 
>  The semaphore feature is optional, so this macro may not be necessary on all implementations of 
MICROSAR OS. 
Call context 
>  The hook routine is called from within operating system API functions with interrupts disabled. 
Table 6-38   OS_VTH_REL_SEMA 
6.5.4.3.8 
OS_VTH_DISABLEDINT 
Prototype 
OS_VTH_DISABLEDINT( IntLockId, CallerCoreId) 
Parameter 
IntLockId 
OS_VTHP_CAT2INTERRUPTS: Interrupts have been disabled by means of 
the current interrupt level. That interrupt level has been changed in order to 
disable all category 2 interrupts, which also prevents task switch and 
alarm/schedule table management. 
OS_VTHP_ALLINTERRUPTS: Interrupts have been disabled by means of the 
global interrupt enable/disable flag. Additionally to the effects described above, 
also category 1 interrupts are disabled. 
CallerCoreId 
Identifier of the core where interrupts are disabled 
Return code 


Functional Description 
The OS calls this hook if the application has called an API function to disable interrupts. The parameter 
IntLockId describes whether category 1 interrupts may still occur. 
Mind that the two types of interrupt locking (as described by the IntLockId) are independent from each other 
so that the hook may be called twice before the hook OS_VTH_ENABLEDINT is called, dependent on the 
application. 
Particularities and Limitations 
>  The hook is expected to be implemented as a macro. 
>  Reentrancy is possible on multicore systems with different caller core IDs 
>  Call of any operating system API function is prohibited in this hook routine 
>  The hook is not called for operating system internal interrupt locks 
2015, Vector Informatik GmbH 
Version: 9.01 
94 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Call context 
>  The hook routine is called from within operating system API functions with interrupts disabled. 
Table 6-39   OS_VTH_DISABLEDINT 
6.5.4.3.9 
OS_VTH_ENABLEDINT 
Prototype 
OS_VTH_ENABLEDINT( IntLockId, CallerCoreId) 
Parameter 
IntLockId 
OS_VTHP_CAT2INTERRUPTS: Interrupts had been disabled by means of the 
current interrupt level until this hook was called. The OS releases this lock 
right after the hook has returned. 
OS_VTHP_ALLINTERRUPTS: Interrupts had been disabled by means of the 
global interrupt enable/disable flag before this hook was called. The OS 
releases this lock right after the hook has returned. 
CallerCoreId 
Identifier of the core where interrupts are disabled 
Return code 


Functional Description 
The OS calls this hook if the application has called an API function to enable interrupts. 
Mind that the two types of interrupt locking (as described by the IntLockId) are independent from each other 
so that interrupts may still be disabled by means of the other locking type after this hook has returned. 
Particularities and Limitations 
>  The hook is expected to be implemented as a macro. 
>  Reentrancy is possible on multicore systems with different caller core IDs 
>  Call of any operating system API function is prohibited in this hook routine 
>  The hook is not called for operating system internal interrupt locks 
Call context 
>  The hook routine is called from within operating system API functions with interrupts disabled. 
Table 6-40   OS_VTH_ENABLEDINT 
6.6 
Non-Trusted Functions 
Non-trusted functions  are  a  VECTOR  extension to  the AUTOSAR OS  specification. This  concept 
allows non-trusted applications to provide service functions, which are callable by trusted or non-
trusted tasks and ISRs, comparable to the AUTSAR OS API CallTrustedFunction. 
6.6.1 
Functionality 
The  OS  executes  Non-trusted  functions  with  the  memory  access  rights  and  service  protection 
rights  of  the  owner  application.  These  functions  can  access  local  data  of  the  owner  application 
2015, Vector Informatik GmbH 
Version: 9.01 
95 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
without the possibility to overwrite private data of other applications. Non-trusted functions have no 
access to the data on the callers stack. 
6.6.2 
API 
Prototype 
StatusType osCallNonTrustedFunction(NonTrustedFunctionIndexType FunctionIndex, 
NonTrustedFunctionParameterRefType FunctionParams); 
Parameter 
FunctionIndex 
Index of the function to be called. 
FunctionParams 
Pointer to the parameters for the function to be called. If no parameters are provided, 
a NULL pointer has to be passed. 
Return code 
E_OK 
No error 
E_OS_SERVICEID  No function defined for this index 
Functional Description 
Executes the non-trusted function referenced by FunctionIndex and passes argument FunctionParams. 
The non-trusted function must conform to the following C prototype: 
void NONTRUSTED_<name of the non-trusted function(NonTrustedFunctionIndexType, 
NonTrustedFunctionParameterRefType); 
The arguments are the same as the arguments of CallNonTrustedFunction. 
Particularities and Limitations 
>  The non-trusted function is called in user mode with memory protection enabled 
>  The function has memory access rights of the owner application 
>  The function has the service protection rights of the owner application 
Call context 
>  Task, CAT2 ISR, trusted function, non-trusted function 
Table 6-41 API osCallNonTrustedFunction 
 
 
 
 
Note 
Vector MICROSAR OS implementations offer the possibility of stub function generation 
for trusted functions. This mechanism is not available for non-trusted functions. 
 
 
 
6.7 
MPU Access Checking API 
MISCROSAR  OS  provides API,  which  returns  whether  the  caller  has  access  to  a  given 
adderss. 
Prototype 
uint8 osCheckMPUAccess(uint8* DestinationAddress) 
2015, Vector Informatik GmbH 
Version: 9.01 
96 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Parameter 
DestinationAddress 
The address to be checked for access 
Return code 
uint8 
0: Current Software part has write access 
1: Current Software part has no write access 
Particularities and Limitations 
>  The value of DestinationAddress may be temporarly altered within this function (depending on the 
platform). 
>  Due to data consistency, the function should not be used on addresses, which are shared among cores. 
>  A protection violation may occur during this function. But this protection violation does not lead to a 
shutdown of the OS 
>  This function cannot be called prior to StartOS 
Call context 
>  ProtectionHook 
>  Task trusted/non-trusted 
>  ISR Cat2 trusted/non-trusted 
>  ErrorHook 
>  ShutdownHook, 
>  trusted function 
>  non trusted function 
>  StartupHook 
Table 6-42   osCheckMPUAccess API 
6.8 
Peripheral Regions 
On  some  platforms,  there  are  memory  mapped  hardware  registers,  which  are  only 
accessible  in  privileged  mode.  To  access  this  kind  of  registers  even  in  non-trusted 
applications (i.e. non-privileged mode), MICROSAR OS provides Peripheral Regions. 
To access such registers you have to configure a Peripheral Region and pass it’s ID to the 
Peripheral  Region API.  The  OS  checks  whether  the  caller  has  access  to  this  region  and 
performs the requested access operation.  
The OS provides access functions for the following access types: 8, 16, and 32 bit. 
6.8.1 
Reading functions 
Prototype 
osuint8  osReadPeripheral8(osuint16 area, osuint32 address) 
osuint16 osReadPeripheral16(osuint16 area, osuint32 address) 
osuint32 osReadPeripheral32(osuint16 area, osuint32 address) 
2015, Vector Informatik GmbH 
Version: 9.01 
97 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Parameter 
area 
Identifier of peripheral regions to the read from 
address 
Address to be read from 
Return code 
 
The content of “address” interpreted as 8 bit, 16 bit or 32 bit value 
Functional Description 
>  reads either an 8 bit, or a 16 bit or a 32 bit value from “address” 
>  The function performs accessing checks (whether the caller has accessing rights to the peripheral 
region and whether the address to be read from is within the configured range of the peripheral region) 
>  The error hook is raised in case of an error 
>  A shutdown is not issued in case of an error 
Particularities and Limitations 
>  These functions may not be called from OS hooks 
Call context 
>  These functions may be called from Task context 
>  These functions may be called from category 2 ISR context 
>  These functions can be called with interrupts enabled or with interrupts disabled 
Table 6-43   ReadPeripheral API 
6.8.2 
Writing functions 
Prototype 
void osWritePeripheral8(osuint16 area, osuint32 address, osuint8 value) 
void osWritePeripheral16(osuint16 area, osuint32 address, osuint16 value) 
void osWritePeripheral32(osuint16 area, osuint32 address, osuint32 value) 
Parameter 
area 
Identifier of peripheral regions to the read from 
address 
Address to write to 
Value 
Value to be written 
Return code 
None 
 
Functional Description 
>  Writes to either an 8 bit, or a 16 bit or a 32 bit value 
>  The function performs accessing checks (whether the caller has accessing rights to the peripheral 
region and whether the address to be read from is within the configured range of the peripheral region) 
>  The error hook is raised in case of an error 
>  A shutdown is not issued in case of an error 
2015, Vector Informatik GmbH 
Version: 9.01 
98 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Particularities and Limitations 
>  These functions may not be called from OS hooks 
Call context 
>  These functions may be called from Task context 
>  These functions may be called from category 2 ISR context 
>  These functions can be called with interrupts enabled or with interrupts disabled 
Table 6-44   WritePeripheral API 
6.8.3 
Modifying functions 
Prototype 
void osModifyPeripheral8(osuint16 area, osuint32 address, osuint8 clearmask, 
osuint8 setmask) 
void osModifyPeripheral16(osuint16 area, osuint32 address, osuint16 clearmask, 
osuint16 setmask) 
void osModifyPeripheral32(osuint16 area, osuint32 address, osuint32 clearmask, 
osuint32 setmask) 
Parameter 
area 
Identifier of peripheral regions to the read from 
address 
Address to be modified 
clearmask 
Bitmask which is bitwise “ANDed” to “address” 
setmask 
Bitmask which is bitwise “ORed” to “address” 
Return code 
None 
 
Functional Description 
>  The function performs accessing checks (whether the caller has accessing rights to the peripheral 
region and whether the address to be read from is within the configured range of the peripheral region) 
>  The error hook is raised in case of an error 
>  A shutdown is not issued in case of an error 
>  After the access checks has passed first the “clearmask” is ANDed to “address” and afterwards the 
“setmask” is ORed to it. 
Particularities and Limitations 
>  These functions may not be called from OS hooks 
Call context 
>  These functions may be called from Task context 
>  These functions may be called from category 2 ISR context 
>  These functions can be called with interrupts enabled or with interrupts disabled 
Table 6-45   ModifyPeripheral API 
2015, Vector Informatik GmbH 
Version: 9.01 
99 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
7  Configuration 
Since  AUTOSAR  OS  3.0.0  specification,  XML  is  used  to  define  and  describe  an  OS 
configuration.  However,  OIL  is  still  supported  as  an  alternative  description  language, 
especially  if  the  OS  shall  be  used  stand-alone  without  any  other  AUTOSAR  software 
modules. 
All  OSEK  objects  and  their  attributes  have  to  be  defined  by  one  of  these  description 
languages. 
7.1 
Configuration and generation process 
AUTOSAR XML
Code
OIL
Configuration Tool
.xml
Generator
.oil
Configurator
OS source 
.c
.c
Configuration
.c
Application 
files
.h
.h
files
.h
files
Compile and Link
Executable
 
Figure 7-1 
System overview of software parts 
The figure above shows the complete configuration process of a MICROSAR OS. First all 
OS  objects  have  to  be  defined.  This  can  be  done  either  by  an  AUTOSAR  XML 
configuration tool or by the OIL Configurator (in OIL). 
An  OIL or  XML  file  is the  base of  the  code generation process. After  code  generation  all 
files  (OS  source  files,  application  files  and  generated  OS  configuration  files)  have  to  be 
compiled and linked to an executable. 
7.1.1 
XML Configuration 
A configuration which is based on XML must conform to the AUTOSAR XML schema[8]. 
To  edit  a  MICROSAR  OS  XML  configuration  the  DaVinci  Configurator  Pro  or  Base  of 
Vector  Informatik  GmbH  can  be  used.  Other  tools  that  are  able  to  edit  AUTOSAR 
configurations may also be used. 
The XML file that the tool produces has to be passed to the code generator to generate the 
configuration files. 
2015, Vector Informatik GmbH 
Version: 9.01 
100 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
7.1.2 
OIL Configurator  
The OIL specification is based on the document "OIL: OSEK Implementation Language  – 
Version:  2.3”  (ref.  [6]). Additional Attributes  are  defined  by  Vector  Informatik  GmbH;  the 
resulting version of OIL is 4.0. 
The  OIL  Configurator  is  a  Windows  based  program  that  is  used  to  configure  an  OSEK 
application. The  OIL  Configurator  reads  and  writes  OIL  files  (OSEK  Implementation  Lan-
guage). The usage of the OIL Configurator is described in the online help of the OIL Con-
figurator. 
The OIL Configurator has separate property tabs for each OSEK object type. Each object 
has  several  standard  attributes  that  are  defined  in  the  OIL  specification.  Additional 
attributes  that  are  implementation  specific  are  described  in  the  hardware  specific 
document [4].  
7.2 
Configuration Variants 
The OS supports the configuration variants 
>  VARIANT-PRE-COMPILE 
The MICROSAR OS system is typically delivered with the source code. The kernel is 
implemented in several optimized variants, which are enabled from the OIL Configurator 
using C defines. The source code of the operating system has to be compiled if the 
configuration has changed. For some implementations, a library version of the operating 
system is also supplied. For different configurations, different libraries have to be linked to 
the application. 
The  configuration  classes  of  the  OS  parameters  depend  on  the  supported  configuration 
variants. 
For 
their 
definitions 
please 
see 
the 
OS_<platform 
and 
derivate>_bswmd.arxml file. 
7.3  Configuration of the XML / OIL Attributes  
Some of the attributes of an OSEK object are standard for all OSEK implementations, and 
some are specific for each implementation. 
This chapter describes the attributes the user can set for each OSEK object. Please note 
that setting an attribute to TRUE is used as a synonym for selecting it and setting to FALSE 
is  used  as  a  synonym  for  deselecting  it.  The  reason  is  that  a  selection  in  the  OIL 
Configurator  corresponds  to  setting  the  attribute  to  TRUE  in  the  OIL  file  (this  can  be 
checked by opening the OIL file with a normal text editor). 
 
 
Caution 
If a library version of the operating system is used, some attributes or attribute values 
  are not available or predefined. 
1.   
 
 
2015, Vector Informatik GmbH 
Version: 9.01 
101 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
7.3.1 
OS  
The  OS  object  can only  be  defined  once. The  OS  object  controls  general  aspects  of  the 
operating system. 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
Name 
n.a. 
-- 
>  OIL: Freely selectable name, not used by 
the code generator. 
>  XML: Not available in XML 
Comment 
n.a. 
-- 
Any comment. 
CC 
OsOSCC 
ECC2, AUTO  MICROSAR OS SafeContext must always be 
configured to support Conformance class 
ECC2. 
STATUS 
OsStatus 
EXTENDED 
MICROSAR OS SafeContext must always be 
configured to support extended status (error) 
messages. 
SCALABILITY 
OsScalabilityClass  SC3, SC4, 
MICROSAR OS SafeContext can be ordered in 
CLASS  
AUTO
Scalability classes SC3 or SC4. It must be 
configured with the ordered Scalability class. 
SCHEDULE 
OsOSSchedule 
MIXED, 
MICROSAR OS SafeContext always supports 
AUTO 
preemptive and non-preemptive tasks, thus 
scheduling policy must be configured to mixed 
preemptive. 
n.a. 
OsHooks 
hook 
>  XML: Used as a container to store hook 
routines as 
routine information. 
stated below  >  OIL: not available 
(as 
Booleans) 

STARTUPHOOK 
OsStartupHook 
TRUE 
The StartupHook is always called at system 
startup of a MICROSAR OS SafeContext. 
 
>  XML: This attribute is placed in container 
OsHooks 
ERRORHOOK 
OsErrorHook 
TRUE 
The ErrorHook is always called if an error 
occurs in a MICROSAR OS SafeContext. 
 
>  XML: This attribute is placed in container 
OsHooks 
SHUTDOWNHOOK  OsShutdownHook  TRUE 
The ShutdownHook is always called at 
system shutdown of a MICROSAR OS 
 
SafeContext. 
>  XML: This attribute is placed in container 
OsHooks 
PRETASKHOOK 
OsPreTaskHook 
FALSE 
The PreTaskHook is not supported by 
MICROSAR OS SafeContext. However, there is 
a debug switch to turn it on during 
development, see 6.5.1.2 and [9]. 
>  XML: This attribute is placed in container 
OsHooks 
2015, Vector Informatik GmbH 
Version: 9.01 
102 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
POSTTASKHOOK 
OsPostTaskHook 
FALSE 
The PostTaskHook is not supported by 
MICROSAR OS SafeContext. However, there is 
a debug switch to turn it on during 
development, see 6.5.1.3 and [9]. 
>  XML: This attribute is placed in container 
OsHooks 
PROTECTIONHOO
OsProtectionHook  TRUE 
The ProtectionHook is always called when a 

protection error is detected in a MICROSAR OS 
 
SafeContext. 
>  XML: This attribute is placed in container 
OsHooks 
CallISRHooks 
OsOSCallISRHook FALSE 
The UserPreISRHook and 

UserPostISRHook are not supported by 
MICROSAR OS SafeContext. However, there is 
a debug switch to turn them on during 
development, see 6.5.2.1, 6.5.2.2 and [9]. 
USEGET 
OsUseGetService 
TRUE 
Access macros for the service ID information 
SERVICEID 
Id 
are always available in the error hook. 
 
USEPARAMETER- 
OsUseParameter 
FALSE 
Access macros for the context related 
ACCESS 
Access 
information in the error hook are not supported 
in MICROSAR OS SafeContext. 
USERES 
OsUseRes 
TRUE, 
This parameter is available, as the AUTOSAR 
SCHEDULER 
Scheduler 
standard requires it. Since AUTOSAR 4 the 
FALSE 
resource RES_SCHEDULER was removed as 
special case, therefore this attribute is silently 
ignored by MICROSAR OS. 
STACK 
OsStackMonitoring  TRUE 
A stack check is performed with each task 
MONITORING 
switch. See also chapter 3.2.2.3 for details. 
 
StackUsageMeasure OsStackUsageMe
TRUE, 
If selected, the stacks are filled with an indicator 
ment 
asurement 
value during StartOS. This allows measuring 
FALSE, 
the stack usage of tasks and ISRs. See also 
AUTO 
chapter 3.2.2.5. If AUTO is selected, 
StackUsageMeasurement uses the same 
setting as STACKMONITORING. 
ErrorInfoLevel 
OsOSErrorInfo 
STANDARD 
MICROSAR OS SafeContext will report 
Level 
standard OSEK error codes and unique error 
numbers, but no additional information about 
the error location. 
OSInternalChecks 
OsOSInternal 
ADDITIONAL  MICROSAR OS SafeContext will always 
Checks 
perform all available runtime error checks. 
Compiler 
OsOSCompiler 
Implementatio The compiler can be chosen. If there is only 
n specific 
one compiler this attribute is also set by default. 
 
ORTIDebug Support  OsOSORTIDebug
TRUE 
The OS generator always produces an ORTI. 
Support 
 
2015, Vector Informatik GmbH 
Version: 9.01 
103 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
ORTIDebugLevel 
OsOSORTIDebug
 
MICROSAR OS SafeContext will always 
Level 
ORTI_22_Add support version 2.2 of the ORTI standard with 
itional 
all available features. 
UserConfigurationV
OsOSUserConfigu
1...65535 
Version number of the OS configuration. This 
ersion 
rationVersion 
numeric value is not used by the OS, but 
enables the user to track changes in the 
configuration and validate the configuration 
version actually used in the ECUC. Therefore, it 
is suggested to increment this value each time 
the OS configuration is modified. 
ProtectionHook 
OsOSProtection 
SELECTED 
MICROSAR OS SafeContext does not support 
Reaction 
HookReaction 
forcible termination, thus requires this 
parameter to be set to SELECTED. 
See chapter 7.3.1.3 for information about the 
sub-attributes and required values for 
MICROSAR OS SafeContext. 
Timing 
OsOSTiming 
TRUE 
MICROSAR OS SafeContext will always 
Measurement 
Measurement 
perform Timing measurement if delivered in 
 
Scalability class SC4. 
 
See chapter 7.3.1.4 for information about the 
sub-attributes. Chapter 3.2.4.2 provides more 
detailed information about configuration of 
timing measurement. 
TypeHeader Include  OsOSTypeHeader  TRUE, 
If selected, the AUTOSAR type headers are 
Include 
included in the file os_cfg.h. This is included in 
FALSE 
the file os.h, which has to be included in all 
source files that use API functions of 
MICROSAR OS OSEK/AUTOSAR. The 
AUTOSAR type headers are not necessary for 
the usage of MICROSAR OS 
OSEK/AUTOSAR, so it is safe to deselect this 
attribute. 
EnumeratedUnhandl OsOSEnumerated
TRUE, 
Determines the handling of unassigned 
edISRs 
UnhandledISRs 
interrupt sources. The default of this attribute is 
FALSE 
FALSE. 
FALSE: This is the normal handling for 
unassigned interrupt sources. If no interrupt 
service routine is defined in OIL for an interrupt 
source the corresponding interrupt vector will 
be directed to one common unhandled 
exception handler. This setting must be chosen 
for the final application software. 
TRUE: During application development, there 
may be interrupts issued by unassigned 
interrupt sources. In such case it could be a big 
effort to determine the interrupt source. If this 
attribute is set to TRUE the interrupt vector of 
each unassigned interrupt source will be 
directed to an unhandled exception routine. If 
an unhandled exception occurs in that case, the 
2015, Vector Informatik GmbH 
Version: 9.01 
104 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
interrupt source which causes this exception 
can easily be determined by the variable 
“osISRUnhandledException_Number“. The 
corresponding interrupt source can be 
distinguished by having a look into the interrupt 
vector table which normally is generated to 
intvect.c. This is a debug feature only and is not 
permitted for the final application software 
running on a MICROSAR OS SafeContext. 
This feature is optional. Please refer t[5] to 
find out whether a specific implementation of 
MICROSAR OS supports this feature.
 
ConditionalGenerati
/MICROSAR/Boar
TRUE, 
Determines whether the OS code generator 
ng 
d/BoardGeneral/B
creates the files only if the relevant 
FALSE 
oardConditionalGe
configuration has been modified since the last 
nerating 
generator run (ConditionalGenerating = TRUE). 
If ConditionalGenerating = FALSE, the OS files 
are always generated. 
For details about this attribute, see chapter 
8.1.3. 
Table 7-1  
OS attributes 
7.3.1.1 ProtectionHookReaction / OsOSProtectionHookReaction 
>  MICROSAR OS SafeContext requires this attribute to be set to SELECTED with the 
following subattributes: 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
KILLTASKISR 
OsOSKILLTASK 
FALSE 
MICROSAR OS SafeContext does not support 
ISR 
the return value PRO_TERMINATETASKISR. 
KILLAPPL 
OsOSKILLAPPL 
FALSE  
MICROSAR OS SafeContext does not support 
the return value PRO_TERMINATEAPPL. 
KILLAPPL_ 
OsOSKILLAPPL_
FALSE 
MICROSAR OS SafeContext does not support 
RESTART 
RESTART 
the return value 
PRO_TERMINATEAPPL_RESTART. 
SHUTDOWN 
OsOS 
TRUE 
PRO_SHUTDOWN is the only return value 
SHUTDOWN 
supported by MICROSAR OS SafeContext. 
Table 7-2  
Sub-attributes of ProtectionHookReaction = SELECTED 
 
 
 
Caution 
Currently MICROSAR OS does not support killing. So only SHUTDOWN should be 
  selected! 
 
 
2015, Vector Informatik GmbH 
Version: 9.01 
105 / 136 
based on template version 4.3 




Technical Reference MICROSAR OS SafeContext  
 
 
 
 
Caution 
If the Protection hook returns a value that is not configured by means of the sub-
  attributes of ProtectioHookReaction, the OS performs a Shutdown. 
 
 
 
 
Note 
MICROSAR OS allows to use the return values  
 
  PRO_KILLTASKISR,  
  PRO_KILLAPPL and  
  PRO_KILLAPPL_RESTART  
In the protection hook as synonyms for  
  PRO_TERMINATETASKISR, 
  PRO_TERMINATEAPPL and  
  PRO_TERMINATEAPPL_RESTART  
as long as no macro OS_SUPPRESS_PROTHOOK_OLD_RET_VALS is defined. 
 
 
7.3.1.2 TimingMeasurement / OsOSTimingMeasurement 
This  Attribute  must  be  set  to  TRUE  for  a  MICROSAR  OS  SafeContext  that  has  been 
delivered in Scalability class SC4. 
Please see also 3.2.4.2 and 7.3.2.2. 
>  If this attribute is set to TRUE, the subattribute GlobalConfig allows to globally override 
theTask/ISR settings for Timing Protection and Timing Measurement: 
Attribute Name 
Values 
Description 
The default value is written in 
OIL 
XML 
bold 
GlobalConfig 
OsGlobalConfig  ProtectAndMeasureAll  >  ProtectAndMeasureAll: The OS 
AsSelected 
provides timing measurement for all tasks 
and ISRs regardless of their setting in the 
OnlyMeasureAll 
attribute TIMING_PROTECTION. Timing 
protection however is provided only for all 
tasks and ISRs that have the attribute 
TIMING_PROTECTION set to TRUE. In 
case the subattribute OnlyMeasure is set 
to TRUE, that setting is ignored with a 
warning. In case the attribute 
TIMING_PROTECTION of a task or ISR is 
set to FALSE, the OS provides no timing 
protection. 
>  AsSelected: The os provides timing 
protection for a task or ISR if that is 
configured, the attribute OnlyMeasure is 
honored. 
>  OnlyMeasureAll: The OS does not 
provide timing protection for any Task or 
ISR. Instead, it provides timing 
2015, Vector Informatik GmbH 
Version: 9.01 
106 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value is written in 
OIL 
XML 
bold 
measurement for all tasks and ISRs. In 
case a task or ISR is configured to have 
timing protection and has the subattribute 
OnlyMeasure set to FALSE, that setting is 
overridden with a warning. 
Table 7-3  
Sub-attributes of TimingMeasurement = TRUE 
7.3.1.3 
PeripheralRegion / OsOSPeripheralRegion 
OIL Name 
XML Name 
Values  Description 
StartAddress 
OsOSStartAddress 

Numeric value 
Specifies the start address of the 
peripheral region, which shall be 
configured. 
EndAddress 
OsOSEndAddress 

Numeric value 
Specifies the end address of the 
peripheral region, which shall be 
configured. 
Identifier 
OsOSIdentifier 

Area name 
Must be a unique C-identifier, which can 
be used in an application or BSW module 
to access the peripheral region. 
ACCESSING_
OsOSAccessingApplication  - 
Grants access for this Peripheral Region. 
APPLICATION 
Multiple applications can be defined for 
the same Peripheral Region. 
Table 7-4  
Sub-attributes of PeripheralRegion 
 
 
Caution 
The application is allowed to access memory addresses in the interval of StartAddress 
  <= memory to be accessed <= EndAddress 
The “EndAddress” value is included! All bytes of a peripheral access must fit into the 
peripheral region. 
 
 
 
7.3.2 
Task 
In the section Task all tasks and their attributes have to be defined. 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
Name 
Short-Name 

Name of the task. This name is used as an 
argument to all task-related OSEK API 
2015, Vector Informatik GmbH 
Version: 9.01 
107 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
functions (e.g. ActivateTask). The task 
function (or task body) has to be defined using 
the C macro TASK() (which appends the suffix 
func to the task name). 
Comment  
n.a. 
-- 
Any comment. 
TYPE  
OsTaskTYPE 
BASIC, 
Type of the task: either BASIC or EXTENDED. 
If set to AUTO, the type is calculated based on 
EXTENDED, 
the settings for events and the activation count. 
AUTO 
SCHEDULE 
OsTaskSchedule 
NON, 
Scheduling policy for this task.  
FULL 
PRIORITY 
OsTaskPriority 

The priority of the task. A higher number 
represents a higher priority (according to the 
OSEK specification). The priority may be set 
with gaps, though the gaps will be eliminated by 
the code generator. Several tasks may be set 
on the same priority level. 
ACTIVATION  
OsTaskActivation 

The number of activations that are recorded in 
the kernel while the task is possibly running or 
delayed by higher priority tasks. 
If ACTIVATION is set to a value bigger than 1, 
no events can be received. 
AUTOSTART  
OsTaskAutostart 

If set to TRUE, the task will be activated at 
startup of the operating system. See chapter 
7.3.2.1 for details about the sub-attributes. 
EVENT 
OsTaskEventRef 

Reference to an event that is used by this task. 
This attribute can only be used for extended 
tasks (the attribute TYPE might be set to 
EXTENDED or AUTO). This attribute can be used 
multiply if more than one EVENT has to be 
assigned. 
If events are used with this task, the attribute 
ACTIVATION cannot be bigger than 1. 
RESOURCE 
OsTaskResource 

Reference to a resource that is occupied by this 
Ref 
task. This attribute can be used multiply if more 
than one RESOURCE shall be assigned. 
StackSize 
OsTaskStackSize 

Task stack size in byte. This attribute is only 
available if the implementation supports 
configurable task stacks. 
TIMING_PROTECTI OsTaskTiming 

Selects timing protection for the task. See 
ON 
Protection 
chapter 7.3.2.2 for information about the sub-
attributes. 
ACCESSING_ 
OsTaskAccessing

Defines access rights of an application for this 
APPLICATION 
Application 
task. This attribute can be defined multiply, so 
different applications might have access right to 
the same task. This attribute can be used in 
2015, Vector Informatik GmbH 
Version: 9.01 
108 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
scalability classes SC3 and SC4 only. 
Table 7-5  
Task attributes 
7.3.2.1 AUTOSTART / OsTaskAutostart 
>  OIL: If attribute set to FALSE: 
 No sub-attributes. 
>  XML: If this container is not present: 
 AUTOSTART switched off. 
>  If attribute is set to TRUE: 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
APPMODE 
OsTaskAppMode 

Defines an application mode in which the task 
Ref 
is started in automatically. This attribute might 
be defined several times to start the task in 
different application modes. 
Table 7-6  
Sub-attributes of TASK->AUTOSTART=TRUE 
7.3.2.2 TIMING_PROTECTION / OsTaskTimingProtection 
Please  note  that  TIMING_PROTECTION  =  TRUE  can  only  be  selected  for  a  MICROSAR 
OS SafeContext that has been delivered in Scalability class SC4. 
>  If attribute is set to FALSE: 
No sub-attributes. 
>  If this attribute is not defined in XML: 
Timing protection is switched off. 
The value of this attribute might be overridden by the OS attribute TimingMeasurement, 
as described in chapters 7.3.1.4 and 3.2.4.2 
>  If attribute is set to TRUE: 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
EXECUTION 
OsTaskExecution 

Defines the maximum execution time for the 
BUDGET 
Budget 
task 
TIMEFRAME 
OsTaskTimeFrame  - 
Defines the minimum time between task 
activations 
MAXOS 
OsTaskOsInterrupt - 
Maximum time OS interrupts are locked (by 
2015, Vector Informatik GmbH 
Version: 9.01 
109 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
INTERRUPT 
LockBudget 
SuspendOSInterrupts) 
LOCKTIME 
MAXALL 
OsTaskAllInterrupt

Maximum time ALL interrupts are locked (by 
INTERRUPT 
LockBudget 
SuspendAllInterrupts or 
LOCKTIME 
DisableAllInterrupts) 
LOCKINGTIME = 
OsTaskResource 

Is intended to be a container for sub-attributes 
RESOURCELOCK 
Lock 
concerning the locking time of resources 
LOCKINGTIME = 
Inside the 

The resource for which the locking time is 
RESOURCELOCK/ 
container 
specified. 
RESOURCE 
OsTaskResource 
Lock: 
OsTaskResource 
LockResourceRef 
LOCKINGTIME = 
Inside the 

Maximum time the resource is locked (by 
RESOURCELOCK/ 
container 
GetResource) 
RESOURCELOCK 
OsTaskResource 
TIME 
Lock: 
OsTaskResource 
LockBudget 
OnlyMeasure 
OsOnlyMeasure 
TRUE 
If set to FALSE, timing values of this task are 
measured and violations against the configured 
FALSE 
values lead to a call of the ProtectionHook. If 
set to TRUE, the timing values are still 
measured but no call of the ProtectionHook 
occurs. 
Table 7-7  
Sub-attributes of TASK-> TIMING_PROTECTION=TRUE 
7.3.2.3 
Task attributes concerning the timing analyzer 
The following attributes have to be used when working with the timing analyzer tool. They 
are used as input for this tool. 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
ComputationTime 
OsTask 

The worst case execution time (in 
ComputationTime 
nanoseconds) 
Period 
OsTaskPeriod 

The minimum activation period of the task (in 
nanoseconds) 
Deadline 
OsTaskDeadline 

The deadline of the task (in nanoseconds) 
PRIORITY 
OsTaskPriority 

Priority of the task 
UseResource 
OsTaskUse 

If set to TRUE the occupation of resources can 
Occupation 
Resource 
be taken into consideration by the analysis tool. 
Occupation 
UseResource 
OsTaskUse 

Reference to the resource that is occupied. 
Occupation=TRUE/
Resource 
2015, Vector Informatik GmbH 
Version: 9.01 
110 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
Resource 
Occupation 
=TRUE/OsTask 
Resource 
UseResource 
OsTaskUse 

Maximum 
resource 
occupation 
time 
(in 
Occupation=TRUE/
Resource 
nanoseconds) 
OccupationTime 
Occupation 
=TRUE/OsTask 
OccupationTime 
Table 7-8  
Task attributes concerning the timing analyzer 
7.3.3 
Counter 
The Counter container provides the following configuration attributes. 
Attribute Name 
Values 
Description 
The default 
OIL 
XML 
value is written 
in bold 
Name 
Short-Name 

Name of the counter. This name is used 
for the Alarm configuration. 
Comment  
n.a. 
 
Any comment. 
MINCYCLE 
OsCounterMinCycle 

This attribute specifies the minimum 
allowed number of ticks for a cyclic 
alarm linked to the counter. 
MAXALLOWED 
OsCounterMaxAllowedValue  
Maximum value, which is reachable by 
VALUE 
the counter in counter ticks. 
TICKSPERBASE 
OsCounterTicksPerBase 

This attribute specifies the number of 
hardware timer ticks required to reach a 
counterspecific unit. E.g. if you have a 
periodic tick timer, which is running with 
16MHz and it is configured to trigger a 
timer interrupt with 1kHz. You have 
16000 ticks per base. 
TYPE 
OsCounterType 
SOFTWARE,  Defines the type of the counter. 
Possible settings are SOFTWARE or 
HARDWARE  HARDWARE. SOFTWARE means the 
counter is incremented by means of the 
system service IncrementCounter, 
which has to be called by the 
application. HARDWARE means the 
counter is incremented by MICROSAR 
OS internally. 
DRIVER 
OsDriver 

This Container contains the information 
who will drive the counter. This 
configuration is only valid if the counter 
has OsCounterType set to HARDWARE. 
Sub-Attributes are hardware dependent 
(see [5])
2015, Vector Informatik GmbH 
Version: 9.01 
111 / 136 
based on template version 4.3 




Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default 
OIL 
XML 
value is written 
in bold 
TIMECONSTANT 
OsTimeConstant 

This Container allows the user to define 
constants, to be used e.g. to compare 
physical time values with timer tick 
values. 
TIMECONSTANT/ 
OsConstName 

The name, to be used by the application 
CONSTNAME 
to get OsTimeValue in counter units. 
TIMECONSTANT/ 
OsTimeValue 

This attribute contains the value of the 
VALUE 
constant in seconds. 
SECONDSPERTICK  OsSecondsPerTick 

This attribute contains the time of one 
counter tick in seconds. 
ACCESSING_ 
OsCounter Accessing 

Defines access rights of an application 
APPLICATION 
Application 
for this counter. This attribute can be 
used multiply, so different applications 
might have access rights to this counter. 
This attribute can only be used in 
scalability classes SC3 and SC4. 
Table 7-9  
Attributes of COUNTER 
 
Figure 7-2 
Relation between Physical Units, Counter Units and Driver Units 
 
 
 
Note 
If the OS supports High-Resolution, there is no periodic counter tick. The OS programs 
  the driver to interrupt on demand (e.g. next Alarm, next Expiry Point, etc.). Therefore, 
the counter has the same resolution as the driver (OsCounterTicksPerBase is 1). 
 
 
 
 
 
 
7.3.4 
Alarm 
The action of an alarm has to be defined statically. 
2015, Vector Informatik GmbH 
Version: 9.01 
112 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value is 
OIL 
XML 
written in bold 
Name 
Short-Name 

Name of the alarm. This name is used as an 
argument to all alarm related OSEK API 
functions (e.g. SetRelAlarm). 
Comment 
n.a. 
-- 
Any comment 
COUNTER 
OsAlarmCounter   
Reference to the counter that drives the 
Ref 
alarm.  
ACTION 
OsAlarmAction 
>  OIL: 
See chapter 7.3.4.1 for more information.   
SETEVENT, 
ACTIVATETASK, 
INCREMENTCOU
NTER 
 
>  XML: 
Choice container: 
OsAlarmActivateT
ask, 
OsAlarmIncrement
Counter, 
OsAlarmSetEvent 
AUTOSTART  
OsAlarmAutostart  TRUE 
>  OIL: If set to TRUE, the alarm will be 
activated at startup of the system. 
FALSE 
>  XML: If attribute is present, the alarm will 
be activated at startup of the system. 
See chapter 7.3.4.2 for more information 
about the sub-attributes and chapter 3.2.1.3 
for more information about static alarms.  
ACCESSING_ 
OsAlarmAccessin  
Defines access rights of an application for 
APPLICATION 
gApplication 
this alarm. This attribute can be used 
multiply, so different applications might have 
access rights to this alarm. This attribute can 
be used in scalability classes SC3 and SC4 
only. 
Table 7-10   Attributes of ALARM 
7.3.4.1 ACTION / OsAlarmAction 
>  Attribute / ChoiceContainer is set to ACTIVATETASK / OsAlarmActivateTask: 
2015, Vector Informatik GmbH 
Version: 9.01 
113 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
TASK 
OsAlarmActivate 

Task to be activated 
TaskRef 
Table 7-11   Sub-attributes of ACTION = ACTIVATETASK 
>  Attribute / ChoiceContainer is set to SETEVENT / OsAlarmSetEvent: 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
TASK 
OsAlarmSetEvent 

Task to which the event should be sent 
TaskRef 
EVENT 
OsAlarmSetEvent
 
Event to be sent to the specified task 
Ref 
Table 7-12   Sub-attributes of ACTION = SETEVENT 
 
>  Attribute / ChoiceContainer is set to INCREMENTCOUNTER / 
OsAlarmIncrementCounter: 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
COUNTER 
OsAlarmIncrement 
Name of the counter to be incremented 
CounterRef 
Table 7-13   Sub-attributes of ACTION = ALARMCALLBACK 
 
7.3.4.2 AUTOSTART / OsAlarmAutostart 
>  OIL: This attribute can be either TRUE or FALSE. Depending on the value, there may be 
different sub-attributes. 
>  XML: This attribute can be present in the configuration or it can be omitted. In case this 
container is present, it has sub-attributes, which are described below. 
>  If AUTOSTART is set to TRUE (OIL) or if the container is present (XML): 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
ALARMTIME 
OsAlarmAlarmTim

The relative or absolute tick value when the 

alarm expires for the first time. Note that for an 
alarm which is RELATIVE the value should be 
bigger than 0. 
2015, Vector Informatik GmbH 
Version: 9.01 
114 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
TYPE 
OsAlarmAutostar 
ABSOLUTE 
The value corresponds to a call of the API-
tType 
Functions SetRelAlarm or SetAbsAlarm 
RELATIVE 
CYCLETIME 
OsAlarmCycleTim
 
This atttibute defines the cycle time of a cyclic 

alarm in counter units.  A zero value indicates 
that the alarm is not cyclic. 
APPMODE 
OsAlarmAppMode
 
Reference to the application modes for which 
Ref 
the AUTOSTART shall be performed. 
Table 7-14   Sub-attributes of AUTOSTART = TRUE 
 
7.3.5 
Resource 
Resources have to be defined with the following attributes: 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
Name 
Short-Name 

Name of the resource. This name is used as an 
argument to all resource related OSEK API 
functions (e.g. GetResource). 
Comment 
n.a. 
-- 
Any comment 
RESOURCE 
OsResource 
STANDARD, 
This attribute can take the following values:  
PROPERTY 
Property 
LINKED 
>  STANDARD: A normal resource that is not 
linked to another resource and is not an 
internal resource. 
>  LINKED: A resource that is linked to another 
resource with the property STANDARD or 
LINKED. 
Internal resources are not supported by 
MICROSAR OS SafeContext. 
ACCESSING_ 
OsResource 
 
Defines access rights of an application for this 
APPLICATION 
Accessing 
resource. This attribute can be used multiply, so 
Application 
different applications might have access rights 
to this resource. This attribute can only be used 
in scalability classes SC3 and SC4. 
RESOURCE 
OsResourceLinked  
>  OIL: If the resource property is set to 
PROPERTY 
ResourceRef 
LINKED, the LINKEDRESOURCE attribute 
holds a reference to a resource. 
=LINKED / LINKED 
RESOURCE 
>  XML: This attribute holds a reference to a 
resource. 
2015, Vector Informatik GmbH 
Version: 9.01 
115 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
Table 7-15   Attributes of RESOURCE 
7.3.6 
Event 
Events  in  the  OSEK  operating  system  are  always  implemented  as  bits  in  bit-fields.  The 
user could use bit-masks like ‘0x0001’, but to achieve portability between different OSEK 
implementations, the user should use event  names, which are mapped to defined bits by 
the code generator. 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
Name 
Short-Name 

Name of the event. This name is used as an 
argument to all event related OSEK-API-
functions (e.g. SetEvent). 
Comment 
n.a. 
-- 
Any comment 
MASK 
OsEventMask 

>  OIL: Eventmask or AUTO 
>  XML: If EventMasks shall be defined 
automatically this attribute shall be omitted 
Table 7-16   Sub-attributes of EVENT 
 
 
Caution 
If the user selects AUTO for the mask, the code generator will search for free bits in the 
  bit mask of the receiving task. It is important to specify each task that receives an 
event, otherwise the code generator will generate wrong bit-masks. 
 
 
7.3.7 
ISR 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
Name 
Short-Name 

Name of the interrupt service routine. 
Comment 
n.a. 
-- 
Any comment 
CATEGORY 
OsIsrCategory 

>  OIL: Number of category for the interrupt 
service routine (1-2) 
>  XML: this attribute can be CATEGORY_1 or 
CATEGORY_2 
RESOURCE 
OsIsrResourceRef  - 
Resource management for ISRs is not 
supported by MICROSAR OS SafeContext. 
TIMING_ 
OsIsrTiming 

Selects timing protection for the ISR. See 
PROTECTION 
Protection 
chapter 7.3.7.2 for information about the sub-
attributes. 
EnableNesting 
OsIsrEnable 

If set to TRUE the OS will call the user ISR in a 
Nesting 
way that interrupts will be enabled again during 
user ISR. Thus, it is possible that the user ISR 
can be interrupted by other ISRs. 
2015, Vector Informatik GmbH 
Version: 9.01 
116 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
UseSpecialFunction
OsIsrUseSpecial 

Normally the attribute Name/Short-Name 
Name 
FunctionName 
defines the C-Name of the ISR. Since this 
name must be unique, it would not be possible 
to map different interrupt Sources to a single 
ISR. This can be done by this attribute. 
If this attribute is set to TRUE, it is possible to 
define the function name of the ISR in a 
separate sub-attribute. These names do not 
have to be unique. 
ACCESSING_ 
OsIsrAccessing 

Defines access rights of an application for this 
APPLICATION 
Application 
ISR. This attribute can be used multiply, so 
different applications might have access rights 
to this alarm. 
Table 7-17   Attributes of ISR 
7.3.7.1 UseSpecialFunctionName / OsIsrUseSpecialFunctionName 
If  this  attribute  is  set  to  TRUE  a  function  name  can  be  specified  which  is  taken  as  ISR 
name instead of the Name (OIL) / Short-Name (XML) attribute. 
This can be used to map several interrupt sources to one ISR routine. 
 
Attribute Name 
Values 
Description 
The default 
OIL 
XML 
value is written 
in bold 
FunctionName 
OsIsrFunctionName  - 
Name of the ISR routine. 
Table 7-18   Sub-attributes of UseSpecialFunctionname / OsIsrUseSpecialFunctionName 
 
 
 
Example 
Given  two  Interrupts  MyISR1  and  MyISR2.  Both  shall  trigger  the  same  ISR  routine. 
  Activate  SpecialFuntionName  for  MyISR2,  and  set  FunctionName  to  “MyISR1”.  Now, 
MyISR2 is mapped onto the MyISR1 routine, which is implemented as usual:  
ISR(MyISR1)  

  … 

 
 
 
 
2015, Vector Informatik GmbH 
Version: 9.01 
117 / 136 
based on template version 4.3 



Technical Reference MICROSAR OS SafeContext  
 
 
 
Note 
The ISR() macro MUST be used for the definition of category 2 ISR handlers. If this 
  is not possible, a wrapper using this macro can be used to call the respective ISR 
handler: 
 
ISR(MyISR1) /* “MyISR1” is the configured */ 
{           /* FunctionName in OIL or XML */ 
  MyISRHandlerFunction(); /* “MyISRHandlerFunction” is  */ 
}                         /* the name of the actual ISR */        
/* handler provided by the    */ 
/* application                */ 
 
 
 
 
 
7.3.7.2 TIMING_PROTECTION / OsIsrTimingProtection 
>  OIL: This attribute has to be set to TRUE to switch on timing protection. The sub-
attributes are only visible if TIMING_PROTECTION is TRUE. 
>  XML: This attribute has to be present to switch on timing protection. 
Please  note  that  timing  protection  can  only  be  switched  on  for  a  MICROSAR  OS 
SafeContext that has been delivered in Scalability class SC4. 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
EXECUTIONTIME 
OsIsrExecution 

The parameter contains the maximum allowed 
Budget 
execution time of the interrupt. 
>  OIL: the times are given in nanoseconds. 
>  XML: the times are given in seconds. 
TIMEFRAME 
OsIsrTimeFrame 

This parameter contains the minimum inter-
arrival time between successive interrupts  
>  OIL: the times are given in nanoseconds. 
>  XML: the times are given in seconds. 
MAXOSINTERRUP
OsIsrOsInterrupt 

This parameter contains the maximum time for 
TLOCKTIME 
LockBudget 
which the ISR is allowed to lock all Category 2 
interrupts (via SuspendOSInterrupts()).  
>  OIL: the times are given in nanoseconds. 
>  XML: the times are given in seconds. 
MAXALLINTERRUP OsIsrAllInterrupt 

This parameter contains the maximum time for 
TLOCKTIME 
LockBudget 
which the ISR is allowed to lock all interrupts 
(via SuspendAllInterrupts() or 
DisableAllInterrupts()) 
2015, Vector Informatik GmbH 
Version: 9.01 
118 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
>  OIL: the times are given in nanoseconds. 
>  XML: the times are given in seconds. 
LOCKINGTIME 
OsIsrResource 

>  OIL: This is a (empty) list of all lock times, in 
Lock 
nanoseconds 
>  XML: This container holds resource lock 
times, in seconds. 
Resource lock times are the maximum times an 
ISR is allowed to hold a resource. 
OnlyMeasure 
OsOnlyMeasure 
TRUE 
If set to FALSE, timing values of this ISR are 
measured and violations against the configured 
FALSE 
values lead to a call of the ProtectionHook. If 
set to TRUE, the timing values are still 
measured but no call of the ProtectionHook 
occurs. The value of this attribute might be 
overridden by the OS attribute 
TimingMeasurement, as described in 
chapters 7.3.1.4 and 3.2.4.2. 
Table 7-19   Sub-attributes of TIMING_PROTECTION / OsIsrTimingProtection 
7.3.7.2.1 
LOCKINGTIME / OsIsrResourceLock 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
LOCKINGTIME= 
OsIsrResource 

The parameter contains the maximum allowed 
RESOURCELOCK/
LockBudget 
time an ISR is allowed to hold a resource 
RESOURCELOCK 
>  OIL: the times are given in nanoseconds. 
TIME 
>  XML: the times are given in seconds. 
LOCKINGTIME= 
OsIsrResource 
 
Holds the reference to this resource 
RESOURCELOCK/
LockResourceRef 
RESOURCE 
Table 7-20   Sub-attributes of LOCKINGTIME / OsIsrResourceLock 
 
7.3.7.3 
ISR Attributes concerning the Timing Analyzer 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
ComputationTime 
OsIsrComputation

The worst case execution time (in 
Time 
nanoseconds) 
Period 
OsIsrPeriod 
 
The minimum activation period of the ISR (in 
nanoseconds) 
2015, Vector Informatik GmbH 
Version: 9.01 
119 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
Deadline 
OsIsrDeadline 
 
The deadline of the ISR (in nanoseconds) 
AnalysisPriority 
OsIsrAnalysis 
 
The AnalysisPriority corresponds to the 
Priority 
Task attribute PRIORITY / osTaskPriority.  
 
The AnalysisPriority is an extension of 
the priority values from tasks to ISRs, so all ISR 
priorities must have higher values as all task 
priorities to get correct analysis results. (Some 
OS Implementations use an attribute similar to 
priority for the hardware interrupt level. 
Therefore to the timing analysis an own 
attribute was introduced). 
UseResource 
OsIsrUseResource  
If set to TRUE the occupation of resources can 
Occupation 
Occupation 
be taken into consideration by the analysis tool. 
UseResource 
OsIsrUseResource  
Reference to the resource that is occupied. 
Occupation= 
Occupation=TRUE
TRUE/Resource 
/OsIsrResource 
UseResource 
OsIsrUseResource  
Maximum resource occupation time (in 
Occupation= TRUE/  Occupation=TRUE
nanoseconds) 
OccupationTime 
/OsIsrOccupation 
Time 
Table 7-21   ISR attributes concerning the timing analyzer 
 
7.3.8 
COM 
The section COM is not used by MICROSAR OS. 
 
7.3.9 
NM 
The section NM is not used with the current MICROSAR OS implementation. 
 
7.3.10  APPMODE / OsAppMode 
Application modes have to be defined with the following attributes: 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
Name 
Short-Name 

Name of the application mode. This name is 
used as an argument to all related OSEK-API-
functions and for the definition of the 
AUTOSTART functionality of tasks and alarms. 
Comment 
n.a. 
-- 
Any comment 
2015, Vector Informatik GmbH 
Version: 9.01 
120 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
n.a. 
OsAppModeId 
 
Internal ID of an Appmode. The value of this 
attribute is ignored by MICROSAR OS. 
Table 7-22   Attributes of Appmode / OsAppMode 
 
7.3.11  Application / OsApplication 
The object APPLICATION is meant for the usage with scalability classes SC3 and SC4.  
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
Name 
Short-Name 
-- 
Freely selectable name, not used by the code 
generator. 
Comment 
n.a. 
-- 
Any comment. 
n.a. 
OsApplication 
FALSE 
MICROSAR OS SafeContext does not support 
Hooks 
any application specific Hook routines. 
STARTUPHOOK 
OsAppStartup 
FALSE 
MICROSAR OS SafeContext does not support 
Hook 
any application specific Hook routines. 
(XML: is contained in OsApplicationHooks) 
ERRORHOOK 
OsAppErrorHook 
FALSE 
MICROSAR OS SafeContext does not support 
any application specific Hook routines. 
(XML: is contained in OsApplicationHooks) 
SHUTDOWNHOOK  OsAppShutdown 
FALSE 
MICROSAR OS SafeContext does not support 
Hook 
any application specific Hook routines. 
(XML: is contained in OsApplicationHooks) 
TRUSTED 
OsTrusted 
TRUE, 
>  OIL: Defines whether the application is 
trusted or not. See chapter 7.3.11.1 for 
FALSE 
information about the sub-attributes. 
>  XML: This is only a boolean which marks the 
Application as trusted application 
HAS_RESTART 
n.a. 
FALSE 
>  OIL: MICROSAR OS SafeContext does not 
TASK 
support terminating or restarting an 
application. 
TASK 
OsAppTaskRef 

Reference to all tasks belonging to this 
application. 
ISR 
OsAppIsrRef 

Reference to all ISRs belonging to this 
application. 
ALARM 
OsAppAlarmRef 

Reference to all alarms belonging to this 
application. 
SCHEDULETABLE 
OsAppSchedule 

Reference to all schedule tables belonging to 
TableRef 
this application. 
2015, Vector Informatik GmbH 
Version: 9.01 
121 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
COUNTER 
OsAppCounterRef  - 
Reference to all counters belonging to this 
application. 
n.a. 
OsApplication 

Container that is used to define trusted 
TrustedFunction 
functions. 
NonTrusted_Functio OsApplicationNon

List of non-trusted functions provided by this 

Trusted_Function 
application (only for non-trusted applications). 
Table 7-23   Attributes of Application / OsApplication 
7.3.11.1  Trusted Functions 
>  OIL: trusted functions are defined as sub-attributes of 'TRUSTED=TRUE'. 
>  XML: there are containers for trusted functions. 
The 
preconditions 
for 
editing 
the 
sub-attributes 
in 
the 
next 
table 
are 
TRUSTED=TRUE/TRUSTED_FUNCTION=TRUE  for  OIL  and  the  existence  of  (at  least  one) 
OsApplicationTrustedFunction container. 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
TRUSTED_ 
OsTrustedFunction - 
List of trusted functions provided by this 
FUNCTION 
Name 
application. 
=TRUE/TRUSTED 
FUNCTION 
=TRUE/NAME 
TRUSTED_ 
OsApplication 

Parameter (arguments) of trusted function. 
FUNCTION 
Params 
Empty string means void. Used for stub 
=TRUE/TRUSTED 
generation only. See attribute GenerateStub. 
FUNCTION 
=TRUE/Params 
TRUSTED_ 
OsApplication 

Return value data type of trusted function. 
FUNCTION 
ReturnType 
Empty string means void. Used for stub 
=TRUE/TRUSTED 
generation only. See attribute GenerateStub. 
FUNCTION 
=TRUE/ReturnType 
TRUSTED_ 
OsApplication 

If set to TRUE, stub functions are generated for 
FUNCTION 
GenerateStub 
all trusted functions of this application. 
=TRUE/Generate 
Stub 
Table 7-24   Sub-attributes for trusted functions 
 
2015, Vector Informatik GmbH 
Version: 9.01 
122 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
7.3.12  Scheduletable 
Schedule tables have to be defined with the following attributes. 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
Name 
Short-Name 

Name of the SCHEDULETABLE. This name is 
used as an argument to all related OSEK API 
functions. 
Comment 
n.a. 
-- 
Any comment 
COUNTER 
OsScheduleTable

Defines the counter used as time basis for this 
CounterRef 
schedule table. 
REPEATING 
OsScheduleTable

If selected, the schedule table is performed 
Repeating 
periodically after it is started. If deselected, the 
schedule table is performed once per activation. 
DURATION 
OsScheduleTable

Defines the length of the schedule table in ticks, 
Duration 
based on the underlying counter. This is the 
time from the first expiry point to the end of the 
schedule table or in the case of a periodic 
schedule table, between two subsequent first 
expiry points. The length is defined in units of 
ticks of the underlaying counter. 
AUTOSTART  
OsScheduleTable 

>  OIL: If set to TRUE, the schedule table is 
Autostart 
activated at startup of the operating system. 
>  XML: If attribute is present, the schedule 
table is activated at startup of the operating 
system. 
See chapter 7.3.13.1 for more information 
about the sub-attributes. 
LOCAL_TO_ 
OsScheduleTable 

Defines, whether the schedule table shall be 
GLOBAL_TIME_SY
Sync 
synchronized to a global time source. This 
NCHRONIZATION 
attribute is only supported in scalability class 
SC4. Sub-attributes are described in chapter 
7.3.13.6. 
EXPIRY_POINT 
OsScheduleTable 

Defines an expiry point for this schedule table 
ExpiryPoint 
ACCESSING_ 
OsSchTbl 

Defines access rights of an application for this 
APPLICATION 
Accessing 
schedule table. This attribute can be used 
Application 
multiply, so different applications might have 
access rights to this schedule table.  
Table 7-25   Attributes of SCHEDULETABLE 
7.3.12.1  AUTOSTART / OsScheduleTableAutostart 
>  OIL: If this attribute is set to TRUE sub-attributes are visible and the schedule table is 
auto started. 
>  XML: If this container is present in the configuration the schedule table is auto started 
2015, Vector Informatik GmbH 
Version: 9.01 
123 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
APPMODE 
OsScheduleTable 

Defines an application mode in which the 
AppModeRef 
schedule table is started automatically. This 
attribute might be defined several times to start 
the schedule table in several application 
modes. 
TYPE 
OsScheduleTable 
ABSOLUTE 
Defines the method how the schedule table is 
AutostartType 
autostarted. 
RELATIVE 
 
SYNCHRON 
TYPE=ABSOLUT/ 
OsScheduleTable 

Absolute autostart tick value when the schedule 
ABSVALUE 
StartValue 
table starts. Only used if the 
OsScheduleTableAutostartType is 
ABSOLUTE. 
TYPE=RELATIVE/ 
OsScheduleTableS - 
Relative offset in ticks when the schedule table 
RELOFFSET 
tartValue 
starts. Only used if the 
OsScheduleTableAutostartType is 
RELATIVE. 
Table 7-26   Sub-attributes for auto start of a schedule table 
 
7.3.12.2  EXPIRY_POINT / OsScheduleTableExpiryPoint 
An expiry point consists of a sequence of actions which are performed on a given tick time 
of the schedule table. There are the following sub-attributes. Some of them also have sub-
attributes. 
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
ACTION 
n.a. 
>  OIL : 
>  OIL: a list of actions 
ACTIVATETA
 
SK 
SETEVENT 
ADJUST  
OFFSET 
OsScheduleTbl 

Defines the time at which the defined actions 
ExpPointOffset 
occur in ticks based on the underlying counter. 
The time is absolute to the start of the schedule 
table and is given in ticks of the underlying 
counter. 
ACTION=ADJUST 
OsScheduleTbl 

>  XML: containers for holding the sub-
AdjustableExp 
attributes in case of expiry point action 
Point 
ADJUST 
ACTION 
OsScheduleTable 

>  XML: containers for holding the sub-
=ACTIVATETASK 
TaskActivation 
attributes in case of expiry point action 
2015, Vector Informatik GmbH 
Version: 9.01 
124 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
ACTIVATESTASK 
ACTION 
OsScheduleTable 

>  XML: containers for holding the sub-
=SETEVENT 
EventSetting 
attributes in case of expiry point action 
SETEVENT 
Table 7-27   Sub-attributes of expiry points 
7.3.12.3  Expiry point action ADJUST 
>  OIL: the following attributes are visible if the expiry point action is ADJUST 
>  XML: the following attributes are located in the container 
OsScheduleTblAdjustableExpPoint 
Those attributes are only relevant in SC2 or SC4 if synchronization mechanisms are used. 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
MAXLENGTHEN 
OsScheduleTable
  
The maximum positive adjustment that can be 
MaxLengthen 
made to the expiry point offset to achieve 
synchronizationin ticks based on the underlying 
counter. 
MAXSHORTEN 
OsScheduleTable

The maximum negative adjustment that can be 
MaxShorten 
made to the expiry point offset to achieve 
synchronization in ticks based on the underlying 
counter. 
Table 7-28   Sub-attributes of expiry point action ADJUST 
7.3.12.4  Expiry point action ACTIVATETASK 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
TASK 
OsScheduleTable 
 
Reference to the task to be activated.  
ActivateTaskRef 
Cyclic 
OsScheduleTable
TRUE, 
>  OIL: If set to TRUE, this action is repeatedly 
Cyclic 
added to the schedule table. 
FALSE 
>  XML: This is a choice container. If set to 
TRUE the action will be repeatedly added to 
the schedule table. 
The cycle time is located in a sub-attribute. See 
chapter 3.2.6.3 for more details. 
Cyclic=TRUE/Cycle
OsScheduleTable
 
If the action is declared as cyclic, this attribute 
Time 
CycleTime 
holds the cycle time in counter ticks. 
Table 7-29   Sub-attributes of expiry point action ACTIVATETASK 
2015, Vector Informatik GmbH 
Version: 9.01 
125 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
7.3.12.5  Expiry point action SETEVENT 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
TASK 
OsScheduleTable 

Task to which the event should be sent 
SetEventTaskRef 
EVENT 
OsScheduleTable 

Event to be sent to the specified task 
SetEventRef 
Cyclic 
OsScheduleTable
TRUE, 
>  OIL: If set to TRUE, this action is repeatedly 
Cyclic 
added to the schedule table. 
FALSE 
>  XML: This is a choice container. If set to 
TRUE the action will be repeatedly added to 
the schedule table. 
The cycle time is located in a sub-attribute. See 
chapter 3.2.6.3 for more details. 
Cyclic=TRUE/Cycle
OsScheduleTable

If the action is declared as cyclic, this attribute 
Time 
CycleTime 
holds the cycle time in counter ticks. 
Table 7-30   Sub-attributes of expiry point action SETEVENT 
 
7.3.12.6  LOCAL_TO_GLOBAL_TIME_SYNCHRONIZATION / OsScheduleTableSync 
>  OIL: If set to TRUE, the synchronization of this schedule table is switched on and the 
sub-attributes will be visible. 
>  XML: If this attribute is present in the configuration the synchronization is used for this 
schedule table. 
This is only relevant in SC4. 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
SYNC_STRATEGY 
OsScheduleTbl 
EXPLICIT 
Defines the synchronization strategy of this 
SyncStrategy 
schedule table. 
IMPLICIT 
>  EXPLICIT: The schedule table is driven by 
NONE 
an OS counter, but processing needs to be 
synchronized with a different counter, which 
is not an OS counter object. 
>  IMPLICIT: The counter driving the schedule 
table is the counter with which 
synchronisation is required 
>  NONE: no synchronization is applied at all 
SYNC_STRATEGY
OsScheduleTbl 

Defines the synchronization tolerance (in ticks) 
=EXPLICIT/PRECIS ExplicitPrecision 
for this schedule table. 
ION 
If the absolute value of the deviation between 
the schedule table counter and the 
synchronization counter is smaller than this 
2015, Vector Informatik GmbH 
Version: 9.01 
126 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Attribute Name 
Values 
Description 
The default value 
OIL 
XML 
is written in bold 
value schedule table state is set to 
SCHEDULETABLE_RUN-
NING_AND_SYNCHRONOUS 
Table 7-31   Sub-attributes SCHEDULETABLE-> LOCAL_TO_GLOBAL_TIME_SYNCHRONIZATION = TRUE 
 
2015, Vector Informatik GmbH 
Version: 9.01 
127 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
8  System Generation 
This chapter describes the generation of the executable program. The definition of the OIL 
/  XML  file  was  described  in  the  chapter  7  Configuration. The  general  steps programming 
an  application  using  the  OSEK  operating  systems  are  illustrated  in  chapter  7.1 
Configuration and generation process.
 
The dependencies on include files are described in chapter 5.2 Include Structure. 
8.1 
Code Generator 
The code generator GENxxxx.EXE is delivered with the MICROSAR OS package (xxxx is 
replaced by the hardware platform name). The code generator is implemented as a 32-bit 
Windows console application and can be started from the OIL Configurator or directly from 
the command line. 
The  code  generator  has  different  command-line  options.  When  started  without  any 
parameters, a list of all parameters is printed: 
GENxxxx.EXE, Version: 6.00, Vector Informatik GmbH, 2012 
Usage: GENxxxx.EXE [options] <Filename> 
-s : print symboltable 
-r <Filename> : write errors into file 
-g : generate code 
-d <Pathname> : path to write generated code 
-m : prints list of known implementations 
-i <Pathname>: include path for implementation files 
-x : include path equals to generator exe path 
-f <Filename>: read options and filename from command file 
-y : perform a syntax check on OIL file 
 
8.1.1 
Generated Files 
The code generator generates several files as described in chapter 5.1.2 Dynamic Files. 
The files always have the same name. They are written to the generation path specified in 
the OIL Configurator or with the command line option -d. 
The '.c' modules have to be compiled and linked to the application. 
8.1.2 
Automatic Documentation 
Automatic documentation of the generation process is provided by two list files, which are 
generated  by  the  code  generator.  A  basic  list  file  is  generated  in  text  format.  The  more 
detailed list file is generated in HTML format and can be used to publish a system design 
in the internet or an intranet. Both files have the same name as the OIL file, i.e.: 
>  <OILFileName>.lst   (basic list file in text format) 
>  <OILFileName>.htm   (extended list file in HTML format) 
The files are located in the directory of the OIL file. 
2015, Vector Informatik GmbH 
Version: 9.01 
128 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
8.1.3 
Conditional Generation 
If  MICROSAR  OS  is  configured  using  an  OIL  file,  the  OS  object  provides  the  attribute 
ConditionalGenerating. If AUTOSAR ECUC files are used for configuration, the parameter 
for conditional generation is not located in the OS configuration but in the BSWMD file of 
the Board, as other modules also use this parameter. 
If  conditional  generation  is  selected,  the  generated  files  are  overridden  only  if  the  OS 
configuration  has  changed  since  the  last  generator  run.  This  allows  using  the  file 
modification date of the generated files to decide which modules need recompilation after 
configuration changes. Compile times of a complete AUTOSAR stack may be dramatically 
reduced with this setting in the development cycle. 
Setting  ConditionalGenerating  =  FALSE  forces  the  MICROSAR  OS  code  generator  to 
generate  the  files  newly  on  each  run.  This  is  the  recommended  setting  for  the  final, 
productive build. 
8.1.4 
Generated files backup 
To avoid a mixed set of generated files from various runs of the generator, already existing 
files are either deleted or renamed before the new generation starts.  
Before previously generated files are overwritten in a new run of a generator, the complete 
file set is renamed to files with the original name plus a “.bak” suffix (backup file set). This 
file set contains the last valid generated file set even if a consecutive generator run fails for 
any reason. 
8.2 
Application Template Generator 
The application template generator is not available in current versions of MICROSAR OS. 
8.3 
Compiler 
The supported compiler package has to be installed, and the search path of the compiler, 
assembler and linker has to be set. If special options are  required, they are described in 
the hardware specific manual. 
8.3.1 
Include Paths 
The  operating  system  is  delivered  with  include  files  in  the  subdirectory 
root\HwPlatform\include (osCAN style) or root\BSW\Os (MICROSAR style). 
2015, Vector Informatik GmbH 
Version: 9.01 
129 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
9  AUTOSAR Standard Compliance 
9.1  Deviations 
Currently no known deviations 
9.2  Limitations 
9.2.1 
API Function OS_GetVersionInfo 
The function 
void OS_GetVersionInfo(Std_VersionInfoType *version info) 
is  not  supported  by  MICROSAR  OS.  The  version  information  can  be  collected  by  the 
following #defines: 
Vendor ID 
OS_VENDOR_ID 
Module ID 
OS_MODULE_ID 
Major version number 
OS_SW_MAJOR_VERSION 
Minor version number 
OS_SW_MINOR_VERSION 
Patch version number 
OS_SW_PATCH_VERSION 
9.2.2 
Forcible Termination 
MICROSAR OS does currently not support forcible termination. The only possible reaction 
on a protection error is to shutdown the system. 
9.2.3 
AUTOSAR Debug support 
MICROSAR  OS  does  not  provide  any  variables  and  type  definitions  for  AUTOSAR 
Debugging (See requirements OS549-551 in [1]). The suggested way to gather information 
about the internals of the OS is to use the ORTI feature supported by MICROSAR OS. 
9.2.4 
Port Interface 
The  Port  interface  described  by  requirements  OS560,  OS561  in  [1]  is  not  supported  by 
MICROSAR OS. 
9.2.5 
NULL Pointer Checks 
Null  pointer  checks  described  by  requirements  OS566  is  [1]  are  not  implemented  in 
MICROSAR OS. 
9.2.6 
SafeContext specific limitations 
In  order  to  achieve  a  safe  execution  environment  and  fulfill  the  requirement  for  reduced 
complexity of ISO26262, the following OSEK/AUTOSAR OS features are not implemented 
in MICROSAR OS SafeContext. 
>  Pre- and PostTaskHook as well as ISRHooks are only supported as a debug feature 
and not released for use in safety environments. 
2015, Vector Informatik GmbH 
Version: 9.01 
130 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
>  Application specific hook routines are not supported. 
>  Forcible termination of Tasks, ISRs or OS-Applications is neither supported through the 
service TerminateApplication, nor as a reaction to a protection violation. 
>  All checks of the OS must be turned on any time (StackMonitoring, OSInternalChecks). 
>  ORTI Debug information is always recorded and cannot be turned off. 
>  Internal resources are not supported. 
>  StartupHook, ErrorHook, ShutdownHook and ProtectionHook cannot be turned off in the 
configuration. 
Further restrictions may be found in [5] and/or [9]. 
On  the  other  hand,  there  are  additional  features  and  measures  implemented  in 
MICROSAR OS SafeContext to increase safety: 
>  StartOS is protected against calls from non-trusted code to avoid unintended reboot. 
>  An API is provided to allow protected access to peripherals (either by peripheral 
protection subsystem if provided by the hardware, or by memory protection, see [5] for 
details). However, trusted applications are always granted full access to all peripherals. 
>  A global Shared Memory Area allows quick exchange of non-critical data between OS-
Applications. 
>  Non-trusted functions allow a safe execution of non-trusted code triggered by trusted 
code. 
>  A user configuration version can be freely assigned and read via an API 
(osGetConfigBlockVersion), allowing verification that the correct configuration is used 
during runtime. 
2015, Vector Informatik GmbH 
Version: 9.01 
131 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
10  Debugging Support 
10.1  Kernel aware Debugging 
All  implementations  of  MICROSAR  OS  support  kernel-aware  debugging  according  to  the 
ORTI specification. On some platforms, proprietary solutions are available. 
Refer to the hardware specific documentation [4] for details. 
10.2  Version and Variant Coding 
The version and the variant are coded into the generated binary or HEX file. The user has 
the possibility to read version and variant using an emulator, or if the electronic control unit 
is accessible via the CCP protocol via the CAN bus.  
The generator writes version and variant information into a structure, defined in osek.h. 
typedef struct 

   osuint8 ucMagicNumber1;     /* magic number:                        */ 
   osuint8 ucMagicNumber2;     /* defined as uint8 for independency of */ 
   osuint8 ucMagicNumber3;     /* byte order                           */ 
   osuint8 ucMagicNumber4; 
    
   osuint8 ucSysVersionMaj;    /* version of operating system, Major   */ 
   osuint8 ucSysVersionMin;    /* version of operating system, Minor   */ 
   osuint8 ucGenVersionMaj;    /* version of code generator            */ 
   osuint8 ucGenVersionMin;    /* version of code generator            */ 
   osuint8 ucSysVariant1;      /* general variant coding 1             */ 
   osuint8 ucSysVariant2;      /* general variant coding 2             */ 
   osuint8 ucOrtiVariant;      /* ORTI version and variant             */ 
    
   …                       /* implementation specific variant coding */ 
 
} osVersionVariantCodingType; 
 
The  structure  contains  the  version  of  the  operating  system  (major  and  minor  version 
number),  the  version  of  the  code  generator  used  (major  and  minor  version  number), 
information  about  the  OS  configuration  bit-encoded  into  8-bit  values  (ucSysVariantX) 
and information about usage of the OSEK runtime interface (ORTI): 
The  magic  number  is  defined  as  0xAFFEDEAD  and  may  be  used  for  an  identification  of 
the version in hex or binary files. 
Bits 
Meaning 
Possible Values 
0..1 
Conformance Class 
3: ECC2 

Status Level 
1: EXTENDED STATUS 
3..4 
Scheduling policy 
2: mixed preemptive 

Stack Check 
1: enabled 
2015, Vector Informatik GmbH 
Version: 9.01 
132 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
Bits 
Meaning 
Possible Values 

Error information level 
0 STANDARD 

OS internal checks 
1 Additional 
Table 10-1   Bit-definitions of the variant coding, ucSysVariant1 
Bits 
Meaning 
Possible Values 
0..1 
Scalability Class 
2: SC3   3: SC4 

Usage of Schedule tables 
0: no schedule tables in system 
1: schedule tables are used 

Usage of high resolution 
0: no high resolution tables in system 
schedule tables 
1: high resolution schedule tables are used 

Schedule table 
0: synchronization is not used 
synchronization 
1: synchronization is used 

Timing protection 
0: timing protection is used 
1: timing protection is switched off 
Table 10-2   Bit-definitions of the variant coding, osSysVariant2 
 
Bits 
Meaning 
Possible Values 
0..6 
ORTI version 
0x22: ORTI 2.2 used 

ORTI additional information 
1: The full set of ORTI information is provided by the 
OS 
Table 10-3   Bit definitions of the variant coding, osOrtiVariant 
The data for the structure is located in the constant oskVersionVariant and specified in the 
OS module osek.c. 
The  structure  also  contains  implementation  specific  variant  coding  which  is  described  in 
the separate documentation [4]. 
 
2015, Vector Informatik GmbH 
Version: 9.01 
133 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
11  Glossary and Abbreviations 
11.1  Abbreviations 
Abbreviation 
Description 
API 
Application Programming Interface   
AUTOSAR 
Automotive Open System Architecture 
BSW 
Basis Software 
CCP 
CAN Calibration Protocol 
COM 
Communication (= module COM in AUTOSAR/MICROSAR)  
CPU 
Central Processing Unit 
ECU 
Electronic Control Unit 
EPROM 
Erasable Programmable Read Only Memory 
EEPROM 
Electrically Erasable Programmable Read Only Memory 
HIS 
Hersteller Initiative Software 
IRQ 
Interrupt ReQuest 
ISR 
Interrupt Service Routine 
MICROSAR 
Microcontroller Open System Architecture (the Vector AUTOSAR 
solution) 
NM 
Network Management (= module NM in AUTOSAR/MICROSAR) 
NMI 
Non Maskable Interrupt 
OIL 
OSEK Implementation Language 
ORTI 
OSEK RunTime  Debugging Interface 
OS 
Operating System 
OSEK 
Abbreviation of the German term "Offene Systeme und deren 
Schnittstellen für die Elektronik im Kraftfahrzeug" - Open Systems and 
the Corresponding Interfaces for Automotive Electronics 
RAM 
Random Access Memory 
ROM 
Read-Only Memory 
SC1, SC2, SC3, SC4  Scalability Class 1, -2, -3, -4 
SEooC 
Safety Element out of Context; a safety related element, which is not 
developed for a specific item 
SRS 
Software Requirement Specification 
SWC 
Software Component 
SWS 
Software Specification 
WCET 
Worst Case Execution Time 
XML 
Extensible Markup Language 
Table 11-1   Abbreviations 
2015, Vector Informatik GmbH 
Version: 9.01 
134 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
11.2  Terms 
 
Terms 
Description 
Forcible Termination 
Forcible termination means that a task, an ISR or even a whole OS 
application is terminated before it has reached its end. This may be 
caused by a call of the API function TerminateApplication or by returning 
certain values in the protection hook. 
Killing 
The term ‘killing’ is used as a synonym for forcible termination within this 
document. 
Process 
The term ‘process’ is used within this document as a short form of ‘task or 
ISR’. 
Thread 
The term ‘thread’ is used as a synonym of the term ‘process’ within this 
document. 
Table 11-2   Terms 
 
 
2015, Vector Informatik GmbH 
Version: 9.01 
135 / 136 
based on template version 4.3 


Technical Reference MICROSAR OS SafeContext  
 
12  Contact 
Visit our website for more information on 
 
>   News 
>   Products 
>   Demo software 
>   Support 
>   Training data 
>   Addresses 
 
www.vector.com 
 
For support requests you may write to osek-support@vector.com 
 
 
 
2015, Vector Informatik GmbH 
Version: 9.01 
136 / 136 
based on template version 4.3 

Document Outline