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.

DS90UB954-Q1: I2C write fail while UB954 access cmos sensor through UB953

Part Number: DS90UB954-Q1
Other Parts Discussed in Thread: DS90UB953-Q1

Dear Sir,

Sometimes  I2C write fails occasionally while UB954 access cmos sensor which attacted with UB953.   sometime just a few of regsistors writing operations maybe fails,Can TI expert give me some advcie how to investiagte this issue?  The HSOT I2C speed is 100Khz.

Best regards!

  • Hi Tiger,

    Have you tried using 400kHz? If so, was their any improvement?

    What is the value of the pull-up resistors and the pull-up voltage that is used on the UB954?

    Regards,
    Mandeep Singh
  • Dear Mandeep,

    All pull-up resistors are 2.2K , in UB954 side , they are pulled up with 3.3Vcc, in UB953 side, they are pulled-up with 1.8Vcc.

    Regards.
  • Hi Tiger,

    Can you lower the votlage on the 954 to 1.8V? It's possible that the transition of voltage is causing the issue. What is the voltage of i2C on the Soc? If this doesn't work, then try matching the voltage to the votlage of the SoC if it's not already 1.8V.

    Regards,
    Mandeep Singh
  • Dear Mandeep,

    The HOST SOC I2C bus voltage is 3.3V,so UB954 I2C bus voltage can not be changed to 1.8V, is there any other method to investigate this issue?

    Best Regards.
  • Dear Mandeep,

    In my opinion, UB954 slave I2C controller receive sensor init command, encode them and transmit them by FPD LINK back channel, UB953 decode them from back channel and retransmit them to imag sensor.

    So, do you think the different I2C bus voltage on UB954 and UB953 may cause this occasional fail?

    Best Regards.
  • Hi Tiger,

    I investigated further and I don't think that would be it. Does the SoC have clock stretching? Because our devices require this, they require that that an I2C slave be allowed to hold down the clock if it needs to reduce the bus speed. Not all SoC's provide this, so please check if this functionality is there.

    Also, didn't get an answer from you regarding changing the speed to 400kHz? Have they tried that and what were the results?

    Additinally, is the issue only when the 954 tries to talk to the 953 or sensor? There's no issue with the 954 and SoC? Are there any back channel errors that are being flagged in the registers?

    Regards,
    Mandeep Singh
  • Dear Mandeep,

    The host SOC supports clock stretching, I will try it!


    Best regards!
  • Dear Mandeep,

    Whatever 100Khz or 400Khz,I2C accessing for image sensor or UB953 maybe fail occasionally!it seems no big power supply noise,Which registers can be used  to debug this issue?

    Best,

  • Hi Tiger,

    There's really no registers to debug i2c, because in order to communicate to those registers, you would need i2c. The best indicator therefore is to ensure you have it set-up correctly on the hardware and all the alias and slave_alias are set-up correctly. You can also monitor the timings of your I2C and ensure they are meeting the spec.

    On the DS90UB953-Q1, it is recommended that reg 0x32[7:5] = 010. See Table 3 in the app note below. This app note is good in general for understanding and making sure i2c is working correctly, so you can refer to certain parts of this that still apply for the 953/954.

    Regards,
    Mandeep Singh

  • Dear Sir,

    reg 0x32 value is 0x49, which is suggested by you,I understand the app note, it seems about 20 percent probability accessing some register of image sensor fails. and usually, it works fine.

    I had tested the following cases:

    1. UB954 400Khz   UB953 90Khz (standard, default )

    2. UB954 400Khz   UB953 300Khz(fast)

    3. UB954 100Khz   UB953 90Khz(standard, default )

    case 1, the fail probability is bigger than other case

    case2,3.  no much more different, 20 percent probability fails.

    I will try to slow down I2C speed by increasing SCL_high(0x0b) and SCL_low (0x0c). can you give more advice?

    Best,

  • Sorry, case 2 is much more worse than others.

  • Hello Tiger,

    I suspect there may be an SI issue causing the back channel communication to fail. Are you using PoC? Does your PoC network match the recommendations from the datasheet? Can you try running BIST to ensure that there are no forward or back channel errors during self test mode?

    Best Regards,

    Casey 

  • Hi Tiger,

    Do you have any further questions related to this specific post?

    Regards,
    Mandeep Singh