• 0
Andras

Logic Analyzer: debugging I2C on Raspberry Pi

Question

Posted (edited)

Hi @attila,

I started to play around with the logic analyzer and I got a few questions.

I'm working with a Raspberry Pi 3 B and my goal is to communicate with multiple ADS1115 ADCs on the I2C bus.

I have a Python script that demonstrates reading the ADC values and I would like to write a .NET Core 3.0 C# application running on the Pi to do the same.

Something isn't right just yet and I used WaveForms v3.11.5's Logic Analyzer with AD2 to see what's going on. I connected the SCL and SDA to the digital inputs #0 and #1.

IMG_20190514_080147_web.thumb.jpg.4428fa5ecdf28b1176ed44c579b52d49.jpg

The Raspberry Pi's I2C bus runs at 100 kHz as far as I know, so I had the following settings:

image.png.0b5a3e23bd93aa8ea150ed28970ec9de.png

I selected to have a I2C protocol and I wanted to catch a few Start - Stop packets:

image.png.228ba381f7c9c1cf9ebdc977c63b44fb.png

The address of the ADS1115 is 0x48, but it's not that relevant here.

Even if neither the script nor the app are running, when I click on the "Single" button in WaveForms the capture session it runs and stops immediately. When I examine the 10 buffers they all show only unrecognized "ERROR" chunks, none of them has I2C "START" events that could have triggered the capture.

image.thumb.png.06cbfcb06347ff421c861ac17e78df1e.png

Is this the expected behavior? If yes, can I set the trigger somehow to capture only the valid packets between START - STOP events (and ignore ERRORs)?

 

The "Address & Data" trigger works fine, it stays in "Armed" state until I send a packet with the predefined address.

In this case my experience was that even if I set the buffer value to #1 it records the packet into the buffer #2. It's not a big deal, I'm just curios if that's intentional.

The scroll bar above the signals also acts a little strange: if I scroll either way I don't see any new data, just blank spaces left or right of the captured signals.

Also, if I see "ERROR" could you tell a little more about the nature of that error? I get that a lot, and I'm not sure if my SCL, SDA line are too noisy or the clock isn't stable enough or I set the rate wrong or I send an invalid packet?

 

Thanks,

Andras

Edited by Andras
Added a photo of the connections

Share this post


Link to post
Share on other sites

4 answers to this question

Recommended Posts

  • 1

Szia @Andras

You need higher sample rate, more than twice of the signal toggle rate in order the interpreter to decode correctly the I2C.

You can use Record to capture more data like 400kHz for 100kHz I2C:
image.png.cb6d1cdb697b2c7b6a61b3909207799f.png

 

You can also use the Protocol/I2C/Spy in case you are not interested in timing, you only need the decoded data.

image.png.a286a1642439677491b86ebc19795ece.png

Share this post


Link to post
Share on other sites
  • 1

For the Protocol / SPI-I2C /Spy mode you should specify the approximate (or highest) protocol frequency which will be used to filter transient glitches, like ringing on clock signal transition.

The Errors you get indicate the signals are not correctly captured.
- make sure to have proper grounding between the devices/circuits
- use twisted wires (signal/ground) to reduce EMI
- use logic analyzer and/or scope to verify the captured data / voltage levels at higher sample rate at least 10x the protocol frequency

Like here in the Logic Analyzer you can see a case when the samples are noisy:image.thumb.png.8e185dbf7b244047520c1f630becc8f2.png
 

Share this post


Link to post
Share on other sites
  • 0

Szia @attila,

This Protocol Spy looks like a lot of fun :)

Still I got errors and lost samples even at higher capture sample rates. Some packets are recognized properly though.

Should the sampling frequency be exactly 4 times the baud rate?

What does the "error" exactly mean in this context?

image.thumb.png.deb4a0567393687dd5d2db509aacd4b5.png

Do you have a guess what can I do wrong?

 

 

Share this post


Link to post
Share on other sites
  • 0

Szia @attila,

 

Thank you for the tips, I finally could find the problem.

It's very likely that Adafruit's ADS1115 is faulty and messes up the I2C line. I could use the Logic Analyzer's Record function to make some tests, and here you can see the difference between the two cases when the ADS1115 is first not connected:

image.thumb.png.63ea222d886a8c710b8dc2c0ef685a5f.png

The correct sequence of events coming from the Pi: START + h48 WR + NAK + STOP.

After connecting the ADS1115 there are spikes on both the data and the clock lines. You can see the spike on the data line here:

image.thumb.png.a499d2eaf03be8242d0967f025511c5d.png

And because of this, the sequence ends prematurely. Sometimes it's still ok, but sometimes it results an error.

The ADC still works, but it clutters the bus so much that theoretical 100'000 baudrate is impossible to reach, I could get it to around 45'000.

 

Thanks again,

Andras

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now