On Xavier NX, I can access our i2c device in our custom carrier board on i2c bus 8 with the following command: sudo i2cdetect -y 8
I am looking for a device on address 0x5f, as seen in the screenshots below, the device is present on Xavier NX, but on Orin NX I cannot find devicess address 0x5f on any of the i2c busses.
This is on L4T 35.2 on Orin NX
Is there another step I need to take to configure i2c? These screenshots are from Orin NX and Xavier NX that was flashed in an nVidia devkit then placed in our custom carrier board
We have a custom carrier board with a device at address 0x5f connected to I2C1_SDL and I2C1_SDA. Using Xavier NX and JetPack 4.6.1, I can see the device on i2c bus 8 using the command sudo i2cdetect -y 8 (see in the 2nd photo how we can see device 0x5f). We then remove the Xavier NX and replace it with an Orin NX running L4T 35.2 EA. With the Orin NX in the same board, I am unable to see the device 0x5f on any of the i2c busses (including bus 8). I am trying to determine how to gain access to this i2c device on Orin NX.
Just wanted to provide an update, I am now using GA L4t 35.2.1 and the problem persists.
We leave our pinmux at default settings for pins 189 and 191 (I2C1_SCL and I2C1_SDA). On Xavier NX this allowed us to access the device but on Orin NX we cannot.
We’ve used an oscilliscope to verify that the i2c bus connected to pins 189 and 191 is identified in the system as i2c7.
We also verified that the i2c bus on our custom PCB is working properly and we were able to capture the data and clock to verify that it was at 3.3V level and100kHz clock (this setting is 400kHz by default).
I am not sure what else I can do at this point. Are there any next steps I should take to debug this issue further?
In case of Xavier NX, Pin 189 and 191 are configured as i2c9 where as in Orin NX, those pins are configured as i2c8. Can you try this below command to detect the device?
Hi @gauthams thanks for your reply. As said on my Feb 1 reply, we confirmed i2c7 (i gues the proper name for this is i2c8?) was the bus connected to 189 and 191. When I run the i2cdetect command on bus 7 I see no devices present.
Hi – are you able to post a screenshot from your scope showing the portion where you scan for device 0x5F? Does the device ACK? You mentioned there’s a voltage translator, so please measure on the side of the Jetson if possible.
In the Orin case, the external device did not respond. That explains why Orin does not report a device at address 0x5F. The next step is to understand why the external device is not responding. Is there a reset pin for that external device? Have you verified the external device is released from reset? You may need to discuss further with the vendor of that device if there isn’t something obvious that is wrong. My suggestion for right now is to look very closely at that device to understand why it doesn’t respond. Ideally solving that issue will get it working with the Orin module.
We are in talks with our vendor about this issue as well. I will update here when we come to a solution.
We will also verify that device is released from reset. Since the above screenshots are from the same board with the same device on the i2c line, I am fairly certain it is not being held in reset and is being released.
On your side @bgriffis, nothing loooks wrong in the above waveforms? I noticed the rising clock edge on Orin NX seems a little soft when compared to the rising edge from Xavier NX.
Looks fine to me. Rising edge speed is dictated by the strength of the pull-up. Since your screenshots were taken on opposite sides of the level shifter it doesn’t surprise me that they are not identical. In any case, I2C does not expect or require sharp clock edges.
@bgriffis understood. Thanks for the information, hopefully we can solve this issue from the ethernet switch side.
Can you confirm for me whether or not the Orin NX has 1.5kohm pull-up resistance or 2.2kohm pull-up resistance to 3.3v? I have seen documentation that lists 1.5kohm pull-up on pins 189 and 191 and I have also seen documentation that lists the pull-up resistance as 2.2kohms.
Also, what is the role of the ext pull up value field in the pinmux for orin nx? The document states that ext pull-up value is for “external pull-up on the platform”. By default, this is set to 2.2k but I checked the schematic for the xavier nx carrier board and it looks like there are no additional pull-ups to 3.3v on those lines. Is that field refering to the resistance that is on the SOM? If so, why is it a field we can change, and why do they refer to this as “external pull-up on the platform”?
The 2.2k pullups you mention are part of the Orin NX module. The column you mentioned is strictly informational, e.g. changing that value has no impact on the generated software, etc… It is there to let you know that a 2.2k pullup is already present. The terms “external” and “internal” are relative to the SoC. For example, under the “Req. initial state” column there are options such as “Int PU”. That is referring to a weak pullup that is integrated directly into the SoC and is software configurable. The “external pull up” column is referring to resistors that are on the board. I understand your point about some ambiguity as to whether it is on the module or the carrier board.
I will pass a suggestion to the maintainer of this spreadsheet about potentially having separate columns for the module and the carrier board. To your point, the module columns should be locked as that configuration cannot be altered, while the carrier board column should be changeable (i.e. to correspond with your own design).
PS. I just noticed an important point. The column “Customer Usage Description or Net Names” specifies the location of the pullup. For example, in your screenshot if you look at the far right you see that it says “module”. That is how to know the location of the pullup.
@bgriffis understood, thanks for the response and the information, that clears things up.
Can you confirm that the pull-up resistance on the Orin NX SOM is in fact 2.2k? I have seen conflicting information listing this pull-up as 1.5k (See photo).
