In this article, we will look at the STARTUP phase of the ECU in detail. The figure below shows the startup sequence of an ECU.
Activities before EcuM_Init
Once the ECU starts the first step is MCU initialization. As soon as the microcontroller unit receives power, it jumps to the reset vector to run the boot loader code. The bootloader is where the basic controller is called hardware initialization, eg, memories, timers, etc. Next, all C code initialisation takes place. Stack memory is set up and all C variables are initialized. The call for the EcuM_Init () API then calls the ECU State Manager and it completes the rest of the startup sequences.
Activities in StartPreOS sequence
Once activated, ECUM will perform all steps as described IN in the figure below for the StartPreOS sequence. This is done to prepare the ECU to start the OS. This sequence is to be kept as short as possible. The StartPreOS sequence initializes all the basic software modules needed to start the OS. We will now study each step in the order in which they are called.
A – EcuM_AL_DriverInitZero – EcuM does not strictly define the initialization of drivers and hardware abstraction modules. However, it provides two callouts EcuM_AL_DriverInitZero and EcuM_AL_DriverInitOne to define init blocks 0 and 1. In addition to driver initialization, these blocks may also contain any preOS, low-level initialization codes.
B – EcuM_DeterminePbConfiguration – This callout returns a pointer to a fully initialized EcuM_ConfigType structure that contains post-build configuration data for all BSW module post-build configurations.
C – EcuM_AL_DriverInitOne – The ECU Manager module calls EcuM_AL_DriverInitOne in the preOS sequence. In addition to driver initialization, it also performs initialization sequences defined by the AUTOSAR MCU driver software specification.
Now let’s see the possible sequences of activities for init blocks 0 and 1. Depending on the hardware and software configuration, some of these BSW modules may be added or dropped and other sequences may also be possible. It all depends on the integrator.
Initialization Activity inside Init Block 0 (EcuM_AL_DriverInitZero)
- Default Error Tracer – DET module lets other modules report any development errors
- Diagnostic Event Manager – DEM module provides diagnostic services
- Driver to access post-build configuration data – These drivers do not depend on post-build configurations of the OS.
Initialization Activity inside Init Block 1 (EcuM_AL_DriverInitOne)
- MCU Driver – MCU driver provides services for basic initialization of the microcontroller unit like the startup code, also power down and reset functionality of the MCU.
- Port Driver – Handling of on-chip port pins. Initializes MCU port structure and assigns different functionality to different ports as required
- DIO Driver – It provides general purpose input / output functionality on the MCU I/O pins
- General Purpose Timer – GPT driver provides access and control of the hardware timers on the MCU.
- Watchdog Driver – It provides services for initialization, changing operation mode and triggering the watchdog timer.
- ADC Driver – Provides services to trigger the analog to digital conversion.
- ICU Driver – ICU driver provides services for demodulation of a PWM signal, counting pulses, measuring of frequency and duty cycle, generating simple interrupts and also wakeup interrupts.
- PWM Driver – Generates pulses with variable pulse width according to the set duty cycle and signal time period.
D – Get Reset Cause – The EcuM_GetValidatedWakeupEvents API returns wakeup events that have been validated.
E – Select the default shutdown target – These set the shutdown state in which the ECU will run after exiting the UP phase. It can be configured in one of these three, OFF, SLEEP and RESET.
F – Start OS – Here AUTOSAR OS starts its execution.
Activities in StartPostOS sequence
The second part of the startup sequence ie StartPostOS sequence is activated after a call to EcuM_StartupTwo. The figure below shows the sequence after postOS startup in ECU initialization.
Start BSW Scheduler (SchM) – SchM stands for BSW Scheduler. The job of this central module is to assemble and implement BSW modules in a well-defined and efficient manner using the means provided by the AUTOSAR OS. It uses the concept of ‘TASK’ in AutoSAR OS to trigger key processing of BSW modules. Thus since it uses the AUTOSAR OS, it is introduced in the PostOS initialization sequence.
Init BSW Scheduler – SchM_Init () is the function defined for initialization of the SchM module. It is used to allocate and initialize the resources used by the BSW Scheduler module. As discussed earlier, this AUTOSAR can call OS services to start OS ‘work’.
Init BSW Mode Manager (BswM) – BSWM is a module in AUTOSAR’s services layer that interacts with various basic and application software modules. BSW is responsible for two main functions, mode arbitration and mode control. It applies configurable rules and action lists to evaluate the conditions for switching ECU modes and implement the actions required to do so. The BswM_Init () API initializes the BSW Mode Manager module. BswM_Init needs to be initialized before starting the OS and SchM.
Thus, we have followed the entire initial sequence of electronic control units. For initialization of MCUs hardware and peripheral drivers, the ECU State Manager module is initialized. Furthermore, EcuM firstly performs a well-defined startup sequence to initialize the BSW Scheduler and finally the BSW Manager Module (BWSM) Autosar OS. Once SchM and BswM get up and running, we can finally start RTE and other BSW modules, and then COM stack. Finally, the use of SW-C run on this ECU, now up and running, can begin its operation using different layers and modules of the AUTOSAR architecture. While everything is running on EcuM, it manages different mode switches for the proper functioning of the ECU until it is eventually brought down to a shutdown state by powering off the ECU.3