Hi,
I am using the ESP32-WROOM-32U with the latest esp-idf.
I have I2C running constantly getting information from sensors. I also want to be able to log onto the ESP32 flash itself. When I do log onto the flash, sometimes it will mess up the I2C transaction and the I2C transaction returns ESP_FAIL.
When I scope the I2C bus, I can see that the SCL is pulled low and then the SDA and they stay low for like 30ms. (See attached image which shows the two ends of this time frame and the whole time frame itself.)
I only ever see this issue when I start doing SPI FLASH transactions. I am using the I2C driver in the idf.
I have tried using different pins for I2C, with no success.
Is there something I am missing or a workaround for this error?
Thank you.
I2C Fails when doing SPI FLASH
I2C Fails when doing SPI FLASH
- Attachments
-
- i2cbug2.png (162.65 KiB) Viewed 2758 times
Re: I2C Fails when doing SPI FLASH
Hi,
Yes, I suspect this is an inherent device issue.
(1) ESP32 internal flash write will block code cache fetching
- If your I2C driver is not located in IRAM then the driver may/will block.
Simple answer is IRAM your I2C driver. There is lots of IRAM free these days & being 32 bit addressable its hard to otherwise use!
(2) Other weird stuff
I have seen >2mS I2C clock idle even when not writing to FLASH.
I have put this down to general bus contension e.g. Ethernet. I have not had time to investigate but do suspect that ESP32 does not have as many peripheral buses as (say) an M4 and so I/O hungry applications may well hang.
I think (1) is most likely but be aware of (2).
I have found this issue to cause problems with I2C devices even when the device's datasheet allows clock stretch.
I would be interested in your diagnostics as I suspect a silicon issue (other than the clock stretch which may well be 'allowed' although masked by ESP32 headline summary).
PM me when you post. I would like to follow this theme.
Yes, I suspect this is an inherent device issue.
(1) ESP32 internal flash write will block code cache fetching
- If your I2C driver is not located in IRAM then the driver may/will block.
Simple answer is IRAM your I2C driver. There is lots of IRAM free these days & being 32 bit addressable its hard to otherwise use!
(2) Other weird stuff
I have seen >2mS I2C clock idle even when not writing to FLASH.
I have put this down to general bus contension e.g. Ethernet. I have not had time to investigate but do suspect that ESP32 does not have as many peripheral buses as (say) an M4 and so I/O hungry applications may well hang.
I think (1) is most likely but be aware of (2).
I have found this issue to cause problems with I2C devices even when the device's datasheet allows clock stretch.
I would be interested in your diagnostics as I suspect a silicon issue (other than the clock stretch which may well be 'allowed' although masked by ESP32 headline summary).
PM me when you post. I would like to follow this theme.
& I also believe that IDF CAN should be fixed.
Who is online
Users browsing this forum: axellin and 68 guests