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.

DS90UB953-Q1: I2C Communication Instability with DS90UB953-Q1 on RK3588 Platform

Part Number: DS90UB953-Q1

Tool/software:

Dear  Experts,

I am working on an FPD-Link III camera system using the following configuration:

  • Host: RK3588 (I2C7 as master)
  • Deserializer: DS90UB954 (I2C slave address: 0x30)
  • Serializer: DS90UB953 (I2C slave addresses: 0x18/0x19) (2 camera)
  • Operating Mode: CSI-2 Non-Synchronous Back Channel Mode

Issue Description:
During initialization, the DS90UB953 serializer fails to configure properly. Key observations include:

  1. Driver Initialization Failure: The DS90UB953 initialization sequence does not complete, and the device ID (e.g., register 0x00) cannot be reliably read.
  2. I2C Address Instability:
    • i2cdetect -y 7 intermittently shows addresses 0x18 and 0x19 (sometimes marked as UU, sometimes missing).
    • Direct register access via i2cget results in sporadic errors (Error: Read failed).
  3. Link Quality Issues: The FPD-Link III connection exhibits frequent synchronization drops (observed via dmesg logs).

Attached Data:

  • Device tree configuration snippets (I2C alias definitions, clock settings).
  • dmesg logs showing repeated timeout errors during initialization.

Request for Guidance:
Could you provide insights into the following?

  1. Device Tree Best Practices:
    • Proper configuration of slave-alias entries for dual-serailizer setups.
    • Recommended I2C bus settings (clock frequency, noise filters) for RK3588 compatibility.
  2. Non-Synchronous Mode Pitfalls:
    • Critical timing requirements for CSI-2 back channel initialization.
    • Known issues with clock stretching or ACK/NACK handling in this mode.
  3. Signal Integrity Validation:
    • Key parameters to measure for FPD-Link III stability.
    • Debugging steps to isolate I2C vs. link-layer faults.

Thank you for your expertise and support.

Best regards,

qing

jinanhauxiangxinxikejiyouxiangongsi

  • Hello,

    Please note that on this forum we can only support FPD-Link devices and their application and can not provide guidance on the creation or implementation of drivers. With that being said, the 953 and 954 devices are able to lock and communicate automatically as long as the proper modes are strapped at power up. First verify that both the 953 and 954 mode pins are configured to select the non-synchronous mode. Note, that this mode requires an external clock be available to the 953 serializer for operation. 

    The serializer alias are configured in register 0x5C of the 954. This is a port specific register, so make sure to select the intended RX port with register 0x4C. If clock stretching is to be implemented, verify that all devices in the system (display, imagers, processor, etc.) can support clock stretching. You can check the lock status of the 953 and 954 by reading back register 0x4D. Bit 0 indicates if the devices currently have lock and bit 4 logs if lock has been lost at any point since the last time the register was read. It is recommended to read registers 0x4D several times with a slight delay, to verify if lock is stable. A stable lock will not have bit 4 set at any time.