BUG: Jetson Nano P3450-B00 with MCP2515, can receive but cannot send

Hi folks,

I and my teammates are currently working with Jetson Nano Devkit 4GB. We want to connect that Jetson with multiple STM32 via MCP2515 drivers but the problem is Jetson unable to transmit but able to receive data. And the Jetson stops receiving any data after transmit until we run sudo ifconfig can0 down then sudo ifconfig can0 up. We experimented it with both candump + cansend and C program. Keep in mind that we already updated to the latest Jetpack version yesterday. Also the DTB file is automatically configured with jetson-io.py script which is preloaded by Jetpack to enable MCP251x support. Then I manually modify the clock speed to 8MHz and recompile with dtc.

Jetson Nano’s System Information

Here’s what ip -det link show can0 command says:

4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0 
    can state ERROR-ACTIVE restart-ms 0 
	  bitrate 125000 sample-point 0.875 
	  tq 500 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 8000000numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

Also we spotted that the MCP2515 has its interrupt pin successfully attached to Jetson Nano, here’s what /proc/interrupts says:

        CPU0    CPU1    CPU2    CPU3
299:      13       0       0       0    GPIO 200 Edge    mcp251x

In case you wondering, here’s the dmesg message:

[    8.065539] mcp251x spi0.0 can0: MCP2515 successfully initialized.

Experiment Result

So we ended up purchased another identical Jetson Nano to do experiment. Here’s the result:

  • STM32 to STM32: Working both direction
  • STM32 to Jetson: Working
  • Jetson to STM32: Not working, seems stuck on kernel side, repeat this multiple times cause Jetson to throw error write: no buffer space available
  • Jetson to Jetson: Not working at all, seems stuck on kernel side too

We Borrowed an Oscilloscope, Here’s a Result

On this experiment, a single STM32 send RTR frame with interval around 1 second whereas Jetson send “Hello!” string with interval 5 milliseconds. Then we put the probe at CAN-H cable with ground at one of unused Jetson ground pin. We also change 5ms to 500ms on the second try but the result exactly same.

If you see those images carefully, you’ll realize that the Jetson is having seizure after I run sudo ifconfig can0 down command. This supposed to not happen! We really confused what makes this occured. The pins are correctly and tightly connected, we checked them three times on both side. Oh… also this exactly the same with our new Jetson Nano.

Literally I scratched my head until get bald because of this anomaly. Dear moderators please help us out from this misery. Thanks!

Update #1

STM32 to Raspberry PI 4 Model B with latest OS is working in both direction, simultaneously. I don’t test Raspberry PI to Jetson Nano yet, pretty sure it will fail. The point is this is not kernel’s fault but more like Jetson itself.

By the way, the configuration on both Raspberry PI and Jetson Nano are same. So the configuration supposed to not be blamed.

We will do the investigate to have the update soon. Thanks

1 Like

Thanks! I suspect this because kernel version 4.9 but we didn’t test with custom kernel yet. Last time I build it fails (compilation error) which means I have to re download the source again. Raspberry uses 5.10 by the way.

Update #2

We did compile the L4T kernel successfully with mcp251x.c came from upstream repo. The result still same. Thus, the problem most likely came from DTB. We’ll keep investigate this problem.

Hey kayccc, how’s the investigation? Any updates? I have a quite bad news. After we have discussion with our boss, he’s not happy of this long-running bug and there’s a big possibility to ban any Nvidia product for next research. Please for your cooperation, thanks!

Can you check this: Jetson nano and mcp2515 can module - #289 by michael.sanne

After spending entire day of fixing the problem with helps from that seeed repo and dts file, finally it works 😁

Thanks for your guidance shgarg! I summarized the fix with this repo fork:

github.com/Thor-x86/seeed-linux-dtoverlays

Hope it helps, thanks!