AUTOSAR CanIf

CAN IF Architecture Location

CAN interface introduction

??As shown in the figure above, CAN interface is referred to as canif, which is located between the lower CAN physical layer (CAN Driver + CAN transceiver) and the upper CAN service layer (CAN sm + CAN NM) CAN protocol layer (CAN TP + PDUR).

CANif is independent of hardware and provides a unified interface to manage CAN physical layer devices. At the same time, it can be combined with the CAN SM module to manage all internal and external CAN drivers and CAN transceivers to achieve their state changes.

??In the reception and transmission of PDU, the upper layer can be notified of the send confirmation (transmit confirm), and the receive indication (Rxindication()) will package the lower PCI and SDU to the upper layer. SUD can be distributed to the driver downward.

Supported functions:

1.CAN Interface initialization

2.Transmit confirmation

3.Transmit buffer

4.Receive indication

5.DLC check

6.CAN FD support

7.Communication Modes

8.BusOff detection

9.External wakeup

10.Wakeup validation

11.Multiple CAN Driver support

CAN interface main function description

CANIF is called

1. Interrupt Mode

??The CanIf services are called from an interrupt generated by the CAN driver.

2. Polling Mode

??CanIf services are called in Can_MainFunction_XX (XX = Write/read/busoff/wakeup/transceiver).

3. Mixed Mode

??For example: full can uses interrupts, basic can uses polling.

Hardware object handles (HO)

??The Hardware Object Handle (HOH) for sending (HTH) and receiving (HRH) represents an abstract reference to a CAN mailbox structure containing CAN related parameters like CanId, DLC and data. Based on the CAN hardware buffer abstraction, each hardware object is referenced in the CAN IF independently of the layout of the CAN hardware buffer. The HOH is used as a parameter in the interface service call of CanDrv, provided by the configuration of CanDrv and used by CanDrv as an identifier of the CAN mailbox communication buffer.

??CanIf acts only as a user of the hardware object handle but does not interpret it based on hardware specific information. Therefore CanIf remains hardware independent.

Static L-PDUs

??CanIf provides upper layers with generic access to CAN L-SDU related data.

??CanIf shall assign each L-PDU to only one CAN controller. Therefore, it is forbidden to assign a single L-PDU to multiple CAN controllers.

??CanIf supports activation and deactivation of all L-PDUs belonging to one CAN controller for sending and receiving.

Dynamic L-PDUs

CANIF supports filtering IDs via CanIfRxPduCanIdMask.

Dynamic Transmit L-PDUs

Definition of Dynamic Transmit L-PDUs: Allows to reconfigure the CanId (CanIfTxPduType) at runtime or include the ID or part of it as metadata of the L-SDU.

Dynamic receive L-PDUs

Definition of Dynamic receive L-PDUs: An L-PDU corresponding to a set of Can Ids, where the Can Id actually received is provided to the upper layer as part of the PDU data.

Physical channel view

A Physical channel is composed of a CAN Controller and a CAN Transceiver. One or more Physical channels are connected to a network.

CanIf provides services to control all CAN devices, such as CAN Controllers and CAN and Transceivers. CanSm uses these API services to provide network observation results to ComM for executing wake-up and sleep requests for all physical channels connected to a single network.

CanIf passes the status information provided by CanDrv and CanTrcv for each physical channel as status information passed upward to CanSm.

The Controller_Id provided by the CanIf module is an abstraction of CanDrv instances, and the ID starts from 0.

The Transceiver_Id provided by the CanIf module is an abstraction of CanTrcv instances, and the ID starts from 0

CanSm associates the notification with the following CanDrv CanTrcv through the above abstracted ID.

Since CANIF is independent of the hardware layer, CanIf does not care what type of hardware is connected below (high-speed CAN or low-speed CAN) or how many hardware there are.

CAN Hardware Unit

??The CAN Hardware Unit consists of one or more CAN controller modules of the same type, which can be located on the chip or as external independent devices. Each CAN Hardware Unit is served by the corresponding CanDrv.

??If different CAN Controllers are used, different types of CanDrvs will be used, but the CanIf module provides a unified API. The CanIf module collects abstract information (object ID, type, etc.) of the CAN Controller and Hardware Objects in the configuration.

Initialization

Initialized by CanIf_Init().

Transmit request

The CanIf module provides the CanIf_Transmit() public interface to the upper-layer modules (CAN TP, PDUR, etc.) to transmit L-PDU. The upper-layer modules can only start the data transmission service through the CanIf_Transmit() interface, but cannot directly access the CAN driver.

When the CanIf_Transmit() interface is called, the CanIf module performs the following actions:

??Check and initialize the CanIf module status

??Identify CanDrv (multiple CanDrvs are used)

??Determine the HTH that accesses the CAN hardware transmission object

??Call CanDrv's Can_Write() function

??Transmission is successful Return E_OK

Transmit data flow

The transmission service CanIf_Transmit() is based on L-PDUs. The L-SDU data can be accessed/obtained through the L-SDU ID and the pointer to the L-SDU data in the L-PDU data structure.

CanIf stores information about the available hardware objects configured for the transmission task. The function CanIf_Transmit() maps the CanTxPduId to the corresponding HTH and calls the function Can_Write().

Transmit buffering

General behavior

??In the scope of CanIf, the transmission process starts with a call to CanIf_Transmit() and ends with a call to the callback service <User_TxConfirmation>() of the upper module. During the transmission process, CanIf, CanDrv and the CAN Mailbox shall store L-PDUs that are only sent once in one location. Depending on the transmission method, these are: the Can hardware send mailbox or the L-PDU send buffer in the CanIf module (if the send buffer is enabled).

??For triggered transmissions, CanIf only needs to store the transmission request of a given L-PDU, but not its data. The data is obtained in time by the triggered transmission function when the HTH is idle (again). The request for a single Tx L-PDU to be transmitted shall not be stored twice. This behavior corresponds to the usual cyclical communication method on the CAN network.

??If the send buffer is enabled, CanIf shall store a Tx L-PDU in the CanIf send L-PDU buffer (CanIfBufferCfg) if it was rejected by canrv during the send request.

Storage of L-PDUs in the transmit L-PDU buffer

CanIf tries to store a new transmit L-PDU or its send request in the transmit L-PDU buffer only if CanDrv returns CAN_BUSY when calling Can_Write().

Initialization of transmit L-PDU buffers

??After the CanIf_Init() function is called, CanIf completes the initialization of sending the L-PDU Buffer.

Transmit confirmation

??If the previous transmission request was completed successfully, CanDrv notifies CanIf of this by calling CanIf_TxConfirmation().

Receive data flow

??According to the AUTOSAR Basic Software Architecture, the received data will be evaluated and processed in the upper communication stack (i.e. AUTOSAR COM, CanNm, CanTp, DCM). This means that the upper modules can neither work with (i.e. change) the buffers of CanDrv (Rx) nor access the buffers of CanIf (Tx).

??CanIf can only provide internal buffering in the receive path if CanIf_PUBLIC_READRXPDU_DATA_API is set to TRUE.

??If a new L-PDU is received, CanDrv calls CanIf_RxIndication() of CanIf. The access to the L-PDU specific data is implemented by the following parameters: Hardware Receive Handle (HRH), Receive CAN ID, Receive CAN data length, reference (pointer) to the received L-PDU data.

??The CAN hardware receive object is locked until the process of copying the data to a temporary or upper module buffer is over. After CanIf_RxIndication() of CanIf returns, the hardware object will be released immediately to avoid data loss.

Receive indication

??The call to CanIf_RxIndication() references a newly received CAN L-PDU in its parameter. If the CanIf_RxIndication() function is called, CanIf will evaluate whether the CAN L-PDU is accepted and prepare the L-SDU for subsequent access by the upper communication layer. If the CAN L-PDU is configured and the CAN L-PDU is successfully detected and accepted for further processing, CanIf notifies the upper layer module about this asynchronous event using <User_RxIndication>().

??If the CanIf_RxIndication function is called in CanTrv, CanIf performs the following operations:

??Software filtering (configurable)

??DLC check (configurable)

??Buffer received L-SDU (configurable)

??Call the receive notification callback function provided by the upper layer (configurable).

Read received data

??The read receive data interface CanIf_ReadRxPduData() is a common interface for the upper layer module to read the CAN L-SDU recently received from the CAN network. The upper layer module only initiates a receive request through the CanIf service without directly accessing CanDrv. If CanIf writes the received L-SDU to the upper layer module I-PDU buffer, it means that the receive request is successfully completed.

Read Tx/Rx notification status

??In addition to the notification callback function, CanIf provides the API service CanIf_ReadTxNotifStatus() to read the transmission confirmation status of any transmitted L-SDU, and provides the API service CanIf_ReadRxNotifStatus() to read the reception indication status of any received L-SDU.

Data integrity

??Rationale: Attempts to update data in upper module buffers as well as in CanIf's internal buffers must take into account possible changes that may have occurred in the context of an interrupt service routine or other preemption event. Preemption events may occur in the context of a preemption task, multiple CAN interrupts, if multiple physical channels are used, such as a gateway, or in the case of other peripheral or network system interrupts that require sending and receiving L-PDUs on the network.

??If the CanIf_Transmit(), CanIf_TxConfirmation() and CanIf_ReadRxPduData() functions are called in the CanIf module to read data from a CanIf controlled memory area, the CanIf shall guarantee that the value provided is the most recently obtained value.

??If the CanIf is configured to use a transmit buffer or a receive buffer, the CanIf_Transmit(), CanIf_TxConfirmation() and CanIf_ReadRxPduData() functions only access data in the memory area controlled by the CanIf.

CAN Controller Mode

??The CanIf module provides services to control the mode of CAN Controllers. It provides CanIf_GetControllerMode() to get the mode of CAN Controllers and provides CanIf_SetControllerMode() to set the mode of CAN Controllers.

??The CanSM module is responsible for the consistency management of all CAN Controllers on a CAN network. CanSM is responsible for setting all CAN Controllers on a network to sleep or wake up in sequence.

CAN Controller Operation Modes

??If the current CAN network identified by ControllerID is in CAN_CS_STOPPED state, calling the CanIf_Transmit() function through the network will return E_NOT_OK, and the Can_Write() function will not be called. At the same time, the transmit buffer in CanIf will be cleared. At the same time, <User_TxConfirmation>(id, E_NOT_OK) will be called and the upper layer will fail to send data.

Controller Mode Transitions

??The CAN controller's state change request API issues asynchronous notifications through callback services in an asynchronous manner.

??The actual change to the requested mode happens asynchronously, depending on the settings of the change request in the CAN controller hardware, e.g. the requested sleep transition CAN_CS_SLEEP. After a successful change to e.g. CAN_CS_SLEEP mode, CanDrv calls the function CanIf_ControllerModeIndication(), which in turn calls the function <User_ControllerModeIndication>(). If the CAN transmission is very fast, CanIf_ControllerModeIndication() can be called during CanIf_SetControllerMode().

The upper layer of CanIf can poll the current controller mode via CanIf_GetControllerMode().

Wake-up

??The ECU supports wakeup via the CAN network, regardless of which wakeup method is used (directly regarding the CAN controller or the CAN transceiver), only when the CAN controller and the CAN transceiver are set to some kind of "listen for wakeup" mode. This is usually a sleep mode where usual communication is disabled. Only this mode ensures that the CAN controller is in a stopped state. Therefore, the wakeup interrupt can be enabled.

Wake-up detection

??If wake-up support is enabled, CanIf detects a CAN wake-up with the CanIf_CheckWakeup() service via the integration code.

??In a CAN bus "wake-up" event, the CanIf_CheckWakeup(WakeupSource) function may be called when EcuM_CheckWakeup(WakeupSource) is executed. CanIf in turn checks the EcuMWakeupSource in the CanDrvs by configuring the input reference, which is the CanDrvs that must be checked. CanIf obtains this information by referencing the CanIfCtrlCanCtrlRef.

The communication service that is called belongs to the services defined during configuration. In this way, EcuM and CanSM are able to change the CAN controller state and control the system behavior related to BusOff recovery or wake-up procedures.

Wake-up Validation

??When the CAN controller/CAN transceiver detects a bus wake-up event, the ECU State Manager will be notified directly. If such a wake-up event needs to be verified, EcuM (or CDD) turns on the corresponding CAN Controller (CanIf_SetControllerMode()) and CAN Transceiver (CanIf_SetTrcvMode()).

??When "PDU Channel Mode" is set to "CanIf_ONLINE" or "CanIf_TX_OFFLINE", CanIf notifies the upper layer module of the received message. Therefore, if wake-up verification is required, there is no need to set the PDU channel mode to CanIf_ONLINE or CanIf_TX_OFFLINE.

PDU channel mode control

?? Each L-PDU is assigned to a dedicated physical CAN channel, which is connected to a CAN Controller and a CAN network. In this way, all L-PDUs in a group are controlled by processing a single logical L-PDU channel group. These logical groups represent all L-PDUs connected to a lower layer network.

PDU channel modes

??The CanIf module provides CanIf_SetPduMode() and CanIf_GetPduMode() services to set and get the CAN channel mode.

??The channel mode can only be changed when a CAN channel is in CAN_CS_STARTED mode.

??CanIf_ONLINE and CanIf_OFFLINE will affect the entire communication process (receive/send) of the PDU channel. CanIf_TX_OFFLINE and CanIf_TX_OFFLINE_ACTIVE modes turn off/on the occurrence of PDU respectively.

??Each PDU channel can be in CAN_OFFLINE mode (no communication), CanIf_TX_OFFLINE (passive mode can receive but not send) mode, CanIf_TX_OFFLINE_ACTIVE (simulate sending but not receiving), CanIf_ONLINE (full communication mode).

Software receive filter

??Not all L-PDUs are defined as Receive L-PDUs. Receive L-PDUs need to be received from the corresponding ECU. These L-PDUs can pass the hardware receive filter and are therefore successfully received in the BasicCAN hardware object. CanIf optionally filters out these L-PDUs and prohibits further software processing.

??The method of the software filtering mechanism is to find the corresponding L-PDU from the HRH and CanId being processed. After finding the L-PDU, CanIf accepts the received L-PDU and the upper layer can directly access the L-SDU information.

Software filtering concept

??The configuration tool processes information about the hardware accept filter settings. The most important settings are the number and range of L-PDU hardware objects. The output range defines which L-PDUs are received belonging to each hardware receive object.

Data Length Check

??The received Data Length value is compared with the configured Data Length value. The configured Data Length value shall be derived from the byte size used in this L-PDU. The configured Data Length value is not necessarily the Data Length value defined in the CAN Communication Matrix and used by the sender of this CAN L-PDU.