Summary

The Start-up Sequence of the Starter Kit is based off of the Start-up  Sequence defined in the EcuM Autosar Specification. This application note runs you through the Start-up sequence as configured within the ETAS Starter Kit, this will vary slightly between targets due to hardware specific code but the sequence will remain the same. The Starter Kit that this specific application note is based upon is the RH850. 

1. Hardware Reset

The first stage of the Start-up  is jumping from the reset vector on the micro, through the micro specific Start-up  code. This typically involves initializing the stack pointer and preparing the memory. This code will eventually result in a Jump to the Main code from the application. 

The first step into the application is at EcuM_Init. 

2. Initialize the OS

One of the first things done in the EcuM_Init is the call to EcuM_AL_SetProgrammableInterrupts. This call can be enabled/disabled in the  configuration here:

This step is critical because in here Os_InitializeVectorTable() is called. This is an OS api that is responsible for preparing the Micro for the Os to run, and for interrupts to be activated. Without this call, ISRs and the OS will not run properly. 

General case for Os_InitializeVectorTable

Shown above is the use case for the RH850 port, but In general Os_InitializeVectorTable could be called once in one of two places:

• In non-Autosar systems it should be called in Os_Main()
• In Autosar systems it should be called through the EcuM

However, if it were to be configured to be called in both places and hence called twice in succession, it would just overwrite the initialisation with itself, so if it is the case where the vector tables had been configured to be initialised twice the implications would be limited. (As long as it’s done before the Os is started.)

3. Driver Initialization

The next stage in EcuM_Init is the Driver Init Zero and Driver Init One calls. These are some of the  first init calls that can be configured in the basic software. These init lists are intended to be use to bring up the MCAL and the lowest level complex device drivers.

The configuration can be found in Isoalr B here:

The generated code is here:

In general every module will take a pointer to an object containing the configuration. This may not be the case for certain MCAL modules in certain targets which are none AUTOSAR compliant. Please refer to the generated code / documentation from your hardware provider.

EcuM Startup Duration

If you want to use the function EcuM_GetTicks(); then you can get add it by setting the related configuration parameter to true.

This function is automatically generated at the start and end of every driver initalisation list and will be called if EcuMRbStartupDuration is true.

Additionally, you must be careful to integrate the function  EcuM_GetTicks to be mapped to a timer that has already started. For example there is no point making the EcuM_GetTicks() function return the value of the timer that is intialised by the Mcu as you can see that the Mcu will not be initialised until after the call to EcuM_GetTicks. It should be the integrator's responsibility that this works sensibly, should they wish to use EcuM_GetTicks.

4. Starting the OS

The last step in the EcuM_Init is to actually start the OS. 

Starting the OS here puts the micro into a while loop. 

Here the OS will sit in a while loop performing the Os_Cbk_Idle, which always returns TRUE.  This intentionally creates a while(1) condition. The Os sits here waiting for Tasks/ISRs to be activated/triggered. Note this important distinction. The Os has been started, but the Starter Kit uses a schedule table and the Schedule table has not been started yet. At this point in the sequence, the OS is activated but periodic Tasks are not being called.

The call to Start the OS will also trigger any Os components that are configured as Auto Start. In the Starter Kit, the InitTask is the only task configured as Auto Start:

The init task is not part of the Schedule Table, and thus is only activated once on Start-up.

Starting the OS in a muti-core system

For multicore applications, all non-master cores should initially start halted. For example on the RH850, Os_AwaitStartup is called on any non-master core.

The Os will then bring them out of sleep itself. When they are started, they will each jump to Os_Main and then need to call EcuM_Init.

1. The Os will call Os_Cbk_StartCore (which is internal to the library) and brings the cores out of Os_AwaitStartup.
2. The cores can either be started by writing to the boot register, or you can configure the RH850 option bytes to do this automatically.

5. Init Task

The Init Task is the next phase in the start-up sequence. Its main goal is to initialize and start the BswM Init lists:

The main objective of this task is to initialize the BswM module, and then trigger the first Action list. 

The function of the Startup Two is covered later in this guide.

Older versions of BSW

EcuM_StartupTwo will ultimately call the BswM_Init function. Once the BswM has been initialized properly the SchM_IModeInit will trigger the BswM init list one:

6. BswM Start-up  One

Here is where the list of BswM user callouts list can be found in Isolar:

The goal of Start-up  One is to initialize the Mem Stack and perform the NvM Read all. It also kicks off the Start-up  Two BswM list. The two items here are the trigger for the next Action List to begin. 

7. BswM Start-up  Two

For Start-up  Two to be activated, there are 2 conditions that need to be met:

The NvM read all needs to be completed, and Start-up  one also needs to be completed. The Start-up  Two init list includes the initialization calls for the remaining Bsw modules. The last important call here is the call to some integration code that starts the RTE. 

Module initialisation order

During "Start-up  Two" SchM_Init() and BswM_Init() will need to be called:

Due to changes in the AUTOSAR specification there is a difference between the order of these calls:

In RTA-BSW versions <= 6.1.2 the order is SchM_Init() then BswM_Init():

In RTA-BSW versions >= 6.1.3 the order is BswM_Init() then SchM_Init():

8. RTE Start Phase

The RTE start phase is one of the more important sections of the Start-up sequence. When this call is made, the Ecu is close to being completely up and running. 

So the first call to Rte_Start is important because it is responsible for starting the Schedule Table. Once the Schedule table has been started the Ecu is one step closer to being fully up and running.

At this point the Schedule table has been started, but it is not being driven. A schedule table is driven by a counter. In the Starter Kits case, it is driven by the Rte_TickCounter.

In the starter kit, the Rte_TickCounter is incremented in a callback notification from a GPT timer. 

This is why we enable the gpt notifiaction, and start the gpt timer. Once the Gpt notification is being triggered every 1ms, then the counter will be incremented every 1ms. 

At this point, the ECU is essentially up and running. There is one last BswM action list that is used to enable the ComM channel and to enable the PduGroups. This last action list is only to get the Com up and running. 

9. Schedule Table

For a complete detailed explanation on the RTA-OS Schedule Table please see the RTA-OS User Guide Section 10. The following is a general description of how the OS operates in the context of the Starter Kit. 

The Starter Kit uses a schedule table that is completely generated by the RTE. The RTE generates the schedule table, because it knows all of the information related to runnable to task mapping and the time periods of the runnables. 

Using this information the RTE will generate a file called osNeeds.arxml. This file is taken as an input to the RTA-OS. 

A schedule table is comprised of Expiry Points. Each expiry point contains a list of Task Activations. In the RTA-SK there are only two periodic tasks. The BSW task needs to be activated every millisecond, while the ASW task needs to be activated every 10 ms.

Above we can see that in the first expiry point, there are two task activations. Both the ASW and BSW tasks will be activated. When the tasks are activated they are moved from the Suspended to Ready State. Then the OS will then look at the priority and dispatch the higher priority task. When a task is dispatched, it will move from the Ready to Running state. Upon competition, the task will go from Running to Suspended. Then the OS will dispatch any tasks that are in the Ready state with a lower priority.

Since the BSW task is activated every 1ms, it will be triggered in every expiry point.

There are a total of 10 Expiry Points. This is known as the Duration:

Because the schedule table is configured as repeating the table will roll from expiry point 9 back to expiry point 0. This means that the ASW is activated every 10ms. So we only see the ASW task activated in the first expiry point. 

As mentioned above, the schedule table is driven by the Counter. Every time the Rte_TickCounter is incremented, the OS will move to the next expiry point. In the Starter Kit, the counter is incremented every 1ms in the GPT callback notification. 

Debugging issues in the OS

It can be useful to have an infinite loop in the ErrorHooks that can be hit by the OS, or at the very least some sort of logging feature.

e.g. in the OS ErrorHook:

Other Endless Loops

If your code ends up in an endless loop that has not been written by you then there will have been problem with one of the functions called during startup e.g. a response that one of your functions is expecting has never arrived.

For example in the MCU code a function may wait for MCU_PLL_LOCKED status of a PLL register indefinitely. In other targets there may be a timeout that occurs where it enters an error hook if the correct feedback is not received in time so you will be able to debug using the error reported in the error hook