AUTOSAR ECU Startup Sequence: From Reset Handler to Application

When an automotive ECU receives power, its application software does not begin running immediately. The microcontroller must complete its startup process, establish a working C runtime, initialize essential software modules, start the operating system, and prepare communication between the application and Basic Software.

This process is known as the AUTOSAR ECU startup sequence. Understanding it is essential for embedded software developers, AUTOSAR integrators, and ECU testing engineers. A configuration error in one stage can prevent the ECU from reaching normal application operation.

Consider an automotive ECU responsible for monitoring a sensor and transmitting information over CAN. The application may contain a runnable that reads the sensor every 10 milliseconds. But before that runnable executes, the ECU needs a valid clock configuration, memory initialization, operating system scheduling, appropriate drivers, and a functioning Runtime Environment.

In this article, we will follow the complete AUTOSAR ECU startup sequence from processor reset to the execution of application software. The explanation focuses on AUTOSAR Classic Platform R21-11 and a typical Arm Cortex-M ECU. The precise implementation varies with the microcontroller, AUTOSAR stack, software configuration, and hardware architecture.

1. What Is the AUTOSAR ECU Startup Sequence?

The AUTOSAR ECU startup sequence is the coordinated process that prepares an electronic control unit to execute its configured software after reset or power-up.

It involves several software layers:

• Processor startup code: Establishes the execution environment.
• ECU State Manager (EcuM): Coordinates early startup and ECU lifecycle activities.
• Microcontroller Abstraction Layer (MCAL): Provides hardware-specific driver interfaces.
• AUTOSAR Operating System: Manages tasks, priorities, timing, and scheduling.
• BSW Mode Manager (BswM): Evaluates configured conditions and executes mode-dependent actions.
• Runtime Environment (RTE): Connects application software components with each other and with services.
• Software Components (SWCs): Execute the vehicle application’s functional behavior.

Each layer has specific dependencies. For example, an application runnable cannot safely use an uninitialized communication service. Similarly, a task may be configured correctly but never execute if the operating system or its activation mechanism is not running.

That is why startup is not simply a list of function calls. It is a dependency-driven process.

2. AUTOSAR ECU Startup Sequence: The Nine Main Stages

The following table gives a practical overview of the AUTOSAR boot sequence.

Stage	Activity	Purpose
1	Hardware reset	Establish the processor reset state
2	Reset handler	Enter the startup code
3	C runtime initialization	Prepare memory and execution
4	EcuM initialization	Start ECU management
5	Pre-OS initialization	Prepare essential drivers and OS dependencies
6	AUTOSAR OS startup	Enable configured task scheduling
7	Post-OS and BswM initialization	Prepare mode management
8	BSW and RTE startup	Prepare services and software component interfaces
9	Application runnable execution	Execute configured application functionality

This is a conceptual nine-stage explanation, not a mandatory nine-function AUTOSAR API sequence. Some operations overlap or differ between ECU configurations.

3. Stage One: Hardware Reset and the Interrupt Vector Table

The process begins when the microcontroller resets. A reset may result from applying power, a watchdog event, a software reset request, or another device-specific condition.

On a typical Arm Cortex-M microcontroller, the processor uses the interrupt vector table to establish its initial execution context.

The first two vector table entries are especially important:

• Offset 0x00: Initial Main Stack Pointer value.
• Offset 0x04: Reset handler address.

The processor loads the initial stack pointer and begins executing the reset handler. Other vector entries contain addresses for exceptions and peripheral interrupt handlers.

The vector table must be located where the processor expects it at reset, accounting for the device’s memory mapping and boot configuration.

What if the ECU contains a bootloader?

Some automotive ECUs execute a bootloader before entering the AUTOSAR application.

A bootloader may check the application image, determine whether a programming request is pending, or transfer execution to the application.

When control transfers to an application at a different flash address, the bootloader must establish the execution context required by the target architecture. Depending on the device, this can include configuring the vector table base, preparing the stack pointer, and transferring control to the application’s reset entry point.

Important: The bootloader is not a mandatory AUTOSAR Classic module. An ECU can start its AUTOSAR application without a separate application-level bootloader.

For a detailed introduction to firmware startup and update mechanisms, see the Embedded Bootloader Development Course from PiEST Systems.

4. Stage Two: Reset Handler and C Runtime Initialization

The reset handler is the first software entry point executed after the processor enters the application startup path.

Its exact implementation depends on the compiler, MCU vendor, linker script, and runtime library.

Typical responsibilities include:

• Establishing essential processor configuration.
• Executing early system initialization.
• Copying initialized variables from their load image into RAM.
• Clearing zero-initialized memory.
• Preparing runtime facilities required by the application.
• Transferring control to the application’s main entry point.

For example, an initialized variable stored in the .data section needs its initial value copied into RAM before application code uses it. Variables in the .bss section normally require zero initialization.

Startup implementations may perform these operations in different orders. In Arm CMSIS examples, the reset handler can call SystemInit() before transferring control to runtime initialization code.

By the time the AUTOSAR ECU State Manager is called, the required C initialization and minimal processor setup must already be complete.

Why is this stage important?

Suppose an ECU configuration pointer is stored in RAM. If the relevant initialization has not completed, subsequent software may read an invalid address.

The result can be a processor fault, unexpected reset, or failure before the first application task begins.

For this reason, ECU startup debugging should begin at the reset handler rather than assuming the problem exists inside AUTOSAR.

5. Stage Three: AUTOSAR EcuM Initialization

After the low-level runtime is prepared, the AUTOSAR application typically calls EcuM_Init().

AUTOSAR EcuM initialization is responsible for establishing the initial ECU management environment and carrying out the specified early startup activities.

In the AUTOSAR Classic R21-11 flexible ECU State Manager architecture, EcuM performs the essential preparation needed to start the operating system and mode management facilities.

The ECU State Manager also deals with information related to ECU reset, wakeup handling, configuration consistency, and lifecycle coordination.

The exact activities depend on the configured ECU and its integration code.

What does EcuM initialize?

EcuM does not indiscriminately initialize every Basic Software module at the same moment.

Instead, its configured initialization callouts establish the components required before the operating system starts. Other modules can be initialized later under BswM control.

This separation allows the system integrator to respect dependencies and avoid unnecessary work during the earliest startup phase.

For example, an MCU driver may need to establish a clock configuration before a peripheral driver can operate correctly.

Similarly, a communication stack may depend on several lower-level modules and should only be initialized when its prerequisites are ready.

6. Stage Four: AUTOSAR BSW Initialization Before the OS

The next important part of the AUTOSAR boot sequence is the pre-OS initialization phase.

In AUTOSAR R21-11, EcuM provides integration callouts such as:

• EcuM_AL_DriverInitZero()
• EcuM_AL_DriverInitOne()

These callouts support the configured initialization of early software and hardware dependencies.

Depending on the ECU, this may include MCU configuration, essential timing facilities, driver preparation, and other activities necessary before starting the OS.

Configuration consistency checks and reset-reason handling also belong to the startup responsibilities described by the EcuM specification.

Why not initialize all modules immediately?

Consider a CAN communication system.

The CAN driver depends on the relevant MCU and peripheral configuration. Higher communication modules such as CanIf and PduR depend on their underlying interfaces and configuration being available.

Initializing a dependent module too early can lead to incorrect state, rejected operations, or undefined application behavior.

AUTOSAR BSW initialization must therefore follow the dependencies established by the hardware design and ECU configuration.

The official standard explicitly allows driver initialization to occur at different stages, depending on module requirements and integration choices.

7. Stage Five: AUTOSAR OS Startup

Once the required pre-OS activities are complete, EcuM calls the operating system startup interface.

In AUTOSAR Classic, the relevant service is StartOS().

The AUTOSAR OS startup process prepares the configured operating system environment. Depending on the implementation and configuration, this includes internal scheduler initialization, startup hooks, and activation of autostart tasks.

After StartOS() transfers control to the OS, the normal ECU startup procedure continues through configured task execution.

What is an autostart task?

An autostart task is configured to become active automatically when the OS starts in the applicable application mode.

A designated startup task can perform the next stage of AUTOSAR initialization.

The AUTOSAR R21-11 EcuM startup sequence shows a BSW task calling EcuM_StartupTwo() after the operating system has started.

That task allows EcuM to perform the required post-OS activities.

The initialization task and the application tasks are not necessarily the same tasks. Application scheduling follows the generated OS and RTE configuration.

8. Stage Six: Post-OS Initialization and BswM

Following OS startup, the configured startup task invokes EcuM_StartupTwo().

This begins the post-OS part of the startup sequence.

The ECU must now establish the mechanisms needed for Basic Software scheduling and mode management.

The R21-11 specification describes initialization activities involving the BSW Scheduler (SchM) and the Basic Software Mode Manager (BswM).

What is the difference between EcuM and BswM?

EcuM provides essential ECU lifecycle functions, startup preparation, and coordination of shutdown and wakeup activities.

BswM evaluates configured mode requests and conditions, then executes action lists defined by the ECU integrator.

For example, BswM may coordinate further module initialization, communication permissions, or transitions between operational modes.

This distinction is important because flexible EcuM does not itself dictate every later initialization step.

Once BswM is operational, configured rules can control the remaining sequence according to the system’s requirements.

9. Stage Seven: Remaining AUTOSAR BSW Initialization

After mode management becomes available, additional AUTOSAR BSW initialization can take place.

Depending on the ECU, these modules may include:

• NvM: Nonvolatile memory management.
• Dem: Diagnostic event management.
• Dcm: Diagnostic communication management.
• Can: CAN controller driver.
• CanIf: CAN interface.
• PduR: Protocol Data Unit Router.
• Com: Signal and I-PDU communication processing.
• ComM: Communication mode management.

Not every ECU contains every listed module. A simple sensor controller may require fewer communication services than a gateway or diagnostic controller.

Initialization order is also configuration-dependent.

For example, a communication stack should only be enabled when its required controller, interface, routing, and mode-management dependencies are established.

Some systems also retrieve stored configuration or application data from nonvolatile memory before enabling dependent functionality.

Consequently, AUTOSAR BSW initialization should be reviewed as a configured dependency graph rather than a universal sequence copied from another ECU project.

10. Stage Eight: AUTOSAR RTE Startup

The Runtime Environment connects AUTOSAR software components through generated interfaces.

It handles configured communication mechanisms between application components and their supporting services.

Once the necessary prerequisites are available, the ECU integration workflow starts the RTE using the appropriate startup mechanism.

The AUTOSAR RTE specification defines Rte_Start() and the behavior of runnable activation events.

During AUTOSAR RTE startup, the system prepares application communication and initialization behavior according to the generated configuration.

Does Rte_Start immediately execute every runnable?

No. Different runnable entities can have different activation conditions.

An application initialization runnable may be associated with an InitEvent, while a periodic runnable may be associated with a TimingEvent.

The AUTOSAR R21-11 RTE specification defines the activation of initialization runnables and the scheduling behavior associated with configured RTE events.

Some initialization runnables may execute through an OS task. Others may be grouped into RTE initialization batches.

The actual execution order depends on the generated task mapping, event configuration, and initialization scheduling.

This means that successful Rte_Start() execution does not automatically prove every application function is operating correctly.

11. Stage Nine: The First Application Runnable Executes

At this stage, the ECU has reached the point where its configured application behavior can execute.

Consider an AUTOSAR software component named SensorMonitorSWC.

Its purpose is to read a sensor signal, evaluate the value, and provide information to another software component.

A typical runnable might follow this logical sequence:

1. The configured OS task is activated.
2. The generated RTE scheduling code invokes the runnable.
3. The runnable reads an input using an RTE API.
4. The application processes the input.
5. The result is written through an RTE interface.
6. The task continues or completes according to its configuration.

For a periodically triggered runnable, the event and task mapping determine when the logic executes.

Application components should use their generated RTE interfaces to interact with other SWCs and configured services. This helps maintain separation between application behavior and Basic Software implementation.

The first successful runnable execution is an important milestone in the AUTOSAR ECU startup sequence. It confirms that execution has progressed from processor startup to scheduled application behavior.

12. Example: Simplified AUTOSAR ECU Startup Flow

The following example illustrates the major transitions on a single-core ECU. It is a conceptual representation, not source code to paste into a production ECU.

Power On / Reset
        |
        v
MCU Vector Table
        |
        v
Reset_Handler
        |
        v
C Runtime Initialization
        |
        v
main()
        |
        v
EcuM_Init()
        |
        +-- Pre-OS Driver Initialization
        |
        v
StartOS()
        |
        v
Autostart BSW Task
        |
        v
EcuM_StartupTwo()
        |
        v
SchM and BswM Initialization
        |
        v
Configured BSW Initialization
        |
        v
Rte_Start()
        |
        v
Configured RTE Events / OS Tasks
        |
        v
Application SWC Runnables

The exact order of some later operations is controlled by ECU configuration. In particular, BswM rules may govern module initialization, mode changes, and RTE startup.

13. Common AUTOSAR ECU Startup Problems

Most startup failures can be narrowed down by identifying the last stage that executed successfully.

Symptom	Possible cause	What to check
ECU faults immediately after reset	Invalid stack pointer, vector table, or memory initialization	Reset handler, linker map and memory layout
Startup stops before StartOS	Driver initialization or configuration error	EcuM callouts and MCU initialization
OS starts but startup task does not execute	Incorrect OS task or application mode configuration	Autostart settings and task activation
BswM actions do not execute	Incorrect mode requests or rule configuration	BswM initialization, rules and action lists
RTE does not start	Missing prerequisites or integration errors	BSW initialization and Rte_Start conditions
Application runnable never executes	Incorrect event mapping or task activation	RTE events, generated task mappings and OS scheduling
CAN communication is unavailable	Communication modules or controller modes not ready	MCAL, CanIf, ComM, routing and controller state

Practical debugging method

Start by placing breakpoints at the earliest available software entry points.

Trace execution through Reset_Handler, the runtime entry, EcuM_Init(), StartOS(), and the post-OS startup task.

Then examine BswM initialization, configured action execution, Rte_Start(), and the first application runnable.

If the ECU resets unexpectedly, inspect reset-reason information and fault status registers before that evidence is overwritten.

Use trace instrumentation when breakpoints would interfere with timing-sensitive startup behavior.

For repeatable tests, record the expected initialization milestones and verify the observed execution order against the generated ECU configuration.

14. Why Understanding AUTOSAR Startup Matters

Engineers often focus on application logic because that is where vehicle functionality is implemented. However, many difficult integration problems occur before the application starts.

Understanding the AUTOSAR ECU startup sequence helps engineers:

• Identify failures during processor and runtime initialization.
• Configure EcuM and BswM more accurately.
• Understand OS task activation and scheduling dependencies.
• Investigate driver initialization failures.
• Debug RTE startup and missing application runnable execution.
• Plan more effective ECU integration and validation tests.

These skills are particularly relevant to automotive ECU software development, AUTOSAR configuration, ECU bootloaders, and Hardware-in-the-Loop testing.

15. Frequently Asked Questions

16. Conclusion: Understanding the AUTOSAR ECU Startup Sequence

The AUTOSAR ECU startup sequence is a controlled progression from processor reset to application execution.

The reset handler prepares the execution environment. EcuM coordinates essential early initialization. The AUTOSAR OS enables task scheduling, BswM manages configured startup actions, and the RTE prepares communication and runnable activation for application software components.

The most important engineering lesson is that startup order depends on both standardized interfaces and ECU-specific configuration. A reliable application needs more than correct software logic. Every underlying initialization dependency must also be satisfied.

Understanding this complete sequence makes it easier to configure AUTOSAR stacks, investigate ECU startup failures, and validate embedded automotive software.

Explore AUTOSAR and Embedded Engineering at PiEST Systems

PiEST Systems offers technical training covering embedded systems, AUTOSAR architecture, ECU software development, debugging, and automotive testing.

Engineers who want to explore these topics further can review our AUTOSAR Training Course, browse the Embedded Systems Training Programs, or contact PiEST Systems to discuss a suitable learning path.

Technical References

• AUTOSAR Classic R21-11: Specification of ECU State Manager
• AUTOSAR Classic R21-11: Specification of RTE Software
• Arm CMSIS-Core: Cortex-M Startup File
• AUTOSAR: Guide to Mode Management