• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 99 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TSER953: Inquiry About I2C Communication Issue with V3 Link Adapter Board and TSER953

yang tian
Prodigy 10 points
Part Number: TSER953
Other Parts Discussed in Thread: TDES954

Tool/software:

I am currently working on a setup involving the V3 Link Adapter Board connected to a Raspberry Pi 4. The TSER953 serializer and the TDES954 deserializer are connected via a coaxial cable, with the TDES954 controlling an image sensor.

On the TSER953 side, I have added an LED device that uses I2C communication. However, when I run the command i2cdetect -y 10, I can only detect the address 0x0c and not the address of the LED device. Could you please help me understand why the LED device's address is not being detected?

Additionally, if I want to add another I2C-based LED device on the TSER953 side, what steps should I take to ensure proper communication and address detection? Are there any specific configurations or considerations I need to be aware of?

Here is the hardware setup.

  • 0
    TI__Mastermind 22095 points

    Hi Yang Tian, 

    Would you be able to confirm the following in a system context? 

    • Set 0x4C to select each port (e.g. 0x01, 0x12)
      • Read back 0x4D
      • Read back 0x58

    For bidirectional I2C communication, lock will need to be asserted in register 0x4D and I2C passthrough must be enabled in register 0x58. I2C passthrough all 0x58[7] will allow any I2C address to potential be recognized. If I2C passthrough 0x58[6] is enabled, only I2C addresses which have target aliases and IDs programmed will be recognized through the command. Target alias and ID registers are port specific. 

    Best,

    Zoe 

  • 0 in reply to Zoe Bison
    Prodigy 10 points

    Hi Zoe,

    Thank you for your detailed explanation regarding the register configuration for I2C passthrough. Based on your information, I understand that:

    1. Port selection is done via register 0x4C.

    2. Register 0x4D needs to have the lock asserted.

    3. I2C passthrough must be enabled in register 0x58, with:

      • Bit 7 allowing any I2C address.

      • Bit 6 restricting to programmed target aliases/IDs.

    Current Setup & Issue:

    My hardware configuration is as follows:

    • Host: Raspberry Pi 5 (I2C bus 4, same behavior as Pi 4 in testing).

    • TDES954: Connected to the Pi via I²C.

    • TSER953: Connected to the TDES954 via coaxial cable (FPD-Link III).

    When I run i2cdetect -y 4, only 0x0C (the TDES954’s control interface) appears, but I do not see the expected I²C address for programming the device.

    Questions:

    1. Initialization Sequence: What is the correct procedure to establish communication with the TDES954 for programming?

    2. Expected I²C Address: Should I see a different address appear during the bus scan, or is 0x0C the correct interface for configuration?

    3. Pre-Configuration Steps: Are there any specific register settings or initialization steps required before the device will respond to programming commands?

    I’d appreciate any guidance on properly configuring the device for bidirectional I²C communication in this setup.

    Best regards,
    Yang Tian

  • 0 in reply to yang tian
    TI__Mastermind 22095 points

    Hi Yang Tian, 

    Prior to I2C communication with the TDES954, the following power-up sequencing requirements must be followed on the deserializer. 

    If mode straps are matching (e.g FPD-Link Synchronous mode) on the serializer and deserializer, lock will be asserted on its own. Since these are custom boards, would you be able to share the schematics for these projects? 

    The I2C address for the TDES954 should match one of the ones listed below here: 

    Local I2C communication should be available following proper power-up sequencing. Remote I2C access will be dependent on lock and I2C passthrough configurations. 

    Best,

    Zoe