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.

DS90UB960-Q1: FPD Link - I2C error

Part Number: DS90UB960-Q1

Hi all,

I have following setup: TDA2p -> UB960 -> Coax -> UB953 -> IMX390 sensor.

I'm receiving frames from camera without any problem (FULL HD, 60 fps), but I have some strange problems related to I2C communication with sensor.
In run-time, exposure parameters are set for every frame via I2C. The problem I'm facing is that sometimes I2C write fails (every few minutes):

[HOST] [IPU2 ] 205.169706 s: src/bsp_deviceI2c.c @ Line 1271:
[HOST] [IPU2 ] 205.169859 s: I2C2: DEV 0x44: WR 0x0008 = 0x0001 ... ERROR !!!
[HOST] [IPU2 ] 205.169981 s: src/bsp_deviceI2c.c @ Line 1293:
[HOST] [IPU2 ] 205.170072 s: I2C2: Error timeout 236 ms!!!
[HOST] [IPU2 ] 205.170682 s: Fail to set sensor aewb data: status=-21!

I suppose this problem could be related to I2C timing parameters, so I have few questions for you:

1. If I have a good understanding, in this situation, UB953 is master proxy and UB960 is a slave proxy?

2. The proxy master (UB953) timing parameters are based on the internal reference clock? Is this correct for synchronous mode?

3. If UB960 is slave proxy, it's not necessary to set I2C timing parameters for deserializer?

4. Could it be related to I2C clock stretching? I noticed following - If I set BCC_WATCHDOG_TIMER value from BCC_WATCHDOG_CONTROL register to 0x01 instead of 0x7F, timeout from error above will be 1-2 ms, instead of 236 ms.

I would appreciate some advice or help with this issue.


Best regards,
Stefan.

  • Hello Stefan,

    1) If the I2C host master is on the deserializer side (which is your case), the Serializer will act as proxy master when communicating to image sensor/other remote slaves.

    2) Yes.

    3) In this case you will need to setup the I2C timing parameters only for the Serializer.

    4) Have you monitored LOCK on the Deserilizer side? Have you monitored CRC errors on the Serializer? Such behavior could come due to back channel instability.