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

Return to the regular view of this page.

OS

1: MicrosarOS_RH850_SafeContext_SafetyManual
2: MicrosarOS_RH850_SafeContext_SafetyManual_ind
3: MicrosarOS_RH850_SafeContext_SafetyManuals
4: Os Integration Manual
5: Os Module Design Document
6: Os Peer Review Checklists
7: ProductInformation_2_Restrictions-for-MSR-OS-SafeContext-SC3
8: ProductInformation_2_Restrictions-for-MSR-OS-SafeContext-SC3_ind
9: ProductInformation_2_Restrictions-for-MSR-OS-SafeContext-SC3s
10: TechnicalReference_MICROSAROS_RH850
11: TechnicalReference_MICROSAROS_RH850_ind
12: TechnicalReference_MICROSAROS_RH850s
13: TechnicalReference_Os
14: TechnicalReference_Os_ind
15: TechnicalReference_Oss

OS

Component Documentation

1 - MicrosarOS_RH850_SafeContext_SafetyManual

MICROSAR OS SafeContext

2 - MicrosarOS_RH850_SafeContext_SafetyManual_ind

3 - MicrosarOS_RH850_SafeContext_SafetyManuals

MICROSAR OS SafeContext Safety Manual

MICROSAR OS SafeContext
Safety Manual

Renesas RH850 with compiler Green Hills

Authors
Senol Cendere, Yohan Humbert, Michael Kock
Version
1.10
Status
Released

© 2016 Vector Informatik GmbH
Version 1.10
1
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
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
Michael Kock
2015-08-18  1.06
Updated chapter Configuration Block
Senol Cendere
2016-01-05  1.07
Updated hardware specific part
Senol Cendere
2016-01-29  1.08
Rework after review
Senol Cendere
2016-02-09  1.09
Rework after review
Michael Kock
2016-06-17  1.10
Updated chapter Review Generated Code and Rework

[END  OF HI ST ORY]

© 2016 Vector Informatik GmbH
Version 1.10
2
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
Reference Documents
No.  Source
Title
Version
[1]    AUTOSAR
AUTOSAR Operating System Specification
3.x
This document is available in PDF-format on the Internet at
4.x
the AUTOSAR homepage: http://www.autosar.org
[2]    OSEK
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
[3]    Vector Informatik
MICROSAR OS SafeContext Technical Reference  9.01
GmbH
TechnicalReference_Os.pdf
[4]    Vector Informatik
MICROSAR Safe Silence Verifier Technical
1.04
GmbH
Reference
TechnicalReference_MSSV.pdf
[5]    Vector Informatik
MICROSAR OS RH850 User Manual
1.10
GmbH
TechnicalReference_MICROSAROS_RH850.pdf
[6]    Vector Informatik
Vector MICROSAR OS SafeContext Concept
1.04
GmbH
[7]    ISO
International Organization for Standardization,
2009
Draft International Standard ISO/DIS 26262 Road
Vehicles - Functional Safety (all parts), 2009
[8]    Renesas Electronics  V850E3v5 Architecture Specifications
(5th edition)
[9]    Renesas Electronics   RH850G3K User’s Manual: Software
Rev. 1.00

r01us0125ej0100_rh850g3k.pdf
Aug, 2014
[10]   Renesas Electronics   RH850G3M User’s Manual: Software
Rev. 1.00

r01us0123ej0100_rh850g3m.pdf
Aug, 2014
[11]   Green Hills Software  MULTI: Building Applications for Embedded V850
PubID:
and RH850
build_v800-
build_v800.pdf
496213
Date: October
4, 2013
© 2016 Vector Informatik GmbH
Version 1.10
3
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
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 262621
>  OSEK OS2
>  AUTOSAR OS3


1 International Standard ISO 26262 Road Vehicles - Functional Safety (all parts), 2011
2 OSEK/VDX Operating System, v2.2.3
3 AUTOSAR Specification of Operating  System
© 2016 Vector Informatik GmbH
Version 1.10
8
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
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.
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.
The OS assures this mainly by programming of an MPU.
ASA_OS_2: A runtime context (Task, Hook, (Non-)Trusted-Function or ISR) must not
be destroyed by a switch (to another runtime context).
The  OS  assures  this  mainly  by  correct  storage  and  restauration  of  the  register
context.
ASA_OS_3: A runtime context shall be set up according to compiler and processor
specifications.
The OS assures this mainly by correct implementation of the register setup at context
switches.
ASA_OS_4:  Services  to  prevent  data  inconsistencies  by  racing  conditions  shall  be
provided.
The OS provides the following functions for this purpose:
  DisableAllInterrupts/EnableAllInterrupts,
  SuspendOsInterrupts/ResumeOSInterrupts
  SuspendAllInterrupts/ResumeAllInterrupts
ASA_OS_5: The OS never writes to unintended memory locations.
The OS assures this mainly by correct implementation of its functionality.
© 2016 Vector Informatik GmbH
Version 1.10
9
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
2.4
SafeContext Functionality
MICROSAR OS SafeContext implements the AUTOSAR OS and OSEK OS standards of a
real-time operating system with some restrictions.

2.4.1
ASIL Functionality
Derived  from  our  safety  requirements,  SafeContext  provides  the  following  functionality
safely:
1.  Context management
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/preemption/stop,
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
  All other OS functionality, for example the sequence of task executions (scheduling)
including the Task pre-emption is provided on QM level.

© 2016 Vector Informatik GmbH
Version 1.10
10
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
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-1  Stored and active contexts

© 2016 Vector Informatik GmbH
Version 1.10
11
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
2.4.2
Detailed List
2.4.2.1
Provided Functionality
The following OS services are provided by MICROSAR OS SafeContext.
Class
Description
Startup API
>  osInitialize
>  osInitINTC
>  StartOS
Shutdown API
>  ShutdownOS
Application API
>  GetApplicationID
>  CheckObjectOwnership
>  CheckObjectAccess
>  GetApplicationState (if ASR4)
>  AllowAccess
>  GetISRID
>  GetTaskID
>  GetActiveApplicationMode
>  CheckObjectAccess
>  CheckObjectOwnership
Interrupt API
>  DisableAllInterrupts
>  EnableAllInterrupts
>  SuspendAllInterrupts
>  ResumeAllInterrupts
>  SuspendOSInterrupts
>  ResumeOSInterrupts
Stack usage API
>  osGetStackUsage
>  osGetISRStackUsage
>  osGetSystemStackUsage
Trusted Function
>  CallTrustedFunction
API
Schedule Table API  >  StartScheduleTableRel
>  StartScheduleTableAbs
>  StopScheduleTable
>  NextScheduleTable
>  GetScheduleTableStatus
Event API
>  SetEvent
>  ClearEvent
>  GetEvent
© 2016 Vector Informatik GmbH
Version 1.10
12
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
Class
Description
>  WaitEvent
Alarm API
>  GetAlarm
>  SetRelAlarm
>  SetAbsAlarm
>  CancelAlarm
Resource API
>  GetResource
>  ReleaseResource
Task API
>  ActivateTask
>  TerminateTask
>  ChainTask
>  Schedule
>  GetTaskState
Counter API
>  IncrementCounter
>  GetElapsedValue(ASR4)/GetElapsedCounterValue(ASR3)
>  GetCounterValue
SafeContext
>  osCheckMPUAccess
Extensions
>  osCheckAndRefreshTimer
>  osCheckAndRefreshMPU
>  osGetConfigBlockVersion
>  CallNonTrustedFunction
>  osReadPeripheral8
>  osReadPeripheral16
>  osReadPeripheral32
>  osWritePeripheral8
>  osWritePeripheral16
>  osWritePeripheral32
>  osModifyPeripheral8
>  osModifyPeripheral16
>  osModifyPeripheral32
OS System Hooks
>  StartupHook
>  ErrorHook
>  ProtectionHook
>  ShutdownHook
Error Handling
>  osUnhandledException
>  osAbortSystem
>  OSErrorGetServiceId
© 2016 Vector Informatik GmbH
Version 1.10
13
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
Class
Description
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 realized as QM software.
Table 2-1   MICROSAR OS SafeContext Functionality

2.4.2.1.1
osGetConfigBlockVersion
Description of the osGetConfigBlockVersion-API. [SPMF92:0045]
Prototype
uint16 osGetConfigBlockVersion(void)
Return code
uint16
The version number which was specified by the user in the
configuration attribute UserConfigurationVersion.
Functional Description
Return user configuration version.
Particularities and Limitations
>  -
Call context
>
any

2.4.2.2
Not provided Functionality
The features listed in the following table are not supported in SafeContext per default.
Class
Description
OS service API
>  TerminateApplication
>  CheckISRMemoryAccess
>  CheckTaskMemoryAccess
>  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]
© 2016 Vector Informatik GmbH
Version 1.10
14
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
Class
Description
Killing
Terminating Tasks or Applications is not supported.
OS Hooks
>  PreTaskHook (only for debugging!)
>  PostTaskHook (only for debugging!)
>  ISRHook
>  PreAlarmHook
OS Application
>  StartupHook<AppName>
specific Hooks
>  ErrorHook<AppName>
>  ShutdownHook<AppName>
Address Parameter  In case API functions with output-parameters are called with illegal
Check
address, 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 and stack sharing are not supported.
Internal Resources  Internal Resources are not supported.
Configuration
The following hooks must always 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-2   Functionality – Not provided

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.

© 2016 Vector Informatik GmbH
Version 1.10
15
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
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 “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”)
Follow SafeContext guidelines

(see chapter “SafeContext Guidelines”)
Review the safety relevant configuration data

(see chapter “Configuration Block Review”)
Qualify the generated OS code

(see chapter “Generated OS Code”)
Review your software

(see chapter “Review User Software”)
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!

© 2016 Vector Informatik GmbH
Version 1.10
16
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
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

Patching the
In Human
Configuration Block
Readable

Hex Converter
ConfigBlock
Executable
Hex File
Verify ConfigBlock
Flashing
Read Back
ECU

Figure 3-1  Strategy for safety configuration
© 2016 Vector Informatik GmbH
Version 1.10
17
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
4
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 which is not part of the
SafeContext safety requirements. Only the safety requirements (see chapter “Safety
Requirements”) are assured by SafeContext.
[SPMF92:0075]
Timing and Scheduling

If timing and scheduling is safety critical in your application, you have to supervise this
by an external tool like e.g. SafeWatchdog.
[SPMF92:0050]
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.
Use only the delivered OS generator

The  user  shall  only  use  the  delivered  OS  generation  tool  for  generating  the  user
specific configuration.
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

© 2016 Vector Informatik GmbH
Version 1.10
18
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
Description of requirements to the OS user
Fulfilled
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

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
© 2016 Vector Informatik GmbH
Version 1.10
19
based on template version 2.0

MICROSAR OS SafeContext Safety Manual
4.1
Context Definition
The context which is used by MICROSAR OS RH850 consists of the following registers:
FPU used
Registers
Size in Bytes FPU not used Registers
Size in Bytes
R1
4
R1
4
R2
4
R2
4

R4
28 * 4 = 112
R4
28 * 4 = 112
R5
R5
…
…
R30
R30
R31
R31

total size = 152
total size = 144
EIPC
4
EIPSW
4
CTPC
4
EIPC
4
CTPSW
4
EIPSW
4
MPLA0
4
CTPC
4
MPUA0
4
CTPSW
4
FPSR
4
MPLA0
4
FPEPC
4
MPUA0
4

Caution
FPU setting in OS configuration must match the used compiler FPU option!

© 2016 Vector Informatik GmbH
Version 1.10
20
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
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.exe <config.ini>

This tool calculates the CRC32 checksum over all files specified in file <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 file <config.ini> shall contain the OS sources listed in the Safety Case.

The calculated checksum returned by tool CCodeSafe.exe must be identical to the

checksum given in the Safety Case.

© 2016 Vector Informatik GmbH
Version 1.10
21
based on template version 2.0

MICROSAR OS SafeContext Safety Manual

Example
An example for a <config.ini> file:

..\..\implementation\atosappl.c
..\..\implementation\atostime.c
..\..\implementation\osek.c
..\..\implementation\osekalrm.c
..\..\implementation\osekasm.c
..\..\implementation\osekerr.c
..\..\implementation\osekevnt.c
..\..\implementation\osekrsrc.c
..\..\implementation\oseksched.c
..\..\implementation\osekstart.c
..\..\implementation\osektask.c
..\..\implementation\osektime.c
..\..\implementation\osOstmHiRes.c
..\..\implementation\osSysCall.c
..\..\implementation\Os.h
..\..\implementation\Os_Cfg.h
..\..\implementation\osDerivatives.h
..\..\implementation\osek.h
..\..\implementation\osekasm.h
..\..\implementation\osekasrt.h
..\..\implementation\osekcov.h
..\..\implementation\osekerr.h
..\..\implementation\osekext.h
..\..\implementation\oseksched.h
..\..\implementation\osINTC2.h
..\..\implementation\osRH850_F1L.h
..\..\implementation\testmac1.h
..\..\implementation\vrm.h
..\..\implementation\osSysCallTable.dld

© 2016 Vector Informatik GmbH
Version 1.10
22
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
6
Patching the Configuration Block
Configuration  information  which  is  relevant  to  reach  the  safety  goals  is  stored  in  a  data
structure  called  the  configuration  block.  The  integrity  of  this  information  is  checked  in
StartOS using a CRC16 checksum.
The CRC must be calculated after compiling and linking the application. There are two
programs provided to calculate and apply the CRC patch into the binary file:
ElfConverter.exe
For patching the CRC into an ELF file.
Creating an intermediate file for reading back the configuration
block is also possible with this tool.
ConfigBlockCRCPatch.exe
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 the complete application project to build the executable
2.  Run CRC patch tool on executable
3.  Write modified executable into ECU 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]

© 2016 Vector Informatik GmbH
Version 1.10
23
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
6.1
Using ElfConverter
The program ElfConverter.exe is called with the following parameters:
ElfConverter.exe <Input-File> <Output-File> --crc_patch

Parameter
Description
<Input-File>    Input file with ELF-format which was built by the compiler tool chain
<Output-File>
Intermediate output file which is used by the tool ConfigViewer.exe for
reading back the configuration block.
--crc_patch
Patch CRC checksum into ELF-file
--help
Show help
Table 6-1   ElfConverter Parameters

Example
Patching the CRC checksum into configuration block of ELF-file testappl.out:

ElfConverter.exe testappl.out testcfg.hex --patch_crc

6.2
Using ConfigBlockCRCPatch
The tool ConfigBlockCRCPatch.exe is called with the following parameters:
ConfigBlockCRCPatch.exe <Input-File> <Output-File> <Base-Address>

Example
Read HEX-file project.hex and create file project2.hex with patched CRC checksum:

ConfigBlockCRCPatch.exe project.hex project2.hex 0x4000
Read SREC-file project.mot and create file project2.mot with patched CRC checksum:
ConfigBlockCRCPatch.exe project.mot project2.mot 0x4000

The address of the configuration block must be taken via symbol _osConfigBlock from
the linker generated map file. [SPMF92:0016]

© 2016 Vector Informatik GmbH
Version 1.10
24
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
7
SafeContext Guidelines
7.1
Configuration
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 goals

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] [SPMF92:03.0010]
>  Category 1 ISRs [SPMF92:0054] [SPMF92:03.0004] [SPMF92:03.0010]
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  the  MPU  granularity  is.
[SPMF92:0065] [SPMF92:04.0005]
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]
FPU  setting  in  OS  configuration  must  match  compiler  FPU  option.
[SPMF92:04.0019]
© 2016 Vector Informatik GmbH
Version 1.10
25
based on template version 2.0

MICROSAR OS SafeContext Safety Manual
Description of requirements to the OS user
Fulfilled
Check that osdRH850_FPU is only defined in file tcb.h and in osek.h
If compiler option -fnone or -fsoft is used, then assure that in OS
configuration the attribute SupportFPU is set to FALSE and that in file tcb.h
the following line is generated:
#define osdRH850_FPU 0
If compiler option -fsingle or -fhard is used, then assure that in OS
configuration the attribute SupportFPU is set to TRUE and that in file tcb.h
the following line is generated:
#define osdRH850_FPU 1

© 2016 Vector Informatik GmbH
Version 1.10
26
based on template version 2.0

MICROSAR OS SafeContext Safety Manual
7.2
Linking Example for Memory Mapping
The memory mapping should look like following example:

Figure 7-1 Linking Example
© 2016 Vector Informatik GmbH
Version 1.10
27
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8
Configuration Block Review
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 CRC16 checksum. 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.  Patch CRC checksum into executable file and create the intermediate file:
a)  use ElfConverter.exe for CRC patch and intermediate file creation
b)  or use ConfigBlockCRCPatch.exe for CRC patch and use HexConverter.exe for
intermediate file creation
2.  Extract the configuration block from intermediate file into human readable output by
using the tool ConfigViewer.exe
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.

© 2016 Vector Informatik GmbH
Version 1.10
28
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.1.1  Using ElfConverter
The tool ElfConverter.exe is able to patch CRC into ELF-file and create the intermediate
file for reading back the configuration block. It is called with the following parameters:
ElfConverter.exe <Input-File> <Output-File> --crc_patch

Parameter
Description
<Input-File>     Input file with ELF-format which was built by the compiler tool chain
<Output-File>
Intermediate output file which is used by the tool ConfigViewer.exe for
reading back the configuration block.
--crc_patch
Patch CRC checksum into ELF-file
--help
Show help
Table 8-1   ElfConverter Parameters

8.1.2  Using HexConverter
The tool HexConverter.exe creates the intermediate file for reading back the configuration
block. It must be used after the CRC is patched via tool  ConfigBlockCRCPatch.exe. Tool
HexConverter.exe is called with the following parameters:
HexConverter.exe –i <Input-File> -o <Output-File> -b <Address> -s <Size>
All parameters are mandatory.
Parameter  Value
Description
-i
Input File Path and Name  File which was created by ConfigBlockCRCPatch.exe
-o
Output File Path and
Intermediate output file which is used by the tool
Name
ConfigViewer.exe for reading back the configuration
block.
-b
Base Address of data
Base address of the configuration block as defined in the
structure _osConfigBlock   linker map file.
(see linker map file)
It is the address of the symbol ‘osConfigBlock’.
Value has to be given as hexadecimal (e.g. 0x008000).
-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-2   HexConverter parameters

© 2016 Vector Informatik GmbH
Version 1.10
29
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.1.3  Using ConfigViewer
The tool ConfigViewer.exe reads the intermediate file and creates a human readable file.
The  intermediate  input  file  must  be  generated  via  tool  ElfConverter.exe  or
HexConverter.exe. ConfigViewer.exe is called with the following parameters:
ConfigViewer –i <Input-File> -o <Output-File> -x <XML-File>
Parameter  Value
Description
-i
Input File Path & Name
Intermedia input file which was created by
ElfConverter.exe or HexConverter.exe
-o
Output File Path & Name  Human readable configuration output file
-x
XML-ConfigFile
optional: XML-file which was generated by the OS
generator with additional description of the OS
configuration
Table 8-3   ConfigViewer Parameters
ConfigViewer.exe  expects  the  intermediate  file  format  to  contain  nothing  else  than  the
configuration block with patched CRC checksum.

© 2016 Vector Informatik GmbH
Version 1.10
30
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual

8.2
Configuration Block Head
The configuration block head contains information to identify the configuration block.

Example
The configuration block head must look like:

==================================================
Start of Config Block 0x00004000
Length 636
CRC 0x14e9
Config Block Format Version 03.00
MICROSAR OS RH850 SafeContext Version 01.06
User Config Version 1
==================================================

Description of requirements to the OS user
Fulfilled
Check that the listed start address, length and CRC is correct and matches the linker
map file of symbol osConfigBlock.
Check that the listed configuration block format is 03.00

Check  that  the  listed  version  of  MICROSAR  OS  RH850  SafeContext  matches  the
delivered OS version.
If you are using the user configuration version, check that the listed one matches the
configured value. [SPMF92:0045]
The names printed by the ConfigViewer come from an unsafe source. For this reason
check  that  object  IDs  and  object  Names  have  the  same  mapping  in  all  configuration
block sub-containers.

© 2016 Vector Informatik GmbH
Version 1.10
31
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.3
General Information
The configuration viewer generates the general information as followed [SPMF92:0063].

Example
The container “General Information” must look like:

0. General Information
-------------------------------------------------------
Property Value Checked?
-------------------------------------------------------
Stack Usage Measurement Yes [ ]
Number of Tasks 11 [ ]
Number of Cat1 ISRs 0 [ ]
Number of Cat2 ISRs     3 [ ]
Number of Trusted Functions 1 [ ]
Number of Non-Trusted Functions 0 [ ]
Number of Applications 3 [ ]
Number of Peripheral Regions 0 [ ]
Number of Alarms 2 [ ]
Number of all Resources 1 [ ]
Number of CPU Cores 1 [ ]
Number of Counters 2 [ ]
Number of Processes 14    [ ]
Number of ScheduleTables 1 [ ]
Number of Spinlocks 0 [ ]
Number of MPU Regions 4 [ ]
Number of Dynamic MPU Regions 0 [ ]
Number of Static MPU Regions 1 [ ]
System Stack Start-Address 0xfedf0720 [ ]
System Stack End-Address 0xfedf08b0 [ ]
-------------------------------------------------------

Note
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 are active at runtime.

© 2016 Vector Informatik GmbH
Version 1.10
32
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual

Description of requirements to the OS user
Fulfilled
Check that the listed number of OS objects matches the OS 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  following  sub
containers. [SPMF92:0074]
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 stack MPU values lower address matches the corresponding stack start

address
Compare the system stack start address in the configuration viewer output against

the label  _osSystemStack_<CoreID>_StartAddr in the linker map-file.
Compare the system stack end address in the configuration viewer output against

the label _osSystemStack_<CoreID>_EndAddr in the linker map-file.
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.
Check that only the array variable osSystemStack<CoreID>  is located between the
labels described above.
Check the difference between the system stack start- and end-address against the

designed (and therefore also configured) system stack size.

© 2016 Vector Informatik GmbH
Version 1.10
33
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.4
Task Start Address
Container “Task Start Address” contains the start addresses of all task functions.

Example
The container “Task Start Address” must look like:

1. Task Start Address:
--------------------------------------------------
Task-ID Task-Name Value Checked?
--------------------------------------------------
0 (osSystemExtendedTask) 0x00007cea [ ]
1 (Task2) 0x0000553a [ ]
2 (Task1) 0x00005508 [ ]
3 (osSystemBasicTask) 0x00007ce8 [ ]
--------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that the listed Task start addresses match to the function start address called
<Task-Name>func (see linker map file). [SPMF92:02.0025]

© 2016 Vector Informatik GmbH
Version 1.10
34
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.5
Task Pre-emptive Configuration
Container  “Task  Pre-emptive  Attribute  Setting”  contains  information  about  which  task  is
full-pre-emptive or non-pre-emptive.

Example
Container “Task Pre-emptive Attribute Setting" must look like:

2. Task Pre-emptive Attribute Setting:
--------------------------------------------------------
Task-ID Task-Name Value Checked?
--------------------------------------------------------
0 (osSystemExtendedTask) full pre-emptive [ ]
1 (Task2) full pre-emptive [ ]
2 (Task1) full pre-emptive [ ]
3 (osSystemBasicTask) non pre-emptive [ ]
--------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check  that  the  listed  task  pre-emptive  attribute  settings  matches  the  OS
configuration.

© 2016 Vector Informatik GmbH
Version 1.10
35
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.6
Task Trusted Configuration
Container "Task Trusted Attribute Setting” contains information about which task is trusted
or non-trusted.

Example
Container “Task Trusted Attribute Setting” must look like:

3. Task Trusted Attribute Setting:
---------------------------------------------------
Task-ID Task-Name Value Checked?
---------------------------------------------------
0 (osSystemExtendedTask) trusted [ ]
1 (Task2) non-trusted [ ]
2 (Task1) non-trusted [ ]
3 (osSystemBasicTask) trusted [ ]
---------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that the trusted attribute setting of each task fits to the trusted attribute setting
of the owner application [SPMF92:0061].

© 2016 Vector Informatik GmbH
Version 1.10
36
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.7
Task Stack Addresses
Container “Task Stack Lower Boundary Address” contains start address of all task stacks.

Example
Container “Task Stack Lower Boundary Address” must look like:

4. Task Stack Lower Boundary Address:
--------------------------------------------------
Task-ID Task-Name Value Checked?
--------------------------------------------------
0 (osSystemExtendedTask) 0xfedf08b0 [ ]
1 (Task2) 0xfedf0590 [ ]
2 (Task1) 0xfedf0720 [ ]
3 (osSystemBasicTask) 0xfedf08c0 [ ]
--------------------------------------------------

Container “Task Stack Upper Boundary Address” contains end address of all tasks stacks.

Example
Container “Task Stack Upper Boundary Address” must look like:

5. Task Stack Upper Boundary Address:
--------------------------------------------------
Task-ID Task-Name Value Checked?
--------------------------------------------------
0 (osSystemExtendedTask) 0xfedf08c0 [ ]
1 (Task2) 0xfedf0720 [ ]
2 (Task1) 0xfedf08b0 [ ]
3 (osSystemBasicTask) 0xfedf08d0 [ ]
--------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that the difference between stack start and stack end address fits to the

configured size of each task stack.
Check that the stacks do not overlap [SPMF92:0056]. Start address of stack on higher
address must be >= end address of stack on lower address.
Compare 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.

© 2016 Vector Informatik GmbH
Version 1.10
37
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.8
Task to Application Mapping
Container “Task to Application Mapping” contains the assignment of tasks to applications.

Example
Container “Task to Application Mapping” must look like:

6. Task to Application Mapping:
--------------------------------------------------------------------------
Task-ID Task-Name Appl-ID Appl-Name Checked?
--------------------------------------------------------------------------
0     (osSystemExtendedTask) 3 (osSystemApplicationCore0) [ ]
1 (Task2) 0 (ApplNonTrust) [ ]
2 (Task1) 0 (ApplNonTrust) [ ]
3 (osSystemBasicTask) 3     (osSystemApplicationCore0) [ ]
--------------------------------------------------------------------------

Description of requirements to the OS user
Fulfilled
The configuration of each application contains a list of the tasks which belong to this
application. Check for each of the named applications that it owns exactly those tasks
listed in the configuration viewer output. [SPMF92:0062]

© 2016 Vector Informatik GmbH
Version 1.10
38
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.9
Category 2 ISR Trusted Configuration
Container “Category 2 ISR Trusted Attribute Setting” contains information about which
category 2 ISR is trusted or non-trusted.

Example
Container  “Category 2 ISR Trusted Attribute Setting” must look like:

7. Category 2 ISR Trusted Attribute Setting:
--------------------------------------------
ISR-ID ISR-Name Value Checked?
--------------------------------------------
0 (ISR1) trusted [ ]
1 (osOstmInterrupt_c0) trusted [ ]
2 (osSystemCat2ISR) trusted [ ]
--------------------------------------------

Description of requirements to the OS user
Fulfilled
Check  that  the  trusted  attribute  setting  of  each  category  2  ISR  fits  to  the  trusted
attribute setting of the owner application.

Note
The trusted attribute setting of the system timer ISR osOstmInterrupt_c<CoreID>
  cannot be configured because it is always a trusted ISR.

© 2016 Vector Informatik GmbH
Version 1.10
39
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.10  Category 2 ISR to Application Mapping
Container “Category 2 ISR to Application Mapping” contains the assignment of category 2
ISR functions to applications.

Example
Container “Category 2 ISR to Application Mapping ” must look like:

8. Category 2 ISR to Application Mapping:
-----------------------------------------------------------------------
ISR-ID ISR-Name Appl-ID Appl-Name Checked?
-----------------------------------------------------------------------
0 (ISR1) 1 (abcAppl) [ ]
1 (osOstmInterrupt_c0) 2 (osSystemApplicationCore0) [ ]
2 (osSystemCat2ISR) 2 (osSystemApplicationCore0) [ ]
-----------------------------------------------------------------------

Description of requirements to the OS user
Fulfilled
The  configuration  of  each  application  contains  a  list  of  ISRs  which  belong  to  this
application. Check for each of the named applications that it owns exactly those ISRs
which are listed in the configuration viewer output [SPMF92:02.0028].
Check that category 1 ISRs are not listed in the configuration block [SPMF92:0055].

© 2016 Vector Informatik GmbH
Version 1.10
40
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.11  Application Trusted Configuration
Container “Application Trusted Attribute Setting” contains information about which
application is trusted or non-trusted.

Example
Container “Application Trusted Attribute Setting” must look like:

9. Application Trusted Attribute Setting:
----------------------------------------------------------
Application-ID Application-Name Value Checked?
----------------------------------------------------------
0 (ApplStartVectCore0) trusted [ ]
1 (abcAppl) trusted [ ]
2 (osSystemApplicationCore0) trusted [ ]
----------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check  that  the  trusted  attribute  of  the  listed  applications  matches  to  the  OS
configuration. [SPMF92:02.0027]

© 2016 Vector Informatik GmbH
Version 1.10
41
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.12  Trusted Functions Configuration
Container “Trusted Functions Start address and Application Mapping” contains the
configuration of trusted functions.

Example
  Container “Trusted Functions Start Address and Application Mapping” must look like:

10. Trusted Functions Start Address and Application Mapping:
-----------------------------------------------------------------------------------------------
Function-ID Function-Name Start-Address Appl-ID Appl-Name Checked?
-----------------------------------------------------------------------------------------------
0 (TF1) 0x0000560c 4 (TrustedApplB) [ ]
1 (TF2) 0x0000564c 4 (TrustedApplB) [ ]
2 (TF3)       0x000056f0 4 (TrustedApplB) [ ]
3 (osSystemTrustedFunction) 0x00007ed2 5 (osSystemApplicationCore0) [ ]
4 (step) 0x0000d3d6 3 (TraceAppl) [ ]
-----------------------------------------------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check  that  the  listed  Trusted  Function  IDs  match  to  the  corresponding  defines  of
function names generated in tcb.h. [SPMF92:0048]
Check  that  the  listed Trusted  Function  start  addresses  matches  the Trusted  Function
start  addresses  called  TRUSTED_<TrustedFunctionName>  (see  linker  map  file).
[SPMF92:0057]
The  configuration  of  each  application  contains  a  list  of  the  trusted  functions  which
belong  to  this  application.  Check  for  each  of  the  named  applications  that  it  owns
exactly those trusted functions listed in the configuration viewer output.

© 2016 Vector Informatik GmbH
Version 1.10
42
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.13  Non-Trusted Functions Configuration
Container “Non-Trusted Functions Start Address and Application Mapping” contains the
configuration of non-trusted functions.

Example
  Container “Non-Trusted Functions Start Address and Application Mapping” must look like:

11. Non-Trusted Functions Start Address and Application Mapping:
--------------------------------------------------------------------------
Function-ID Function-Name Start-Address Appl-ID Appl-Name     Checked?
--------------------------------------------------------------------------
0 (NTFunc1) 0x000054dc 2 (NonTrustedApplA) [ ]

1 (NTFunc2) 0x000068e6 3 (NonTrustedApplB) [ ]
--------------------------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that the listed Non-Trusted Function start addresses matches the address of

symbols NONTRUSTED_<NonTrustedFunctionName> (see linker map file).
[SPMF92:02.0024]
Check that the listed Non-Trusted Function to application assignment matches the OS
configuration. [SPMF92:02.0029]

© 2016 Vector Informatik GmbH
Version 1.10
43
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.14  Category 2 ISR Start Addresses
Container “Category 2 ISR Function Start Address” contains the start address of all
category 2 ISR functions.

Example
Container “Category 2 ISR Function Start Address” must look like:

12. Category 2 ISR Function Start Address:
--------------------------------------------
ISR-ID ISR-Name Value Checked?
--------------------------------------------
0 (ISRNonTrust) 0x000054b6 [ ]
1 (osSystemCat2ISR) 0x00007cac [ ]
--------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that the listed category 2 ISR start addresses match to the function start

address called _<ISR-Name>func (see linker map file). [SPMF92:02.0026]

Note
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.

© 2016 Vector Informatik GmbH
Version 1.10
44
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.15  Category 2 ISR Nesting Configuration
Container “Category 2 ISR Nested Attribute Setting” contains information about which
category 2 ISR is nestable or non-nestable.

Example
Container “Category 2 ISR Nested Attribute Setting” must look like:

13. Category 2 ISR nested attribute setting:
-----------------------------------------------
ISR-ID ISR-Name Value Checked?
-----------------------------------------------
0 (TestTimer1) nested [ ]
1 (osOstmInterrupt_c0) nested [ ]
2 (osSystemCat2ISR) non-nested [ ]
-----------------------------------------------

Description of requirements to the OS user
Fulfilled
Check  that  the  listed  category  2  ISR  nested  attributes  match  the  OS  configuration.
[SPMF92:02.0031]

© 2016 Vector Informatik GmbH
Version 1.10
45
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.16  Process to Core Mapping
Container “Process to Core Mapping” contains mapping information of all processes to the
available cores. The term “process” means the superset of Tasks and ISRs.

Example
Container “Process to Core Mapping” must look like:

14. Process to Core Mapping:
------------------------------------------------------------
Process-ID Process-Name Core-ID Core-Name Checked?
------------------------------------------------------------
0 (osSystemExtendedTask) 0 (Core0) [ ]
1 (TaskTrust) 0 (Core0) [ ]
2 (osSystemBasicTask) 0 (Core0) [ ]
3 (ISRNonTrust) 0 (Core0) [ ]
4 (osSystemCat2ISR) 0 (Core0) [ ]
------------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that the listed Task and ISR to core assignment matches the OS configuration.
In single core systems the core ID should be identical in all “to core” sub-containers.

Note
In single core systems the core ID should be identical in all “to-core” sub-containers.

© 2016 Vector Informatik GmbH
Version 1.10
46
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.17  Alarms to Core Mapping
Container “Alarms to Core Mapping” contains the mapping of Alarms to processor cores.

Example
Container “Alarms to Core Mapping” must look like:

15. Alarms to Core Mapping:
---------------------------------------------------------
Alarm-ID Alarm-Name Core-ID Core-Name Checked?
---------------------------------------------------------
0 (Alarm0) 0 (Core0) [ ]
1 (Alarm1) 0 (Core0) [ ]
2 (Alarm2) 0 (Core0) [ ]
3   (osSystemAlarm) 0 (Core0) [ ]
---------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that the listed Alarms to core assignment matches the OS configuration.

© 2016 Vector Informatik GmbH
Version 1.10
47
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.18  Resources to Core Mapping
Container “Resources to Core Mapping” contains the mapping of Resources to processor
cores.

Example
Container “Resources to Core Mapping” must look like:

16. Resources to Core Mapping:
---------------------------------------------------------------
Resource-ID Resource-Name Core-ID Core-Name Checked?
---------------------------------------------------------------
0 (RES_SCHEDULER) 0 (Core0) [ ]
1 (osSystemResource) 0 (Core0) [ ]
2 (resourceConf1) 0 (Core0) [ ]
---------------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that the listed Resources to core assignment matches the Resource usage.
All Tasks and ISRs, which use a Resource, shall belong to OS Applications, which
belong to the listed core.

© 2016 Vector Informatik GmbH
Version 1.10
48
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.19  Counters to Core Mapping
Container “Counters to Core Mapping” contains the mapping of Counters to processor
cores.

Example
Container “Counters to Core Mapping” must look like:

17. Counters to Core Mapping:
---------------------------------------------------------
Counter-ID Counter-Name Core-ID Core-Name Checked?
---------------------------------------------------------
0 (AddCount) 0 (Core0) [ ]
1 (osSystemSWCounter) 0 (Core0) [ ]
2 (SystemTimer)     0 (Core0) [ ]
---------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that the listed Counter to core assignment matches to the OS configuration.

© 2016 Vector Informatik GmbH
Version 1.10
49
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.20  Schedule Tables to Core Mapping
Container “Schedule Tables to Core Mapping” contains the mapping of Schedule Tables to
processor cores.

Example
Container “Schedule Tables to Core Mapping” must look like:

18. Schedule Tables to Core Mapping:
--------------------------------------------------------------------
ScheduleTable-ID ScheduleTable-Name Core-ID Core-Name Checked?
--------------------------------------------------------------------
0 (ScT1) 0 (Core0) [ ]
1 (ScT2) 0 (Core0) [ ]
2 (ScT3) 0 (Core0) [ ]
3 (ScT4) 0 (Core0) [ ]
4 (osSystemSchT) 0 (Core0) [ ]
--------------------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check  that  the  listed  Schedule  Tables  to  core  assignment  matches  the  OS
configuration.

© 2016 Vector Informatik GmbH
Version 1.10
50
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.21  Application to Core Mapping
Container “Applications to Core Mapping” contains the mapping of applications to
processor cores.

Example
Container “Applications to Core Mapping” must look like:

19. Applications to Core Mapping:
--------------------------------------------------------------------
Application-ID Application-Name Core-ID Core-Name Checked?
--------------------------------------------------------------------
0 (allAppl) 0 (Core0) [ ]
1 (osSystemApplicationCore0) 0    (Core0) [ ]
--------------------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that the listed Applications to core assignment matches the OS configuration.

© 2016 Vector Informatik GmbH
Version 1.10
51
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.22  Trusted Functions to Core Mapping
Container “Trusted Functions to Core Mapping” contains the mapping of Trusted Functions
to processor cores.

Example
Container “Trusted Functions to Core Mapping” must look like:

20. Trusted Functions to Core Mapping:
------------------------------------------------------------------
Function-ID Function-Name      Core-ID Core-Name Checked?
------------------------------------------------------------------
0       (TF1)       0 (Core0) [ ]
1    (TriggerISR1)      0 (Core0) [ ]
2    (osSystemTrustedFunction)   0 (Core0) [ ]
------------------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check  that  the  listed  Trusted  Functions  to  core  assignment  matches  the  OS
configuration.

© 2016 Vector Informatik GmbH
Version 1.10
52
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.23  Non-Trusted Functions to Core Mapping
Container “Non-trusted Functions to Core Mapping” contains the mapping of Non-Trusted
Functions to processor cores.

Example
Container “Non-Trusted Functions to Core Mapping” must look like:

21. Non-Trusted Functions to Core Mapping:
------------------------------------------------------
Function-ID Function-Name Core-ID Core-Name Checked?
------------------------------------------------------
0 (NTF1) 0 (Core0) [ ]
1 (NTF2) 0 (Core0) [ ]
2 (NTF3) 0 (Core0) [ ]
------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check  that  the  listed  Non-Trusted  Functions  to  core  assignment  matches  the  OS
configuration.

© 2016 Vector Informatik GmbH
Version 1.10
53
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.24  Core Control Block Address
Container “Core Control Block Start Address” contains the start address of the core
specific control block data structure.

Example
Container “Core Control Block Start Address" must look like:

22. Core Control Block Start Address:
------------------------------------------------
Core-ID Core-Name Control-Block-Address Checked?
------------------------------------------------
0 (Core0) 0xfedf135c [ ]
------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check  that  the  listed  Control  Block  Start  Address  matches  to  the  start  address  of
RAM data structure called osCtrlVarsCore0 (see linker map file).

© 2016 Vector Informatik GmbH
Version 1.10
54
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.25  Peripheral Regions Configuration
Container “Peripheral Regions Configuration” contains information about peripheral
regions configuration. [SPMF92:02.0030]

Example
Container “Peripheral Regions Configuration” must look like:

23. Peripheral Regions Configuration:
-------------------------------------------------------------------------------------
Region-ID Region-Name Start-Addr End-Addr Application-Name Application-ID Checked?
-------------------------------------------------------------------------------------
0 (IORegion0) 0xff030000 0xff03ffff (AppNT1) 0 [ ]
1 (IORegion1) 0xff080000 0xff080fff (AppNT1) 0 [ ]
2 (IORegion2) 0xffff0000 0xffff00ff (AppNT2) 1 [ ]
-------------------------------------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check  that  the  listed  peripheral  region  start  and  end  addresses  match  the  OS
configuration.
Check that the listed accessing application names match the OS configuration.

© 2016 Vector Informatik GmbH
Version 1.10
55
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.26  Spinlock Lock Method
Container “Spinlock Lock Method” contains information about how spinlocks prevent
interruption by ISRs and pre-emption by tasks with higher priority.
Possible settings are:
LOCK_ALL_INTERRUPTS
LOCK_CAT2_INTERRUPTS
LOCK_WITH_RES_SCHEDULER
LOCK_NOTHING
This container is always available but only relevant in multi core systems.

Example
Container “Spinlock Lock Method” must look like:

24. Spinlock Lock Method: N/A

8.27  Spinlock Config Type
Container “Spinlock Config Type” contains information whether the spinlock type is
standard AUTOSAR or optimized.
This container is always available but only relevant in multi core systems.

Example
Container “Spinlock Config Type” must look like:

25. Spinlock Config Type: N/A

8.28  Optimized Spinlock Variable Addresses
Container “Optimized Spinlock Variable Addresses” contains information about the variable
addresses of optimized spinlocks. Standard AUTOSAR spinlocks have no such address,
so there will be a NULL pointer for them.
This sub-container is always available but only relevant in multi core systems.
© 2016 Vector Informatik GmbH
Version 1.10
56
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual

Example
Container “Optimized Spinlock Variable Addresses” must look like:

26. Optimized Spinlock Variable Address: N/A

8.29  Category 2 ISR Stack Address
Container “Category 2 ISR Stack Address Area” contains the stack start and stack end
address of all category 2 ISR functions.

Example
Container “Category 2 ISR Stack Address Area” must look like:

27. Category 2 ISR Stack Addresses:
-------------------------------------------------------------
ISR-ID ISR-Name Start-Address End-Address Checked?
-------------------------------------------------------------
0 (ISRNonTrust) 0xfedf0400 0xfedf0800 [ ]
1 (ISRTrust) 0xfedf0800 0xfedf0A00 [ ]
2 (osSystemCat2ISR) 0x00000000 0x00000000 [ ]
-------------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that for each listed category 2 ISR the start and end address matches to the
stack  of  the  corresponding  interrupt  priority  level.  See  linker  map  file  for  symbols
_osIntStackLevel<PriorityLevel>_c<CoreID>

8.30  Category 2 ISR Interrupt Channel Index
Container “Category 2 ISR Interrupt Channel Index” contains the interrupt channel index of
all category 2 ISR functions.
© 2016 Vector Informatik GmbH
Version 1.10
57
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual

Example
Container “Category 2 ISR Interrupt Channel Index” must look like:

28. Category 2 ISR Interrupt Channel Index:
--------------------------------------------------
ISR-ID ISR-Name Channel-Index Checked?
--------------------------------------------------
0 (TestTimer1) 75 [ ]
1 (osOstmInterrupt_c0) 76 [ ]
2   (osSystemCat2ISR) 0 [ ]
--------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that for each listed category 2 ISR the interrupt channel index matches to the
OS configuration.

8.31  Category 2 ISR Priority Level
Container “Category 2 ISR Interrupt Priority Level” contains the priority level of all category
2 ISR functions.

Example
Container “Category 2 ISR Interrupt Priority Level” must look like:

29. Category 2 ISR Interrupt Priority Level:
---------------------------------------------
ISR-ID ISR-Name Priority Checked?
---------------------------------------------
0 (TestTimer1) 6 [ ]
1 (osOstmInterrupt_c0) 6      [ ]
2 (osSystemCat2ISR) 128 [ ]
---------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that for each listed category 2 ISR the interrupt priority level matches to the
OS configuration.
© 2016 Vector Informatik GmbH
Version 1.10
58
based on template version 2.0

MICROSAR OS SafeContext Safety Manual
Description of requirements to the OS user
Fulfilled
Note: The interrupt priority of system ISR osSystemCat2ISR is always 128.

© 2016 Vector Informatik GmbH
Version 1.10
59
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.32  Category 2 ISR to Core Mapping
Container “Category 2 ISR to Core Mapping” contains the mapping of category 2 ISRs to
processor cores. [SPMF92:02.0030]

Example
Container “Category 2 ISR to Core Mapping” must look like:

30. Category 2 ISR to Core Mapping:
------------------------------------------------------
ISR-ID ISR-Name Core-ID Core-Name Checked?
------------------------------------------------------
0 (TestTimer1) 0 (Core0) [ ]
1 (osOstmInterrupt_c0) 0 (Core0) [ ]
2 (osSystemCat2ISR) 0 (Core0) [ ]
------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that the listed category 2 ISR to core assignment matches the OS

configuration.

© 2016 Vector Informatik GmbH
Version 1.10
60
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.33  Application MPU Configuration
Container “Application MPU Configuration” contains the dynamic MPU region settings of all
applications. [SPMF92:02.0030]

Example
  Container “Application MPU configuration” must look like:
31. Application MPU configuration:
------------------------------------------------------------------------
Appl-ID Appl-Name Region Start-Addr End-Addr Checked?
------------------------------------------------------------------------
0 (APPL1) 1 0xfedf2000 0xfedf21ff [ ]
------------------------------------------------------------------------
1 (APPL2) 1 0xfedf2200 0xfedf23ff [ ]
------------------------------------------------------------------------
2 (APPL3) 1 0xfedf3000 0xfedf3fff [ ]
------------------------------------------------------------------------
3 (ApplStartVectCore0) 1 0x00000010 0x00000000 [ ]
------------------------------------------------------------------------
4 (TraceAppl) 1   0x00000010 0x00000000 [ ]
------------------------------------------------------------------------
5 (osSystemApplicationCore0) 1 0x00000010 0x00000000 [ ]
------------------------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Trusted  applications  must  always  have  Start-Addr  =  0x00000010  and  End-Addr  =
0x00000000.
Unused MPU regions in non-trusted applications must have Start-Addr = 0x00000010

and End-Addr = 0x00000000
Check that values of Start-Addr and End-Addr in row of non-trusted applications

matches the OS configuration.
Check that MPU regions of trusted applications have Start-Addr value smaller than the
End-Addr value.
Check that unused MPU regions of 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.
© 2016 Vector Informatik GmbH
Version 1.10
61
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.34  MPU Configuration
Container “MPU Configuration” contains the MPU regions settings [SPMF92:02.0030]. The OS
uses the settings to initialize the MPU during StartOS. Static regions stay unchanged after
StartOS. Stack region and dynamic regions are reprogrammed when context is switched.

Example
Container “MPU configuration” must look like:

32. MPU Configuration:
---------------------------------------------------------------------------------------
Region Start-Addr (MPLAn) End-Addr (MPUAn) Attributes (MPATn) Type Checked?
---------------------------------------------------------------------------------------
0 0xfedf0400 0xfedf058c 0x000000c3 (Stack Region) [ ]
---------------------------------------------------------------------------------------
1 0x00000010 0x00000000 0x000000c3 (Dynamic Region) [ ]
---------------------------------------------------------------------------------------
2 0x00000000 0xfffffffc 0x03ff00c5 (Static Region) [ ]
3 0xfedf0768 0xfedf07fc 0x03ff00c3 (Static Region) [ ]
---------------------------------------------------------------------------------------

The MPU configuration in ConfigBlock must be reviewed by the user: [SPMF92:04.0005]
Description of requirements to the OS user
Fulfilled
Check that the total number of Region matches the number of MPU regions which are
provided by the used CPU derivative.
Dynamic regions must have the following entries:

Start-Addr=0x00000010, End-Addr=0x00000000 and Attributes=0x000000c3.
Unused regions must have the following entries: Start-Addr=0x00000010, End-

Addr=0x00000000 and Attributes=0x00000000
Region 0 Start-Addr must match to the system stack start address.

Region 0 End-Addr must match to the system stack end address – 4 Bytes.

Region 0 entry Attributes must match 0x000000c3.

Check that the number of static regions matches the OS configuration.

Check each static region that Start-Addr and End-Addr match the OS configuration.

Check each static region that Start-Addr is lower than End-Addr.

Check each static region that Attributes access rights matches the OS configuration.

Check each static region that Attributes access rights contain the correct ASID.

Note
Default ASID value is 0x3ff if no ASID is configured.
  RH850 F1L does not support ASID due to hardware restrictions.

© 2016 Vector Informatik GmbH
Version 1.10
62
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
8.35  Application MPU ASID Configuration
Container “Application MPU ASID Configuration” contains the MPU ASID settings of all
applications.

Example
Container “Application MPU ASID configuration” must look like:

33. Application MPU ASID configuration:
---------------------------------------------------------
Application-ID Application-Name Value Checked?
---------------------------------------------------------
0 (APPL1) 0x0001 [ ]
1 (APPL2)      0x0002 [ ]
2 (APPL3) 0x0003 [ ]
3 (ApplStartVectCore0) 0x03ff [ ]
4 (TraceAppl) 0x03ff [ ]
5 (osSystemApplicationCore0) 0x03ff [ ]
---------------------------------------------------------

Description of requirements to the OS user
Fulfilled
Check that the listed ASID configuration matches the OS configuration.

All applications with ASID value 0x03ff must not have an ASID identifier configured.

Note
Default ASID value is 0x3ff if no ASID is configured.
  RH850 F1L does not support ASID due to hardware restrictions.

© 2016 Vector Informatik GmbH
Version 1.10
63
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
9
Generated OS 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 MSSV [4].
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
Using MICROSAR Safe Silence Verifier (MSSV)
The following chapter tells how you shall apply MSSV.exe on the OS sources.
MSSV.exe is called with the following parameters:
MSSV.exe -i <SourcePath> -i <GenPath> -i <HeaderPath> -D osdNOASM

Parameters
Description
-i <SourcePath>
This parameter is multiple used:
At least path of OS source files (e.g. osek.c), path of generated OS
files (e.g. tcb.c) and path of additional header files (e.g. Std_Types.h)
must be specified.
-r <ReportFile>
Optional: Path and name which shall be used to save the MSSV report.
If not used then the results will be saved in file report.html
-D osdNOASM
Disable OS assembler code parts. Mandatory for OS.
Parameter -D can be multiple used.
--help
Show help

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.

© 2016 Vector Informatik GmbH
Version 1.10
64
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
Description of requirements to the OS user
Fulfilled
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]

Example

An example for qualifying generated OS sources:

MSSV.exe -i .\BSW\OS -i .\TestAppl -i .\TestAppl\Gen -D osdNOASM

The output of MSSV.exe must look like:

note: MICROSAR Safe Silence Verifier Version 1.04.00
note: Copyright (C) 2012-2015 Vector Informatik GmbH
note: License <CBD1600111> Vector Informatik GmbH
note: mssv.exe started at 12:01:28 2016-01-21
note: scanning plugin directory '... \MSSV\plugins'
note: scanning input directory '... \BSW\OS'
note: scanning input directory '... \TestAppl'
note: scanning input directory '... \TestAppl\Gen'
note: found 29 source code files, 57 header files and 3 include directories
note: module plugin 'Tcb' successfully initialized
note: starting execution of plugin 'Tcb'
note: plugin 'Tcb' executed 57 rules (84 assertions held, 0 assertions did
not hold)
note: Log file written to 'stdout'
note: Report file written to 'report.invalid'
note: On success report file will be renamed to 'report.html'
note: mssv.exe finished at 12:01:28 2016-01-21
note: 0 Errors
note: 0 Warnings
note: the final verdict of the report is 'pass'

© 2016 Vector Informatik GmbH
Version 1.10
65
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual

9.2
Manual Reviews
Some generated code parts currently cannot be checked automatically. Therefore the user
has to check them manually.

9.2.1  Review generated file tcb.h
Description of requirements to the OS user
Fulfilled
1.  You shall review the system level definition osdSystemLevel to be the

maximum of all category 2 ISR priorities and check mask definition
osdSystemLevelMask to be the corresponding value, which has to be
stored in PMR register to mask (i.e. disable) all category 2 interrupts.
[SPMF92:02.0019] [SPMF92:04.0017]  [SPMF92:02.0032] [SPMF92:02.0033]
[SPMF92:0059] [SPMF92:0060]
#define osdSystemLevel <MAXIMUM_OF_ALL_CAT2_ISR_PRIORITIES>
#define osdSystemLevelMask <PMR_VALUE_MASK_ALL_CAT2_ISR>

2.  Check that osdExceptionDetails is defined = 1

#define osdExceptionDetails 1

© 2016 Vector Informatik GmbH
Version 1.10
66
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
9.2.2
Review of tcb.c
The function osSTWorkActions() is used for handling Expiry Points. It calls OS internal
functions to perform the configured actions at the configured Expiry Points. This function is
generated, therefore the user has to review that safety requirements are fulfilled.

Example
The function osSTWorkActions() may look like:

osqFunc1 osSTReactionType osqFunc2 osSTWorkActions(GlobalTimeTickType* diff,
osSTIndexType CurrentEP)
{
switch (CurrentEP)
{
  case 0: /* SchedT1 */
(void)osSysActivateTask(TaskBasic);
*diff= 250; /* no sync for this schedule table / this expiry point */
return osdSTReact_Continue;
  case 1: /* SchedT1 */
(void)osSysSetEvent(TaskExt,evTaskExt);
*diff= 150; /* no sync for this schedule table / this expiry point */
return osdSTReact_Continue;
…
  case 15: /* osSystemSchT */
(void)osSysSetEvent(osSystemExtendedTask,osSystemEvent);
*diff=0;
return osdSTReact_Stop;
  /* MISRA RULE 14.1 VIOLATION: return is not
* reachable but this is the only way for prevent a compiler warning (3201)
*/
  default:
osSysErrAssertFailed(osdErrWSUnknownAction)
return osdSTReact_Stop; /* PRQA S 3201 */
}
}

Description of requirements to the OS user
Fulfilled
Check that osSTWorkActions() is only called by osWorkScheduleTable() in

atostime.c and nowhere else.
Check for all osSysActivateTask() calls pass valid Task names

© 2016 Vector Informatik GmbH
Version 1.10
67
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
Description of requirements to the OS user
Fulfilled
User has to review that the parameter of each call of osSysActivateTask in tcb.c is a
valid task identifier (define in tcbpost.h). [SPMF92:05.0009]

Check for all osSysSetEvent() calls pass valid Task and Event names

The user has to review that the first parameter of all calls of osSysSetEvent in
tcb.c is a valid task identifier (define in tcbpost.h) and that the value of the
define is smaller than osdNumberOfExtendedTasks.
[SPMF92:05.0006]
Check that the array oskAlarmCounterRef[] contains osdNumberOfAlarms

elements and that each element contains the index of the counter related to that
alarm.
Check that the array oskAlarmTask[] contains valid task ID values (Task ID of

either the activated task or the Task ID of the task which receives an event).
Check that oskResCeilingPrio[] contains priorities smaller than

oskNumberOfPriorities[<Core ID of the Core to which the
resource is assigned>]
Check the size of all osQTaskActivation_<Prio Index> arrays

The size must be the value of
oskQMaxActivations[Prio Index] + 1
[SPMF92:05.0012]
Check that the array “oskAlarmHeaps” has the size of “osdNumberOfCounters”
[SPMF92:05.0002]
Check that all elements of one entry in “oskAlarmHeaps” are related to the same

counter
{
os<Counter Name>Heap,
&osAlarmHeapCount[<Counter Name>]
},
[SPMF92:05.0002]
Check for the correct ordering of the entries in “oskAlarmHeaps”. Correct ordering
means that the first entry must be related to the counter which is defined to zero (in
tcbpost.h). The second entry must be related to the counter which is defined to
one etc.
[SPMF92:05.0002]
Check for the correct size of the Heap arrays.

The size of such an array “os<Counter Name>Heap” must be
Number of alarms related to counter  <Counter Name> + Number of Scheduletables
related to <Counter Name> + 1
[SPMF92:05.0005]

© 2016 Vector Informatik GmbH
Version 1.10
68
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual

9.2.3  Review of tcbpost.h
Description of requirements to the user
Fulfilled
Check that the Alarm names are mapped onto adjoining numbers. Starting with zero
to osdNumberOfAlarms – 1
(osdNumberOfAlarms is defined in tcb.h) [SPMF92:05.0013]

Example
/* Alarms */
  #define CrossCoreATAlarm ((AlarmType)0)
#define osSystemAlarm ((AlarmType)1)
#define My10msAlarm ((AlarmType)2)

Check that the Counter names are mapped onto adjoining numbers. Starting with

zero to osdNumberOfCounters – 1
(osdNumberOfCounters is defined in tcb.h) [SPMF92:05.0003]

Example
/* Counter */

#define osSystemSWCounter ((CounterType) 0)
#define SystemTimerCore0 ((CounterType) 1)
#define OtherCounter ((CounterType) 2)

Check that the task names are mapped onto adjoining numbers starting from zero to
osdNumberOfAllTasks – 1
(osdNumberOfAllTasks is defined in tcb.h) [SPMF92:05.0010]

Example
/* Tasks */
  #define Task2Core1 ((TaskType)0)
#define osSystemExtendedTask ((TaskType)1)
#define Task1Core1 ((TaskType)2)
#define Task1Core0 ((TaskType)3)
#define IdleTaskCore1 ((TaskType)4)
#define IdleTaskCore0 ((TaskType)5)
#define osSystemBasicTask ((TaskType)6)

© 2016 Vector Informatik GmbH
Version 1.10
69
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
Check that the category 2 ISR names are mapped onto adjoining numbers starting

from zero to osdNumberOfCat2ISRs – 1
(osdNumberOfCat2ISRs is defined in tcb.h) [SPMF92:05.0015]

Example
/* ISR IDs */
  #define SystemTimerISR_Core0 ((ISRType)0)
#define osIOCNotificationISRCore0 ((ISRType)1)
#define osIOCNotificationISRCore1 ((ISRType)2)
#define osIOCNotificationISRCore2 ((ISRType)3)
#define osShutdownRequestISRCore0 ((ISRType)4)
#define osShutdownRequestISRCore1 ((ISRType)5)
#define osShutdownRequestISRCore2 ((ISRType)6)
#define osSystemCat2ISR ((ISRType)7)

Check that the Schedule Table names are mapped onto adjoining numbers. Starting
with zero to osdNumberOfScheduleTables – 1
(osdNumberOfScheduleTables is defined in tcb.h)

Example
/* Schedule Tables */

#define Scheduletable1 ((ScheduleTableType) 0)
#define Scheduletable2 ((ScheduleTableType) 1)
#define osSystemSchT ((ScheduleTableType) 2)

Check that the values of osr(NumberOf)<OS Object> are defined to

osd(NumberOf)<OS Object>

Example
#define osrRTSize osdRTSize
  #define osrNumberOfPriorities osdNumberOfPriorities
#define osrNumberOfAppModes osdNumberOfAppModes
#define osrNumberOfAllTasks osdNumberOfAllTasks
#define osrNumberOfAllResources osdNumberOfAllResources
.
.
.
#define osrSystemTimer SystemTimer
#define osrNumberOfCounters osdNumberOfCounters

© 2016 Vector Informatik GmbH
Version 1.10
70
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual

9.2.4  Review of trustfct.c & trustfct.h
The following review checks are only relevant for trusted functions that  belong to an OS-
application which has the parameter GenerateStub set to TRUE.
The  OS  provides  the  possibility  to  use  generated  stub  functions  for  the  call  of  trusted
functions. These stubs are generated into the following files:
>  trustfct.c
>  trustfct.h
Both  files  are  generated  on  QM  level  but  executed  in  supervisor-mode.  Therefore  the
generated code shall be reviewed.
If stubs are generated for a trusted function, there are two parts: the Caller stub and the
Callee-stub.  The  Caller-stub  is  a  function  which  packs  the  parameters  which  shall  be
passed  to  the  trusted  function  into  a  C-struct  and  calls  the  API  function
CallTrustedFunction.  The  Callee-stub  unpacks  the  parameters  from  the  struct  and
passes them to the users trusted function.

9.2.4.1  File trustfct.c
Review the file trustfct.c according the following review criteria.
Description of requirements to the OS user
Fulfilled
The name of the trusted function caller function body shall be

Call_<TrustedFunctionName>

If second parameter of API function CallTrustedFunction is &<ParamName>

then the following local variable shall exist:
TrustedFunctionParameterType <ParamName>;

Check that the API function CallTrustedFunction only uses a reference to this

local variable.
The first parameter shall be:

osd_TFCT_<TrustedFunctionName>

If the trusted function has no arguments, then the second parameter shall be:

(TrustedFunctionParameterRefType)0

If the trusted function has arguments, then the second parameter shall be:

&<ParamName>

Callee-stubs shall have the following function prototype:

void TRUSTED_<TrustedFunctionName>( TrustedFunctionIndexType
FunctionIndex, TrustedFunctionParameterRefType
FunctionParams );

Callee-stubs shall not modify any ASIL data.

© 2016 Vector Informatik GmbH
Version 1.10
71
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
Description of requirements to the OS user
Fulfilled
Callee-stubs shall not call any function other than the specific trusted function.

Callee-stubs shall not consume more stack space than available.

Trusted functions which have arguments shall be called with following parameter

notation syntax:
((TrustedFunctionParameterType*)FunctionParams) ->
<TrustedFunctionName>_args.os_arg_<MemberName>

Example
The following trusted function configuration:

TRUSTED_FUNCTION = TRUE {
NAME = "StartTestStep";
Params = "osuint8 p";
ReturnType = "void";
};
Leads to the following code in trustfct.c:
...
void Call_StartTestStep(osuint8 os_arg_p)
{
TrustedFunctionParameterType myargs;

myargs.StartTestStep_args. os_arg_p = os_arg_p;
(void) CallTrustedFunction(osd_TFCT_StartTestStep, &myargs);
}
...
void TRUSTED_StartTestStep(TrustedFunctionIndexType FunctionIndex,
TrustedFunctionParameterRefType FunctionParams) /* PRQA S 1505, 3673 */
{
/* osdDummyRead might intentionally assign a value to an unused variable
on some platforms to avoid compiler warnings. This is no MISRA error. (3199)
*/
osdDummyRead(FunctionIndex) /* PRQA S 3199 */
StartTestStep(((TrustedFunctionParameterType*)FunctionParams)-
>StartTestStep_args. os_arg_p);
}

© 2016 Vector Informatik GmbH
Version 1.10
72
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual

9.2.4.2  File trustfct.h
Review the file trustfct.h according the following rules:
Description of requirements to the OS user
Fulfilled
Each trusted function shall have an index definition with following notation syntax:

>  If configuration attribute is “GenerateStub=FALSE“:
  #define <TrustedFunctionName> <TrustedFunctionIndex>
>  If configuration attribute is “GenerateStub=TRUE“:
  #define osd_TFCT_<TrustedFunctionName> <TrustedFunctionIndex>

The mapping of trusted function names to indexes shall be consistent to the

mapping of trusted function start addresses to indexes as printed in the
configuration block output. [SPMF92:0048]
Each trusted function stub which uses function arguments shall have its specific C-

struct type definition osTFArgType_<TrustedFunctionName>
This C-struct shall contain all arguments which are used by the specific trusted

function.
Check that the following union type definition is generated and check that each

trusted function which uses function arguments is listed in this union type definition.
typedef union
{
  osTFArgType_<TrustedFuncName1> <TrustedFuncName1>_args;
  osTFArgType_<TrustedFuncName2> <TrustedFuncName2>_args;
  osTFArgType_<TrustedFuncName3> <TrustedFuncName3>_args;
  ...
} TrustedFunctionParameterType;

© 2016 Vector Informatik GmbH
Version 1.10
73
based on template version 2.0

MICROSAR OS SafeContext Safety Manual

Example
The following trusted function configuration:

TRUSTED_FUNCTION = TRUE {
NAME = "StartTestStep";
Params = "osuint8 p";
ReturnType = "void";
};
Leads to the following code in trustfct.h:
#define osd_TFCT_StartTestStep 1
void TRUSTED_StartTestStep(TrustedFunctionIndexType FunctionIndex,
TrustedFunctionParameterRefType FunctionParams);
void Call_StartTestStep(osuint8 os_arg_p);

typedef struct
{
osuint8 os_arg_p;
} osTFArgType_StartTestStep;

© 2016 Vector Informatik GmbH
Version 1.10
74
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
10
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]
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 API service
functions.
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.
© 2016 Vector Informatik GmbH
Version 1.10
75
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
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.
© 2016 Vector Informatik GmbH
Version 1.10
76
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
Description of requirements to the OS user
Fulfilled
No APIs in NMIs

Non-maskable interrupts shall not use any OS APIs. [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.
Functions osDisable/EnableLevelKM and osDisable/EnableGlobalKM

Functions osDisableLevelKM, osEnableLevelKM, osDisableGlobalKM and
osEnableGlobalKM  shall only be called by trusted applications, i.e. when
CPU is in privileged mode. [SPMF92:0094]
Functions osEnableLevelKM, osEnableLevelUM, osEnableLevelAM

Assure that these functions are only called if the interrupt level was equal to
the task level at the matching disable function (especially: not called in ISR!)
Mind that the level functions may use the global flag, if disabling on level is
not supported for a specific hardware. [SPMF92:0095]
Functions osEnableGlobalKM, osEnableGlobalUM, osEnableGlobalAM

Assure that these functions are only called if interrupts were enabled by
means of the global flag at the matching disable function (especially: not
called in ISR with EnableNesting=FALSE) Mind that the global interrupt API
functions may use the interrupt level in case no global disabling is supported
on a specific hardware or if timing protection is active. [SPMF92:0096]
Functions osEnableLevelKM, osEnableLevelUM, osEnableLevelAM and

functions osEnableGlobalKM, osEnableGlobalUM, osEnableGlobalAM
Assure that these functions are not called in a nested way, even if they seem
to use different locking mechanisms. [SPMF92:0097]
Header file osek.h

This header file is included into the OS almost everywhere. Make sure that
you do not manipulate the OS in an unforeseen way. [SPMF92:0098]
Timing Hooks

Assure that hook functions do not violate safety goals especially do not
manipulate safety relevant data, the interrupt state and do not cause stack
overflow (prevention of stack overflow may be unnecessary if the hardware
allows to keep the MPU active in privileged mode) (interrupt disabling by
means of the global flag and restauration its's state before returning to the
caller shall be explicitly allowed if no OS API functions are used for that).
[SPMF92:0099]
Timing Hooks Parameters

Assure that parameters of the hook routines are not used to reference a
memory location to write to without a check for validity. (Mind that the invalid
values are usually big numbers). [SPMF92:0100]
© 2016 Vector Informatik GmbH
Version 1.10
77
based on template version 2.0

MICROSAR OS SafeContext Safety Manual
Description of requirements to the OS user
Fulfilled
Timing Hooks

The OS does not guarantee the call of the hook routines on ASIL level. There
is no safety requirement which assures that the hooks are correctly called (at
correct time, in correct context etc.). [SPMF92:0101]
Timing Hooks

Calling OS API functions in OS_VTH* hooks is not allowed. [SPMF92:0102]
Timing Hooks

Usage of OS variables in OS_VTH* hooks is dangerous as they may not be
consistent. [SPMF92:0103]
Timing Hooks

Mind that the CAT1 ISRs may interrupt the hook routines which may cause
concurrent calls. [SPMF92:0104]
© 2016 Vector Informatik GmbH
Version 1.10
78
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
11
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 compiler 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:04.0003]
  The user has to review that all task stacks, all ISR stacks and the system stack have 4 Byte
alignments [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 11.3.
  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.
© 2016 Vector Informatik GmbH
Version 1.10
79
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
  The user has to consider DMA controller usage if the used RH850 derivative 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.
  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:0070].
  The user has to review that all generated files belong together and that all generated files
are compiled and linked [SPMF92:0064]. The user shall not change any generated header
file (*.h) or source file (*.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
-  GetApplicationState
-  GetEvent
-  GetAlarm
-  GetScheduleTableStatus
-  GetCounterValue
-  GetElapsedValue
-  GetElapsedCounterValue
  The user has to assure that symbol _osStartupStack_StartAddr is provided in linker file and
points to the startup stack [SPMF92:05.0004].
  User  has  to  review  that  osdTimerInterruptSourceNumberCore0  in  generated  file  tcb.h  is
equal to channel index of timer unit OSTM0 [SPMF92:05.0007].
  User  has  to  review  in  generated  file  tcb.c  the  content  of  arrays  "oskGetCurrentTimeOps"
and "oskCounterId2GetCurrentTimeOpIdx" [SPMF92:05.0016].
  User  has  to  review  in  generated  file  tcb.c  the  arrays  "oskInsertMinHeapOps"  and
"oskCounterId2InsertMinHeapOpIdx" [SPMF92:05.0017].
  The  user  has  to check that  the  application  does  not modify  CPU  core  register  PMR  after
StartOS is called [SPMF92:04.0018].
  If  High  Resolution  Timer  is  used  as  SystemTimer  then  the  user  has  to  review  that  the
following  defines  exists  in  tcbpost.h  and  that  HiResSystemTimer  is  defined  smaller  than
osdNumberOfCounters [SPMF92:05.0018]:
#define HiResSystemTimer             <x>
#define osdTimerOSTM_HIRESID  HiResSystemTimer

© 2016 Vector Informatik GmbH
Version 1.10
80
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
  If  Standard Timer  is  used  as  SystemTimer  then  the  user  has  to  review  that  the  following
defines  exists  in  tcbpost.h  and  that  SystemTimer  is  defined  smaller  than
osdNumberOfCounters [SPMF92:05.0019]:
#define SystemTimer       <x>
#define osdTimerOSTM   SystemTimer
  The  user  has  to  review  in  the  generated  file  tcb.c  that  the  size  of  the  array
oskAlarmHeapSize is equal to osdNumberOfCounters. Furthermore, the user has to review
that each entry must be equal to 1 + the number of alarms that are related to the counter
<CounterName>  +  the  number  of  schedule  tables  that  are  related  to  the  counter
<CounterName>. The counter osSystemSWCounter is the only exception to this rule. This
counter must always exist and the related array element must be one.

© 2016 Vector Informatik GmbH
Version 1.10
81
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
11.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<CoreID>.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<CoreID>.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.

11.1.1 Header Include Section
Generated file intvect_c<CoreID>.c starts exactly with the following lines:

#if defined USE_QUOTE_INCLUDES
#include "vrm.h"
#else
#include <vrm.h>
#endif

#define osdVrmGenMajRelNum 1
#define osdVrmGenMinRelNum 6
#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

#ifndef osdNOASM

© 2016 Vector Informatik GmbH
Version 1.10
82
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
11.1.2 Core Exception Vector Table
The core exception vector table section looks exactly like the following lines:
#pragma asm

.section ".osExceptionVectorTable_c0", "ax"
.align 512

.globl _osExceptionVectorTable_c0
_osExceptionVectorTable_c0:

.offset 0x0000
.globl  _osCoreException_c0_0x0000
_osCoreException_c0_0x0000:
jr <interrupt_handler_0>

.offset 0x0010
.globl _osCoreException_c0_0x0010
_osCoreException_c0_0x0010:
jr <interrupt_handler_1>

.offset 0x0020
.globl _osCoreException_c0_0x0020
_osCoreException_c0_0x0020:
jr <interrupt_handler_2>

...

.offset 0x01F0
.globl _osCoreException_c0_0x01F0
_osCoreException_c0_0x01F0:
jr <interrupt_handler_23>

.globl _osExceptionVectorTableEnd_c0
_osExceptionVectorTableEnd_c0:

#pragma endasm

The sequence of core exception vector table entries starts at vector address 0x0000, increases in
steps of 0x0010 and ends with vector address 0x01F0.
<interrupt_handler_x> is the name of the handler which is called when an exception occurs.
If no specific handler is configured then osUnhandledCoreException is called:
example for unused interrupt source
.offset 0x0010
.globl _osCoreException_c0_0x0010
_osCoreException_c0_0x0010:
jr  _osUnhandledCoreException

© 2016 Vector Informatik GmbH
Version 1.10
83
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
11.1.3 EIINT Vector Table
The EIINT vector table section starts exactly with the following lines:
#pragma asm

.section ".osEIINTVectorTable_c0", "ax"
.align 512

.globl _osEIINTVectorTable_c0
_osEIINTVectorTable_c0:

.word _<EIINT_handler_0>
.word _<EIINT_handler_1>
.word _<EIINT_handler_2>
...
.word _<EIINT_handler_x>

For each unused interrupt source the following table entry must be generated:
.word  _osUnhandledEIINTException

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_ISR_Name>_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 _osEIINTVectorTableEnd_c0
_osEIINTVectorTableEnd_c0:

#pragma endasm

© 2016 Vector Informatik GmbH
Version 1.10
84
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
11.1.4 CAT2 ISR Wrappers
The category 2 ISR wrapper section looks exactly like the following lines:
#pragma asm

.section ".os_text", "ax"

osCAT2ISRC0(...)

osCAT2ISRC0(...)

osCAT2ISRC0(...)

...

osCAT2ISRC0(...)

#pragma endasm

Each category 2 ISR handler must be generated exactly like the following line [SPMF92:0044]:
osCAT2ISRC0(<Cat2_ISR_Name>, <Cat2_ISR_Priority)

Macro osCAT2ISRC0() is defined in osekext.h.
It defines the CAT2 ISR prologue for each interrupt source which is used as category 2 ISR.
<Cat2_ISR_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:
.word _<Cat2_ISR_Name>_CAT2

<Cat2_ISR_Priority>  is  the  value  of  the  interrupt  priority  level  which  is  configured  for  the
corresponding ISR. The valid range of <Cat2_ISR_Priority> is 0 ... 7

11.1.5 End of file Intvect_c<CoreID>.c
Generated file intvect_c<CoreID>.c ends exactly with the following line:
#endif /* ifndef osdNOASM */

© 2016 Vector Informatik GmbH
Version 1.10
85
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
11.2  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_c<CoreID>  Contains the core exception vector table. It is generated
section type .text
into file intvect_c<CoreID>.c
.osEIINTVectorTable_c<CoreID>
Contains the EIINT exception vector table. It is generated
section type .text
into file intvect_c<CoreID>.c
.os_text
Contains the interrupt handler for category 2 ISRs. It is
section type .text
generated into file intvect_c<CoreID>.c
Must be linked to program code section.
.os_text
Contains all OS program code, except those which must
section type .text
be 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
section type .rodata
be 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
section type .rosdata
area, 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
section type .rosdata
enabled
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
section type .data
copied 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
section type .sbss
SDA 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
section type .sdata
area if SDA optimization is enabled.
Must be linked to the SDA section. This section must be
empty!
© 2016 Vector Informatik GmbH
Version 1.10
86
based on template version 2.0

MICROSAR OS SafeContext Safety Manual
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_c<CoreID>
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.

© 2016 Vector Informatik GmbH
Version 1.10
87
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
11.3  Linker Include Files
The generated linker include files shall be reviewed if they are used for serial production.

11.3.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) :>.

© 2016 Vector Informatik GmbH
Version 1.10
88
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
11.3.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;

© 2016 Vector Informatik GmbH
Version 1.10
89
based on template version 2.0

MICROSAR OS SafeContext Safety Manual
11.3.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

© 2016 Vector Informatik GmbH
Version 1.10
90
based on template version 2.0

MICROSAR OS SafeContext Safety Manual
11.3.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) :>.

11.3.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) :>.

© 2016 Vector Informatik GmbH
Version 1.10
91
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
11.4  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].
© 2016 Vector Informatik GmbH
Version 1.10
92
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
11.5  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.
On  derivatives  with  MPU  inactive  in  privileged  mode  all  OS  API  functions  are  executed  on  the
stack of caller without memory protection. [SPMF92:04.0020{!MPUPRIVMODE}]

11.6  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.

11.7  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].

© 2016 Vector Informatik GmbH
Version 1.10
93
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
12
Glossary and Abbreviations
12.1  Glossary
Term
Description
OS-Application
An OS-Application is a set of tasks, ISRs and (Non-)Trusted Functions
with common peripheral/memory access rights and executing in the same
privilege mode.
Trusted software
Trusted application code is code which is executed with supervisor
privileges. The user has to ensure that this code does not interfere with
other components. Examples are start-up code, global Hook functions,
Tasks and ISRs which are configured to be part of a trusted OS
Application.
Non-trusted software  Defined by AUTOSAR specification: Part of a non-trusted application.
Non-trusted software is running with memory protection enabled and in
non-privileged mode. Therefore non-trusted software might be
implemented on QM level but ASIL software which does not need
unlimited memory access or privileged access can also be configured as
non-trusted.
Privileged mode
CPU mode with unlimited access to CPU system registers. Software
running in privileged mode is e.g. able to reconfigure the MPU and to
enable or disable interrupts. Therefore software running in privileged
mode must be implemented on ASIL level.
Non-privileged mode  CPU mode without or with limited access to CPU system registers.
Software running in privileged mode is not able to reconfigure the MPU or
to enable or disable interrupts. Therefore software running in privileged
mode might be implemented on QM level.
Silent principle
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.
Table 12-1   Glossary

© 2016 Vector Informatik GmbH
Version 1.10
94
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual

12.2  Abbreviations
Abbreviation
Description
API
Application Programming Interface
ASIL
Automotive Safety Integrity Level
AUTOSAR
Automotive Open System Architecture
BSW
Basis Software
CRC
Cyclic Redundancy Check
ECU
Electronic Control Unit
IRQ
Interrupt Request
ISR
Interrupt Service Routine
MICROSAR
Microcontroller Open System Architecture (the Vector AUTOSAR
solution)
MPU
Memory Protection Unit (realized in hardware by the processor)
MSSV
MICROSAR Safe Silence Verifier
ORTI
OSEK Run Time Interface
OS
Operating System
QM
Quality Management (used for software parts developed following only a
standard quality management process)
SC
Scalability Class (of AUTOSAR OS)
SEooC
Safety Element out of Context: a safety-related element which is not
developed for a specific item
Table 12-2   Abbreviations

© 2016 Vector Informatik GmbH
Version 1.10
95
based on template version 2.0

MICROSAR OS SafeContext  Safety Manual
13
Contact
Visit our website for more information on

>  News
>  Products
>  Demo software
>  Support
>  Training data
>  Addresses
www.vector.com

For support requests and issue notifications write to osek-support@vector.com

© 2016 Vector Informatik GmbH
Version 1.10
96
based on template version 2.0

Document Outline

4 - Os Integration Manual

Integration Manual

For

VERSION: 1

DATE: 01/08/16

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA

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

Revision History

Sl. No.	Description	Author	Version	Date
1	Initial version	Lucas Wendling	1.0	01/08/16

Table of Contents

1 Abbrevations And Acronyms 4

2 References 5

3 Dependencies 6

3.1 SWCs 6

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

4 Configuration REQUIREMeNTS 7

4.1 Build Time Config 7

4.2 Configuration Files to be provided by Integration Project 7

4.3 Da Vinci Parameter Configuration Changes 7

4.4 DaVinci Interrupt Configuration Changes 7

4.5 Manual Configuration Changes 7

5 Integration DATAFLOW REQUIREMENTS 8

5.1 Required Global Data Inputs 8

5.2 Required Global Data Outputs 8

5.3 Specific Include Path present 8

6 Runnable Scheduling 9

7 Memory Map REQUIREMENTS 10

7.1 Mapping 10

7.2 Usage 10

7.3 Non RTE NvM Blocks 10

7.4 RTE NvM Blocks 10

8 Compiler Settings 11

8.1 Preprocessor MACRO 11

8.2 Optimization Settings 11

9 Appendix 12

Abbrevations And Acronyms

Abbreviation	Description

References

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

Sr. No.	Title	Version

Dependencies

SWCs

Module	Required Feature

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

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

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

void NxtrOsErrHndlg(StatusType Error)

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

Configuration REQUIREMeNTS

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

Build Time Config

Modules	Notes

Configuration Files to be provided by Integration Project

N/A

Da Vinci Parameter Configuration Changes

Parameter	Notes	SWC

DaVinci Interrupt Configuration Changes

ISR Name	Notes

Manual Configuration Changes

Constant	Notes	SWC

Integration DATAFLOW REQUIREMENTS

Required Global Data Inputs

Required Global Data Outputs

Specific Include Path present

Yes

Runnable Scheduling

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

Init	Scheduling Requirements	Trigger

Runnable	Scheduling Requirements	Trigger
NxtrOsErrHndlg	See section 3.2	Os Error and Protection Hooks

Memory Map REQUIREMENTS

Mapping

Memory Section	Contents	Notes

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

Usage

Feature	RAM	ROM

NvM Blocks

Compiler Settings

Preprocessor MACRO

Optimization Settings

Appendix

<This section is for appendix>

5 - Os Module Design Document

Module Design Document

For

1/6/16

Prepared For:

Software Engineering

Nexteer Automotive,

Saginaw, MI, USA

Prepared By:

Software Group,

Nexteer Automotive,

Saginaw, MI, USA
Change History

Description	Author	Version	Date
Initial Version	Lucas Wendling	1	1/6/16

Table of Contents

1 Introduction 5

1.1 Purpose 5

1.2 Scope 5

2 Os & High-Level Description 6

3 Design details of software module 7

3.1 Graphical representation of Os 7

3.2 Data Flow Diagram 7

3.2.1 Component level DFD 7

3.2.2 Function level DFD 7

4 Constant Data Dictionary 8

4.1 Program (fixed) Constants 8

4.1.1 Embedded Constants 8

5 Software Component Implementation 9

5.1 Sub-Module Functions 9

5.1.1 Init: Os_Init<n> 9

5.1.1.1 Design Rationale 9

5.1.1.2 Module Outputs 9

5.1.2 Per: Os_Per<n> 9

5.1.2.1 Design Rationale 9

5.1.2.2 Store Module Inputs to Local copies 9

5.1.2.3 (Processing of function)……… 9

5.1.2.4 Store Local copy of outputs into Module Outputs 9

5.2 Server Runables 9

5.2.1 <Server Runable Name> 9

5.2.1.1 Design Rationale 9

5.2.1.2 (Processing of function)……… 10

5.3 Interrupt Functions 10

5.3.1 Interrupt Function Name 10

5.3.1.1 Design Rationale 10

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

5.4 Module Internal (Local) Functions 10

5.4.1 Local Function #1 10

5.4.1.1 Design Rationale 10

5.4.1.2 Processing 10

5.5 GLOBAL Function/Macro Definitions 10

5.5.1 GLOBAL Function #1 10

5.5.1.1 Design Rationale 11

5.5.1.2 processing 11

6 Known Limitations with Design 12

7 UNIT TEST CONSIDERATION 13

Appendix A Abbreviations and Acronyms 14

Appendix B Glossary 15

Appendix C References 16

Introduction

Purpose

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

Scope

The following definitions are used throughout this document:

Shall: indicates a mandatory requirement without exception in compliance.
Should: indicates a mandatory requirement; exceptions allowed only with documented justification.
May: indicates an optional action.

High-Level Description

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

Design details of software module

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

Graphical representation of NxtrOsErrHndlg (Expected External Intefaces)

Data Flow Diagram

Component level DFD

Function level DFD

Constant Data Dictionary

Program (fixed) Constants

Embedded Constants

Local Constants

Constant Name	Resolution	Units	Value
None

Software Component Implementation

Sub-Module Functions

Init:

None

Per:

None

Server Runables

NxtrOsErrHndlg

Design Rationale

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

Processing

switch (OSErrorGetosCANError())

case osdErrUEUnhandledException:

case osdErrUEUnhandledCoreException:

case osdErrUEUnhandledDirectBranch:

/* Unhandled Exceptions */

ProcUkwnExcpnErr(OSErrorGetosCANError())

break

case osdErrEXMemoryViolation:

/* MPU Violations */

ProcMpuExcpnErr(OSErrorGetosCANError());

break

case osdErrEXPrivilegedInstruction:

/* Privileged Instruction Exceptions */

ProcPrvlgdInstrExcpnErr(OSErrorGetosCANError());

break

case osdErrATWrongTaskPrio:

case osdErrTTNotActivated:

case osdErrTTNoImmediateTaskSwitch:

case osdErrTTWrongActiveTaskID:

case osdErrHTNotActivated:

case osdErrHTNoImmediateTaskSwitch:

case osdErrHTWrongActiveTaskID:

case osdErrSHScheduleNotAllowed:

case osdErrSHWrongActiveTaskID:

case osdErrGSOddInvocation:

case osdErrGIOddInvocation:

case osdErrMTMissingTerminateTask:

case osdErrEAIntAPIWrongSequence:

case osdErrDAIntAPIDisabled:

case osdErrSDWrongCounter:

case osdErrREWrongCounter:

case osdErrSGWrongCounter:

case osdErrRGWrongCounter:

case osdErrGRPriorityOccupied:

case osdErrGRNoAccessRights:

case osdErrGRWrongTaskID:

case osdErrRRCeilingPriorityNotSet:

case osdErrRRWrongTask:

case osdErrRRNoReadyTaskFound:

case osdErrRRWrongTaskID:

case osdErrRRWrongHighRdyPrio:

case osdErrSEWrongTaskPrio:

case osdErrGEOddInvocation:

case osdErrCAAlarmInternal:

case osdErrWAWrongIDonHeap:

case osdErrWAHeapOverflow:

case osdErrWAUnknownAction:

case osdErrWAWrongCounterID:

case osdErrSOStackOverflow:

case osdErrSUWrongTaskID:

case osdErrCLWrongLibrary:

case osdErrEHInterruptsEnabled:

case osdErrSTMemoryError:

case osdErrSTNoImmediateTaskSwitch:

case osdErrSTWrongAppMode:

case osdErrSTConfigCRCError:

case osdErrSTConfigMagicNrError:

case osdErrSTInvalidMajorVersion:

case osdErrSTInvalidMinorVersion:

case osdErrSTInvalidSTCfg:

case osdErrQIWrongTaskPrio:

case osdErrQRInterruptsEnabled:

case osdErrQRWrongTaskID:

case osdErrQRWrongTaskPrio:

case osdErrQRWrongHighRdyPrio:

case osdErrQSInterruptsEnabled:

case osdErrQSNoReadyTaskFound:

case osdErrQSWrongPriority:

case osdErrQOWrongTaskID:

case osdErrSPUnknownCase:

case osdErrSGOddInvocation:

case osdErrWSUnknownAction:

case osdErrWSUnknownReaction:

case osdErrWSWrongID:

case osdErrGCOddInvocation:

case osdErrBMResAlreadyMeasured:

case osdErrBMInvalidProcessInStart:

case osdErrBMInvalidProcessInStop:

case osdErrBMInvalidResource:

case osdErrETNoCurrentProcess:

case osdErrASOddInvocation:

case osdErrTAInvalidTaskState:

case osdErrRSWrongTaskPrio:

case osdErrPAInvalidAreaIndex:

case osdErrPANoAccessRight:

case osdErrPAInvalidAddress:

case osdErrYOSystemStackOverflow:

case osdErrYOTaskStackOverflow:

case osdErrYOISRStackOverflow:

case osdErrSCWrongSysCallParameter:

case osdErrDPStartValidContext:

case osdErrDPResumeInvalidContext:

case osdErrDPInvalidTaskIndex:

case osdErrDPInvalidApplicationID:

case osdErrSUInvalidTaskIndex:

case osdErrSUInvalidIsrIndex:

case osdErrSUInvalidIsrPrioLevel:

case osdErrCIInvalidIsrIndex:

case osdErrCIInvalidIsrPrioLevel:

case osdErrCIInvalidApplicationID:

case osdErrCIMissingIntRequest:

case osdErrCIInterruptIsMasked:

case osdErrCIWrongIntPriority:

case osdErrPIGetIMRInvalidIndex:

case osdErrPISetIMRInvalidIndex:

case osdErrPIClearIMRInvalidIndex:

case osdErrPIWriteIMR8InvalidAddr:

case osdErrPIWriteIMR16InvalidAddr:

case osdErrPIWriteIMR32InvalidAddr:

case osdErrPISetICRMaskInvalidAddr:

case osdErrPIClearICRMaskInvalidAddr:

case osdErrPISetICRReqInvalidAddr:

case osdErrPIClearICRReqInvalidAddr:

case osdErrPIWriteICR8InvalidAddr:

case osdErrPIWriteICR16InvalidAddr:

case osdErrPIWriteICRxLoInvalidIndex:

case osdErrPIWriteICRxHiInvalidIndex:

case osdErrPIWriteICRx16InvalidIndex:

case osdErrCRInvalidSettingOSTM:

case osdErrCRInvalidSettingMPU:

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

ProcPrmntOsErr(OSErrorGetosCANError())

break

default:

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

ProcNonCritOsErr(OSErrorGetosCANError())

break

Interrupt Functions

None

Module Internal (Local) Functions

Local Function #1

Function Name	Type	Min	Max
Arguments Passed

Return Value

Design Rationale

Processing

GLOBAL Function/Macro Definitions

GLOBAL Function #1

Function Name	Type	Min	Max
Arguments Passed

Return Value

Design Rationale

Processing

Known Limitations with Design

UNIT TEST CONSIDERATION

Abbreviations and Acronyms

Abbreviation or Acronym	Description

Glossary

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

ISO 9000
ISO/IEC 12207
ISO/IEC 15504
Automotive SPICE® Process Reference Model (PRM)
Automotive SPICE® Process Assessment Model (PAM)
ISO/IEC 15288
ISO 26262
IEEE Standards
SWEBOK
PMBOK
Existing Nexteer Automotive documentation

Term	Definition	Source
MDD	Module Design Document
DFD	Data Flow Diagram

References

Ref. #	Title	Version
1	AUTOSAR Specification of Memory Mapping (Link:AUTOSAR_SWS_MemoryMapping.pdf)	v1.3.0 R4.0 Rev 2
2	MDD Guideline	EA4 01.00.00
3	Software Naming Conventions.doc	1.0
4	Software Design and Coding Standards.doc	2.0

6 - Os Peer Review Checklists

Overview

Summary Sheet
Synergy Project

Sheet 1: Summary Sheet

Rev 1.2

8-Jun-15

Peer Review Summary Sheet

Synergy Project Name:

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

Revision / Baseline:

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

Change Owner:

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

Work CR ID:

EA4#8733

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

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

Reviewed:

Yes

MDD

Yes

Source Code

N/A

PolySpace

N/A

Integration Manual

N/A

Davinci Files

Comments:

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

source files and documentation

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

Sheet 2: Synergy Project

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

Follows convention created for

naming convention

BSW components

Project contains necessary subprojects

Yes

Comments:

Project contains the correct version of subprojects

Yes

Comments:

Design subproject is correct version

N/A

Comments:

General Notes / Comments:

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

Change Owner:

Lucas Wendling

Review Date :

12/11/16

Lead Peer Reviewer:

Jared Julien

Approved by Reviewer(s):

Yes

Other Reviewer(s):

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

Restrictions for MICROSAR OS SafeContext

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

Outline
Page 1
Page 2

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

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

ShutdownHook<Applicationname>
2014, Vector Informatik GmbH
Version: 1.0.0
1 / 2
based on template version 4.7.2

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

Document Outline

10 - TechnicalReference_MICROSAROS_RH850

MICROSAR OS RH850

11 - TechnicalReference_MICROSAROS_RH850_ind

12 - TechnicalReference_MICROSAROS_RH850s

MICROSAR OS RH850
Technical Reference

Authors
Senol Cendere, Yohan Humbert
Version
1.11
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
Y. Humbert
2015-11-10
1.10
Support Multicore SC3
S. Cendere
2016-01-22  1.11
Added description for osCheckAndRefreshTimer

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
9.01

2016, Vector Informatik GmbH
Version: 1.11                                2 / 58

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).
2016, Vector Informatik GmbH
Version: 1.11                                3 / 58

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
2016, Vector Informatik GmbH
Version: 1.11                                8 / 58

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
E1x-FCC2  RH850_E1x_FCC2.i41
RH850_E1x_FCC2.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

2016, Vector Informatik GmbH
Version: 1.11                                9 / 58

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.
2016, Vector Informatik GmbH
Version: 1.11                                10 / 58

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

2016, Vector Informatik GmbH
Version: 1.11                                11 / 58

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 FALSE then the OS API
FALSE
functions 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

2016, Vector Informatik GmbH
Version: 1.11                                12 / 58

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.
CORE
OsOSCORE
uint32
Only Multicore OS: Core assignment for
No default
corresponding MPU region

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.
The number of configurable static MPU regions depends on the derivative.
MpuRegion = Enable
{

StartAddr  = 0x... ;

EndAddr  = 0x… ;

AccessRights = 0x…;

ASID = TRUE;

Identifier = 0x01;

CORE = 0;             /* Multicore OS */
};

2016, Vector Informatik GmbH
Version: 1.11                                13 / 58

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.

2016, Vector Informatik GmbH
Version: 1.11                                14 / 58

Technical Reference MICROSAR OS RH850
3.4
Counter Attributes
Platform specific attributes are located within the container “DRIVER”.
Sub-Attribute Name
Values
Description
(default value is
OIL
XML
written in bold)
Timer
OsCounterTimer  OSTM
Selects the timer hardware which drives the
OSTM_HIRES  hardware counter.
No default
OSTM: OSTM timer is used and generates cyclic
interrupts.
OSTM_HIRES: OSTM timer is used and runs in
high resolution timer mode.
Which interrupt channel is used for a specific
derivative can be found in chapter 8.1.

3.4.1  OSTM Sub-Attributes
Sub-Attribute Name
Values
Description
(default value is
OIL
XML
written in bold)
EnableNesting
OsCounterEnabl
TRUE
Specifies whether the timer interrupt which drives
eNesting
FALSE
the hardware counter can be interrupted by
No default
higher priority interrupts.
InterruptPriority
OsCounterInterr
0 ... 15
The priority of the timer ISR which drives the
uptPriority
0 ... 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].

2016, Vector Informatik GmbH
Version: 1.11                                15 / 58

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

2016, Vector Informatik GmbH
Version: 1.11                                16 / 58

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.
2016, Vector Informatik GmbH
Version: 1.11                                17 / 58

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.
2016, Vector Informatik GmbH
Version: 1.11                                18 / 58

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
2016, Vector Informatik GmbH
Version: 1.11                                19 / 58

Technical Reference MICROSAR OS RH850
4.1
Code Generator
The following files are generated by the code generator genRH850.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_c<X>.c  contains  the  interrupt  vector  tables  for  the  Green  Hills
compiler, where X is the corresponding logical core ID.
The module OILFileName.ort is only generated if the configuration attribute
ORTIDebugSupport is selected.
OILFileName.htm is containing information about the configuration settings.
2016, Vector Informatik GmbH
Version: 1.11                                20 / 58

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 for each core X to use the system stack as start-up
stack:
_osSystemStack_EndAddr_c<X>
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

2016, Vector Informatik GmbH
Version: 1.11                                21 / 58

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().
2016, Vector Informatik GmbH
Version: 1.11                                22 / 58

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
logical 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.
2016, Vector Informatik GmbH
Version: 1.11                                23 / 58

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:
For EIINT, 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.
2016, Vector Informatik GmbH
Version: 1.11                                24 / 58

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.

2016, Vector Informatik GmbH
Version: 1.11                                25 / 58

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 (per Core)
D1L and D1M
12
E1L and E1M
12
E1x-FCC2
16
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. Furthermore, for Multicore OS the core assignment has to be specified.
If a MPU region is configured to be static then it is initialized in StartOS with settings from
the configuration block.

2016, Vector Informatik GmbH
Version: 1.11                                26 / 58

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 on the corresponding core. Example: If a system has 2 non-trusted applications on
the same core,  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.
2016, Vector Informatik GmbH
Version: 1.11                                27 / 58

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
E1x-FCC2  25
OSTM0
26 for second core (Multicore OS)
OSTM1 for second core (Multicore OS)
F1M
84
OSTM0
F1H
84
OSTM0
314 for second core (Multicore OS)  OSTM5 for second core (Multicore OS)
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.

2016, Vector Informatik GmbH
Version: 1.11                                28 / 58

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.

2016, Vector Informatik GmbH
Version: 1.11                                29 / 58

Technical Reference MICROSAR OS RH850
9.1.6  ResumeOSInterrupts
The function ResumeOSInterrupts restores the content of register PMR which was stored
by SuspendOSInterrupts.
Remark: Nested calls are possible.

Note
If  OS API  functions  are  used  before  StartOS  then  osInitialize  must  be  called
  before  any  OS  API  function  is  called.  If  SC3  or  SC4  is  used,  then  also
osInitINTC must be called before StartOS.

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 for the
corresponding core X:
  EBASE = &osExceptionVectorTable_c<X>
  INTBP = &osEIINTVectorTable_c<X>
  INTCFG = 0
  SCBP = &osSysCallTable_c<X> (SC3 and SC4)
  SCCFG = osdNumberOfSysCallFunctions (SC3 and SC4)
  set  table  mode  and  priority  level  for  each  configured  EIINT  interrupt  source
assigned to core X
osInitINTC is called by the OS in StartOS.
Prototype: void osInitINTC(void)

2016, Vector Informatik GmbH
Version: 1.11                                30 / 58

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

2016, Vector Informatik GmbH
Version: 1.11                                31 / 58

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

2016, Vector Informatik GmbH
Version: 1.11                                32 / 58

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

2016, Vector Informatik GmbH
Version: 1.11                                33 / 58

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)
E1x-Fcc2
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)

2016, Vector Informatik GmbH
Version: 1.11                                34 / 58

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;

2016, Vector Informatik GmbH
Version: 1.11 35 / 58

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;

2016, Vector Informatik GmbH
Version: 1.11 36 / 58

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;

2016, Vector Informatik GmbH
Version: 1.11 37 / 58

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;

2016, Vector Informatik GmbH
Version: 1.11                                38 / 58

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;

2016, Vector Informatik GmbH
Version: 1.11                                39 / 58

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;

2016, Vector Informatik GmbH
Version: 1.11 40 / 58

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.
2016, Vector Informatik GmbH
Version: 1.11                                41 / 58

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.

2016, Vector Informatik GmbH
Version: 1.11                                42 / 58

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

2016, Vector Informatik GmbH
Version: 1.11                                43 / 58

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

2016, Vector Informatik GmbH
Version: 1.11                                44 / 58

Technical Reference MICROSAR OS RH850
9.6 Function for OSTM functionality checks
9.6.1  Function osCheckAndRefreshTimer
Function osCheckAndRefreshTimer can be called by trusted applications at any time after
StartOS to check and re-initialize the register settings of system timer OSTM.
Prototype
StatusType osCheckAndRefreshTimer(void)
Parameter
-
-
Return Type
StatusType  E_OK:                                   all registers of OSTM have expected content
E_OS_SYS_API_ERROR:   invalid content was detected in OSTM register
Functional Description
  check content of all used OSTM registers
  re-initialize all OSTM registers which have wrong content
  returns E_OK if all OSTM registers have expected content
  returns E_OS_SYS_API_ERROR if invalid content was detected in OSTM registers
Particularities and Limitations
-
Call Context
  Call is only allowed after StartOS()
  Call is only allowed by trusted applications
Table 7: Function osCheckAndRefreshTimer

2016, Vector Informatik GmbH
Version: 1.11                                45 / 58

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.
2016, Vector Informatik GmbH
Version: 1.11                                46 / 58

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 8 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.

2016, Vector Informatik GmbH
Version: 1.11                                47 / 58

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
2016, Vector Informatik GmbH
Version: 1.11                                48 / 58

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;

2016, Vector Informatik GmbH
Version: 1.11                                49 / 58

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 9: 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.
2016, Vector Informatik GmbH
Version: 1.11                                50 / 58

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;

}

[…]
}

2016, Vector Informatik GmbH
Version: 1.11                                51 / 58

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;

}

[…]
}

2016, Vector Informatik GmbH
Version: 1.11                                52 / 58

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

2016, Vector Informatik GmbH
Version: 1.11                                53 / 58

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
2016, Vector Informatik GmbH
Version: 1.11                                54 / 58

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 10
RH850 specific Error Numbers
2016, Vector Informatik GmbH
Version: 1.11                                55 / 58

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
MC

Table 11
List of source files

1 Only for multi core systems
2016, Vector Informatik GmbH
Version: 1.11                                56 / 58

Technical Reference MICROSAR OS RH850
14.2  Header Files
Module Name
Description
SC1  SC3  SC4
This header has to be included by the
Os.h
●
●
●
application
Included by Os.h, includes the Autosar Header
Os_Cfg.h
files if 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
osekasrt.h
●
●
●
assertion-handling
osekcov.h
Coverage macros
●
●
●
Included by osek.h, definitions of all error-
osekerr.h
●
●
●
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
testmac1.h
●
●
●
ORTI debug support)
User API hook macros (contains macros for
testmac3.h
●

ORTI debug support)
User API hook macros (contains macros for
testmac4.h
●

ORTI debug support)
Included by all headers and system modules,
vrm.h
●
●
●
Vector release management
Linker specific symbols for the syscall table.
osSysCallTable.dld
This file must be included into the global project

●
●
linker file.
File for including the necessary derivative
osDerivatives.h
●
●
●
dependent header.
osRH850_<Derivative>.h  RH850 Derivative specific header file.
●
●
●
Contains specific code for the interrupt
osINTC2.h
●
●
●
controller.
osMultiCore.h
Header for multicore related functions
MC
MC

Table 12
List of header files
2016, Vector Informatik GmbH
Version: 1.11                                57 / 58

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
2016, Vector Informatik GmbH
Version: 1.11                                58 / 58

Document Outline

13 - TechnicalReference_Os

YourTopic

14 - TechnicalReference_Os_ind

Outline
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
Page 20
Page 21
Page 22
Page 23
Page 24
Page 25
Page 26
Page 27
Page 28
Page 29
Page 30
Page 31
Page 32
Page 33
Page 34
Page 35
Page 36
Page 37
Page 38
Page 39
Page 40
Page 41
Page 42
Page 43
Page 44
Page 45
Page 46
Page 47
Page 48
Page 49
Page 50
Page 51
Page 52
Page 53
Page 54
Page 55
Page 56
Page 57
Page 58
Page 59
Page 60
Page 61
Page 62
Page 63
Page 64
Page 65
Page 66
Page 67
Page 68
Page 69
Page 70
Page 71
Page 72
Page 73
Page 74
Page 75
Page 76
Page 77
Page 78
Page 79
Page 80
Page 81
Page 82
Page 83
Page 84
Page 85
Page 86
Page 87
Page 88
Page 89
Page 90
Page 91
Page 92
Page 93
Page 94
Page 95
Page 96
Page 97
Page 98
Page 99
Page 100
Page 101
Page 102
Page 103
Page 104
Page 105
Page 106
Page 107
Page 108
Page 109
Page 110
Page 111
Page 112
Page 113
Page 114
Page 115
Page 116
Page 117
Page 118
Page 119
Page 120
Page 121
Page 122
Page 123
Page 124
Page 125
Page 126
Page 127
Page 128
Page 129
Page 130
Page 131
Page 132
Page 133
Page 134
Page 135
Page 136

15 - TechnicalReference_Oss

MICROSAR OS SafeContext
Technical Reference

Version 9.01

Status
Released
Document ID
OS01.0280

Technical Reference MICROSAR OS SafeContext

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

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

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

Caution
We have configured the programs in accordance with your specifications in the
questionnaire. Whereas the programs do support other configurations than the one
specified in your questionnaire, Vector´s release of the programs delivered to your
company is expressly restricted to the configuration you have specified in the
questionnaire.

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

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

2  Introduction
This document describes the functionality, API and configuration of the general part of the
AUTOSAR BSW module OS as specified in [1].

Supported AUTOSAR Release:
4.0.3
Supported Configuration Variants:
pre-compile
Vendor ID:
OS_VENDOR_ID
30  decimal  (= Vector-
Informatik,  according  to
HIS)
Module ID:
OS_MODULE_ID
1 decimal  (according to
ref. [2])

2.1  Architecture Overview
The following figure shows where the OS is located in the AUTOSAR architecture.

Figure 2-1
AUTOSAR 3.x Architecture Overview
Figure 2-2
AUTOSAR architecture
2015, Vector Informatik GmbH
Version: 9.01
15 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

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

Technical Reference MICROSAR OS SafeContext

3  Functional Description
3.1
Features
The features listed in this chapter cover the complete functionality specified in [1].
The  "supported"  and  "not  supported"  features  are  presented  in  the  following  two  tables.
For further information of not supported features, also see chapter 9.

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

Technical Reference MICROSAR OS SafeContext

The operating system is controlled by external events. External events can be events from
interrupt  routines,  from  the  alarm  management,  or  from  schedule  tables  (Alarms  and
schedule  tables  are  also  driven  by  interrupt  service  routines).  Therefore,  any  external
event will result in the change of task states.

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

Technical Reference MICROSAR OS SafeContext

3.2.1.1
Time Base
3.2.1.1.1
Counter Macros
To  support  the  portability  of  OSEK,  application  alarm  related  functions,  for  example
SetRelAlarm,  should  be  called  using  macros  for  the  calculation  of  ticks  based  on
millisecond or seconds:
SetRelAlarm (Alarm1, OS_xx2TICKS_<CounterName> (1200), OS_xx2TICKS_<CounterName>
(1200));
The macros OS_TICKS2xx_<CounterName>() (whereas xx denotes NS, US, MS or SEC;
described by the AUTOSAR standard) may be used to convert tick values (as returned for
example  by  GetElapsedTime()  and  GetCounterValue()  )  to  into  a  second  based
timer
unit.
Additionally,
MICROSAR
OS
provides
the
inverse
macros
OS_xx2TICKS_<CounterName>() for conversion into the opposite direction (see Figure
2-2).

Figure 3-2
Counter Macros

Caution
Depending on the hardware settings, certain nanosecond times may not be
  representable accurately.

Therefore, if large times, very small times or very high precision is needed, use
AUTOSAR OS OsTimeConstant instead (see 7.3.3).

3.2.1.1.2
Temporal Range of Alarms
The  temporal  range  of  an  alarm  depends  on  the  Counter,  which  drives  the  alarm.  The
important
configuration
attributes
here
are
OsSecondsPerTick
and
OsCounterMaxAllowedValue (see 7.3.3).
3.2.1.2
Timer Interrupt Routine
The timer interrupt routines are category 2 ISRs and are part of the operating system. The
configuration is done automatically by the OS using  information that has to be defined in
the OIL Configurator.
3.2.1.2.1
Counter API
To  obtain  the  counter  specific  limits  (e.g.  maxallowedvalue)  the  function
GetAlarmBase can be used.
2015, Vector Informatik GmbH
Version: 9.01
19 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

Example
The ISR that triggers the counter must be of category 2.
  ISR(MyCounterISR)
{
IncrementCounter(MyCounter);
}

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

Technical Reference MICROSAR OS SafeContext

3.2.2.3
Stack Monitoring
MICROSAR OS SafeContext always initializes the last useable bytes of each stack with an
indicator value.
This indicator is then checked with each task switch or ISR exit. A change of the element
value  indicates  a  stack  overflow  by  the  task  or  ISR.  In  this  case,  the  system  calls  the
ErrorHook (if configured), the ShutdownHook (if configured) and enters the shutdown
state.

Note
MICROSAR OS checks the indicator value only at task switches and on a return from
  an ISR. Therefore, stack overflows are not detected immediately. Detection might be
delayed arbitrary in case of a stack overflow in a hook routine. Some implementations
of MICROSAR OS implement additional checks of the indicator value, see [4]. If
memory protection is configured, stack overflows in tasks and ISRs of non-trusted
applications are found immediately by the memory protection if the stack is followed by
an area with no access rights.

In case a  stack fault is detected by memory protection,  the ProtectionHook is called with
parameter  E_OS_PROTECTION_MEMORY.  If  a  stack  fault  is  detected  by  stack
monitoring, MICROSAR OS goes into shutdown after the ProtectionHook.

3.2.2.4
Stack Usage
If  StackUsageMeasurement  is  set  to  TRUE,  the  OS  fills  all  available  stacks  with  the
indicator value 0xAA during StartOS (startup times will be slower). This allows measuring
the  amount  of  stack  used  since  StartOS  by  counting  the  amount  of  bytes  that  have  not
been overwritten yet.
The following function is available to determine the amount of used stack:
osuint16 osGetStackUsage(TaskType taskId)
>  Argument: Task number
>  Return value:  Maximum stack usage (bytes) by task since call of StartOS()
Additional implementations specific functions may be available. Please see the hardware
specific part of the documentation of this implementation [4].

Caution
Dependent on the stack size, the measurement operation can take a long time.

3.2.3
Interrupt Handling
Implementation  specific  details  about  interrupt  handling  are  described  in  the  hardware
specific part of this implementation [4].
2015, Vector Informatik GmbH
Version: 9.01
21 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Caution
Knowledge about the interrupt handling is very important. If interrupt routines are used
  it is essential to read this chapter.

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

/* code with API calls */

}

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

Technical Reference MICROSAR OS SafeContext

To ensure data consistency, the operating system needs to disable category 2
interrupts during critical sections of code. Therefore, applications must not use non-
maskable interrupts as category 2 interrupts.

3.2.3.2
Usage of the Interrupt API before StartOS
The usage of the interrupt API functions is in general allowed before the operating system
is started. The affected functions are:
>  DisableAllInterupts, EnableAllInterrupts
>  SuspendAllInterrupts, ResumeAllInterrupts
>  SuspendOSInterrupts, ResumeOSInterrupts
However,  these  functions  use  some  internal  variables  that  have  to  be  initialized  to  zero
before  the  first  call  of  the  interrupt  API.  Typically,  this  initialization  is  performed  by  the
startup code (which might be delivered with the compiler). In case no startup code is used,
the  function  osInitialize()  needs  to  be  called.  osInitialize  initializes  the
variables which are used in the interrupt API.
2015, Vector Informatik GmbH
Version: 9.01
23 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

3.2.4
Timing Protection
The  timing  protection  is  implemented  in  the  Scalability  Classes  2  and  4.  This  chapter
provides some hints on the functionality according to the AUTOSAR OS standard [1] and
describes additional functionality provided by Vector MICROSAR OS. To enable the timing
protection of a task or ISR, the OIL-attribute TIMING_PROTECTION of the respective task
or ISR needs to be configured, as described in chapters  7.3.2.2 and 7.3.7.2 . (AUTOSAR
XML: OsTaskTimingProtection/OsIsrTimingProtection).

Caution
The runtime of all tasks and ISRs is observed, however parts of the time for task switch
  and interrupt entry/exit cannot be monitored by the timing protection. Therefore, some
extra time for task switches and interrupt entry/exit needs to be considered in the
configuration of the timing protection.

Caution
Timing Protection is implemented with interrupts. If the application manually disables
  interrupts anywhere, the timing protection cannot work as expected. In order to enable
and disable interrupts, the application must use the following API functions:
>  DisableAllInterupts, EnableAllInterrupts
>  SuspendAllInterrupts, ResumeAllInterrupts
>  SuspendOSInterrupts, ResumeOSInterrupts

Caution
The timing protection works very precise. However, if an OS API function is called by a
  task/ISR, the OS may enter a critical section; if a timing protection violation is detected
while the system is in a critical section, the call of the protection hook may be delayed
until the end of the critical section. Note, that critical sections in AUTOSAR OS are very
short.

3.2.4.1
Reaction on Protection Failure
The AUTOSAR  specification  describes  different  possibilities  how  to  react  to  a  protection
violation.  In  SafeContext  implementations,  reaction  to  such  a  situation  is  limited  to
Shutdown.
3.2.4.2
Timing Measurement
MICROSAR  OS  is  not  only  able  to  provide  timing  protection  but  allows  using  the  same
functionality  for  timing  measurement.  If  timing  measurement  is  performed  for  a  specific
task or ISR, the OS measures the following times for that task or ISR:
>  the maximum run time since StartOS
>  the maximum locking times for resources and interrupts since StartOS
2015, Vector Informatik GmbH
Version: 9.01
24 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

OS
TASK/ISR

                   TIMING_PROTECTION
Timing-
Global-
FALSE
TRUE
Measuremen
Config

OnlyMeasure
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  (Chapters  6.6.2  and
6.6.3) is considered to belong to the runtime of the currently active task.

Caution
Depending on the implementation, the execution of the ProtectionHook might be
  delayed until the PreTaskHook or PostTaskHook has finished. In case of a protection
violation during the PostTaskHook while a task state change into the states
SUSPENDED or WAITING, the call of the ProtectionHook gets lost.
Therefore, the PreTaskHook and the PostTaskHook are allowed for debugging
purposes only. They must be disabled in production code, see [9].

The  runtime  of  the  hook functions  UserPreIsrHook  and  UserPostIsrHook  (Chapters  6.6.7
and 6.6.8) is considered to belong to the runtime of the currently active ISR.
3.2.5
Memory Protection
MICROSAR OS uses the MPU of the microcontroller to implement memory protection as
described  in  [1].  Former  versions  of  MICROSAR  OS  fulfilled  the AUTOSAR  requirement
OS195  and  prevented  write  access  to  Task/ISR  private  data  areas  even  within  an

1 Optimization: The timing measurement API is unavailable
2015, Vector Informatik GmbH
Version: 9.01
26 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

OSApplication. This behaviour is defined as optional by AUTOSAR and not implemented in
most current versions of MICROSAR OS. It is explicitly mentioned in [5] if supported.
3.2.6
Schedule Tables
MICROSAR  OS  implements  schedule  tables  as  defined  by  the AUTOSAR  standard. The
document  [1]  provides  the  base  description  of  schedule  tables  and  their  usage.  This
chapter is meant as an extension that clarifies and corrects some points, provides details
about points left open and describes corrections and extensions by MICROSAR OS.
AUTOSAR  defines  schedule  tables  for  all  scalability  classes,  but  synchronization  to  a
global time only for SC2 and SC4. MICROSAR OS offers some additional error checking
to the AUTOSAR standard.
3.2.6.1
Synchronization
In  SC2  and  SC4  or  the  High-Resolution  Schedule  Tables  option,  it  is  possible  to
synchronize a schedule table to a global time source. The schedule table must be marked
with the OIL attribute LOCAL_TO_GLOBAL_TIME_SYNCHRONIZATION.
3.2.6.1.1
Starting a synchronizable Schedule Table
One  way  to  start  a  synchronizable  schedule  table  is  to  use  the  functions
StartScheduleTableRel(Tablename, TimeOffset)
and
StartScheduleTableAbs(Tablename, Time). The time parameters refer to the local
time and not to the global time. It is assumed that the schedule table will not have an offset
to  global  time:  when  synchronization  starts,  the  start  of  the  schedule  table  is  moved  to
global time zero. Note that the schedule table always starts at the stated start time. A call
of  SyncScheduleTable  does  not  influence  this  start  time.  Synchronization  starts  after
execution of the first expiry point.
The recommended way to start a synchronizable schedule table is to use the combination
of StartScheduleTableSynchron(Tablename) and SyncScheduleTable(). The
first expiry point is executed at global time 0. The schedule table starts execution after a
global time is available, i.e. after calling SyncScheduleTable() for the schedule table. If
SyncScheduleTable() is never called for the schedule table, the schedule table is
never executed. The following algorithm describes a possibility to set up a timeout:
Set
up
an
alarm
to
the
timeout
time.
When
the
alarm
expires
and
GetScheduleTableStatus()  indicates  that  the  schedule  table  is  still  waiting,  call
SyncScheduleTable()
with
an
arbitrary
time.
Note:
if
the
call
to
SyncScheduleTable() is done in an interrupt, it may occur between the two API calls,
and thus gets overridden by the arbitrary time.
3.2.6.1.2
Autostart
For an automatic start of a schedule table on startup of the OS, the attribute AUTOSTART
must  be  set. The  sub-attribute  TYPE  defines  how  the  start  is  performed. The possibilities
are:  ABSOLUT,  RELATIVE  and  SYNCHRON.  These  types  of  autostart  are  similar  to  the
normal
start
of
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 document [4].
To access these error numbers the ERRORHOOK has to be enabled. The numbers are then
accessible via the macro OSErrorGetosCANError().
Error Types:
Error Type
Description
OSEK
OSEK / AUTOSAR error. After calling the ErrorHook, the program is
continued.
assertion
System assertion error. After calling the ErrorHook the operating system
is shut down. Assertion checking is always enabled in SafeContext
implementations.
2015, Vector Informatik GmbH
Version: 9.01
34 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Error Type
Description
syscheck
System error. After calling the ErrorHook the operating system is shut
down. Refer to the specific error for a description how to enable or disable
error checking.
Table 3-6
Error types
3.3.3.1
Error Numbers of Group Task Management / (1)
Group (1) contains the functions:
API Function
Abbreviation  Function
Number
ActivateTask
AT
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 manual [4].
4.3.3
Code Generator
The  code  generator  GENxxxx.EXE  is  copied  onto  the  local  hard  disk  by  the  installation
program.  The  code  generator  is  defined  in  the  INI-file  OILGEN.INI.  (‘xxxx’  has  to  be
replaced by a hardware dependent abbreviation)
4.4
OSEK Operating System
4.4.1
Installation Paths
The delivered operating system parts are organized in different subdirectories.
The following structure is used by osCAN style installations:
>  root\HwPlatform\APPL\Compiler\Derivative
Sample applications
>  root\HwPlatform\BIN
executable files (e.g. make tool)
>  root\HwPlatform\bswmd_files
XML parameter descrption files
2015, Vector Informatik GmbH
Version: 9.01
58 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

>  root\HwPlatform\DOC
Documentation
>  root\HwPlatform\INCLUDE
OSEK include files
>  root\HwPlatform\LIB
OSEK library (only if a library is available)
>  root\HwPlatform\SRC
OSEK sources (C and Assembler)

The following structure is used by MICROSAR style installations:
>  root\Demo\Os
Sample applications
>  root\Generators\Os
executable files (e.g. make tool)
>  root\Generators\Components\_Schemes\
XML parameter descrption files
Os_<platform and derivate>_bswmd \bswmd
>  root\Doc\TechnicalReferences
Documentation
>  root \Doc\UserManuals
>  root\BSW\Os
OSEK include files
>  root\BSW\Os
OSEK library (only if a library is available)
>  root\BSW\Os
OSEK sources (C and Assembler)

4.5
XML Configurations
AUTOSAR uses for configuration files the XML format. An XML Schema (ref. [8]) defines
the structure. For each derivative there is an ECU Parameter Definition File (file extension
is  arxml)  which  defines  all  attributes  (standard  attribute  and  vendor/platform  specific
attributes).
The  Vector  implementation  of AUTOSAR  OS  uses  the OIL  [6]  configuration file format or
ECU Configuration files. A conversion of ECUC files to OIL, as it was necessary in former
versions of MICROSAR OS, is not required any more.
4.5.1
Parameter Definition Files
Parameter  Definition  Files  for  the  implementation  can  be  found  in  the  directory
root\HwPlatform\BSWMD_files (osCAN style) or
root\Generators\Components\_Schemes\Os_<platform and
derivate>_bswmd\bswmd (MICROSAR style).
The files have the name OS_<platform and derivate>_bswmd.arxml.
2015, Vector Informatik GmbH
Version: 9.01
59 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

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

Technical Reference MICROSAR OS SafeContext

Variable
Meaning
LIB
Always 0, because MICROSAR OS SafeContext cannot be configured to library
variant.
STATUS_LEVEL
Reflects the setting of the configuration attribute STATUS of MICROSAR OS.
Possible values:
EXTENDED_STATUS = 1
DEBUG_SUPPORT
Always 1, because ORTIDebugSupport is always enabled for MICROSAR OS
SafeContext.
Table 5-2
Variables generated into the file libconf

5.1.2.2
Application Template Generator GENTMPL
Former  versions  of  MICROSAR  OS  and  osCAN  came  with  a  template  code  generator
which generates a main.c template file with empty implementations for the objects defined
in the configuration. This is not supported any more in newer implementations.
5.2  Include Structure
The  header  files  tcb.h  and  tcbpost.h  are  included  into  the  file  os.h.  The  user  must
include os.h in every module of his application. The headers tcb.h and tcbpost.h are
included  automatically.  Always  recompile  all  files  after  a  new  generation  of  tcb.h  and
tcbpost.h.
If  an  application  is  using  trusted  functions  and  the  Vector  extension  “GenerateStubs”,  an
include file named usrostyp.h must be present in the include path. This file must contain
all user specific data types used for trusted functions.
2015, Vector Informatik GmbH
Version: 9.01
61 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

6  API Description
6.1  Standard API - Overview
This  chapter  gives  an  overview  of  all  standard  API  functions  defined  for  the  OS.  The
following synonyms present the standard specifications:
>  ASR: AUTOSAR standard, reference [1]
>  OSEK: OSEK standard, reference [3]
These standard specifications contain the detailed API descriptions. In case part of an API
function  is  implementation  specific,  the  detailed  API  description  is  given  in  a  further
subchapter in this document.
API Function Prototype
Standard
Scalability
Specification  Class
OSEK  ASR
1  2  3  4
Task Handling
StatusType ActivateTask  (TaskType TaskID)


      
StatusType TerminateTask (void)


      
StatusType ChainTask      (TaskType TaskID)


      
StatusType Schedule       (void)


      
StatusType GetTaskID      (TaskRefType TaskID)


      
StatusType GetTaskState  (TaskType TaskID,


      
                                  TaskStateRefType State)
Event Control
StatusType SetEvent   (TaskType TaskID,


      
                              EventMaskType Mask)
StatusType ClearEvent (EventMaskType Mask)


      
StatusType GetEvent   (TaskType TaskID,


      
                              EventMaskRefType Mask)
StatusType WaitEvent  (EventMaskType Mask)


      
Interrupt Handling
The behavior of the interrupt handling functions is implementation specific. For a detailed
description see hardware specific technical reference [4].
void EnableAllInterrupts   (void)


      
void DisableAllInterrupts (void)


      
void ResumeAllInterrupts   (void)


      
void SuspendAllInterrupts (void)


      
void ResumeOSInterrupts    (void)


      
void SuspendOSInterrupts   (void)


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

Technical Reference MICROSAR OS SafeContext

API Function Prototype
Standard
Scalability
Specification  Class
OSEK  ASR
1  2  3  4
Resource Management
The behaviour of the resource management functions is implementation specific
StatusType GetResource       (ResourceType ResID)


      
StatusType ReleaseResource  (ResourceType ResID)


      
Alarms
StatusType GetAlarmBase  (AlarmType AlarmID,


      
                                AlarmBaseRefType Info)
StatusType GetAlarm       (AlarmType AlarmID,


      
                                TickRefType Tick)
StatusType SetRelAlarm   (AlarmType AlarmID,


      
                                TickType Increment,
                                TickType cycle)
StatusType SetAbsAlarm   (AlarmType AlarmID,


      
                                TickType Start,
                                TickType cycle)
StatusType CancelAlarm   (AlarmType AlarmID)


      
Execution Control
void           StartOS     (AppModeType Mode)


      
void           ShutdownOS (StatusType Error)


      
ISRType       GetISRID   (void)


      
AppModeType GetActiveApplicationMode(void)


      
ApplicationType  GetApplicationID     (void)



  
StatusType   CallTrustedFunction



  
  (TrustedFunctionIndexType FunctionIndex,
  TrustedFunctionParameterRefType FunctionParams)
StatusType   GetApplicationState



  
  (ApplicationType Application,
ApplicationStateRefType Value)
Hook Routines
The context for called hook routines is implementation specific. For a detailed description see
see hardware specific technical reference [4].
void   ErrorHook              (StatusType Error)


void   PreTaskHook           (void)


void   PostTaskHook          (void)


void   StartupHook           (void)


void   ShutdownHook          (StatusType Error)


ProtectionReturnType ProtectionHook



    
                                  (StatusType Fatalerror)
2015, Vector Informatik GmbH
Version: 9.01
63 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

API Function Prototype
Standard
Scalability
Specification  Class
OSEK  ASR
1  2  3  4
Schedule Tables
StatusType   StartScheduleTableRel


      
      (ScheduleTableType ScheduleTableID,
        TickType Offset)
StatusType   StartScheduleTableAbs


      
      (ScheduleTableType ScheduleTableID,
        TickType Start)
StatusType   StopScheduleTable


      
      (ScheduleTableType ScheduleTableID)
StatusType   NextScheduleTable


      
      (ScheduleTableType ScheduleTableID_From,
        ScheduleTableType ScheduleTableID_To)
StatusType   StartScheduleTableSynchron



    
      (ScheduleTableType ScheduleTableID)
StatusType   SyncScheduleTable



    
      (ScheduleTableType ScheduleTableID,
        TickType Value)
StatusType   SetScheduleTableAsync



    
      (ScheduleTableType ScheduleTableID)
StatusType   GetScheduleTableStatus


      
      (ScheduleTableType ScheduleTableID,
        ScheduleTableStatusRefType ScheduleStatus)
Counters
StatusType   IncrementCounter


      
      (CounterType CounterID)
StatusType   GetCounterValue


      
      (CounterType CounterID, TickRefType Value)
StatusType   GetElapsedValue


      
      (CounterType CounterID, TickRefType Value,
        TickRefType ElapsedValue)
Access Rights Management
AccessType   CheckISRMemoryAccess



  
      (ISRType ISRID,
        MemoryStartAddressType Address,
        MemorySizeType Size)
AccessType   CheckTaskMemoryAccess



  
      (TaskType TaskID,
        MemoryStartAddressType Address,
        MemorySizeType Size)
ObjectAccessType CheckObjectAccess



  
      (ApplicationType ApplID,
        ObjectTypeType ObjectType, …)
2015, Vector Informatik GmbH
Version: 9.01
64 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

API Function Prototype
Standard
Scalability
Specification  Class
OSEK  ASR
1  2  3  4
ApplicationType CheckObjectOwnership



  
      (ObjectTypeType ObjectType, …)
Table 6-1
Standard API functions
6.2  API Functions defined by Vector - Overview
This chapter gives an overview of all API functions defined for the OS by Vector.  Further
chapters contain detailed descriptions of these API functions.
API Function Prototype
Scalability
Class
1  2  3  4
Measurement API
For a detailed description see chapter 6.4.
StatusType   GetTaskMaxExecutionTime

    
        (TaskType TaskID, osTPTimeRefType MaxTime)
StatusType   GetISRMaxExecutionTime

    
        (ISRType TaskID, osTPTimeRefType MaxTime)
StatusType   GetTaskMaxBlockingTime

    
        (TaskType TaskID, BlockTypeType BlockType,
          ResourceType ResourceID, osTPTimeRefType MaxTime)
StatusType   GetISRMaxBlockingTime

    
        (ISRType ISRID, BlockTypeType BlockType,
          ResourceType ResourceID, osTPTimeRefType MaxTime)
StatusType osGetISRMinInterArrivalTime

    
         (ISRType ISRID, osTPTimeStampRefType MinTime)
StatusType osGetTaskMinInterArrivalTime

    
         (TaskType ISRID, osTPTimeStampRefType MinTime)
Non-Trusted Functions
Calling service functions from Non-Trusted Applications. The complement part of the AUTOSAR
API CallTrustedFunction.
StatusType   osCallNonTrustedFunction

  
  (NonTrustedFunctionIndexType FunctionIndex,
  NonTrustedFunctionParameterRefType FunctionParams)
Peripheral Region API

API to access memory mapped hardware registers, which are only accessible in
privileged mode.
osuint8 osReadPeripheral8(osuint16 area, osuint32 address)

  
osuint16 osReadPeripheral16(osuint16 area, osuint32 address)

  
osuint32 osReadPeripheral32(osuint16 area, osuint32 address)

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

Technical Reference MICROSAR OS SafeContext

API Function Prototype
Scalability
Class
1  2  3  4
void osWritePeripheral8(osuint16 area, osuint32 address, osuint8

  
value)
void osWritePeripheral16(osuint16 area, osuint32 address, osuint16

  
value)
void osWritePeripheral32(osuint16 area, osuint32 address, osuint32

  
value)
void osModifyPeripheral8(osuint16 area, osuint32 address, osuint8

  
clearmask, osuint8 setmask)
void osModifyPeripheral16(osuint16 area, osuint32 address, osuint16

  
clearmask, osuint16 setmask)
void osModifyPeripheral32(osuint16 area, osuint32 address, osuint32

  
clearmask, osuint32 setmask)
MPU Access Checking API

Check whether you have read/write access to a given address.
uint8 osCheckMPUAccess(uint8* DestinationAddress)

  
Table 6-2
Vector API functions
6.3
Timing Measurement API
6.3.1
GetTaskMaxExecutionTime
Prototype
StatusType GetTaskMaxExecutionTime ( TaskType TaskID, osTPTimeRefType MaxTime )
Parameter
TaskID
The task to be questioned
MaxTime
Maximum execution time, measured in all finished time frames.
Return code
E_OK
No errors
E_OS_ID
The TaskID is not valid.
Functional Description
The maximum execution time of finished executions of the questioned task since StartOS. The value is in
ticks of the ExecutionTime hardware timer. The number of ticks per ms of this timer is printed into the HTML
list file.
Particularities and Limitations
>  Available in Scalability Classes 2 and 4.
>  This function is synchronous.
>  This function is reentrant.
>  This function is only available if the attribute TimingMeasurement is set to TRUE (is selected)
2015, Vector Informatik GmbH
Version: 9.01
66 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

>  SuspendAllInterrupts
>  ResumeAllInterrupts
>  SuspendOSInterrupts
>  ResumeOSInterrupts
The implementation specific behaviour is of these functions is described in [5].
6.4.1.1
EnableAllInterrupts
Prototype
void EnableAllInterrupts ( void )
Parameter
--
--
Return code
void
--
Functional Description
This service restores the state saved by DisableAllInterrupts.

This service is a counterpart of DisableAllInterrupts service, which has to be called before, and its
aim is the completion of the critical section of code. No API service calls are allowed within this critical
section.

The implementation should adapt this service to the target hardware providing a minimum overhead.
Usually, this service enables recognition of interrupts by the central processing unit.

This function might be implemented using a global interrupt flag or an interrupt level register.
Particularities and Limitations
>  When using before StartOS, the function osInitialize must be called first to initialize the variables
which are used in the interrupt API.
>  The function must not be used within handlers of non-maskable interrupts as this can violate the
consistancy of internal variables.
Expected Caller Context
>  --
Table 6-9
EnableAllInterrupts

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

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

Functional Description
This service restores the recognition status of all interrupts saved by the SuspendAllInterrupts
service.

This service is the counterpart of SuspendAllInterrupts service, which has to have been called
before, and its aim is the completion of the critical section of code. No API service calls beside
SuspendAllInterrupts/ResumeAllInterrupts pairs and
SuspendOSInterrupts/ResumeOSInterrupts pairs are allowed within this critical section.

The implementation should adapt this service to the target hardware providing a minimum overhead.
SuspendAllInterrupts/ResumeAllInterrupts can be nested. In case of nesting pairs of the calls
SuspendAllInterrupts and ResumeAllInterrupts the interrupt recognition status saved by the first
call of SuspendAllInterrupts is restored by the last call of the ResumeAllInterrupts service.

This function might be implemented using a global interrupt flag or an interrupt level register.
Particularities and Limitations
>  When using before StartOS, the function osInitialize must be called first to initialize the variables
which are used in the interrupt API.
>  The function must not be used within handlers of non-maskable interrupts as this can violate the
consistancy of internal variables.
Expected Caller Context
>  --
Table 6-11   ResumeAllInterrupts
6.4.1.4
SuspendAllInterrupts
Prototype
void SuspendAllInterrupts ( void )
Parameter
--
--
Return code
void
--
2015, Vector Informatik GmbH
Version: 9.01
73 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Functional Description
This service saves the recognition status of all interrupts and disables all interrupts for which the hardware
supports disabling.

This service is intended to protect a critical section of code from interruptions of any kind. This section shall
be finished by calling the ResumeAllInterrupts service. No API service calls beside
SuspendAllInterrupts/ResumeAllInterrupts pairs and
SuspendOSInterrupts/ResumeOSInterrupts pairs are allowed within this critical section.
The implementation should adapt this service to the target hardware providing a minimum overhead.

This function might be implemented using a global interrupt flag or an interrupt level register.
Particularities and Limitations
>  When using before StartOS, the function osInitialize must be called first to initialize the variables
which are used in the interrupt API.
>  The function must not be used within handlers of non-maskable interrupts as this can violate the
consistancy of internal variables.
Expected Caller Context
>  --
Table 6-12   SuspendAllInterrupts
6.4.1.5
ResumeOSInterrupts
Prototype
void ResumeOSInterrupts ( void )
Parameter
--
--
Return code
void
--
Functional Description
This service restores the recognition status of interrupts saved by the SuspendOSInterrupts service.

This service is the counterpart of SuspendOSInterrupts service, which has to have been called before,
and its aim is the completion of the critical section of code. No API service calls beside
SuspendAllInterrupts/ResumeAllInterrupts pairs and
SuspendOSInterrupts/ResumeOSInterrupts pairs are allowed within this critical section.
The implementation should adapt this service to the target hardware providing a minimum overhead.
SuspendOSInterrupts/ResumeOSInterrupts can be nested. In case of nesting pairs of the calls
SuspendOSInterrupts and ResumeOSInterrupts the interrupt recognition status saved by the first
call of SuspendOSInterrupts is restored by the last call of the ResumeOSInterrupts service.

This function might be implemented using a global interrupt flag or an interrupt level register
2015, Vector Informatik GmbH
Version: 9.01
74 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Particularities and Limitations
>  When using before StartOS, the function osInitialize must be called first to initialize the variables
which are used in the interrupt API.
>  The function must not be used within handlers of non-maskable interrupts as this can violate the
consistancy of internal variables.
Expected Caller Context
>  --
Table 6-13   ResumeOSInterrupts
6.4.1.6
SuspendOSInterrupts
Prototype
void SuspendOSInterrupts ( void )
Parameter
--
--
Return code
void
--
Functional Description
This service saves the recognition status of interrupts of category 2 and disables the recognition of these
interrupts.

This service is intended to protect a critical section of code. This section shall be finished by calling the
ResumeOSInterrupts service. No API service calls beside
SuspendAllInterrupts/ResumeAllInterrupts pairs and
SuspendOSInterrupts/ResumeOSInterrupts pairs are allowed within this critical section.

The implementation should adapt this service to the target hardware providing a minimum overhead.
It is intended only to disable interrupts of category 2. However, if this is not possible in an efficient way
more interrupts may be disabled.

This function might be implemented using a global interrupt flag or an interrupt level register.
Particularities and Limitations
>  When using before StartOS, the function osInitialize must be called first to initialize the variables
which are used in the interrupt API.
>  The function must not be used within handlers of non-maskable interrupts as this can violate the
consistancy of internal variables.
2015, Vector Informatik GmbH
Version: 9.01
75 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

Functional Description
This call serves to enter critical sections in the code that are assigned to the resource referenced by
ResID. A critical section shall always be left using ReleaseResource.

Nested resource occupation is only allowed if the inner critical sections are completely executed within the
surrounding critical section (strictly stacked, Restrictions when using resources). Nested occupation of one
and the same resource is also forbidden!

It is recommended that corresponding calls to GetResource and ReleaseResource appear within the
same function.

It is not allowed to use services which are points of rescheduling for non preemptable tasks
(TerminateTask, ChainTask, Schedule and WaitEvent) in critical sections. Additionally, critical
sections are to be left before completion of an interrupt service routine.

Generally speaking, critical sections should be short.
The service may be called from an ISR and from task level.

Depending on the possibility to manipulate interrupt levels, this function may be used on interrupt level or
not and may be implemented differently.
If used on task level, the behavior and functionality is always the same (according to the specification).
Particularities and Limitations
>  --
Expected Caller Context
>  Task level or cat2 ISR
Table 6-15   GetResource
6.4.2.2
ReleaseResource
Prototype
StatusType ReleaseResource ( ResourceType ResID )
Parameter
ResID
Reference to resource
Return code
E_OK
No error
E_OS_ID
Resource ResID is invalid
E_OS_NOFUNC
Attempt to release a resource which is not occupied by any task or ISR, or
another resource shall be released before.
E_OS_ACCESS
Attempt to release a resource that has a lower ceiling priority than the
statically assigned priority of the calling task or interrupt routine.
2015, Vector Informatik GmbH
Version: 9.01
77 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Functional Description
ReleaseResource is the counterpart of GetResource and serves to leave critical sections in the code that
are assigned to the resource referenced by ResID.

For information on nesting conditions, see particularities of GetResource.

The service may be called from an ISR and from task level.

Depending on the possibility to manipulate interrupt levels, this function may be used on interrupt level or
not and may be implemented differently.
If used on task level, the behavior and functionality is always the same (according to the specification).
Particularities and Limitations
>  --
Expected Caller Context
>  Task level or cat2 ISR
Table 6-16   ReleaseResource
6.4.3
Execution Control
The affected functions are:
>  StartOS
>  ShutdownOS
The implementation specific behavior is of these functions is described in [4].
6.4.3.1
StartOS
Prototype
void StartOS ( AppModeType Mode )
Parameter
Mode
application mode
Return code
void
--
Functional Description
The user can call this system service to start the operating system in a specific mode.

Only allowed outside of the operating system, therefore implementation specific restrictions may apply.

After calling StartOS the program never returns to the call level of StartOS.
Particularities and Limitations
>  --
2015, Vector Informatik GmbH
Version: 9.01
78 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Expected Caller Context
>  C main function
Table 6-17   StartOS

6.4.3.2
ShutdownOS
Prototype
void ShutdownOS ( StatusType Error )
Parameter
Error
error occurred
Return code
void
--
Functional Description
The user can call this system service to abort the overall system (e.g. emergency off). The operating
system also calls this function internally, if it has reached an undefined internal state and is no longer ready
to run.

If a ShutdownHook is configured the hook routine ShutdownHook is always called (with Error as
argument) before shutting down the operating system.

If ShutdownHook returns, further behaviour of ShutdownOS is implementation specific.

In case of a system where OSEK OS and OSEKtime OS coexist, ShutdownHook has to return.

Error needs to be a valid error code supported by OSEK OS. In case of a system where OSEK OS and
OSEKtime OS coexist, Error might also be a value accepted by OSEKtime OS. In this case, if enabled by
an OSEKtime configuration parameter, OSEKtime OS will be shut down after OSEK OS shutdown.

After this service the operating system is shut down.
Allowed at task level, ISR level, in ErrorHook and StartupHook, and also called internally by the
operating system.
If the operating system calls ShutdownOS it never uses E_OK as the passed parameter value.

After the call of ShutdownHook MICROSAR OS disables all interrupts and will never return to the call
level. The ShutdownHook is called with disabled interrupts.
Particularities and Limitations
>  --
2015, Vector Informatik GmbH
Version: 9.01
79 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

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

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

Technical Reference MICROSAR OS SafeContext

6.5.1.4
ErrorHook
Prototype
void ErrorHook ( StatusType ErrorCode ) /* general error hook */
void ErrorHook_<App> ( StatusType ErrorCode ) /* appl. spec. error hook */
Parameter
ErrorCode
Error code of API which detected the error and called the error hook
Return code
void
--
Functional Description
The user may use the error number parameter to decide how to react on the error.

Additional error information is available in the error hook if the attributes USEGETSERVICEID and
USEPARAMETERACCESS are set to TRUE. This information can be accessed by access macros; for details
refer to the OSEK specification [3]. All possible access macros are supported by MICROSAR OS.

If EXTENDED_STATUS is enabled and ErrorInfoLevel is set to Modulnames, additional error
information is available in the ErrorHook. The variable osActiveTaskModule is a pointer to the module
name and the variable osActiveTaskLineNumber is the line number in the C module where the API
function was called. Inspecting these two variables allows the user to locate the source code that caused
the error message.

Particularities and Limitations
>  --
Call Context
>  interrupt or task context
>  ErrorHook is called every time an API function is called with wrong parameters or if the system detects
an error (e.g. stack overflow).
Table 6-22   ErrorHook
6.5.1.5
ShutdownHook
Prototype
void ShutdownHook ( StatusType ErrorCode ) /* general shutdown hook */
void ShutdownHook_<App> (StatusType ErrorCode) /* appl. spec. shutdown hook */
Parameter
ErrorCode
Error code of API that detected the error and called the shutdown hook, or the
parameter that was passed to ShutdownOS.
Return code
void
--
2015, Vector Informatik GmbH
Version: 9.01
82 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

6.5.4.1
Hooks for arrival
MICROSAR OS prvides hooks that allow an external tool to trace all activations of task as
well  as  further  arrivals  like  the  setting  of  an  event  or  the  release  of  a  semaphore  with
transfer to another task.
This shall allow the external tool to visualize the arrivals and to measure the time between
them in order to allow a schedulability analysis.
Mind that  schedulability analysis requires  the minimum time between arrivals while these
hooks only provide measured values.
6.5.4.1.1
OS_VTH_ACTIVATION
Prototype
OS_VTH_ACTIVATION( TaskId, DestCoreId, CallerCoreId)
Parameter
TaskId
Identifier of the task which is activated
DestCoreId
Identifier of the core on which the task is activated
CallerCoreId
Identifier of the core which performs the activation (has called ActivateTask,
has called TerminateTask or has performed an alarm/schedule table action to
activate a task)
Return code
-
-
Functional Description
This hook is called on the caller core when that core has successfully performed the activation of TaskId on
the destination core. On single core systems both core IDs are always identical.
Particularities and Limitations
>  The hook is expected to be implemented as a macro.
>  Reentrancy is possible on multicore systems with different caller core IDs
>  Call of any operating system API function is prohibited in this hook routine
Call context
>  The hook routine is called from within operating system API functions with interrupts disabled.
Table 6-28   OS_VTH_ACTIVATION
6.5.4.1.2
OS_VTH_SETEVENT
Prototype
OS_VTH_SETEVENT( TaskId, EventMask, StateChange, DestCoreId, CallerCoreId)
Parameter
TaskId
Identifier of the task which receives this event
EventMask
A bit mask with the events which shall be set
2015, Vector Informatik GmbH
Version: 9.01
86 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

StateChange
TRUE: The task state has changed from WAITING to READY
FALSE: The task state hasn’t changed
DestCoreId
Identifier of the core on which the task receives the event
CallerCoreId
Identifier of the core which performs the event setting (has called SetEvent or
performed an alarm/schedule table action to set an event)
Return code
-
-
Functional Description
This hook is called on the caller core when that core has successfully performed the event setting on the
destination core. On single core systems both core IDs are always identical.
Particularities and Limitations
>  The hook is expected to be implemented as a macro.
>  Reentrancy is possible on multicore systems with different caller core IDs
>  Call of any operating system API function is prohibited in this hook routine
Call context
>  The hook routine is called from within operating system API functions with interrupts disabled.
Table 6-29   OS_VTH_SETEVENT
6.5.4.1.3
OS_VTH_TRANSFER_SEMA
Prototype
OS_VTH_TRANSFER_SEMA( FromThreadId, ToTaskId, SemaId, DestCoreId, CallerCoreId)
Parameter
FromThreadId
Identifier of the thread (task; ISR) which releases the semaphore
ToTaskId
Identifier ot the task which receives the semaphore
SemaId
Identifier of the semaphore to be transferred
DestCoreId
Identifier of the core on which the task igets the semaphore
CallerCoreId
Identifier of the core which releases the semaphore
Return code
-
-
Functional Description
This hook is called on the caller core when that core has successfully performed release of the semaphore
while a task was waiting for that semaphore. On single core systems both core IDs are always identical.
2015, Vector Informatik GmbH
Version: 9.01
87 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

ToThreadReason
OS_VTHP_TASK_ACTIVATION: The thread is a task, which was activated.
OS_VTHP_ISR_START: The thread is an ISR, which will now start execution.
OS_VTHP_TASK_SETEVENT: The thread is a task, which has just received
an event it was waiting for. It resumes execution right behind the call of
WaitEvent.
OS_VTHP_GOTSEMA: The thread is a task, which has just got the
semaphore it was waiting for.
OS_VTHP_THREAD_RESUME: The thread is a task or ISR, which was
preempted before and becomes running again as all higher priority tasks and
ISRs do not run anymore.
CallerCoreId
Identifier of the core which performs the thread switch
Return code
-
-
Functional Description
This hook is called on the caller core when that core in case it performs a thread switch (from one task or
ISR to another task or ISR). On single core systems both core IDs are always identical.
Particularities and Limitations
>  The hook is expected to be implemented as a macro.
>  Reentrancy is possible on multicore systems with different caller core IDs
>  Call of any operating system API function is prohibited in this hook routine
Call context
>  The hook routine is called from within operating system internal functions with interrupts disabled.
Table 6-31   OS_VTH_SCHEDULE

6.5.4.3
Hooks for locking
MICROSAR  OS  provides  hooks,  which  allow  an  external  tool  to  trace  locks.  This  is
important  as  locking  times  of  tasks  and  ISRs  influence  the  exectution  of  other  tasks  and
ISRs.  The  kind  of  influence  is  different  for  different  locks  and  is  presented  below  in  the
functional description of the respective hooks.
Please keep in mind that measured times for locking may not reflect the worst case.
6.5.4.3.1
OS_VTH_GOT_RES
Prototype
OS_VTH_GOT_RES( ResId, CallerCoreId)
Parameter
ResId
Identifier of the resource which has been taken
CallerCoreId
Identifier of the core where GetResorce was called
2015, Vector Informatik GmbH
Version: 9.01
89 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

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

6.5.4.3.4
OS_VTH_GOT_SPINLOCK
Prototype
OS_VTH_GOT_SPINLOCK( SpinlockId, CallerCoreId)
Parameter
SpinlockId
Identifier of the spinlock which has been taken
CallerCoreId
Identifier of the core where GetSpinlock or TryToGetSpinlock were called
Return code
-
-
Functional Description
The OS calls this hook whenever a spinlock has successfully been taken. If the task or ISR was not
successful immediately (entered busy waiting state), this hook means that it leaves the busy waiting state.
From now on no other task or ISR may get the spinlock until the current task or ISR has released it.
2015, Vector Informatik GmbH
Version: 9.01
91 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Particularities and Limitations
>  The hook is expected to be implemented as a macro.
>  Reentrancy is possible on multicore systems with different caller core IDs
>  Call of any operating system API function is prohibited in this hook routine
>  The hook is not called for optimized spinlocks
>  The hook is not called for operating system internal spinlocks
>  The hook is called only on multicore operating system implementations
Call context
>  The hook routine is called from within operating system API functions with interrupts disabled.
Table 6-35   OS_VTH_GOT_SPINLOCK

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

Technical Reference MICROSAR OS SafeContext

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

6.5.4.3.7
OS_VTH_REL_SEMA
Prototype
OS_VTH_REL_SEMA( ThreadId, SemaId, CallerCoreId)
Parameter
ThreadId
Identifier of the task or ISR which has released the semaphore
SemaId
Identifier of the semaphore which has been released
CallerCoreId
Identifier of the core where ReleaseSemaphore was called
Return code
-
-
2015, Vector Informatik GmbH
Version: 9.01
93 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Functional Description
The OS calls this hook in the API function ReleaseSemaphore if the semaphore becomes free after the
call. If a task is currently waiting for the semaphore, the API function GetSemaphore calls
OS_VTH_TRANFER_SEMA instead, as described in chapter 6.5.4.1.3.
Particularities and Limitations
>  The hook is expected to be implemented as a macro.
>  Reentrancy is possible on multicore systems with different caller core IDs
>  Call of any operating system API function is prohibited in this hook routine
>  The semaphore feature is optional, so this macro may not be necessary on all implementations of
MICROSAR OS.
Call context
>  The hook routine is called from within operating system API functions with interrupts disabled.
Table 6-38   OS_VTH_REL_SEMA
6.5.4.3.8
OS_VTH_DISABLEDINT
Prototype
OS_VTH_DISABLEDINT( IntLockId, CallerCoreId)
Parameter
IntLockId
OS_VTHP_CAT2INTERRUPTS: Interrupts have been disabled by means of
the current interrupt level. That interrupt level has been changed in order to
disable all category 2 interrupts, which also prevents task switch and
alarm/schedule table management.
OS_VTHP_ALLINTERRUPTS: Interrupts have been disabled by means of the
global interrupt enable/disable flag. Additionally to the effects described above,
also category 1 interrupts are disabled.
CallerCoreId
Identifier of the core where interrupts are disabled
Return code
-
-
Functional Description
The OS calls this hook if the application has called an API function to disable interrupts. The parameter
IntLockId describes whether category 1 interrupts may still occur.
Mind that the two types of interrupt locking (as described by the IntLockId) are independent from each other
so that the hook may be called twice before the hook OS_VTH_ENABLEDINT is called, dependent on the
application.
Particularities and Limitations
>  The hook is expected to be implemented as a macro.
>  Reentrancy is possible on multicore systems with different caller core IDs
>  Call of any operating system API function is prohibited in this hook routine
>  The hook is not called for operating system internal interrupt locks
2015, Vector Informatik GmbH
Version: 9.01
94 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

without the possibility to overwrite private data of other applications. Non-trusted functions have no
access to the data on the callers stack.
6.6.2
API
Prototype
StatusType osCallNonTrustedFunction(NonTrustedFunctionIndexType FunctionIndex,
NonTrustedFunctionParameterRefType FunctionParams);
Parameter
FunctionIndex
Index of the function to be called.
FunctionParams
Pointer to the parameters for the function to be called. If no parameters are provided,
a NULL pointer has to be passed.
Return code
E_OK
No error
E_OS_SERVICEID  No function defined for this index
Functional Description
Executes the non-trusted function referenced by FunctionIndex and passes argument FunctionParams.
The non-trusted function must conform to the following C prototype:
void NONTRUSTED_<name of the non-trusted function(NonTrustedFunctionIndexType,
NonTrustedFunctionParameterRefType);
The arguments are the same as the arguments of CallNonTrustedFunction.
Particularities and Limitations
>  The non-trusted function is called in user mode with memory protection enabled
>  The function has memory access rights of the owner application
>  The function has the service protection rights of the owner application
Call context
>  Task, CAT2 ISR, trusted function, non-trusted function
Table 6-41 API osCallNonTrustedFunction

Note
Vector MICROSAR OS implementations offer the possibility of stub function generation
for trusted functions. This mechanism is not available for non-trusted functions.

6.7
MPU Access Checking API
MISCROSAR  OS  provides API,  which  returns  whether  the  caller  has  access  to  a  given
adderss.
Prototype
uint8 osCheckMPUAccess(uint8* DestinationAddress)
2015, Vector Informatik GmbH
Version: 9.01
96 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

Parameter
area
Identifier of peripheral regions to the read from
address
Address to be read from
Return code

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

Functional Description
>  Writes to either an 8 bit, or a 16 bit or a 32 bit value
>  The function performs accessing checks (whether the caller has accessing rights to the peripheral
region and whether the address to be read from is within the configured range of the peripheral region)
>  The error hook is raised in case of an error
>  A shutdown is not issued in case of an error
2015, Vector Informatik GmbH
Version: 9.01
98 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Particularities and Limitations
>  These functions may not be called from OS hooks
Call context
>  These functions may be called from Task context
>  These functions may be called from category 2 ISR context
>  These functions can be called with interrupts enabled or with interrupts disabled
Table 6-44   WritePeripheral API
6.8.3
Modifying functions
Prototype
void osModifyPeripheral8(osuint16 area, osuint32 address, osuint8 clearmask,
osuint8 setmask)
void osModifyPeripheral16(osuint16 area, osuint32 address, osuint16 clearmask,
osuint16 setmask)
void osModifyPeripheral32(osuint16 area, osuint32 address, osuint32 clearmask,
osuint32 setmask)
Parameter
area
Identifier of peripheral regions to the read from
address
Address to be modified
clearmask
Bitmask which is bitwise “ANDed” to “address”
setmask
Bitmask which is bitwise “ORed” to “address”
Return code
None

Functional Description
>  The function performs accessing checks (whether the caller has accessing rights to the peripheral
region and whether the address to be read from is within the configured range of the peripheral region)
>  The error hook is raised in case of an error
>  A shutdown is not issued in case of an error
>  After the access checks has passed first the “clearmask” is ANDed to “address” and afterwards the
“setmask” is ORed to it.
Particularities and Limitations
>  These functions may not be called from OS hooks
Call context
>  These functions may be called from Task context
>  These functions may be called from category 2 ISR context
>  These functions can be called with interrupts enabled or with interrupts disabled
Table 6-45   ModifyPeripheral API
2015, Vector Informatik GmbH
Version: 9.01
99 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

7  Configuration
Since  AUTOSAR  OS  3.0.0  specification,  XML  is  used  to  define  and  describe  an  OS
configuration.  However,  OIL  is  still  supported  as  an  alternative  description  language,
especially  if  the  OS  shall  be  used  stand-alone  without  any  other  AUTOSAR  software
modules.
All  OSEK  objects  and  their  attributes  have  to  be  defined  by  one  of  these  description
languages.
7.1
Configuration and generation process
AUTOSAR XML
Code
OIL
Configuration Tool
.xml
Generator
.oil
Configurator
OS source
.c
.c
Configuration
.c
Application
files
.h
.h
files
.h
files
Compile and Link
Executable

Figure 7-1
System overview of software parts
The figure above shows the complete configuration process of a MICROSAR OS. First all
OS  objects  have  to  be  defined.  This  can  be  done  either  by  an  AUTOSAR  XML
configuration tool or by the OIL Configurator (in OIL).
An  OIL or  XML  file  is the  base of  the  code generation process. After  code  generation  all
files  (OS  source  files,  application  files  and  generated  OS  configuration  files)  have  to  be
compiled and linked to an executable.
7.1.1
XML Configuration
A configuration which is based on XML must conform to the AUTOSAR XML schema[8].
To  edit  a  MICROSAR  OS  XML  configuration  the  DaVinci  Configurator  Pro  or  Base  of
Vector  Informatik  GmbH  can  be  used.  Other  tools  that  are  able  to  edit  AUTOSAR
configurations may also be used.
The XML file that the tool produces has to be passed to the code generator to generate the
configuration files.
2015, Vector Informatik GmbH
Version: 9.01
100 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

Caution
If a library version of the operating system is used, some attributes or attribute values
  are not available or predefined.
1.

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

Technical Reference MICROSAR OS SafeContext

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

>  XML: This attribute is placed in container
OsHooks
ERRORHOOK
OsErrorHook
TRUE
The ErrorHook is always called if an error
occurs in a MICROSAR OS SafeContext.

>  XML: This attribute is placed in container
OsHooks
SHUTDOWNHOOK  OsShutdownHook  TRUE
The ShutdownHook is always called at
system shutdown of a MICROSAR OS

SafeContext.
>  XML: This attribute is placed in container
OsHooks
PRETASKHOOK
OsPreTaskHook
FALSE
The PreTaskHook is not supported by
MICROSAR OS SafeContext. However, there is
a debug switch to turn it on during
development, see 6.5.1.2 and [9].
>  XML: This attribute is placed in container
OsHooks
2015, Vector Informatik GmbH
Version: 9.01
102 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

StackUsageMeasure OsStackUsageMe
TRUE,
If selected, the stacks are filled with an indicator
ment
asurement
value during StartOS. This allows measuring
FALSE,
the stack usage of tasks and ISRs. See also
AUTO
chapter 3.2.2.5. If AUTO is selected,
StackUsageMeasurement uses the same
setting as STACKMONITORING.
ErrorInfoLevel
OsOSErrorInfo
STANDARD
MICROSAR OS SafeContext will report
Level
standard OSEK error codes and unique error
numbers, but no additional information about
the error location.
OSInternalChecks
OsOSInternal
ADDITIONAL  MICROSAR OS SafeContext will always
Checks
perform all available runtime error checks.
Compiler
OsOSCompiler
Implementatio The compiler can be chosen. If there is only
n specific
one compiler this attribute is also set by default.

ORTIDebug Support  OsOSORTIDebug
TRUE
The OS generator always produces an ORTI.
Support

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

Technical Reference MICROSAR OS SafeContext

Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
ORTIDebugLevel
OsOSORTIDebug

MICROSAR OS SafeContext will always
Level
ORTI_22_Add support version 2.2 of the ORTI standard with
itional
all available features.
UserConfigurationV
OsOSUserConfigu
1...65535
Version number of the OS configuration. This
ersion
rationVersion
numeric value is not used by the OS, but
enables the user to track changes in the
configuration and validate the configuration
version actually used in the ECUC. Therefore, it
is suggested to increment this value each time
the OS configuration is modified.
ProtectionHook
OsOSProtection
SELECTED
MICROSAR OS SafeContext does not support
Reaction
HookReaction
forcible termination, thus requires this
parameter to be set to SELECTED.
See chapter 7.3.1.3 for information about the
sub-attributes and required values for
MICROSAR OS SafeContext.
Timing
OsOSTiming
TRUE
MICROSAR OS SafeContext will always
Measurement
Measurement
perform Timing measurement if delivered in

Scalability class SC4.

See chapter 7.3.1.4 for information about the
sub-attributes. Chapter 3.2.4.2 provides more
detailed information about configuration of
timing measurement.
TypeHeader Include OsOSTypeHeader TRUE,
If selected, the AUTOSAR type headers are
Include
included in the file os_cfg.h. This is included in
FALSE
the file os.h, which has to be included in all
source files that use API functions of
MICROSAR OS OSEK/AUTOSAR. The
AUTOSAR type headers are not necessary for
the usage of MICROSAR OS
OSEK/AUTOSAR, so it is safe to deselect this
attribute.
EnumeratedUnhandl OsOSEnumerated
TRUE,
Determines the handling of unassigned
edISRs
UnhandledISRs
interrupt sources. The default of this attribute is
FALSE
FALSE.
FALSE: This is the normal handling for
unassigned interrupt sources. If no interrupt
service routine is defined in OIL for an interrupt
source the corresponding interrupt vector will
be directed to one common unhandled
exception handler. This setting must be chosen
for the final application software.
TRUE: During application development, there
may be interrupts issued by unassigned
interrupt sources. In such case it could be a big
effort to determine the interrupt source. If this
attribute is set to TRUE the interrupt vector of
each unassigned interrupt source will be
directed to an unhandled exception routine. If
an unhandled exception occurs in that case, the
2015, Vector Informatik GmbH
Version: 9.01
104 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
interrupt source which causes this exception
can easily be determined by the variable
“osISRUnhandledException_Number“. The
corresponding interrupt source can be
distinguished by having a look into the interrupt
vector table which normally is generated to
intvect.c. This is a debug feature only and is not
permitted for the final application software
running on a MICROSAR OS SafeContext.
This feature is optional. Please refer 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 also 3.2.4.2 and 7.3.2.2.
>  If this attribute is set to TRUE, the subattribute GlobalConfig allows to globally override
theTask/ISR settings for Timing Protection and Timing Measurement:
Attribute Name
Values
Description
The default value is written in
OIL
XML
bold
GlobalConfig
OsGlobalConfig  ProtectAndMeasureAll  >  ProtectAndMeasureAll: The OS
AsSelected
provides timing measurement for all tasks
and ISRs regardless of their setting in the
OnlyMeasureAll
attribute TIMING_PROTECTION. Timing
protection however is provided only for all
tasks and ISRs that have the attribute
TIMING_PROTECTION set to TRUE. In
case the subattribute OnlyMeasure is set
to TRUE, that setting is ignored with a
warning. In case the attribute
TIMING_PROTECTION of a task or ISR is
set to FALSE, the OS provides no timing
protection.
>  AsSelected: The os provides timing
protection for a task or ISR if that is
configured, the attribute OnlyMeasure is
honored.
>  OnlyMeasureAll: The OS does not
provide timing protection for any Task or
ISR. Instead, it provides timing
2015, Vector Informatik GmbH
Version: 9.01
106 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Attribute Name
Values
Description
The default value is written in
OIL
XML
bold
measurement for all tasks and ISRs. In
case a task or ISR is configured to have
timing protection and has the subattribute
OnlyMeasure set to FALSE, that setting is
overridden with a warning.
Table 7-3
Sub-attributes of TimingMeasurement = TRUE
7.3.1.3
PeripheralRegion / OsOSPeripheralRegion
OIL Name
XML Name
Values  Description
StartAddress
OsOSStartAddress
-
Numeric value
Specifies the start address of the
peripheral region, which shall be
configured.
EndAddress
OsOSEndAddress
-
Numeric value
Specifies the end address of the
peripheral region, which shall be
configured.
Identifier
OsOSIdentifier
-
Area name
Must be a unique C-identifier, which can
be used in an application or BSW module
to access the peripheral region.
ACCESSING_
OsOSAccessingApplication  -
Grants access for this Peripheral Region.
APPLICATION
Multiple applications can be defined for
the same Peripheral Region.
Table 7-4
Sub-attributes of PeripheralRegion

Caution
The application is allowed to access memory addresses in the interval of StartAddress
  <= memory to be accessed <= EndAddress
The “EndAddress” value is included! All bytes of a peripheral access must fit into the
peripheral region.

7.3.2
Task
In the section Task all tasks and their attributes have to be defined.
Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
Name
Short-Name
-
Name of the task. This name is used as an
argument to all task-related OSEK API
2015, Vector Informatik GmbH
Version: 9.01
107 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
functions (e.g. ActivateTask). The task
function (or task body) has to be defined using
the C macro TASK() (which appends the suffix
func to the task name).
Comment
n.a.
--
Any comment.
TYPE
OsTaskTYPE
BASIC,
Type of the task: either BASIC or EXTENDED.
If set to AUTO, the type is calculated based on
EXTENDED,
the settings for events and the activation count.
AUTO
SCHEDULE
OsTaskSchedule
NON,
Scheduling policy for this task.
FULL
PRIORITY
OsTaskPriority
-
The priority of the task. A higher number
represents a higher priority (according to the
OSEK specification). The priority may be set
with gaps, though the gaps will be eliminated by
the code generator. Several tasks may be set
on the same priority level.
ACTIVATION
OsTaskActivation
-
The number of activations that are recorded in
the kernel while the task is possibly running or
delayed by higher priority tasks.
If ACTIVATION is set to a value bigger than 1,
no events can be received.
AUTOSTART
OsTaskAutostart
-
If set to TRUE, the task will be activated at
startup of the operating system. See chapter
7.3.2.1 for details about the sub-attributes.
EVENT
OsTaskEventRef
-
Reference to an event that is used by this task.
This attribute can only be used for extended
tasks (the attribute TYPE might be set to
EXTENDED or AUTO). This attribute can be used
multiply if more than one EVENT has to be
assigned.
If events are used with this task, the attribute
ACTIVATION cannot be bigger than 1.
RESOURCE
OsTaskResource
-
Reference to a resource that is occupied by this
Ref
task. This attribute can be used multiply if more
than one RESOURCE shall be assigned.
StackSize
OsTaskStackSize
-
Task stack size in byte. This attribute is only
available if the implementation supports
configurable task stacks.
TIMING_PROTECTI OsTaskTiming
-
Selects timing protection for the task. See
ON
Protection
chapter 7.3.2.2 for information about the sub-
attributes.
ACCESSING_
OsTaskAccessing
-
Defines access rights of an application for this
APPLICATION
Application
task. This attribute can be defined multiply, so
different applications might have access right to
the same task. This attribute can be used in
2015, Vector Informatik GmbH
Version: 9.01
108 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
scalability classes SC3 and SC4 only.
Table 7-5
Task attributes
7.3.2.1 AUTOSTART / OsTaskAutostart
>  OIL: If attribute set to FALSE:
No sub-attributes.
>  XML: If this container is not present:
AUTOSTART switched off.
>  If attribute is set to TRUE:
Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
APPMODE
OsTaskAppMode
-
Defines an application mode in which the task
Ref
is started in automatically. This attribute might
be defined several times to start the task in
different application modes.
Table 7-6
Sub-attributes of TASK->AUTOSTART=TRUE
7.3.2.2 TIMING_PROTECTION / OsTaskTimingProtection
Please  note  that  TIMING_PROTECTION  =  TRUE  can  only  be  selected  for  a  MICROSAR
OS SafeContext that has been delivered in Scalability class SC4.
>  If attribute is set to FALSE:
No sub-attributes.
>  If this attribute is not defined in XML:
Timing protection is switched off.
The value of this attribute might be overridden by the OS attribute TimingMeasurement,
as described in chapters 7.3.1.4 and 3.2.4.2
>  If attribute is set to TRUE:
Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
EXECUTION
OsTaskExecution
-
Defines the maximum execution time for the
BUDGET
Budget
task
TIMEFRAME
OsTaskTimeFrame  -
Defines the minimum time between task
activations
MAXOS
OsTaskOsInterrupt -
Maximum time OS interrupts are locked (by
2015, Vector Informatik GmbH
Version: 9.01
109 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
INTERRUPT
LockBudget
SuspendOSInterrupts)
LOCKTIME
MAXALL
OsTaskAllInterrupt
-
Maximum time ALL interrupts are locked (by
INTERRUPT
LockBudget
SuspendAllInterrupts or
LOCKTIME
DisableAllInterrupts)
LOCKINGTIME =
OsTaskResource
-
Is intended to be a container for sub-attributes
RESOURCELOCK
Lock
concerning the locking time of resources
LOCKINGTIME =
Inside the
-
The resource for which the locking time is
RESOURCELOCK/
container
specified.
RESOURCE
OsTaskResource
Lock:
OsTaskResource
LockResourceRef
LOCKINGTIME =
Inside the
-
Maximum time the resource is locked (by
RESOURCELOCK/
container
GetResource)
RESOURCELOCK
OsTaskResource
TIME
Lock:
OsTaskResource
LockBudget
OnlyMeasure
OsOnlyMeasure
TRUE
If set to FALSE, timing values of this task are
measured and violations against the configured
FALSE
values lead to a call of the ProtectionHook. If
set to TRUE, the timing values are still
measured but no call of the ProtectionHook
occurs.
Table 7-7
Sub-attributes of TASK-> TIMING_PROTECTION=TRUE
7.3.2.3
Task attributes concerning the timing analyzer
The following attributes have to be used when working with the timing analyzer tool. They
are used as input for this tool.
Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
ComputationTime
OsTask
-
The worst case execution time (in
ComputationTime
nanoseconds)
Period
OsTaskPeriod
-
The minimum activation period of the task (in
nanoseconds)
Deadline
OsTaskDeadline
-
The deadline of the task (in nanoseconds)
PRIORITY
OsTaskPriority
-
Priority of the task
UseResource
OsTaskUse
-
If set to TRUE the occupation of resources can
Occupation
Resource
be taken into consideration by the analysis tool.
Occupation
UseResource
OsTaskUse
-
Reference to the resource that is occupied.
Occupation=TRUE/
Resource
2015, Vector Informatik GmbH
Version: 9.01
110 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
Resource
Occupation
=TRUE/OsTask
Resource
UseResource
OsTaskUse
-
Maximum
resource
occupation
time
(in
Occupation=TRUE/
Resource
nanoseconds)
OccupationTime
Occupation
=TRUE/OsTask
OccupationTime
Table 7-8
Task attributes concerning the timing analyzer
7.3.3
Counter
The Counter container provides the following configuration attributes.
Attribute Name
Values
Description
The default
OIL
XML
value is written
in bold
Name
Short-Name
-
Name of the counter. This name is used
for the Alarm configuration.
Comment
n.a.

Any comment.
MINCYCLE
OsCounterMinCycle
-
This attribute specifies the minimum
allowed number of ticks for a cyclic
alarm linked to the counter.
MAXALLOWED
OsCounterMaxAllowedValue  -
Maximum value, which is reachable by
VALUE
the counter in counter ticks.
TICKSPERBASE
OsCounterTicksPerBase
-
This attribute specifies the number of
hardware timer ticks required to reach a
counterspecific unit. E.g. if you have a
periodic tick timer, which is running with
16MHz and it is configured to trigger a
timer interrupt with 1kHz. You have
16000 ticks per base.
TYPE
OsCounterType
SOFTWARE,  Defines the type of the counter.
Possible settings are SOFTWARE or
HARDWARE  HARDWARE. SOFTWARE means the
counter is incremented by means of the
system service IncrementCounter,
which has to be called by the
application. HARDWARE means the
counter is incremented by MICROSAR
OS internally.
DRIVER
OsDriver
-
This Container contains the information
who will drive the counter. This
configuration is only valid if the counter
has OsCounterType set to HARDWARE.
Sub-Attributes are hardware dependent
(see [5]).
2015, Vector Informatik GmbH
Version: 9.01
111 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Attribute Name
Values
Description
The default
OIL
XML
value is written
in bold
TIMECONSTANT
OsTimeConstant
-
This Container allows the user to define
constants, to be used e.g. to compare
physical time values with timer tick
values.
TIMECONSTANT/
OsConstName
-
The name, to be used by the application
CONSTNAME
to get OsTimeValue in counter units.
TIMECONSTANT/
OsTimeValue
-
This attribute contains the value of the
VALUE
constant in seconds.
SECONDSPERTICK  OsSecondsPerTick
-
This attribute contains the time of one
counter tick in seconds.
ACCESSING_
OsCounter Accessing
-
Defines access rights of an application
APPLICATION
Application
for this counter. This attribute can be
used multiply, so different applications
might have access rights to this counter.
This attribute can only be used in
scalability classes SC3 and SC4.
Table 7-9
Attributes of COUNTER

Figure 7-2
Relation between Physical Units, Counter Units and Driver Units

Note
If the OS supports High-Resolution, there is no periodic counter tick. The OS programs
  the driver to interrupt on demand (e.g. next Alarm, next Expiry Point, etc.). Therefore,
the counter has the same resolution as the driver (OsCounterTicksPerBase is 1).

7.3.4
Alarm
The action of an alarm has to be defined statically.
2015, Vector Informatik GmbH
Version: 9.01
112 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Attribute Name
Values
Description
The default value is
OIL
XML
written in bold
Name
Short-Name
-
Name of the alarm. This name is used as an
argument to all alarm related OSEK API
functions (e.g. SetRelAlarm).
Comment
n.a.
--
Any comment
COUNTER
OsAlarmCounter
Reference to the counter that drives the
Ref
alarm.
ACTION
OsAlarmAction
>  OIL:
See chapter 7.3.4.1 for more information.
SETEVENT,
ACTIVATETASK,
INCREMENTCOU
NTER

>  XML:
Choice container:
OsAlarmActivateT
ask,
OsAlarmIncrement
Counter,
OsAlarmSetEvent
AUTOSTART
OsAlarmAutostart  TRUE
>  OIL: If set to TRUE, the alarm will be
activated at startup of the system.
FALSE
>  XML: If attribute is present, the alarm will
be activated at startup of the system.
See chapter 7.3.4.2 for more information
about the sub-attributes and chapter 3.2.1.3
for more information about static alarms.
ACCESSING_
OsAlarmAccessin
Defines access rights of an application for
APPLICATION
gApplication
this alarm. This attribute can be used
multiply, so different applications might have
access rights to this alarm. This attribute can
be used in scalability classes SC3 and SC4
only.
Table 7-10   Attributes of ALARM
7.3.4.1 ACTION / OsAlarmAction
>  Attribute / ChoiceContainer is set to ACTIVATETASK / OsAlarmActivateTask:
2015, Vector Informatik GmbH
Version: 9.01
113 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

Event to be sent to the specified task
Ref
Table 7-12   Sub-attributes of ACTION = SETEVENT

>  Attribute / ChoiceContainer is set to INCREMENTCOUNTER /
OsAlarmIncrementCounter:
Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
COUNTER
OsAlarmIncrement -
Name of the counter to be incremented
CounterRef
Table 7-13   Sub-attributes of ACTION = ALARMCALLBACK

7.3.4.2 AUTOSTART / OsAlarmAutostart
>  OIL: This attribute can be either TRUE or FALSE. Depending on the value, there may be
different sub-attributes.
>  XML: This attribute can be present in the configuration or it can be omitted. In case this
container is present, it has sub-attributes, which are described below.
>  If AUTOSTART is set to TRUE (OIL) or if the container is present (XML):
Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
ALARMTIME
OsAlarmAlarmTim
-
The relative or absolute tick value when the
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 chapter 7.3.13.1 for more information
about the sub-attributes.
LOCAL_TO_
OsScheduleTable
-
Defines, whether the schedule table shall be
GLOBAL_TIME_SY
Sync
synchronized to a global time source. This
NCHRONIZATION
attribute is only supported in scalability class
SC4. Sub-attributes are described in chapter
7.3.13.6.
EXPIRY_POINT
OsScheduleTable
-
Defines an expiry point for this schedule table
ExpiryPoint
ACCESSING_
OsSchTbl
-
Defines access rights of an application for this
APPLICATION
Accessing
schedule table. This attribute can be used
Application
multiply, so different applications might have
access rights to this schedule table.
Table 7-25   Attributes of SCHEDULETABLE
7.3.12.1  AUTOSTART / OsScheduleTableAutostart
>  OIL: If this attribute is set to TRUE sub-attributes are visible and the schedule table is
auto started.
>  XML: If this container is present in the configuration the schedule table is auto started
2015, Vector Informatik GmbH
Version: 9.01
123 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
APPMODE
OsScheduleTable
-
Defines an application mode in which the
AppModeRef
schedule table is started automatically. This
attribute might be defined several times to start
the schedule table in several application
modes.
TYPE
OsScheduleTable
ABSOLUTE
Defines the method how the schedule table is
AutostartType
autostarted.
RELATIVE

SYNCHRON
TYPE=ABSOLUT/
OsScheduleTable
-
Absolute autostart tick value when the schedule
ABSVALUE
StartValue
table starts. Only used if the
OsScheduleTableAutostartType is
ABSOLUTE.
TYPE=RELATIVE/
OsScheduleTableS -
Relative offset in ticks when the schedule table
RELOFFSET
tartValue
starts. Only used if the
OsScheduleTableAutostartType is
RELATIVE.
Table 7-26   Sub-attributes for auto start of a schedule table

7.3.12.2  EXPIRY_POINT / OsScheduleTableExpiryPoint
An expiry point consists of a sequence of actions which are performed on a given tick time
of the schedule table. There are the following sub-attributes. Some of them also have sub-
attributes.

Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
ACTION
n.a.
>  OIL :
>  OIL: a list of actions
ACTIVATETA

SK
SETEVENT
ADJUST
OFFSET
OsScheduleTbl
-
Defines the time at which the defined actions
ExpPointOffset
occur in ticks based on the underlying counter.
The time is absolute to the start of the schedule
table and is given in ticks of the underlying
counter.
ACTION=ADJUST
OsScheduleTbl
-
>  XML: containers for holding the sub-
AdjustableExp
attributes in case of expiry point action
Point
ADJUST
ACTION
OsScheduleTable
-
>  XML: containers for holding the sub-
=ACTIVATETASK
TaskActivation
attributes in case of expiry point action
2015, Vector Informatik GmbH
Version: 9.01
124 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
ACTIVATESTASK
ACTION
OsScheduleTable
-
>  XML: containers for holding the sub-
=SETEVENT
EventSetting
attributes in case of expiry point action
SETEVENT
Table 7-27   Sub-attributes of expiry points
7.3.12.3  Expiry point action ADJUST
>  OIL: the following attributes are visible if the expiry point action is ADJUST
>  XML: the following attributes are located in the container
OsScheduleTblAdjustableExpPoint
Those attributes are only relevant in SC2 or SC4 if synchronization mechanisms are used.
Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
MAXLENGTHEN
OsScheduleTable

The maximum positive adjustment that can be
MaxLengthen
made to the expiry point offset to achieve
synchronizationin ticks based on the underlying
counter.
MAXSHORTEN
OsScheduleTable
-
The maximum negative adjustment that can be
MaxShorten
made to the expiry point offset to achieve
synchronization in ticks based on the underlying
counter.
Table 7-28   Sub-attributes of expiry point action ADJUST
7.3.12.4  Expiry point action ACTIVATETASK
Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
TASK
OsScheduleTable

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

If the action is declared as cyclic, this attribute
Time
CycleTime
holds the cycle time in counter ticks.
Table 7-29   Sub-attributes of expiry point action ACTIVATETASK
2015, Vector Informatik GmbH
Version: 9.01
125 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

7.3.12.5  Expiry point action SETEVENT
Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
TASK
OsScheduleTable
-
Task to which the event should be sent
SetEventTaskRef
EVENT
OsScheduleTable
-
Event to be sent to the specified task
SetEventRef
Cyclic
OsScheduleTable
TRUE,
>  OIL: If set to TRUE, this action is repeatedly
Cyclic
added to the schedule table.
FALSE
>  XML: This is a choice container. If set to
TRUE the action will be repeatedly added to
the schedule table.
The cycle time is located in a sub-attribute. See
chapter 3.2.6.3 for more details.
Cyclic=TRUE/Cycle
OsScheduleTable
-
If the action is declared as cyclic, this attribute
Time
CycleTime
holds the cycle time in counter ticks.
Table 7-30   Sub-attributes of expiry point action SETEVENT

7.3.12.6  LOCAL_TO_GLOBAL_TIME_SYNCHRONIZATION / OsScheduleTableSync
>  OIL: If set to TRUE, the synchronization of this schedule table is switched on and the
sub-attributes will be visible.
>  XML: If this attribute is present in the configuration the synchronization is used for this
schedule table.
This is only relevant in SC4.
Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
SYNC_STRATEGY
OsScheduleTbl
EXPLICIT
Defines the synchronization strategy of this
SyncStrategy
schedule table.
IMPLICIT
>  EXPLICIT: The schedule table is driven by
NONE
an OS counter, but processing needs to be
synchronized with a different counter, which
is not an OS counter object.
>  IMPLICIT: The counter driving the schedule
table is the counter with which
synchronisation is required
>  NONE: no synchronization is applied at all
SYNC_STRATEGY
OsScheduleTbl
-
Defines the synchronization tolerance (in ticks)
=EXPLICIT/PRECIS ExplicitPrecision
for this schedule table.
ION
If the absolute value of the deviation between
the schedule table counter and the
synchronization counter is smaller than this
2015, Vector Informatik GmbH
Version: 9.01
126 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

Attribute Name
Values
Description
The default value
OIL
XML
is written in bold
value schedule table state is set to
SCHEDULETABLE_RUN-
NING_AND_SYNCHRONOUS
Table 7-31 Sub-attributes SCHEDULETABLE-> LOCAL_TO_GLOBAL_TIME_SYNCHRONIZATION = TRUE

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

Technical Reference MICROSAR OS SafeContext

8  System Generation
This chapter describes the generation of the executable program. The definition of the OIL
/  XML  file  was  described  in  the  chapter  7  Configuration. The  general  steps programming
an  application  using  the  OSEK  operating  systems  are  illustrated  in  chapter  7.1
Configuration and generation process.
The dependencies on include files are described in chapter 5.2 Include Structure.
8.1
Code Generator
The code generator GENxxxx.EXE is delivered with the MICROSAR OS package (xxxx is
replaced by the hardware platform name). The code generator is implemented as a 32-bit
Windows console application and can be started from the OIL Configurator or directly from
the command line.
The  code  generator  has  different  command-line  options.  When  started  without  any
parameters, a list of all parameters is printed:
GENxxxx.EXE, Version: 6.00, Vector Informatik GmbH, 2012
Usage: GENxxxx.EXE [options] <Filename>
-s : print symboltable
-r <Filename> : write errors into file
-g : generate code
-d <Pathname> : path to write generated code
-m : prints list of known implementations
-i <Pathname>: include path for implementation files
-x : include path equals to generator exe path
-f <Filename>: read options and filename from command file
-y : perform a syntax check on OIL file

8.1.1
Generated Files
The code generator generates several files as described in chapter 5.1.2 Dynamic Files.
The files always have the same name. They are written to the generation path specified in
the OIL Configurator or with the command line option -d.
The '.c' modules have to be compiled and linked to the application.
8.1.2
Automatic Documentation
Automatic documentation of the generation process is provided by two list files, which are
generated  by  the  code  generator.  A  basic  list  file  is  generated  in  text  format.  The  more
detailed list file is generated in HTML format and can be used to publish a system design
in the internet or an intranet. Both files have the same name as the OIL file, i.e.:
>  <OILFileName>.lst   (basic list file in text format)
>  <OILFileName>.htm   (extended list file in HTML format)
The files are located in the directory of the OIL file.
2015, Vector Informatik GmbH
Version: 9.01
128 / 136
based on template version 4.3

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

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

Technical Reference MICROSAR OS SafeContext

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

osuint8 ucSysVersionMaj; /* version of operating system, Major   */
osuint8 ucSysVersionMin; /* version of operating system, Minor   */
osuint8 ucGenVersionMaj; /* version of code generator   */
osuint8 ucGenVersionMin; /* version of code generator   */
osuint8 ucSysVariant1; /* general variant coding 1    */
osuint8 ucSysVariant2; /* general variant coding 2    */
   osuint8 ucOrtiVariant; /* ORTI version and variant   */

… /* implementation specific variant coding */

} osVersionVariantCodingType;

The  structure  contains  the  version  of  the  operating  system  (major  and  minor  version
number),  the  version  of  the  code  generator  used  (major  and  minor  version  number),
information  about  the  OS  configuration  bit-encoded  into  8-bit  values  (ucSysVariantX)
and information about usage of the OSEK runtime interface (ORTI):
The  magic  number  is  defined  as  0xAFFEDEAD  and  may  be  used  for  an  identification  of
the version in hex or binary files.
Bits
Meaning
Possible Values
0..1
Conformance Class
3: ECC2
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