7. Integration

7.1. Introduction

MCAL and CDD drivers offered by TI are compatible with AUTOSAR basic software provided by different AUTOSAR vendors. These drivers are specific to MCU hardware and work as abstraction layer which makes rest of BSW independent of MCAL. The intention of this document is to provide information on integrating TI MCALs/CDDs to AUTOSAR BSW provided by different vendors to ensure smooth interfacing.

7.2. How to use TI MCAL with Vector Stack

This chapter explains how TI MCAL can be integrated into Vector stack with respect to different use cases.

7.2.1. Board Bring-up with Vector’s startup code

7.2.1.1. Objective

The intention of this use case is to bring the program flow at the start of application, perform the startup activities such as but not limited to initialization of Interrupt Vector Table, Exception Vector Table, initialization of data, initialization of default clocks etc. This is achieved by integrating Vector startup code and Vector stack. Vector startup code has some dependencies on TI SDK which are explained in detail in subsequent chapter. Further, the required BSW modules are initialized and periodic scheduling is started via OS and RTE.

7.2.1.2. List of Modules

7.2.1.2.1. Vector Modules

Sl.No.	Vector Modules	Description	Significance in use case
1	EcuC (Autosar EcuC module), vSet (Vector Common Settings module)	EcuC and vSet are virtual modules that collect the global and ECU specific configuration information.	In this use case, this module is necessary to provide the partition and core information along with default global configurations for ECU.
2	vBaseEnv (Vector Base Environment), vBRS (Vector Basic Runtime System)	These modules together constitute Vector startup code that provide basic hardware setup options such as memory init, PLL init, Port init and Watchdog init etc. in order to set up the environment for cyclic runtime behavior. These modules can be configured to select which of its features shall be enabled and executed during startup to setup the environment based on use case.	In this use case, these modules are used to initialize memory, interrupt vector tables, exception vector tables. It initializes OS and EcuM and hands over control to EcuM for further processing
3	vLinkGen (Vector Linkers-script Generator)	The MICROSAR linker script generator provides a way to create a linker file in order to place the code, constants and data in intended memory location.	In this use case, this module is used to setup the application entry point, IVT etc.
4	OS (MICROSAR Operating System)	The Operating System is mainly responsible for handling of tasks and interrupts.	In this use case, it used to define a periodic task.
5	Rte (MICROSAR Runtime Environment)	The Runtime Environment module manages the information flow between Software Components (SWCs), BSW and CDDs.	In this use case, it is used to schedule the periodic task defined in OS.
6	EcuM (MICROSAR Ecu State Manager)	The Ecu State Manager starts/stops OS, SchM, BswM and other BSW modules. It is responsible for startup, shutdown, sleep modes and wakeup sources of the ECU.	In this use case, it used to start/stop OS and scheduler.

Note: For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector for each of these modules

7.2.1.2.2. TI SDK

SDK : MCU-PLUS-SDK-AM263

From downloaded SDK package copy following to common folder in your workspace -

Sl.No.	TI Modules	Description
1.	kernel	Include all the headers files from path {sdk_installation_dir}/source/kernel
2.	drivers	Include all the headers files from path {sdk_installation_dir}/source/drivers

7.2.1.3. Configuration

This chapter explains the minimum configurations that must be applied on top of the default configuration for each module, to realize this use case:

7.2.1.3.1. EcuC

This module contains the information of different partitions on each core. For this use case, we only require one partition on one core to run the OS. This partition is configured as below:

Microcontroller mentioned in the vBaseEnvDerivativeInformation — Fig. 7.1 EcuC Module Configuration

Configure the ASIL level as per the requirement. For this use case, ASIL Level is configured as QM.

7.2.1.3.2. vBaseEnv and vBRS

In vBaseEnv module the derivative of MCU being used is selected as shown below. Once this derivative is selected all MCU specific information is automatically set.

vBRS module is configured to enable features offered by startup code that are needed for this use case. The default configuration settings offered by vBRS are enough to achieve this use case. In this use case, we configure the vBRS to set the application entry point, clock frequencies, define the user code for makesupport, define the initialization pattern for data etc. Please ensure that configurations shown in below screenshots are intact:

As this use case is an application category, execution instance is selected as Application.

7.2.1.3.3. vLinkGen

vLinkGen configurations are done to generate a linker script that will store data/code/constants in desired memory location. By default vLinkGen will populate some variable/constant groups and memory regions based on other configured modules. The mandatory parameters in the default configurations shall be updated with the help of TechnicalReference_vLinkGen. To define the entry point to vector startup code, you add the entry point in generated linker file as shown below:

–entry_point=intvect_CoreExceptions /ENTRY POINT/

The entry point can be defined in multiple ways: The option –entry_point can be set to either intvect_CoreException OR _start in linker file. When entry point is set to intvect_CoreExceptions, the program counter points to the start of interrupt vector table after reset vector. Entry point is set to _start only when using debugger to preset the start address. In this use case we use the entry_point as intvect_CoreExceptions.

If the entry point is not set in linker file, then the default entry point (_cinit) is used, which uses a compiler based startup code instead of vector startup code.

Fig. 7.5 CINIT memory section configuration

Note

entry_point generation is not supported in the current Vector package. Hence, the –entry_point needs to be set to intvect_CoreExceptions in the linker file manually.

For details about vLinkGen configuration please refer Vector document TechnicalReference_vLinkGen.

7.2.1.3.4. OS

In this use case, intention of OS is to schedule one task with periodicity of 10ms. In order to achieve this, counter is configured to set the timebase for periodic task as shown below:

Os_Task_10ms configuration — Fig. 7.6 Counter configuration

Default auto-start tasks are created as shown below. These tasks participate in startup process. The default definition of task is present in startup code. For this use case, it is used as-is, however it can be modified as need be.

Auto-start task configuration — Fig. 7.7 Auto start task configuration1

Then we can configure a periodic task (10 ms) as shown below. This task is used to schedule the periodic runnable. In this use case, there is only one BSW module with a schedulable periodic runnable, which is EcuM.

7.2.1.3.5. Rte

The RTE defines each BSW module instance and its associated runnables. In this use case, the RTE is used to schedule the EcuM_MainFunction in the periodic task created in the OS configuration, as shown below.

Fig. 7.10 Mapping of EcuM main function

Thus, the Rte generates the mapping of the runnable to the task.

7.2.1.3.6. EcuM

In this use case, EcuM is used to start the OS and scheduler via EcuM_Init and EcuM_StartupTwo function calls in startup code. It also manages all the wakeup events associated with ECU. The mandatory configurations related to wakeup/sleep can be updated as shown below, however wakeup scenario is not part of this use case.

Fig. 7.12 OsResource added in the OS module is mapped in EcuM.

Note

Reference to Mcu Mode Setting Configuration is provided as placeholder because it is a mandatory parameter. This configuration is not used in this use case. Any MCU module definition can be used as reference. (e.g. Autosar standard definition of MCU already available in Vector Modules list).

7.2.1.4. Folder Structure

📦am26xx_autosar_integration
┣ 📂appl
┃ ┣ 📂soc
┃ ┃ ┗ 📂am263
┃ ┃ ┃ ┗ 📂r5f0_0
┃ ┃ ┃ ┃ ┗ 📂ti-arm-clang - Projectspec file is placed in the folder. Projectspec file shall be updated with the source and header files path to build in Code composer studio.
┃ ┃ ┃ ┃ ┃ ┣ 📜makefile_ccs_bootimage_gen
┃ ┃ ┃ ┃ ┃ ┣ 📜makefile_projectspec
┃ ┃ ┃ ┃ ┃ ┣ 📜Start_up.projectspec
┃ ┗ 📜Makefile
┣ 📂bsw
┃ ┣ 📂bsw - Vector stack static source and header files are placed in the module sub-folders of this folder.
┃ ┃ ┣ 📂EcuM - This folder contains the Vector static files of EcuM module.
┃ ┃ ┣ 📂Os - This folder contains the Vector static files of OS module.
┃ ┃ ┣ 📂vBaseEnv - This folder contains the Vector static files of vBaseEnv module.
┃ ┗ 📂bsw_gen - - This folder contains the generated Vector files of all necessary modules.
┣ 📂build - This folder contains the necessary generic files to build the project.
┃ ┣ 📂bootimage_scripts
┃ ┣ 📂makerules
┃ ┣ 📜ccs_makefile
┃ ┣ 📜makefile
┃ ┗ 📜Rules.make
┣ 📂common - This folder contains the TI SDK files.
┃ ┣ 📂hw
┃ ┣ 📂include
┃ ┃ ┣ 📂drivers
┃ ┃ ┃ ┣ 📂gpio
┃ ┃ ┃ ┣ 📂hw_include
┃ ┃ ┃ ┃ ┣ 📂am263x
┃ ┃ ┃ ┣ 📂i2c
┃ ┃ ┃ ┣ 📂pinmux
┃ ┃ ┃ ┣ 📂soc
┃ ┃ ┃ ┃ ┗ 📂am263x
┃ ┃ ┣ 📂kernel
┃ ┃ ┃ ┗ 📂dpl
┃ ┗ 📂memmap
┣ 📂Utils
┗ 📜lnk_r5_am263_CLANG.ld - This is the linker file used in the project build.

7.2.1.5. Build

Project can be build in two ways -

Using Code Composer Studio (CCS)
Using Makefile

For scope of this document CCS is used for building.

To build the project using Makefile please refer Vector documentation.

The module source files and generated files paths need to be mentioned in the .projectspec file. Files mentioned in the .projectspec file are considered in build process of Code Composer Studio.

Fig. 7.13 Adding paths of generated files in the projectspec file

Auto Run Option shall be disabled as mentioned below, to avoid the dependency of debugger in execution of the startup code.

Disabling the "On a program load or restart" option in the setting — Fig. 7.14 Disabling the “On a program load or restart” option in the setting

7.2.1.6. Compiler and Linker Settings

Following are the compiler and linker settings that are necessary in addition to the setting recommended by Vector in their release note:

Sl.No.	Compiler Option	Description
1	-x ti-asm	Indicates file needs to be processed by the TI-syntax ARM assembler

Sl.No.	Linker Option	Description
1	–retain=’(.OS_EXCVEC_CORE0_CODE)’ –retain=’(.brsExcVect1)’ –retain=’(.brsExcVect2)’ –retain=’(.brsExcVect3)’ –retain=’(.brsExcVect)’	The –retain option tells the linker to retain a list of sections that would otherwise not be retained. This is needed to retain the vector table symbols required by vBRS module.

7.2.1.7. Commonly faced issues

No	Issues	Solution
1	An unused variable “forceRead” is declared in Os_Hal_InterruptController_VIM_TPRxx.h > Os_Hal_INTC_ClearPending function. If -Werror is enabled in compiler option then this throw an error.	To solve this issue either - Remove -Werror compiler flag Remove the variable
2	Startup code crashes due to invalid address in vector table	Vector vBRS doesn’t support thumb mode; to solve this issue build in ARM mode.