Best device for debugging I2C issues?

[xtjacob]

I'm working on a project, and I seem to be running into some issues with my I2C sensors. I am using a raspberry pi to communicate with them, but I am getting some random I/O errors. After talking with a co-worker of mine he said I could be running into some signal integrity issues. I've been looking at a couple different options, and I think I've narrowed it down between the Rigol DS1054Z and the Saleae Logic 8. However, I'm not sure which would be better for the job. Would someone be able to direct me towards the best instrument (whether it's one of these or a different one)?

Thanks

[ogden]

I'm working on a project, and I seem to be running into some issues with my I2C sensors. I am using a raspberry pi to communicate with them, but I am getting some random I/O errors. After talking with a co-worker of mine he said I could be running into some signal integrity issues. I've been looking at a couple different options, and I think I've narrowed it down between the Rigol DS1054Z and the Saleae Logic 8. However, I'm not sure which would be better for the job. Would someone be able to direct me towards the best instrument (whether it's one of these or a different one)?

Definitely oscilloscope, preferably with I2C decode option is tool for the job - because you want to see signal waveform first. Most likely you know what you are sending over i2c, so decode is not that important actually.

IMHO logic analyzer is overhyped tool in amateur community. It's just *digital* 1's and 0's analyzer/decoder which you can use to analyze digital data w/o possibility to look at the electrical signal, its waveform. In case of bad signal integrity could be so that logic analyzer still shows everything OK while your device/sensor does not. Then what?

Only when you have complex bus like 12 I/O lines and you want to find some logic/timing glitch there - then you need logic analyzer. Obviously not Saleae Logic 8 with it's sorre 24MSPS. In short - better save money for the scope

Tell more about your i2c circuit. What are I2C pull-up resistors in your circuit? How long are i2c signal/ground traces/wires?

[rx8pilot]

Assuming you have already confirmed signal integrity with a scope....I sure get a lot of use out of my Total Phase Beagle side my side with a Bus Pirate. The Beagle allows you to record, filter, and analyze the data for extended periods of time. Scopes look at the signals and can decode/analyze relatively small chunks of data.

The Bus Pirate allows me to inject various bits and pieces of data to program parts or stimulate an action of some sort. I generally use a little GUI app that allows me to run scripts which is faster than the command line approach.
http://akb77.com/g/net/buspirate-console/

In the end, I have all the tools and use all the tools. In order of importance (to me)

• Scope to check the signals
• Beagle for data analysis
• Saleae of similar for timing

[mikeselectricstuff]

Definitely a scope with I2C decode, so you can see the whole picture.
Signal integrity problems with I2C only tend to happen when you take it off board and down wires, which I2C is simply not designed for and is highly likely to be unreliable.

[xtjacob]

Thanks everyone. My setup is over an 8-inch ribbon cable (way too long for my needs, I need a much shorter version) from my raspberry pi over to a perfboard with all my sensors. From the ribbon cable I have wires distributing the I2C pins over to my various sensors. I thought I had 2 pull up resistors, but it looks like I forgot to bridge the soldering pads for them.

Edit: It looks like the raspberry pi already has pull-up resistors build in on the I2C lines.

[maginnovision]

The raspberry pi also has a hardware bug with the I2C peripheral. Clock stretching can cause issues so if anything connected to your bus forces the pi to stretch be aware it likely will ignore it and corrupt the bus from then on.

[Fungus]

It's probably your pullup resistors, try smaller values. The default 4.7k in the original specification is rarely suitable in real life.

To see what effect pullups have on the signal you need an oscilloscope, A DS1054Z is plenty of oscilloscope for looking at I2C.

[ogden]

From the ribbon cable I have wires distributing the I2C pins over to my various sensors.

So 8 inches ribbon + how long distribution wires/leads?

While you don't have instrument to look at the signal - try lowering i2c speed, like 10x times. As already mentioned here, try lowering pull-up downto 1KOhm.

[David Hess]

A DSO with I2C decoding can provide both signal integrity analysis and basic protocol decoding.

[xtjacob]

Thanks for the advice guys, I ordered the O-scope. It'll be a nice upgrade from my all-analog 25 MHz one.

I'll give the resistors a try. One of the odd things was I didn't have problems when using a realtime kernel (but I had problems with the pi freezing up due to an unrelated bug). When I switched back to the regular kernel all the problems started appearing. So maybe I need to recompile my own rt kernel with the bug fix, and figure out what's going on with my I2C signals.

[Rob_R]

My little Saleae logic 8 (Cypress chipset  types) have one almost unbeatable feature when used with sigrok/pulseview ...

they can capture extremely long sequences using the PC memory , rather than a small intrinsic capture buffer ,such as my Zeroplus has.

Rob.

[rrinker]

Definitely a scope with I2C decode, so you can see the whole picture.
Signal integrity problems with I2C only tend to happen when you take it off board and down wires, which I2C is simply not designed for and is highly likely to be unreliable.

 And I have people constantly asking me why I am using RS485 between boards which will be several FEET apart in a relatively noisy environment, instead of just using I2C.  DOH.

[maginnovision]

An RPi has 1.8k pull-up resistors they shouldn't be a problem.

[Fungus]

An RPi has 1.8k pull-up resistors they shouldn't be a problem.

Famous last words.

For longer wires you might need pullups on both ends.

I'll give the resistors a try. One of the odd things was I didn't have problems when using a realtime kernel (but I had problems with the pi freezing up due to an unrelated bug).

OTOH it might be software.

[ogden]

My little Saleae logic 8 (Cypress chipset  types) have one almost unbeatable feature when used with sigrok/pulseview ...
they can capture extremely long sequences using the PC memory , rather than a small intrinsic capture buffer ,such as my Zeroplus has.

Indeed logic analyzer have it's place in your lab, it is useful tool - if you are searching small glitch in the pile of bits. Anyway it does not replace scope and shall be purchased after scope, not before

[maginnovision]

An RPi has 1.8k pull-up resistors they shouldn't be a problem.

Famous last words.

For longer wires you might need pullups on both ends.

I'll give the resistors a try. One of the odd things was I didn't have problems when using a realtime kernel (but I had problems with the pi freezing up due to an unrelated bug).

OTOH it might be software.

From experience with the pi in noisy environments(brushed and brushless motors, rotating magnetic fields) at 8 inches the included resistors are usually fine if the hardware bugs don't cause you issues.

[ogden]

From experience with the pi in noisy environments(brushed and brushless motors, rotating magnetic fields) at 8 inches the included resistors are usually fine if the hardware bugs don't cause you issues.

Two more cents: ground noise can be to blame if controller (rPI) and sensors are powered by different supplies and/or ground is not "solid enough".

[David Hess]

Definitely a scope with I2C decode, so you can see the whole picture.
Signal integrity problems with I2C only tend to happen when you take it off board and down wires, which I2C is simply not designed for and is highly likely to be unreliable.

And I have people constantly asking me why I am using RS485 between boards which will be several FEET apart in a relatively noisy environment, instead of just using I2C.  DOH.

Usually you can get by with a terminated single ended pair where the single ended driver drives one wire and the other wire is the singled ended driver's ground.  Then a differential line receiver is used at the receiving end.  This saves needing a special driver as just a logic gate can be used.  The differential line receiver also allows the signal to be double terminated.

Another trickier way to do it involves a gate output driving a bipolar transistor to make a current source to drive the transmission line.  Then the ground termination on the receiver end rejects ground noise.