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:
-
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. -
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)