Electronic – I2C slave not pulling down SDA data line for the full clock cycle

clocki2c

I am communicating with some slave devices via multiple busses, however even though they are all the same device (http://www.invensense.com/mems/gyro/mpu3050.html) and all receive the same message/clock from the master, they don't hold the SDA line down for the same amount of time:

Devices

If you notice, devices 1 and 3 do not pull down for the same length of time as devices 2 and 4. However they are all the same type of device receiving the same messages from the master.

In this instance, devices 1 and 3 are causing problems because their changing from low to high (due to not holding the line low for long enough time) on the same clock cycle which should not happen during slave ACK or slave data sending:

Issues

The device I am using to send and capture these signals (simultaneously) is a National Instruments PXI device that oversamples at 1 MHz which should be plenty so I don't think its simply a display issue.

I thought it could be a timing issue of some sort, but per the MPU-3050 device specifications on page 16, it adhears to I2C FAST-MODE:

timing

My current timing parameters are much slower than that so they should be valid inputs:

tSU;STA - 4700 ns
tHD;STA - 4000 ns
tSU;DAT - 1000 ns
tHD;DAT - 4000 ns
tSU;STO - 4000 ns
tBUF - 4700 ns
tHIGH - 4000 ns
fSCL - 80 kHz

My only real requirement is I need the device to ALSO satisfy the STANDARD-MODE specifications for I2C (as my above ones do) because I plan to add more devices to these busses that won't allow FAST-MODE.

I really have no idea of what could be happening here, so its possible its not even a timing issue at all. I've tried some "trial-error" stuff with the timing, but similar behavior always occurs. If you have any ideas as to how I could try to fix this, please let me know!

Best Answer

The variation in delay you're seeing is immaterial. I2C is a synchronous protocol, so the only thing that matters is whether or not the SDA line is still low on the next rising edge of SCL. As you can see in your first diagram, they all pull SDA low before that happens, so they are behaving correctly.

If this is causing problems on your I2C master, then it is implemented incorrectly.

In fact, the rising edges you've circled are caused when the master stops driving the SDA low itself, and have nothing to do with the slave devices' activity. They haven't yet driven the line at all.

(The timing variation you see is probably due to the asynchronous nature of your logic analyzer's sampling.)

Related Topic