1
\$\begingroup\$

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!

| improve this question | |
\$\endgroup\$
  • \$\begingroup\$ I think we need to see real oscilloscope traces. There are two many subtle problems that a logic analyzer will miss. \$\endgroup\$ – Joe Hass Jan 13 '14 at 18:42
3
\$\begingroup\$

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.)

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ So you are saying I should simply acquire data on each rising edge of the clock and ignore the falling edge overlap since its not an issue? (Sorry if that's a silly question, I'm pretty new to serial protocols. I recall reading that the data needs to be consistent across the entire clock in the specifications so what I have implemented in the master is probably wrong.) \$\endgroup\$ – MrHappyAsthma Jan 13 '14 at 17:59
  • \$\begingroup\$ It could also be a difference in the pull-up resistors on the SDA line. You don't see that on a logic analyzer. \$\endgroup\$ – Tom L. Jan 13 '14 at 18:00
  • 1
    \$\begingroup\$ @MrHappyAsthma: Yes, that's correct. In fact, if you have a mix of different-speed devices, you may need to allow for "clock stretching" in your master. Clock stretching is when a slave holds the SCL line low until it is ready to act on the current data bit. In your master, you need to stop driving the SCL line low, then poll it until it actually goes high, and then sample the SDA line. \$\endgroup\$ – Dave Tweed Jan 13 '14 at 18:23
  • \$\begingroup\$ "the only thing that matters is whether or not the SDA line is still low on the next rising edge of SCL" Are you sure? It seems to me I2C is designed to be possibly implemented with latches as the sampling element rather than flip-flops, and SDA switching prematurely (before the SCL falling edge) could result in latching in the wrong data. \$\endgroup\$ – The Photon Jan 13 '14 at 18:33
  • \$\begingroup\$ @ThePhoton You are correct, sir. From the NXP I2C spec: "The data on the SDA line must be stable during the HIGH period of the clock. The HIGH or LOW state of the data line can only change when the clock signal on the SCL line is LOW" Transitions on SDA when the clock is high are used as the special START and STOP conditions. \$\endgroup\$ – Joe Hass Jan 13 '14 at 18:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.