Configure CAN Channels

This article was written for version 2.3.1 of Core. Click here for the most recent version of the help center.

CAN interfaces exist on an ECU as PCIe cards and/or USB devices. The Linux system denotes each CAN bus on an interface as a channel, and sets a unqiue channel identifier. Some multi-channel CAN interfaces also contain channel indexes to identify a specific CAN bus.

PolySync Core supports linuxcan and socketcan-enabled CAN interface hardware devices. Core enables the socketcan drivers to communicate with CAN hardware by default.

1. Define the CAN driver used by Core nodes

Core is able to load one CAN driver at a time. Check which driver is loaded by Core with the provided tool.

$ polysync-can-chooser
Using SocketCAN

All nodes on a given host must use either linuxcan or all nodes must use socketcan drivers to communicate with CAN interface hardware.

1.1 linuxcan

To configure Core to use linuxcan drivers, issue the command:

$ polysync-can-chooser linuxcan

1.2 socketcan

To configure Core to use socketcan drivers, issue the command:

$ polysync-can-chooser socketcan

2. Configure socketcan CAN channels

CAN interfaces must be configured and actived for Core nodes to be able to open and communicate over the CAN bus.

PolySync provides the utility application polysync-core-socketcan-util to enumerate available CAN interfaces, and start/stop them.

2.1 Enumerate CAN interfaces

socketcan enumerates CAN interfaces as if it were an Ethernet socket.

Connect the CAN interface to the ECU and run the socketcan utility with the -l flag to list all interfaces.

$ polysync-core-socketcan-util -l

CAN interfaces will be follow one of these naming conventions, where X is a unique CAN channel identifier.

  • canX
  • vcanX
  • slcanX

2.2 Activate CAN interfaces

Each CAN interface must set the bitrate of the CAN bus in bit/s. Most automotive sensors use a bitrate of 500K, equivelent to 500000 bit/s.

$ polysync-core-socketcan-util -s  -b 500000  can0
2.2.1 Stop an active interface

Pass the -k flag to to stop the interface.

$ polysync-core-socketcan-util -k can0

2.3 Locating CAN identifiers

Use the output of the -l list flag to locate CAN channel identifiers.

$ polysync-core-socketcan-util -l
-- name: 'can0'
  - PolySync SDF CAN I/O
    * hardware identifier: 0
    * circuit identifier: 0
    * system identifier: 0
  - state: STOPPED

Update the SDF node entry with the hardware identifier value.

IO Configuration

2.4 Restart CAN interfaces

To restart an interface pass the -r flag.

$ polysync-core-socketcan-util -r can0

To auto-restart the interface with a predefined interval use the -R flag and specify the interval in milliseconds.

$ polysync-core-socketcan-util -R 100 can0

2.5 Migrate from linuxcan to socketcan

Follow these steps to update systems that have linuxcan installed but need to use socketcan drivers.

  1. Unplug or disconnect all CAN interfaces
  2. Remove the existing linuxcan installation
    • $ cd /usr/local/polysync/deps/
    • $ tar xf linuxcan-5.19.tar.gz
    • $ cd linuxcan
    • $ sudo make uninstall
  3. Follow the steps starting in section 2.1 to configure socketcan

3. Locate linuxcan CAN channels

linuxcan drivers are compatible with Kvaser CAN interfaces.

3.1 Locating identifiers

linuxcan uses both the CAN channel hardware ID and the CAN channel circuit ID of the Kvaser CAN interfaces (USB, PCIe, etc.) to detect the hardware that is connected to the ECU.

The hardware identifier is unique to each physical hardware device, where each device has one or more channels. The circuit identifier is an index for multi-channel CAN hardware interfaces.

Consider the following example where there are three Kvaser Leaf Lights connected:

  • Two 2x CAN to 1x USB Leaflight
  • One 1x CAN to to 1x USB Leaflight
$ /usr/doc/canlib/examples/listChannels
Found 5 channels.
channel 0 = Kvaser Leaf Light v2, 73-30130-00685-0, (0)28373,
channel 1 = Kvaser Leaf Light v2, 73-30130-00685-0, (1)28373,
channel 2 = Kvaser Leaf Light v2, 73-30130-00685-0, (0)11375,
channel 3 = Kvaser Leaf Light v2, 73-30130-00685-0, (0)10049,
channel 4 = Kvaser Leaf Light v2, 73-30130-00685-0, (1)10049,
Example input CAN Channel Hardware Identifier CAN Channel Circuit Identifier System index
channel 0 = Kvaser Leaf Light v2, 73-30130-00685-0, (0)28373, 28373 0 0
channel 1 = Kvaser Leaf Light v2, 73-30130-00685-0, (1)28373, 28373 1 1
channel 2 = Kvaser Leaf Light v2, 73-30130-00685-0, (0)11375, 11375 0 2
channel 3 = Kvaser Leaf Light v2, 73-30130-00685-0, (0)10049, 10049 0 3
channel 4 = Kvaser Leaf Light v2, 73-30130-00685-0, (1)10049, 10049 1 4

For single-channel Kvaser CAN interfaces like the Leaflight, the circuit identifier will always be 0.

Enter the CAN channel hardware identifier and CAN channel circuit identifier in the IO Configuration section of the nodes SDF Configurator entry.

IO Configuration

3.2 Troubleshooting

3.2.1 Secure boot

The kernel modules are built, but the kernel will not load the module.

Secure boot must be disabled on Ubuntu 16.04 (or any kernel after 4.4.0-20) for the Kvaser Linuxcan kernel modules to be properly loaded. Secure boot is configured through the machines BIOS.

3.2.2 Cannot detect linuxcan channels

A USB Leaf Light is connected, but the listChannels example application does not detect any hardware.

This happens when the Linux system cannot properly load the module, or the linuxcan module wasn’t built against the most recent kernel headers.

Follow these steps repeatedly until the Kvaser device(s) can be detected by listChannels.

  $ cd /usr/local/polysync/deps
  $ sudo tar xf linuxcan-5.19.tar.gz
  $ cd linuxcan
  $ sudo make clean 
  $ sudo make
  $ sudo make install 
  • Unplug and replug the USB Leaf Light hardware
  • Manually modprobe the kernel module used to communicate with the hardware
  $ sudo modprobe leaf   # see the list of modules and associated hardware in the linuxcan/README 
  • Run the listChannels example application
  $ /usr/local/polysync/deps/linuxcan/canlib/examples/listChannels

If channels are not listed, return to step 2. Eventually the Linux system will detect the USB device and load the driver.

3.2.3 Unable to sniff CAN data

While trying to validate the data coming in over CAN, error frames are read using the Kvaser linuxcan canmonitor example.

This is likely caused by having the wrong baudrate set in the canmonitor example, versus what the CAN sensor is publishing. Nearly all automotive based sensors publish data to the CAN bus at 500K baud.

Update the canmonitor source code to open the CAN channel with 500K baud to read and validate the incoming data.

$ cd /usr/local/polysync/deps/linuxcan/canlib/examples/
$ vim canmonitor.c
  Line 93: BAUD_1M --> BAUD_500K

Rebuild the example application with the new baud-rate to read CAN data at the proper frequency.