I2C device(s) on I2C5 (0x031a0000)

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Xavier
1

Hi!

I am wondering about the various devices on I2C5 (0x031a0000).

Especially the address 0x50 - what is it and how do I find information about it/dts nodes etc?

The reason I am wondering is because on some of our devices (AGX Xavier Industrial on custom carrier board) we “see it” when running “i2cdetect -y -r 4” and on some devices we don’t.

Example output from “i2cdetect -y -r 4”:

i2cdetect -y -r 4
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 -- -- -- -- -- -- -- 28 -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 
40: 40 -- -- -- -- -- -- -- 48 -- -- -- UU -- -- -- 
50: -- -- -- -- -- -- -- -- 58 -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

During investigation - we found that 0x28, 0x48 and 0x58 seem to be linked to the RTC battery being used/plugged in or not.

Thanks.

3

Maybe you can dump the device tree to check the device under the i2c@31a0000

sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree
4

Thanks for the response.

However, there is no node “i2c@31a0000” in the dump - but, there is an “bpmp_i2c” that seems to match some of it (thanks to: Jetson/AGX Xavier Misc Interfaces - eLinux.org)

i2cdetect -y -r 4
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 -- -- -- -- -- -- -- 28 -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 
40: 40 -- -- -- -- -- -- -- 48 -- -- -- UU -- -- -- 
50: -- -- -- -- -- -- -- -- 58 -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

From the dumped device tree:

...
i2c4 = "/bpmp_i2c";
...
spmic@3c (rtc0 = "/bpmp_i2c/spmic@3c";)
temp-sensor@4c (tegra_tmp451 = "/bpmp_i2c/temp-sensor@4c";)
...

This explains the 0x3C and 0x4C.

Maybe I should rephrase the question/issue:
In what document/resource can I find what “devices” should be/are located on the I2C bus 0x031a0000? Since we are finding that different Xavier AGX Industrial units either expose 0x50 on the bus or not, and are worried they might be faulty/we would like to know what is happening.

In the same way as 0x28, 0x48 and 0x58 disappears when booting the device without an RTC battery connected and appears when be boot the device with the battery connected.

0x50 would not show up in any dts/device tree - since when it does show up, it is not used by any driver (i.e. no “UU” in i2cdetect) etc.

Thanks.

5

Maybe check the HW design guide.

Thanks

6

Hello again.

I did, before reaching out to you for assistance.

However, I could share my findings. But I still need some guidance.

image
image704×114 13 KB

(DG-09840-001_v2.6)

First off - the bus is exposed on L44/L45 (on JAXi). We are not using those pins for anything on our carrier board/not routed from the contact.

image
image1094×213 29.5 KB

(DG-09840-001_v2.6)

The “Mux JAXi Only” routes to “Voltage Monitors”. “On-Module Control” also seems to be on the bus.

image
image780×224 27.3 KB

(DG-09840-001_v2.6)

“Voltage Monitor” seems to be exposed on L47 - which is not used for anything on the carrier board.

There must be a list of the addresses exposed on the bus somewhere - but I cannot find it in the documents.

So, if you could help with supplying one (or the information in any other way), I would appreciate it.

Thanks.

8

Hi, 0x50 is address of a phase buck controller used on module. The address list of I2C5 is not public as it is on-module only.

9

Hi.
Thank you for the response.

Understood. But just to clear all things up and close this issue then hopefully:

0x50 seems to be present/not present on the bus rather at random, and not as I stated before about the “0x28, 0x48 and 0x58 seem to be linked to the RTC battery being used/plugged in or not”

I have failed to see anything coherent in the same way for 0x50.

Bottom line: Should 0x50 be or not be present on the bus during “normal function”/“AGX is healthy”, or can we disregard it completely?

Thank you.

11

Do you mean run below command sometimes 0x50 shows but sometimes don’t?

How about the failed rate?

i2cdetect -y -r 4
13

Please use command line “tegrastats” to read the voltage value of VDD_GPU which is from 0x50 device.

15

Thanks guys for getting back to me.

First @ShaneCCC :
Yes that is exactly the case. I would have a hard time estimating the fail rate, but I can explain a bit more at least.

Since we noticed this behaviour, we have tested approx 50 units. Out of those we have only seen 0x50 on two of those.
However, it does seem to differ from boot to boot as well - since 0x50 have “always dissapeared after the initial/first boot in the test rig”.

So what I am saying is that I cannot say with confidence that “we have only seen 0x50 on two out of 50 units”, since we might just have been “un-/lucky” that specific boot, or the timings have not been identical.

So that is why I am wondering if it is a cause for concern, or not.

And, for @Trumany :
Thanks!
I’ll paste two different tegrastats - ran at different uptimes.

RAM 416/31930MB (lfb 7786x4MB) SWAP 0/15965MB (cached 0MB) CPU [17%@2035,14%@2035,11%@2035,10%@2035,18%@2035,19%@2035,25%@2035,20%@2035] EMC_FREQ 0% GR3D_FREQ 0% AO@23C GPU@23C thermal@23.65C Tdiode@24.5C PMIC@50C AUX@24C CPU@24.5C slv@24.562C bme280_1@25.79C Tboard@23C

RAM 413/31930MB (lfb 7758x4MB) SWAP 0/15965MB (cached 0MB) CPU [1%@115,0%@115,0%@115,0%@115,0%@115,0%@192,0%@192,0%@192] EMC_FREQ 0% GR3D_FREQ 0% AO@31C GPU@33C thermal@32.1C Tdiode@33.5C PMIC@50C AUX@31.5C CPU@33C slv@32.742C bme280_1@32.73C Tboard@32C

From what I can read, there is no “VDD_GPU”. There does not seem to be any voltage/power-related reading at all.

I will try some more, and keep it in mind and run tegrastats if I manage to “see 0x50” on the bus, and try to get back to you by monday.

16

You can read the value of VDD_GPU following this example: Jetson Xavier NX Series and Jetson AGX Xavier Series — Jetson Linux<br/>Developer Guide 34.1 documentation

17

@Trumany

That worked as described in the doc . So what does this mean then, that 0x50 is NOT for VDD_GPU, since it is “on the 0x40 device”…?

Back to the main question - is this a cause for concern, 0x50 appearing seemingly random?

Thanks.

18

What’s the value you read? 0x40 is address to read value, not the 0x50 device itself.

0x50 device should be on bus always.

19

(Some of) The values present on 0x40 (AGX Xavier in “idle”):

cat /sys/bus/i2c/drivers/ina3221x/1-0040/iio:device0/rail_name_0
GPU
cat /sys/bus/i2c/drivers/ina3221x/1-0040/iio:device0/in_voltage0_input
11768
cat /sys/bus/i2c/drivers/ina3221x/1-0040/iio:device0/in_current0_input
0

So that matches the doc you linked. However, I cannot seem to get a reading of the current for that specific (GPU) “hwmon”. Current readings for CPU and SoC power rails work fine. But, this might be by design and in secondary in regards to the main question/issue.

Side note. These 0x40/0x41 I/V-sensors are not even on the same bus as for which we seem to have issues.

A paste of what our 0x031a0000 bus looks like (missing 0x50):

i2cdetect -y -r 4
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – – – – – – – – – – – – –
10: – – – – – – – – – – – – – – – –
20: 20 – – – – – – – 28 – – – – – – –
30: – – – – – – – – – – – – UU – – –
40: 40 – – – – – – – 48 – – – UU – – –
50: – – – – – – – – 58 – – – – – – –
60: – – – – – – – – UU – – – – – – –
70: – – – – – – – –

UUs being on 3C, 4C and 68.

So, what would cause the 0x50 device to not be on the bus?

21

@tobias.johansson1
Could you run the tegrastats then run the i2cdetect in another console to check if 0x50 present.

Thanks

22

Yes, of course.

Terminal 1 - tegrastats output:

...
RAM 423/27896MB (lfb 6754x4MB) SWAP 0/13948MB (cached 0MB) CPU [28%@192,14%@192,2%@192,4%@192,2%@192,1%@192,
0%@192,0%@192] EMC_FREQ 0% GR3D_FREQ 0% AO@41C GPU@43C thermal@42.7C Tdiode@42.5C PMIC@50C AUX@41.5C CPU@43C
slv@38.934C bme280_1@35.45C Tboard@40C
...

Terminal 2 - i2cdetect -y -r 4 output:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 
40: 40 -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

Note 1: No RTC battery was connected during this try, hence the 0x28, 0x48 and 0x58 devices are “missing from the bus”.

Note 2: I ran the tegrastats for a long while, and “spammed” i2cdetect at the same time in Terminal 2 - but got no differences, same i2cdetect result every time.

Thanks.

23

There is a level shift on the I2C bus to convert 1.8V to 5V for the VDD_GPU buck. If it has problem, the I2C device detection of the buck will fail. According to your tests and descripiton, the level shift might fail and so cause the random detection. But it won’t cause the VDD_GPU output fail since the buck uses default settings, and so AGX is healthy. You can run RMA for the modules if you have concerns on this.

24

Thank you for the response.

Is this a “known issue” from your side, and/or is this something we could mitigate with a rework of the carrier board/dts/etc?

What I am really asking for is what might the root cause issue be with this level shifter problem. Since we on the last 79 units have seen the level shifter (0x50) on two of the units. Now I am more curious than cautious - since you said that the AGX is to be considered as healthy even in this state.

Thanks!

26

It is not “known issue”. We don’t know the reason of that.

28

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.