0
\$\begingroup\$

I have an ESP-WROOM-32 (I2C master) and an ATmega328p (I2C slave, address 0x03) assembled on a prototype PCB using external 6k8 pull-ups.

I'm using the ESP's default I2C pins 21 (SDA) and 22 (SCL) as I always did, but when running the I2C scanner below, I do not observe any communication on the bus. SDA remains on high, SCL on low.

The same sketch works as expected when I flashed it to another individual ESP32 (there I see communication on the bus and the slave is recognized at address 0x03).

I'm very confused by that!

I'm pretty sure there is no hardware issue on the PCB, because I verified it on a breadboard before giving it to the manufacturer and I have also tested the circuitry with a multimeter after the assembly. Also toggling pins 21 and 22 in software with high frequency works as intended.

When I connect the other ESP32 to the same hardware, the signal has sufficient quality and is (at least) there.

As there is nothing magic about my PCB (SCL/SDA lines are about 1" long with no slave assembled, nothing else), I don't think posting my layout will be necessary (and I'm also concerned about posting it publicly as it's the property of my company).

I have no idea how the problem could be in my PCB, but as my previous thread was closed in the SE software section as "off-topic", I hope to find some answers here.

Has anyone made experience that too high pull-ups suppress signal transmission completely?

Is it reasonable that I partly destroyed the ESP through soldering (using a self-made reflow station which up til now did a great job). As I had no problems with other features at all, that does not seem to be likely.

At least some information I provided in the software section.

Before debugging with my oscilloscope and believing in a software fault, I flashed sketches that use the Wire.h, drivers/i2c.h and /peripherals/i2c.h, where I2C was set up on different pins (right now I don’t have access to those pins due to shielding, so I can't check if there is a signal output).

It seems like the interface was not even initialized? I can’t imagine I have a faulty chip...

Any ideas?

This is the I2C scanner I used (but I reproduced the problem with anything I did with Wire.h, drivers/i2c or peripherals/i2c.h):

#include <Wire.h>

#define SDA_PIN 21
#define SCL_PIN 22

void setup () {
  Wire.begin(SDA_PIN, SCL_PIN);
  Serial.begin(115200);
  Serial.println("\nI2C Scanner");
}

void loop () {
  byte error, address;
  int nDevices;
  Serial.println("Scanning...");
  nDevices = 0;

  for (address = 1; address < 127; address++ ) {
    Wire.beginTransmission(address);
    error = Wire.endTransmission();
    if (error == 0) {
      Serial.print("I2C device found at address 0x");
      if (address<16) {
        Serial.print("0");
      }
      Serial.print(address,HEX);
      Serial.println("  !");
      nDevices++;
    }

    else if (error==4) {
      Serial.print("Unknown error at address 0x");
      if (address<16) {
        Serial.print("0");
      }
      Serial.println(address,HEX);
    }    
  }

  if (nDevices == 0) {
    Serial.println("No I2C devices found\n");
  }
  else {
    Serial.println("done\n");
  }
  delay(1000);
}
\$\endgroup\$
  • \$\begingroup\$ Given it has been previously pointed out, why are your resistors still too large? Even if it were working you would still need to fix that by replacing them or adding more. If you configure the pins for i2c but send no operations scl should be high. Try holding each of the atmega and esp in reset in turn and see which is driving it low. \$\endgroup\$ – Chris Stratton Aug 31 '18 at 13:06
  • \$\begingroup\$ SCL low can also mean the communication is stuck in clock stretching. The master thinks the slave needs more time to react to the sent data. The slave helds SCL low in that situation and well behaving I²C masters wait endless. \$\endgroup\$ – Janka Aug 31 '18 at 13:13
  • \$\begingroup\$ It turned out that the gpio I used for SCL was broke indeed. I removed the shielding and configure different pins for I2C and after some time of successful signal generation the SCL pin was destroyed again (floating high-state at a level of around 2V). The ESP32 seems to be much more sensitive than I'm used to from my avrs. After reconfiguring once again and NOT touching/unplugging the bus it's doing fine since hours now. @Chris Stratton: I also reduced the pullups to 4k7, but it works with values between 1k and 10k as well and corresponding to the specs 6k8 is far from "far too high"... \$\endgroup\$ – Sim Son Aug 31 '18 at 23:17
-1
\$\begingroup\$

The problem was a destroyed gpio. For those who face this problem: the suspicious behaviour in that case is the concerned gpio floating in HIGH state at undefined voltages far below the high level. Obviously a damage of the output transistor.

\$\endgroup\$
  • \$\begingroup\$ -1 No. This cannot explain the situation you observed. An intermediate voltage is not "low". Had you been using a logic analyzer such an error might be excusable, but you specifically stated on IoT Stack Exchange that "yes, i've been using an oscilloscope." So this cannot explain the situation allegedly observed via an oscilloscope and reported by you in the question. Either your question is faulty or your "answer" mistaken. \$\endgroup\$ – Chris Stratton Sep 1 '18 at 2:53
  • \$\begingroup\$ Well, you don't have to accept it, but that's how it is. Why don't you save your effort if you don't have constructive contributions? And btw, it does exactly explain my situation, lol \$\endgroup\$ – Sim Son Sep 1 '18 at 3:09
  • \$\begingroup\$ No, it isn't the way it is. Either your question contains false statements or your answer is wrong. Further, even if it is the question which is wrong and the answer true, you still have an unsolved problem: damage like you alledge should not be happening. \$\endgroup\$ – Chris Stratton Sep 1 '18 at 15:19
  • \$\begingroup\$ The first gpio was allready dead when I started debugging and while the second got killed I had a scope in charge, so I could see it loosing its capability to toggle logic levels. I wrote a tiny debugging script which continuously switched the pinmode between I2C (tristate if I'm right) and output. I wasn't careful enough and must have created a short circuit, as I had no series resistor... stupid misstake and therefore an obsolete thread (which I'd simply like to close). If you provide an short answer that fits the question in your mind I'll accept it as solved and close this chapter \$\endgroup\$ – Sim Son Sep 1 '18 at 15:43
  • \$\begingroup\$ I should have mentioned that the gpio was temporarily connected to ground. That means I have created a short circuit when the gpio was configured as output in high state... \$\endgroup\$ – Sim Son Sep 1 '18 at 15:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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