Jetson Orin Nano - CAN RX not working, CAN TX only works with Loopback enabled

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin Nano
1

Device Specifications:
Jetson Orin Nano Devkit Super with Carrier Board
Jetson Linux 36.4.3 flashed using ./jetson-disk-image-creator.sh and using the board support package with an unmodified sample root file system (Jetson Linux | NVIDIA Developer).

External Transceiver: MCP2562

External CAN Device: CANable - search canable io

Wiring Diagram:
see Figure 1

Setup:
Command to startup network “sudo ip link set can0 up type can bitrate 1000000”

Relevant Files:
FILE: /etc/systemd/system/umdloop_can_bringup.service
[Unit]
Description=Configure CAN interface on Jetson Orin Nano
After=network.target
Wants=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/umdloop_configure_can.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

FILE: /usr/local/bin/umdloop_configure_can.sh
#!/bin/bash

Load necessary kernel modules

sudo modprobe can
sudo modprobe can_raw
sudo modprobe mttcan

Apply pinmux settings (only until reboot)

sudo busybox devmem 0x0c303018 w 0xc458 # can0_din
sudo busybox devmem 0x0c303010 w 0xc400 # can0_dout

Bring up the CAN interface with a bitrate of 1 Mbps and send a test frame on boot

sudo ip link set can0 up type can bitrate 1000000 loopback on
cansend can0 100#ABFFCDFFABFFCDFF
sudo ip link set can0 down
sudo ip link set can0 up type can bitrate 1000000 berr-reporting off loopback off restart-ms 1000

The Problems:

  1. The Jetson is only able to send CAN frames when loopback is on.
    When loopback mode is on, the jetson is able to send frames like normal. You send the message using “cansend can0 100#AABBCCDDAABBCCDD” and the candump on the Jetson records the message twice and it is sent on the network once. This is confirmed by candump, two external CAN device (CANable), and an oscilloscope with decoding features.
    When loopback is turned off the Jetson only sends error frames. The error frames measured are identical to the ones mentioned in this post - CAN Quiz Question #2: Answer | Dr. Ken Tindell - and are shown below. see Figure 2.

  2. The Jetson is not able to receive/parse the CAN RX signal. It has been confirmed by the external CAN device (CANable) and an oscilloscope that the other devices on the network are properly sending CAN frames and themselves able to read the CAN frames. Additionally the RX pin itself on the Jetson Nano was confirmed to have the proper signal as shown below.
    See figure 3.
    It should also be noted that when the Jetson is operating on the network with only one other external device (CANable) that when receiving a message from the device, it does not drive the ACK bit. This means that device will continually send that frame endlessly.

Things to consider:
Our Jetson was at one point able to both send and receive messages in every way that we would expect though this was only ever tested with several other nodes on the bus. Problem #1 was always an issue but it never interfered with the operation of the network as a whole. Problem #2 was discovered when the Jetson was one of only two nodes on the bus. For seemingly no apparent reason, the Jetson lost its ability to receive CAN messages. Our team wonders if there might have been some unintentional software change or if there might be some hardware issue on the Jetson itself. We are fairly certain that we ruled out any issue beyond the Jetson itself as the remaining devices work with no issue and we have used (and replaced) the transceivers working with the Jetson with no issues either.

This is a file generated by the command “sudo dmesg | grep -i can > can_dmesg.txt” and you may find its contents useful: See File 1

Finally, its also worth noting that we followed the directions outlined in - Controller Area Network (CAN) — NVIDIA Jetson Linux Developer Guide 1 documentation - for setting up the CAN configuration on the Jetson. Everything relevant to the Jetson Orin Nano we were able to get to work, with the exception of “cat /proc/device-tree/mttcan@c310000/status” There is no mttcan or anything can related in the /proc/device-tree directory.

Supporting Figures & Documents:
NVIDIA Support Resources.zip (336.9 KB)

3

Hi,
We have done loopback test on AGX Xavier develoer kit:

Jetson/L4T/peripheral/ - eLinux.org

Ideally it should be working the same on Orin Nano developer kit, but probably something is missing. Will test further and update.

4

Hello,
@jpauleni and I are working together on this issue. I have provided additional information in case it is relevant.
system_info.txt (895 Bytes)

6

Hi jpauleni and ciresadrian,

[  263.199519] mttcan c310000.mttcan can0: can_put_echo_skb: BUG! echo_skb 0 is occupied!
[  263.199662] mttcan c310000.mttcan can0: entered error warning state
[  263.199670] mttcan c310000.mttcan can0: entered error passive state
[  263.199993] mttcan c310000.mttcan can0: entered bus off state
[  264.223354] mttcan_controller_config: ctrlmode 0
[  264.223380] mttcan c310000.mttcan can0: Bitrate set
[  264.223394] mttcan c310000.mttcan can0: wait for bus off seq

From the log you shared, it seems entering into bus off state.
Normally, it is caused from the wrong connection in your CAN setup.
Do you use 5V or 3.3V for your MCP2562 CAN transceiver?
Have you also tried using another CAN transceiver and hit the similar issue?

I’ve also checked “Figure 1.png” you shared, there’re 3 devices(2Host+1Jetson) connected on CAN-bus.
Could you transmit and receive the expected data if you just send from the first host and receive from another host?

9

Hi KevinFFF,

Thanks for getting back to us.

We use 5V according to spec.

Yes, we’ve confirmed that the same issue occurs, even with different known-working CAN transceivers.

No, we can confirm via a picoscope that the ACK bit isn’t being set to recessive by the Jetson when it is receiving a message from another node, causing the message to be sent over and over again by the other node. With loopback enabled, the Jetson is able to send the message completely fine, and the other node sets the ACK bit dominant. With loopback disabled, the Jetson is not able to register that the message was properly sent on candump, however there were messages being sent from the Jetson. Presumably, the rx pin is just not working.

Further evidence of the Rx pin not functioning at a hardware level:
I have another Jetson running an older firmware version, but the microSD card inside is properly configured for CAN such that we can receive and send from this older-firmware Jetson. I downgraded the firmware version of the problematic Jetson to match, and inserted the microSD card that has confirmed working CAN. The same issue occurs where the Rx pin doesn’t work. I have to enable loopback to be able to successfully send CAN messages, but I cannot receive messages from any other nodes.

10

loopback on is used for internal loopback test to confirm that the configurations are correct for CAN usage.

Have you also tried using 2 Jetson w/o connecting with host PC? since we don’t suggest using VM in the setup.

18

We are using a native Ubuntu 22.04 machine as a secondary host, so there is no VM involved anywhere in the process. The other Jetson we had is no longer available for use. In any case, I can guarantee you that our physical setup is correct. The only situation in which the Jetson can send messages is with loopback set to on, and there is absolutely no configuration in which the Jetson can receive messages from the CAN bus.

19

I’ve asked you if you can transmit/receive data from first host to another and you said the answer is No so that we suspect there might be something error in your setup.

We would suggest you just getting an Orin Nano devkit to verify external loopback test as we’ve verified in https://elinux.org/Jetson/L4T/peripheral/#Loopback_test_for_2_CAN_interfaces. You can get another Orin Nano to test since there’s only one native CAN interface.

21

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