I am using the Logic analyzer Pro16 to troubleshoot I2C packets between a single master and a slave device and having been struggling to get consistent reading for many hours. I have now narrowed it down to the Pro 16.
Until today I have used the Saleae as my arbiter of truth for troubleshooting communications signals but unfortunately on this occasion my trust has cost me.
In my test scenario, the master simply reads data from a single slave. In the slave device I hard codded “Hello” to be sent back to the master on request. I then continued to monitor the bus using my pro 16 which sometimes you see the correct data over the bus and then sometimes you see corrupted data.
My initial instinct was query the slave device as I wrote this slave firmware running on ATtiny816. I also did not pay much attention to the master as I never had to doubt what Saleae displayed.
After finally convincing myself that the slave is doing the right thing. I then decided to print the data that master was receiving and at it was at this point that I noticed that every time the master got the correct message and printed “Hello” even when Saleae is showing that the data is incorrect.
I am hoping that is simply a firmware bug within the latest update as I don’t want to loose my trust my Saleae pro 16 which as it has become my most trusted tool in my debugging toolbox.
===== Example of data from terminal====
write to 0x53 ack data: 0x00
read to 0x69 nak
0x24 0x32
0x36 0x36 0x37
write to 0x53 ack data: 0x00
read to 0x53 ack data: 0x48 0x65 0x6C 0x6C 0x6F
write to 0x53 ack data: 0x00
read to 0x53 ack data: 0x48 0x65 0x6C 0x6C 0x6F
write to 0x53 ack data: 0x00
read to 0x69 nak
0x24 0x32
0x36 0x36 0x37
write to 0x53 ack data: 0x00
read to 0x53 ack data: 0x48 0x65 0x6C 0x6C 0x6F
Could this be glitches on the clock line due to slow signal rise/fall times? Turning the glitch filter on and set to somewhere around 1us may help.
I often check lower speed signals using the analog input turned on with the digital input. The analog input signal is filtered so won’t show high frequency noise, but gives a good idea of the actual rise and fall times. Rise times in particular can be a problem with I2C if pull up resistors aren’t strong enough for the bus length and clock rate.
Hi @oniola, sorry to hear that. I think @P.Jaquiery brings up a great point. We talk a bit about this common issue in the support article below, under the section titled “Common Issus with Noise Around Clock Edges,” with reference to a workaround via enabling our glitch filter.
If that doesn’t help, feel free to send over your capture file (in .sal file format) and we can help look into this for you.
Thank you @P.Jaquiery and @timreyes for your reply. I will do further investigation and report back. Since I discovered that the i2c master device was receiving the correct data sent by the slave I moved on with the project as I lost a considerable amount of time debugging the i2c bus.
I will definitively come back and setup the same scenario so I can restore my trust in my Saleae Pro 16 which as I mentioned before is my most preferred debugging tool.
I will also have a read of the I2C Analyzer - User Guide to see if the error that was occurring was due to my incorrect use of the Saleae Pro 16. And that I might have just been very lucky to have never seen this issue in the past.
Concerning the glitch filter that @P.Jaquiery mentioned I have used this in the past for filtering noise on the bus but on this occasion did not work.
I have attached the Sal file as I saved it as I thought it might be requested for.
At 3.7900374 there is an 8ns wide glitch on the clock line. You will need to zoom to 20us per 100 pix to see it.
A heads up is that there is an up arrow on the first falling clock edge of the transfer rather than on the first rising edge. You need to zoom in to about 50us per 100 pix to see the sample edge arrows. That first edge also looks fat compared to the other edges.
Thanks @P.Jaquiery for taking a look at the capture file. Yes indeed I can see the 8ns glitch. Looking back on my screen I noticed that I forgot to add glitch filter settings to the SCL line but only added to the 1us to SDA line.
Do you know if is possible to replay captured waveform with the SCL filter turned on and see if that would affect the readings much? I have tried I can’t find a way to do it.
Regarding the “up arrow on the first falling clock edge” I can not see it. I have zoomed it as much as the application allows me and I can’t see.
Any I will keep an eye should I see any further reading when I hook back the Pro 16 on the I2C bus.
Once again many thanks for looking at this.
To the best of my knowledge it isn’t possible to turn on glitch detection after the capture has been made. The glitch filter is in the hardware - which makes sense because glitches can generate a lot of edges and removing those in the hardware helps reduce data rate and data processing. @timreyes it would be really nice to be able to post process a capture with glitch filtering on!
I have learned after multiple frustrating sessions with I2C and similar things that glitches and bad grounding are often the actual culprits when things look bad! I very often turn on the analog channel as well as the digital channel for an input to get a better picture of what’s going on. With I2C and SPI you can often see small voltage differences in the signal that are generated by different devices so it is possible to tell which specific device, or devices, are driving the bus at any particular moment. This can be very useful to determine when a device drives an ACK/NAK in I2C for example!
Oh, and I don’t glitch filter SDA because noise on the data edges usually doesn’t matter. Glitches on SCL however are critical.
I absolutely agree with you! Personally, it’s frustrating not being able to apply a glitch filter after the capture, and being forced to take a brand new capture (lot of set up involved if everything is not already hooked up properly for another quick capture).
I’ve added another comment in the feature request post below that links back to this forum post so we can keep track of this request.
As a quick note, Mark summarized some of the challenges with implementing an “after-capture” glitch filter. It’s certainly doable, but not something we can prioritize at the moment, given the scope of the project.
