I am capturing a simple, clean, and slow i2c and Logic seems to be decoding it incorrectly. Here is what the decoder is showing me…
If you look at the 2nd byte, it is decoding as “0x07” but if you look at the waveform it seems to be 00001101=0x0D (which is the expected value).
My scope seems to be decoding the same waveform correctly…
Any ideas what could be going on?
Also, I thought there used to be little up arrows on the rising clock edges, right?
Session 0.sal (35.1 KB)
OK, I think I found it!
Looks like there is a 20ns glitch on the clock like at bit #2…
I do not think there is any way to see that without zooming all the way in on every bit. Would be nice if there was some visual indication of an extra transition in cases like this. Note that glitch filter was on during this capture.
@salfrm4 Glad you found the glitch! What value did you have the glitch filter set to? If it was enabled, but set to a value less than 20 ns (or if a value wasn’t set at all), then that may exlpain why the 20 ns glitch/pulse you show in your screenshot wasn’t filtered properly. A glitch filter set to around 200 ns may be needed.
Also, you’re right about the glitches being difficult to see when zoomed out. From my recollection, I believe the edges will be a bit thicker when multiple transitions occur at that time point. We may want to consider making it more visible (either via thickness, color adjustment, etc). We’ll take note of this feedback!
Actually in the screen shot you posted there are some anomalously bright clock edges. That is pretty much always a heads up for places to look when clocked signals are not being analysed correctly.
HLA tools like Pulse Stats can be useful for finding unexpected pulse widths quickly.
I think those thick edges are an artifact of the image scaling on this webpage. If you click in to the original, I do not think there are any visual cues on the glitched edge. You have to zoom way in while inside Logic to see anything different visually.
Maybe Logic could show up arrows on the significant edges, and arrows are to close together to resolve at current zoom level, then show maybe an arrow with a number indicating how many arrows are really there? Even double width or dotted or color highlighted lines when there is more than one edge per pixel would be helpful. Thanks!!
Here is a magnified view of the pixels- the middle edge is the glitched one…
You have to zoom in a couple of orders of magnitude before the line appears 2 pixels thick…
…which is not practical when you do not know which edge (or if any edge) is glitched!
You may well be right about the thick edges in the browser image, but that is very much what I frequently see on my PC when there are glitched edges. That’s probably due to the same sort of drawing artifacts that we get rendering pretty much any image at a lower resolution.
Edge glitches is an issue that comes up here a LOT! Highlighting pixels which contain more than one edge could be a major help, and not just for this issue.
@salfrm4 After testing your capture file again, you’re right about the edge thickness around the glitch not being any thicker than normal. The glitch was very difficult to find, so you’re feedback makes a lot of sense! I’ll makes sure this feedback gets reviewed by our team here.
I have the same problem, attached is an example. It says the decoded address is 0x47, but it is clearly 0x4e. I set a marker where the glitch is. Attached is the file.
Recorded with an original Logic Pro 8, which I bought a few days ago. Technically this is not a glitch of the input signal. I guess the digital inputs don’t have schmitt triggers, or is it possible to enable this? This would be a major product bug, if they wouldn’t have schmitt triggers, my logic analyzer of my oscilloscope detects it also right. Is it possible to enable schmitt trigger at the inputs?
Setting the glitch filter also didn’t help. How can I set the length of the glitch filter? I saw only a switch to turn it on or off.
A workaround is to set the digital sampling rate to 6.25 MS/s, and enable the glitch filter. But then the Analog sample rate is limited to 1.5625 MS/s, which doesn’t allow a nice resolution of the signals. Why can’t I change both sample rates independently? Just skip every x’th sample, if you have to lock it physically.
PS: I’m a FPGA programmer, if you need help
i2c.sal (107.7 KB)
@fb1 Thanks for sending over your capture file. Yes, the glitch looks like the cause of the decoding issue (our I2C analyzer is registering 2 clock cycles instead of just 1 at that point).
For the digital inputs’ voltage threshold on our Logic Pro devices, we use comparators without (or very little) hysteresis. Because of this, recording I2C using our Logic Pro devices are particularly vulnerable to recording glitches at the clock or data line edges due to the slow rise times caused by the open drain bus topology. The relatively slow signal rise time through the threshold region of the logic analyzer input buffer can sometimes cause these glitches to occur.
Once you enable the Glitch Filter switch, there should be input boxes for each enabled digital channel underneath that will allow you to set the glitch filter width. More information on this can be found below:
Ok, a glitch filter of 1 us helped, I don’t see any problems for I2C anymore. Of course, this is only a workaround, and wouldn’t work for very slow edges, and now I don’t see real glitches anymore which might be caused by the circuit itself. So a hysteresis for the comparators would be best.
Is it possible to change the comparators and add an external hysteresis? Usually this can be done with just one resistor from the output to the input, which might be already there for frequency compensation, but I haven’t opened it so far. If they are like TQFP parts, I can solder this (I would risk my warranty for it), but of course, would be impossible or very difficult for BGAs.
@fb1 Glad to hear the glitch filter ended up helping out. Unfortunately, we can’t provide recommendations for making changes to the components on the PCB of our products.
In case you want to give it a try, the part number we use today is ADCMP600BKSZ-REEL7. You can’t miss it on the PCB, there are 16 of them arranged near the inputs. Also, if you damage your unit in the process, or if it breaks later, we’ll still cover it under the warranty - you will just need to reference this message .
The hysteresis on that part is only 2mV, hence the problem. The part is downstream of a voltage divider, so the effective hysteresis at the input is larger than that, but not by a lot.
If you get it working please let me know! I’d love to hear about it.
Our longer term plan is to build the glitch filter functionality into the I2C analyzer as a new setting (and potentially other analyzers as well). That way we won’t need to filter the data you record. Instead the analyzer will just ignore glitches, and we can enable it by default.
Thanks, I give it a try. Looks like an easy solution is to just replace it with ADCMP601, I ordered a few at Digikey, and like a 82k resistor for about 100 mV hysteresis, which I can solder by hand on top of it, and which should be perfect for all applications. The screws look odd, what tool do I need to open it?
@fb1 A T6 torx screwdriver will do the trick!
Thanks, found one for it. The parts are easy to find and to de-solder, I marked them with blue dots.
Will get the new comparators next week.
Wow those are some great board photos, could you tell me about the setup you use for that?
I used my Tagarno Trend electronic microscope with it, with additional polarization filter which helps to read the IC markings better. It is also really nice for soldering small SMD parts, I use it often, because it has a no-lag realtime HDMI output.