kostka
February 15, 2022, 9:33pm
1
I have two I2C transactions. The first one reads 1 byte and the second reads 2 bytes, both from the same slave.
The first transaction looks and is interpreted correctly (read from 0x40 + ACK)
The second transaction is interpreted as a (write to 0x40 + NACK), despite the waveform for the first 9 bits being identical to the first transaction.
Is this a (rather large) bug or am I missing something?
Just for clarity, I’ve rearranged the waveforms so you can see the first 9 bits are identical. I’ve included the analog trace above so you can see there are no glitches on the line.
kostka
February 15, 2022, 10:28pm
2
Looks like there is a toggle on the SCL line which explains it. I guess the relatively slow rise time causes it. Reducing sample time fixes it.
Perhaps I2C should filter out glitches at 60MHZ, perhaps not.
It is very repeatable, which seems odd to me. In a string of 4 transactions, this always happens on the second one.
You should turn on the glitch filter for I2C (and SPI etc) clock channels.
Note that your analog sampling speed isn’t fast enough to show the noise on the signal that is causing the logic analyser to see the glitches.
@kostka Sorry about that. @P.Jaquiery is correct. You will ned to enable the glitch filter for the I2C analyzer as per the instructions below:
Glitches are unfortunately common when analyzing I2C due to the slow rise/fall times caused by the pullup resistors.
