We are testing an I2C accelerometer connected to the ATMega32A micro-controller. The accelerometer was working fine. We can write and read the registers using I2C protocol. When connected to the oscilloscope, we find it very hard to decode the signals to normal value.

We are just writing a value 0x08 (00001000) into the register 0x10 (00010000).

As per the I2C protocol, after the start condition we have to write SLA+W (slave address + write command). The 8-bit slave address with write command for the accelerometer is 0x30 (00110000).

I2C data must be like this

0 0 1 1 0 0 0 0       0(ack)      0 0 0 1 0 0 0 0     0(ack)     0 0 0 0 1 0 0 0     0(ack)

0(ack) is the acknowledgement of the I2C slave (accelerometer). Yet the signal we got from the oscilloscope gives no clue

The clock and I2C settings are as follows

  • Controller clock: 4 MHz internal clock
  • I2C frequency: 100 kHz
  • Pull-up resistors: 4.7 kOhms

Here is the image of the I2C-clock (Yellow signal) and I2C-data (Blue signal) lines.

enter image description here

I really need someone's hand in it to help in decoding

  • 6
    \$\begingroup\$ 4MHz is a very fast I2C clock frequency. Your scope readings look like they're undersampled. Try slowing down your clock, at least as a debugging step \$\endgroup\$ – Scott Seidman Oct 15 '14 at 14:52
  • 7
    \$\begingroup\$ It's still true that the scope is not sampling fast enough for this task. Especially worrisome is the time relationship between channels - is that one ADC dividing its already insufficient sample rate (and thus introducing a sample worth of skew), or two ADCs at least taking their insufficient samples at about the same time? \$\endgroup\$ – Chris Stratton Oct 15 '14 at 15:08
  • 1
    \$\begingroup\$ The pull up resistors are obviously not good enough. Replace them with 2.2K resistors and retry and re-scope the data/lines. \$\endgroup\$ – KyranF Oct 15 '14 at 15:18
  • 1
    \$\begingroup\$ You really need to do another measurement but with good oscilloscope and probes. For instance I've made some measurement on a 100kHz I2C recently with a high-end oscilloscope, 500 MHz passives probes and a limiting bandwidth of 20 MHz and here is the result : toopix.eu/userfiles/5a718f0b27c2bfd2ffa02f54edc22cba.png (I was accessing a device at address 0x50) \$\endgroup\$ – zeqL Oct 15 '14 at 15:45
  • 4
    \$\begingroup\$ The overall consensus is - scope is bad/not set up correctly? \$\endgroup\$ – KyranF Oct 15 '14 at 15:51

Because I2C does not use a continuous clock, its always a little challenging to synchronize and capture a message, but it is do-able, and 100 Khz isn't an extreme rate. Now if you were developing a set of brand new I2C interface routines from scratch for a new library, you'd definitely want to slow down even further until the code was proven. If ou are using existing proven routines though, you may want to slow down anyway for now, because from the traces you've captured, I can tell you that these edges are terrible! I doubt any I2C receiver could decode a signal like that with any degree of reliability.

I'd like to hope, as others have suggested, that your scope sample rate is too low. But if each of those small "shelves" in the vertical lines are samples, then it looks like the signal slew rate itself is getting bogged down. In addition to slowing down the I2C clock, you may have to use stiffer pull up resistors, make sure to place them at every device along the chain, and sadly you may even have to re-examine your PCB traces. Are they long traces over a ground plane? Are there other sources of series resistance or shunt capacitance in these I2C lines?

Id take a look with a 100Mhz analog scope if you can, with X10 probes of course, if only to see if these edges are really as bad as they look, or just a trick of the scope. Do all you can to speed up these edges and figure out why they are so poorly defined. You really don't want to see any instances of non-flat peaks!

  • 4
    \$\begingroup\$ The visible problem is clearly with the scope, not the signal - this is not what electrical distortion looks like. Just rehashing the existing comments, with incorrect supposition on top, does not an answer make. \$\endgroup\$ – Chris Stratton Oct 16 '14 at 1:33
  • 1
    \$\begingroup\$ Clearly to you maybe, but you're dead wrong to suppose distortion doesn't look like this. The linear ramps, instead of the desired near vertical traces are indicative of slewing limitations, a form of distortion. And since I have indeed both used and developed I2C driver routines and successfully implemented them, what you're calling suppositions happen to be facts. I just hope your arrogance doesn't dissuade the person inquiring from a possible solution. Thinking someone else's experience brought to the table is incorrect when it conflicts your suppositions, does not an answer make either. \$\endgroup\$ – Randy Oct 16 '14 at 2:18
  • 2
    \$\begingroup\$ -1 no, the symmetric and asynchronous linear ramps are obviously indicative of a plotter connecting insufficient data points. Please stop trying to confuse the poster with wildly mistaken hypothesis in clear conflict with the evidence. \$\endgroup\$ – Chris Stratton Oct 16 '14 at 2:23

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.