CAN

The principal operation of SocketCAN in the User VM can be found in the system architecture section.

The code running in the User VM, referred to as the User Code interacts with the CAN subsystems in two ways, firstly by sending Messaging requests to the CAN service in the ACU6 Base System and secondly by normal SocketCAN APIs against the virtual PV-CAN interface inside of the User VM

The diagram below illustrates a typical flow where User Code initializes CAN interfaces, opens a socket and sends and receives any number of frames and then closes the CAN interface.

hide footbox skinparam ParticipantPadding 20 skinparam BoxPadding 10 box "User VM" #White actor "User Code" as UserCode participant "Socket" as UserSocket participant "PV-CAN" as PVCANU end box box "ACU6 Base System" #White participant "CAN Service" as CanService participant "PV-CAN" as PVCANB participant "CAN Interface" as CanInterface end box queue "CAN BUS" as CanBus group Initialization UserCode -> CanService : ipc_msg_can_configure_req CanService -> CanInterface : configure CanService -> UserCode : ipc_msg_can_configure_rsp UserCode -> PVCANU : configure\nip link... UserCode -> CanService : ipc_msg_can_request_req CanService -> CanInterface : Set active activate CanInterface CanService -> UserCode : ipc_msg_can_request_rsp end group Sending UserCode -> UserSocket : send(...) UserSocket -> PVCANU : <send frame> UserCode <-- UserSocket : send(...) returns PVCANU -> PVCANB : <copy frame> PVCANB -> CanInterface : <gateway frame> CanInterface -> CanBus : <send frame to bus> end group Receiving CanInterface <- CanBus : <receive frame from bus> PVCANB <- CanInterface : <gateway frame> PVCANU <- PVCANB : <copy frame> UserCode -> UserSocket : recv(...) UserSocket <- PVCANU : <receive frame> UserCode <-- UserSocket : recv(...) returns end group Shutdown UserCode -> CanService : ipc_msg_can_release_req CanService -> CanInterface : Set inactive deactivate CanInterface CanService -> UserCode : ipc_msg_can_release_rsp end

Configuration

The central functionality of the CAN service is configuration of the physical CAN interface(s) of the device. The main way to configure a CAN interface is via the ipc_msg_can_configure_req AIPC message. For 2.0B (“Classic”) CAN the only configurable parameter is the data-rate, for CAN FD the configuration must include both the nominal data rate and the increased data data-rate.

In addition a CAN interface can be configured as a wake-up source from Sleep and Stand-by power states (see Power Modes and Handling) by using the ipc_msg_can_set_wakeup_req AIPC message.

Status and bus state handling

The bus state can be polled by the ipc_msg_can_status_req AIPC message.

If the bus enters an error state such as BUS_OFF the interface needs to be reset to recover the bus, which can be done with the ipc_msg_can_reset_req AIPC message.

hide footbox skinparam ParticipantPadding 20 skinparam BoxPadding 10 box "User VM" #White actor "User Code" as UserCode participant "Socket" as UserSocket end box box "ACU6 Base System" #White participant "CAN Service" as CanService participant "CAN Interface" as CanInterface end box group BusError Recovery UserCode -> CanService : ipc_msg_can_status_req CanService -> CanInterface : Read status CanService -> UserCode : ipc_msg_can_status_rsp [state=BUS_OFF] UserCode -> CanService : ipc_msg_can_reset_req CanService -> CanInterface : Reset interface CanService -> UserCode : ipc_msg_can_reset_rsp end

CAN Configuration API Reference