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

Does the ADC128D818 utilize I2C clock stretching?

Steve Strobel
Intellectual 370 points

Other Parts Discussed in Thread: ADC128D818

While monitoring an I2C bus with a scope, I noticed what appears to be clock stretching during communication with the ADC128D818.  I was surprised because I didn't find any mention of clock stretching in its datasheet.  Specifically, I see about a 500uS period where SCL is low (between the first and second images below), then a shorter 14uS stretch as shown in the middle of the second image.  Could someone confirm that the ADC128D818 does in fact utilize clock stretching?

Also, in the second image, is the short glitch during the last SCL pulse expected, or does it indicate some kind of problem?

Any help would be greatly appreciated.

Steve

  • 0
    TI__Mastermind 27750 points
    Steve
    just a point of clarification. the master controls the clock, not the ADC. Unfortunately I am not familiar with the term clock stretching but data is loaded and read by devices on the rising edge. delays between rising edges is not a problem. Runt looking pulses on SDA are common. that just means someone took control of the bus and this is not a sign of any problem. in general, i am not seeing any problem with the waveforms you have shared.
    chuck
  • 0 in reply to Chuck Sins
    Intellectual 370 points
    Thanks for the response. I understand that only the I2C master can generate clock pulses, but as I understand it, a slave is allowed to hold the clock line low if it wants more time before responding. Considering that my I2C master (a Tiva C Launchpad board) is using its hardware I2C interface (not bit-banging it), I wouldn't expect (and have never previously observed) any variation at all in the clock period.

    For more about I2C clock stretching, see these:
    www.i2c-bus.org/.../
    en.wikipedia.org/.../I²C (search for "Clock stretching using SCL")

    If there is someone at TI (or elsewhere) that could confirm or deny whether the ADC128D818 utilizes clock stretching, that would be helpful to me.

    Steve
  • 0 in reply to Steve Strobel
    TI__Mastermind 27750 points
    Steve
    I double checked with our digital designer. As I assumed, our part does not perform clock stretching. however, if another slave on the bus does this, we will not be adversely affected.
    chuck
  • 0 in reply to Chuck Sins
    Intellectual 370 points
    Thanks for following up on that. It looks like I have more digging to do.

    Steve
  • 0 in reply to Steve Strobel
    Intellectual 370 points
    Just to follow up for anyone that stumbles across this thread later, the intervals when the clock was held low were caused by the polling I2C driver in the Tiva C MCU not starting the next byte of a transfer-in-progress right away. Each byte is transferred with perfect (hardware-controlled) timing, but since the TM4C123 hardware doesn't include a queue, software has to start each byte transfer (and my software was busy doing other things during those gaps). They didn't cause any trouble (they are far far shorter than any I2C bus timeouts), but did confuse me.

    Thanks, Chuck, for following up on this even though the problem was just me :)

    Steve