Error handling, tracing and debugging

Hook routines

The OSEK operating system provides system specific hook routines to allow user-defined actions within the OS internal processing.

#!python

module HOOK
{
  imports
  {
    ex(ENTITY)
    pr(ASSIGN)
    pr(ISR2)
  }
  signature
  {
    [ Hook < Entity ]
  }
  axioms
  {
    vars X : Hook
    vars T : ISR2
    eq assign(X) > assign(T) = true .
  }
}

Those hook routines are

• called by the operating system, in a special context depending on the implementation of the operating system
• higher prior than all tasks
• not interrupted by category 2 interrupt routines.
• part of the operating system
• implemented by the user with user defined functionality
• standardised in interface, but not standardised in functionality (environment and behaviour of the hook routine itself), therefore usually hook routines are not portable
• are only allowed to use a subset of API functions.
• mandatory, but configurable via OIL

In the OSEK operating system hook routines may be used for:

• system start-up. The corresponding hook routine (StartupHook) is called after the operating system start-up and before the scheduler is running.
• system shutdown. The corresponding hook routine (ShutdownHook) is called when a system shutdown is requested by the application or by the operating system in case of a severe error.
• tracing or application dependent debugging purposes as well as user defined extensions of the context switch.
• error handling.

Each implementation of OSEK has to describe the conventions for the hook routines. If the application calls a not allowed API service in hook routines the behaviour is not defined. If an error is raised, the implementation should return an implementation specific error code. Most operating system services are not allowed for hook routines. This restriction is necessary to reduce system complexity.