[sht3x]: i2cdev: Could not write to device [0x44 at 0]

[FeOAr]

The issue

• release version: 0.9.4
• esp-idf version: 5.1.1

I am using the example of SHT30, which can function normally when the I2C speed is 100K, but other chips can reach 200K using the same "i2cdev" lib. The last discovered issue may be that the i2c device was not fully configured before the first measurement. Just add a delay to use it normally.

void task(void *pvParameters)
{
    float temperature;
    float humidity;

    TickType_t last_wakeup = xTaskGetTickCount();
    vTaskDelay(pdMS_TO_TICKS(10));  // Add delay before measurement

    while (1)
    {
        // perform one measurement and do something with the results
        ESP_ERROR_CHECK(sht3x_measure(&dev, &temperature, &humidity));
        printf("SHT3x Sensor: %.2f °C, %.2f %%\n", temperature, humidity);

        // wait until 5 seconds are over
        vTaskDelayUntil(&last_wakeup, pdMS_TO_TICKS(1000));
    }
}

Which SDK are you using?

esp-idf

Which version of SDK are you using?

5.1.1

Which build target have you used?

• [ ] esp32
• [ ] esp32s2
• [X] esp32s3
• [ ] esp32c2
• [ ] esp8266
• [ ] other

Component causing the issue

sht3x

Anything in the logs that might be useful for us?

E (320) i2cdev: Could not write to device [0x44 at 0]: -1 (ESP_FAIL)
ESP_ERROR_CHECK failed: esp_err_t 0xffffffff (ESP_FAIL) at 0x4200870b

Additional information or context

No response

Confirmation

• [X] This report is not a question nor a request for drivers.

[cmorganBE]

Using sht4x driver here (with the default of 1MHz). Seeing similar issues with periodic failures during configuration (retries resolve), and periodically during run-time where the write to start a measurement read fails:

E (668146) i2cdev: Could not read from device [0x44 at 0]: -1 (ESP_FAIL)

Note that these failures are seemingly random, we read the temp/humidity every 500ms, several reads are successful, then a failure, then the next several are successful etc.

[cmorganBE]

Modified the sht4x driver code to slow from 1MHz down to 100khz, and changed i2c bus pullups from 4.6k down to 2.6k. Signals on the scope look very clean vs. the original 1MHz 4.6k pullup.

Still seeing the i2cdev errors here though.

[cmorganBE]

I was able to catch the issue here. In the good case:

• write to start measurement (0xFD)
• Longer delay (~1ms)
• data response from part

bad case:

• write to start measurement (0xFD)
• Shorter delay (~0.5ms)
• Data response is cut short after the first byte

[cmorganBE]

Alright, root cause identified for my case, opening a PR today to resolve. The issue was that for the SH4Tx driver pdMS_TO_TICKS() was being used. ticks on my system (and likely many others) is 10ms (100hz). The delay time was 10ms / (10ms / tick) = 1 tick, but vTaskDelay() is NOT guaranteed to delay for at least the value given, see https://www.freertos.org/a00127.html, there is no mention of "at least" which is typical for delay functions. So for single tick delays you could delay for 10ms, or 6ms or 15ms, it does its best to get close.

In the case where the delay is supposed to be 10ms but its 6ms the SH4Tx isn't ready yet to respond, hence the error.

This is corroborated by:

• Scope showing 10ms (1 tick) delays being shorter than 10ms (otherwise I wouldn't have believed it)
• SH4Tx measurements only fail if the time between the 0xFD (start measurement) and the measurement read is less than 10ms
• No failures if I apply the fixes from the SHT3x driver to the SHT4x driver (this is going to be the PR I'm opening today)

So maybe this isn't the same issue as the OP reported with the sht3x not reading correctly since it looks like that driver has had the correct tick calculation with margin in place since 8dd5853b (from 2019).

[FeOAr]

Thank you very much for your answer. I now have a rough understanding. I will take some time to reproduce it with an oscilloscope later.

[cmorganBE]

@FeOAr I'm guessing you have a different issue than I have. I wouldn't have posted here but it looked like the same issue initially. PR is #632