No signal output on I2C bus

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 () {
int nDevices;
Serial.println("Scanning...");
nDevices = 0;

error = Wire.endTransmission();
if (error == 0) {
Serial.print("I2C device found at address 0x");
Serial.print("0");
}
Serial.println("  !");
nDevices++;
}

else if (error==4) {
Serial.print("0");
}
}
}

if (nDevices == 0) {
Serial.println("No I2C devices found\n");
}
else {
Serial.println("done\n");
}
delay(1000);
}

• 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. – Chris Stratton Aug 31 '18 at 13:06
• 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. – Janka Aug 31 '18 at 13:13
• 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"... – Sim Son Aug 31 '18 at 23:17