Electronic – I2C ACK bit glitch

i2cnucleostm32stm32f0

I'm using an SMT32F030R8 to communicate via I2C with some other devices, and the problem is that I'm capturing some glitch in the I2C ACK bit.
As shown in the picture, at the end of one of the bytes, the data line should remain low because it has been acknowledged by the slave; however, the SDA goes high and is promptly pulled to GND again.

enter image description here

My first thought was that there could be some timing issue, but I have tried different frequencies and data hold and setup configurations and the same problem still happens. What I'm thinking now is that this is the result of a delay from the slave to pull down the SDA line (even though it has already acknowledged the byte).

Has anyone had the same problem and found the answer?

I have seen people suggesting adding capacitance to the line, but that is not solving the problem, it's just hiding it.

I have configured the I2C ports as open-drain with no internal pull-up, and I have added external 10k pull-up resistors.
I have captured the same type of issue with different devices and it is not something that happens for all the bytes.

If you guys need more info or have any suggestion, please let me know.

Best Answer

What you describe seems normal. If the last data bit in a byte is low, the master must drive SDA throughout the high-low cycle of SCK which follows that bit. During the following high-low cycle of SCK, the master will need to release SDA and the slave will need to drive it, but between the two high-low cycles the master and slave are allowed to arbitrarily drive or release SDA in whatever fashion they see fit. If the slave does not quickly start driving SDA, it must keep SCK low until it has done so.

The STM's bus-master circuitry appears to release SDA immediately upon the falling edge of SCK, before the slave has started to assert it, but that's not a problem since the slave starts asserting SDA well before the next rising edge of SCK.

Related Topic