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.

  • \$\begingroup\$ We know absolutely nothing about your hardware layout and components, how are we supposed to point out mistakes there? \$\endgroup\$
    – PlasmaHH
    Feb 14, 2017 at 20:30
  • \$\begingroup\$ Do you experience communication problems? ACK is sampled on the positive edge of SCL and this seems alright here. \$\endgroup\$
    – Janka
    Feb 14, 2017 at 20:33
  • \$\begingroup\$ Post a diagram of your I2C setup, including all devices that touch the bus, pull ups and capacitors. Is the glitch being clocked? \$\endgroup\$
    – Voltage Spike
    Feb 14, 2017 at 20:38
  • \$\begingroup\$ do u see any bit errors? \$\endgroup\$
    – user19579
    Feb 15, 2017 at 5:39

1 Answer 1


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.

  • \$\begingroup\$ This is quite correct. The slave is expected to release SDA (allow it to float high) as soon as SCL falls at the end of the ack . Looking at the level of the 0, you see that it is a little above zero when the slave is holding SDA down for the ACK, and right at 0V when the master holds it down. As supercat says, the master can do what the hell it likes with SDA while SCL is low - and with bit bashed implementations, it can go up and down more than once... \$\endgroup\$
    – Henry Crun
    Feb 15, 2017 at 1:47
  • \$\begingroup\$ ... and it is only at the rising edge of SCK when the state of the SDA line is read. \$\endgroup\$
    – CL.
    Feb 15, 2017 at 9:16
  • \$\begingroup\$ @HenryCrun: If the slave is capable of holding down SCK, it too has the leisure to do anything it likes with SDA as long as it keeps SCK held down. \$\endgroup\$
    – supercat
    Feb 15, 2017 at 15:05
  • \$\begingroup\$ supercat: Thanks for the answer. That all make sense to me. I was just concerned because the Saleae software was reading many of those as a byte +NACK, which is no correct. As @CL also mentioned, the ACK bit is only registered at the rising edge of the SCL, so this is a misinterpretation of the Saleae software. In any case, I asked to make sure this behavior wasn't unusual. Thanks a lot for the prompt a constructive answer. \$\endgroup\$
    – Lucas
    Feb 15, 2017 at 21:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.