candump not showing anything

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hello,
we are working with the Jetson TX2 development kit and use it to build an autonomous car. We are using Ubuntu 18.04 with ROS melodic and CANopenSocket. We already managed to get the motors running and see all the data in the candump, but since we disconnected the Jetson and did some Software updates, we are now unable to see data in the candump.
We do the standard start up routine for CAN, that includes:

sudo modprobe can
sudo modprobe can_raw
sudo modprobe mttcan
ip link set can0 type can bitrate 1000000
ip link set up can0
candump can0

Then we use the canopend-command:

app/canopend can0 -i 4 -s od4_storage -a od4_storage_auto

Now we should see the heartbeat of this node in our candump, like we did before.

If I use the start up routine with vcan0 and then use the canopend with vcan0, I see the heartbeat in the candump and can also send commands with cansend.

No motors or other CAN bus devices are connected to the jetson.
The problem occured after we connected an USB Hub to J1/J2 (power from J1 and data to J2), but I don’t believe that would interfere with the can interface.

Ifconfig also shows that can0 is set up, so I don’t see a problem here either.

Thank you in advance.
Simon

2

Hi Simon,
Can you please tell me if you have updated software related to CAN, if yes, what are those updates?
Connecting USB hub should not affect CAN performance.

Thanks,
Shubhi

3

Hey Shubhi,
my colleague did the “sudo apt-get update” command. So far none of the updated modules seemed to interfere with can.
We now tried the routine with another Jetson TX2 (same model) and get the same results: vcan is working, can is not. As with the other Jetson TX2, we downloaded and made CANopenSocket (not into the catkin_ws) and can_utils.
We used the exact same start-up script as for can, but used vcan instead. Also the canopend command is the same, just with the difference that we changed can to vcan.

We can read the heartbeat (with canopencomm) of the own created node with both can and vcan. But the candump remains empty. Also, if we use “candump can0 -l” to test if the terminal is buggy, the created file remains empty too.

EDIT: Here are some outputs

$ ip -d link show can0

8: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 25
    link/can  promiscuity 0 
    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 
      bitrate 1000000 sample-point 0.750 
      tq 25 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1
      mttcan: tseg1 2..255 tseg2 0..127 sjw 1..127 brp 1..511 brp-inc 1
      mttcan: dtseg1 1..31 dtseg2 0..15 dsjw 1..15 dbrp 1..15 dbrp-inc 1
      clock 40000000numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

$ ifconfig

...

can0: flags=193<UP,RUNNING,NOARP>  mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 25  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 131

...

As I said, it worked with the same start-up routine always a few weeks ago.

4

Hi,
Can you explain your setup? How many nodes and from where are they connected to CAN bus. It will help me debug further and understand your problem.
Can you also again try these things once :
sudo modprobe can
sudo modprobe can_raw
sudo modprobe mttcan
ip link set can0 type can bitrate 1000000
ip link set up can0
candump can0 &
cansend can0 123#abcdabcd

After sending data, what is the status of CAN bus.
ip -d -s link show can0
And if there are other nodes connected to bus then try sending from other node like can1 and receive at can0
cansend can1 123#abcdabcd

Let me know the results.

Thanks,
Shubhi

5

Thank you for your time.
Our final setup is to connect the jetson to our CAN board (https://www.amazon.de/SN65HVD230-Board-Connecting-Communication-Development/dp/B00KM6XMXO) and then connect it to our 6 CANopen-nanotec Motors.
For the first testing, we did not connect any nodes (not even the CAN board) to the jetson. Usually it shouldn’t be a problem as the Jetson itself doesn’t appear in the Candump.

Your commands do not work, because we have to use “sudo ip link” in order to set up the network. Without sudo ip link we get:

RTNETLINK answers: Operation not permitted
RTNETLINK answers: Operation not permitted
read: Network is down
write: Network is down

and

ip -d -s link show can0

8: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0 
    can state STOPPED (berr-counter tx 0 rx 0) restart-ms 0 
      mttcan: tseg1 2..255 tseg2 0..127 sjw 1..127 brp 1..511 brp-inc 1
      mttcan: dtseg1 1..31 dtseg2 0..15 dsjw 1..15 dbrp 1..15 dbrp-inc 1
      clock 40000000
      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

The testing with sudo ip link:

ip -d -s link show can0

8: 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 (berr-counter tx 248 rx 0) restart-ms 0 
      bitrate 1000000 sample-point 0.750 
      tq 25 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1
      mttcan: tseg1 2..255 tseg2 0..127 sjw 1..127 brp 1..511 brp-inc 1
      mttcan: dtseg1 1..31 dtseg2 0..15 dsjw 1..15 dbrp 1..15 dbrp-inc 1
      clock 40000000
      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   
    24         3        0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    0          0        0       0       0       0

We also tried to test these with or without connecting the CAN board and the motors. Neither did affect the results. We also tried sending messages over can1 and also tried to set up the network with can1. Neither did work.

6

Hi,

Yes please use ‘sudo’ if you are not root logged in.
in CAN statistics, CAN STATE is either stopped or BUS-OFF. Are these stats when you have not connected any HW on Jetson?
Can you please try loopback test?
Short TX and RX pin of CAN on Jetson 40 pin. and run all above commands.

sudo modprobe can
sudo modprobe can_raw
sudo modprobe mttcan
sudo ip link set can0 type can bitrate 1000000 loopback-on
sudo ip link set up can0
candump can0 &
cansend can0 123#abcdabcd
ifconfig can0

Please give dmesg logs and output of each command.
Further, which transceiver are you using for Jetson Mttcan controller?

Thanks,
Shubhi

7

Hey,
due to the holidays I am not near the hardware. I will come back to the hardware at the beginning of 2020, then I can test the commands again and deliver the logs.

As far as I can remember, the stats were created without any CAN-devices connected to the Jetson (not even the transceiver). The transceiver we are using is the Waveshare SN65HVD230 with the following connection to the Jetson:

3,3V → J26: Pin2 VDD_3V3_SYS
GND → J26: Pin10 GND
CAN RX → J26: Pin5 CAN0_RX
CAN TX → J26: Pin7 CAN0_TX

The devices at the end of the bus will be terminated with a 120 Ohm resistor.

Just to clarify: Could you explain that part with the shorting of RX and TX on Jetson 40pin. What does the 40pin mean here?

EDIT: Changed the wiring-order from CAN RX and CAN TX (Before RX was connected to Pin7, which was not real case)

8

Hi,
As this is Tx2, it is 30 pin header(J26) not 40 pin(J21) (sorry for confusion)
Without transceiver you won’t be able to communicate on CAN Bus.
But you can still test controller using loopback. Short CAN0_TX and CAN0_RX and follow commands given in previous comment.
If you see messages in candump this way, then please check your transceiver if it is connected properly.
Let me know the results.

Thanks,
Shubhi

9

Hey,

here are the results:
I shorted pin5 and pin7 from J26 (30 pin header) and ran the above commands.

rover@rover:~$ sudo modprobe can
[sudo] password for rover: 
rover@rover:~$ sudo modprobe can_raw
rover@rover:~$ sudo modprobe mttcan
rover@rover:~$ sudo ip link set can0 type can bitrate 1000000 loopback on
rover@rover:~$ sudo ip link set up can0
rover@rover:~$ candump can0 &
[1] 7727
rover@rover:~$ cansend can0 123#abcdabcd
  can0  123   [4]  AB CD AB CD
  can0  123   [4]  AB CD AB CD
rover@rover:~$ ifconfig
can0: flags=193<UP,RUNNING,NOARP>  mtu 16
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 10  (UNSPEC)
        RX packets 1  bytes 4 (4.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 4 (4.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 131  

eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:04:4b:c5:ee:49  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 41  

l4tbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.55.1  netmask 255.255.255.0  broadcast 192.168.55.255
        inet6 fe80::1  prefixlen 128  scopeid 0x20<link>
        inet6 fe80::28f5:efff:fed7:170b  prefixlen 64  scopeid 0x20<link>
        ether 52:ab:49:5f:3e:f1  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 12  bytes 1804 (1.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 192  bytes 14196 (14.1 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 192  bytes 14196 (14.1 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

rndis0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 52:ab:49:5f:3e:f1  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

usb0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 52:ab:49:5f:3e:f3  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.233  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::7391:a08c:3289:7849  prefixlen 64  scopeid 0x20<link>
        ether 00:04:4b:c5:ee:47  txqueuelen 1000  (Ethernet)
        RX packets 31  bytes 2947 (2.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 52  bytes 6208 (6.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

dmesg

[   64.857680] can: controller area network core (rev 20120528 abi 9)
[   64.859238] NET: Registered protocol family 29
[   66.785815] can: raw protocol (rev 20120528)
[   70.224911] CAN device driver interface
[   70.232219] 	 Message RAM Configuration
               	| base addr   |0x0c312000|
               	| sidfc_flssa |0x00000000|
               	| xidfc_flesa |0x00000040|
               	| rxf0c_f0sa  |0x000000c0|
               	| rxf1c_f1sa  |0x00000300|
               	| rxbc_rbsa   |0x00000540|
               	| txefc_efsa  |0x00000780|
               	| txbc_tbsa   |0x00000800|
               	| tmc_tmsa    |0x00000c80|
[   70.232391] Release 3.2.0 from 19.12.2014
[   70.232835] net can0: mttcan device registered (regs=ffffff8011c5f000, irq=387)
[   70.234703] 	 Message RAM Configuration
               	| base addr   |0x0c322000|
               	| sidfc_flssa |0x00000000|
               	| xidfc_flesa |0x00000040|
               	| rxf0c_f0sa  |0x000000c0|
               	| rxf1c_f1sa  |0x00000300|
               	| rxbc_rbsa   |0x00000540|
               	| txefc_efsa  |0x00000780|
               	| txbc_tbsa   |0x00000800|
               	| tmc_tmsa    |0x00000c80|
[   70.234875] Release 3.2.0 from 19.12.2014
[   70.235325] net can1: mttcan device registered (regs=ffffff8011c87000, irq=388)
[   77.981889] mttcan c310000.mttcan can0: Bitrate set
[   81.153418] mttcan_controller_config: ctrlmode 1
[   81.153454] mttcan c310000.mttcan can0: Bitrate set

With this, I was able to use canopend to see the heartbeat of the Jetson CAN-node. Each heartbeat was shown in the log twice a time.
I also tried it again (now with loopback on) with our transceiver and connected a single motor to the Jetson, representing the first scenario when everything worked. In this case, I was also not able to read the external motor heartbeat. So nothing changed.

I then un-shorted the RX and TX pin and get the exact same result.

Afterwards I deleted “loopback on” from the commands and came back to the old results, where no candump is shown.

over@rover:~$ sudo modprobe can
[sudo] password for rover: 
rover@rover:~$ sudo modprobe can_raw
rover@rover:~$ sudo modprobe mttcan
rover@rover:~$ sudo ip link set can0 type can bitrate 1000000
rover@rover:~$ sudo ip link set up can0
rover@rover:~$ candump can0 &
[1] 7824
rover@rover:~$ cansend can0 123#abcdabcd
rover@rover:~$ ip -d -s link show can0
8: 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-PASSIVE (berr-counter tx 128 rx 0) restart-ms 0 
	  bitrate 1000000 sample-point 0.750 
	  tq 25 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1
	  mttcan: tseg1 2..255 tseg2 0..127 sjw 1..127 brp 1..511 brp-inc 1
	  mttcan: dtseg1 1..31 dtseg2 0..15 dsjw 1..15 dbrp 1..15 dbrp-inc 1
	  clock 40000000
	  re-started bus-errors arbit-lost error-warn error-pass bus-off
	  0          0          0          1          1          0         numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    RX: bytes  packets  errors  dropped overrun mcast   
    16         2        0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    0          0        0       0       0       0

dmesg

[   49.981947] ifidx:0 DHCP - REQUEST [RX]
[   50.674472] can: controller area network core (rev 20120528 abi 9)
[   50.675693] NET: Registered protocol family 29
[   52.805492] can: raw protocol (rev 20120528)
[   55.877340] CAN device driver interface
[   55.883429] 	 Message RAM Configuration
               	| base addr   |0x0c312000|
               	| sidfc_flssa |0x00000000|
               	| xidfc_flesa |0x00000040|
               	| rxf0c_f0sa  |0x000000c0|
               	| rxf1c_f1sa  |0x00000300|
               	| rxbc_rbsa   |0x00000540|
               	| txefc_efsa  |0x00000780|
               	| txbc_tbsa   |0x00000800|
               	| tmc_tmsa    |0x00000c80|
[   55.883601] Release 3.2.0 from 19.12.2014
[   55.883984] net can0: mttcan device registered (regs=ffffff8011ce0000, irq=387)
[   55.886634] 	 Message RAM Configuration
               	| base addr   |0x0c322000|
               	| sidfc_flssa |0x00000000|
               	| xidfc_flesa |0x00000040|
               	| rxf0c_f0sa  |0x000000c0|
               	| rxf1c_f1sa  |0x00000300|
               	| rxbc_rbsa   |0x00000540|
               	| txefc_efsa  |0x00000780|
               	| txbc_tbsa   |0x00000800|
               	| tmc_tmsa    |0x00000c80|
[   55.886807] Release 3.2.0 from 19.12.2014
[   55.887325] net can1: mttcan device registered (regs=ffffff80121cc000, irq=388)
[   60.583333] mttcan c310000.mttcan can0: Bitrate set
[   69.367951] mttcan_controller_config: ctrlmode 0
[   69.367973] mttcan c310000.mttcan can0: Bitrate set
[   75.921563] mttcan c310000.mttcan can0: entered error warning state
[   75.927877] mttcan c310000.mttcan can0: entered error passive state
10

Hi,

Sorry, I did not understand this line and I am not clear with your setup.

I also tried it again (now with loopback on) with our transceiver and connected a single motor to the Jetson, representing the first scenario when everything worked. In this case, I was also not able to read the external motor heartbeat. So nothing changed.

You can try following things:

Loopback is working means there is no issue on CAN Software controller side.
When you are using transceiver on Tegra CAN , you should not short CAN_RX and CAN_TX on Tegra. Just connect RX of transceiver to CAN_RX and TX of transceiver to CAN_TX. Try with this setup. Do not connect anything else and short Transceiver TX and RX pin and check loopback again.

If you are using both CAN of Tegra and please try CAN1 loopback also just the way you did for CAN0.

When you are connecting Motor or any other CAN node, do not short any pin on Tegra and try basic communication.
Let me know the results.

Thanks,
Shubhi

11

Hey,
our setup is as follows:
We have an NVIDIA Jetson TX2, that should control 6 Motors using ROS and CANopen. For the ROS part, we use CANopenSocket. Between the Jetson and the motors, we use a “Waveshare SN65HVD230” transceiver that uses the same GND as the Jetson and the motors and is terminated with a 120 Ohm resistor. The end of the line is also terminated.

This setup does not work anymore: we can not see any heartbeats or any messages sent by cansend in the candump.

When I now use the start up routine with “loopback on” (as mentioned by you in #6), I can see all the messages (heartbeat, cansend, PDO readings) from the Jetson-Node, but I can not communicate with the motors.

Now to your ideas:
I now connected the transceiver as mentioned by me in #7 and shorted the output RX and TX of the transceiver. The results were as expected: With loopback on, I can still see all messages of the Jetson-Node and can not communicate with the motor (because they are not connected).

Un-shorting the RX and TX of the transceiver and then connecting the motor to the RX and TX of the transceiver changed nothing. I can still see the messages of the Jetson-Node with loopback on, but can not communicate with the motor.

CAN1 behaves the same way as CAN0.
Overall: no messages can be seen with loopback off. When using loopback on, I can see messages of the Jetson itself, but still can not communicate with the motors. Shorting of the pins did not change anything at the previous behaviour.

12

Hi,

Ok, Problem is with attaching motor to the Jetson. Can you please check what bitrate does motor support? and from datasheet you may get more info. Is it compatible to communicate in Bus. Also, some more details of motors with respect to CAN.

1 Like
13

Hey,
we did a lot of testing with the current system and got us a PCAN module to analyse the traffic on the CAN Bus.
Using this module, we were able to show CAN messages of the motors in the candump as it should be. Which lead us through a long night of error searching with the result, that all of our selfmade cables had an error with the pinouts. Therefor CAN signals were not acknowledged and thus not shown in the candump. Using the producer cable it finally shows every message in the candump and allows us to communicate flawlessly with the CAN motors.

I really want to thank you for your kind help and want to apologize for making such a mess because of such an easy error. We were not expecting an error at the wiring at all.

14

Hi,

Good to know that the issue is resolved.

Thanks,
Shubhi