arduino-esp32
arduino-esp32 copied to clipboard
espressif
I2C Master Wire.requestFrom timeout not obeyed, takes a whole second to read when slave is not present
What you are trying to do? I'm trying to read from an I2C device which is not always present. With ESP32 Arduino 1.0.6, the read fails instantly as it should. With 2.0.1 it blocks for a full second (1000ms) every time.
This sketch will duplicate the error, no hardware required.
#include <Wire.h>
void setup()
{
Serial.begin(115200);
Wire.begin();
}
void loop()
{
uint32_t time_before=millis();
const int address=10;
const int length=16;
int rcvd = Wire.requestFrom(address, (uint8_t) length, (uint8_t) true);
if(rcvd==length)
{
uint8_t data[length];
Wire.readBytes(data, length);
}
Serial.printf("I2C: Received %u bytes in %u ms\n",rcvd,millis()-time_before);
delay(250);
}
If run on a regular ESP32 board with Arduino Core version 1.0.6, each Wire.requestFrom completes instantly or within 1 millisecond. With 2.0.1 it takes 1001 milliseconds.
I discovered the issue when recompiling a large project with the new Arduino core, so I stripped it down until I found the issue, but I don't know what's causing it.
I followed the code into esp32-hal-i2c.c and attempted to change the last parameter of i2c_master_cmd_begin to a hardcoded 1, and it still took a full second to complete the failed read -- the parameter change made no difference at all, so it seems perhaps the issue is all the way down inside the IDF?
Hardware:
Board: Generic 38-pin ESP32 dev board Core Installation version: 2.0.1 (and for reference 1.0.6) IDE name: Sloeber 4.4.0 Flash Frequency: 40Mhz PSRAM enabled: no Upload Speed: 921600 Computer OS: Windows 10
Debug Messages:
I tried, there are no I2C related debug messages even on Verbose.
Looks related to espressif/esp-idf#4999
Now that you mention it yes, it does look similar.. but that thread is from April 2020 which is over a year ago. This was not a problem in 1.0.6 (as far as I could tell?) which is from March 2021 which is only 7 months ago at the time of this writing?
Sorry I hadn't seen the dates. But since 1.0.6 is based on IDF v3.3.5 and that thread is about IDF v4.2, maybe the bug was introduced in between those IDF versions?
Sorry I hadn't seen the dates. But since 1.0.6 is based on IDF v3.3.5 and that thread is about IDF v4.2, maybe the bug was introduced in between those IDF versions?
Definitely possible. :)
Did you get a change to test it yet? The example code above requires no additional hardware to reproduce the issue.
I can definitelly confirm the bug. When there's no device listening on the given address, Wire.requestFrom takes at least 1 second before it returns.
Is there a simple workaround for this? I have tried to recompile the libraries using https://github.com/espressif/esp32-arduino-lib-builder modifying the driver i2c.c as seen in https://github.com/espressif/esp-idf/issues/4999 but I get errors when I use the libraries I obtain.
hello guys, can you please validate if this is still present on v2.0.3-rc1? thanks
@VojtechBartoska I have now checked with the current master (6cfe4613e4b4846e1ab08c7f78b7ea241f52c7da) and unfortunately, the problem is unchanged. Wire.requestFrom(address, (byte)1) takes exactly 1 second when there's no device at the given address.
I did update the toolchain (by running get.exe), but do I need to update something else?
Hi, seems you did it right and this issue still persist. We will take a look on it.
The problem is here. I2C_CMD_ALIVE_INTERVAL_TICK is 1000ms and it seems that it's the minimum time to wait. I guess this should/can be considered a bug in IDF's I2C driver.
@VojtechBartoska would you report this?
@me-no-dev There's already a ticket at https://github.com/espressif/esp-idf/issues/4999 Maybe you put your suggested fix there?
@theotherjenkutler there are not any updates, I'll ask if it's planned and let you know.
@VojtechBartoska thank you. If there would be any way to add this to roadmap I would very much appreciate it. Thank you for all your hard work!
@VojtechBartoska In case it is useful, it looks like 2 commits were made in the ESP-IDF since the problem was brought up by @me-no-dev on the ESP-IDF github: https://github.com/ci4rail/esp-idf/commit/6fcb9a53b48a22f4b5980621653d63ae5e7357c1
Just checking in regarding this issue. It seems like it was solved in the ESP-IDF....
Possibly related: readBytes() also has a 1000ms timeout by default. It is part of the parent class "Stream".
I ran into the same problem: IMU sensor hanging for 1 second a couple times per minute...
As a workaround I've created a fast bit-bang I2C lib, maybe it is of use for somebody else: https://github.com/qqqlab/ESP32_SoftWire
@VojtechBartoska When I last tested about a month ago it was still the same (a bus scan would take in the order of 5 minutes). I will try again.
Hello @leifclaesson, is this still valid?
Yes @VojtechBartoska, literally three years later the issue remains. I am still using v1.0.6 for all my projects that use I2C, and that is most of them.
I just tested with version 2.0.11, issue remains. A one second deadlock of the main thread completely breaks I2C bus scanning. I am surprised the issue has survived for three years considering how popular I2C is...
The sketch in my original problem report is still a valid test. You don't need any I2C hardware to run it, because the problem occurs when there is no I2C device connected on that bus. All you need is any ESP32 and the Arduino IDE.
It would be great to finally have a solution to this issue -- 1.0.6 is getting long in the tooth and missing more and more features compared to current versions, but with such a basic thing being broken for three years I and surely others are forced to stick with an outdated version that does handle the basics reliably.
To add a few more data points, it seems I am not alone in discovering this issue. I googled "esp32 i2c arduino timeout" and this is the first result.
If you notice, the replies are horrifyingly unhelpful, blaming his hardware and essentially saying "don't do that". I don't think this is correct. Conceptionally, the I2C bus has a master and multiple slaves. (Please forgive my non-PC terminology -- this is just simply what the I2C standard calls it.) The master is the ESP32. The master toggles the CLOCK pin high and low, and selectively holds the DATA pin low, or not, to address and send data to a slave. Then, the master keeps toggling the CLOCK pin, reading the DATA pin so that the slave can respond -- or not. Other than for rare devices that do "clock stretching" by holding the clock pin down to give themselves more time to respond, timeouts do not ever enter into the equation. If a slave chooses not to respond, or if there is no slave present, all that happens is that the master immediately gets 0xFF in response -- all bits high.
Other than to support clock stretching, the master never waits for the slave!
So, why does the ESP32 Arduino core 2.0.1 and forward wait for a whole second -- an astronomically long time for a microcontroller -- for no reason?
1.0.6 and earlier versions do not have this problem at all. Calls return immediately, as they should. Timeout is not even a thing.
I ran into the same problem: IMU sensor hanging for 1 second a couple times per minute...
As a workaround I've created a fast bit-bang I2C lib, maybe it is of use for somebody else: https://github.com/qqqlab/ESP32_SoftWire
Thank you for this, @qqqlab ! Definitely keeping this around for a rainy day. I've used the standard SoftWire library plenty on ESP32, and it has worked fine, pretty sure it can't do 3 MHz like yours though.