AN3423

Optimization

Doc ID 018987 Rev 2

5/13

2.3

Kernel customizations

Kernel customizations are further options that must be explicitly enabled in the

AUTOSAR OS configuration. They can provide further reductions in size and runtime.

However, many of them result in a kernel whose behavior is not strictly AUTOSAR

conformant, so these options must be used with care. In particular, extreme caution must be

exercised if customized error handling is selected in a system with protection features

enabled.

To use the Kernel Customizations, the OsAutosarCustomization container first must be

enabled. Then the options inside the container can be configured as desired.

●

OsErrorHandling [MINIMAL, AUTOSAR, FULL]

–

MINIMAL error handling means that API functions simply return an error code if an

error is detected. The error hook is not called. Internal errors are be detected but

not reported.

–

FULL error handling means that errors in APIs that do not return StatusType are

detected and handled. If OsErrorHookForVoidApi is also enabled the ErrorHook

appears. The default error action preforms, which could result in the caller being

killed.

–

AUTOSAR selects AUTOSAR-conformant error handling. Errors are detected but

no action is taken, so the API silently fails to do its job.

●

OsErrorHookForVoidApi [TRUE, FALSE]

–

TRUE causes the ErrorHook to be called when an error is detected in an API that

does not return StatusType. Needs OsErrorHandling=FULL.

●

OsErrorAction [TRUE, FALSE]

–

FALSE disables all special reaction to errors such as terminating tasks and

applications. The result is always to return an error code to the caller.

●

OsStrictServiceProtection [TRUE, FALSE]

–

Setting this to FALSE disables the very strict calling-checks required by

AUTOSAR. The implicit checks that are necessary for correct functioning of the

kernel (such as TerminateTask being called from a task) are still present, so this

does not affect the safety of the kernel. In the EB kernel, many APIs work correctly

when called from a context that is forbidden by AUTOSAR. ActivateTask and

SetEvent work correctly when called from an alarm callback or the ErrorHook.

●

OsInterruptLockingChecks [MINIMAL, EXTRACHECK,AUTOSAR]

–

MINIMAL means that the interrupt lock status is only checked when it affects the

kernel's operation (for example in GetResource and ReleaseResource).

EXTRACHECK is for compatibility with ProOSEK - the check is made whenever a

task switch is possible. AUTOSAR means full confirmance with the AUTOSAR

specification.