This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi Shailesh,
Based on the information provided, it looks like the I2C transaction is not being transmitted over the link, hence the NACK during the transaction. My first suggestion would be to see if the control registers are configured correctly. The serializer and deserializer need to be set to identify I2C transactions addressed to remote devices as such.
Can you tell me the configuration of the following registers?
UB904: 0x03, 0x07 through 0x17
Based on the provided informaiton, the following register settings are needed (assuming your I2C master controller is at the deserializer)
Hi Ryan,
Thanks for the information.
The I2C transaction (NACK one) have been captured on the Serialiser side itself ( Setup in CAMERA MODE), hence the I2C transactions are getting transmitted over the link.
The configuration of Deserialiser is as follows:
UB904: 1. Reg[0x03] = 0xE9 i.e. I2C pass through enabled.
2. Reg[0x07] = 0xB0 i.e. Serialiser address in 8 bit form.
3. Reg[0x08] = 0x60 i.e. Remote Sensor address in 8 bit form.
4. Reg[0x09] to Reg[0x0F] = 0x00 i.e. Other slave address not configured.
5. Reg[0x10] = 0x60 i.e. Alias for Remote sensor address in 8 bit form.
6. Reg[0x11] tp Reg[0x17] = 0x00 i.e. Alias of other slave address not configured.
Is there anything wrong with above settings?
As per my understanding, above settings seem proper. Unable to understand why the sensor is not acknowledging the I2C transaction.
Any more inputs / check point you can provide ?? Currently we are clueless.
Should we try evaluation in Display mode and check if the sensor acknowledges the transaction. Should that help in identification of issue?
Thanks and Regards,
Shailesh
Hi Shailesh,
Can you disclose the camera sensor used? I suspect the issue may be related to insufficient I2C hold time on the camera sensor. We had some customers experience similar issues related to I2C timing due to non-I2C compliant devices. Some slave peripherals use their own flavor of I2C protocol; such as 2-wire, serial bus interface, etc. and does not comply with the I2C standard. Do you know the minimum I2C hold time for the camera? The tHD:DAT data hold time I2C bus specification is 0us (min) for this timing. The I2C module implemented on DS90UB903/4 complies with the I2C standard. Since the serdes link is a synchronous system, the I2C is based on the falling edge of the SCL clock. Unfortunately there are no registers to adjust the hold timing on Serializer side. However, our newer chipsets such as DS90UB913/914, DS90UB925/926, etc. do have I2C setup/hold time programmability.
A possible workaround is to delay the SDA line on bus (additional hold time) by adding RC to slow the SCL -> SDA transition. They may also experiment with different I2C datarates to achieve this timing.
Dac Tran
SVA APPS
Hi Dac Tran,
We may not be able to provide the sensor number over the open forum, but here are the sensor timing details as mentioned in its datasheet.
tHD:DAT = 0 uS
tHD:STA = 0.6 uS
tSU:STA = 0.6 uS
tSU:DAT = 0.1 uS
all above values are MIN as mentioned in SCCB interface timing section of the datasheet.
Which appear to be I2C compliant as per the tHD:DAT = 0 time mentioned by you.
Also tried reducing the I2C frequency from 100KHz to 50KHz and 26KHz, but no change in behavior.
The I2C communication worked properly in DISPLAY MODE. i.e DM6437 -> Serialiser and Camera sensor connected to Deserialiser. But that's of no use to us.
Considering above inputs can you help us in drawing any conclusion of what might be going wrong? Or what could be the issue.
Do let us know if you need any more inputs.
Thanks and Regards,
Shailesh
Hey TI experts,
Please find below the register settings for Deserialiser and Serialiser after configuring the Link.
**************************************************************************************************
[C64XP_0] In Read_LVDS_Setting
[C64XP_0] Deserialiser Read Reg[0] = c0
[C64XP_0] Deserialiser Read Reg[1] = 4
[C64XP_0] Deserialiser Read Reg[2] = 0
[C64XP_0] Deserialiser Read Reg[3] = e9
[C64XP_0] Deserialiser Read Reg[4] = 0
[C64XP_0] Deserialiser Read Reg[5] = 0
[C64XP_0] Deserialiser Read Reg[6] = f
[C64XP_0] Deserialiser Read Reg[7] = b0
[C64XP_0] Deserialiser Read Reg[8] = 60
[C64XP_0] Deserialiser Read Reg[9] = 0
[C64XP_0] Deserialiser Read Reg[a] = 0
[C64XP_0] Deserialiser Read Reg[b] = 0
[C64XP_0] Deserialiser Read Reg[c] = 0
[C64XP_0] Deserialiser Read Reg[d] = 0
[C64XP_0] Deserialiser Read Reg[e] = 0
[C64XP_0] Deserialiser Read Reg[f] = 0
[C64XP_0] Deserialiser Read Reg[10] = 60
[C64XP_0] Deserialiser Read Reg[11] = 0
[C64XP_0] Deserialiser Read Reg[12] = 0
[C64XP_0] Deserialiser Read Reg[13] = 0
[C64XP_0] Deserialiser Read Reg[14] = 0
[C64XP_0] Deserialiser Read Reg[15] = 0
[C64XP_0] Deserialiser Read Reg[16] = 0
[C64XP_0] Deserialiser Read Reg[17] = 0
[C64XP_0] Deserialiser Read Reg[18] = 0
[C64XP_0] Deserialiser Read Reg[19] = 1
[C64XP_0] Deserialiser Read Reg[1a] = 0
[C64XP_0] Deserialiser Read Reg[1b] = 0
[C64XP_0] Deserialiser Read Reg[1c] = 3
[C64XP_0] Deserialiser Read Reg[1d] = 17
[C64XP_0] Deserialiser Read Reg[1e] = 7
[C64XP_0] Deserialiser Read Reg[1f] = 1
[C64XP_0] Deserialiser Read Reg[20] = 1
[C64XP_0] Deserialiser Read Reg[21] = 1
[C64XP_0] Deserialiser Read Reg[22] = 1
[C64XP_0] Deserialiser Read Reg[23] = 0
[C64XP_0] Deserialiser Read Reg[24] = 0
[C64XP_0] Deserialiser Read Reg[25] = 0
[C64XP_0] Deserialiser Read Reg[26] = 0
[C64XP_0] Deserialiser Read Reg[27] = c0
[C64XP_0] Deserialiser Read Reg[28] = 0
[C64XP_0] Deserialiser Read Reg[29] = 20
[C64XP_0] Deserialiser Read Reg[2a] = 0
[C64XP_0] Deserialiser Read Reg[2b] = 0
[C64XP_0] Deserialiser Read Reg[2c] = 0
[C64XP_0] Deserialiser Read Reg[2d] = 8
[C64XP_0] Deserialiser Read Reg[2e] = 0
[C64XP_0] Deserialiser Read Reg[2f] = 0
[C64XP_0] Deserialiser Read Reg[30] = 0
[C64XP_0] Deserialiser Read Reg[31] = 0
[C64XP_0] Deserialiser Read Reg[32] = 0
[C64XP_0] Deserialiser Read Reg[33] = a4
[C64XP_0] Deserialiser Read Reg[34] = fa
[C64XP_0] Deserialiser Read Reg[35] = 0
[C64XP_0] Deserialiser Read Reg[36] = 0
[C64XP_0] Deserialiser Read Reg[37] = 0
[C64XP_0] Deserialiser Read Reg[38] = 0
[C64XP_0] Deserialiser Read Reg[39] = 0
[C64XP_0] Deserialiser Read Reg[3a] = 18
[C64XP_0] Deserialiser Read Reg[3b] = 60
[C64XP_0] Deserialiser Read Reg[3c] = 0
[C64XP_0] Deserialiser Read Reg[3d] = 0
[C64XP_0] Deserialiser Read Reg[3e] = 0
[C64XP_0] Deserialiser Read Reg[3f] = 10
[C64XP_0] Serialiser Read Reg[0] = b0
[C64XP_0] Serialiser Read Reg[1] = 0
[C64XP_0] Serialiser Read Reg[2] = 20
[C64XP_0] Serialiser Read Reg[3] = fb
[C64XP_0] Serialiser Read Reg[4] = 80
[C64XP_0] Serialiser Read Reg[5] = 40
[C64XP_0] Serialiser Read Reg[6] = c0
[C64XP_0] Serialiser Read Reg[7] = 60
[C64XP_0] Serialiser Read Reg[8] = 0
[C64XP_0] Serialiser Read Reg[9] = 1
[C64XP_0] Serialiser Read Reg[a] = 0
[C64XP_0] Serialiser Read Reg[b] = 0
[C64XP_0] Serialiser Read Reg[c] = 1
[C64XP_0] Serialiser Read Reg[d] = 11
[C64XP_0] Serialiser Read Reg[e] = 1
[C64XP_0] Serialiser Read Reg[f] = 3
[C64XP_0] Serialiser Read Reg[10] = 3
[C64XP_0] Serialiser Read Reg[11] = 3
[C64XP_0] Serialiser Read Reg[12] = 3
[C64XP_0] Serialiser Read Reg[13] = ff
**************************************************************************************************
Please have a look and provide inputs on whether any of the configuration is improper or not.
A quick reply in this regards is highly appreciable.
Shailesh
Hi Shailesh,
I reviewed the register settings and everything looks in order except:
[C64XP_0] Serialiser Read Reg[7] = 60
When configured in camera mode (i2c host directly connected to deserializer), serializer Reg0x07 should not be programmed and left with default value of 0x00. Then try again to communicate with image sensor.
If you are still experiencing issues, try the following experiment. Modify the i2c slave address on the camera sensor programmed on the Deserializer (regs 0x08 and 0x10) to extend the hold time. For example, camera sensor id is 0x60 (0110_0000) and change to 0x70 (0111_0000). From past experience, we’ve had good success interfacing with camera devices with SCCB buses without any i2c timing issues.
One last test if that fails. Try blocking the PCLK input during initialization. In some cases, we have experienced excessive PCLK jitter coming from the camera sensors which may interrupt I2C communication. Use the following sequence:
===========
Example I2C addresses:
SER ID = 0xB0
DES ID = 0xC0
Camera ID = 0x60
===========
1) Perform Remote Wake Up Sequence
Write 0xC0 to register 0x26 of device 0xC0
Write 0x04 to register 0x01 of device 0xC0
Write 0x00 to register 0x26 of device 0xC0
2) Set the DES to Auto Ack I2C Commands
Write 0xED to register 0x03 of device 0xC0
3) Program Remote Slave ID into DES Index Register
Write 0x60 to register 0x08 of device 0xC0
4) Program Remote Slave ID into DES Match Register
Write 0x60 to register 0x10 of device 0xC0
5) Set Ser to Ignore Input PCLK (Force to Internal Oscillator)
Write 0x08 to register 0x27 of device 0xB0
6) Disable Auto Ack of DES
Write 0xE9 to register 0x03 of device 0xC0
7) Program remote slave (Camera), address 0x60, registers here to optimize the pixel clock fed to the SER.
8) Set SER to Accept the Now Stable PCLK
Write 0x00 to register 0x27 of device 0xB0
Dac Tran
SVA APPS
Hi Dac Tran,
Thanks for confirming the register settings.
1. We have tried with and without configuring the Serialiser Reg[07] register. But did not help in resolving the issue.
2. Currently we don't have any provision to change the I2C address of the camera sensor, hence we are evaluation if we can connect any other camera to the setup.
3. In our case the PCLK is generated only after the sensor is configured through I2C. And currently the I2C is not working for camera sensor, hence the PCLK is not generated at all. Even then we tried your suggested register configuration. But the issue still persists.
Would update once we either get the newer 913/914 chipset or try new camera sensor with same setup.
Do let us know if you find something that we should try, in order to resolve the issue.
Thanks for your continuous support.
Shailesh
Hi Shailesh,
For suggestion #2, the intent is not to change the physical slave address of the sensor. The experiment involves altering the slave id address programmed on the Deserializer (regs 0x08 and 0x10) to emulate extending the hold time when transmitted across to the Serializer on the remote i2s bus. This is to rule out if there is indeed a i2c hold timing issue. The only change is programming 0x70 (0111_0000) on Reg0x08 and 0x10. If that does not work, sweep the address on Reg0x08/0x10 until the remote camera responds to a particular address. This test is to ensure what device address will acknowledge to. Last test is to attach a different slave device (ie eeprom) on the remote bus to validate the i2c communication.
Dac Tran
SVA APPS
Hi Dac Tran,
As suggested by you, we tried configuring Deserializer reg[08] and reg[0x10] with 0x70 or 0xF0 or 0xA0. But sensor does not respond to any of them.
We did not completely understanding "sweep the address until the remote camera responds". But have tried with above 3 different address. If you feel any more address needs to be tried, please let us know the exact addresses.
We are trying to arrange some other I2C slave, but are unsure about whether that would be possible or not.
Kindly look into the matter and help us in resolving the issue.
Shailesh