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 : can_configure_req
CanService -> CanInterface : configure
CanService -> UserCode : can_configure_rsp

UserCode -> PVCANU : configure\nip link...

UserCode -> CanService : can_request_req
CanService -> CanInterface : Set active
activate CanInterface
CanService -> UserCode : 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 : can_release_req
CanService -> CanInterface : Set inactive
deactivate CanInterface
CanService -> UserCode : 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 can_configure_req message. For 2.0B (“Classic”) CAN the main 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 to data-rate parameters the configuration allows setting of the CAN sample points within each bit. For most cases the default of automatic selection should be suitable, but if needed it can be specified between 0.1% and 99.9%. It is worth noting that the setting is a hint and the system will select the closest point supported by the hardware. After an interface has been both requested and configured the actual configuration can be read back from hardware using the can_get_configuration_req message.

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 can_set_wakeup_req message.

Status and bus state handling

The bus state is available either by subscribing to can_status_publish_ind or by polling using the can_status_req 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 can_reset_req message.

Reference

IPC Module - CAN Service