BeagleBone® Comms Capes remain mute

General Discussion
,
1

Due to new devices at home that exchange data via Modbus RTU and Can, I wanted to take the opportunity to “play around” with both protocols to make the house even smarter at best. With a BeagleBone Green Wireless and a BeagleBone Black Wireless still on hand, it made sense to use the BeagleBone® Comms Cape advertised on your site for testing. Both were ordered from Digi-Key and delivered quickly.

First: Disillusionment, as “only” two naked boxes were delivered, without documentation and without any link to a Wiki or similar.

Sources I found on this:

My problem: The BBs do not talk to each other.

Status (dmesg partially):

Device I

debian@BeagleBone:~$ dmesg
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.10.168-ti-r71 (voodoo@rpi4b4g-02) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1bullseye SMP PREEMPT Fri Sep 1 04:05:07 UTC 2023
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: TI AM335x BeagleBone Black Wireless

…

[    9.237625] Freeing unused kernel memory: 1024K
[    9.238468] Run /init as init process
[    9.238483]   with arguments:
[    9.238491]     /init
[    9.238497]   with environment:
[    9.238504]     HOME=/
[    9.238511]     TERM=linux
[    9.238518]     uboot_detected_capes=BBORG_COMMS,

...

Device II

debian@BeagleBone:~$ dmesg
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.10.168-ti-r71 (voodoo@rpi4b4g-02) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1bullseye SMP PREEMPT Fri Sep 1 04:05:07 UTC 2023
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: TI AM335x BeagleBone Green Wireless

…

[    9.289883] Run /init as init process
[    9.289898]   with arguments:
[    9.289906]     /init
[    9.289913]   with environment:
[    9.289919]     HOME=/
[    9.289926]     TERM=linux
[    9.289933]     uboot_detected_capes=BBORG_COMMS,

I think the two Capes have been properly recognised.
I have activated the Canbus on both units as follows:

debian@BeagleBone:~$ sudo modprobe can
debian@BeagleBone:~$ sudo modprobe can-dev
debian@BeagleBone:~$ sudo modprobe can-raw
debian@BeagleBone:~$ sudo ip link set can1 up type can bitrate 115200
debian@BeagleBone:~$ sudo ifconfig can1 up

dmesg says can is running:

debian@BeagleBone:~$ dmesg | grep can
[ 43.232214] c_can_platform 481cc000.can: c_can_platform device registered (regs=d27d78b0, irq=46)
[ 43.279717] c_can_platform 481d0000.can: c_can_platform device registered (regs=9064f815, irq=47)
[ 53.031698] wlcore: WARNING This default nvs file can be removed from the file system
[ 178.012869] can: controller area network core
[ 186.499703] can: raw protocol
[ 202.786333] c_can_platform 481d0000.can can1: bitrate error 0.1%
[ 202.786705] c_can_platform 481d0000.can can1: setting BTR=0519 BRPE=0000
[ 202.809239] IPv6: ADDRCONF(NETDEV_CHANGE): can1: link becomes ready

More info:

debian@BeagleBone:~$ ip a

4: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
    link/can 
5: can1: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN group default qlen 1000
    link/can

debian@BeagleBone:~$ sudo networkctl 
IDX LINK    TYPE     OPERATIONAL SETUP
  1 lo      loopback carrier     unmanaged
  2 usb0    gadget   no-carrier  configuring
  3 usb1    gadget   no-carrier  configuring
  4 can0    can      off         unmanaged
  5 can1    can      no-carrier  unmanaged
  6 wlan0   wlan     routable    configured 
  7 SoftAp0 wlan     routable    configured 

7 links listed.

Attempts with cangen can1 and cansniffer can1 remain unsuccessful.

When the can cable is removed, I see this:

[29678.107021] c_can_platform 481d0000.can can1: bus-off

Questions:

  1. is there any reasonable documentation/documentation for sold capes (70,- EUR after all)? For example, I would have known what the two LEDs on the boards are for. Besides, RS485 is also on the agenda.
  2. Does anyone have any ideas on how to get the capes to talk?

Regards.

2

not sure if this applies to CAN, but for wifi and ethernet, having multiple devices with the same host name will be an issue.

3

I have never had any trouble with CAN and the BBB boards, but not used that cape.

As you have truncated the u-boot log, is it loading any DTS overlay files ?
The cape only has a single CAN transceiver, so it seems strange that you are getting 2 CAN interfaces listed. It is pointless to enable both if you can only use 1, but should not stop it from working.

Ok first important thing. A CAN bus must be terminated at both ends with a 120 Ohm resistor across CAN high and CAN low. Looking at the schematic for the cape, there is a terminating resistor on the board, however you need to short out a couple of pads to enable it.

This is labeled SJ4 on the pcb. If this is not shorted, this is most likely the cause for no CAN.

It is a shame this is not a header pin. Hopefully you have access to a soldering iron.

Alternatively, if you have access to a 120 Ohm resistor, you could connect it to the screw terminals along with the cables on both boards.

As far as I can see from the schematic, the board offers to low side current sinks. The two transistors by the SINK connectors. The leds will turn on when these are on ( a high on the GPIO pins). SINKA is on GPIO48 and SINKB on GPIO49.

4

I have also thought about the terminators, but I can’t (or don’t want to) believe that I have to use a soldering iron. The hardware is, as I said, unfortunately sold as a “miracle bag”. I ordered some 120 Ohm resistors yesterday and will test them tomorrow to see if that helps.

Thank you very much for the quick feedback. I will give an update if the problem has been solved.

5

I suspect the most of the uses for the board are to connect to existing CAN networks, in which case there would be no need for terminators. But a simple 2 pin header would not have increased the cost of the board by much.

1 Like
6

Okay, I connected the two resistors to the screw terminals, parallel to the cables on both capes. Now it works.

What is the best way to configure can1 so that I don’t always have to enter the individual steps manually?

can
can-dev
can-raw
sudo ip link set can1 up type can bitrate 115200
sudo ifup can1
7

on my laptop I have a script to set the baud rate for my USB CAN interfaces.

however if the BB is using systemd, you can configure the CAN settings there.

Initializing CAN interfaces with systemd-networkd

Incidentally I have never had to modprobe the modules to get CAN working.