Weird CAN BUS behaviour when booting

Hello.
In the past, we have encountered a weird error with Jetson TX2: when booting up, the Jetson would randomly send garbage data to the CAN BUS and other devices would enter in a weird error mode.
The workaround we manage to do was to delay the EMU device to only start after a certain DELAY. This was a quick workaround, but not the ideal one.

Now we have switched to Orin NX and encountered the same problem. But now, we can’t delay only the EMU, since we have more devices in the CAN BUS, and they’re all entering in the error state.
Another problem is that this is inconsistent, it happens sometimes, so it’s hard to reproduce the problem. E.g after a reboot, things can work properly.

TLDR: When Jetson boots up, sends garbage to CAN BUS (weird baudrate/clock?), other devices enter in a weird error mode.

Setup:

  • Orin NX, Custom carrier, Jetson Linux release: R35.5.0 JetPack release: 5.1.3
CONFIG_CAN_RAW=y
CONFIG_CAN_DEV=y
CONFIG_MTTCAN=y

Is this a known problem?

Probably related threads: Jetson many CAN bus errors - #19 by silaj30653

Hi robyawyx,

I would like to know more details about "Jetson would randomly send garbage data to the CAN BUS ".
From the linked post you shared, it seems there’re unexpected data even if Jetson is off?

Are you using the internal mttcan?
Have you tried to build mttcan driver as kernel module and check if there’s still garbage data on CAN bus during boot up?

Have you tried to build mttcan driver as kernel module and check if there’s still garbage data on CAN bus during boot up?

As in, setting

CONFIG_MTTCAN=m

?

Wouldnt this require to load modprobe mttcan every boot?

Okay, it seems you have built it as kernel module so that it should not be loaded automatically during boot up.
Do you still get “randomly garbage data” during boot up?

So, in my config i have

CONFIG_CAN_RAW=y
CONFIG_CAN_DEV=y
CONFIG_MTTCAN=y

What im asking is, you told me to change it to m, but wouldnt that require me to manually load the driver every time i boot?

Yes, I suggest you modifying it as m for test purpose to check if there’s still garbage data been sent.
You can also add it to boot script to load it automatically even if you build it as kernel module.