What is CAN

Controller Area Network (CAN) is a communication protocol for real-time data exchange. It enables high-speed, communication between multiple ECUs without the need for a central host controller. CAN is known for its reliability, fault tolerance, and deterministic behavior, making it ideal for safety-critical and time-sensitive applications.

Functions and Responsibilities

1. Sending and Receiving Messages:

The CAN module in the MCAL provides functionalities for sending and receiving CAN messages between ECUs on the network.
It encapsulates data into CAN frames and transmits them over the CAN bus.
It also rec
Receives incoming CAN frames from other ECUs and processes them accordingly.

2. Frame Filtering and Buffering:

CAN modules typically support filtering mechanisms to selectively receive messages based on message identifiers (IDs).
The MCAL's CAN module configures filters and manages message buffering to ensure that only relevant messages are processed by the ECU.

3. Error Handling and Management:

CAN communication is subject to various error conditions such as bit errors and frame errors.
The CAN module in MCAL monitors the bus for error conditions and implements error handling mechanisms as per the CAN protocol specification.
It manages error counters and implements bus-off recovery procedures to restore communication in case of bus-off states.

4. Bus Arbitration and Collision Avoidance:

CAN uses a non-destructive bitwise arbitration mechanism to determine message priority and resolve bus conflicts.
The CAN module in the MCAL handles bus arbitration and collision avoidance to ensure that messages are transmitted in a deterministic and collision-free manner.

5.Clock Synchronization:

CAN communication relies on accurate clock synchronization between ECUs to maintain the integrity of the data transmission.
MCAL's CAN module may include functionalities for clock synchronization and drift compensation to ensure reliable communication across the network.

6. Interrupt Handling:

CAN modules can generate interrupts to notify the microcontroller about incoming messages, error conditions, and bus status changes.
The MCAL's CAN module configures and manages interrupt sources, allowing the microcontroller to handle CAN-related events in a timely manner.

Integration with Higher-Level Software Layers

The CAN module in the MCAL serves as the low level driver sitting between the hardware and the higher-level software layers in the automotive software stack. It provides standardized APIs for sending and receiving CAN messages, allowing upper layers such as the AUTOSAR Basic Software (BSW) and application software to communicate with other ECUs on the network.

MCAL Configurations

CanGeneral

CanDevErrorDetect

This parameter controls the error detection mechanism for the CAN driver. It should be set based on your error handling strategy. Here are the options

ON: Error detection mechanism is enabled. Use this if you want the CAN driver to detect errors runtime errors.
OFF: Error detection mechanism is disabled. Use this if you want to minimize runtime overhead and rely on external handling mechanisms.

Enable for comprehensive detection and handling of development errors within the CAN driver. Implement error handling routines to log, notify, or handle detected errors appropriately.

CanInitDeInitApiMode

This configuration parameter defines the mode in which the CAN Init and CAN DeInit API will be used.

Choose the initialization and de-initialization API mode for the CAN driver. Select between user mode and supervisor mode based on system security requirements and access privileges.

CanMultiCoreErrorDetect

This parameter controls error detection for multicore for multicore environments.

ON: Enables error detection for multicore.
OFF: Disables error detection for multicore.

Enable to ensure synchronization and error detection across multiple cores in multi-core systems. Configure error detection thresholds and mechanisms to maintain system integrity.

CanIndex

This parameter specifies the index of the CAN hardware channel. Value ranging from 0 to 255.

Assign a unique index to the CAN controller instance. Ensure that each controller has a distinct index for identification and communication setup within the system.

CanMainFunctionModePeriod

This parameter determines the main function mode period, which is the time interval for calling the main function of the CAN driver.

It's represented in milliseconds with a range from 0.001 to 65.535

Set the period for the main function mode, specifying how often the main function is executed. Adjust the period based on application requirements and system responsiveness needs.

CanMultiplexedTransmission

This parameter controls wheter multiplexed transmission is supported, you should set it if it's applicable for your microcontroller.

ON: Multiplexed transmission is supported.
OFF: Multiplexed transmission is not supported.

Enable multiplexed transmission for efficient utilization of CAN bandwidth. Configure transmission priorities and scheduling algorithms to optimize data transmission.

CanTimeoutDuration

This Parameter sets timeout duration for internal timeout monitoring of the CAN driver functions.

It's represented in microseconds with a range from 0.000001 to 65.535.

CanVersionInfoApi

This Parameter enables or disables the API to read version information of the CAN driver module.

ON: Enables version information API.
OFF: Disables version information API.

Enable the Version Information API to retrieve information about the CAN driver version. Use this information for diagnostics, compatibility checks, and version-specific feature utilization.

CanSupportTTCANRef

This parameter indicates whether Time-Triggered CAN (TTCAN) is supported or not.

Enable support for Time-Triggered CAN (TTCAN) if required. Configure TTCAN-specific settings and parameters to enable time-triggered communication functionality within the CAN network.

CanRunTimeErrorDetect

This parameter controls the runtime error detection mechanism.

ON: Enables runtime error detection.
OFF: Disables runtime error detection.

Activate runtime error detection to monitor and handle errors occurring during runtime. Implement error detection mechanisms such as error codes, interrupts, or error counters to ensure robust error handling.

CanIcom

This parameter group contains settings for configuring pretended networking, a feature used to simulate network communication for testing or development purposes.

Configure ICOM (Integrated Communication Controller) settings based on the requirements of your application. Enable features such as network management and message routing as needed.

CanLPduReceiveCalloutFunction:

Specifies whether a specific function, known as a callout function, is called after successfully receiving a Low Priority Protocol Data Unit (LPDU) message. This function can be used for custom processing or handling of received messages.

Define a callout function to handle received Low Priority Protocol Data Units (LPDUs). Implement custom logic or processing within the callout function to respond to incoming messages effectively.

CanMainFunctionBusoffPeriod:

Indicates the interval, in seconds, at which the function Can_MainFunction_Busoff is called cyclically. This function typically handles bus-off events, ensuring the CAN controller recovers from error states effectively.

Specify the period for cyclic calls to the main function for handling bus-off events. Adjust the period based on bus-off recovery requirements and system responsiveness needs.

CanMainFunctionWakeupPeriod:

Defines the frequency, in seconds, at which the function Can_MainFunction_Wakeup is invoked cyclically. This function manages wake-up events, allowing the CAN controller to respond promptly when a wake-up signal is detected on the bus.

Set the period for cyclic calls to the main function for handling wake-up events. Configure the period based on wake-up signal detection requirements and system responsiveness needs.

CanSetBaudrateApi:

Specifies whether the CAN driver supports the optional API function Can_SetBaudrate. This function allows dynamic adjustment of the CAN communication speed during runtime, providing flexibility in adapting to changing network conditions.

If supported, use the Set Baudrate API to dynamically adjust the CAN communication speed during runtime. Implement error handling and validation mechanisms to ensure safe baud rate changes.

CanEcucPartitionRef:

Maps the CAN driver to one or more ECUC partitions, enabling the driver's API functions to be accessible within each partition independently. This facilitates modular software design and integration, allowing the CAN driver to operate as a separate instance within each partition.

Map the CAN driver to one or more ECUC partitions to make the driver's API available within each partition. Configure partition mapping based on software architecture and partitioning requirements.

CanOsCounterRef:

Contains a reference to the OsCounter, an operating system counter utilized by the CAN driver for timing and scheduling purposes. This parameter ensures synchronization with the system clock or other timing mechanisms, enhancing the reliability of CAN communication.

Assign a reference to the OsCounter used by the CAN driver for timing and scheduling purposes. Configure counter synchronization and resolution settings to ensure accurate timing within the CAN module.

CanIcomGeneral:

This parameter group encompasses general configuration settings for the Integrated Communication Controller (ICOM) feature. It includes fundamental parameters essential for configuring ICOM functionality within the CAN module.

Configure general parameters for the Integrated Communication Controller (ICOM) as needed for your application. Adjust settings such as communication mode and error handling to match system requirements.

CanMainFunctionRWPeriods:

This parameter group defines the periods for cyclic calls to either Can_MainFunction_Read or Can_MainFunction_Write, depending on the referring item. These functions manage read and write operations within the CAN module, ensuring efficient data exchange between the CAN controller and application software.

Set the periods for cyclic calls to the main function for reading and writing CAN messages. Adjust these periods based on message frequency and system responsiveness requirements.

CanController

CanBusoffProcessing:

This parameter determines whether the CAN driver should handle bus-off events.

POLLING: Bus-off processing is handled via polling. The driver periodically checks the bus-off state and attempts recovery if necessary.
INTERRUPT: Bus-off processing is handled via interrupts. The driver responds to bus-off events immediately upon occurrence.

Enable to handle bus-off events within the CAN driver. Configure bus-off recovery mechanisms and error handling strategies to ensure minimal disruption to communication.

CanControllerActivation:

Defines if a CAN controller is used in the configuration.

ON: Activates the CAN controller.
OFF: Deactivates the CAN controller.

Specify activation settings for the CAN controller. Configure activation triggers and conditions to ensure the controller operates only when required, conserving system resources.

CanRxInputSelection:

This parameter specifies the input selection for CAN receive functionality. Options depend on the hardware configuration and pin assignments. Typically, you select the appropriate input pin for CAN reception.

Select the input source for CAN message reception. Choose between hardware-based inputs or software-based inputs depending on system configuration and compatibility.

CanControllerBaseAddress:

This parameter defines the base address of the CAN controller in memory. It's a numerical value ranging from 0 to 4294967295, depending on the memory mapping of your microcontroller.

Define the base address for the CAN controller registers. Ensure compatibility with hardware specifications and address mapping requirements of the microcontroller.

CanControllerId:

This parameter provides the controller ID which is unique in a given CAN Driver. The value for this parameter starts with 0 and continue without any gaps.

Assign a unique identifier to the CAN controller. Use this identifier for device identification and communication setup in multi-controller systems.

CanRxProcessing:

This parameter determines the mode of receive message processing, Enables / disables API Can_MainFunction_Read() for handling PDU reception events in polling mode.

Configure settings related to message reception within the CAN controller. Adjust buffer sizes, filtering criteria, and interrupt handling to optimize reception performance.

CanTxProcessing:

This parameter determines the mode of transmit message processing, Enables / disables API Can_MainFunction_Write() for handling PDU transmission events in polling mode.

Configure settings related to message transmission within the CAN controller. Adjust priority levels, transmission scheduling, and error handling to optimize transmission performance.

CanWakeupFunctionalityAPI:

This parameter specifies the availability of the wakeup functionality API, Adds / removes the service Can_CheckWakeup() from the code.

ON: Enables the wakeup functionality API.
OFF: Disables the wakeup functionality API.

Enable support for wakeup functionality API within the CAN driver. Implement wakeup functionality as needed for power management and system wakeup requirements.

CanWakeupProcessing:

This parameter controls the processing of wakeup events, Enables / disables API Can_MainFunction_Wakeup() for handling wakeup events in polling mode.

Configure wakeup processing settings for the CAN controller. Specify wakeup detection mechanisms and actions to be taken upon detecting a wakeup event, such as activating the controller or initializing communication.

CanWakeupSupport:

This parameter indicates whether wakeup functionality is supported.

ON: Wakeup functionality is supported.
OFF: Wakeup functionality is not supported.

Enable support for wakeup functionality within the CAN controller hardware. Configure wakeup sources and wakeup signal detection mechanisms to meet system requirements.

CanControllerDefaultBaudrate:

This parameter defines the default baud rate for the CAN controller. Specify the default baud rate value according to your application requirements and network configuration.

Reference to baudrate configuration container configured for the CAN Controller.

Specify the default baud rate for the CAN controller(s) if applicable. Set the baud rate to a standard value compatible with the communication network or adjust it according to specific requirements.

CanCpuClockRef:

This parameter refers to the reference clock for the CPU. Typically, this is a clock signal used by the CPU for timing and synchronization purposes.

Reference to the CPU clock configuration, which is set in the MCU driver configuration.

Specify the reference to the CPU clock used by the CAN controller. Ensure proper synchronization and timing alignment between the CAN module and the CPU.

CanPeripheralBusClockRef:

This parameter refers to the reference clock for the CAN peripheral bus.This clock signal is used by the CAN controller for timing and synchronization with other nodes on the CAN bus.

Reference to the CPU peripheral bus clock configuration, which is set in the MCU driver configuration.

Define the reference to the peripheral bus clock used by the CAN controller. Ensure proper clock configuration and synchronization for reliable CAN communication.

CanControllerEcucPartitionRef:

This parameter allows mapping the CAN controller to zero or one ECUC partitions. ECUC partitions are subsets of where the CAN driver is mapped, providing flexibility in organizing and isolating resources within the system.

Map the CAN controller to one or more ECUC partitions based on system architecture and partitioning requirements. Ensure that the CAN driver's API is available within each partition as needed.

CanWakeupSourceRef:

Contains a reference to the Wakeup Source specific to this controller, as defined in the ECU State Manager. This reference is crucial for handling wake-up events effectively, ensuring the controller responds appropriately to wake-up signals.

Define the wakeup source for the CAN controller as specified in the ECU State Manager. Configure the wakeup source detection mechanisms and criteria to ensure timely and reliable wake-up functionality.

CanControllerBaudrateConfig:

This parameter group includes configuration parameters related to bit timing for the CAN controller(s). Bit timing settings are essential for establishing communication speed and synchronization within the CAN network, ensuring reliable data transmission.

Configure the bit timing parameters for the CAN controller(s) to establish communication baud rates. Set appropriate values for propagation delay, phase segments, and synchronization to ensure reliable data transmission.

CanTTController:

CanTTController is a subset of the SWS TTCAN and encompasses configuration parameters specific to the Time-Triggered CAN (TTCAN) controller(s). In addition to standard CAN controller configuration, these parameters are necessary for enabling and configuring TTCAN functionality within the system.

Specify configuration parameters for Time-Triggered CAN (TTCAN) controller(s) in addition to standard CAN controller configurations. Adjust TTCAN-specific settings such as time synchronization and message scheduling to meet real-time communication requirements.

CanHardwareObject

CanHandleType:

This parameter defines the type of the CAN handle, which represents a logical entity used for transmitting or receiving CAN messages.

The handle type might be defined by your development environment or framework and could include options such as transmit handles, receive handles, or error handles.

Full: Offers comprehensive features and customization options for CAN communication, suitable for applications requiring advanced functionality and extensive control.
Basic: Provides essential functionality with simplified configuration, ideal for applications with straightforward requirements or limited resources.

Define the handle type for CAN message objects. Choose between "full" and "basic" handle types based on the level of functionality required for message handling in the application.

CanHwObjectCount:

This parameter specifies the Number of hardware objects used to implement one HOH. In case of a HRH this parameter defines the number of elements in the hardware FIFO

or the number of shadow buffers, in case of a HTH it defines the number of hardware objects used for multiplexed transmission or for a hardware FIFO used by a FullCAN HTH.

Specify the number of hardware objects (HOBJs) available for message reception and transmission. Adjust the count based on the number of messages to be processed concurrently and hardware limitations.

CanHwFIFOThreshold:

This parameter sets the FIFO (First-In-First-Out) threshold level for the hardware FIFO buffer in the CAN controller.

It's a numerical value ranging from 1 to 64, indicating the number of messages that must be present in the FIFO before an interrupt or event is triggered.

Set the threshold level for hardware FIFOs (First-In-First-Out buffers) used for message buffering. Configure the threshold to optimize memory usage and minimize message loss during high-load scenarios.

CanIdType:

This parameter specifies the type of identifier used in CAN messages.

It could include options such as standard identifiers (11-bit) or extended identifiers (29-bit), depending on the CAN protocol and message format used in your application.

Standard: Uses 11-bit identifiers for CAN messages, suitable for applications with basic addressing needs.
Mixed: Supports a combination of both 11-bit (standard) and 29-bit (extended) identifiers, providing flexibility in addressing.
Extended: Uses 29-bit identifiers, offering a larger address space for applications requiring more unique identifiers or higher-priority messages.

Define the identifier type used for CAN messages, such as standard or extended identifiers. Choose the appropriate type based on the addressing requirements and message format of the application.

CanObjectId:

This parameter represents the object identifier for a specific hardware object within the CAN controller. Holds the handle ID of HRH or HTH. The value of this parameter is unique in a given CAN Driver,

and it should start with 0 and continue without any gaps.The object identifier may be dynamically assigned or configured based on the hardware configuration and the requirements of your application.

Specify the object type for CAN message handling, such as transmit, receive, or both. Configure object types based on the communication needs and message flow within the system.

CanObjectType:

This parameter defines the type of object within the CAN controller, such as transmit object, receive object, or FIFO object. Specifies if the HardwareObject is used as Transmit or as Receive object

Specify the object type for CAN message handling, such as transmit, receive, or both. Configure object types based on the communication needs and message flow within the system.

CanControllerRef:

This parameter references the CAN controller to which the hardware object belongs. It associates the hardware object with a specific CAN controller within the microcontroller, enabling communication between the hardware object and the controller.

Assign a reference to the CAN controller for identification and communication setup purposes. Ensure that the reference is unique and consistent across the system.

CanFdPaddingValue:

Specifies the value used to pad unspecified data in CAN FD frames larger than 8 bytes for transmission. This padding is necessary due to the discrete possible values of the Data Length Code (DLC) if the frame size exceeds 8 bytes.

Set the padding value used for CAN FD frames larger than 8 bytes. Choose an appropriate value to ensure correct frame formatting and data integrity during transmission.

CanHardwareObjectUsesPolling:

Enables polling of this hardware object, indicating whether the CAN hardware object utilizes a polling mechanism for handling transmission or reception tasks.

Enable polling for hardware objects if required for message reception and transmission. Configure polling settings to optimize CPU usage and system responsiveness.

CanTriggerTransmitEnable:

Defines whether the CAN controller supports the trigger-transmit API for the specified handle. The trigger-transmit API allows for asynchronous transmission of CAN messages based on predefined triggers.

Enable support for the trigger-transmit API for CAN message transmission. Implement trigger conditions and mechanisms to initiate transmission based on predefined events or triggers.

CanMainFunctionRWPeriodRef:

This parameter is a reference to the period configuration for cyclic calls to the read or write main functions (Can_MainFunction_Read or Can_MainFunction_Write).

Specify the reference to the period configuration for cyclic calls to the read or write main functions. Ensure that the reference is accurate and synchronized with system timing requirements.

CanHwFilter:

This container holds the configuration parameters for one hardware filter, specifically for Hardware Receive Handles (HRHs). Hardware filters are used to selectively receive CAN messages based on predefined criteria.

Configure hardware filters to selectively receive CAN messages based on predefined criteria. Set filter parameters such as message identifiers and masks to filter incoming messages effectively.

CanTTHardwareObjectTrigger:

Specifies configuration parameters for TTCAN triggers associated with Hardware Objects. These triggers are additional to the configuration of standard CAN Hardware Objects and are specific to Time-Triggered CAN (TTCAN) communication.

Define configuration parameters for TTCAN triggers associated with hardware objects. Adjust trigger settings to initiate specific actions or events based on TTCAN message timing or state changes.

Note: When configuring these parameters, ensure they align with your application's requirements and capabilities of your hardware, and the specifications of your CAN communication protocol. Refer to documentation and guidelines provided by supplier regarding each parameter.

RTA Knowledge Base

TC399 CAN MCAL Configurations

Table of Contents