0

I have a slight problem with using can bus on a raspberry pi with Debian 64 bit running on it.

My /etc/modules-load.d/modules.conf looks like this:

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
ixxat_usb2can
can-dev
can-raw

Right after startup and sshing to the machine, I have the modules loaded:

~/$ lsmod | grep can
can_raw                28672  0
can                    28672  1 can_raw
ixxat_usb2can          28672  0
can_dev                28672  1 ixxat_usb2can
usbcore               266240  5 xhci_hcd,ixxat_usb2can,dwc2,brcmfmac,xhci_pci

The can bus seems to be ready and the interface can0 is up:

~/$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e4:5f:01:2e:2e:72 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.77/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2a02:810b:43c0:539c:e65f:1ff:fe2e:2e72/64 scope global dynamic mngtmpaddr
       valid_lft 86398sec preferred_lft 43198sec
    inet6 fe80::e65f:1ff:fe2e:2e72/64 scope link
       valid_lft forever preferred_lft forever
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
    link/can
4: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
    link/can
5: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether e4:5f:01:2e:2e:73 brd ff:ff:ff:ff:ff:ff
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:6b:e0:11:18 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

if I try to access a motor device connected via can adapter on interface can0, it does not work, I get an error code from the motor control library which is, sadly, not documented, but it happens while trying to find the can device.

What I think is weird: I only need to reload the can-dev module to make it work. Afterwards, there is no change to lsmod, but I can find the device and the motor moves just as I wish to:

~/$ sudo /sbin/modprobe can-dev
~/$ lsmod | grep can
can_raw                28672  0
can                    28672  1 can_raw
ixxat_usb2can          28672  0
can_dev                28672  1 ixxat_usb2can
usbcore               266240  5 xhci_hcd,ixxat_usb2can,dwc2,brcmfmac,xhci_pci

So my basic question is: What happens here? Am I missing anything? Thanks in advance!

Fux
  • 1
  • 2

1 Answers1

0

I just figured it out, kind of, so in case someone runs into any problem like this:

I have never looked at interface can1, because I don't use it. My usb to can dongle has this interface, but it is open ended, nothing is connected there, so it was way out of my scope. But having a closer look at ip a right after start and then again after loading the can-dev-module a second time manually reveals that it has impact on the state of interface can1.

Before manually loading can-dev:

3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
    link/can
4: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
    link/can

and afterwards:

3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
    link/can
4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP group default qlen 10
    link/can

So, it seems that the state of can1 is crucial for my device on can0 to work properly. All I did then was to create a file called can1 in my /etc/network/interfaces.d which looks the following and which gets can1 up on startup:

auto can1
iface can1 inet manual
  pre-up /sbin/ip link set can1 type can bitrate 1000000
  up /sbin/ip link set up can1 && /sbin/modprobe can-dev
  down /sbin/ip link set down can1

I am not sure if loading of the module in the "up" part of that configuration is neccessary here and - more important - has any disadvantages. If someone knows about that stuff better than me (and I am sure most of you linux people out there do), please let me know.

In the end, the can bus works as expected without executing additional commands, right from startup.

Fux
  • 1
  • 2