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
1 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
2 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: A
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
3 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
4 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
4
R2
4
R4
28 * 4 = 112
R5
…
R30
R31
EIPC
4
EIPSW
4
CTPC
4
CTPSW
4
MPLA0
4
MPUA0
4
2015, Vector Informatik GmbH
Version: 1.05 23 / 80
Safety Manual MICROSAR OS SafeContext
5 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
6 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
7 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
8 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
9 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
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_AdSupport 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 chapt
er 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 ...
7 (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 ...
7 (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
0 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
O
RTIDebugSupport 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
4
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
X
GetTaskID
X
TerminateTask
DC
GetTaskState
X
ChainTask
DC
StartOS
-
Schedule
DC
ShutdownOS
-
DisableAllInterrupts
P
GetApplicationID
X
EnableAllInterrupts
P
GetActiveApplicationMode
X
SuspendAllInterrupts
P
GetISRID
X
ResumeAllInterrupts
P
CallTrustedFunction
X
SuspendOSInterrupts
P
CallNonTrustedFunction
X
ResumeOSInterrupts
P
CheckObjectAccess
X
GetResource
X
CheckObjectOwnership
X
ReleaseResource
X
StartScheduleTableRel
X
SetEvent
X
StartScheduleTableAbs
X
ClearEvent
DC
StopScheduleTable
X
GetEvent
X
NextScheduleTable
X
WaitEvent
DC
StartScheduleTableSynchron
X
GetAlarm
X
SyncScheduleTable
X
SetRelAlarm
X
GetScheduleTableStatus
X
SetAbsAlarm
X
SetScheduleTableAsync
X
CancelAlarm
X
IncrementCounter
X
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
1
2
Logical core ID
0
1
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
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
documen
t [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 chapte
r 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 chapte
r 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 chapte
rs 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 chapte
r 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 chapte
r 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 MeasuremenConfig OnlyMeasure t 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
d 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.
l 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 (Chapte
rs 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 (Chapte
rs 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
a
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 0
E_OK
Service executed successfully
1
E_OS_ACCESS
Several APIs: general access of object failure
2
E_OS_CALLEVEL
Several APIs: service accessed from wrong context
3
E_OS_ID
Several APIs: service called with wrong ID
4
E_OS_LIMIT
Several APIs: service called too often
5
E_OS_NOFUNC
Several APIs: (warning) service not executed
6
E_OS_RESOURCE
Several APIs: service called with occupied resource
7
E_OS_STATE
Several APIs: object is in wrong state
8
E_OS_VALUE
Several APIs: passed parameter has wrong value
9
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 documen
t [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
1
TerminateTask
TT
2
ChainTask
HT
3
Schedule
SH
4
GetTaskState
GS
5
GetTaskID
GI
6
osMissingTerminateError
MT
7
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
4
DisableAllInterrupts
DA
5
ResumeOSInterrupts
RI
6
SuspendOSInterrupts
SI
7
osUnhandledException
UE
8
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
9
osRestoreEnableLevelNested
RE
A
osSaveDisableGlobalNested
SG
B
osRestoreEnableGlobalNested RG
C
ResumeAllInterrupts
RA
D
SuspendAllInterrupts
SA
E
GetISRID
II
2
Interrupt Exit (SC3 only)
IX
3
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
1
ReleaseResource
RR
2
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
1
ClearEvent
CE
2
GetEvent
GE
3
WaitEvent
WE
4
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
1
GetAlarm
GA
2
SetRelAlarm
SA
3
SetAbsAlarm
SL
4
CancelAlarm
CA
5
osWorkAlarm
WA
6
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
D
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
1
osSchedulePrio
SP
2
osGetStackUsage
SU
3
osCheckLibraryVersionAndVariant CL
4
osErrorHook
EH
5
StartOS
ST
6
osSchedInsertTask
QI
7
osSchedRemoveRunningTask
QR
8
osSchedOnHomePrio
QS
9
osSchedOccupyInternalResource
QO
A
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
r
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
1
StartScheduleTableAbs
SS
2
StopScheduleTable
SP
3
GetScheduleTableStatus
SG
4
NextScheduleTable
SN
5
osWorkScheduleTable
WS
6
SyncScheduleTable (SC2 and SC4)
SY
7
SetScheduleTableAsync (SC2 and SC4)
AY
8
StartScheduleTableSynchron (SC2 and SC4) TS
C
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
1
GetCounterValue
GC
3
GetElapsedValue
GV
4
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
s
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
0
BlockingTimeMonitoring
BM
7
GetTaskMaxExecutionTime
TE
8
GetISRMaxExecutionTime
IE
9
GetTaskMaxBlockingTime
TB
A
GetISRMaxBlockingTime
IB
B
ExecutionTimeMonitoring
ET
D
GetISRMinInterArrivalTime
MI
F
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
1
AllowAccess
AA
2
TerminateApplication
TA
4
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
1
osReleaseSemaphore
RS
2
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
k
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
d
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
3
CallNonTrustedFunction
NT
4
PeripheralAPI functions
PA
5
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 manua
l [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 chapte
rs 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 referen
ce [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 referen
ce [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 chapt
er 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 chapt
er 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 XMLCodeOILConfiguration Tool
.xmlGenerator
.oilConfigurator
OS source
.c.cConfiguration
.cApplication
files
.h.hfiles
.hfiles
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 schem
a[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
documen
t [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
K
protection error is detected in a MICROSAR OS
SafeContext.
> XML: This attribute is placed in container
OsHooks
CallISRHooks
OsOSCallISRHook
FALSE The UserPreISRHook and
s
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 chapt
er 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 chapt
er 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 chapt
er 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 chapt
er 7.3.1.4 for information about the
sub-attributes. Chap
ter 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 to [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 a
lso 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 chapte
rs 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
(s
ee [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 chapt
er 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 chapt
er 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
e
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
e
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
n
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 chapt
er 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 chapte
r 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 chapte
r 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 chapte
r 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
2
Status Level
1: EXTENDED STATUS
3..4
Scheduling policy
2: mixed preemptive
5
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 6
Error information level
0 STANDARD
7
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
2
Usage of Schedule tables
0: no schedule tables in system
1: schedule tables are used
3
Usage of high resolution
0: no high resolution tables in system
schedule tables
1: high resolution schedule tables are used
4
Schedule table
0: synchronization is not used
synchronization
1: synchronization is used
5
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
7
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