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?
Thanks!
-josh
{“Environment”:“production”,“Branch”:“master”,“Commit”:“dbca5b914ee1b56c9de43e47790fdd08700223cc”,“Version”:“2.4.7”,“AutomationVersion”:“1.0.0”,“MachineID”:“f8947bbe-2db9-4e33-a9ca-c3b581c2fcef”,“PID”:54324,“LaunchId”:“93d4180e-737f-473a-9f01-dd18c9f553de”}
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.
Thanks!
@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.
1 Like
