[sht3x]: i2cdev: Could not write to device [0x44 at 0] about esp-idf-lib HOT 6 OPEN

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.

from esp-idf-lib.

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.

from esp-idf-lib.

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

from esp-idf-lib.

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 8dd5853 (from 2019).

from esp-idf-lib.

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.

from esp-idf-lib.

@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

from esp-idf-lib.