We observe that sometimes the Jetson has issues writing a register of our camera using i2c .
We attached a beagle i2c analyzer to the i2c bus and could observe that the following occurs when the write fails:
The address byte is written to the bus and acknowledged by the camera as expected. But then it takes about 20 ms until the first data byte is sent by the Jetson.
On normal writes this just takes 5 us, so here it is 4000 times slower!
Also see this timing diagram of one recorded case:
Do you have any idea how such a problem could occur or what we could do to further debug it?
We are using JetPack 36.4.0 with Linux Kernel 6.6.23 on a custom carrier board.
The tests so far only involved normal camera operation while running some other programs.
With i2cset (while true; do i2cset -y 2 0x42 0x30 0x50 0x00 i ; done), I could not yet reproduce a failed i2c write. Though I could observe some other unusual long write transactions.
E.g. one write took 588 us instead of the usual 105 ns.
As in the failed write transaction above, all the delay occurred in the ACK of the address byte:
The address byte is ACKed as expected, but after that SCL stays low and SDA stays high for 12.9 ms.
This can not be explained with clock stretching by the camera. In such a case the Jetson would already prepare SDA for the next data bit, which is ‘0’ in our case and pull it low.
Instead the recorded signal implies that there is an issue with the Jetson (or its I²C controller) and it is hanging/pausing for 12.9 ms.
Do you have any idea why this could happen?
Are there any known bugs in the i2c controller?
(For the record: The signal quality looks so bad because of the external wiring for recording the signal)
Probably the previous write might have taken longer than expected and the I2C might have timed out.
I2C driver will then reset the I2C controller. The “hang” state might be time I2C took to reset itself.
Could you check the kernel log if any information.
Do you mean the previous write on the same bus? That one looked totally normal and was successful.
The kernel log does not contain any message for the time this issue occurred.
So there’s no any error from the dmesg and i2c write successfully but observe delay from the scope right?
No, the write in question fails with an -121 (EREMOTEIO). As can be seen in the scope recording the first data byte is not ACKed.
In the scope we also see that the Jetson does not even try to transmit the remaining other two data bytes the write transaction consists of (which makes sense, as the first data byte was not ACKed).
So obviously the i2c write fails.
But besides results of this one write failure we don’t see any extra information or further i2c failures in the kernel log.
Looks like the you observe the i2c write delay by the scope without write failed.
I don’t think the bus driver have any control on that. If the delay is after address byte.
From the I2C driver, i2c bus driver write the data to the FIFO and initiate the transfer.
That don’t have any control in SW after that until the complete interrupt comes.
No, the i2c write fails.
I know this because
A) in the scope output you see that the second byte (which is the first data byte) is not ACKed.
B) I see in the Kernel log that the camera driver logs a failed i2c write:
Oct 17 10:43:04 device kernel: imx676 9-001a: imx676_write_reg: i2c write failed, 0x30dc = 32
Oct 17 10:43:04 device kernel: imx676 9-001a: imx676_write_buffered_reg: BUFFERED register write error
Oct 17 10:43:04 device kernel: imx676 9-001a: tegracam_ctrl_set_overrides: error to set 10100852 override
Oct 17 10:43:04 device kernel: imx676 9-001a: overrides cannot be set
Oct 17 10:43:06 device kernel: tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
Oct 17 10:43:06 device kernel: tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
Oct 17 10:43:06 device kernel: tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
Ok, so this issue probably comes from the i2c controller of the Jetson?
Hi @kayccc, yes this issue still exists.
We would really appreciate if someone from Nvidia could explain to us how this issue could occur.
There are no additional results to share from our side as the scope recordings strongly hint to some issue with the Jetson i2c controller. Are there any known issues with that controller?
