I2C bus stops working when plugging in a CAN device

The xavier dev kit is set up with i2c and CAN. Both i2c and CAN work flawless when used individually, but when CAN runs, i2c just stops even it’s running fine before. It appears the SCL just stops (see screenshot with i2c signals).
Any ideas how to resolve this?

I’m working on this issue with Chris. Some additional information about what had been tried or had worked:

  • we use jetpack 4.3, l4t 32.3.1
  • this is happening on factory installed Xavier AGX dev kits (tried multiple - same behavior)
  • this seems to work without problems in earlier Xavier AGX dev kits with the same jetpack/l4t versions

We are approaching a deadline and are completely out of ideas, any help is highly appreciated.

Best regards,
Jonas

May I know which I2C bus you are using?

BUS 1 (GPIO header pins 27 + 28)

Can you share following outputs from the device :
cat /proc/device-tree/compatible
cat /sys/kernel/debug/bpmp/debug/clk/i2c2/parent
after loading can on network:
cat /sys/kernel/debug/bpmp/debug/clk/can1/parent

Issue is seen on 32.3.1?

Below are the outputs. And yes, we are on 32.3.1.
From the analyzer logs we also noticed that the SCL timing is not consistent at 10us (i2c speed is set to 100kHz). Sometimes it goes up to 15us or more.

$ cat /proc/device-tree/compatible
nvidia,galennvidia,jetson-xaviernvidia,p2822-0000+p2888-0001nvidia,tegra194

$ sudo cat /sys/kernel/debug/bpmp/debug/clk/i2c2/parent
pllp_out0

$ sudo cat /sys/kernel/debug/bpmp/debug/clk/can1/parent
pll_aon

We figured out the issue and the Xavier was actually innocent. We were facing an EMI issue that was causing I2C failures due to noise on the lines. The inconsistent SCL was due to the client doing clock stretching (BNO080).

Good to know it is solved.

Thanks,
Shubhi