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.

I2C communication issue with Serializer 903Q and Deserializer 904Q Evaluation Kit

We are evaluating the TI DS90UB903Q and DS90UB904Q Serializer and Deserializer Evaluation kit received from TI. 
We are using the kit in CAMERA MODE where in we have connected the CAMERA sensor to the SERIALIZER and the DESERIALIZER is connected to DM6437 EVM.   
The connections comprises of 10 bits parallel data lines, along with HSYNC, VSYNC, PCLK and the I2C Clock and Data signals also.
 
On following the exact CAMERA MODE procedure provided in the User Manual of evaluation kit, we are able to get the link working (indicated by the LINK LED).
Only difference in the procedure we followed is, in our case the Camera Sensor Device ID is 0x60 instead of 0xA0 as provided in the user manual procedure.
 
Once the link is established we are configuring the camera sensor over I2C but the sensor is not Acknowledging the I2C transaction for some reason.
Camera sensor module is working and responding to the same I2C address, which is ensured by connecting the Camera module directly to the DM6437 EVM.
 
The Deserializer and Serializer link is ensured to be working, as we are observing I2C Clock and Data signals getting generated on the camera module I2C pins which
 is connected at the Serializer side. Also the address generated in the I2C transaction happens to be exactly same as in the case of direct connection to DM6437
(observed on Digital Storage Oscilloscope) . Only difference observed is with the edge on which the I2C data changes with respect to I2C clock.  We are not sure if
that is the issue.
 
For your reference the waveforms are attached.
TEK0000-Issue.jpg -> Waveform captured with Serializer and Deserializer connected in-between.

TEK0001-Working.kpg -> Waveform captured with Camera  sensor directly connected to DM6347 EVM.
 
What could be the reason due to which the camera sensor I2C communication is not working in case of Serializer and Deserializer introduced in-between.
Is there anything we are not configuring properly or what else we should be monitoring / ensuring to help us in identify and resolve the problem?

A quick reply in this regard is highly appreciable.
  • 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)

    1. Ensure deserializer register reg_0x03[3]=1'b (this is the default)
    2. Write the serializer I2C address (default 0x58) to deserializer register reg_0x07
    3. Write the sensor I2C address (0x60) to deserializer register reg_0x08
    4. Write the sensor I2C address (0x60) to deserializer register reg_0x10
    This configures the deserializer to pass I2C transactions meant for the image sensor to the serializer side.
    Step (1) ensures that the pass-through mode is set at the deserializer. This tells the device that there may be remote I2C devices whose transactions should be passed to the serailizer. This is a gating mechanism that keeps transaction intended locally from traversing the link. We tell the deserializer the serializer's I2C address in step (2). We then load the ID of the downstream image sensor in parts (3) and (4).
    The address loaded in step (3) identifies the actual I2C address of the sensor, and the address loaded in step (4) is an alias. This is used to alleviate address ambiguity in systems where there are multiple camera modules with the same address and a common I2C bus. For the purposes of your app, the ID and Alias can be the same thing. 
    Refer to datasheet pp17-24 for more information. Let me know if you have more questions.
    Regards,
    Ryan 
    AIDA APPS
  • 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

  • This thread was moved to private email.

    Dac Tran 

    SVA APPS