ESP32 Errata "3.16" correction (I2C problem)

[marcelounisb]

Hello,

I'm working on a very large project with ESP32­-WROOM­-32UE, which makes intense use of the UART, I2C, SPI and TIMERS peripherals. I've been struggling with a very sporadic bug, in which an I2C reading returns an inconsistent value (for example, should read zero from an external sensor register, but returns a non zero value). I'm confident that it's not an electrical issue. Although I’ve not been able so far to obtain a minimal reproducible environment of the error occurrence, the occurrence of the problem seems highly dependent on the amount of use of the other peripherals and general system configurations, such as the peripherals interrupt priorities and their associated core. Changes in those configurations highly modify the occurrence frequency, going from a few minutes to several hours.
Searching in the documentation, I've stumbled across the errata issue “3.16.”, that describes:
There are limitations to the CPU access to 0x3FF0_0000 ~ 0x3FF1_EFFF and 0x3FF4_0000 ~ 0x3FF7_FFFF address spaces, which seem possibly related.
I couldn't find, however, a clear report of the current status of the implementation of the proposed corrections in the drivers. Inspecting the I2C driver, for example, the function i2c_ll_read_rxfifo doesn't seem to implement workaround number 3 (inclusion of nop operations in between reads). I’m using release/v4.4, commit a49e0180ee638e41876a8f7bc6428a983fc69d66.

Some questions:

1. Is it possible that the observed behaviour might be related to issue 3.16?
2. Is this issue fully correct in ESP-IDF version "release/v4.4"? Is it absolutely guaranteed to be safe making heavy use of several hardware peripherals concurrently in different CPU cores?
3. How do the proposed workarounds prevent 3.16.2 (If the two CPUs continuously access address space 0x3FF0_0000 ~ 0x3FF1_EFFF at the same time, some of the access may be lost)?

Thank you very much in advance.

Marcelo