Jetson nano CAN via J17 pins only works with `loopback on`

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

Hi,

I am having a similar issue with the Jetson Nano Nx compared to:

In my case, we hook a CAN transceiver up to the J17 pin set on the board and run the following

#!/bin/bash

sudo busybox devmem 0x0c303020 w 0x458
sudo busybox devmem 0x0c303018 w 0x400

sudo modprobe can
sudo modprobe can_raw
sudo modprobe mttcan

# Does not work without "loopback on" unknown why
sudo ip link set can0 type can bitrate 1000000 loopback on

sudo ip link set up can0
ip -s -d link show can0

candump can0 &
cansend can0 123#abcdabcd

This successfully transmits the CAN message over the bus and is received by another node on the bus. We also see the message via candump. We also see the message on the Tx side and bus side via a logic analyzer.

In this configuration we receive loopback messages even without the transceiver or shorting the Tx and Rx pins. Why is that?

Nothing is transmitted on the Tx pins (or the bus) without ā€˜loopback onā€™ in the above script.

Is loopback on required to transmit CAN messages?

3

ā€œLoobackā€ mode means that the receiving buffer of the CAN controller will only accept the messages sent by itself. In my opinion, the message transmission is carried out inside the CAN controller without wire connection.

Loopback mode can indeed send messages to the CAN bus, but it cannot accept messages from other nodes. I think the more important significance of loopback is to test whether the CAN controller is normal.

In my opinion, if you want to realize two-way communication, you should configure it into normal can mode, and someone has successfully done it. Follow: GitHub - Aravindseenu/CAN-communication-on-Nvidia-AGX-xavier
However, I did not succeed according to his steps.

In fact, I tested with other AGX xaviers in the laboratory and failed to use the normal mode of can

1 Like
4

Correct!
With loopback , it is within the controller and not need external connections. You cannot send outside of CAN0 with loopback.
To transfer to other CAN nodes on bus, check clock rates, bitrates, it should be same for all the nodes on the bus.

5

Thanks for the clarification.
So shorting the Tx and Rx pins is not required to test loopback. Could you please clarify this under the " Loopback test" heading at Welcome ā€” Jetson Linux<br/>Developer Guide 34.1 documentation

6

Thanks @JohnSyu. That is consistent with what we observed.

What confuses me is why can we transmit (and receive on the other nodes) at 1Mbps using loopback on but 1Mbps cannot be achieved using normal mode without changing the parent clock.

@shgarg any thoughts on this?

I will attempt to change the parent clock but there is a lot of confusing documentation to go through to achieve that.

7

I donā€™t know, Iā€™m just one postgraduate, hhhhhhhhhh

But if I change the parent clock and achieved CAN using normal modeļ¼Œ I am willing to spend a lot of time writing down my development process in detail.

8

when the bitrates differ, you will not be able to receive sent message in proper way and thus errors will show up.
Please change clock to match bitrates.
https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/clocks.html#wwpID0E06B0HA