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.

DS92LX2121/DS92LX2122 I2C

I am having some difficulties with the I2C control channel in an imager setup.

First question: Should the Index and Match registers contain the same address, or different (alias) values like in this application note for a different SER/DES pair?   http://www.ti.com/lit/an/snla222/snla222.pdf

Second question: It seems to work with the same address in both Index and Match, unless the imager PCLK stops or changes during its configuration, then either (1) the address coming out of the SER is different from the one sent to the DES, or (2) the correct address comes out the of the SER and the imager acks the address but a nack is returned through the DES to the host. Are the SER/DES register values retained through PCLK changes/interruptions?

Thanks

Gideon

  • Hi Gideon,

    Thanks for posting, and sorry for the delay! We're taking a look at this and will get back to you as soon as possible to double-check your findings.

    Regards,

    Michael

  • Hi Michael,

    Thank you for your reply. The imager I am using is an Omnivision ov5640, which enables, disables and changes the frequency of PCLK in response to I2C commands, and this seems to upset the SER/DES I2C channel.

    Regards,

    Gideon

  • Hi Gideon,

    Thanks for your patience as I looked into this. Please see responses to your questions below:

    1. The index and match register can contain the same address value as long as there are no other I2C devices on the line that have duplicate device IDs . If you are connected to only one imager in the entire system, having the same index and match will not present a problem. Using different alias values is particularly useful in situations where you need to differentiate from multiple slave devices that happen to use the same I2C address so that you don't run into undesirable SDA/SCL line contention.

    2. When the PCLK is interrupted, the Serializer and Deserializer addresses should not change. As long as there is a valid VDD power connected to the SerDes ICs, the register settings should be retained. However, it is possible that during the PCLK interruption, the I2C transmission, particularly if the interruption occurs in the middle of an I2C transmission, will become corrupted until the PCLK stabilizes and the SerDes locks again. There is a work-around for situations where the PCLK is in this transition state.

    Please see the following program sequence. The following register writes will configure the SER to ignore the bad pixel clock so that control information can be sent to configure the remote slaves.

    ================================================

    Example I2C addresses:

    SER ID = 0xB0

    DES ID = 0xC0

    Camera ID = 0x31

    ===========

     

    1)     Perform Remote Wake Up Sequence

    1. Write 0xC0 to register 0x26 of device 0xC0
    2. Write 0x04 to register 0x01 of device 0xC0
    3. Write 0x00 to register 0x26 of device 0xC0

    2)     Set the DES to Auto Ack I2C Commands

    1. Write 0xED to register 0x03 of device 0xC0

    3)     Program Remote Slave ID into DES Index Register

    1. Write 0x31 to register 0x08 of device 0xC0

    4)     Program Remote Slave ID into DES Match Register

    1. Write 0x31 to register 0x10 of device 0xC0

    5)     Set Ser to Ignore Input PCLK (Force to Internal Oscillator)

    1. Write 0x08 to register 0x27 of device 0xB0

    6)     Disable Auto Ack of DES

    1. Write 0xE9 to register 0x03 of device 0xC0

    7)     Program remote slave (Camera), address 0x31, registers here to optimize the pixel clock fed to the SER.

    8)     Set SER to Accept the Now Stable PCLK

    1. Write 0x00 to register 0x27 of device 0xB0

    ================================================

    I have taken this information from a draft app note document that was written a few years ago. If you would like a look at the full document, please e-mail me at m-lu@ti.com.

    Hope this helps, and sorry again for the response delay.

    Thanks,

    Michael