I2C Master Wire.requestFrom timeout not obeyed, takes a whole second to read when slave is not present

[leifclaesson]

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.

[leifclaesson]

Thanks @me-no-dev

[CarlosGS]

Looks related to espressif/esp-idf#4999

[leifclaesson]

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?

[CarlosGS]

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?

[leifclaesson]

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. :)

[leifclaesson]

Did you get a change to test it yet? The example code above requires no additional hardware to reproduce the issue.

[pgrawehr]

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.

[simondddd]

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 espressif/esp-idf#4999 but I get errors when I use the libraries I obtain.

[VojtechBartoska]

hello guys, can you please validate if this is still present on v2.0.3-rc1? thanks

[pgrawehr]

@VojtechBartoska I have now checked with the current master (6cfe461) 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?

[VojtechBartoska]

Hi, seems you did it right and this issue still persist. We will take a look on it.

[me-no-dev]

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?

[pgrawehr]

@me-no-dev There's already a ticket at espressif/esp-idf#4999 Maybe you put your suggested fix there?

[VojtechBartoska]

@me-no-dev Reported to the existing issue.

[VojtechBartoska]

Thanks, let us please now, on which version did you test it?

[leifclaesson]

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.

[leifclaesson]

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.

[leifclaesson]

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.

[shalomberm]

Any updates for this?

[VojtechBartoska]

we will recheck, assigning to 3.0.5 milestone.

@lucasssvaz will you be please be able to retest this with version 3.0.4? thanks

[shalomberm]

For anyone that needs a quick fix you can do

Wire.beginTransmission(_addr);
if (Wire.endTransmission() == 0)
    Wire.requestFrom(_addr, x);

since endTransmition doesnt take up any extra time. Hope this helps

[lucasssvaz]

A fix for this issue was added recently to IDF. Does this still happens in 3.0.x ?

[pgrawehr]

I just updated to the latest master of the Arduino-ESP SDK and yes, it is a lot better than before. A full I2C bus scan now takes aroun 30 seconds, while previously it was much more (can't remember exactly, though). That is still a lot worse than on an Arduino Uno or similar board.

Maybe this could be further improved if that timeout was configurable (is it already?)

[lucasssvaz]

@pgrawehr It already is with Wire.setTimeOut(time_in_ms). By default it is 50 ms, I haven't tried using lower values though

[gian-didom]

I am experiencing the same problem and can confirm that the latest version of the SDK does not fix the issue. I still have a 1000ms minimum timeout despite setting it to 50 ms.

[VojtechBartoska]

@lucasssvaz Do you know if there have been any updates regarding this?

[lucasssvaz]

This might be due to I2C_CMD_ALIVE_INTERVAL_TICK being to high: https://github.com/espressif/esp-idf/blob/release/v5.3/components/driver/i2c/i2c.c#L84

I have not tested but using Arduino as a component and lowering this value might result in a shorter timeout.

[Jason2866]

closing since outdated. Please open a new issue if the issue still exists with actual Arduino core