7. AUTOSAR Integration Guide

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 for Board Bring-up

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

Vector startup code requires some low level functions that can interact directly with hardware e.g. to setup the interrupt vector table and interrupt controller, to set the clock etc. These kind of low level functions can be take from TI Software Development Kit (SDK).

SDK : MCU-PLUS-SDK-AM263

From downloaded SDK package copy following to 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 of modules in Board Bring-up

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 make support, 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

To achieve an OS task with 10 ms as the period. The following are the main parameters to be configured in OS module. Task Period should be 0.01s in OS tasks container. Which is shown in the below figure -

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

ECUM main function is mapped to 10ms task and position is given as shown. Importance of position parameter come into picture if more than more function is mapped in the TASK. Position parameter determines which mapped function will execute first within the particular task -

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.2. Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator

7.2.2.1. Objective

The TI MCAL modules are configured using EB Tresos tool. When Vector DaVinci Configurator is used for BSW stack configuration, we may require to import the MCAL modules to DaVinci Configurator so that Vector modules can have reference to MCAL modules e.g. The clock references from MCU module may be required by other module to derive their own clock. This chapter explains how TI MCAL modules can be imported to Vector DaVinci Configurator.

7.2.2.2. Files required for import

1.Export of MCAL from EB Tresos (ARXML): The MCAL modules can be exported from EB Tresos into an ARXML file as instructed in Run Export. This ARXML contains ECU configuration of MCAL modules. 2.Vendor Specific Module Definition (ARXML): TI defines Vendor Specific Module Definition for each MCAL module based on AUTOSAR Standard Module definition. This file is needed by Vector DaVinci Configurator to understand the parameters in MCAL modules. This ARXML file can be found as given in Module Plugin Directory Structure. 3.BSW Module Description File (ARXML): The BSWMD is a formal notation of all information belonging to a certain BSW module in addition to the implementation of the artifact. Each MCAL module generates it’s BSWMD file. Please refer Generate BSWMD for details.

7.2.2.3. Steps to import

1.Provide the path of Vendor Specific Module Definition (ARXML) and BSW Module Description File (ARXML) in Additional Definitions settings in DaVinci project settings as shown below -

Fig. 7.13 Additional Definition Settings

2.Import the MCAL Module Export from EB Tresos, e.g. -

Fig. 7.14 Importing MCAL module from EB Tresos

3.Provide the path of ARXML export of MCAL modules from EB Tresos, e.g. -

4.Select the MCAL modules to be imported. If there are any stubs/unwanted modules in export, they can be deselected -

5.The imported modules can be seen in DaVinci Configurator as shown below -

6.As shown in below image, the TI MCAL driver and it’s vendor specific module definition file are mapped to the respective driver -

Note

This import of MCAL modules to DaVinci configurator is only for reference to other modules. The MCAL modules can’t be updated/generated from DaVinci configurator.

7.2.3. CAN Integration

7.2.3.1. Objective for CAN Integration

The intention of CAN Integration is to have successful CAN communication by configuring TI MCAL modules along with Vector BSW Modules. Further details are explained in the subsequent chapter.

7.2.3.2. List Of Modules for CAN

7.2.3.2.1. MCAL Modules for CAN Integration

Sl. No.	MCAL Modules	Description	Significance in use case
1	CAN Driver	The CAN module initializes and controls the internal CAN Controllers of the microcontroller. It provides services to write, read, and configure mailboxes of the CAN controllers.	In this use case , this module is responsible for configuring the CAN hardware unit, hardware mailboxes, scheduled functions etc.
2	Mcu	The MCU module manages microcontroller features such as power modes, clock settings, and interrupts.	In this use case, this module is responsible for providing the clock for CAN communication.
3	Port	The PORT module provides an interface to configure and control microcontroller pins (e.g., GPIO, ADC, PWM).	In this use case, this module is responsible for configuring the hardware pins necessary for CAN communication.

Note

For detailed information, please refer to the section CAN Module.

7.2.3.2.2. Vector Modules for CAN Integration

Sl. No.	Vector Modules	Description	Significance in use case
1	EcuC (Autosar EcuC module)	EcuC is a virtual module 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	CanIf	The CanIf module provides an interface between the CAN driver and upper layers. It handles message transmission and reception, manages hardware object, and offers error handling.	In this use case, CanIf module mainly acts as interface between CAN driver and upper layers of communication stack, configures transmit/receive hardware objects etc.
3	PduR	PduR routes protocol data units between communication modules and ensures that the correct Pdus are transmitted to the appropriate destination.	In this use case, PduR module handles the routing of Pdus to and from Com layer and CAN driver.
4	Com	Com is responsible to provide a signal-based interface to the upper layer. It handles signal conversion, transmission and reception.	In this use case, Com module handles packing of AUTOSAR signals to I-Pdus to be transmitted and unpacking of received I-Pdus.
5	CanSM	The CAN State Manager (CanSM) realizes a software layer between the Communication Manager (ComM) and the CAN Interface (CanIf). The CanSM handles the startup and shutdown of the communication of a CAN network. The CAN State Manager maps the CAN State Manager states to the states of the ComM and causes the necessary actions to change the CAN State Manager state to those requested by the ComM.	In this use case, CanSM module manages the state transitions of the CAN controller, mainly from NO COMMUNICATION to FULL COMMUNICATION.
6	ComM	The Communication Manager is a resource manager, which encapsulates the control of the underlying communication services. It controls more than one communication bus channel of an ECU by implementing a channel state machine for every channel.	In this use case, ComM provides a mechanism for users to request communication modes, coordinating requests from multiple independent users.
7	OS (MICROSAR Operating System)	The Operating System is mainly responsible for handling tasks and interrupts.	In this use case, OS module is used to define periodic tasks needed for CAN communication such as processing transmit and receive message.
8	RTE (MICROSAR Runtime Environment)	The Runtime Environment module manages the information flow between Software Components (SWCs), BSW and CDDs.	In this use case, Rte module is used to schedule the periodic tasks defined in the operating system (OS) and sender receiver ports created for sending receiving CAN messages from application.
9	DET	The DET is used in order to report development errors. The DET can be replaced optionally by an equivalent component which is responsible for recognizing development errors, if no DET component is available.	In this use Case, Development error is enabled to detect all development errors.

Note

For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector.

Note

For importing MCAL configuration files to DaVinci refer Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator.

7.2.3.3. Configuration of modules in CAN Integration

This chapter explains the basic configurations that are needed to realize CAN communication.

7.2.3.3.1. CAN Configuration

TI CAN driver is configured using EB Tresos tool. It is then imported to Vector DaVinci configurator for integration with CAN stack. Following containers and parameters shall be configured.

CanController:

The CanController container defines the configuration parameters for individual CAN controllers within hardware. It manages essential settings like baud rate, timing segments, and hardware addressing, ensuring proper communication between the CAN bus and the application layer. The following figure shows the configuration of MCAN4 with CAN Bus off and CAN Reception/Transmission in polling mode -

Configuration of CAN controller with 1000kbps of baudrate is shown below -

Fig. 7.20 Configuration of CANcontrollerBaudrate

CANHwObject:

The CANHwObject container configures hardware objects (HOHs) used for transmitting and receiving CAN messages. It defines the type, direction, and identifier settings for each hardware object, ensuring proper handling of CAN message.

The configuration of a transmitting CAN signal with basic standard Id is shown below -

CANHwFilter:

The CANHwFilter container defines the hardware based message filtering mechanism for received CAN message. It ensures that only relevant messages matching a specified identifier pattern are accepted, reducing the load on the CPU.

The configuration of CAN signal Id filter which will be able to accept a CAN message of ID 0x9A(154) and mask code is shown below -

Fig. 7.22 Configuration for CAN_HwFilter

Note

CAN driver doesn’t support Sleep / Wakeup modes and ICOM functionality, hence the related parameters like partial networking shall not be configured in BSW modules.

7.2.3.3.2. MCU Configuration

The CAN module has dependencies on MCU module to provide the CAN clock setting reference. The MCU clock configuration for CAN controller is shown below -

Fig. 7.23 Configuration of McuClockSettingconfig

CAN clock should be derived from MCU clock reference point. The configuration for clock reference point is shown below -

Fig. 7.24 Configuration for Mcu_ClockReferencePoint

7.2.3.3.3. Port Configuration in CAN Module

CAN module has dependency on Port module to configure transmit, receive, standby and enable pins of hardware. Configuration of receive pin is as shown below -

Fig. 7.25 Port Pin Configuration for CAN module

7.2.3.3.4. EcuC Configuration in CAN Module

EcuC is a virtual module to collect ECU Configuration specific global configuration information. EcuCPduCollection container collects all the Pdus flowing through the COM Stack as shown below -

7.2.3.3.5. CanIf Configuration in CAN Module

CanIf module abstracts the CAN driver from the rest of the CAN stack. CAN driver and dependent MCAL modules must be imported to Vector DaVinci configurator before configuring Vector modules.

CanIf configures transmit and receive Pdus.

For a transmit message:

CanIfHthCfgs:

Hardware Transmit Handle shall be configured which is shown in below figure. It contains the reference to CAN controller and HTH object in the CAN driver module configuration -

Reference from TI's MCAL module imported in DaVinci — Fig. 7.27 Reference from TI’s MCAL module imported in DaVinci

From the available reference, CAN Controller and HTH object shall be selected as shown below -

Fig. 7.28 Configuration for CanIfHthCfgs

CanIfTxPduCfgs:

CanIf Tx Pdu container contains the configuration (parameters) of a transmit CAN L-Pdu. CanIf Tx Pdu configuration is shown below -

CANIfBufferCfgs:

CANIfBufferCfgs container contains the Tx-buffer configuration. Multiple buffers with different sizes could be configured. CANIfBufferCfgs configuration is shown below -

For a Receive message:

CanIfHrhCfgs:

CanIfHrhCfgs container contains configuration parameters for each hardware receive object (HRH). CanIfHrhCfgs configuration is shown below. It contains the reference to CAN controller and HRH object in the CAN driver module configuration -

CanIfRxpduCfgs:

CanIfRxpduCfgs container contains the configuration (parameters) of each receive CAN L-Pdu. Filters and delivers incoming messages to the upper layers. CanIfRxpduCfgs configuration is shown below -

7.2.3.3.6. PduR Configuration in CAN Module

The primary function of the Pdu Router module is to abstract the bus access type (Interface layer) and the bus type itself. The Pdu Router routing tables are configured with source and destination parameters. Pdu Router configuration to send and receive CAN message to and from CAN driver and Com module is shown below -

7.2.3.3.7. Com Configuration in CAN Module

The Com provides a signal-based communication interface to the upper layer (Rte). Also it is responsible for Packing and unpacking of signals in I-Pdus. Com configuration with different I-Pdus are shown below -

7.2.3.3.8. CanSM Configuration in CAN Module

CanSM changes the communication modes of the configured CAN networks according to requests from the ComM module and and performs a bus-specific error handling (BusOff). CanSM configuration is shown below -

7.2.3.3.9. ComM Configuration in CAN Module

The ComM is a resource manager, which encapsulates the control of the underlying services. The main purpose is controlling of multiple communication requests by the application independent of the used bus system -

7.2.3.3.10. Os Configuration in CAN Module

The OS module is responsible for task scheduling. Tasks such as 10ms and 1s are created to schedule different schedulable functions for CAN and respective BSW modules. The figure below illustrates the OS configuration -

7.2.3.3.11. Rte Configuration in CAN Module

Runtime Environment (RTE) manages communication between the software components (SWC), assures consistency of the overall information flow between basic software (BSW). It also maps a BswSchedulableEntity onto a OsTask.

The scheduling of the CAN_MainFunction Read is shown below -

Fig. 7.38 Scheduling of Periodic Function - Read

The scheduling of CAN_MainFunction Write is shown below -

Scheduling of Periodic Function - Write — Fig. 7.39 Scheduling of Periodic Functions - Write

All runnable in the 10ms task are shown below -

In the RTE (Runtime Environment), the corresponding port is created based on the configuration, and it can be used to communication between software components.

The port connection to software component is shown below -

Development Error Detection:

This configuration enables development error detection in all BSW and MCAL modules. Please refer to this setup as a reference for configuring other modules -

7.2.4. ADC Integration

7.2.4.1. Objective for ADC Integration

The purpose of ADC integration is to get digital voltage value from analog inputs by configuring TI MCAL modules along with Vector BSW Modules. Further details are explained in the subsequent chapter.

7.2.4.2. List Of Modules for ADC

7.2.4.2.1. MCAL Modules for ADC Integration

Sl. No.	MCAL Modules	Description	Significance in use case
1	ADC	The ADC module handles analog-to-digital conversions for external monitoring channels and internal temperature sensors, allowing start, stop, and result reading for configurable channel groups.	In this use-case, this module is used to convert analog voltage value to digital value.
2	Mcu	The MCU module manages microcontroller features such as power modes, clock settings, and interrupts.	In this use case, this module is responsible for providing the clock for ADC communication.

Note

For detailed information, please refer to the section ADC Module.

7.2.4.2.2. Vector Modules for ADC Integration

Sl. No.	Vector Modules	Description	Significance in use case
1	IoHwAb	The aim of the IoHwAb is to provide ECU hardware-independent data transition from driver modules up to the Software Components.	In this use case, IoHwAb layer provides wrapper function for each of the underlying ADC API’s, so that the application is independent on the hardware.
2	OS (MICROSAR Operating System)	The Operating System is mainly responsible for handling tasks and interrupts.	In this use case, OS module is used to define periodic tasks needed for ADC communication such as processing transmit and receive message.
3	RTE (MICROSAR Runtime Environment)	The Runtime Environment module manages the information flow between Software Components (SWCs), BSW and CDDs.	In this use case, Rte module is used to schedule the periodic tasks defined in the operating system (OS) and sender receiver ports created for sending receiving can messages from application.
4	DET	The DET is used in order to report development errors. The DET can be replaced optionally by an equivalent component which is responsible for recognizing development errors, if no DET component is available.	In this use Case, Development error is enabled to detect all development errors.

Note

For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector.

Note

For importing MCAL configuration files to DaVinci refer Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator.

7.2.4.3. Configuration of modules in ADC Integration

This chapter explains the basic configurations that are needed to realize ADC communication

7.2.4.3.1. ADC Configuration

TI ADC driver is configured using EB Tresos tool. It is then imported to Vector DaVinci configurator for integration with BSW stack. Following containers and parameters shall be configured.

AdcGeneral:

The AdcGeneral container defines the generic configuration parameters for ADC and provide provisions to enable disable API’s. The following figure shows the configuration of parameters interrupt as ADC_ISR_CAT2 and result alignment as ADC_ALIGN_RIGHT -

AdcHwUnit:

The AdcHwUnit container defines the configuration of individual ADC hardware units. It defines hardware related settings such as hardware unit to be used and resolution. The following figure shows the ADCHwUnit configurations -

AdcChannel:

The AdcChannel container defines the channel configuration depending on the hardware capabilities. The following figure shows the configuration of AdcChannel high/low limit and channel ID and channel range -

AdcChannelGroup:

The AdcChannelGroup configures multiple channels together, and it defines group-specific settings such as conversion mode and trigger source. The following figure shows the configuration of ADC_CONV_MODE_ONESHOT mode -

AdcGroupDefinition:

The AdcChannelGroupDefinition configures AdcChannel reference. AdcChannel_0 reference provided in AdcGroup_0 is shown below -

7.2.4.3.2. Mcu Configuration in ADC Module

The McuInterruptChannelXbar configuration is set to ‘MCU_INTRXBAR0_OUT_1’ and mapped to ‘MCU_INT_XBAR_ADC1_INT1. ADC interrupt is needed to be mapped through XBAR configuration. As shown in the figure, MCU_INTRXBAR0_OUT_1 an XBAR interrpt is being mapped to MCU_INT_XBAR_ADC1_INT1, which is the interrupt for ADC hardware unit 1.

The ADC interruption channel configuration is shown below -

Fig. 7.48 Configuration for AdcInterrupt

ADC hardware unit reference in MCU module is shown below -

Fig. 7.49 Configuration for McuAdcHWUnitId

7.2.4.3.3. IoHwAb Configuration in ADC Module

IoHwAb is a layer in the AUTOSAR architecture that abstracts hardware-level interfaces and provides a standardized API to the upper layers. It bridges the gap between hardware peripherals (like ADCs, GPIOs, etc.) and software components, ensuring hardware independence for application layers.

The configuration process for creating IoHwAb_AdcReadResultBuffer API in the IoHwAbCSPortInterfaces container is shown below -

Fig. 7.50 Configuration for IoHwAb_AdcReadResultBuffer

The configuration process for creating IoHwAbAdcReadResultBuffer API in the IoHwAbCSPortPrototypes container is shown below -

The interface between IoHwAb module and Mcal module API is shown below -

Fig. 7.52 Function call between IoHwAb and ADC

In the RTE (Runtime Environment), the corresponding port is created based on the configuration, and it can be used to communication between software components.

The port connection to software component is shown below -

7.2.4.3.4. Os Configuration in ADC Module

The OS module is responsible for task scheduling. The mapping of ADC Mainfunction to the 10ms event is shown below -

7.2.4.3.5. Rte Configuration in ADC Module

The ADC main function is mapped to a 10ms task as shown in the below -

Fig. 7.55 Mapping ADC main function to 10ms task

7.2.5. SPI Integration

7.2.5.1. Objective for SPI Integration

The intention of SPI integration is to establish successful SPI communication by configuring the SPI MCAL and dependent Vector modules. It will facilitate communication between the MCAL modules, transmitting and receiving data from the Vector module, which will be explained in the subsequent chapter.

7.2.5.2. List of Modules for SPI

7.2.5.2.1. MCAL Modules for SPI Integration

Sl. No.	MCAL Modules	Description	Significance in use case
1	Mcu	The MCU module manages microcontroller features such as power modes, clock settings, and interrupts.	In this use case, this module is responsible for providing the clock for SPI communication.
2	SPI (Serial Peripheral Interface)	The main tasks of the SPI are Handle data transmission to the components connected via SPI, take care of the settings required by external components (baud rate etc.)	In this use case, this module is responsible for configuring spi channel, job and sequence.
3	Port	The PORT module provides an interface to configure and control microcontroller pins (e.g., GPIO, ADC, PWM).	In this use case, this module is responsible for configuring the hardware pins necessary for Spi communication.

Note

For detailed information, please refer to the section SPI Module.

7.2.5.2.2. Vector Modules for SPI Integration

Sl. No.	Vector Modules	Description	Significance in use case
1	IoHwAb	The aim of the IoHwAb is to provide ECU hardware-independent data transition from driver modules up to the Software Components.	In this use case, IoHwAb layer provides wrapper function for each of the underlying SPI API’s, so that the application is independent on the hardware.
2	OS (MICROSAR Operating System)	The Operating System is mainly responsible for handling tasks and interrupts.	In this use case, OS module is used to define periodic tasks needed for SPI communication such as processing transmit and receive message.
3	RTE (MICROSAR Runtime Environment)	The Runtime Environment module manages the information flow between Software Components (SWCs), BSW and CDDs.	In this use case, Rte module is used to schedule the periodic tasks defined in the operating system (OS) and sender receiver ports created for sending receiving spi messages from application.
4	DET	The DET is used in order to report development errors. The DET can be replaced optionally by an equivalent component which is responsible for recognizing development errors, if no DET component is available.	In this use Case, Development error is enabled to detect all development errors.

Note

For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector.

Note

For importing MCAL configuration files to DaVinci refer Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator.

7.2.5.3. Configuration of modules in Spi Integration

This chapter explains the basic configurations that are needed to realize SPI communication.

7.2.5.3.1. Spi configuration

TI SPI driver is configured using EB Tresos tool. It is then imported to Vector DaVinci configurator for integration with SPI stack. Following containers and parameters shall be configured.

SpiGeneral:

The SpiGeneral container is used to configure SPI-related global settings that affect the SPI driver as a whole. It manages essential settings like enabling Apis and setting timeout duration, maxjobs and maxSequences etc. The following figure shows the configuration of SpiMainFunctionPeriod with 10ms -

SpiMaxChannel:

The SpiMaxChannel container Specifies the maximum number of SPI channels that can be configured and used by the SPI driver in the system. The configuration of max channels is shown below -

SpiJob:

The SpiJob container specifies the Spi job priority, Device assignment and HW unit assignment. The configuration of Spijob is shown below -

SpiHwUnitSynchronous:

The SpiHwUnitSynchronous container is set to “SYNCHRONOUS”, the SpiJob uses its contained SpiDriver in a synchronous manner. If it is set to “ASYNCHRONOUS”, it uses the driver in an asynchronous way. The configuration of SYNCHRONOUS is shown below -

SpiJobEndNotification:

The SpiJobEndNotification parameter is a reference to a notification function. The configuration of NULL_PTR is shown below -

SpiChannelList:

The SpiChannelList container references spi channels and their order within the job. The configuration of spi channel order is shown below -

SpiMaxSequence:

The SpiMaxSequence configures the maximum number of SPI sequences that the SPI driver can handle concurrently or sequentially in the system. The configuration of the Max sequence is shown below -

SpiChannel:

The SpiChannel configuration defines the parameters for a specific SPI channelId, channeltype, data width and transfer start, etc. The configuration of SpiChannel is shown below -

SpiExternalDevice:

The SpiExternalDevice container is used to define the properties and configuration settings for an SPI peripheral device that is external to the ECU. It specifies how the ECU (master) will communicate with an external device (slave) via the SPI interface. This configuration includes details about the device’s requirements for communication, such as timing, data format, and the SPI mode -

SpiSequence:

The SpiSequence configuration defines a series of SpiJobs that are executed in a particular order to achieve a complete communication task. The configuration of spi sequence Id is shown below -

SpiSeqEndNotification:

The SpiSeqEndNotification contains a reference to a notification function. The following figure is shown below -

SpiJobAssignment:

The SpiJobAssignment container references several jobs, which are executed during a communication sequence. The following figure is show below -

SpiHwUnitConfig:

The SpiHwUnitConfig is used to define the hardware settings to initialize and control the physical SPI hardware unit (such as SPI0, SPI1, etc.) on the microcontroller -

SpiUserCallbackHeaderFile:

The SpiUserCallbackHeaderFile specifies the header file that contains user-defined callback functions that the SPI driver can call at various stages of the SPI communication process -

SpiHwUnitEnabled:

The SpiHwUnitEnabled is used for storing enabled SPI HW units -

7.2.5.3.2. Port Configuration in SPI Module

In the configuration of the SPI module, the port pins are used to facilitate the transmission (Tx) and reception (Rx) of data. The pin configurations for both SPI0 and SPI1 are shown below -

Fig. 7.71 Port pin configuration for spi

The SPI0 clock pin configuration is shown below -

Fig. 7.72 Configuration for Spi clock pin

7.2.5.3.3. IoHwAb configuration in SPI Module

The configuration process for determining the IoHwAb_Async_Transmit API in the IoHwAbCSPortInterfaces container is shown below -

Fig. 7.73 Configuration for IoHwAbCSPortInterface

The configuration process for determining IoHwAbCSAsyncTransmit API in the IoHwAbCSPortPrototypes container is shown below -

Fig. 7.74 Configuration for IoHwAbCSPortPrototypes

The function call interaction between the IoHwAb module and the Mcal module API is shown below -

Fig. 7.75 Function call between IoHwAb and SPI

In the RTE (Runtime Environment), the corresponding port is created based on the configuration, and it can be used to communication between software components.

The port connection to software component is shown below -

7.2.5.3.4. Rte Configuration in SPI Module

The SPI main function timing event handling is mapped to a 10ms task, and its position is specified as shown below. The importance of the position parameter comes into play when more than one function is mapped to the same task. The position parameter determines the execution order of the mapped functions within that particular task, with lower values executing first -

Fig. 7.77 Configuring 10ms task to spi_mainfunctionTimingEvent_Handling

7.2.6. PWM Integration

7.2.6.1. Objective for PWM Integration

The intention of PWM Integration is to enable successful PWM signal generation by configuring TI MCAL modules along with Vector BSW Modules. Further details are explained in the subsequent chapter.

7.2.6.2. List of Modules for PWM

7.2.6.2.1. MCAL Modules for PWM Integration

Sl. No.	MCAL Modules	Description	Significance in use case
1	Mcu	The MCU module manages microcontroller features for PWM, such as power modes and clock settings.	In this use case, this module is responsible for providing the clock for PWM signal generation.
2	Port	The PORT module provides an interface to configure and control microcontroller pins (e.g., GPIO, ADC, PWM).	In this use case, this module is responsible for configuring the hardware pins necessary for PWM signal generation.
3	Pwm	The PWM module initializes and controls the internal PWM peripherals of the microcontroller. It provides services to configure, start, and stop PWM channels used for generating variable duty cycle signals	In this use case, PWM is used to generate PWM signal with different duty cycle.

Note

For detailed information, please refer to the section PWM Module.

7.2.6.2.2. Vector Modules for PWM Integration

Sl. No.	Vector Modules	Description	Significance in use case
1	IoHwAb	The aim of the IoHwAb is to provide ECU hardware-independent data transition from driver modules up to the Software Components.	It provides an abstraction for the PWM driver and enables communication with the application layer.
2	OS	The Operating System is mainly responsible for handling tasks.	In this use case, it is used to initialize PWM.
3	RTE	The Runtime Environment module manages the information flow	In this use case, it is used to schedule the periodic task defined in OS.
4	DET	The DET is used in order to report development errors. The DET can be replaced optionally by an equivalent component which is responsible for recognizing development errors, if no DET component is available.	In this use Case, Development error is enabled to detect all development errors.

Note

For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector.

Note

For importing MCAL configuration files to DaVinci refer Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator.

7.2.6.3. Configuration of modules in PWM Integration

This chapter explains the basic configurations that are needed to realize PWM functionality.

7.2.6.3.1. PWM Configuration

The PWM driver is configured using the EB Tresos tool and then imported into the Vector DaVinci Configurator for integration with the application software. The following containers and parameters should be configured.

PwmGeneral:

The PwmGeneral container provides general configuration settings for the PWM module.

In PWM general settings, PWMSetDutyCycle API is enabled as shown below -

PwmChannel:

The PwmChannel configuration container specifies the settings for a specific PWM channel.

In the PWM channel configuration, the channel ID is set to 3, the default duty cycle is configured as 16384, and the PWM polarity is set to high, as shown below -

Configuration for Pwm Channel — Fig. 7.79 Configuration of PWM Channel

7.2.6.3.2. Mcu Configuration in PWM Module

The PWM module has dependencies on MCU module to provide the PWM clock setting reference.

The MCU clock configuration for PWM controller is shown below -

PWM clock should be derived from MCU clock reference point.

The MCU clock reference point is shown below -

Fig. 7.81 Configuration of McuClockReferencePoint

7.2.6.3.3. Port Configuration in PWM Module

The PWM module has a dependency on the Port module to configure the output pins used for generating PWM signals. Each PWM channel is mapped to a specific physical pin on the microcontroller, which must be configured as an output using the Port module.

In the port pin configuration, EPWM3 is configured as a PWM output, as shown below -

Port pin configuration for Pwm — Fig. 7.82 Port Pin configuration for Pwm

7.2.6.3.4. IoHwAb Configuration in PWM Module

IoHwAb is a layer in the AUTOSAR architecture that abstracts hardware-level interfaces and provides a standardized API to the upper layers.

To configure a Client/Server Port Interface, the container IoHwAb_PWM_DutyCycle holds the configuration elements for a Client/Server template interface. This interface is instantiated by a Client/Server Port Prototype.

The container IoHwAbOperationArguments contains the configuration of Operation Elements, such as ChannelID and DutyCycle, for a Client/Server Operation. These Operation Elements will be generated as function parameters in the I/O Hardware Abstraction (IoHwAb) implementation.

Similarly, it is possible to enable communication between the I/O Client/Server interface and the MCAL APIs.

Configuration of pwm IoHwAbCS port interface as shown below -

Fig. 7.83 Configuration for Pwm IoHwAbCSPortInterface

The container IoHwAbPWMDutyCycle is used for configuring a Client/Server Port Prototype. This container represents an instantiation of a Client/Server Port Interface.

Configuration of pwm IoHwAbCS port prototype as shown below -

Fig. 7.84 Configuration for Pwm IoHwAbCSPortPrototypes

The function IoHwAb_IoHwAbPWMDutyCycle_IoHwAbOperation is generated, and then the MCAL API function Pwm_SetDutyCycle is called -

Fig. 7.85 Invoking MCAL API SetDutyCycle

In the RTE (Runtime Environment), the corresponding port is created based on the configuration, and it can be used to communication between software components.

The port connection to software component is shown below -

7.2.7. LIN Integration

7.2.7.1. Objective for LIN Integration

The intention of LIN integration is to establish successful LIN communication by configuring the MCAL and Vector modules. To achieve effective communication between the LIN master and slave, proper configurations are implemented, which will be explained in the subsequent chapter.

7.2.7.2. List of Modules for LIN

7.2.7.2.1. MCAL Modules for LIN Integration

Sl. No.	MCAL Modules	Description	Significance in use case
1	Mcu	Manages microcontroller features such as power modes, clock settings, and interrupts.	In this use case this module is used to provide clock for CAN communication.
2	Port	Provides an interface to configure and control microcontroller pins (e.g., GPIO, ADC, PWM).	In this use case allows application software to interact with hardware pins, making it transmit and receive LIN Message.
3	Lin	A communication protocol for low-speed communication between ECUs (Electronic Control Units) in automotive applications.	In this use case, it is used for communication between the MCAL layer and the Application layer to transmit and receive data.

Note

For detailed information, please refer to the section LIN Module.

7.2.7.2.2. Vector Modules for LIN Integration

Sl. No.	Vector Modules	Description	Significance in use case
1	EcuC	Virtual module to collect ECU Configuration specific / global configuration information.	In this use case, EcuC collects all Pdu objects flowing through the Com-Stack.
2	LinIf	Provides an interface for handling communication over the LIN (Local Interconnect Network) protocol.	In this use case, LinIf ensures communication between application software and the LIN hardware.
3	LinSM	Manages the state machine for the LIN communication stack.	In this use case, LinSM manages the state transitions of the Lin controller to error recovery and maintain reliable communication.
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	Com	Com is responsible to provide a signal-based interface to the upper layer. It handles signal conversion, transmission and reception.	In this use case, Com module handles packing of AUTOSAR signals to I-Pdus to be transmitted and unpacking of received I-Pdus.
7	ComM	The Communication Manager is a resource manager, which encapsulates the control of the underlying communication services. It controls more than one communication bus channel of an ECU by implementing a channel state machine for every channel.	In this use case, ComM provides a mechanism for users to request communication modes, coordinating requests from multiple independent users.
8	EcuM	EcuM is responsible for initialization of BSW (Basic Software) modules that are needed to start the operating system and preparation of the microcontroller for a sleep phase and the following wake up	In this use case, EcuM is used to wake up the LIN channel by configuring the EcuM wakeup sources
9	PduR	PduR routes protocol data units between communication modules and ensures that the correct Pdus are transmitted to the appropriate destination.	In this use case, PduR module handles the routing of Pdus to and from Com layer and LIN driver.
10	DET	The DET is used in order to report development errors. The DET can be replaced optionally by an equivalent component which is responsible for recognizing development errors, if no DET component is available.	In this use Case, Development error is enabled to detect all development errors.

Note

For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector.

Note

For importing MCAL configuration files to DaVinci refer Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator.

7.2.7.3. Configuration of modules in LIN Integration

This chapter explains the basic configurations that are needed to realize LIN communication.

7.2.7.3.1. Lin Configuration

LinGeneral:

The LinGeneral container is responsible for configuring the global settings of the LIN protocol in the system.

Follow the configuration of Lin General settings as shown below -

LinChannel:

This container holds the configuration parameters for the LIN Controller(s). It defines critical settings such as the baud rate, which is essential for enabling proper communication between the LIN bus and the application layer.

Select LIN1 hardware unit, with loopback mode disabled and baud rate configuration as shown below -

7.2.7.3.2. MCU Configuration for LIN Module

The LIN module has dependence on MCU module. Hence, we need to provide clock setting reference in MCU module. Please refer to TechnicalReference_Mcu was used to configure this module.

Lin clock reference point is configured as shown below -

Fig. 7.89 Lin Mcu Clock reference configuration

7.2.7.3.3. Port Configuration in LIN Module

In the configuration of the port for the LIN module, the port pins are used to facilitate the transmission (Tx) and reception (Rx) of messages.

LIN1 Rx is configured on pin A9 and LIN1 Tx is configured on pin B9 as shown below -

Fig. 7.90 Port pin configuration for Lin

Similarly, port pin for LIN RX can be configured.

7.2.7.3.4. EcuC Configuration in LIN Module

EcuC is a virtual module to collect ECU Configuration specific global configuration information. EcuCPduCollection container collects all the Pdus flowing through the COM Stack as shown below -

7.2.7.3.5. LinIf Configuration in LIN Module

LinIf is responsible for managing the interaction between the application layer and the underlying LIN driver.

LinIfChannels:

LinIfChannels define the communication channels for the LIN (Local Interconnect Network) protocol.

The configuration of the LinIf channel is done with the startup state set to NORMAL and the wake-up confirmation timeout period configured as 2 seconds as shown below -

LinIfFrames:

LinIfFrames represent the actual message format used in LIN communication, specifying message IDs, data length, and content.

Both LINIf Tx and Rx frames are configured as Unconditional frames as shown below -

Fig. 7.93 LinIf Tx and Rx frame configuration

The configuration of LinIf Tx Pdu frame is as shown below -

The configuration of LinIf Rx Pdu frame is as shown below -

LinIfScheduleTables:

The schedule table allows for time-based control of message exchanges, ensuring that messages are sent at the correct intervals, such as periodically requesting sensor data or controlling actuators.

The configuration of LinIfScheduleTable for both master and slave response where both are configured with runmode as RUN_ONCE as shown below -

Fig. 7.96 Configuration for LinIfScheduleTables

The configuration of LinIfEntry is shown below -

LinIfNodeType:

LinIfNodeType specifies the role of a LIN node (communication endpoint) in the network. Master Node: Initiates communication controls the flow of data, and requests data from slave nodes. Slave Node: Responds to requests from the master node, providing data or status information.

The configuration of LinIfNodeType is shown as below -

Fig. 7.98 configuration for LinIfNodeType

7.2.7.3.6. LinSM Configuration in LIN Module

The LinSM (LIN State Manager) is responsible for controlling the communication states of the LIN network, such as initialization, sleep, and wake-up.

LinSMChannel:

LinSMChannel configures the LIN State Manager channel, managing state transitions (e.g., from sleep to active) for LIN communication.

The configuration of LinSM channel is done as shown below by selecting appropriate node type -

LinSMSchedule:

LinSMSchedule defines the schedule for the LIN State Manager (LinSM), specifying the timing and sequence for state transitions (such as wake-up and communication states).

Two LinSM Schedules are created with different schedule index as shown below -

Fig. 7.100 LinSM Schedules Configuration

LinSMGeneral:

LinSMGeneral is used to configure general settings for the LIN State Manager (LinSM), which controls the state transitions of the LIN communication.

The configuration of LinSM is configured as shown below, by setting the main Processing period as 10ms -

7.2.7.3.7. EcuM Configuration in LIN Module

The EcuM is used to wake up the LIN channel by configuring the EcuM wakeup source ID and setting the parameters that reference the LinWakeupChannel parameter.

Follow the configuration of EcuM with EcuM wakeup source ID as 4 and EcuM wakeup source enabled in Polling mode as shown below -

Fig. 7.102 Lin wakeup configuration in EcuM

7.2.7.3.8. PduR Configuration in LIN Module

The primary function of the Pdu Router module is to abstract the bus access type (Interface layer) and the bus type itself. The Pdu Router routing tables are configured with source and destination parameters. Pdu Router configuration to send and receive LIN message to and from LIN driver and Com module, is shown below -

7.2.7.3.9. Com Configuration in LIN Module

Com module provides the configuration for ComIpdus and ComIpdugroups. It also provides Tx and Rx main function. Below figure illustrates the com configuration

To configure Lin in DaVinci Configurator the following containers need to be set up.

ComSignal:

The ComSignal container is used to define individual signals within a communication protocol (e.g., CAN, LIN) in the system.

The configuration of the Com Signal for the LIN master response is done with the transfer property set to TRIGGERED and the signal access set to ACCESS_NEEDED_BY_OTHER, as shown in the figure below -

Fig. 7.104 Configuration for Lin Tx signal

Configuration of Lin Slave signal is done with signal access set to ACCESS_NEEDED_BY_OTHER as shown below -

Fig. 7.105 Configuration of Lin Rx signal

ComIPuds:

The ComIPuds container simplifies the definition of data transfer mechanisms between ECUs, especially when communication involves multiple protocols or complex mappings of signals and messages.

Configuration of a Lin Master comIpdu is configured with Ipdu signal processing as IMMEDIATE as shown below -

Fig. 7.106 configuration for Lin Tx Ipdu

Configuration of a Lin Slave comIpdu is done with Ipdu signal processing as DEFERRED, as shown below -

Fig. 7.107 Configuration for Lin Rx Ipdu

ComIPduGroup:

The ComIPduGroup container is used to group related IPdus together, which can represent different sets of data that need to be communicated within the same context or for the same functional block.

The configuration of ComIPduGroup associated with the LIN Master is shown below -

Fig. 7.108 Configuration for Lin Tx IpduGroup

The configuration of ComIPduGroup associated with the LIN Slave is shown below -

Fig. 7.109 Configuration for Lin Rx IpduGroup

7.2.7.3.10. ComM Configuration in LIN Module

The ComM module allows the system to operate in different communication modes. Lin Controller channel reference shall be given in the ComM module.

ComMUser:

The ComMUser configuration is used to specify user-defined settings related to Communication Management (ComM).

The configuration of ComMUser for LIN is shown below -

Fig. 7.110 Configuration for Lin RteSwComponentInstances

ComMChannel:

The ComMChannel container is responsible for configuring communication channels within the ComM (Communication Management) module.

The Configuration of ComMChannels for LIN is as shown below -

Fig. 7.111 Configuration for Lin ComM channel

The configuration of ComMUserPerChannels for Lin is as shown below -

Fig. 7.112 Configuration for lin ComMUserPerChannels

7.2.7.3.11. OS Configuration in LIN Module

The OS module is responsible for task scheduling. Tasks such as 10ms and 1s are created to schedule different schedulable functions for LIN and respective BSW modules. The figure below illustrates the OS configuration -

7.2.7.3.12. Rte Configuration in LIN Module

Runtime Environment (RTE) manages communication between the software components (SWC), assures consistency of the overall information flow between basic software (BSW). It also maps a BswSchedulableEntity onto a OsTask.

The scheduling of the LinIf_MainFunction is shown below -

Fig. 7.114 Scheduling of LinIf main function

All runnable in the 10ms task are shown below -

In the RTE (Runtime Environment), the corresponding port is created based on the configuration, and it can be used to communication between software components.

The port connection to software component is shown below -

7.2.8. CDD_IPC Integration

7.2.8.1. Objective for CDD_IPC Integration

The intention of CDD_IPC Integration is to enable reliable and efficient inter-core communication by configuring the TI MCAL IPC driver in conjunction with the Vector Basic Software (BSW) modules.Further details are explained in the subsequent chapter.

7.2.8.2. List of Modules for CDD_IPC Integration

7.2.8.2.1. MCAL Modules for CDD_IPC Integration

Sl.No.	MCAL Modules	Description	Significance in use case
1	IPC	The IPC module initializes and manages the inter-core communication hardware of the microcontroller. It provides services to configure communication channels, send and receive messages, and handle inter-core synchronization.	In this use case,the module is used to enable and manage communication between master core and slave cores, ensuring reliable data exchange and synchronization.

Note

For detailed information, please refer to the section CDD_IPC Module.

7.2.8.2.2. Vector Modules for CDD_IPC Integration

Sl.No.	Vector Modules	Description	Significance in use case
1	IoHwAb	This module provides an abstraction layer for handling hardware-related input/output operations. It facilitates interaction with IPC hardware resources for data exchange between processor cores.	In this use case,it abstracts the IPC driver and facilitates interaction between the application layer and the underlying inter-core communication mechanism.
2	OS	The Operating System is mainly responsible for handling tasks.	In this use case, it is used to initialize,manage tasks and interrupts related to inter-core communication,
3	RTE	The Runtime Environment module manages the information flow	In this use case, it is used to schedule the periodic task defined in OS.
4	DET	The DET is used in order to report development errors. The DET can be replaced optionally by an equivalent component which is responsible for recognizing development errors, if no DET component is available.	In this use Case, Development error is enabled to detect all development errors.

Note

For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector.

Note

For importing MCAL configuration files to DaVinci refer Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator.

7.2.8.3. Configuration of modules in CDD_IPC Integration

This chapter explains the basic configurations that are needed to realize CDD IPC functionalities.

7.2.8.3.1. CDD_IPC Configuration

The TI IPC driver is configured using the EB Tresos tool. It is then imported into the Vector DaVinci Configurator for integration with the application software. Following containers and parameters shall be configured.

CDD_IPC General:

The IpcGeneral container provides general configuration settings for the IPC module.

In IPC general settings,IpcWriteApi and IpcReadApi is enabled as shown below -

Fig. 7.117 Configuration of IPC general settings

CddIpcDriver:

This CddIpcDriver container contains the configuration parameters and sub containers of the AUTOSAR Complex device driver(CDD) module

In the Cdd_Ipc Driver configuration,Specifies the local core ID on which the IPC instance is running, as shown below -

Fig. 7.118 Configuration of IPC driver settings

CddIpcRemoteCoreList:

This CddIpcRemoteCoreList container refers to the list of core IDs that are valid for the particular platform and can participate in inter-process communication,as shown below -

7.2.8.3.2. IoHwAb Configuration

IoHwAb is a layer in the AUTOSAR architecture that abstracts hardware-level interfaces and provides a standardized API to the upper layers.

To configure a Client/Server Port Interface,the container Cdd_Ipc_Notify_RegisterClient holds the configuration elements for a Client/Server template interface. This interface is instantiated by a Client/Server Port Prototype.

The container IoHwAbOperationArguments contains the configuration of Operation Elements, such as Cdd_Ipc_localClientId,Cdd_Ipc_notify_msgHandler and IoHwAbOperationArgument,for a Client/Server Operation. These Operation Elements will be generated as function parameters in the I/O Hardware Abstraction(IoHwAb) implementation.

Similarly, it is possible to enable communication between the I/O Client/Server interface and the MCAL APIs.

Configuration of Cdd_Ipc IoHwAbCS port interface as shown below -

Fig. 7.120 Configuration for Cdd_Ipc IoHwAbCSPortInterface

The container RegisterClient is used for configuring a Client/Server Port Prototype. This container represents an instantiation of a Client/Server Port Interface.

Configuration of Cdd_Ipc IoHwAbCS port prototype as shown below -

Fig. 7.121 Configuration for Cdd_Ipc IoHwAbCSPortPrototypes

The function IoHwAb_RegisterClient_Wrapper is generated, and then the MCAL API function Cdd_Ipc_Notify_RegisterClient is called.

In the RTE (Runtime Environment), the corresponding port is created based on the configuration, and it can be used as a Sender-Receiver Port for communication between software components -

Fig. 7.122 Invoking MCAL API Cdd_Ipc RegisterClient

The port connection to software component for Ipc notify is shown below -

The port connection to software component for Ipc rp is shown below -

7.2.9. WDG Integration

7.2.9.1. Objective for WDG Integration

The WDG driver provides services for handling the watch dog timer on the microcontroller.

7.2.9.2. List of Modules for WDG Integration

7.2.9.2.1. MCAL Modules for WDG Integration

Sl.No.	MCAL Modules	Description	Significance in use case
1	Mcu	Manages microcontroller features such as power modes, clock settings, and interrupts.	In this use case this module is used to provide clock for WDG operation.
2	WDG	The WDG provides services for handling the watch dog timer on the microcontroller	In this use case, WDG is configured to handle the watch dog timer

Note

For detailed information, please refer to the section WDG Module.

7.2.9.2.2. Vector Modules for WDG Integration

Sl.No.	Vector Modules	Description	Significance in use case
1	WDGIf	The main WdgIf functionality consists of linking the overlying Watchdog Manager module (WdgM) to one or more underlying WDG drivers	In this use case, WdgIf ensures operation between application software and the WDG driver.
2	WDGM	The Watchdog Manager (WdgM) is responsible for supervising the software components and ensuring system health by monitoring the execution flow of supervised entities.	In this use case, WDGM supervises the software components and ensures system health.
3	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.
4	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.
5	DET	The DET is used in order to report development errors. The DET can be replaced optionally by an equivalent component which is responsible for recognizing development errors, if no DET component is available.	In this use Case, Development error is enabled to detect all development errors.

Note

For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector.

Note

For importing MCAL configuration files to DaVinci refer Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator.

7.2.9.3. Configuration modules in WDG Integration

This chapter explains the basic configurations that are needed to realize WDG functionalities.

7.2.9.3.1. Wdg Configuration

As part of WDG module integration, WDG module from TI MCAL stack shall be interconnected with vector modules. For that WDG along with its dependent WDG modules shall be configured and provide the reference to WdgIf module. As a first step following Containers and parameters shall be configured in WDG module.

WdgGeneral: The WDGGeneral container is responsible for configuring the global settings of the WDG in the system. It ensures that the WDG operation module is properly set up for tasks such as WDG window size, WDG default mode.

WDG is configured with 100 percent window size as shown below -

The default mode of WDG is selected as WDGIF_SLOW_MODE and WDG reaction is set to WDG_GENERATE_RESET as shown below -

7.2.9.3.2. MCU Configuration for WDG Integration

The Wdg module has dependence on MCU module. Hence, we need to provide clock setting reference in MCU module. Please refer to TechnicalReference_Mcu was used to configure this module.

The MCU clock configuration for WDG driver is shown below -

Fig. 7.127 Wdg Mcu Clock reference configuration

7.2.9.3.3. WdgIf Configuration for WDG Integration

WdgIF is responsible for managing the interaction between the application layer and the underlying WDG driver. To configure WdgIF, the following containers and parameters need to be set up.

WdgIfDevices:

WDGIF is configured for WDG usecase realisation. We need to provide WDG driver reference as shown below -

7.2.9.3.4. WdgM Configuration for WDG Integration

The WdgM monitors safety-relevant applications on the ECU. When the WdgM detects a violation of the preconfigured temporal or logical constraints in the program flow, it takes several configurable actions to log the fault and to go to a safe state after a configurable time delay.

Two WDG check points are created for entry and exit as shown below -

WDG deadline supervision is configured with maximum deadline of 5000 ms and minimum deadline of 10 ms, and the entry and exit references are given as shown below -

Fig. 7.130 WDG Deadline supervision configuration

Two different triggers are configured with different WDG modes. One trigger is configured with slow mode, while another with fast mode as shown below -

7.2.9.3.5. OS Configuration for WDG Integration

The OS module is responsible for task scheduling. Tasks such as 10ms and 1s are created to schedule different schedulable functions for WDG and respective BSW modules.

The OS configuration is shown below -

7.2.9.3.6. Rte Configuration for WDG Integration

Runtime Environment (RTE) manages communication between the software components (SWC), assures consistency of the overall information flow between basic software (BSW). It also maps a BswSchedulableEntity onto one OsTask.

The scheduling of the WdgM_MainFunction is shown below -

Fig. 7.133 Scheduling of periodic function - WdgM_MainFunction

7.2.10. DIO Integration

7.2.10.1. Objective for DIO Integration

The intention of DIO integration is to verify DIO functionality by configuring the DIO MCAL and dependent Vector modules. It will facilitate switching of digital signals, representing ON/OFF or HIGH/LOW states, which will be explained in the subsequent chapter.

7.2.10.2. List of Modules for DIO Integration

7.2.10.2.1. MCAL Modules for DIO

Sl.No.	MCAL Modules	Description	Significance in use case
1	Mcu	The MCU module manages microcontroller features such as power modes, clock settings, and interrupts.	In this use case, this module is responsible for providing the clock for ADC communication.
2	DIO	The DIO driver provides port and channel based read and write access to the internal general purpose I/O ports. The read and write behaviour is unbuffered. The basic behaviour of this driver is synchronous.	In this use case, this module is responsible for providing read input from software and send output to controller.
3	Port	The PORT module provides an interface to configure and control microcontroller pins (e.g., GPIO, ADC, PWM).	In this use case, this module is responsible for configuring the hardware pins necessary for DIO output.

Note

For detailed information, please refer to the section DIO Module.

7.2.10.2.2. Vector Modules for DIO

Sl.No.	Vector Modules	Description	Significance in use case
1	IoHwAb	The IoHwAb module provides a layer between the ECU software and the hardware. It allows higher-level software to access I/O hardware (like ADCs or DIOs) in a standardized way.	In this use case, IoHwab layer provides wrapper function for each of the underlying ADC API’s, so that the application is independent on the hardware.
2	OS (MICROSAR Operating System)	The Operating System is mainly responsible for handling tasks and interruptions.	In this use case, OS module is used to define periodic tasks needed for ADC communication such as processing transmit and receive message.
3	RTE (MICROSAR Runtime Environment)	The Runtime Environment module manages the information flow between Software Components (SWCs), BSW and CDDs.	In this use case, Rte module is used to schedule the periodic tasks defined in the operating system (OS) and sender receiver ports created for sending receiving can messages from application.
5	DET	The DET is used in order to report development errors. The DET can be replaced optionally by an equivalent component which is responsible for recognizing development errors, if no DET component is available.	In this use Case, Development error is enabled to detect all development errors.

Note

For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector.

Note

For importing MCAL configuration files to DaVinci refer Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator.

7.2.10.3. Configuration of modules in DIO integration

This chapter explains the basic configurations that are needed to realize DIO functionality.

7.2.10.3.1. DIO Configuration

TI DIO driver is configured using EB Tresos tool. It is then imported to Vector DaVinci configurator for integration with upper layers like IoHwAb. Following containers and parameters shall be configured.

DioGeneral:

The DioGeneral contains the enabling and disabling of apis. The following figure shows the enabling DioFlipChannel api -

DioPort:

The DioPort container is used to configure groups of DIO channels (GPIO pins) under a logical port. Each port (e.g., GPIOAB, GPIOCD) is assigned a unique DioPortId for identification. This setup enables efficient handling of multiple pins together using AUTOSAR DIO APIs. The example shows five ports with IDs from 0 to 4 -

DioChannel:

The DioChannel container in the EB Tresos tool is used to configure individual DIO (Digital Input/Output) channels within a specified DIO port. In this example, the port being configured is named GPIOAB. Under the DioChannel tab, each row represents a single DIO channel configuration. Each DIO channel is assigned a unique DioChannelId which acts as an identifier used in the application code for referencing the channel -

The port pin 128 in DIO channel is configured as shown below -

Fig. 7.137 Configuration for Port pin 128

DioChannelGroup:

The DioChannelGroup contains the configuration of DIO port mask and port offset value. The DioChannelGroup configuration is shown below -

7.2.10.3.2. Port Configuration for DIO Integration

The port pin configuration of DIO channel is shown below -

The PortPinMode configuration of DIO channel is shown below -

Fig. 7.140 Configuration for PortpinMode

7.2.10.3.3. IoHwAb Configuration for DIO Integration

The configuration process for determining the IoHwAb_DioFlipChannel API in the IoHwAbCSPortInterfaces container is shown below -

Fig. 7.141 Configuration for DIO IoHwAbCSPortInterface

The configuration process for determining IoHwAbDioFlipChannel API in the IoHwAbCSPortPrototypes container is shown below -

Fig. 7.142 Configuration for DIO IoHwAbCSPortPrototypes

The function call interaction between the IoHwAb module and the Mcal module API is shown below -

Fig. 7.143 Function call between IoHwAb and DIO

7.2.10.3.4. Os Configuration for DIO Integration

The OS module is responsible for task scheduling. Tasks such as 10ms are created to schedule TestApp_DioRunnable. The following figure is shown below -

Fig. 7.144 OsAlarms configuration for DIO

7.2.10.3.5. Rte Configuration for DIO Integration

TestApp_DioRunnable is mapped to a 10ms task and will be called periodically every 10ms by the OS task to execute the runnable.The following figure is shown below -

Fig. 7.145 creating 10ms task for DIO runnable

7.2.11. CDD_I2C Integration

7.2.11.1. Objective for CDD_I2C Integration

The intention of I2C Integration is to enable successful I2C communication by configuring TI MCAL modules along with Vector BSW Modules. Further details are explained in the subsequent chapter.

7.2.11.2. List of Modules for CDD_I2C Integration

7.2.11.2.1. MCAL Modules for CDD_I2C Integration

Sl.No.	MCAL Modules	Description	Significance in use case
1	I2C	I2C (Inter-Integrated Circuit) is a two-wire serial communication protocol using SDA (data) and SCL (clock) lines. It allows a master to communicate with one or more slave devices using unique addresses. I2C is commonly used for connecting low-speed peripherals like sensors, EEPROMs, and displays in embedded systems.	In this use case, this module is responsible for configure I2C channel list and Sequence.
2	Mcu	Manages microcontroller features such as power modes, clock settings, and interrupts.	In this use case this module is used to provide clock for I2C operation.
3	Port	Provides an interface to configure and control microcontroller pins (e.g., GPIO, ADC, PWM).	In this use case, this module is responsible for configuring the hardware pins necessary for I2C communication.

Note

For detailed information, please refer to the section CDD_I2C Module.

7.2.11.2.2. Vector Modules for CDD_I2C Integration

Sl.No.	Vector Modules	Description	Significance in use case
1	IoHwAb	This module provides an abstraction layer for handling hardware-related input/output operations. It facilitates interaction with IPC hardware resources for data exchange between processor cores.	In this use case,it abstracts the IPC driver and facilitates interaction , between the application layer and the underlying inter-core communication mechanism.
2	DET	The DET is used in order to report development errors. The DET can be replaced optionally by an equivalent component which is responsible for recognizing development errors, if no DET component is available.	In this use Case, Development error is enabled to detect all development errors.
3	RTE (MICROSAR Runtime Environment)	The Runtime Environment module manages the information flow between Software Components (SWCs), BSW and CDDs.	In this use case, Rte module is used to schedule the periodic tasks defined in the operating system (OS) and sender receiver ports created for sending receiving can messages from application.

Note

For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector.

Note

For importing MCAL configuration files to DaVinci refer Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator.

7.2.11.3. Configuration modules in CDD_I2C Integration

This chapter explains the basic configurations that are needed to realize CDD I2C communication.

7.2.11.3.1. CDD_I2C Configuration

As part of I2C module integration, I2C module from TI MCAL stack shall be interconnected with vector modules. For that I2C along with its dependent I2C modules shall be configured and provide the reference to other module. As a first step following Containers and parameters shall be configured in I2C module.

I2cGeneral:

General configuration settings for Complex Device Drivers are defined in the container, which includes options to enable or disable API and IRQ types, as shown below -

CddI2cHwConfig:

This container contains the HW unit initialization parameters. The HwUnitType and ChannelBitRate, HwUnitFrequency and ClkInputSrc are shown below -

CddI2cChannelConfig:

This container includes the channel configurations. The I2C channel direction, ChannelSlaveAddress, and SlaveAddressScheme are shown below -

CddI2cSequenceConfig:

This container contains the Sequence configurations. The I2C Channel SequenceHwUnitType, NumberOfChannelsInSequence and SequenceCompleteNotify and SequenceErrorNotify are shown below -

I2cChannelList:

References to I2C channels and their order within the Sequence shown below -

7.2.11.3.2. MCU Configuration for CDD_I2C Integration

The I2C module has dependence on MCU module. Hence, we need to provide clock setting reference in MCU module. Please refer to TechnicalReference_Mcu was used to configure this module. The following figure illustrates the configuration process for determining I2C clock reference point configuration -

Fig. 7.151 Configuration for McuClockSettingConfig_I2C

7.2.11.3.3. Port Configuration for CDD_I2C Integration

In the configuration of the port for the I2C module, the port pins are used to facilitate the I2C data line as shown below -

Fig. 7.152 Configuration for I2C Port pin

Similarly, port pin for I2C clock line can be configured.

7.2.11.3.4. IoHwAb Configuration for CDD_I2C Integration

IoHwAb is a layer in the AUTOSAR architecture that abstracts hardware-level interfaces and provides a standardized API to the upper layers. To configure a Client/Server Port Interface, the container Cdd_I2c_AsyncTransmit holds the configuration elements for a Client/Server template interface. This interface is instantiated by a Client/Server Port Prototype. The container IoHwAbOperationArguments contains the configuration of Operation Elements, such as Cdd_I2c_SetupEB, and IoHwAbOperationArgument, for a Client/Server Operation. These Operation Elements will be generated as function parameters in the I/O Hardware Abstraction (IoHwAb) implementation. Similarly, it is possible to enable communication between the I/O Client/Server interface and the MCAL APIs. Configuration of Cdd_I2c IoHwAbCS port interface as shown below -

Fig. 7.153 Configuration for Cdd_I2C IoHwAbCSPortInterface

The container AsyncTransmit is used for configuring a Client/Server Port Prototype. This container represents an instantiation of a Client/Server Port Interface. Configuration of Cdd_I2c IoHwAbCS port prototype as shown below -

Fig. 7.154 Configuration for Cdd_I2C IoHwAbCSPortPrototypes

The function IoHwAb_Construct_Wrapper is generated, and then the MCAL API function Cdd_I2c_AsyncTransmit is called. In the RTE (Runtime Environment), the corresponding port is created based on the configuration, and it can be used as a Sender-Receiver Port for communication between software components -

Fig. 7.155 Invoking MCAL API Cdd_I2c_AsyncTransmit

The port connection to software component for I2C is shown below -

Fig. 7.156 Port connection to software component for CDD_I2C

7.2.12. ICU Integration

7.2.12.1. Objective for ICU Integration

The objective of ICU integration is to achieve accurate duty cycle measurement of the PWM signal by configuring TI MCAL modules in coordination with Vector BSW modules. Further implementation details are provided in the subsequent chapter.

7.2.12.2. List Of Modules for ICU

7.2.12.2.1. MCAL Modules for ICU Integration

Sl. No.	MCAL Modules	Description	Significance in use case
1	Mcu	The MCU module manages microcontroller features for PWM, such as power modes and clock settings.	In this use case, this module is responsible for providing the clock for PWM signal generation.
2	Port	The PORT module provides an interface to configure and control microcontroller pins (e.g., GPIO, ADC, PWM).	In this use case, this module is responsible for configuring the hardware pins necessary for ICU signal capturing.
3	ICU	The Input Capture Unit (ICU) is a peripheral used to detect and timestamp signal edges (rising/falling) on an input pin. It enables measurement of signal characteristics such as frequency, period, and duty cycle, commonly used for PWM analysis.	In this use case, the ICU is used to measure the duty cycle and period of a signal.

Note

For detailed information, please refer to the section ICU Module.

7.2.12.2.2. Vector Modules for ICU Integration

Sl. No.	Vector Modules	Description	Significance in use case
1	IoHwAb	The aim of the IoHwAb is to provide ECU hardware-independent data transition from driver modules up to the Software Components.	It provides an abstraction for the ICU driver and enables communication with the application layer.
2	DET	The DET is used in order to report development errors. The DET can be replaced optionally by an equivalent component which is responsible for recognizing development errors, if no DET component is available.	In this use Case, Development error is enabled to detect all development errors.
3	RTE (MICROSAR Runtime Environment)	The Runtime Environment module manages the information flow between Software Components (SWCs), BSW and CDDs.	In this use case, Rte module is used to schedule the periodic tasks defined in the operating system (OS) and sender receiver ports created for sending receiving can messages from application.

Note

For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector.

Note

For importing MCAL configuration files to DaVinci refer Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator.

7.2.12.3. Configuration of modules in ICU Integration

This chapter explains the basic configurations that are needed to realize ICU functionalities.

7.2.12.3.1. ICU Configuration

The TI ICU driver is configured using the EB Tresos tool. It is then imported into the Vector DaVinci Configurator for integration with the application software. The following containers and parameters shall be configured.

IcuGeneral:

Configuration of general ICU parameters involves enabling or disabling the required macros, as shown below -

IcuChannel:

The configuration of an individual ICU channel involves assigning the IcuChannelId, selecting the appropriate mode (e.g., timestamp or edge detection), setting the XBAR (crossbar) references, and configuring the ICU functional clock. These settings define how the channel will operate and interface with hardware resources, as illustrated in the configuration below -

IcuSignalMeasurement:

This container holds the configuration parameters for the measurement mode set to IcuSignalMeasurement. In this configuration, the signal measurement property is set to ICU_PERIOD_TIME to enable period time measurement of the input signal -

7.2.12.3.2. MCU Configuration in ICU Module

The following figure demonstrates the configuration of the ECAP0 interrupt within the MCU module for AM263Px. In this setup, the ECAP0 interrupt is routed through the XBAR (Crossbar) configuration. Specifically, MCU_INTRXBAR0_OUT_2 is selected as the output line, which is then mapped to MCU_INT_XBAR_EPWM3_INT. This routing enables the ECAP0 event to be captured correctly by the desired interrupt source -

Fig. 7.160 Configuration for McuXbarChannelTrigger Configuration

The following configuration illustrates the setup of an input XBAR trigger channel within the MCU module. In this example, MCU_INPUT_XBAR0_OUT_2 is selected as the output XBAR line, and it is mapped to the input source MCU_INPUT_XBAR_GPIO49. This mapping allows an external signal on GPIO49 to be routed through XBAR0 output channel 2, enabling it to trigger peripherals such as ECAP, EPWM, or other interrupt-driven modules -

Fig. 7.161 Configuration for McuInputXbarChannelTrigger Configuration

7.2.12.3.3. Port Configuration in ICU Module

The PWM module has a dependency on the Port module to configure the output pins used for generating PWM signals. Each PWM channel is mapped to a specific physical pin on the microcontroller, which must be configured as an output using the Port module.

In the port pin configuration, EPWM3 is configured as a PWM output, as shown below -

7.2.12.3.4. IoHwAb Configuration in ICU Module

IoHwAb is a layer in the AUTOSAR architecture that abstracts hardware-level interfaces and provides a standardized API to the upper layers. To configure a Client/Server Port Interface, the container IoHwAb_IcuStartSignalMeasurement holds the configuration elements for a Client/Server template interface. This interface is instantiated by a Client/Server Port Prototype. The container IoHwAbOperationArguments contains the configuration of Operation Elements, such as Channel for a Client/Server Operation. These Operation Elements will be generated as function parameters in the I/O Hardware Abstraction (IoHwAb) implementation. Similarly, it is possible to enable communication between the I/O Client/Server interface and the MCAL APIs. Configuration of ICU IoHwAbCS port interface as shown below -

Fig. 7.163 Configuration of ICU CSPortinterface

The container IoHwAbIcuStartSignalMeasurement is used for configuring a Client/Server Port Prototype. This container represents an instantiation of a Client/Server Port Interface. Configuration of cddIcu IoHwAbCS port prototype as shown below -

Fig. 7.164 Configuration of ICU PortPrototype

The function IoHwAb_IcuStartSignalMeasurement Operation is generated, and then the MCAL API function Icu_StartSignalMeasurement is called. In the RTE (Runtime Environment), the corresponding port is created based on the configuration, and it can be used as a Sender-Receiver Port for communication between software components -

Fig. 7.165 Invoking MCAL API for Icu_StartSignalMeasurement

7.2.13. GPT Integration

7.2.13.1. Objective for GPT Integration

The intention of GPT Integration is to verify successful GPT functionalities by configuring TI MCAL modules along with Vector BSW Modules. Further details are explained in the subsequent chapter.

7.2.13.2. List of Modules for GPT Integration

7.2.13.2.1. MCAL Modules for GPT Integration

Sl. No.	MCAL Modules	Description	Significance in use case
1	Mcu	The MCU module manages microcontroller features for PWM, such as power modes and clock settings.	In this use case, this module is responsible for providing the clock for GPT module.
2	GPT	The GPT module initializes and manages hardware timers, enabling start/stop control, time value reading, and interrupt notifications. It operates in timer ticks, and conversion to real-time units must be handled by the application using clock and prescaler settings.	In this use case, this module responsible for providing 1ms toggling of DIO port pin in continuous mode.

Note

For detailed information, please refer to the section GPT Module.

7.2.13.2.2. Vector Modules for GPT Integration

Sl. No.	Vector Modules	Description	Significance in use case
1	IoHwAb	The aim of the IoHwAb is to provide ECU hardware-independent data transition from driver modules up to the Software Components.	It provides an abstraction for the ICU driver and enables communication with the application layer.
2	DET	The DET is used in order to report development errors. The DET can be replaced optionally by an equivalent component which is responsible for recognizing development errors, if no DET component is available.	In this use Case, Development error is enabled to detect all development errors.
3	RTE (MICROSAR Runtime Environment)	The Runtime Environment module manages the information flow between Software Components (SWCs), BSW and CDDs.	In this use case, Rte module is used to schedule the periodic tasks defined in the operating system (OS) and sender receiver ports created for sending receiving can messages from application.

Note

For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector.

Note

For importing MCAL configuration files to DaVinci refer Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator.

7.2.13.3. Configuration of modules in GPT Integration

This chapter explains the basic configurations that are needed to realize GPT functionalities.

7.2.13.3.1. GPT Configuration

GptConfigurationOfOptApiServices:

This container contains all configuration switches for configuring the optional API services of the GPT driver. The following figure shows the enabling of Api’s -

GptDriverConfiguration:

This container contains the module-wide configuration (parameters) of the GPT Driver. The following figure shows the configuration of interrupt function and prescaler value and Gpt timeout duration -

GptChannelConfiguration:

This container serves as the base of a Configuration Set, holding the configured GPT channels. It allows definition of multiple configuration sets for post-build usage, where each GPT channel is assigned a channel ID, mode, and optional notification function -

7.2.13.3.2. Mcu Configuration in GPT Integration

The GPT module relies on the MCU module to supply the necessary clock configurations. The MCU clock configuration for GPT driver is shown below -

Fig. 7.169 Configuration for McuClockSettingConfig

GPT clock should be derived from MCU clock reference point. The MCU clock reference point is shown below -

7.2.13.3.3. IoHwAb Configuration in GPT Integration

IoHwAb is a layer in the AUTOSAR architecture that abstracts hardware-level interfaces and provides a standardized API to the upper layers. To configure a Client/Server Port Interface, the container IoHwAb_GptStartTimer holds the configuration elements for a Client/Server template interface. This interface is instantiated by a Client/Server Port Prototype. The container IoHwAbOperationArguments contains the configuration of Operation Elements, such as Channel for a Client/Server Operation. These Operation Elements will be generated as function parameters in the I/O Hardware Abstraction (IoHwAb) implementation. Similarly, it is possible to enable communication between the I/O Client/Server interface and the MCAL APIs. Configuration of ICU IoHwAbCS port interface as shown below -

Fig. 7.171 Configuration of GPT CSPortinterface

The container IoHwAbGptStartTimer is used for configuring a Client/Server Port Prototype. This container represents an instantiation of a Client/Server Port Interface. Configuration of Gpt IoHwAbCS port prototype as shown below -

Fig. 7.172 Configuration of GPT PortPrototype

The function IoHwAb_GptStartTimer Operation is generated, and then the MCAL API function Icu_StartSignalMeasurement is called. In the RTE (Runtime Environment), the corresponding port is created based on the configuration, and it can be used as a Sender-Receiver Port for communication between software components -

Fig. 7.173 Invoking MCAL API for Gpt_StartTimer

7.2.14. CDD FSI Integration

7.2.14.1. Objective for CDD FSI Integration

The intention of CDD FSI Integration is to enable successful CDD FSI communication by configuring TI MCAL modules along with Vector BSW Modules. Further details are explained in the subsequent chapter.

7.2.14.2. List of Modules for CDD FSI Integration

7.2.14.2.1. MCAL Modules for CDD FSI Integration

Sl. No.	MCAL Modules	Description	Significance in use case
1	FsiRx	The Fast Serial Interface (FSI) is a high-speed serial communication module designed for reliable data transfer, especially across isolation barriers without needing extra components. It includes two separate parts: the CDD FSI Transmitter (CDD FSI TX) and the CDD FSI Receiver (CDD FSI RX). These are implemented as Complex Device Drivers (CDD) in AUTOSAR and work independently from each other.	In this use case, this module is responsible for reception of transmitted data.
2	FsiTx	The Fast Serial Interface (FSI) is a high-speed serial communication module designed for reliable data transfer, especially across isolation barriers without needing extra components. It includes two separate parts: the CDD FSI Transmitter (CDD FSI TX) and the CDD FSI Receiver (CDD FSI RX). These are implemented as Complex Device Drivers (CDD) in AUTOSAR and work independently from each other.	In this use case, this module is responsible for transmitting data frames.
3	Mcu	The MCU module manages microcontroller features for PWM, such as power modes and clock settings.	In this use case, this module is responsible for providing the clock for FSI clock generation.

Note

For detailed information, please refer to the section FSIRX Module. For detailed information, please refer to the section FSITX Module.

7.2.14.2.2. Vector Modules for CDD FSI Integration

Sl. No.	Vector Modules	Description	Significance in use case
1	IoHwAb	The aim of the IoHwAb is to provide ECU hardware-independent data transition from driver modules up to the Software Components.	It provides an abstraction for the CDD FSI driver and enables communication with the application layer.
2	DET	The DET is used in order to report development errors. The DET can be replaced optionally by an equivalent component which is responsible for recognizing development errors, if no DET component is available.	In this use Case, Development error is enabled to detect all development errors.
3	RTE (MICROSAR Runtime Environment)	The Runtime Environment module manages the information flow between Software Components (SWCs), BSW and CDDs.	In this use case, Rte module is used to schedule the periodic tasks defined in the operating system (OS) and sender receiver ports created for sending receiving can messages from application.

Note

For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector.

Note

For importing MCAL configuration files to DaVinci refer Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator.

7.2.14.3. Configuration of modules in CDD FSI Integration

This chapter explains the basic configurations that are needed to realize CDD FSI communication.

7.2.14.3.1. FsiRx Configuration

CddFsiRxConfigSet:

This container contains the configuration parameters and sub containers of the AUTOSAR CDD FSI Rx module. The configuration below shows the configuration of callback functions configuration -

CddFsiRxGeneral:

The CDDFsiRxGeneral contains the enabling and disabling required apis and gives interrupt function type, interrupt vector, number of DMA channelIds and MaxHwUnitCount as shown below -

CddFsiRxHwUnit:

This container holds the driver configuration parameters used to set up the CDD FSI Rx hardware unit. The configuration includes the HwUnitId, RxPingWdgTimerTimeout, RxFrameWdgTimerTimeout, and the CDD FSI Rx reception method, which can be set to Interrupt mode, Polling mode, or DMA mode. The figure below illustrates a configuration where the reception method is set to Interrupt mode -

7.2.14.3.2. FsiTx Configuration

CddFsiTxConfigSet:

This container contains the configuration parameters and sub containers of the AUTOSAR CDD FSI Tx module. The configuration below shows the configuration of callback functions configuration -

CddFsiTxGeneral:

The CDDFsiTxGeneral contains the enabling and disabling required apis and gives interrupt function type, interrupt vector, number of DMA channelIds and MaxHwUnitCount as shown below -

CddFsiTxHwUnit:

This container holds the driver configuration parameters used to set up the CDD FSI Tx hardware unit. The configuration includes the HwUnitId, TxPingTimerTimeout, TxPrescale, and the CDD FSI Tx transmission method, which can be set to Interrupt mode, Polling mode, or DMA mode. The figure below illustrates a configuration where the reception method is set to Interrupt mode.

7.2.14.3.3. port configuration for CDD FSI Integration

The CDD FSI Rx module has a dependency on the Port module to configure the output pins used. Each CDD FSI Rx channel is mapped to a specific physical pin on the microcontroller, which must be configured as an output using the Port module. Configuration of a CDD FSI Rx CLK pin is as shown below. The following figure shows port pin configuration of CDD FSI Rx where PIN_E1 is configured as FSIRX1_CLK -

Fig. 7.180 configuration for FsiRx1_CLK

The CDD FSI Tx module has a dependency on the Port module to configure the output pins used. Each CDD FSI Tx channel is mapped to a specific physical pin on the microcontroller, which must be configured as an output using the Port module. Configuration of a CDD FSI Tx CLK pin is as shown below. The following figure shows port pin configuration of CDD FSI Tx where PIN_E4 is configured as FSITX1_CLK -

Fig. 7.181 configuration for FsiTx1_CLK

7.2.14.3.4. IoHwAb configuration for CDD FSI Integration

IoHwAb is a layer in the AUTOSAR architecture that abstracts hardware-level interfaces and provides a standardized API to the upper layers. To configure a Client/Server Port Interface, the container IoHwAb_Cdd_FsiRx_GetStatus holds the configuration elements for a Client/Server template interface. This interface is instantiated by a Client/Server Port Prototype. The container IoHwAbOperationArguments contains the configuration of Operation Elements, such as Channel for a Client/Server Operation. These Operation Elements will be generated as function parameters in the I/O Hardware Abstraction (IoHwAb) implementation. Similarly, it is possible to enable communication between the I/O Client/Server interface and the MCAL APIs. Configuration of ICU IoHwAbCS port interface as shown below -

Fig. 7.182 Configuration of CDD FSI CSPortinterface

The container IoHwAbCddFsiRxGetStatus is used for configuring a Client/Server Port Prototype. This container represents an instantiation of a Client/Server Port Interface. Configuration of cddFsi IoHwAbCS port prototype as shown below -

Fig. 7.183 Configuration of CDD FSI PortPrototype

The function IoHwAb_CddFsiRxGetStatus Operation is generated, and then the MCAL API function CddFsiRx_GetStatus is called. In the RTE (Runtime Environment), the corresponding port is created based on the configuration, and it can be used as a Sender-Receiver Port for communication between software components -

Fig. 7.184 Invoking MCAL API for CddFsiRx_GetStatus

7.2.15. CDD_UART Integration

7.2.15.1. Objective for CDD_UART Integration

The intention of UART Integration is to enable successful UART communication by configuring TI MCAL modules along with Vector BSW Modules. Further details are explained in the subsequent chapter.

7.2.15.2. List of Modules for CDD_UART Integration

7.2.15.2.1. MCAL Modules for CDD_UART Integration

Sl.No.	MCAL Modules	Description	Significance in use case
1	UART	The UART module initializes and controls the internal UART peripherals of the microcontroller. It provides services to configure baud rate, frame format, and to transmit and receive data over serial communication channels.	In this use case UART module is responsible for enabling serial communication between the microcontroller and external devices. Moreover it facilitates reliable data transmission and reception through asynchronous communication.
2	Mcu	The MCU module manages microcontroller features for UART, such as clock configuration, power modes, and interrupt settings required for UART communication.	In this use case, this module is responsible for providing the clock and initialization required for UART-based serial communication between the microcontroller and external devices.
3	Port	The PORT module provides an interface to configure and control the microcontroller pins used for UART communication, such as setting the TX and RX pins to the appropriate functions.	In this use case, this module is responsible for configuring the hardware pins necessary for UART communication, such as setting the TX and RX pins to their correct functions.

Note

For detailed information, please refer to the section CDD_UART Module.

7.2.15.2.2. Vector Modules for CDD_UART Integration

Sl.No.	Vector Modules	Description	Significance in use case
1	IoHwAb	This module provides an abstraction layer for handling UART operations, enabling seamless interaction with UART hardware channels.	It provides an abstraction for the UART driver and enables communication with the application layer.
2	OS	The Operating System is mainly responsible for handling tasks.	In this use case, it is used to initialize UART and manage UART-related task scheduling.
3	Rte	The Runtime Environment module manages the information flow between software components and the ECU abstraction layers.	In this use case, it is used to schedule and route UART communication tasks between the application and lower layers.

Note

For detailed information on each module and its features, please refer to the Technical Reference Manual provided by Vector.

Note

For importing MCAL configuration files to DaVinci refer Importing TI MCAL modules from EB Tresos to Vector DaVinci Configurator.

7.2.15.3. Configuration of modules in CDD_UART Integration

This chapter explains the basic configurations that are needed to realize CDD UART functionalities.

7.2.15.3.1. CDD_UART Configuration

The UART driver is configured using the EB Tresos tool and then imported into the Vector DaVinci Configurator for integration with the application software. The following containers and parameters should be configured.

CDD_UART General:

The UART General container provides general configuration settings for the UART module.

In UART general settings, CddUartReadApi, CddUartWriteApi and CddUartirq Type is enabled as shown below -

Fig. 7.185 Configuration for CDD_UART General settings

CDD_UART Channel:

The CddUartChannel configuration container defines the configuration parameters for an individual UART channel.

In CddUartChannel configuration, The user needs to specify the CddUartHwID and CddUartIOMode as shown below -

Fig. 7.186 Configuration of CddUarChannel settings

7.2.15.3.2. Mcu Configuration for CDD_UART Integration

The UART module relies on the MCU module to supply the necessary clock configurations.

The MCU clock configuration for UART driver is shown below -

Fig. 7.187 General Configuration of MCU Clock

UART clock should be derived from MCU clock reference point.

The MCU clock reference point is shown below -

7.2.15.3.3. Port Configuration for CDD_UART Integration

The UART module has a dependency on the Port module to configure the pins used for UART communication. Each UART channel is mapped to specific physical pins on the microcontroller, which must be configured as the appropriate alternate functions (TX/RX) using the Port module.

In the port pin configuration, select PortPinPeripheral, PortPinPeripheralSignal, and PortPinDirection as shown below -

Similarly, port pin for UART RX can be configured.

7.2.15.3.4. IoHwAb Configuration for CDD_UART Integration

IoHwAb is a layer in the AUTOSAR architecture that abstracts hardware-level interfaces and provides a standardized API to the upper layers.

To configure a Client/Server Port Interface, the container IoHwAbCS_Uart_read holds the configuration elements for a Client/Server template interface. This interface is instantiated by a Client/Server Port Prototype.

The container IoHwAbOperationArguments contains the configuration of Operation Elements, such as ChannelID, Length, Timeout, UartDestBufferptr for a Client/Server Operation. These Operation Elements will be generated as function parameters in the I/O Hardware Abstraction (IoHwAb) implementation.

Similarly, it is possible to enable communication between the I/O Client/Server interface and the MCAL APIs.

Configuration of UART IoHwAbCS port interface as shown below -

Fig. 7.190 Configuration of cdduart CSPortinterface

The container IoHwAbCSUar_read is used for configuring a Client/Server Port Prototype. This container represents an instantiation of a Client/Server Port Interface.

Configuration of cdduart IoHwAbCS port prototype as shown below -

Fig. 7.191 Configuration of cdduart PortPrototypes

The function IoHwAb_IoHwAbCSUart_read_IoHwAbOperation is generated, and then the MCAL API function Cdd_Uart_Read is called.

In the RTE (Runtime Environment), the corresponding port is created based on the configuration, and it can be used as a Sender-Receiver Port for communication between software components -

Fig. 7.192 Invocking MCAL API for Cdd Uart Read