bbb canbus

The bbb has two canbus ports. On the VE Cape both are available.

The TI AM335x dcan driver guide is here.

According to that manual, can0 in linux is not hard mapped to the physical can0 or can1 on the AM3558. Which one is can0 and which one is can1 depends on the order of registering the instance. I suppose this registering happens at kernel level cq. bootup, so should not be a big issue.

• VE.Can is an isolated canbus port, available to the user as the dual VE.Can RJ-45 socket
• Can aux is not isolated. available to the user with a 3 pole connector. GND, CAN-H and CAN-L

name	physical	linux
VE.Can TX	P9.26 / GPIO0_14/S1_RX	can1
VE.Can RX	P9.24 / GPIO0_15/S1_TX
can2 TX	P9.20 / GPIO0_12	can0
can2 RX	P9.19 / GPIO0_13

Note that both canbus ports have no onboard mounted termination resistors. All our VE.Can products are shipped with a bag with two RJ-45 plugs that contain the termination resistors.

When all is configured correctly, listing all available network devices will include the canbus ports:

root@beaglebone:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can
3: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can
4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default
    link/sit 0.0.0.0 brd 0.0.0.0
5: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
    link/ether ec:24:b8:9e:18:df brd ff:ff:ff:ff:ff:ff

Log of enabling the can0 interface, setting it to 250kbit:

root@beaglebone:~# ip link set can0 up type can bitrate 250000
[ 3528.918254] c_can_platform 481cc000.can can0: setting BTR=1c05 BRPE=0000
[ 3528.925567] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
root@beaglebone:~# ifconfig
can0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP RUNNING NOARP  MTU:16  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:162

eth0      Link encap:Ethernet  HWaddr EC:24:B8:9E:18:DF
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:173

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:11371 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11371 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:978944 (956.0 KiB)  TX bytes:978944 (956.0 KiB)

Run candump to see if there is any traffic on the canbus. Line 3 and further down in below example is data streaming in:

root@ccgx:~# candump can0
interface = can0, family = 29, type = 3, proto = 1
<0x1cefff24> [8] 66 99 db ed 8c 0a 00 00
<0x1cefff24> [8] 66 99 db ed 82 0a 00 00
<0x19f30624> [8] a9 00 00 fc ff ff ff ff
<0x19f21424> [8] 00 4f 14 00 00 ff ff a9
<0x19f21424> [8] 01 50 13 00 00 ff ff a9
<0x19f21224> [8] 80 09 a9 00 00 ff ff ff
<0x19f21224> [8] 81 ff ff ff ff ff ff ff
<0x19f21224> [8] 00 09 a9 01 03 ff ff ff
<0x19f21224> [8] 01 ff ff ff ff ff ff ff

To check that canbus actually works (both tx and rx) use vup (requires a victron canbus device to be connected):

# vup -c socketcan:can1
Querying devices
| NAD  | man | serial              | boot   | bmode| vup| vup#| id   | description                      | version  |
| 0x00 | 161 | 0033680             | x      | x    | x  | x   | x    | x                                | x        |

To update the first device in the above list, use the following command:

vup -n 0x00 -f new_firmware.vup

For other devices, change the address, as found in the first column (NAD).
The name of the firmware file depends on the product.
E.g. skyllai_control_v1.10.vup for updating a Skylla-i Control to version 1.10.