CAN Bus Info
Standard Data Frame

Acronyms
BBB - Beagle Bone Black Development Board
CAN - Controller Area Network
DTS - Device Tree Source
OS - Operating System

Tested on Buildroot release 2019.05
See the pull request at:
  https://github.com/cu-ecen-5013/buildroot-assignments-base/pull/19

DTS patch

TI Pin Mux Tool
TI Pin Mux Tool - Training Video
Example DTS Patch
CAN DTS Example
The TI Pin Mux Tool was used to generate reference pin mappings for the CAN ports. The pins that were mapped for the CAN ports were chosen because the pins were routed to the P9 header on the BBB. The tool generated a .dtsi file. The pin mappings from the file were then incorporated into the BBB file:
  am335x-bone-common.dtsi

The patch was generated from a diff of the changes with and without the CAN port pin mappings. The patch includes disabling the I2C2 port because it overlaps with can0. The patch enables can0 and can1.
  base_external/patches/0001-am335x-bone-common.dtsi.patch

Add the external patches directory to the global patch directories. Use a space to separate directories.
make menuconfig
Build options -> global patch directories ../base_external/patches
Note: There is a conflict with can0 and i2c2, so i2c2 pins are disabled.

CAN driver included in the kernel

TI CAN Driver Guide
make linux-menuconfig
Networking support -> CAN bus subsystem support -> CAN Device Drivers -> Bosch C_CAN/D_CAN devices -> Generic Platform Bus based C_CAN/D_CAN

CAN tool included in the kernel

make menuconfig
Target packages -> Networking applications -> can-utils

The ip application is a link to busybox. This version of ip does not set the CAN interface bitrate correctly. A different ip application is available in iproute2 that works with the CAN interface. Add the iproute2 to the build.
make menuconfig
Target packages -> Networking applications -> iproute2

CAN bus diagram for connecting the ports

Verify Devices are present in OS

The CAN port memory mapped registers are located here:
  can0 - 0x481CC000
  can1 - 0x481D0000

On the target, the CAN devices are listed in:
/sys/devices/platform/ocp
  481cc000.can
  481d0000.can

Verify CAN pin mux settings:
  devmem 0x44E10978 - CAN0 TX
  devmem 0x44E1097C - CAN0 RX
  devmem 0x44E10980 - CAN1 TX
  devmem 0x44E10984 - CAN1 RX

The kernel modules are in:
  /sys/module/can/lib/modules/4.14.40/kernel/drivers/net/can/c_can

Scripts for bringing up the interface at boot

Mastering Embedded Linux Programming - Buildroot init scripts base_external/rootfs_overlay_beaglebone
  etc/init.d/S39canmodules
  etc/network/interface - added can0 and can1
  sbin/can_load
  sbin/can_unload

Kernel messages at boot:
Starting can
[ 2.880626] can: controller area network core (rev 20170425 abi 9)
[ 2.887615] NET: Registered protocol family 29
[ 2.906246] can: raw protocol (rev 20170425)
[ 2.931092] CAN device driver interface
[ 2.965653] c_can_platform 481cc000.can: c_can_platform device registered (regs=fa1cc000, irq=36)
[ 2.977425] c_can_platform 481d0000.can: c_can_platform device registered (regs=fa1d0000, irq=37)

How to use to CAN tools to verify individual CAN port operation

This test does not require anything to be connected to the CAN port. The CAN TX pin does transmit data. The CAN TX pin can be viewed on an oscilloscope to verify operation.

Put the CAN port in loopback mode:
ifconfig can1 down
ip link set can1 type can loopback on
ifconfig can1 up

In one terminal run candump to receive data:
candump can1

In another terminal run cansend to transmit data:
cansend can1 01F#1122334455667788

Show can port settings:
ip --detail link show can1

Show can port status:
ifconfig can1

How to use to CAN tools to verify CAN bus operation

This test requires both CAN ports be connected together via CAN transceivers as shown in the diagram above.

In one terminal run candump to receive data:
candump can1

In another terminal run cansend to transmit data:
cansend can0 01F#1122334455667788