Hi Jaime,
The short answer is: for nearly all users of the ESP32 there is no impact from this bug. It's taken care of in software in IDF V3.0 (currently this the IDF master branch, the V3.0 release is coming soon) when using IDF code & drivers.
If you write code which reads peripheral registers directly then it's only a problem in two cases: when directly reading the AES, SHA & RSA crypto accelerator registers, and when reading some of the very low-level registers that control some low-level chip functions like peripheral clocks, the flash cache, etc. Only ever for direct register reads, not when calling API functions in IDF.
The long answer:
The description in the ECO notice is unfortunately a little terse. The "Address Space A" which is referred to, also sometimes called "DPORT", is a small group of register addresses between DR_REG_DPORT_BASE and DR_REG_DPORT_END:
https://github.com/espressif/esp-idf/bl ... /soc.h#L74
Reading from this range on one CPU can trigger the bug on the other CPU, if that other CPU happens to be reading "Address Space B" at the same time. Address Space B covers most other peripheral registers.
As mentioned above, the dangerous DPORT range is mostly registers that control some low-level parts of the chip:
https://github.com/espressif/esp-idf/bl ... port_reg.h
and also the hardware crypto accelerator control registers happen to be in this range.
To use the DPORT range of registers safely, we have a set of dedicated register access macros which prevent the bug from triggering (they stall the other CPU while the read completes):
https://github.com/espressif//esp-idf/b ... cess.h#L54
Using these macros (ie DPORT_REG_READ instead of REG_READ) allows reading DPORT registers safely when in dual core mode. This is how the bug is worked around inside ESP-IDF (you can grep for DPORT_REG to see that the hardware crypto drivers, startup code, etc. makes some use of these macros). This has some performance impact, but only for these few operations. 99% of register operations can use direct memory techniques like REG_READ() which have no such performance impact.
The people who need to pay attention to this ECO are anyone working directly with hardware cryptography registers, or fiddling with the low-level control registers for the chip - for instance if porting a new SMP-enabled RTOS to run on ESP32.
Does that help explain the situation?
