Trouble with CAN

Autonomous Machines Jetson & Embedded Systems Jetson Orin Nano
1

I’ve set up CAN using this guide:

rmann@mouse:~$ sudo devmem2 0x0c303010 w 0xc400 
/dev/mem opened.
Memory mapped at address 0xffff94c4d000.
Value at address 0xC303010 (0xffff94c4d010): 0x400
Written 0xC400; readback 0xC400
rmann@mouse:~$ sudo devmem2 0x0c303018 w 0xc458 
/dev/mem opened.
Memory mapped at address 0xffff93468000.
Value at address 0xC303018 (0xffff93468018): 0x458
Written 0xC458; readback 0xC458
$ sudo modprobe can
$ sudo modprobe can_raw
$ sudo modprobe mttcan
$ sudo ip link set can0 up type can bitrate 500000 dbitrate 1000000 berr-reporting on fd on
$ rmann@mouse:~$ cat /proc/device-tree/mttcan\@c310000/status
okay

Unfortunately, examining the TX pin while executing

$ cansend can0 123##1abcdabcd

TX always stays high. Similarly,

rmann@mouse:~$ candump -x any

outputs nothing, even though there is a steady stream of CAN data coming into the RX pin.

Any idea what I missed?

3

Hi rmann,

Are you using the devkit or custom board for Orin Nano?
What’s your Jetpack version in use?

Do you want to verify internal loopback test for CAN?
Or you’ve connected any other CAN device?
Could you share the block diagram of your connection and use case?

4 
$ ./jetsonInfo.py 
NVIDIA NVIDIA Orin Nano Developer Kit
 L4T 35.4.1 [ JetPack UNKNOWN ]
   Ubuntu 20.04.6 LTS
   Kernel Version: 5.10.120-tegra

I’ve tried the loopback test instructions, but I don’t get anything from candump.

Suspiciously, those instructions call for shorting the pins together (which I tried), but I thought that was an internal configuration (loopback on), meaning it didn’t go out to the pins.

In any case, nothing changes on the TX pin output.

I’ve also tried connecting a VESC SIX motor controller with CAN. I can see its messages on the oscilloscope and on the RX pin on the dev kit board, but nothing in the software.

Screenshot 2023-10-05 at 19.46.20
Screenshot 2023-10-05 at 19.46.201164×596 43.3 KB

5

Yes, it should be internal loopback test and I would suggest you verifying this with the following command.

$ ip link can0 down
$ ip link set can0 type can bitrate 500000 loopback on
$ ip link set can0 up
$ candump can0 &
$ cansend can0 123#abcdabcd

If you still not receive any data, please share the result of the following commands.

$ sudo busybox devmem 0x0c303018
$ sudo busybox devmem 0x0c303010 
$ sudo ip -d -s link show can0
6

Yeah, that’s exactly what I did, but just to be sure, I do it again (note, I have to use sudo):

rmann@mouse:~/jetson/jetsonUtilities$ sudo ip link set can0 down
rmann@mouse:~/jetson/jetsonUtilities$ sudo ip link set can0 type can bitrate 500000 loopback on
rmann@mouse:~/jetson/jetsonUtilities$ sudo ip link set can0 up
rmann@mouse:~/jetson/jetsonUtilities$ candump can0 &
[1] 10219
rmann@mouse:~/jetson/jetsonUtilities$ cansend can0 123#abcdabcd
rmann@mouse:~/jetson/jetsonUtilities$ 

rmann@mouse:~/jetson/jetsonUtilities$ sudo devmem2 0x0c303018
/dev/mem opened.
Memory mapped at address 0xffff954d9000.
Value at address 0xC303018 (0xffff954d9018): 0xC458

rmann@mouse:~/jetson/jetsonUtilities$ sudo devmem2 0x0c303010
/dev/mem opened.
Memory mapped at address 0xffff83c46000.
Value at address 0xC303010 (0xffff83c46010): 0xC400

rmann@mouse:~/jetson/jetsonUtilities$ sudo ip -d -s link show can0
9: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 72 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can  promiscuity 0 minmtu 0 maxmtu 0 
    can <LOOPBACK,BERR-REPORTING,FD> state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 
	  bitrate 500000 sample-point 0.870 
	  tq 20 prop-seg 43 phase-seg1 43 phase-seg2 13 sjw 1
	  mttcan: tseg1 2..255 tseg2 0..127 sjw 1..127 brp 1..511 brp-inc 1
	  dbitrate 1000000 dsample-point 0.720 
	  dtq 40 dprop-seg 8 dphase-seg1 9 dphase-seg2 7 dsjw 1
	  mttcan: dtseg1 1..31 dtseg2 0..15 dsjw 1..15 dbrp 1..15 dbrp-inc 1
	  clock 50000000 
	  re-started bus-errors arbit-lost error-warn error-pass bus-off
	  0          252074     0          1          1          1         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX: bytes  packets  errors  dropped overrun mcast   
    2016616    252077   252074  0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    0          0        0       3       0       0
7

It seems there’re many error packets at your RX.

When you are doing internal loopback test, do you connect any external cable or devices?

8

Yes, the wave share can transceiver is connected. I had to solder it to the board directly because I couldn’t find an appropriate right-angle socket, and the placement of the pads is under the module (very poorly considered, that).
I’m not sure what the error at the RX means.

If it is an internal Loopback, does it matter what’s connected to the pins?

Oh, another note: there’s no thermal isolation for the ground pin on the CAN header, making it very hard to solder.

9

After a couple of reboots (trying to persist the configuration), I finally have it working. I don’t know what I’ve done differently, because I’ve tried each one of these steps several times.

Now I just have to figure out how to persist the configuration.

10

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.