CAN BUS communication issue

Question

I am trying to set up communication between a rpi4b and pi zero using a custom mcp2515 module, it is custom because I changed the tja1050 for a sn65hvd230.

So, I am trying to send a simple message from 4b to zero, a string of numbers, but at raspberry zero, the one I am using as receiver, only gets this:

Timestamp: 1653393498.932273 ID: 0004 S E DLC: 8 00 10 00 00 00 00 00 00 Channel: can0

I checked at RPI4B, the sender, and the message sender loop runs at least 10 times before giving

can.CanError: Failed to transmit: [Errno 105] No buffer space available

The code for the can sender:

import time
import can

bustype = 'socketcan'
channel = 'can0'
bus = can.interface.Bus(channel=channel, bustype=bustype,bitrate=500000)

msg = can.Message(arbitration_id=0xc0ffee, data=[0, 1, 3, 1, 4, 1], is_extended_id=False)
while True:
    bus.send(msg)
    time.sleep(1)

The code for the receiver:

import can
import time
can_interface = 'can0'
bus = can.interface.Bus(can_interface, bustype='socketcan', bitrate=500000)

while True:
    message = bus.recv()
    print(message)

What I added to /boot/config.txt to both pi's(OBS: SPI is enabled):

dtoverlay=mcp2515-can0,oscillator=8000000,interrupt=25
dtoverlay=spi-bcm2835-overlay
dtoverlay=spi0-hw-cs

What I added to /etc/network/interfaces to both pi's:

auto can0
iface can0 inet manual
    pre-up /sbin/ip link set can0 type can bitrate 500000 triple-sampling on restart-ms 100
    up /sbin/ifconfig can0 up
    down /sbin/ifconfig can0 down

The modification I did to module it's not the cause for this issue, the hardware had worked before more than one time.

I tested all the wires in this setup and they are all good, the High and Low are correctly connected and are twisted , I also tried with another set of untwisted wires but didn't work,and in both modules the 120 ohm resistor is connected.

I tried changing boot/config.txt file,like one post I saw recommended removing the -overlay, but I couldn't detect any discernible change, so I changed back to the way it was.

Does anybody can offer some advice?

1#EDIT

So I tested socketcan commands to rule out my code as the source of the problem.

At my sender I sent thirteen cansend commands then the terminal started warning about buffer space.This operation can be seen below as a copy-paste from my terminal screen.

pi@pi4:~ $ cansend can0 123#1122334455667788
pi@pi4:~ $ cansend can0 123#1122334455667788
pi@pi4:~ $ cansend can0 123#1122334455667788
pi@pi4:~ $ cansend can0 123#1122334455667788
pi@pi4:~ $ cansend can0 123#1122334455667788
pi@pi4:~ $ cansend can0 123#1122334455667788
pi@pi4:~ $ cansend can0 123#1122334455667788
pi@pi4:~ $ cansend can0 123#1122334455667788
pi@pi4:~ $ cansend can0 123#1122334455667788
pi@pi4:~ $ cansend can0 123#1122334455667788
pi@pi4:~ $ cansend can0 123#1122334455667788
pi@pi4:~ $ cansend can0 123#1122334455667788
pi@pi4:~ $ cansend can0 123#1122334455667788
write: No buffer space available
pi@pi4:~ $ cansend can0 123#1122334455667788
write: No buffer space available

While at my receiver side I used the following command :

candump can0

to check the incoming messages, but nothing came out of it.

I also used :

candump -d -x -e

for more information, but it also came empty

2#EDIT

I thought that maybe the resistor in the module could be busted so using a breadboard I made a little circuit for the high and low lines with new 120 ohm resistors, nothing changed.

I also researched a bit and saw that nowadays the text in /boot/config.txt could be just the following line:

dtoverlay=mcp2515-can0,oscillator=8000000,interrupt=25

But again, no changes

Answer 1

I would suggest you read a bit more on CAN. Also posting a schematic of your system would help answer your question. You mention the 120 Ohm resistors, there should be two, one on each physical end of the bus. You need to take a multimeter with the power off measure the bus impedance. You need to get something between 110 Ohms to 130 Ohms. If you are out of this range you definitely have either a termination problem or a broken driver.

You also need at least one known good module as part of the built in CAN protocol is the ACK; that is asserted during the CAN packet frame. Another common problem with the MCP2515 modules is the crystal. REference: "dtoverlay=mcp2515-can0,oscillator=8000000,interrupt=25" Note I use these modules and they are great but I have also seen several crystals in them mainly 16 and 8 Mhz crystals. Also although not required is to connect the grounds of both modules together. You will see this provision on some of the modules.

There is also a length specification for the packet, it needs have the number of bytes in the message. If you are using a 11 bit identifier you are limited to 8 bytes. If you use the 29 bit identifier you can have larger data packets.