Cannot access i2c device Orin NX

The version on the nVidia download center has the correct value (2.2k). I was sent this info by a colleague and I believe they had an earlier revision, just wanted to make sure the version hosted by nVidia was accurate.

@lphillips

We encountered the same situation at our end as well when we used i2cdetect -y 7. But we are able to detect the device when we add -r option along with the command. It makes the i2c controller probes all the salve address. So even if the device is been used by another driver, it will mark as “UU”.

Can you try i2cdetect -y -r 7?

Thanks for the reply @gauthams

I have not been able to communicate with our device using i2cdetect -y -r 7. As seen in the scope captures in my earlier reply, for whatever reason it seems the device on the i2c bus doesn’t issue an Ack to the orin, however it does issue the ack for xavier nx. I am not sure what change is causing this behavior, as the clock-rate, pull-up resistance, line capacitance and the actual device on the i2c bus are all the same. The only variable changing here is the Orin vs Xavier, there must be some lurking variable causing the device to not respond.

image

Hi Iphillips, have you tried other i2c channels, e.g. 8, or 1, etc

@rapidproto I will try this.

Our custom board has these traces built-in. I will connect the lines of a different i2c channel from a Xavier NX devkit 40-pin header with Orin NX inserted into the devkit (perhaps using I2C0_SDA and I2C0_SCL) to the i2c device on our board and update with results here.

I think i2cdetect -l command will show a number of I2C channels, not necessarily physical channels but enumerated (not sure on terminology here). We hardwired I2C1 port but it shows devices connected to channel 8 when we use i2cdetect to find connected devices. So maybe you have the same issue

@rapidproto I appreciate the thought, however, we have verified that i2c7 is the bus that is connected to the pins in question on Orin NX.

Another quick update to this post, if we remove Orin NX from our custom carrier board and use a Xavier NX devkit, we can connect the i2c lines from the 40-pin header (using pins 3 and 5 on the 40-pin header) directly to our device on our carrier board and we are in-fact able to see the address 0x5f on i2c7.

image

Still trying to root-cause why Orin NX i2c isn’t behaving the same as Xavier NX in our carrier board.

@bgriffis @gauthams

Is there any difference in drive strength or any other i2c characteristic that differs from Xavier NX vs Orin NX?

We have removed the level shifter and now pins 189 and 191 go directly to our component on the board with no other components interferring (just like on Xavier NX devkit). I still am seeing the same behavior where 0x5f is not detected on unless the Orin NX is inside a devkit and connected externally to the ethernet switch i2c lines.

Xavier NX is still able to detect and write to the component’s registers when inserted into our carrier board.

Is there a GPIO pin that controls the reset pin of this Ethernet switch? Have you confirmed that the switch has been released from reset in the case of Orin NX?

I2C is not a precise interface at all. Rise times are slow by digital logic standards since it relies on the pullup. The clock period often varies due to clock stretching. I do not expect the electrical characteristics could cause this problem.

Pins 189 and 191(i2c sda and scl) are the only pins from Orin NX connected to the ethernet switch.

Reset pin of the i2c device is tied to 3.3V and is an active low signal. I probed this signal with Xavier NX and Orin NX in the carrier board and the signal is never brought low and it is operating. Therefore I am convinced it isn’t being held in reset.

I didn’t realize the reset pin was tied high. Agreed that isn’t the issue. I was trying to think of some reasons why the switch might not respond. That’s the main one that comes to mind. Signal levels are ok? They looked “approximately the same” from your screenshots, but it is hard to tell exactly. What are the Vih and Vil levels for the switch? Are we comfortably meeting that spec?

Will you please measure the observed rise and fall times?

@bgriffis

Signal levels are ok. For our device on the board (powered by 3.3v) Vih = 2.1V and Vil = 0.9V

The following are screenshots with rough measurements of risetime of clock and data of Xavier NX in our PCB:

The following are screenshots with rough measurements of risetime of clock and data of Orin NX in our PCB:

Looks like we’re seeing about 75ns rise time from vil to vih on Orin NX vs. aprox 68ns on Xavier NX

These are all operating at 100khz

For anyone else reading this post this slide provides good context to what these measurements mean:

The rise times are well within the 1000ns maximum of the I2C standard mode spec. Please share corresponding fall times when you get a chance.

@bgriffis

Here are fall times of Orin NX in our PCB, I can provide Xavier NX captures at a later time as well

Fall time of clock:

Fall time of data:

Both around 40-45ns

I don’t see any issues. The waveforms are clean. Timing is good, e.g. fall time needs to be <300ns, which it is. I’d really like to help you solve this, but we need to understand why the other device isn’t responding. Have you gotten any other data points from the switch vendor? Are you able to share the part number so I can have a look at the corresponding data sheet?

Hi @bgriffis I am working with @lphillips on this issue. The switch is KSZ9567S.

Hi @csileo – thanks for the response! I had a look at the data sheet. I see there are a pair of pins that control the Management Interface Mode (i.e. choice of MDIO, I2C, SPI). These config pins are LED4_1 and LED3_1. Can you have a look at those to see if something is different between the two cases? One possibility that comes to mind is that if somehow an interface other than I2C is chosen, does that make the I2C unresponsive?

If that does not yield any results, can you please create a list of all pins on the switch that are connected to the Jetson Module?

LED4_1 has a 1k pull down resistor tied to it and is also connected to an LED pin on an RJ45 connector.
LED3_1 has a 1k pull up resistor tied to 3.3V.
This would give us the 01 needed for I2C configuration.

LED3_1 is also tied to the LED pin of the Xavier/Orin module slot (pin 188). Is there possibly a difference in these pins between the Orin module and the Xavier module which might cause LED3_1 to be read as a 0 instead of a 1? This would put the switch in a different communication mode.

Pin 188 is driven by the Ethernet PHY that is integrated in the module. On Xavier NX, that signal is also a config strap for the PHY. Correspondingly, there is a pulldown and it is buffered (i.e. the pulldown is between the phy and the buffer, not between the buffer and the connector). On Orin NX this signal is not a config strap and it is not buffered, i.e. the PHY signal goes directly to Orin NX and to the module header.

This discussion is further complicated by the fact that your switch is using this signal for config purposes, i.e. its value is latched by the switch during reset. Which raises some questions in my mind:

  1. Given that you have reset pin tied high, when exactly is the moment when the strap pins are sampled?

  2. I don’t know the precise behavior of these signals as driven by the PHY during power-up. I suspect there could be some differences.

Will you please collect some screenshots of this pin during power-up and near the time that reset is released for the board?

I can work on collecting these screen shots, but I ran a quick test in which I cut the trace on the PCB which removes pin 188 from the net.

With this modification, the Orin can see the switch and can communicate over I2C. It looks like the pull up/pull down combination is causing our switch to latch the incorrect value.