ESP32 Forum

According to the ECO bug list document, bug 3.10 is a dual core issue.

When the dual-core CPU access
es different address spaces,
a random error occurs.
Description:
In the case of a dual-core CPU, when one CPU bus reads address space A (0x3FF0_0000
~ 0x3FF1_EFFF), while the other CPU bus reads address space B (0x3FF4_0000 ~
0x3FF7_FFFF), a random error will be generated on the CPU bus reading address space A.
Workarounds:
When one CPU bus reads address space A, prevent the other CPU bus from reading
address space B by implementing locks and interrupts.

Now my question is how are other people dealing with this issue and how are people dealing with this issue when using libraries? I assume that libraries aren't designed to avoid reading certain address space or include a lock to prevent it from doing so. This bug seems a little dangerous and sounds like we should run the MCU in single core mode until the bug is gone (eg: spurious/random runtime crash due to data access that we can't control from libraries).

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?

ESP_Angus, this is probably the best answer I've ever gotten for chip support.

This is great information and knowing that there are macros handling the issue is exactly what I need to document in our system documents. Looking forward to V3.0 when it comes out and updating the ECO document would be great.

Do you know if there a hardware respin is in the works to fix this issue (and the troubling bad brownout detector)? A timeline would be great if you could share it.

FYI, I don't have access to the gitlabs (is it publicly facing?).

Really appreciate the answer!

Oops, Gitlab is our internal server. I changed the links in the post to point to Github instead.

ESP_Sprite wrote:Oops, Gitlab is our internal server. I changed the links in the post to point to Github instead.

Thanks Sprite. Sorry everyone, I blame jet lag.