From ErikaWiki

Revision as of 10:41, 14 July 2014 by Francesco (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Multicore Autosar OS Support

ERIKA support multicore environments a way before than the first Autosar Multicore OS Release. So it happened that the historical ERIKA multicore support addresses some of the same requiremets of AUTOSAR Multicore OS with a completely different policy.

In detail all the primitives calls on other core, with traditional implementation, called Remote Notifications or RN, are done asynchronously with a fire and forget policy. This approach reduce latency to minimun, but, on the other hand, don't give the opportunity to check for errors in the call site.

Autosar, that take into account a way more code consistency and reliability than efficiency, requires that all the primitives calls on others cores are synchronous giving the opportunity to caller code to correctly handle errors.

To implements Autosar OS requirements a completly new multicore dispatcher have been implemented. This have been called ERIKA Autosar RPC (Remote Procedure Call).

Both traditional and the new dispatcher are available for Infineon AURIX. You can switch between them in OIL with the REMOTENOTIFICATION oil field.


Enable traditional Remote Notification dispatcher. It's the default value, so you don't need to write this.


Enable the new AUTOSAR Remote Procedure Call dispatcher.

Currently with the new RPC dispatcher you can execute on remote cores all the following primitives:

  • ActivateTask
  • ChainTask (Terminate local TASK but can schedule on remote core)
  • GetTaskState
  • SetEvent
  • GetAlarmBase
  • GetAlarm
  • SetRelAlarm
  • SetAbsAlarm
  • CancelAlarm
  • GetCounterValue
  • GetElapsedValue
  • ShutdownOS ( with new ShutdownAllCores API )

So in addition to TASK and EVENT primitives, the new muticore dispatcher support Counters and Alarms as required by Autosar specifications. Multicore awareness have been added to ShutdownOS to fulfill multicore AUTOSAR shutdown sequence.

New Multicore API

AUTOSAR expect a master/slaves multicore enviroment that naturally fit AURIX architecture. New API to start and stops slave cores specified in AUTOSAR v4.0 rev 3.0 have been added:

  • StartCore: This function starts the core specified by the parameter CoreID. The OUT parameter allows the caller to check whether the operation was successful or not. If a core is started by means of this function StartOS shall be called on the core. It is not supported to call this function after StartOS().
  • StartNonAutosarCore: The function starts the core specified by the parameter CoreID. It is allowed to call this function after StartOS(). The OUT parameter allows the caller to check whether the operation was successful or not. It is not allowed to call StartOS on cores activated by StartNonAutosarCore.
  • GetNumberOfActivatedCores: returns the number of cores activated by the StartCore function. This function might be a macro
  • GetCoreID: The function returns a unique core identifier.
  • ShutdownAllCores : After this service the OS on all AUTOSAR cores is shut down. Allowed at TASK level and ISR level and also internally by the OS. The function will never return. The function will force other cores into a shutdown.

New Spinlocks API

Support for AUTOSAR Spinlock API have been added. OIL implementation have been extended to support Spinlocks configuration.

There's two spinlocks behaviour modes: SINGLE and ORDERED. If SINGLE mode is configured a core get an error if, holding a spinlock, try to get access to another one. If ORDERED mode is configurated the core get this error only if it try to get spinlocks out of the order (see AUTOSAR documentation paragraph 7.9.29 The spinlock mechanism).

To configure spinlocks in SINGLE mode, just don't provide any order:

 SPINLOCK spinlock_1 {  };
 SPINLOCK spinlock_2 {  };
 SPINLOCK spinlock_3 {  };

To configure spinlocks in ORDERED mode provide a complete ordering:

 SPINLOCK spinlock_1 { NEXT_SPINLOCK=spinlock_2; };
 SPINLOCK spinlock_2 { NEXT_SPINLOCK=spinlock_3; };
 SPINLOCK spinlock_3 {  };

Provided AUTOSAR API to interact with Spinlocks are:

  • GetSpinlock : Tries to occupy a spin-lock variable. If the function returns, either the lock is successfully taken or an error has occurred. The spinlock mechanism is an active polling mechanism. The function does not cause a de-scheduling.
  • ReleaseSpinlock: Releases a spinlock variable that was occupied before. Before terminating a TASK all spinlock variables that have been occupied with GetSpinlock() shall be released. Before calling WaitEVENT all Spinlocks shall be released.
  • TryToGetSpinlock: Has the same functionality as GetSpinlock with the difference that if the spinlock is already occupied by a TASK on a different core the function sets the OUT parameter to TRYTOGETSPINLOCK_NOSUCCESS and returns with E_OK.

Two spinlocks implementation are provided. The trivial one that does not guarentee upper bond wait, but that can implement the try-to-get behaviour. And the queued one that prevent from starvation queuing requests, but cannot implement try-to-get behaviour (TryToGetSpinlock API is mapped into GetSpinlock).

To enable queued spinlocks just add to the OIL:


IMPORTANT: QUEUED spinlocks are not available for Erika on PowerPC.

Personal tools