• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 34 subscribers
  • Views 516 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: FPD-Link III: I2C fail during initialization

Hanno Reimer
Intellectual 1930 points
Part Number: DS90UB953-Q1
Other Parts Discussed in Thread: DS90UB954-Q1, ALP

We use the FPD III link. Here a question arose, where you can certainly support us:

During I2C communication to connected I2C slaves (serializer) in the initialization phase of the link, the link sometimes loses its PASS/LOCK for a short time and the I2C transfer stalls/fails: The FPD link ( also MIPI image data transfer) works well once the initialization has been successful.

The unlock of the FPD-Link occurs the more often, the earlier after the FPD-Link initialisation the I2C communication is started. The unlock is independent of which component is communicating via I2C.

The problem no longer occurs if communication is started several seconds after PowerON of the link (e.g. continuous reading from an EEPROM several seconds after system start).
Our assumption: The FPD-Link connection is unstable during AEQ at power-on if data is already being transferred during this time.

Is our assumption about the cause of the error correct?
What could we adapt (e.g. AEQ register settings, link training, etc.) to make the link "stable" more quickly after power-up?
What further investigations would be appropriate to find out more about the "error"?

Translated with www.DeepL.com/Translator (free version)

  • 0
    TI__Expert 5480 points

    Hello Hanno, 

    Please refer to figure 57 in the DS90UB954-Q1 datasheet. You should start remote i2c transactions after lock is high. When AEQ is running and the link is not stable, you may see i2c transactions fail because the transactions are not getting to the SER or there is no ACK. You can reduce the AEQ lock time by running margin analysis which is a part of our analog launch pad GUI. Then you can limit the EQ/Sfilter values so the AEQ search range is limited. See table 6.6 in the DS90UB954-Q1 datasheet. Another option is to change 0xD2 [7:5] and reducing the lock time check, but I would recommend leaving it at the default to ensure the AEQ settings are optimized. 

    Here is our appnote going over margin analysis.

  • 0 in reply to Sally Cheung95
    Prodigy 10 points

    Hello Sally,

    Thank you for your answer and the advice to only start I2C transfer when LOCK - OK (high)

    But - we start the I2C transfer approx. 500ms after LOCK / PASS is valid (see attached picture of the starting routine).

    Nevertheless, the error described occurs. As I said, a few seconds later after the LOCK the I2C error no longer occurs.

    Do You have any other suggestion how could we correct this behavior?

    Thank You very much for your support !

  • 0 in reply to Niko Cyris
    TI__Guru** 103215 points

    Hello Niko,

    It seems like the unlock event is happening right after some I2C transactions. Are the transactions changing any register settings in the 953 or the deserializer which could be causing the unlock event?

    Also can you please run the MAP tool in ALP on the deserializer for this link to get an idea about the system margin?

    https://www.ti.com/lit/pdf/snlu243

    https://www.ti.com/lit/pdf/snla301 

    Best Regards,

    Casey