CAN Interface Validation on Nvidia Jetson Orin Nano Dev Board

Issue Overview

Users are experiencing difficulties validating the CAN (Controller Area Network) interface on the Nvidia Jetson Orin Nano Developer Kit. The main concerns revolve around:

1. Verifying CAN functionality beyond software loopback
2. Confusion about shorting TX and RX pins for testing
3. Uncertainty about alternative validation methods
4. Questions about configuring CAN pins as GPIO

The issue impacts users trying to set up and test CAN communication on their Jetson Orin Nano boards, particularly when attempting to validate the interface using a single device.

Possible Causes

1. Misunderstanding of CAN interface testing methods
2. Lack of proper CAN transceiver hardware
3. Incorrect configuration of CAN interface
4. Confusion between CAN and UART testing methods
5. Limited hardware resources (only one CAN interface available)
6. Potential software or driver issues

Troubleshooting Steps, Solutions & Fixes

1. Understand CAN Loopback Testing:

   • Software loopback doesn’t require external connections
   • Use the following commands for software loopback test:

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

   • Successful loopback will show the sent message being received

2. Hardware Setup for External CAN Testing:

   • Do NOT short CAN-TX and CAN-RX pins directly
   • Use a CAN transceiver to convert CAN-TX/CAN-RX to CAN-H/CAN-L
   • For full testing, use two Jetson Orin Nano devkits with CAN transceivers

3. Alternative CAN Interface Options:

   • Consider using an MCP2515 module to add another CAN interface via SPI
   • Steps for this approach:
     a. Port the MCP2515 driver to your system
     b. Verify SPI loopback test first
     c. Configure the MCP2515 for CAN communication

4. Configuring CAN Pins as GPIO:

   • Refer to the Jetson Linux Developer Guide: https://docs.nvidia.com/jetson/archives/r35.3.1/DeveloperGuide/index.html
   • Follow the pinmux configuration instructions to set CAN pins as GPIO
   • Note: This will disable CAN functionality on those pins

5. Verifying CAN Interface without Loopback:

   • Use two Jetson Orin Nano devkits for a complete CAN network test
   • Connect the CAN-H and CAN-L lines between the two boards via CAN transceivers
   • Configure both devices for CAN communication and test message transmission

6. Troubleshooting CAN Driver Issues:

   • Check kernel logs for CAN-related messages:

     dmesg | grep -i can
     

   • Verify that the CAN driver is loaded:

     lsmod | grep can
     

   • If issues persist, try reloading the CAN drivers:

     sudo modprobe -r can_raw mttcan
     sudo modprobe can_raw mttcan
     

7. CAN Configuration Best Practices:

   • Always use the correct bitrate for your CAN network (e.g., 500000 for 500 kbps)
   • Ensure proper termination resistors are in place for external CAN networks
   • Use high-quality, shielded cables for CAN connections to minimize interference

8. Additional Validation Methods:

   • Use a CAN analyzer tool to monitor CAN traffic externally
   • Implement a simple CAN application to send and receive messages between two devices
   • Test with different bitrates to ensure compatibility with various CAN configurations

Remember that CAN and UART are different protocols with distinct testing methods. Unlike UART, you cannot directly short CAN TX and RX for loopback testing. Always use proper CAN transceivers and follow CAN specifications for reliable communication.