Jetson AGX Orin Can with Simulink Problem

Hi all,

ich have a problem with Jetson AGX Orin r36.4.4 with Matlab Simulink.

I have two cans (500k Baud) connected with a PC with Simulink and Vehicle Network Toolbox. Unfortunately this happens when I start the can:

The yellow is a sine from simulink on CAN0. The jetson reads this message (all cycletimes are 20ms) and give it back to CAN1 - violett line. The green line ist a sine from the jetson on CAN1. The measurement is from simulink, but it was doublechecked with a can dongle.

So, CAN0 and CAN1 are working, the jetson ist working, but the jetson is not able to read the yellow and give it back to violett. The violett’s sine first runs slower than it should and after 11 seconds the signal gets bad with a delay of 5 seconds. I tried several things p.e. raising the buffersize but nothing worked.

Does anyone have an idea what the problem could be?

Thanks in advance,

Christoph

Answer 1

[Satyam]

Hi Christoph,

From your description and the attached plot, it looks like the Jetson AGX Orin is able to send and receive CAN frames, but the loopback timing between CAN0 and CAN1 drifts significantly over time, leading to delayed and distorted responses on the return signal. You can try a few troubleshooting steps:

• Task Prioritization & Real-Time Execution:Ensure that your Simulink model running on the Jetson is configured for real-time execution. Delays can occur if the tasks handling CAN communication are not prioritized appropriately or if the model is not running in real-time mode.
• CAN Driver & Hardware Buffer:Verify that the CAN driver on the Jetson is up to date and compatible with your setup. Also, monitor for hardware buffer overflows or errors using system logs (dmesg or candump).
• Message Handling Rate:Check if the message handling rate in your Simulink model matches the actual CAN message rate (20 ms cycle time). Any mismatch can lead to accumulation of delays.
• Simulink Model Design:If possible, try running a simplified loopback test (receive on CAN0, immediately transmit on CAN1 without additional processing) to see if the delay persists. This can help determine if the delay is due to model logic or system performance.