I2C master: Read data does not match actually present on bus.

[katyo]

Bug description

The data in read buffer does not match data which slave writes to the bus. For example it reads 0x83 while on a bus I see the 0xC3, it reads 0x03 while on a bus 0x83 is present.
I deals with a ESP32-C3. I use the default I2C config with SCL on a GPIO3, SDA on a GPIO4. The hardware pull-ups is a 4.7K both. If that matter the slave device is a relative humidity and temperature sensor HTU21D.

Looks like the 7th and 6th bits changes randomly.

To Reproduce

I use the following code snippet:

    esp_println::logger::init_logger_from_env();

    let config = esp_hal::Config::default().with_cpu_clock(CpuClock::max());
    let peripherals = esp_hal::init(config);

    let mut i2c = I2c::new(peripherals.I2C0, i2c::Config::default())
        .unwrap()
        .with_sda(peripherals.GPIO4)
        .with_scl(peripherals.GPIO3);

    loop {
        use embedded_hal::i2c::I2c;

        let mut d = [0u8];

        i2c.write_read(0x40, &[0xe7], &mut d).unwrap();
        println!("data: {d:x?}");

        Timer::after_secs(1).await;
    }

I tried both blocking and async modes with same results. I'm on a main esp-hal branch.

UPD:
Also I tried optimized (release) build but the problem is same.

Expected behavior

Read data same as an actually present on a bus.

Environment

• Target device: ESP32-C3

  Chip type:         esp32c3 (revision v0.3)
  Crystal frequency: 40 MHz
  Flash size:        4MB
  Features:          WiFi, BLE
  MAC address:       60:55:f9:2b:8c:73
  

• Crate name and version:
  esp-hal v0.23.1

[katyo]

If I lower the frequency to 50 kHz, the data is read correctly. It seems to be a hardware issue. May be it needs some configuration for input filters, but seems it still hasn't supported.

[bugadani]

Thanks for reporting this! Just to confirm, the wavefor doesn't change in a meaningful way when you look at it, right?

[bugadani]

Can you please check if #3040 solves your issue?

[lure23]

@katyo Interested to follow this. Just making sure you know about potential problems if using all these together:

• ESP32-C3
• probe-rs and RTT (e.g. defmt) <-- edited
• I2C bus, via esp-hal
  ?

The problem is that probe-rs occasionally needs to stop the MCU core from running (doesn't need to do that in same way on, say, ESP32-C6), and this can cause effects on time-critical things like I2C. Because of this, I moved my i2C project to use C6.

If you don't use probe-rs, just ignore this.

[bugadani]

The problem is that probe-rs occasionally needs to stop the MCU core from running

This is only an issue if you use anything RTT-based, like defmt, but not true in general. I'm not sure if the I2C peripheral would be affected by this, though...

[lure23]

The problem is that probe-rs occasionally needs to stop the MCU core from running

This is only an issue if you use anything RTT-based, like defmt, but not true in general. I'm not sure if the I2C peripheral would be affected by this, though...

Hmm.. so I likely should change the writing in the link I made. I'll try!

For me, I2C was indeed affected; that's why I brought this up. But it only occurred because my VL53L5CX peripheral takes a longish (>64kB) transfer, to upload its firmware.