You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
I have searched the issue tracker for a similar issue and not found a similar issue.
IDF version.
v4.4.4
Operating System used.
Windows
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
CMD
Development Kit.
esp32c3
Power Supply used.
USB
What is the expected behavior?
I am using ESP32C3 in one of my projects to read the sensor data from SHT3x sensor. After reading the data, I publish this data on the TWAI (CAN) bus as well as on the terminal (idf.py monitor) and then put the unit to deep sleep with timer set for 10-30 seconds wake up time. Every time unit wakes up, it initializes everything, reads data, publishes it on the CAN bus and goes to sleep. And this loop just goes on. For debugging reasons, I keep the USB connected and I can see the data coming out every 10-30 seconds.
What is the actual behavior?
After a couple of loops, the unit fails to read the data from SHT3x sensor. No matter what I do with the SHT3x sensor, as long as ESP32C3 module is powered up, it always fails to read sensor data, as if the conversion is still under process. And the only way to fix the problem is to hard reset the ESP32C3 module. Check the SHT3x response after requesting for the data.
Update:
I have tested the code even without going into deep sleep. Just a simple loop, reading the data from SHT3x and after some time, say 1 - 2 hours, the ESP32C3 fails to read the data. And I know for sure that the sensor SHT3x has nothing to do with the error. Because, even if I reset the SHT3x sensor or restart the ESP32C3 module from software, it doesn't help. Only way to make it work is to hard reset the ESP32C3. In my solution, I have put a jumper between EN pin and GPIO9 to reset itself.
Steps to reproduce.
Use any ESP32C3 based dev board, connect SHT3x sensor I2C pins to GPIO5 as SDA and GPIO6 as SCL pin. I am using the following library from github for SHT3x. https://github.com/gschorcht/sht3x-esp-idf
Or use any sensor that communicates over I2C with any ESP32C3 devkit and start fetching data from the sensor. Let it run for some time and keep monitoring the logs on the terminal. Eventually ESP32C3 would end up failing to fetch data. In your code, you can use any gpio to reset the ESP32C3 using "esp_restart()" function in the code. Remember, only the hard reset via reset pin can or will fix the problem and nothing else. Try it.
Debug Logs.
No response
More Information.
I have tried my code with both the variants i.e. ESP32-C3-MINI-1 and ESP32-C3-WROOM-02. The problem is persistent. And highly likely the problem lies within the chip and not the framework.
The text was updated successfully, but these errors were encountered:
github-actionsbot
changed the title
TWI / i2c stops communicating after deep sleep
TWI / i2c stops communicating after deep sleep (IDFGH-10238)
May 25, 2023
@embenix Excuse me, but have you found the cause of this error? I also used the same sht3x library, ESP32-S3 also got this error.
@Sotatek-TuHoang, unfortunately Not!
I have used a free gpio pin to reset the ESP module if such a condition is detected. My application is not very sensitive and so reseting the ESP module works just fine.
Answers checklist.
IDF version.
v4.4.4
Operating System used.
Windows
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
CMD
Development Kit.
esp32c3
Power Supply used.
USB
What is the expected behavior?
I am using ESP32C3 in one of my projects to read the sensor data from SHT3x sensor. After reading the data, I publish this data on the TWAI (CAN) bus as well as on the terminal (idf.py monitor) and then put the unit to deep sleep with timer set for 10-30 seconds wake up time. Every time unit wakes up, it initializes everything, reads data, publishes it on the CAN bus and goes to sleep. And this loop just goes on. For debugging reasons, I keep the USB connected and I can see the data coming out every 10-30 seconds.
What is the actual behavior?
After a couple of loops, the unit fails to read the data from SHT3x sensor. No matter what I do with the SHT3x sensor, as long as ESP32C3 module is powered up, it always fails to read sensor data, as if the conversion is still under process. And the only way to fix the problem is to hard reset the ESP32C3 module. Check the SHT3x response after requesting for the data.
Update:
I have tested the code even without going into deep sleep. Just a simple loop, reading the data from SHT3x and after some time, say 1 - 2 hours, the ESP32C3 fails to read the data. And I know for sure that the sensor SHT3x has nothing to do with the error. Because, even if I reset the SHT3x sensor or restart the ESP32C3 module from software, it doesn't help. Only way to make it work is to hard reset the ESP32C3. In my solution, I have put a jumper between EN pin and GPIO9 to reset itself.
Steps to reproduce.
Use any ESP32C3 based dev board, connect SHT3x sensor I2C pins to GPIO5 as SDA and GPIO6 as SCL pin. I am using the following library from github for SHT3x.
https://github.com/gschorcht/sht3x-esp-idf
Or use any sensor that communicates over I2C with any ESP32C3 devkit and start fetching data from the sensor. Let it run for some time and keep monitoring the logs on the terminal. Eventually ESP32C3 would end up failing to fetch data. In your code, you can use any gpio to reset the ESP32C3 using "esp_restart()" function in the code. Remember, only the hard reset via reset pin can or will fix the problem and nothing else. Try it.
Debug Logs.
No response
More Information.
I have tried my code with both the variants i.e. ESP32-C3-MINI-1 and ESP32-C3-WROOM-02. The problem is persistent. And highly likely the problem lies within the chip and not the framework.
The text was updated successfully, but these errors were encountered: