ESP32-S3 I2C System Reset Bug (IDFGH-7306) #8894
Comments
github-actions
bot
changed the title
|
https://ibb.co/k2FtM1N "xQueueSendFromISR(p_i2c->cmd_evt_queue, &evt, &HPTaskAwoken);" |
|
Hi @hasankarainfo , I saw a similar issue due to that line too in the driver, can you try the fix provided here: #8770 (comment) |
|
@o-marshmallow I am seeing the same Guru Meditation error on the ESP32-S3, in these circumstances:
When I use a different I2C device (MSA311), and the test program in https://github.com/dhalbert/i2c_delay, used in #8770, I don't see these problems. Here is a new test program, specifically for the LC709203F (it does some setup of the device): https://github.com/dhalbert/i2c_s3_stretch Here is a Saleae trace: Here are some screenshots: detail of the toggling on the right above: I mentioned this in #8741 (comment), but the example above is much better. |
|
hi @o-marshmallow. When I updated the relevant lines, it didn't work. Same problem is continue. Below is the updated version of the i2c file. |
|
Hi guys, Sorry for the delay of response. I had a try on my end with an ESP32-S3 and when shorting SCL and SDA I got this: I didn't get the panic like you did. What I did next is to try clock stretching. I don't have any device that does clock stretching, so I used another ESP32 to simulate a device doing clock stretching: I didn't get the toggling afterwards. I will continue investigating. @hasankarainfo The zip you uploaded seems corrupted, I cannot extract the file inside. |
I looked at the header a while ago, and I think it's an RAR file. |
|
@dhalbert Oh indeed, works better now, thanks! |
|
Since the github does not accept rar, I changed the extension to zip. can you try this ? |
|
Hi @hasankarainfo , I did use pin 39 and 40 successfully, no problem. I just cleaned my repo and checked out your commit: Interestingly, I don't get this problem on the latest master, commit |
|
Today, I tried removing idf and doing master checkout again. same result. However, I realized that I missed an important detail about the test. Keeping it short-circuited throughout the test, does not cause the problem to occur. |
|
@hasankarainfo That's exactly what I noticed in my case too with the commit you are using. For some reasons I can't reproduce it with the latest master |
|
Yeah.. I saw your issue and I have merged 0b00831 into master. Which can solve the short circuit issue on master. @hasankarainfo |
espressif-bot
added
Status: In Progress
|
I adapted 0b00831 to ESP-IDF v4.4.1, but I am still seeing the same clock stretch issue mentioned above in #8894 (comment). If you want me to open a new issue for that, I can do so. |
You can still see the timeout after the fix? |
Yes, I still see the same thing I saw in #8894 (comment), with SDA going high after a while, when testing with the LC709203F. Have you backported this fix to v4.4? Could you get an LC709203F to test with? |
|
The fix will go into 4.4.2. And I can't get LC709203F currently... Emm it's so odd that can't solve with that commit. The thing you can make it sure first is to check BTW, I'm curious that are you using wifi or BLE with it together? |
|
I did some more testing. I adapted your 0b00831 commit to v4.4.1 with this patch: I rebuilt my test program (https://github.com/dhalbert/i2c_s3_stretch) against the current I also tested my test program with https://github.com/dhalbert/esp-idf/tree/0b00831-adapted-to-v4.4. That also worked. So I think my adaptation of your patch is OK. As you mentioned, But unfortunately when I tested my adapted patch against CircuitPython, I still see the problem. In #8770, I was able to replicate the CircuitPython problem by adding a second task to a simple ESP-IDF program, to simulate what CircuitPython was doing with tasks. But that didn't work here. https://github.com/dhalbert/i2c_s3_stretch has some commented-out code to add the second task, and uncommenting that still does not cause the problem. So I will work on this some more, seeing just what might be different in the CircuitPython case. If the 4.4.2 release is imminent, I could test CircuitPython against that. |
espressif-bot
added
Status: Reviewing
espressif-bot
added
Resolution: Done
|
Update: I tested again today with the tip of |
|
@dhalbert |
|
i will deal with it soon |
|
@AxelLin Thank you! I will test this soon. |
|
Hello after a long time. Today I had the opportunity to do the relevant tests again. Some test conditions; Development Kit: custom
As in the picture, the result when I scan: i2c-tools> i2cdetect When the dat and clk pins are short-circuited, when I start the scan and remove the short-circuit when I come to the 5th address, the result is: i2c-tools> i2cdetect The result is satisfactory for me. Thanks to everyone who took an interest in the issue and contributed to the fix. |
|
Thank you, reading the battery voltage now works without a workaround. |
|
I retested in CircuitPython with an LC709203F after we upgraded to ESP-IDF v5.1, and it seems to work much better now. Not sure what has been fixed in 5.1, but that's good to see. |
Environment
Development Kit: custom
static gpio_num_t i2c_gpio_sda = 40;
static gpio_num_t i2c_gpio_scl = 39;
Module or chip used: ESP32-S3-WROOM-1-N8R2
IDF version "cpu_start: ESP-IDF: v5.0-dev-2586-ga82e6e63d9-dirty"
Build System: idf.py
Compiler version esp-2021r2-patch3-8.4.0
Operating System: Windows
environment type: ESP Command Prompt.
Using an IDE?: Eclipse
Power Supply: USB
Problem Description
-System resets when a problem occurs even in simple faults in i2c
-The problem also occurs when I short-circuit sda and scl.
Expected Behavior
I am trying to upgrade my project, which is designed according to esp32-wroom and works without any problems, to esp32s3.
Device list I added dynamically in esp32 working without any problem: m24c64 + pcf8563+ scd30 + sgp40 + shtc3 + 2lps22df + 3mcp96rl01 + si7021. It also passes the short-circuit test without any problems. When the short circuit is removed, it continues to communicate.
When I use esp32s3, the system continues to work as long as there is no communication problem. However, the system is reset when any problem or short circuit occurs during communication with any device.
Doesn't matter if optimization is on or off. Doesn't matter if psram is on or off. Doesn't matter whether freertos is always running on the first core, active or deactivated. Doesn't matter if peripheral drivers are on iram or not. Other versions I tried, 4.3.2 | 4.4 | 4.4.1 same result.
I also tried sda and scl pins on io8 and io9 but still no difference.
The other thing I tried is the "i2c_tools" project that I created with the new idf version. When I just change the sda and scl pins and run the same tests, the result is still the same.
Below is the output of my test in the i2c_tools project.
Step1: at first i run i2cdetect command with healthy connection and it finds devices
Step 2: I short-circuit and run the i2cdetect command
Other items if possible
buildfolder (note this may contain all the code details and symbols of your project.)The text was updated successfully, but these errors were encountered: