CAN bus from Raspberry Pi3+ to Arduino Nano

Question

I am currently trying to add my RPi-3B+ to my CAN-Network. I successfully have a running CAN-Network with 10 Unos\Nanos. In the future the Pi should act as a command center and data storage. My network uses this shield (IC's: MCP2515 and TJA1050)

SPI is enabled on the Raspi-config and I already used other cips using SPI and I2C. These two bussystems worked already with other ICs. The wiring looks like (according to this pinout)

RPi Pin    CAN Module
5V------------VCC
GND-----------GND
GPIO10--------MOSI (SI)
GPIO09--------MISO (SO)
GPIO25--------INT
GPIO11--------SCK
GPIO08--------CS

My complete network looks like this. Currently one Arduino constantly transmit a status message. The 'slave'-Arduinos receive the message and acknowledge it. The CAN transmission between the Arduinos is still valid

I followed this tutorial to add and activate a CAN interface. My steps are:

Edit "/boot/config.txt"

dtparam=spi=on
dtoverlay=mcp2515-can0,oscillator=8000000,interrupt=25 
dtoverlay=spi-bcm2835-overlay

Reboot Install CAN-utils library

sudo apt-get install can-utils

Check network status (ifconfig can0)

can0: flags=193<UP,RUNNING,NOARP>  mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Start network (with 500kHz)

sudo ip link set can0 up type can bitrate 50000

Send Can-Message (extended frame)

cansend can0 10100208#FFFFFFFFFFFFFFFF

Here is the problem. Something is sent over the CAN bus, but nothing that resembles a valid telegram. My receiver does not recognize anything. Measuring the bus using a oscilloscope (CH1:H-Gnd and CH2:L-Gnd) gives following result.

Even only one telegram is sent, the bus seems to be constantly loaded with some kind of signal. The communication is stopped after a few tries. The I am unable to send another telegram over can0. Only after the network is 'down' and 'up' again a new telegram can be sent. This may be due to the Tx-Error already on the chip and is probably a follow up error due to the faulty telegram.

When the message is not picked up does it 'circulate' until it is taken by something? (I would guess not, but something blocks the busline). Does the Pi operate at another level, since the measured bus is +1V higher than the telegram I measure for the Arduino-busline?

For reference: Here is a telegram when only my Arduinos are communicating

Has anyone encountered a similar behavior?

EDIT_05.16: After a suggestion from the comments I added my CAN-Network and additional measurement

EDIT_05_17: Sadly there is a lot of conflicting information regarding CAN modules and Pi out there. The few 'working' CAN networks consists of two Pis with the same build and setup. I am starting to doubt a consistent communication (similar to the stable Arduinos, STM, PICs and Labview-CAN cards I already used succesfully) with CAN is even possible with the current version of the OS. Still, I have a some tries left in me. In a few tutorials it is suggested, that the MCP2515 must be supplied with 3V3 rather than 5V . I do not understand why, since Vdd in the datasheet ranges 2.7-5.5V. Its never explained in detail. Also the SPI communication works with ICs that have this common input range. Since I am out of ideas I cut the backside of the module (5Vto3v3) and supplied the TJA1050 with 5V and the MCP2515 with 3V3. With this configuration the can0 network does exist (I defined it) but can not be brought up

sudo ifconfig can0 up

just freezes the command window and the Pi needs to be restarted. This is because of an endless loop of trying to reach the network. Changing the input levels of the receiver/ transceiver does not yield any results.

I found additional commands to check the status for SPI and the connected IC in general. Using

dmesg | grep -i spi
dmesg | grep -i can

gives a little more insight into the status. After a fresh reboot the SPI status is

pi@pi:~ $ dmesg | grep -i can
[   10.775239] CAN device driver interface
[   11.005567] mcp251x spi0.0 can0: MCP2515 successfully initialized.
[   14.271868] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
pi@pi:~ $ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.4.20  netmask 255.255.252.0  broadcast 192.168.7.255
        inet6 fe80::35dc:42ad:db6b:fec1  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:4d:6c:1c  txqueuelen 1000  (Ethernet)
        RX packets 92  bytes 8087 (7.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 40  bytes 4134 (4.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

After sending an extended frame the status message looks like

pi@pi:~ $ cansend can0 10100208#FFFFFFFFFFFFFFFF
pi@pi:~ $ dmesg | grep -i can
[   10.775239] CAN device driver interface
[   11.005567] mcp251x spi0.0 can0: MCP2515 successfully initialized.
[   14.271868] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
[  245.903663] can: controller area network core
[  245.903880] NET: Registered PF_CAN protocol family
[  245.926609] can: raw protocol
[  245.929288] mcp251x spi0.0 can0: bus-off

at this point I am unable to restart the IC (ifconfig can0 down\up) and send another message, as if it is blocked somehow. I do not know if this is a trace for the root problem or just the next one with the Pi-CAN communication in general.

Answer 1

You state: "it is suggested, that the MCP2515 must be supplied with 3V3 rather than 5V . I do not understand why, since Vdd in the datasheet ranges 2.7-5.5V. Its never explained in detail. Also the SPI communication works with ICs that have this common input range. Since I am out of ideas I cut the backside of the module (5Vto3v3) and supplied the TJA1050 with 5V and the MCP2515 with 3V3. With this configuration the can0 network does exist (I defined it) but can not be brought up" You are correct the MPC2515 will operate on 3V3 however the TJA1050 is rated at 4.5V minimum. This is a physical limit of the IC not the bus. I replaced the TJA10 5o with a SN65HVD232 and powered it with 3V3, and the MPC2515 with 3V3. This places both components in a valid voltage range and the MPC2515 has the appropriate IO levels for the Pi.

Answer 2

Like you I have several Arduinos operating on CAN. It is the start of rebuilding my home automation system. It has 120+ hardwired relays running from a XT. I plan on the Pi as the controller but have not gotten that far yet.

Looking at your block diagram you have 120 Ohm resistors on each physical end of the bus, that is correct. Another thing I would try is be sure all the grounds are connected, I know there is no need but that trick has bailed me out a few times until I found the offending noise source. If the bus is to short it can cause similar problems. I am not sure but you may have reflections showing on the first scope trace. The MPC2515 module is a good unit but not 5V only. I changed the line driver on mine to one compatible with 3.3V (SN65HVD232) so it would work with 3.3V micro. The MPC2515 is 3V compatible. Also check the crystals, I have come across three different values depending on where I got the modules.

Answer 3

From another Pi-Baker I borrowed a "Waveshare 2CAN-Shield"

Using the settings from their wiki, I set the "/boot/config.txt" to

dtparam=spi=on
dtoverlay=mcp2515-can1,oscillator=16000000,interrupt=25
dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=23

and the configuration for the networks to

sudo ifconfig can0 down ; sudo ifconfig can1 down
sudo ip link set can0 type can bitrate 500000 ; sudo ip link set can1 type can bitrate 500000
sudo ifconfig can0 txqueuelen 65536 ; sudo ifconfig can1 txqueuelen 65536
sudo ifconfig can0 up ; sudo ifconfig can1 up

I rewrote parts of the library of coryyfowler and wrote a small c++ program to simply send a telegram every 3.1s. I discovered that the clockspeed and the register value of the bitrate are correlated. These may led to incompatible timing in the MCP2515-Shield setup. With 16Mhz,ICs using 3.3V and 8Mhz on the Arduinos the CAN-Network is working. I forked this library on Github and will edit the link here when I am finished with it (cross platform library suitable for Nano\Uno\Pi)

pi@pi:~ $ candump can1
  can1  010   [8]  07 06 05 04 03 02 01 00 <--- Pi (3.1s)
  can1  100   [8]  00 01 02 03 04 05 06 07 <--- Arduino (2.4s)
  can1  100   [8]  00 01 02 03 04 05 06 07
  can1  010   [8]  07 06 05 04 03 02 01 00
  can1  100   [8]  00 01 02 03 04 05 06 07
  can1  010   [8]  07 06 05 04 03 02 01 00
  can1  100   [8]  00 01 02 03 04 05 06 07
  can1  010   [8]  07 06 05 04 03 02 01 00
  can1  100   [8]  00 01 02 03 04 05 06 07
  can1  010   [8]  07 06 05 04 03 02 01 00
  can1  100   [8]  00 01 02 03 04 05 06 07

I tested the modified hardware (MCP2515 shield with the extra 3V3 connection) and the error persists. The telegram from the Arduino is sent, but the bus is overloaded with a periodic telegram unable to be received.

In conclusion:

• The different voltage levels between the sender/ transceiver seems to have effect on the levels of the bus
• The clockspeed is directly correlated in the register values of the bitrate
• The main issue was resolved by changing to more suitable hardware

My step is to build test cases:

• Add an Arduino with incompatible CAN-Bus
• 'Overload' the bus with constant irregular telegrams (1MB\s vs 100kB\s)
• Recreate the reflexions
• Create protocoll when the bus is not reachable anymore (only happened on the Pi until now -> down\ up again)

Since the network is running with standard and extended frames I can continue. My original error seems to be resolved.