-
Notifications
You must be signed in to change notification settings - Fork 7.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I2C Master Wire.requestFrom timeout not obeyed, takes a whole second to read when slave is not present #5934
Comments
Thanks @me-no-dev |
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? |
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, |
Is there a simple workaround for this? |
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 (6cfe461) and unfortunately, the problem is unchanged. 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. @VojtechBartoska would you report this? |
@me-no-dev There's already a ticket at espressif/esp-idf#4999 Maybe you put your suggested fix there? |
@me-no-dev Reported to the existing issue. |
Any chance that there is an update for this issue? |
@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: ci4rail/esp-idf@6fcb9a5 |
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 |
Hello @leifclaesson, is this still valid? |
@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. |
Thanks, let us please now, on which version did you test it? |
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". 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. |
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. |
Any updates for this? |
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 |
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 |
A fix for this issue was added recently to IDF. Does this still happens in 3.0.x ? |
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?) |
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.
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:
The text was updated successfully, but these errors were encountered: