We have a custom board with jetson nano flashed with JP4.6.4 , ALS sensor is connected to i2c-bus 0
sudo i2cdetect -y -r 0
we are getting the following result from terminal
~$ sudo i2cdetect -y -r 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: --
As you can see, it is not scanning completely. When we try with i2c-bus 6 it works fine with i2cdetect and outputs
sudo i2cdetect -y -r 6
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
if replace the SOM , the same bus works fine, and we are able to check ALS HW is detected
Can you comment on these below questions
What is the reason for this issue?
Whether this is occurred due to any damage in the i2c line of that particular SOM ?
Is there any option to fix this issue?
Could you share the result of cat /etc/nv_boot_control.conf on the working SOM and NG SOM?
cat /etc/nv_boot_control.conf
TNSPEC 3448-401-0002-G.0-1-0-jetson-nano-devkit-emmc-<>-mmcblk0p1
COMPATIBLE_SPEC 3448-300-0002--1--jetson-nano-devkit-emmc-<>-
TEGRA_CHIPID 0x21
TEGRA_OTA_BOOT_DEVICE /dev/mmcblk0boot0
TEGRA_OTA_GPT_DEVICE /dev/mmcblk0boot1
cat /etc/nv_boot_control.conf
TNSPEC 3448-401-0002-G.0-1-0-jetson-nano-devkit-emmc-<>-mmcblk0p1
COMPATIBLE_SPEC 3448-300-0002--1--jetson-nano-devkit-emmc-<>-
TEGRA_CHIPID 0x21
TEGRA_OTA_BOOT_DEVICE /dev/mmcblk0boot0
TEGRA_OTA_GPT_DEVICE /dev/mmcblk0boot1
This contains any other info that we are looking for, it seems results are same only for both the SOM’s
Could you share the full boot up log and dmesg of these 2 modules?
Could you share the full boot up log and dmesg of these 2 modules?
Can we share these logs with custom image?
Yes, just make sure both of them are using same image.
When it is working, what will be shown up there?
I see both NG and working case have “[ 1.372553] tegra-i2c 7000c000.i2c: no acknowledge from address 0x44”.
Since ALS HW is not connected to i2c-0
When ALS HW is connected in dmesg log of working SOM it didn’t show tegra-i2c 7000c000.i2c: no acknowledge from address 0x44, and it detects the ALS HW
In NG SOM in dmesg logs it shows these errors when ALS HW connected or not-connected
[ 11.398048] tegra-i2c 7000c000.i2c: --- register dump for debugging ----
[ 11.404746] tegra-i2c 7000c000.i2c: I2C_CNFG - 0x2c00
[ 11.409794] tegra-i2c 7000c000.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[ 11.416489] tegra-i2c 7000c000.i2c: I2C_FIFO_CONTROL - 0xe0
[ 11.422057] tegra-i2c 7000c000.i2c: I2C_FIFO_STATUS - 0x800040
[ 11.427885] tegra-i2c 7000c000.i2c: I2C_INT_MASK - 0x7d
[ 11.433106] tegra-i2c 7000c000.i2c: I2C_INT_STATUS - 0x0
[ 11.438414] tegra-i2c 7000c000.i2c: i2c transfer timed out addr: 0x44
What exactly is the reason for this i2c -error?
ok, could you share the working case and NG case both with device connected?
I am not sure why you just shared us the working case with no device…
Is it possible to measure the i2c signal on the NG and working case for comparison too?
Want to check if even the clock is not having signal out in NG case.
Since there is no option to take UART logs when ALS HW connected in complete custom board
let me check it, but I cannot guarantee as it need extra efforts
Is it possible to do via software?
krishnaprasad.k:
Are they flashed with the same BSP package(L4T R32.7.4)?
Is I2C address 0x44 for your ALS sensor?
Which I2C interface are you using to connect ALS sensor?
Could you also reproduce the same issue on the devkit? (by connecting ALS sensor on the 40-pins expansion header)
Yes
Correct
We don’t have any separate ALS module, any other option?
From these logs are you not able to conclude anything?
[ 11.646457] tegra-i2c 7000c000.i2c: pio timed out addr: 0x44 tlen:28 rlen:4
[ 11.653425] tegra-i2c 7000c000.i2c: --- register dump for debugging ----
[ 11.660122] tegra-i2c 7000c000.i2c: I2C_CNFG - 0x2c00
[ 11.665171] tegra-i2c 7000c000.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[ 11.671866] tegra-i2c 7000c000.i2c: I2C_FIFO_CONTROL - 0xe0
[ 11.677435] tegra-i2c 7000c000.i2c: I2C_FIFO_STATUS - 0x800040
[ 11.683263] tegra-i2c 7000c000.i2c: I2C_INT_MASK - 0x7d
[ 11.688484] tegra-i2c 7000c000.i2c: I2C_INT_STATUS - 0x0
[ 11.693794] tegra-i2c 7000c000.i2c: i2c transfer timed out addr: 0x44
From the log you shared, it seems the Jetson communicate with your sensor failed due to timeout.
krishnaprasad.k:
sudo i2cdetect -y -r 0
Is there any result on the working SOM?
KevinFFF:
From the log you shared, it seems the Jetson to communicate with your sensor failed due to timeout.
If we connect the NG SOM in devkit without connecting ALS then the i2cdetect on bus 0 won’t detect the HW, but it should scan/list the devices, in this case it is failed. If we replace the SOM it works perfectly so we can easily conclude it is the issue of SOM not from custom carrier board
Different
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
One or two I don’t have the correct count, is it possible to replace these SOM with new one
Do you mean that it will return the same as on your custom board if you put NG module on the devkit?
May I know how’s the fail rate in your case? (i.e. how many modules do you have? and how many module’s I2C0 not work?)
I would still suggest you could request HW team to compare the difference of I2C behavior for those 2 SOMs before request for RMA.
Correct. We have tested and confirmed
As of now, we have 2 modules
If we see the difference in i2c- behavior, whether these SOMs will be replaced by new one?RMA request?
