Jetson nano and mcp2515 can module

I have the same B00 and Jetpack 4.4, have tried with @shgarg 's instruction but the .py file got dumped!

Who can give me the files that @Jetson_SPI upload to wetransfer, thanks you a lot

Hey I share you thr files again here
https://we.tl/t-D70857dRVY

Hi @shgarg

When I test the CAN-modules (CAN0 and CAN1) on a vehicle, then its only CAN1, which actually is working.
both CAN0 and CAN1 is succesfully loaded on dmesg | grep mcp, but its only CAN1, there is working when I test it on a vehicle. the baud rate I use is 250000, the message I get from CAN0, when im testing on a vehicle is
can0 RX - - 000 [0]
and
can0 RX - - 788 [0]
I have tried to switch the modules, so the mcp which is can1 to can0 and vise versa and the same thing happened so im sure that there is a software issue
I hope you can help me with that
Thanks!

Hi @jetson_spi
I use the file that upload to wetransfer on jetpack4.4, I did the following step:
(1)configure the spi
(2)move the mcp251x.ko to /lib/…/can/spi/
(3)move the dtbo to /boot and move the dtb to /boot/dtb ,then /opt/navida/jetson-io/jetson-io.py
use “lsmod”,i can see the mcp251x
but’ ip link set can0 type can bitrate 500000’–>cannot find device “can0”
dmesg | grep mcp
[ 7.731186] mcp251x spi0.0: Cannot initialize MCP2515. Wrong wiring?
[ 7.750954] mcp251x spi0.0: Probe failed, err=19
[ 7.797459] mcp251x spi1.1: Cannot initialize MCP2515. Wrong wiring?
[ 7.842612] mcp251x spi1.1: Probe failed, err=19
Can you tell me how to solve this issue,thank you a lot a lot

Hi,

after a reboot 2 days ago CAN will no longer work. Any idea what is going wrong?
After a reboot all looks good. But when I send date from a other device the CAN on the Nano goes to BUS-OFF and I see 1 TX packet with 18446744073709551615 bytes. The CAN bus work fine. I can see the packets on a third device.

After reboot:

@Phoenix:~$ ip -d -s link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
link/can promiscuity 0
can state ERROR-ACTIVE restart-ms 0
bitrate 1000000 sample-point 0.750
tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
mcp251x: tseg1 3…16 tseg2 2…8 sjw 1…4 brp 1…64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0

Receive packets:

@Phoenix:~$ ip -d -s link show can0
4: can0: <NO-CARRIER,NOARP,UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10
link/can promiscuity 0
can state BUS-OFF restart-ms 0
bitrate 1000000 sample-point 0.750
tq 125 prop-seg 2 phase-seg1 3 phase-seg2 2 sjw 1
mcp251x: tseg1 3…16 tseg2 2…8 sjw 1…4 brp 1…64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 1 1 1 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
RX: bytes packets errors dropped overrun mcast
23 3 0 0 0 0
TX: bytes packets errors dropped carrier collsns
18446744073709551615 1 0 0 0 0

Is there a software problem? I am using Jetpack 4.4 with the latest version.
I have checked different MPC2515 boards.

Hi, thanks for sharing this. I already have the tegra210-p3448-0000-p3449-0000-b00.dtb in /boot/dtb folder, so do I need to replace it by your file? Last time I tried with the above instruction of @shgarg but it the python file dumped (even 2 file .ko and .dtbo are in the right place)

What do I need to modified to get 1 CAN bus work?

Thanks!

Hi Everyone,
Attaching the revised dtb files. You do not need to update mcp driver. Please try communication with these steps:

  1. Connect first MCP251x chip to SPI1 on 40-pin, use CS0 pin, connect INT on Pin 31 (GPIO Z.0)
  2. Connect second MCP251x chip to SPI2 on 40-pin, use CS0 pin, connect INT on Pin 32 (GPIO V.0)
  3. Copy tegra210-p3448-0000-p3449-0000-a02-mcp251x.dtbo under /boot/
  4. Copy tegra210-p3448-0000-p3449-0000-a02.dtb under /boot/dtb/
  5. Run /opt/nvidia/jetson-io/jetson-io.py
  6. Select Configure Jetson for compatible hardware
  7. Select MCP251x CAN Controller
  8. Save and reboot
  9. Make CAN0 and CAN1 inerface up on network:
    ip link set can0 up type can bitrate 500000
    ip link set can1 up type can bitrate 500000
    candump can0 &
    cansend can1 123#abcdabcd

Also, please post your latest queries if any.
These dtbs are already present in our BSP version R32.4

Thanks,
Shubhimcp.zip (45.0 KB)

Hi shgarg,

After I chose new hardware MCP251X from jetson-io.py, I got fail to overlay error. Do you know why? I am using L4T R32.4.3. THX

Could you please share the b00 file again? It has been expired.

@shgarg
Hi shgarg
I use your newly uploaded file of mcp.zip. my jetson nano is b01, L4T 32.4.3,
MCP2515 is successfully initialized.but can0 and can1 can’t send and receive data.Can you guess the possible errors.thanks you a lot

I’m trying to get this working on a custom production board, but I’m not having a lot of luck. The kernel driver finds the gpio pin and attempts to load, but doesn’t get good data (it’s always 255) on the read back from reg = mcp251x_read_reg(spi, CANSTAT); in the function mcp251x_hw_reset.

The one stage in the steps listed I can’t try to replicate is the jetson-io.py script since it’s only meant for devkits. What exactly does that script do? Does it update the u-boot device tree? Is there a way to tell if the SPI pins are in the correct mux configuration?

edit: Well, I’ve updated the u-boot with the one from here: GitHub - gtjoseph/jetson-nano-support at l4t_32.2.1 and it seems to have brought the SPI to life (I can’t get scope probes on these lines unfortunately). I’m now getting 64 back from the first read_reg, and it looks like it’s expecting 128. It looks like it’s dropping a bit on one end or starting too early, so now I get to fiddle with tap delays?

edit edit: It turns out I was driving the SPI way too fast. Dropping the SPI down to 8 MHz solved the bit shift problem.

Hey, I’m trying to replicate the setup: two mcp2515 on a jetson nano (model b00). I have followed instructions (device tree update, latest mcp251x.ko module) and at this point I can bring up two can interfaces, but I can’t send/receive any data. I’m using latest BSP (released 07/07).

Some debug info:

rokas@nano:~$ sudo ip -d -s link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
link/can promiscuity 0
can state ERROR-ACTIVE restart-ms 0
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
mcp251x: tseg1 3…16 tseg2 2…8 sjw 1…4 brp 1…64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
rokas@nano:~$ sudo ip -d -s link show can1
5: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
link/can promiscuity 0
can state ERROR-ACTIVE restart-ms 0
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
mcp251x: tseg1 3…16 tseg2 2…8 sjw 1…4 brp 1…64 brp-inc 1
clock 8000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0

rokas@nano:~$ dmesg | grep mcp
[ 4.796122] mcp251x spi0.0 can0: MCP2515 successfully initialized.
[ 4.807317] mcp251x spi1.0 can1: MCP2515 successfully initialized.

rokas@nano:~$ cat /proc/interrupts | grep mcp
267: 0 0 0 0 GPIO 168 Edge mcp251x
299: 0 0 0 0 GPIO 200 Edge mcp251x

rokas@nano:~$ cansend can0 01a#23223344AABBCCDD
rokas@nano:~$ cansend can0 01a#23223344AABBCCDD
rokas@nano:~$ cansend can0 01a#23223344AABBCCDD
rokas@nano:~$ cansend can0 01a#23223344AABBCCDD
rokas@nano:~$ cansend can0 01a#23223344AABBCCDD
rokas@nano:~$ cansend can0 01a#23223344AABBCCDD
rokas@nano:~$ cansend can0 01a#23223344AABBCCDD
rokas@nano:~$ cansend can0 01a#23223344AABBCCDD
rokas@nano:~$ cansend can0 01a#23223344AABBCCDD
rokas@nano:~$ cansend can0 01a#23223344AABBCCDD
rokas@nano:~$ cansend can0 01a#23223344AABBCCDD
write: No buffer space available
rokas@nano:~$ cansend can0 01a#23223344AABBCCDD
write: No buffer space available
rokas@nano:~$ cansend can0 01a#23223344AABBCCDD
write: No buffer space available

Tripled checked the wiring, seems to be fine.
Maybe you have any ideas how to fix this to be able to send and receive data?

Thanks in advance

I got stuck in the same place and never got through it on a devkit. I set it aside and was able to get everything running with a lot less trouble on a production module on a custom board, so the difference was probably the external wiring.

If you can initialize the mcp2515, then make sure the clock in the device tree is correct for the modules you’re using. The canbus clock in the device tree needs to be set to double what the actual clock is since the driver divides by two, according to the nvidia developers. Note that this is different from the SPI frequency. I’m sure you’ve already checked the resistors you added are right. If you have an oscilliscope, does the cansend command generate can traffic?

@andrew.pease thanks for prompt reply.

I have 8Mhz oscilator on the MCP2515 board. I am setting 16M frequency in the devtree, I can see that, ip command seems to confirm correct frequency:

4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
link/can promiscuity 0
can state ERROR-ACTIVE restart-ms 0
bitrate 500000 sample-point 0.875
tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1
mcp251x: tseg1 3…16 tseg2 2…8 sjw 1…4 brp 1…64 brp-inc 1
clock 8000000

I tried setting spi-max-frequency to 8M (0x7A1200), before it was 10M, doesn’t make any difference.

It seems it does not send anything with cansend (I will check with osciloscope later on). But if I connect the interfaces to other can devices that are sending data from arduinos, I get very strange RX/TX counts in statistics:

rokas@nano:~$ sudo ip -d -s link show can0

RX: bytes packets errors dropped overrun mcast
0 3 0 3 0 0
TX: bytes packets errors dropped carrier collsns
18446744073709551615 1 0 0 0 0

so it seems the CAN interface is reacting to CAN data, but not in a correct way. If I bring up can interface, while disconnected from other devices I can’t see those huge numbers:

rokas@nano:~/dtb-can$ sudo ip -d -s link show can0

RX: bytes packets errors dropped overrun mcast
0 0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0

Is it possible for you to share dts file? Maybe I could find some inspiration where the problem might be…

UPDATE: I’m able to receive some data by setting double bitrate (using 1M, while sending devices use 500K). But does not seem reliable, the interface goes from:

4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10

to:

4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 10

after couple of minutes. I need to manually bring the interface down and up again to receive data again. Sending data to the interface breaks it immediately.

UPDATE 2: The double bit rate issue was my own fault, I can receive data with correct bit rates.

hi ,are you able to send and receive data now?

Hi all,

I have been closely following/studying this thread and following along, trying to get my MCP2515 working via SPI with the Jetson Nano (b00).

I have done the following in this order -

  1. Fresh install of Jet Bot latest release from the website
  2. Used jetson-io.py to enable SPI successfully. They now show on the pin header when I re run jetson-io.py
  3. Downloaded the latest mcp.zip files from @shgarg dated July 08 2020 and extracted
  4. Copied the .ko file to /lib/modules/4.9.140-tegra/kernel/drivers/net/can/spi/
  5. Opened the .dtb and .dtbo files with sudo nano and replace a02 with b00 as my Jetson nano original files are named b00.
  6. Replaced a02 with b00 in the names of the .dtb and .dtbo files
  7. Copied the .dtb file to /boot/dtb/
  8. Copied the .dtbo file to /boot/
  9. Rebooted
  10. Ran jetson-io.py and selected Configure for compatible hardware, then selected MCP2515, but I keep getting the error “FATAL ERROR!
    Failed to overlay /boot/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb
    with /boot/tegra210-p3448-0000-p3449-0000-b00-mcp251x.dtbo!”

Please can someone help with this?

hi,you have to modify the “compatible” in the dtb file? Mine is fine,but not able to send and receive data.

Hi everyone,
I don’t have device access due to wfh.
For people who are facing issues with send/receive, It looks like the issue with interrupts.
Can you try the following experiment and let me know the results.

Short any 2 GPIO pins(For ex. Pin 31 and Pin 33) of 40-pin header and try toggling and producing interrupts.

  1. Write a small driver where you take one GPIO as input and configure pin as interrupt pin. Configure other GPIO as output and toggle it.
    Check the interrupts raised in cat /proc/interrupts for the corresponding irq number.
    If you are facing issues with driver, let me know, I will help you.

Thanks,
Shubhi

After some fiddling, I am able to receive data quite reliably.

One thing to mention, the can_clock configuration should not be doubled in the device tree! This is somewhat confusing, the clock division is done internally by the MCP2515, you need to specify the same oscillator frequency value you have on your MCP2515 board. Otherwise bit timings / bit rates might be wrong. I have 8MHz oscillator and I’m using this can_clock configuration:

    clocks {

            can_clock: can_clock {
                    phandle = <0x12c>;
                    linux,phandle = <0x12c>;
                    clock-accuracy = <0x64>;
                    clock-frequency = <0x7A1200>;
                    #clock-cells = <0x0>;
                    compatible = "fixed-clock";
            };
    };