CAN Communication Issues on Nvidia Jetson Orin Nano Dev Board

Issue Overview

Users are experiencing difficulties with CAN (Controller Area Network) communication on the Nvidia Jetson Orin Nano Development Board. The primary symptoms include:

• TX Pin Behavior: The TX pin remains high during transmission attempts, indicating no data is being sent.
• RX Pin Activity: While data is being received on the RX pin, the software does not reflect this activity.
• Commands Executed: Users have followed several commands to set up and test CAN functionality, including memory writes and module loading, but still encounter issues.

The problem occurs during the setup and testing of CAN communication, specifically when trying to send and receive messages using commands like cansend and candump. The users report that they can see incoming CAN data on an oscilloscope but not in their software output.

Relevant Specifications:

• JetPack Version: L4T 35.4.1
• Operating System: Ubuntu 20.04.6 LTS
• Kernel Version: 5.10.120-tegra

The issue appears to be inconsistent; while some users eventually resolve it after multiple attempts or reboots, others remain stuck without a clear solution.

Possible Causes

Several potential causes for the CAN communication issues have been identified:

• Hardware Incompatibilities: Custom board configurations or improper soldering of components may lead to connectivity problems.

• Software Bugs or Conflicts: Issues within the JetPack version or kernel may prevent proper CAN functionality.

• Configuration Errors: Incorrect settings during CAN interface setup (e.g., bitrate mismatches) could lead to failures in communication.

• Driver Issues: Missing or improperly loaded drivers for CAN modules (e.g., can, can_raw, mttcan) may hinder functionality.

• Environmental Factors: Poor grounding or thermal issues due to soldering conditions can affect signal integrity.

• User Errors or Misconfigurations: Incorrect command usage or misunderstanding of loopback tests could lead to perceived failures.

Troubleshooting Steps, Solutions & Fixes

To diagnose and potentially resolve the CAN communication issues, follow these comprehensive troubleshooting steps:

1. Verify Hardware Connections:

   • Ensure all connections are secure and correctly soldered, especially if using a custom setup.
   • Check for proper grounding and thermal isolation on the CAN header.

2. Run Internal Loopback Test:

   • Execute the following commands to set up an internal loopback test:

     sudo ip link set can0 down
     sudo ip link set can0 type can bitrate 500000 loopback on
     sudo ip link set can0 up
     

   • Use candump to monitor:

     candump can0 &
     

   • Send a test message:

     cansend can0 123#abcdabcd
     

3. Check Device Status:

   • After executing the above commands, check the status of the CAN interface:

     sudo ip -d -s link show can0
     

   • Review output for errors in RX/TX packets.

4. Memory Verification:

   • Verify memory addresses to ensure correct configuration:

     sudo devmem2 0x0c303018
     sudo devmem2 0x0c303010
     

5. Inspect Error Counts:

   • If there are many error packets at RX, consider testing without external devices connected to isolate the issue further.

6. Driver and Module Checks:

   • Ensure all necessary modules are loaded correctly:

     sudo modprobe can
     sudo modprobe can_raw
     sudo modprobe mttcan
     

7. Reboot and Persistence Configuration:

   • If successful after several attempts, document steps taken. Investigate how to persist configurations across reboots by modifying startup scripts or systemd service files.

8. Community Support & Documentation:

   • If issues persist, consider reaching out to community forums or referring to Nvidia’s official documentation for additional troubleshooting tips or updates regarding driver versions.

Recommended Approach

Many users reported success by ensuring proper internal loopback configuration and verifying hardware connections before running tests. It is advisable to follow these steps meticulously for troubleshooting.

Unresolved Aspects

While some users managed to get their setups working after multiple reboots, there remains uncertainty about what specific changes led to successful communication. Further investigation may be needed into persistent configuration methods and potential software updates that could address underlying bugs.