• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 35 subscribers
  • Views 215 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.

DS90UB927Q-Q1: PCLK changes result in intermittent I2C forwarding failures

Alexander Sverdlin
Prodigy 60 points
Part Number: DS90UB927Q-Q1
Other Parts Discussed in Thread: DS90UB928Q-Q1

Tool/software:

Dear TI engineers!

We are experiencing an issue with I2C forwarding between DS90UB927Q-Q1 and DS90UB928Q-Q1.

The issue happens when PCLK is being changed from 37MHz to 3.5MHz and back to 36.7MHz.

The serializer is connected to TI AM62x, OLDI output. The driver which does the clock manipulations is available here.

It doesn't make sense in my opinion to try to adapt the driver code to the DS90UB927Q-Q1 requirements, because all kinds of bridges or panels could be connected to tidss and it's not possible to satisfy all of them.

So as long as PCLK is within the allowed voltage, DS90UB927Q-Q1 probably has to cope with it.

Now it's not really described in the datasheet, what happens if MCLK changes during DS90UB927Q-Q1 operation, neither is any procedure to safely change MCLK is described in the datasheet, while changing MCLK must be possible and legal (even within DS90UB927Q-Q1 5-85MHz limits).

So back to the original issue: we've noticed that right after MCLK changes I2C communication with devices connected to DS90UB928Q-Q1 deserializer is not possible for, roughly 13ms.

During this time General Status register 0xC doesn't register Link or PCLK loss.

Could you please shed some light on the internal processes and requirements of the DS90UB927Q-Q1/DS90UB928Q-Q1 chips regarding MCLK stability or the required procedures to change MCLK in operation. Why is I2C communication intermittently broken, how can we detect or avoid this situation? What are the timing requirements? Do we need to avoid I2C communication for some time after MCLK change? What other functionality is affected? What is the duration? Or is any kind of reset or power down required to cope with MCLK frequency change?

Best regards,

Alexander Sverdlin. 

  • 0
    TI__Mastermind 22205 points

    Hi Alexander,

    Please see this E2E thread for more details (link). Although this is not directly referring to the UB927/UB928, the same basic principles apply.

    Best,

    Nikolas

  • 0 in reply to Nikolas Antonucci
    Prodigy 60 points

    Thank you for the quick reply Nikolas!

    The datasheets for UB927/UB928 only specify the PLL lock timings for the powerup cases.

    What are the PLL unlock-lock timings for the frequency changes?

    As we only have access to UB928 via UB927, we cannot poll 928's PLL lock bit I suppose. UB927 doesn't have any PLL lock bit as I understand.

    So only some conservatively chosen delays possible, if I understand correctly?

    Alexander.

  • 0 in reply to Alexander Sverdlin
    TI__Mastermind 22205 points

    Hi Alexander,

    PLL unlock timings were not spec'd out for either device. In addition, there is no power-down sequence for either device as well.

    Since link will be lost if lock is lost, and changing the PCLK will lead to a loss of lock, this is most likely why you are seeing intermittent I2C failures upon changing of the PCLK frequency. The PLLs need to adapt to the new frequency to re-establish communication across the bidirectional control channel. Am I correct in assuming this intermittent loss of I2C communication occurs when changing the PCLK?

    Best,

    Nikolas

  • 0 in reply to Nikolas Antonucci
    Prodigy 60 points
    Nikolas Antonucci said:
    Am I correct in assuming this intermittent loss of I2C communication occurs when changing the PCLK?

    Correct, that is the case.