• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 858 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.

DS92LX2121 DS92LX2122 I2C clock streching

Chris Demetrioff
Prodigy 30 points
Other Parts Discussed in Thread: DS92LX2121, DS92LX2122, DS90UB925Q-Q1, DS90UB926Q-Q1

I am looking for assistance in troubleshooting an I2C issue with my circuit.

I am using the DS92LX2121/DS92LX2122 in display mode. The DS92LX2121 (Serializer) is connected to my main processor and set to mode 1. The deserializer is set to mode 0.


It seems that the deserializer does not support SCL clock stretching when initiated by the connected remote device. This is evident because I only see 5 clocks being output by the deserializer when performing a read. When I slow down the deserializer i2C read rate to 11KHz (Register 6), I can see all 8 clock pulses and get valid/in-sync data.

The three missing clocks in the first example are the first bits of the byte and are seem to occur when the remote device is pulling SCL low. The remote device pulls SCL low for about 70us.

The remote device pulls SCL low after the slave address read is acknowledged but before a clock pulse is output by the deserializer.

All my other I2C devices work fine. This could be due to the fact that none of the other device clock stretch.

 My question is.... Does the deserializer support clock stretching by the connected remote slave devices? If it does, what could I do to fix it?

Thank you

  • 0
    TI__Mastermind 29655 points
    Hi Chris,

    Please allow me 1-2 days to look into this issue.

    Regards,

    Michael
  • 0 in reply to Michael Lu (Santa Clara)
    TI__Mastermind 29655 points

    Hi Chris,

    After checking through some documentation, it does look like the Remote Master proxy supports slave clock stretching, as seen in the Remote I2C timing relationship diagram in Figures 5 and 6 in the following app note: http://www.ti.com/lit/an/snla131a/snla131a.pdf

    I think it would be helpful if you could provide us with:

    1. Scope shots of the I2C line when SDA and SCL are working and not working with clock stretching.

    2. Measurement of master proxy SCL high and low time.

    3. Specifications regarding your remote device that is implementing the clock stretching. Do you have setup and hold time requirements we can refer to in a datasheet?

    Thanks,

    Michael

  • 0 in reply to Michael Lu (Santa Clara)
    Prodigy 30 points

    Hello Michael.

    I read the document and there is no explicit mention that the serializer/deserializer (BCC) supports clock stretching by the remote peripherals other than a statement that the BCC is i2c compliant. The document references the fact that the BCC its self clock stretches and that the host controller needs to support this stretching.

    Through my testing, I have verified that the BCC stretches the clock, and this is quite evident in the screen shots below. I am having trouble with the BCC not supporting clock stretching by the remote peripheral.

    I have included two attachments. Both show the remote peripheral holding the SCL low for 60us after the acknowledge for the slave address read. I inserted a series resister on the i2c bus to show a "lower" low that occurs when the remote peripheral pulls SCL low. The top waveform is the SCL on the deserializer side. The bottom waveform is the SCL on the serializer side. The top waveform is the clock generated by the deserializer (BCC) and is the one I am having problems with. 

    One waveform is reading data from the remote peripheral at 11KHz, and the other is 33KHz. You can see that the BCC is only clocking out 6 clks when running at 33KHz. The missing clocks are a result of the BCC not waiting for the remote peripheral to release the SCL. The 11Khz waveform shows all 8 clks with the first clock being slightly narrower due to being truncated by the remote peripheral holding SCL low.

    Changing the deserializer i2c frequency is performed by adjusting a register. It is independent of the host controller i2c frequency.

    There is no mention of clock stretching in the remote peripheral data sheet. This is not a concern because the peripheral is following the i2c spec and is allowed to clock stretch.

    If you have any more questions, let me know, and thank you for helping me.

    Regards,
    Chris


  • 0 in reply to Chris Demetrioff
    Prodigy 30 points
    Michael, I obtained a more detailed datasheet for the touch controller, remote peripheral, that is stretching the clock.
    It specifies that it will hold the SCL line low until it is ready to transfer data.

    So it is perfoming as expected...

    Regards,
    Chris
  • 0 in reply to Chris Demetrioff
    TI__Mastermind 29655 points
    Hi Chris,

    Thanks for the waveforms. After doing some more digging over here, I have found that these Channel Link III devices come from a generation of devices where slave clock stretching on the remote side (Deserializer serving as master proxy) is not supported, since this logic was not built into this device. Thus, the deserializer (master proxy) may work with slave clock stretching if the remote device holds the line low for less than the time the deserializer waits to begin the next transaction, as you have seen in the case of SCL f = 11 kHz.

    Therefore, I have concluded that your observations are consistent with the expected device behavior. The DS90UB925Q-Q1/DS90UB926Q-Q1 next-gen family of devices supported by our automotive SerDes team DO have logic for master arbitration to support remote peripheral slave clock stretching if this is an absolute requirement.

    Thanks,

    Michael