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
Panic in I2C driver when reading from I2C EEPROM chip (IDFGH-12697) #13687
Comments
@sfzhi I tried to reproduce with our i2c_eeprom_main example but failed. Could you please provide your sdkconfig? |
IIRC,power-on reset will reset all condition, so after power-on reset, everything should begin as start. Some panic happen after power-on reset looks very strange to me even if GDB shows something. So 1. I want to see your configuration 2. See your reset reason
|
Here you go:
The |
I have conducted a few more experiments and the results are even more puzzling than before. When the panic occurs, if I don't wait until the device is restarted automatically (after 3 seconds, as per the configuration), but press the reset button again immediately, the device boots fine and the problem does not occur. I can't think of any reasonable explanation of what's happening. |
Even more experiments resulted in the following observations and conclusions:
|
Answers checklist.
IDF version.
5.2.1
Espressif SoC revision.
ESP32-C3 revision 0.4
Operating System used.
Linux
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
Seeed XIAO ESP32C3
Power Supply used.
USB
What is the expected behavior?
It should be possible to read a longer sequence of bytes from an external EEPROM over I2C.
What is the actual behavior?
Steps to reproduce.
i2c_new_master_bus(...)
- as usuallyi2c_master_bus_add_device(...)
- as usuallyFrom my observations, for the problem to occur, these two conditions must be true at the same time:
esp_restart()
.If both conditions are true, the problem is 100% reproducible.
Debug Logs.
More Information.
The relevant part of the code disassembled by GDB:
As can be seen from the register dump above, the exact spot where the problem occurs is
0x40382350 <+452>: sb a4,-1(a5)
, which is the assignment toptr[i]
insidei2c_ll_read_rxfifo(...)
.Apparently the destination address (stored in
a5
and already incremented for the next loop iteration) is NULL.The text was updated successfully, but these errors were encountered: