5
\$\begingroup\$

My I2C slave is not pulling down the bus all the way for the ACK.

I have tried replacing 1.5k pullup with 10k pullup, but the ACK voltage remains the same (1.6V).

System Voltage: 2.5V

Master: STM32L151

Slave: NXP NT3H211

I have confirmed that the NT3H2211 is recognizing its address, because when I send another address (0x56 instead of 0x55), I see no response. (See screenshot).

I have confirmed that the NT3H2211 has a good ground and power supply, stable during the I2C access.

I have also ruled out an I2C peripheral issue on the master by writing a bit-bang rutine with the same result.

In this situation, how to proceed?

Schematic

Scope Screenshot

\$\endgroup\$
4
  • 10
    \$\begingroup\$ On your I2C master, are you sure you have the SDA pin open-collector output instead of push-pull? That looks suspiciously like a bus-fight between the master pulling high and the slave pulling low. One way to check is to remove the pull-up entirely. If you still see a waveform, that's your problem. \$\endgroup\$
    – DoxyLover
    Dec 17, 2016 at 19:19
  • 1
    \$\begingroup\$ @DoxyLover I was just about to suggest the same thing... slave pulling down a signal that's actively driven high by the master. \$\endgroup\$
    – Majenko
    Dec 17, 2016 at 19:23
  • 1
    \$\begingroup\$ Yes, what DoxyLover said. And if the master is not the culprit, then is there something else on the net that is driving high? Make sure you scrutinize it thoroughly. Maybe there is another pullup somewhere else in the schematic? A strong one? \$\endgroup\$
    – user57037
    Dec 17, 2016 at 19:41
  • 3
    \$\begingroup\$ By the way, when you solve it, please come back and write a concise answer to your own question. This forum ranks very high in search results, and your answer could help a lot of people. Nothing wrong with writing and accepting your own answer. \$\endgroup\$
    – user57037
    Dec 17, 2016 at 19:43

1 Answer 1

Reset to default
8
\$\begingroup\$

@DoxyLover and the others are right: the master was pulling up, causing driver contention. My mistakes were:

  1. Assuming that configuring the I2C peripheral (alternate function in STM jargon) would automatically set SDA as open drain.

  2. In my bit-banging code, configuring the wrong port for open drain (leaving SDA still push-pull and leading me to believe that the master was not the issue).

  3. Assuming that the functional state of the NT3H2211 does not change during testing. Once I corrected the open drain issue, I saw no ACK at all! It turned out the NT3H2211 failed somewhere along the way. Swapping the NT3H2211, and running the corrected code, fixed the problem.

enter image description here

\$\endgroup\$
2
  • 2
    \$\begingroup\$ FYI: don't be frustrated about making that mistake. I have the same problem with the HDMI I2C on the Raspberry Pi. With Linux kernel <=3.10.28 all works as expected, with later device-tree-enabled kernels I have the same ACK problem. Still looking for the culprit. \$\endgroup\$
    – Janka
    Dec 17, 2016 at 21:07
  • \$\begingroup\$ Nice job; I edited to add stm32 tag, since the root cause was specific to stm32 configuration. This will help other people find your solution in the future. \$\endgroup\$
    – MarkU
    Dec 18, 2016 at 0:08

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.