CAN Driver (Can)

The synchronous, non-reentrant function Can_Init initializes the entire CAN driver module as well as the associated hardware units according to the passed configuration [SWS_Can_00223].

Usage and Call Context

The call to Can_Init is mandatory during the startup phase of the ECU by the ECU State Manager, before any other function of the CAN driver may be called [SWS_Can_91012]. As a parameter, the function takes a pointer to the driver configuration (const Can_ConfigType*) via Config and returns no value [SWS_Can_00223].

Initialization Scope and State Transitions

As part of the initialization, the function sets all required hardware registers and initializes all CAN controllers AUTOSAR_SWS_CANDriver p. 33:

• Initialization of static variables and internal flags [SWS_Can_91012],
• Configuration of common settings for the complete CAN hardware unit [SWS_Can_91012],
• Controller-specific settings for each individual CAN controller [SWS_Can_91012].

The function call triggers state transitions of the CAN hardware AUTOSAR_SWS_CANDriver p. 10, where Can_Init performs the register configuration to transition the controllers into the intended base state [SWS_Can_91010] AUTOSAR_SWS_CANDriver p. 36.

Concurrency and Limitations

Since Can_Init is specified as non-reentrant, no parallel or repeated call may take place during an ongoing initialization [SWS_Can_00223]. Furthermore, certain global settings of the hardware unit can only be set within Can_Init AUTOSAR_SWS_CANDriver p. 33.

The function Can_DeInit serves to deinitialize the CAN driver module ([SWS_Can_91002]). It has the signature void Can_DeInit(void), takes no parameters, returns no value, and is executed synchronously and non-reentrantly ([SWS_Can_91002]). The interface is available via the header Can.h ([SWS_Can_91002]).

The call initiates a software-controlled state transition (AUTOSAR_SWS_CANDriver p. 10; AUTOSAR_SWS_CANDriver p. 41). In doing so, Can_DeInit changes the module state (AUTOSAR_SWS_CANDriver p. 33) and resets all CAN controllers (AUTOSAR_SWS_CANDriver p. 41).

Concurrency and Limitations

Strict preconditions and sequencing requirements regarding hardware and module states apply to the execution:

• The caller must ensure that no CAN controller is in an invalid state (AUTOSAR_SWS_CANDriver p. 61); presumably, active communication operations must be terminated beforehand. Question Q-311343fa42add3a3 (open)
• If the CAN module is not in the required initial state upon the call (AUTOSAR_SWS_CANDriver p. 41), the function reports the error CAN_E_TRANSITION (AUTOSAR_SWS_CANDriver p. 61).
• Likewise, the error CAN_E_TRANSITION is raised if a CAN controller remains in a state that prevents deinitialization (AUTOSAR_SWS_CANDriver p. 61). Interpretation: The driver presumably requires a stopped state of all controllers prior to the transition. Question Q-435095949dafba5c (open)

Interaction

The error and transition behavior reflects the cleaned-up driver workflows, according to which invalid state transitions are intercepted uniformly ([SWS_Can_00441]).

The function Can_SetControllerMode (provided via Can.h with service ID 0x03) performs software-triggered state transitions of the CAN controller state machine ([SWS_Can_00230], AUTOSAR_SWS_CANDriver p. 35). It performs the hardware-related register settings to bring about the transitions between the basic controller states UNINIT, STOPPED, STARTED, and SLEEP ([SWS_Can_91010], AUTOSAR_SWS_CANDriver §7.3 “CAN Controller State Machine”).

Usage and Semantics

The call is made with the parameter Controller to identify the CAN controller and Transition of type Can_ControllerStateType to specify the desired state transition ([SWS_Can_00230]). The service is defined as asynchronous and non-reentrant (Non Reentrant) ([SWS_Can_00230]). A return value of E_OK confirms that the request was accepted; E_NOT_OK indicates that the request was rejected and a development error is present ([SWS_Can_00230], [SWS_Can_00441]).

Sequence and Interaction

After setting the register configuration, Can_SetControllerMode is exited again (AUTOSAR_SWS_CANDriver p. 38). Since the Can module does not store the hardware state changes itself ([SWS_Can_91010]), the cyclic function Can_Mainfunction_Mode presumably handles the asynchronous completion or verification of the transition initiated by Can_SetControllerMode (AUTOSAR_SWS_CANDriver p. 38). Question Q-03edb1b665a1624b (open)

The synchronous and reentrant function Can_DisableControllerInterrupts disables all interrupts for a specified CAN controller ([SWS_Can_00231]). The parameter is passed via Controller without a return value ([SWS_Can_00231]).

Regarding call context and concurrency, the function is designed to be reentrant and supports multiple calls (AUTOSAR_SWS_CANDriver §8.3 “Can_DisableControllerInterrupts”). Interpretation: Multiple calls are likely to increment an internal nesting counter, so that the interrupts are only re-enabled after a corresponding number of enable calls (AUTOSAR_SWS_CANDriver §8.3 “Can_DisableControllerInterrupts”, AUTOSAR_SWS_CANDriver §8.3 “Can_DisableControllerInterrupts”). Question Q-61be56207aa92ee0 (open)

In the area of error handling, the specification requires raising error CAN_E_UNINIT if the driver module is not yet initialized when called (AUTOSAR_SWS_CANDriver §8.3 “Can_DisableControllerInterrupts”). In addition, the specification requires raising another error (AUTOSAR_SWS_CANDriver §8.3 “Can_DisableControllerInterrupts”); presumably this serves to check for an invalid controller identifier. Question (open)

In interaction within the CAN driver, the call serves to protect controller-related critical sections while the controller remains active (AUTOSAR_SWS_CANDriver §7.5 “Interrupt handling”). Formal cleanups and historical interface changes of the driver are documented in the release notes ([SWS_Can_00441]).

The synchronous and reentrant function Can_EnableControllerInterrupts re-enables all allowed interrupts for the CAN controller specified via the parameter Controller ([SWS_Can_00232]). It has no return value and is provided via the header file Can.h ([SWS_Can_00232]).

Regarding the control flow, the function reads software control flags (AUTOSAR_SWS_CANDriver p. 65). If the interrupts of the controller were previously disabled multiple times, Can_EnableControllerInterrupts must be called just as many times before the actual enabling (AUTOSAR_SWS_CANDriver p. 65). Interpretation: The driver presumably manages nested lock sections via internal counters or flags, so that the hardware interrupts are re-enabled only after fully balancing all disable calls. Question Q-6781f0fc9ad7d221 (open)

If the function is called before the CAN driver has been properly initialized, it reports the error CAN_E_UNINIT (AUTOSAR_SWS_CANDriver p. 66). This is likely treated as a development error in the driver context ([SWS_Can_00441]). Question Q-efbbcf03a2589e4e (open) In the uninitialized state, the function performs no further actions on the controller (AUTOSAR_SWS_CANDriver p. 66).

Usage and Behavior

The synchronous function Can_CheckWakeup checks for a specific CAN controller whether a wake-up event has been detected ([SWS_Can_00360], AUTOSAR_SWS_CANDriver p. 48, AUTOSAR_SWS_CANDriver p. 67). It is available via the header file Can.h and has the service ID 0x0b ([SWS_Can_00360]).

• Parameters: Controller (in) designates the identifier of the CAN controller whose state is to be checked for a wake-up ([SWS_Can_00360]).
• Return value: Returns Std_ReturnType. The return value E_OK indicates that the API call was accepted, while E_NOT_OK indicates rejection ([SWS_Can_00360]).
• Concurrency: The function is defined as non-reentrant (Non Reentrant) ([SWS_Can_00360]).

Configuration and Error Handling

The availability of the function is configurable at pre-compile time; the service Can_CheckWakeup can be included in or excluded from the code via this mechanism (AUTOSAR_SWS_CANDriver p. 67, AUTOSAR_SWS_CANDriver p. 97). If the function is called before the CAN driver has been initialized, it reports the error CAN_E_UNINIT (AUTOSAR_SWS_CANDriver p. 67).

Interaction

The call to Can_CheckWakeup is typically triggered by the CAN Interface (AUTOSAR_SWS_CANDriver p. 48). In the event of a wake-up event on the bus, CanIf_CheckWakeup can be called during the execution of EcuM_CheckWakeup (AUTOSAR_SWS_CANInterface §7.18.4.1 “Wake-up detection”). According to [SWS_CANIF_00395], CanIf queries via Can_CheckWakeup() or CanTrcv_CheckWakeup() which specific hardware device caused the bus wake-up (AUTOSAR_SWS_CANInterface p. 55).

Usage and Semantics

The function Can_Write is called synchronously by the module CanIf to pass a CAN message to the CAN driver (CanDrv) for transmission ([SWS_Can_00233]). The caller passes two parameters:

• Hth: Hardware transmit handle that defines the transmit object to be used and implicitly determines the controller, as the handle numbers are unique within a hardware unit ([SWS_Can_00233]).
• PduInfo: Pointer to a structure containing SDU payload data, data length, and CAN identifier ([SWS_Can_00233]).

Before transmitting, the function checks the addressed hardware transmit object (SWS_CANDriver p. 73) and backs up the passed swPduHandle (SWS_CANDriver p. 43). Via the return value of type Std_ReturnType (SRS_BSWGeneral §5.2.3.6 “Types and keywords”), E_OK indicates acceptance of the request, while CAN_BUSY indicates that no hardware transmit buffer is available ([SWS_Can_00233], SWS_CANDriver p. 51).

Error handling

If a development error occurs during execution, the function returns E_NOT_OK ([SWS_Can_00233], [SWS_Can_00441]). Interpretation: Specific DET error codes are not explicitly mentioned in the available extract; however, faulty handles or invalid pointers are likely to result in returning E_NOT_OK. Question Q-ca947a7e0e4fd7d6 (open)

Concurrency and Limitations

Can_Write is specified as reentrant or thread-safe ([SWS_Can_00233], SWS_CANDriver p. 49). If a preemptive call cannot be executed reentrantly on the driver side, this is also reported to CanIf via the return value CAN_BUSY ([SWS_Can_00233]). The caller must ensure that the PDU memory remains valid and unmodified until the function call returns (SWS_CANDriver p. 45).

Interaction

Via [SWS_Can_00416], the type of PDU is conveyed upon the call (SWS_CANDriver p. 51), with the driver supporting transmission up to the maximum PDU length (SWS_CANDriver p. 52).

Usage and Call Context

The configurable call-out interface <LPDU_CalloutName> is optionally called by the AUTOSAR CAN module each time an L-PDU is received (SWS_CANDriver §8.4.1 “Call-out function”). The declaration of the function is provided via the header file Can_Externals.h ([SWS_Can_00443]). The actual name of the function is configured in a project-specific manner ([SWS_Can_00443]).

The hardware receive handle Hrh, the identifier CanId, the data length CanDataLegth, and a pointer to the payload CanSduPtr are passed as input parameters ([SWS_Can_00443]).

Filtering and return value

The function returns a boolean value. If the call-out returns false, the received L-PDU must not be processed further ([SWS_Can_00444]). Interpretation: If the call returns true, the regular forwarding of the L-PDU to the upper layers is likely to take place. Question Q-e96e75e93881c3af (open)

Concurrency and Limitations

The function is assigned the service ID 0x20 and specified as asynchronous (Asynchronous) and non-reentrant (Non Reentrant) ([SWS_Can_00443]). Because it is non-reentrant, concurrent calls must not occur in the same context.

The function Can_MainFunction_Write performs cyclic polling of transmit confirmations (TX confirmation) if the parameter CAN_TX_PROCESSING is configured to POLLING [SWS_Can_00225], AUTOSAR SWS CAN Driver §7 “Scheduled functions”. It takes no parameters (void Can_MainFunction_Write(void)), has the service ID 0x01, and is provided to the scheduler via the header file SchM_Can.h [SWS_Can_00225]. Via configuration switches, the function can be enabled or disabled for processing PDU transmission AUTOSAR SWS CAN Driver §10 “CanMainFunctionWrite”.

If no polling is used for transmission in the system at all, Can_MainFunction_Write shall be implemented as an empty define according to the specification AUTOSAR SWS CAN Driver §7 “Scheduled functions”. This is likely intended to avoid unnecessary scheduler overhead in purely interrupt-driven systems. Question Q-2152a35397130945 (open)

In interaction with Can_MainFunction_Read and Can_MainFunction_BusOff, the routine forms the cyclic interface of the driver to the SchM AUTOSAR SWS CAN Driver §7 “Scheduled functions”. Confirmation processing takes place either directly at the hardware resource or in the context of Can_MainFunction_Write, depending on the mode AUTOSAR SWS CAN Driver §7 “Hardware Resources”. The specific call and mapping depend on the respective referenced elements AUTOSAR SWS CAN Driver §10 “CanMainFunctionWrite”, AUTOSAR SWS CAN Driver §10 “Call Context”, supported by controller-related Tx processing [SWS_Can_00441].

The function Can_MainFunction_Read serves for cyclic querying (polling) of CAN receive messages ([SWS_Can_00226]). It has the signature void Can_MainFunction_Read (void) with service ID 0x08 and is provided for execution control via the header file SchM_Can.h ([SWS_Can_00226]).

Usage and Configuration

The function executes the polling of RX indications when the configuration parameter CAN_RX_PROCESSING is set to POLLING ([SWS_Can_00226]). In the system, this processing can be configured per controller ([SWS_Can_00441]). If no polling is used in the CAN driver at all, Can_MainFunction_Read can be defined as an empty macro (AUTOSAR_SWS_CANDriver p. 77).

Concurrency and Limitations

The call occurs periodically in the scheduler context according to the parameterized trigger period (AUTOSAR_SWS_CANDriver p. 22). Strict conditions apply to the execution:

• The function must not be interrupted by itself (AUTOSAR_SWS_CANDriver p. 47).
• In general, CAN main functions like Can_MainFunction_Read must not be interrupted (AUTOSAR_SWS_CANDriver p. 49) in order to ensure consistent access to driver and hardware resources in polling mode (AUTOSAR_SWS_CANDriver p. 46).

Interpretation: The configured call interval of the task would likely need to be dimensioned such that a processing phase is always finished before the next cycle starts, since reentrancy is not permitted (AUTOSAR_SWS_CANDriver p. 47). Question Q-1f2fa9db14970b12 (open)

The scheduled main function Can_MainFunction_BusOff serves for cyclic polling of bus-off events of the CAN controllers, provided they are statically configured to be polled [SWS_Can_00227], [SWS_Can_00109]. It has the signature void Can_MainFunction_BusOff(void), takes no parameters, returns no value, and is provided via the header SchM_Can.h for execution control [SWS_Can_00227].

Usage and Interaction

Hardware events can be detected in the CAN driver either via interrupt or by polling corresponding status flags, with the query configuration being hardware-dependent [SWS_Can_00099]. The driver can also be configured to dispense entirely with interrupts [SWS_Can_00007]. If no polling is used system-wide at all, the Can module may implement the function as an empty macro [SWS_Can_00183].

If a bus-off event is detected via status bits in Can_MainFunction_BusOff, the module performs the necessary register settings—such as to prevent automatic hardware recovery SWS_CANDriver §7.3 “CAN Controller State Machine”, [SWS_Can_91010]. Subsequently, the module notifies the upper layer CanIf via the associated callback, in which the software state change of the controller takes place SWS_CANDriver §7.3 “CAN Controller State Machine”.

Call Context and Restrictions

In polled operation, the call context of the callback notification is not the ISR, but the executing task of Can_MainFunction_BusOff; nevertheless, all callback functions must be implemented as if they were called from the ISR context SWS_CANDriver §7.9 “Notification concept”. Regarding reentrancy, the payload contains no explicit information; presumably the function is non-reentrant because it accesses global controller registers and states. Question Q-38fcd72c40ce3e66 (open)

The main function Can_MainFunction_Wakeup performs cyclic polling of wake-up events that are statically configured to be polled ([SWS_Can_00228]). The function has the signature void Can_MainFunction_Wakeup(void), takes no parameters, returns no value, and is provided via the header SchM_Can.h for the Schedule Manager (AUTOSAR_SWS_CANDriver p. 79). The execution period of the function is configured in seconds (AUTOSAR_SWS_CANDriver p. 92).

Within the CAN controller state machine (SWS_CANDriver §7.3 “CAN Controller State Machine”), external hardware wake-up events can be signaled via a status bit queried in Can_MainFunction_Wakeup instead of via interrupts ([SWS_Can_91010]). In addition, during state transitions, the function polls a corresponding flag of the CAN status register until it signals that the change has taken effect ([SWS_Can_00370]). After a successful state change, the CAN driver reports the new state to the CAN interface using the callback function CanIf_ControllerModeIndication, referenced to the abstract CanIf ControllerId ([SWS_Can_00370]).

Regarding configuration and resource usage, the API Can_MainFunction_Wakeup() can be enabled or disabled for handling wake-up events (AUTOSAR_SWS_CANDriver p. 97). If no polling is used for wake-up events in the ECU at all, Can_MainFunction_Wakeup can be defined as an empty macro (AUTOSAR_SWS_CANDriver p. 79).

Usage and Operation

The scheduled main function Can_MainFunction_Mode ([SWS_Can_00368]) performs the polling of state transitions of the CAN controllers. It has neither input parameters nor a return value (void Can_MainFunction_Mode(void), service ID 0x0c) and is declared via the header SchM_Can.h SWS_CANDriver §8.5.1.5 “Can_MainFunction_Mode”.

The function is called cyclically on a continuous basis (AUTOSAR_SWS_CANInterface p. 143). It checks the hardware to determine whether the mode of a CAN controller has changed. When a change is detected, the CAN interface is notified via the call to CanIf_ControllerModeIndication(Controller, ControllerMode).

Asynchronous Mode Monitoring

If a mode change was previously requested via Can_SetControllerMode() and this call returns successfully to CanIf, Can_MainFunction_Mode detects the completed state transition of the controller hardware. It then informs CanIf asynchronously via CanIf_ControllerModeIndication about the new state, such as CAN_CS_STARTED AUTOSAR_SWS_CANInterface p. 144.

Call Context and Constraints

Due to its provision via SchM_Can.h and its definition as a scheduled function, the periodic invocation is likely performed by the BSW Scheduler. Question Q-42edbc2aa591e8d7 (open) Specific error codes or development steps are not defined in the payload for this function.

The enumeration type Can_ErrorStateType from Can_GeneralTypes.h describes the error and operating states of a CAN controller [SWS_Can_91003]. It maps the behavior of the controller on the CAN bus via three states SWS_CANDriver §8.2.7 “Can_ErrorStateType”:

• CAN_ERRORSTATE_ACTIVE: The CAN controller fully participates in bus communication [SWS_Can_91003].
• CAN_ERRORSTATE_PASSIVE: The CAN controller participates in communication, but no longer sends active error frames (Error Frames) [SWS_Can_91003].
• CAN_ERRORSTATE_BUSOFF: The CAN controller is isolated from the bus as a result of severe transmission errors and no longer participates in communication [SWS_Can_91003].

At runtime, the state is queried via the synchronous driver service Can_GetControllerErrorState [SWS_Can_91004]. Its output parameter ErrorStatePtr receives the determined value. The same signature is also used by the higher-level function CanIf_GetControllerErrorState in the CAN Interface AUTOSAR_SWS_CANInterface p. 78 “CanIf_GetControllerErrorState”. Regarding concurrency, Can_GetControllerErrorState is specified as non-reentrant for the same ControllerId [SWS_Can_91004].

In case of error, Can_GetControllerErrorState provides the return value E_NOT_OK, upon successful query E_OK [SWS_Can_91004]. When development error detection (DET) is enabled, a call prior to driver initialization leads to error CAN_E_UNINIT [SWS_Can_91005]. An invalid ControllerId triggers the development error CAN_E_PARAM_CONTROLLER [SWS_Can_91006], and passing a null pointer for ErrorStatePtr is rejected with a development error [SWS_Can_91007].

Interpretation: The caller is likely required to allocate the memory area for ErrorStatePtr independently, since the interface treats the pointer as a pure output parameter and precludes null pointers via a development error. Question Q-5c907c21bcb50893 (open)

The enumeration type Can_ControllerStateType defines the fundamental operating states of a CAN controller: CAN_CS_UNINIT, CAN_CS_STARTED, CAN_CS_STOPPED, and CAN_CS_SLEEP [SWS_Can_91013]. The type is used across modules for software-controlled state management of the CAN controller state machine [SWS_Can_00017].

The values are used in the following contexts:

• State request: In Can_SetControllerMode, the type serves as a transition value (parameter Transition) for asynchronously requesting a new operating state [SWS_Can_00230]; correspondingly, CanIf_SetControllerMode exists AUTOSAR_SWS_CANInterface §- “CanIf_SetControllerMode”. The driver forwards the request to the controller hardware, with the actual state change taking effect immediately or after a few milliseconds AUTOSAR_SWS_CANInterface §- “Can_SetControllerMode”. A transition to CAN_CS_STARTED additionally triggers a reinitialization of the controller [SWS_Can_00384].
• Status query: Via Can_GetControllerMode, the current state can be queried synchronously via the output pointer ControllerModePtr [SWS_Can_91014], [SWS_Can_91015] (analogously in CanIf_GetControllerMode AUTOSAR_SWS_CANInterface §- “CanIf_GetControllerMode”).
• State indication: After the transition is completed, callbacks such as CanSM_ControllerModeIndication [SWS_CanSM_00396], CanIf_ControllerModeIndication AUTOSAR_SWS_CANInterface §- “CanIf_ControllerModeIndication”, and user callbacks AUTOSAR_SWS_CANInterface §- “User_ControllerModeIndication” inform higher layers synchronously about the new controller mode.

Regarding concurrency and error handling: The driver functions Can_SetControllerMode and Can_GetControllerMode are non-reentrant [SWS_Can_00230], [SWS_Can_91014]. If Can_GetControllerMode is called before driver initialization, the development error CAN_E_UNINIT is reported and E_NOT_OK is returned [SWS_Can_91016]. The callback function CanSM_ControllerModeIndication is reentrant for different controllers and reports an unconfigured controller ID with CANSM_E_PARAM_CONTROLLER to the DET [SWS_CanSM_00396], [SWS_CanSM_00397].

The enumeration type Can_ErrorType defines a standardized superset of CAN error causes that typical CAN hardware can detect and report to higher layers [SWS_Can_91021]. It is provided via the header file Can_GeneralTypes.h SWS_CANDriver §8.2.9 “Can_ErrorType”.

Since the enumeration is designed as a superset, not every CAN controller necessarily supports all specified values [SWS_Can_91021]. The defined error states include:

• Bit errors during bus monitoring (CAN_ERROR_BIT_MONITORING1, CAN_ERROR_BIT_MONITORING0, or collectively CAN_ERROR_BIT),
• Acknowledgment errors (CAN_ERROR_CHECK_ACK_FAILED, CAN_ERROR_ACK_DELIMITER),
• Transmitter loss of arbitration (CAN_ERROR_ARBITRATION_LOST),
• Overload conditions caused by full receive buffers (CAN_ERROR_OVERLOAD),
• Format and bit-stuffing violations (CAN_ERROR_CHECK_FORM_FAILED, CAN_ERROR_CHECK_STUFFING_FAILED),
• CRC errors (CAN_ERROR_CHECK_CRC_FAILED), and
• a persistent bus lock at dominant level (CAN_ERROR_BUS_LOCK) SWS_CANDriver §8.2.9 “Can_ErrorType”.

In the interaction of BSW modules, the type serves as a parameter of the callback function CanIf_ErrorNotification for forwarding controller errors to the CAN interface AUTOSAR_SWS_CANInterface §8.x “CanIf_ErrorNotification”. The passed value is likely to correspond to the error state detected by the underlying hardware AUTOSAR_SWS_CANDriver §7.x “Error Notification”. Question Q-d23c45dd3b23ec71 (open)