0% found this document useful (0 votes)
430 views13 pages

Function Calls EcuM

This document describes function callouts for different phases of an ECU state manager including startup, run, wakeup handling, and sleep. It provides details on callouts for initializing drivers and determining configuration, requesting state transitions, handling wakeup events, and putting components to sleep.

Uploaded by

shanku kak
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
430 views13 pages

Function Calls EcuM

This document describes function callouts for different phases of an ECU state manager including startup, run, wakeup handling, and sleep. It provides details on callouts for initializing drivers and determining configuration, requesting state transitions, handling wakeup events, and putting components to sleep.

Uploaded by

shanku kak
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 13

FUNCTION CALLOUTS

A. STARTUP PHASE

1. void EcuM_Init (void): Initializes the ECU state manager and carries out the
startup procedure. The function will never return (it calls StartOS)

2. void EcuM_AL_SetProgrammableInterrupts (void): If the configuration


parameter EcuMSetProgrammableInterrupts is set to true, this callout is
executed and shall set the interrupts on ECUs with programmable interrupts.

3. void EcuM_AL_DriverInitZero (void): Initialize drivers that are needed to


determine PostBuild configuration. This callout shall provide driver
initialization and other hardware-related startup activities for loading the post-
build configuration data. Here only pre-compile and link-time configurable
modules may be used. This callout may only initialize BSW modules that do not
use post-build configuration parameters. The callout may not only contain
driver initialization but also any kind of preOS, low level initialization code.
Default Error Tracer should always be the first module to be initialized, so that other
modules can report development errors.

Diagnostic Event Manager Pre-Initialization

4. const EcuM_ConfigType* EcuM_DeterminePbConfiguration (void): This


callout should evaluate some condition, like port pin or NVRAM value, to
determine which post-build configuration shall be used in the remainder of the
startup process. It shall load this configuration data into a piece of memory
that is accessible by all BSW modules and shall return a pointer to the EcuM
post-build configuration as a base for all BSW module post-build
configurations. This callout is expected to return a pointer to a fully initialized
EcuM_ConfigType structure containing the post-build configuration data for
the ECU Manager module and all other BSW modules.
EcuM_ConfigType* : Pointer to the EcuM post-build configuration which
contains pointers to all other BSW module post-build configurations.

5. void EcuM_AL_DriverInitOne (void): This callout shall provide driver


initialization and other hardware-related startup activities in case of a power
on reset.
MCU Driver

Port Driver

General Purpose Timer

Watchdog Driver Internal watchdogs only, external ones may need SPI

Watchdog Manager

ADC Driver

ICU Driver

PWM Driver

OCU Driver

void EcuM_ErrorHook (uint16 reason): The ECU State Manager will call
the error hook if fatal errors occur. In this situation it is not possible to
continue processing and the ECU must be stopped. The integrator may
choose the modality how the ECU is stopped, i.e. reset, halt, restart, safe
state etc.

6. void EcuM_LoopDetection (void): If the configuration parameter


EcuMResetLoopDetection is set to true, this callout is called on every startup.

7. void EcuM_MainFunction (void): The purpose of this service is to


implement all activities of the ECU State Manager while the OS is up and
running.

8. void EcuM_StartupTwo (void): This function implements the STARTUP II


state. This function must be called from a task, which is started directly as a
consequence of StartOS. I.e. either it must be called from an autostart task or
the it must be called from a task, which is explicitly started. The OS offers
different mechanisms to activate a task on startup. Normally
EcuM_StartupTwo would be configured as an autostart task in the default
application mode. The integrator can configure the OS to activate the
EcuM_StartupTwo task by any mechanism, as long as it is started immediately
after StartOS is called. The task can also be activated from within another task
and this other task could be an autostart task. Starting EcuM_StartupTwo as an
autostart task is an implicit activation. The other mechanisms would be an
explicit activation.

9. void BswM_Init(const BswM_ConfigType*): BSW Mode manager

10. void SchM_Init(const SchM_ConfigType*): BSW Scheduler

B. RUN

1. Std_ReturnType EcuM_RequestRUN (EcuM_UserType user): Places a


request for the RUN state. Requests can be placed by every user made known
to the state manager at configuration time. Requests of EcuM_RequestRUN
cannot be nested, i.e. one user can only place one request but not more. An
implementation must track requests for each user known on the ECU. Run
requests are specific to the user. EcuMDevErrorDetect is enabled and there
are multiple requests by the same user detected by EcuM_RequestRUN the
function shall report ECUM_E_MULTIPLE_RUN_REQUESTS to Det.
Std_ReturnType

E_OK: The request was accepted by EcuM.

E_NOT_OK: The request was not accepted by EcuM


2. Std_ReturnType EcuM_ReleaseRUN (EcuM_UserType user): Releases a
RUN request previously done with a call to EcuM_RequestRUN. The service is
intended for implementing AUTOSAR ports. If EcuMDevErrorDetect is enabled
and EcuM_ReleaseRUN did not find a previous matching request for the
provided user the function shall report ECUM_E_MISMATCHED_RUN_RELEASE
to Det.
Std_ReturnType

E_OK: The request was accepted by EcuM.

E_NOT_OK: The request was not accepted by EcuM

3. Std_ReturnType EcuM_RequestPOST_RUN (EcuM_UserType user):


Places a request for the POST RUN state. Requests can be placed by every user
made known to the state manager at configuration time. Requests for RUN and
POST RUN must be tracked independently (in other words: two independent
variables). The service is intended for implementing AUTOSAR ports.
Std_ReturnType

E_OK: The request was accepted by EcuM.

E_NOT_OK: The request was not accepted by EcuM

4. Std_ReturnType EcuM_ReleasePOST_RUN (EcuM_UserType user):


Releases a POST RUN request previously done with a call to
EcuM_RequestPOST_RUN. The service is intended for implementing AUTOSAR
ports.
Std_ReturnType

E_OK: The request was accepted by EcuM.

E_NOT_OK: The request was not accepted by EcuM


C. WAKEUP HANDLING

1. EcuM_WakeupSourceType EcuM_GetPendingWakeupEvents (void): it


shall return wakeup events which have been set to pending but not yet
validated as bits set in a EcuM_WakeupSourceType bitmask. This function only
returns the wakeup events with status ECUM_WKSTATUS_PENDING.

2. EcuM_WakeupSourceType EcuM_GetValidatedWakeupEvents (void):


it shall return wakeup events which have been set to validated in the internal
validated events variable as bits set in a EcuM_WakeupSourceType bitmask.

3. EcuM_WakeupSourceType EcuM_GetExpiredWakeupEvents (void): it


shall return wakeup events which have been set to validated in the internal
expired events variable as bits set in a EcuM_WakeupSourceType bitmask.
Returns all events that have been set and for which validation has failed.
Events which do not need validation must never be reported by this function.

4. void EcuM_CheckWakeup (EcuM_WakeupSourceType wakeupSource):


This function can be called to check the given wakeup sources. It will pass the
argument to the integrator function EcuM_CheckWakeupHook. It can also be
called by the ISR of a wakeup source to set up the PLL and check other wakeup
sources that may be connected to the same interrupt.

5. void EcuM_ClearWakeupEvent (EcuM_WakeupSourceType sources): it


clears all pending events passed as a bit set in the sources in parameter
(EcuM_WakeupSourceType bitmask) from the internal pending wakeup events
variable, the internal validated events variable and the internal expired events
variable.

6. void EcuM_SetWakeupEvent ( EcuM_WakeupSourceType sources ): it


sets (OR-operation) all events passed as a bit set in the sources in parameter
(EcuM_WakeupSourceType bitmask) in the internal pending wakeup events
variable.

7. void EcuM_ValidateWakeupEvent (EcuM_WakeupSourceType sources):


After wakeup, the ECU State Manager will stop the process during the
WAKEUP VALIDATION state/sequence to wait for validation of the wakeup
event. This API service is used to indicate to the ECU Manager module that the
wakeup events indicated in the sources parameter have been validated. It sets
(OR-operation) all events passed as a bit set in the sources in parameter
(EcuM_WakeupSourceType bitmask) in the internal validated wakeup events
variable.

D. SLEEP PHASE

1. void EcuM_EnableWakeupSources (EcuM_WakeupSourceType


wakeupSource): The ECU Manager Module calls EcuM_EnableWakeupSource
to allow the system designer to notify wakeup sources defined in the
wakeupSource bitfield that SLEEP will be entered and to adjust their source
accordingly. The ECU Manager module invokes EcuM_EnableWakeupSources
in the GoSleep Sequence. The ECU Manager module shall derive the wakeup
sources to be enabled (and used as the wakeupSource parameter) from the
EcuMWakeupSource bitfield configured for the current sleep mode.
2. void EcuM_GenerateRamHash (void) / uint8 EcuM_CheckRamHash
(void): This callout is intended to provide a RAM integrity test. The goal of this
test is to ensure that after a long SLEEP duration, RAM contents is still
consistent. The check does not need to be exhaustive since this would
consume quite some processing time during wakeups. A well designed check
will execute quickly and detect RAM integrity defects with a sufficient
probability. This specification does not make any assumption about the
algorithm chosen for a particular ECU. The areas of RAM which will be checked
have to be chosen carefully. It depends on the check algorithm itself and the
task structure. Stack contents of the task executing the RAM check e.g. very
likely cannot be checked. It is good practice to have the hash generation and
checking in the same task and that this task is not pre-emptible and that there
is only little activity between hash generation and hash check. The RAM check
itself is provided by the system designer. In case of applied multi core and
existence of Satellite-EcuM(s): this API will be called by the Master-EcuM only.

3. void EcuM_SleepActivity (void): This callout is invoked periodically in all


reduced clock sleep modes. It is explicitly allowed to poll wakeup sources from
this callout and to call wakeup notification functions to indicate the end of the
sleep state to the ECU State Manager. The ECU Manager module invokes
EcuM_SleepActivity periodically during the Poll Sequence if the MCU is not
halted (i.e. clock is reduced).

4. void EcuM_DisableWakeupSources (EcuM_WakeupSourceType


wakeupSource): The ECU Manager Module calls EcuM_DisableWakeupSources
to set the wakeup source(s) defined in the wakeupSource bitfield so that they
are not able to wake the ECU up. The ECU Manager module invokes
EcuM_DisableWakeupSources in the Wakeup Restart Sequence. The ECU
Manager module shall derive the wakeup sources to be disabled (and used as
the wakeupSource parameter) from the internal pending events variable (NOT
operation). The integration code used for this callout must determine which
wakeup sources must be disabled.

5. void EcuM_StartCheckWakeup (EcuM_WakeupSourceType


WakeupSource): This API is called by the ECU Firmware to start the
CheckWakeupTimer for the corresponding WakeupSource. If
EcuMCheckWakeupTimeout > 0 the CheckWakeupTimer for the Wakeup
Source is started. If EcuMCheckWakeupTimeout <= 0 the API call is ignored by
the EcuM.

6. void EcuM_CheckWakeupHook (EcuM_WakeupSourceType


wakeupSource): This callout is called by the EcuM to poll a wakeup source.
Within the callout EcuM_CheckWakeupHook the following functions may be
called in the given order:

• Call EcuM_StartCheckWakeup with the given wakeup source to start


the CheckWakeupTimer. A running CheckWakeupTimer shall prevent a
shutdown of the ECU before the wakeup sources has been checked by
the corresponding driver module (e.g. CanTrcv) for a pending wakeup.

• Call <driver module>_CheckWakeup of the driver module (e.g.


CanTrcv) which is assigned to the given wakeup source

7. void EcuM_AL_DriverRestart (void): This callout shall provide driver


initialization and other hardware-related startup activities in the wakeup case.
The ECU Manager module invokes EcuM_AL_DriverRestart in the Wakeup
Restart Sequence. The ECU Manager module Configuration Tool shall generate
a default implementation of the EcuM_AL_DriverRestart callout from the
sequence of modules defined in the EcuMDriverRestartList configuration
container.
E. UP PHASE

1. void EcuM_StartWakeupSources (EcuM_WakeupSourceType


wakeupSource): The callout shall start the given wakeup source(s) so that they
are ready to perform wakeup validation.

2. void EcuM_CheckValidation (EcuM_WakeupSourceType wakeupSource):


This callout is called by the EcuM to validate a wakeup source. If a valid
wakeup has been detected, it shall be reported to EcuM via
EcuM_ValidateWakeupEvent().

3. void EcuM_StopWakeupSources (EcuM_WakeupSourceType


wakeupSource): The callout shall stop the given wakeup source(s) after
unsuccessful wakeup validation.

EcuM_WakeupSourceType defines a bitfield with 5 pre-defined


positions. The bitfield provides one bit for each wakeup source. In
WAKEUP, all bits cleared indicates that no wakeup source is known. In
STARTUP, all bits cleared indicates that no reason for restart or reset is
known. In this case, ECUM_WKSOURCE_RESET shall be assumed.
ECUM_WKSOURCE_POWER 0x01 Power cycle (bit 0)

ECUM_WKSOURCE_RESET (default) 0x02 Hardware reset. If the Mcu driver


cannot distinguish between a power cycle and a reset reason, then this shall be the
default wakeup source. (bit 1)
ECUM_WKSOURCE_ INTERNAL_RESET 0x04 Internal reset of Mcu. The
internal reset typically only resets the Mcu core but not peripherals or memory
controllers. The exact behavior is hardware specific. This source may also indicate an
unhandled exception. (bit 2)

ECUM_WKSOURCE_INTERNAL_WDG 0x08 Reset by internal watchdog (bit 3)

ECUM_WKSOURCE_EXTERNAL_WDG 0x10 Reset by external watchdog if


detection supported by hardware (bit 4)

*Additional wakeup sources (to the pre-defined sources) shall be assigned


individually to bitfield positions 5 to 31 by configuration. The bit assignment shall be done by
the configuration tool.

EcuM_SetWakeupEvent shall start the wakeup validation timeout timer


according to Wakeup Validation Timeout

EcuMValidationTimeout : The validation timeout (period for which the ECU State
Manager will wait for the validation of a wakeup event) can be defined for each wakeup
source independently. The timeout is specified in seconds. When the timeout is not
instantiated, there is no validation routine and the ECU Manager shall not validate the
wakeup source

F. SHUTDOWN PHASE

1. void EcuM_OnGoOffOne (void): This call allows the system designer to


notify that the GO OFF I state is about to be entered. The ECU Manager
module invokes EcuM_OnGoOffOne on entry to the OffPreOS Sequence.

2. void EcuM_OnGoOffTwo (void): This call allows the system designer to


notify that the GO OFF II state is about to be entered. The ECU Manager
module invokes EcuM_OnGoOffTwo on entry to the OffPostOS Sequence.
3. void EcuM_Shutdown (void): Typically called from the shutdown hook,
this function takes over execution control and will carry out GO OFF II
activities.

4. void EcuM_AL_SwitchOff (void): This callout shall take the code for
shutting off the power supply of the ECU. If the ECU cannot unpower itself, a
reset may be an adequate reaction. The ECU Manager module invokes
EcuM_AL_SwitchOff as the last activity in the OffPostOS Sequence. In some
cases of HW/SW concurrency, it may happen that during the power down in
EcuM_AL_SwitchOff (endless loop) some hardware (e.g. a CAN transceiver)
switches on the ECU again. In this case the ECU may be in a deadlock until the
hardware watchdog resets the ECU. To reduce the time until the hardware
watchdog fixes this deadlock, the integrator code in EcuM_AL_SwitchOff as last
action can limit the endless loop and after a sufficient long time reset the ECU
using Mcu_PerformReset().

5. void EcuM_AL_Reset (EcuM_ResetType reset): This callout shall take the


code for resetting the ECU.

6. Std_ReturnType EcuM_GoDownHaltPoll (EcuM_UserType UserID):


Instructs the ECU State Manager module to go into a SLEEP mode, RESET or
OFF depending on the previously selected shutdown target.
Std_ReturnType

 E_OK: If the ShutdownTargetType is SLEEP the call successfully returns, the


ECU has left the sleep again.
 E_NOT_OK: The request was not accepted by EcuM
 If the ShutdownTargetType is RESET or OFF this call will not return.

7. Std_ReturnType EcuM_SelectShutdownTarget
(EcuM_ShutdownTargetType shutdownTarget, EcuM_ShutdownModeType
shutdownMode): EcuM_SelectShutdownTarget selects the shutdown target
and is part of the ECU Manager Module port interface. The parameter mode of
the function EcuM_SelectShutdownTarget shall be the identifier of a sleep or
reset mode. The mode parameter shall only be used if the target parameter
equals ECUM_SHUTDOWN_TARGET_SLEEP or
ECUM_SHUTDOWN_TARGET_RESET. In all other cases, it shall be ignored. Only
sleep or reset modes that are defined at configuration time and are stored in
the EcuMCommonConfiguration container are allowed as parameter. The ECU
Manager module does not define any mechanism to resolve conflicts arising
from requests from different sources. The shutdown target is always the last
value set.

Std_ReturnType

E_OK: The new shutdown target was set

E_NOT_OK: The new shutdown target was not set

shutdownTarget: The selected shutdown target.

shutdownMode: The identifier of a sleep mode (if target is


ECUM_SHUTDOWN_TARGET_SLEEP) or a reset mechanism (if target is
ECUM_SHUTDOWN_TARGET_RESET) as defined by configuration.

8. Std_ReturnType EcuM_GetShutdownTarget
(EcuM_ShutdownTargetType* shutdownTarget, EcuM_ShutdownModeType*
shutdownMode): EcuM_GetShutdownTarget returns the currently selected
shutdown target as set by EcuM_SelectShutdownTarget.
EcuM_GetShutdownTarget is part of the ECU Manager Module port interface.

Std_ReturnType

E_OK: The service has succeeded

E_NOT_OK: The service has failed, e.g. due to NULL pointer being passed

shutdownTarget : One of these values is returned:


1. ECUM_SHUTDOWN_TARGET_SLEEP
2. ECUM_SHUTDOWN_TARGET_RESET
3. ECUM_ SHUTDOWN_TARGET_OFF

shutdownMode: If the out parameter "shutdownTarget" is ECUM_SHUTDOWN_


TARGET_SLEEP, sleepMode tells which of the configured sleep modes was actually
chosen. If "shutdownTarget" is ECUM_ SHUTDOWN_TARGET_RESET, sleepMode tells
which of the configured reset modes was actually chosen.

9. Std_ReturnType EcuM_GetLastShutdownTarget
(EcuM_ShutdownTargetType* shutdownTarget, EcuM_ShutdownModeType*
shutdownMode): EcuM_GetLastShutdownTarget returns the shutdown target
of the previous shutdown process. EcuM_GetLastShutdownTarget is part of
the ECU Manager Module port interface. EcuM_GetLastShutdownTarget shall
return the ECU state from which the last wakeup or power up occurred in the
shutdownTarget parameter. EcuM_GetLastShutdownTarget shall always return
the same value until the next shutdown. The EcuM_GetLastShutdownTarget
function is intended primarily for use in the ECU STARTUP or RUN states. To
simplify implementation, it is acceptable if the value is set in late shutdown
phase for use during the next startup.

You might also like