• AVR Freaks

Hot!MCP9600 I2C clock stretching problem with multiple hosts

Author
guarndt
New Member
  • Total Posts : 5
  • Reward points : 0
  • Joined: 2019/06/18 08:30:17
  • Location: 0
  • Status: offline
2019/06/19 06:55:20 (permalink)
0

MCP9600 I2C clock stretching problem with multiple hosts

Dear friends, I have been evaluating the MCP9600 thermocouple temperature converter with different hosts - to be precise, the MikroE  Thermo K click, which is an implementation of the reference design in the MCP9600's data sheet: https://www.mikroe.com/thermo-k-click
To read a measurement from it, the host checks in the status register 0x04 if one is available, and in that case sets the read pointer to 0x00, in order to read six bytes (2 for hot junction, difference, and cold junction, respectively).
 
It works fine and yields very precise and reliable measurements when I use it with the Sitec S4 as a host:

As suggested by the MCP9600's data sheet, there is a clock stretch at the end of each data byte.
But with any other host I have tested, there seem to be problems with the I2C clock stretching, which means that some of the clock stretches do not occur. In that case, the previous byte is just repeated, instead of transmitting the next one.
I'll add details, but I'm encountering technical difficulties posting here.

Attached Image(s)

#1

5 Replies Related Threads

    guarndt
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2019/06/18 08:30:17
    • Location: 0
    • Status: offline
    Re: MCP9600 I2C clock stretching problem with multiple hosts 2019/06/26 00:21:56 (permalink)
    0
    More information: With a BeagleBone Black as the host, it looks like this:

    #2
    guarndt
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2019/06/18 08:30:17
    • Location: 0
    • Status: offline
    Re: MCP9600 I2C clock stretching problem with multiple hosts 2019/06/26 00:24:35 (permalink)
    0
    The same applies to the Odroid C2 as the host:

    Note the different low level voltages; they are within the I2C's tolerance. The lower one, however, seems to be caused by the MCP9600, and the higher one by the Odroid C2.
    #3
    guarndt
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2019/06/18 08:30:17
    • Location: 0
    • Status: offline
    Re: MCP9600 I2C clock stretching problem with multiple hosts 2019/06/26 00:30:30 (permalink)
    0
    It is not surprising the Raspberry Pi 3 has the same issue, as it is known not to support clock stretching:

     
    I tried to use software-emulated I2C on the Raspi with the i2c-gpio overlay; interestingly, it behaves identically.
    post edited by guarndt - 2019/06/26 05:58:36
    #4
    guarndt
    New Member
    • Total Posts : 5
    • Reward points : 0
    • Joined: 2019/06/18 08:30:17
    • Location: 0
    • Status: offline
    Re: MCP9600 I2C clock stretching problem with multiple hosts 2019/06/26 00:33:25 (permalink)
    0
    In very rare instances, it works properly even with the Raspi:

     
    Conclusion: Clock stretching should occur after every byte (SCL low for a prolongated period), but doesn't.
    What could I do about this? And which device to blame - the respective host, or the MCP9600?
    post edited by guarndt - 2019/06/26 04:21:09
    #5
    billyjake
    New Member
    • Total Posts : 1
    • Reward points : 0
    • Joined: 2019/11/05 10:46:41
    • Location: 0
    • Status: offline
    Re: MCP9600 I2C clock stretching problem with multiple hosts 2019/11/05 12:00:33 (permalink)
    0
    guarndt,
    Thank you very much for an extremely detailed posting!
    I'm trying to get this same MCP9600 chip to work with Raspberry Pi 3B+ and having the same issue.
     
    I tried lowering the SCL rate like you did and also found that it lowers the repeated byte instances, but doesn't eliminate them.  I lowered the data rate from 100kHz default to 10kHz with this line in my /boot/config.txt file:
        dtparam=i2c_arm=on,i2c_arm_baudrate=10000
     
    Like you, I tried the i2c-gpio overlay.  And like you, it didn't work.  But then I tried the i2c-gpio overlay and lowered the SCL rate to 10kHz with this line in my /boot/config.txt file:
        dtoverlay=i2c-gpio,i2c_gpio_sda=2,i2c_gpio_scl=3,i2c_gpio_delay_us=20
    (The last parameter, "i2c_gpio_delay_us=20" is what lowers the effective SCL rate to approx 10kHz.
    The default setting is 2 microseconds, which gives approximately 100kHz SCL rate.)
     
    This works for me!  Consistently.  So I can live with the MCP9600 chip for now because it lets me have up to 8 thermocouples on one I2C bus and lets me choose what alloy type they are (K, E, etc).  It's interesting to watch the scope trace for a while to see when the clock stretches occur.
    #6
    Jump to:
    © 2019 APG vNext Commercial Version 4.5