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.

DS90UB914A-Q1: I2C Issue

Part Number: DS90UB914A-Q1

Hi team,

I have a issue for remote I2C access.

I2C communication may be interrupted due to power supply fluctuation on the 913A side during the I2C access from the CPU on 914A side to the serializer 913A.
At this time, we have confirmed that the link between 913A and 914A is lost.
After that, the link between 913A and 914A returns and the image signal of High speed automatically restores, but I2C may not return.
At this time, SCL is High and SDA is Low.
914A is pulled down to Low, is this correct behavior?

If the communication is interrupted during the I2C command transfer, what does the operation of 914A and reflection on some registers become?

Since it happens occasionally, not every time, I want to know what it is supposed to do and take the right measures.
Best regards,
Tomoaki Yoshida
  • Hello,
    The device needs to be powered up properly for the I2C to function correctly.

    1. Measure the power pins and PDB to make sure device is powered up properly.
    2. Can you confirm there is proper SDA/SCL pull-up and the IDx address and I2C configuration registers are set properly?
    3. Are you able to capture the failed I2C transaction on the bus?
  • Hi Palaniappan-san,

    Thank you for your support.

    1. Measure the power pins and PDB to make sure device is powered up properly.
    >The power supply and PDB of 914A is normal before and after.
    Camera modules with 913A can not be monitored inside.
    Is there a case that 914A pulls SDA low regardless of 913A after the 913 and 914 links are lost?
    If it is caused by 914, it is necessary to take countermeasures on the board side that we are designing.

    2. Can you confirm there is proper SDA/SCL pull-up and the IDx address and I2C configuration registers are set properly?
    >This is normal also for 914A.

    3. Are you able to capture the failed I2C transaction on the bus?
    >I will check this.

    Best regards,
    Tomoaki Yoshida
  • Are the 1.8V and 3.3V supplies powered up properly? If you have power supply fluctuation on the 913A side during I2C access, you need to make sure the power supplies have settled and at proper and stable levels and then toggle PDB (high -> low -> high, minimum 2ms low pulse) and then wait for a delay (>1ms for local I2C access, for remote I2C wait for LOCK in addition to the PDB requirement).

    If you are not able to capture the power supply levels and PDB on the 913A side to confirm the proper sequence, then this fix above should help.
  • Hi Palaniappan-san,

    Thank you for your support.

    In order to confirm the communication at the time of fluctuation of power supply, we control the power supply of the camera side to make the crank state.

    Although it is not possible to monitor 1.8 V and 3.3 V in the actual camera module, it is designed to not exceed the power operation range of 913A.

    Since I2C is out of control, it is not possible to monitor registers of 914A and 913A, so it seems to be the only way to reset it with PDB.

    As you taught me, is there a description in the data sheet on how to deal with the link lost?

    If it is clearly stated somewhere that I2C command transfer is restricted when the link is established, and it should be resetted the link is lost during the command transfer, I will use this restricted usage It is necessary to clarify.

    Best regards,

    Tomoaki Yoshida

  • You can refer to the 914A datasheet 'power up requirements and PDB' section (page 46) for details on how to handle loss of lock. It is recommended to perform either PDB reset or digital reset (which is not possible via I2C in your case).

    By the way, during the time when the link comes back after the power supply fluctuation did you check for LOCK (at the output pin) when I2C is not working?
  • Hi Palaniappan-san,

    Thank you for your kind support.

    We were monitoring that LOCK is out during power cranking, and that LOCK is stable after the link returns.

    We also thought that the only countermeasure was PDB of 914A.
    However, there is a request from our customers to investigate this cause, and we must isolate whether it is at least 914A or 913A problem.
    Since SCL is stopped high, I think that at least the master 914 A has been held.
    Slave 913A should not have generated SCL.
    Is this right?


    Best regards,
    Tomoaki Yoshida
  • Do you have a block diagram of the system? Can you take scope captures of the SCL/SDA lines, reset along with the power supply/PDB signals? What is your power supply ramp up sequence?
    We need to confirm if you are seeing this behavior during the time the 1.8V VDDIO rail is not applied or powered up at proper stable level.

    If you have a microcontroller enabling the reset/power supplies of the serializer, then if possible delay the initialization of the microcontroller I2C until after the supplies have stabilized to check if that makes a difference.
  • Hi Palaniappan-san,

    Thank you for your support.
    I was able to capture the I2C line.
    I want to send data, can I communicate by e-mail locally?
    I am applying for friendship, so please email me.

    I want to check again, dose the mode in which I2C of 914A is fixed with SCL = High and SDA = Low exist?
    If this state is conceivable in some mode it may be useful to judge whether it depends on 913A or 914A.

    Best regards,
    Tomoaki Yoshida
  • Yoshida-san,
    We received the additional data you captured from TI Japan by email, and the FAE will log this as a support request internally so we can handle this offline with the FAE.
    To close the loop here, this isn't an expected use mode where SCL and SDA are fixed to a certain value. Again this is likely caused by the power supply fluctuations on the camera side, and without being able to measure the power supplies on the camera side the PDB can be used as a fix.
  • Hi Palaniappan-san,

    Thank you for your support.

    We are pushing to the customer to monitor the 913A power supply.
    We will share information with local FAE.

    Best regards,
    Tomoaki Yoshida