I2C address conflict between INA3221 and GMSL serializer default address

Robotics & Edge Computing Jetson Systems Jetson Thor
1

Hi NV team,

On our current hardware design, the GMSL deserializer is connected to i2c-2. On this bus, an INA3221 power monitor is already present at address 0x40, which is the same as the default I2C address of our GMSL serializer.

  • JetPack 7.2.1
  • Custom Carrier board
  • GMSL deserializer / serializer: MAX96724 / MAX9217

Under the Argus/tegracam architecture, we can work around this by sending a command to 0x40 to change the serializer to another (virtual) address. However, since both devices respond at 0x40, the INA3221 also receives writes that are meant for the serializer, so unintended values are written into its registers (e.g. configuration / critical and warning limits). We consider this an operational risk to the system, especially if the INA3221 alert pins are used for power/over-current protection. [Please confirm/modify whether alert pins are connected on your board.]

The hardware design is already finalized, so we would like to avoid a board respin if possible.

Questions

  1. Is there any way to change the INA3221 I2C address by software? Our understanding is that the address is determined only by the A0 pin strapping (GND/VS/SDA/SCL) ?
  2. Is there a recommended I2C bus on Jetson dedicated to GMSL / camera devices? Is i2c-9 (CAM_I2C) the intended bus for this purpose, and is i2c-2 (gen2_i2c) intended only for general system peripherals?
  3. If we do not change the main board design, is it feasible to add an I2C mux on the GMSL adapter board, on the i2c-9 side, to replace the i2c-2 connection? Are there any known limitations when using i2c-mux child buses with the Argus / tegracam / SIPL driver framework (device tree parent adapter, bus numbering, etc.)?
  4. Are there any other recommended approaches to avoid the conflict (for example, configuring the serializer’s default address via CFG pin strapping, or any NVIDIA-recommended reference design)?

Thank you for your help.

4

Do not keep writing serializer 0x40 on i2c-2. INA3221 will ACK those cycles and can take bad config/alert values.

1. INA3221 address in software?
No. Address is only A0 strap: GND=0x40, VS=0x41, SDA=0x42, SCL=0x43.

2. Dedicated camera I2C?
Yes. GMSL belongs on CAM_I2C, not the CVM power-monitor bus. NVIDIA modules put ina3221@40 on that power I2C; camera overlays put the deserializer on cam_i2c. i2c-2 vs i2c-9 is DT alias numbering — confirm with i2cdetect -l. If i2c-2 has INA3221@0x40, do not put MAX96724 there.

3. Mux on the adapter on i2c-9?
Yes, if the mux parent is CAM_I2C (no INA3221). Argus/tegracam/SIPL support PCA954x child buses; point i2c-bus at the child /dev/i2c-N.
A mux on i2c-2 does not help: INA3221 is still on the parent and still sees 0x40.

4. No main-board respin

  • Best: wire MAX96724 to CAM_I2C (i2c-9), not i2c-2.
  • Or strap serializer ADD/CFG off 0x40 (confirm MAX96717 vs MAX9217).
  • Or program MAX96724 translation so the host never puts 0x40 on the wire. “Write 0x40 then remap” on i2c-2 is unsafe.

Keep INA3221 on i2c-2; keep GMSL off that bus.

5

Hi ShaneCCC,

Thanks for the information.

Is CAM_I2C the only NVIDIA-recommended I²C bus for GMSL devices on Jetson Thor?

Could you also share the document, design guide, or reference schematic that defines the CAM_I2C pins and their intended usage? I’d like to reference the official documentation when evaluating our next hardware revision.

6

I don’t know if the design tell that or not.

Please check the download center for the design guide.

Thanks