Hi, I think the i2c analyzer has trouble recognizing the repeated start condition.
100ns glitch filter is enabled on both channels, because I have weird fast signal toggles before the communication start.
I2C-rep-start.sal (112.6 KB)
Thanks for reporting this. This is certainly strange. On my initial review, I can’t find anything obvious in your capture that would cause that to happen. There also seem to be 948ns pulses still present even after your glitch filter. I don’t expect those are causing any issues though. The data seems to start getting offset (time wise) after the 2nd frame (0x28 + ACK). I’ll have to dive into the I2C source code to see what it could be expecting from your data.
In the meantime, what happens when you take a new capture with a glitch filter > 948ns (to get rid of those pulses)?
Thanks for the answer. I don’t believe I should be filtering out the 948-ns pulses. They occur after the slave sends ACK bit, and releases the bus on falling clock edge, but before the master claims the bus again. The analyzer goes out of sync after the second byte on the bus, and starts interpreting the bytes at the wrong point, that’s why the 948-ns pulses seem to be in the middle of a byte, but they are not. They are always after the ACK bit (or before if ACK is sent by the master), so thay are perfectly normal and shouldn’t be filtered out.
1 Like
I agree with @kazink’s analysis. I2C often shows glitch like pulses during hand off from slave to master, or master to slave during ack processing.
The other thing of passing interest, just to note and eliminate as an issue, are the different 0 levels. I’m betting @kazink has a level shifting buffer or bus isolator between master and slave that account for those level changes. They can be really useful to get a handle on which end is driving the bus. You will note that there is a baseline adjustment associated with each “glitch” implying a hand off from one end to the other.
1 Like
I have a multiplexer because I need to talk to several slaves with the same address. And yes, these zero-level differences make it easy to tell who is driving the bus at what point. I measure the signal at the slave, so it’s natural the lower zero level comes from the slave device.
Hi @kazink, we re-reviewed your i2c capture to try and find more clues as to why it was failing.
We might be on to something. In short, SDA should not change state if SCL is high in the middle of a byte, as this indicates a start condition (the green circle in the capture). This seems to happen multiple times, which I believe is causing the I2C analyzer to become offset with your data over time.
SDA and SCL shouldn’t be transitioning at the same time, but instead, SDA should transition in the middle of the SCL low period.
I’ll need to double check this again, but I believe this could be the cause of the decode errors.
Then perhaps there is something wrong with the physical analyzer, because for every green dot the analog channels show SDA falling edge slightly after the SCL falling edge. But on the digital channels SDA falls before SCL, that’s why it is interpreted wrongly.
@kazink You’re right about that. They’re essentially falling at almost the same time. The digital channel will interpret the time of the transition based on whether the threshold has been crossed, which will vary from channel to channel with some amount of error. This is most likely the cause of the digital edges seemingly falling at slightly different times than what is shown in the analog capture.
Since our I2C analyzer only looks at the digital channels, it will interpret it based on the order of the SDA/SCL transitions it is given. For example, a high-to-low transition on the SDA line while the SCL is high would be defined a START condition without any wiggle room. Therefore, our analyzer is unfortunately not suited to decode data when the transitions occur at the same time.
My initial thought was that I2C master modules would generally not be allowed to transition edges at the same time due to the misinterpretations it could cause with slave devices. Apologies in advance if we’ve misunderstood that part of the spec. If this is a common operation mode in I2C, then we’ll need to update the behavior of our I2C analyzer to accomodate that.
No need to apologize for anything. We are here to find a solution, not to find the guilty person 
From the zero-level analog level of the SDA line (as described by P.Jaquiery) I can see it is always the slave - not master - who is pulling the SDA right at the SCL falling edge. More precisely 25-30ns after, which I think is quite strange as the slave should detect the falling edge of SCL and drive SDA after that. There is no way a common chip could react to a clock edge that fast. It seems like this slave has its own clock that synchronizes with the master, and drives SDA exactly on the falling SCL edges. All green dots from the third one on are caused by just that - the slave driving SDA slightly after the clock edge and analyzer’s digital part misinterpreting it as occuring before the clock edge.
Now the question is what to do with it. I don’t need this any more now, because I have already solved the problem I was analyzing. But the slave is not my custom thing, it’s a common chip - LIS3DH - accelerometer chip from ST, so this problem may occur for more people in the future. Making the analyzer ignoring the edge order would not be good, because it would not detect potentially erroneous bus signals. In my case perhaps swapping the analyzer inputs would help, if I knew then what the problem was. How about making the analyzer detecting simultaneous (with a margin) transitions on both lines and warning the user that this could cause problems (in the analyzer as in my case, or in the device’s operation if the master drives the lines that way)?
1 Like
@kazink Good point on below.
There is no way a common chip could react to a clock edge that fast. It seems like this slave has its own clock that synchronizes with the master, and drives SDA exactly on the falling SCL edges.
We’ll have to consider updating our I2C analyzer to support this, especially since LIS3DH is a fairly common part. I’ll put this on our backlog to review. It’s likely I’ll get this added as an Issue in the github repo for the I2C analyzer for now (i.e. adding support for simultaneous transitions).
1 Like
I see from the data sheet that the minimum “SDA data hold time” (the parameter specifying that delay) has a minimum value of 0! So a few tens of nanoseconds is within spec and well within timing jitter due to things like noise affecting the level detection threshold for signals that are usually measured in microseconds…
1 Like
Thank you @timreyes and @P.Jaquiery
This thread is a couple years old so please excuse the bump; I’ve just run into another case of the i2c analyzer not recognizing an extremely brief Repeated Start state on the bus with Logic 2.4.9. Either I use glitch filtering to completely filter out that state, and “READ” addresses show up as “data” with a NAK, or I disable it and that glitch knocks everything downstream of it out of phase by one clock pulse.
Knowing this, I can interpret the results correctly, but it’s still a bit confusing to see in the display.
Here’s a screen shot:
(Yeah, there’s a ton of parasitic capacitance/inductance on the line, but the device behaves correctly)
That tiny SCL high pulse while SDA is high is a Repeated Start state and not the start of a byte. Knowing that, the rest of that burst (pictured below) is correctly interpreted as:
(RS) 0 0 1 1 1 0 0 1 R (A), the correct interpretation (a read to address 0x39).
I hope this can be addressed.
Complete Logic build info:
{“Environment”:“production”,“Branch”:“master”,“Commit”:“05ae03a49b520156f8d69106363edc34355c2362”,“Version”:“2.4.9”,“AutomationVersion”:“1.0.0”,“MachineID”:“d98ac8a1-957d-407d-b007-c51a439c554e”,“PID”:14332,“LaunchId”:“5eacde48-b3da-40c2-80cc-0aa0b3806280”,“Architecture”:“x64”}
@lotharyx It’s been quite some time since I looked into this. At first glance, I suspect a few things at play.
I don’t immediately remember the conditions for a Repeated Start condition, but it looks like we haven’t provided support for this as per the Open GitHub Issue Post below. I suspect this might be causing the issue on your side with not recognizing the Repeated Start event.
We also have several internal hardware / software filters in place that could cause small glitches to be visible on digital channels but not on analog channels like you’ve shown in your first screenshot. We describe this behavior below.
However, the parasitic capacitance effect does look quite strong as shown in your second screenshot. If you send me your capture file (in .sal file format), I’d be happy to take a closer look at these issues.