ECO and Workarounds for Bugs in ESP32 18 Nov 2016

[rudi ;-)]

hi guys

ECO and Workarounds for Bugs in ESP32

eco_and_workarounds_for_bugs_in_esp32_en.pdf

PDF V1.0 2016.11.18

(348.06 KiB) Downloaded 806 times

This document details the silicon errata and workarounds for the ESP32.
PDF V 1.0 from 18. Nov 2016

errata_workarounds.png (5.17 KiB) Viewed 10655 times

be sure you allways check espressif resource for update information too

best wishes
rudi

[onehorse]

How is it possible for any ESP32 development board or module to function properly if the spurious reset on power up (I am seeing this on my board) cannot be worked around in software? Does this mean the 100 ESP32 chips i just bought are garbage? This is quite frustrating.

[ESP_igrr]

RTC watchdog reset happens shortly after initial poweron, this can not be worked around. However the chip is perfectly functional after this reset. This does have impact on the startup time (i.e. the program will only boot up ~400ms after power on instead of ~60ms). The issue you seem to be having (judging from your other post) is related to the fact that after the initial RTCWDT reset the ESP32 can not load program from flash memory. I suggest that we proceed to troubleshoot that in the other topic you have opened or in the Github issue (i assume it is also opened by you).

[rudi ;-)]

How is it possible for any ESP32 development board or module to function properly if the spurious reset on power up (I am seeing this on my board) cannot be worked around in software? Does this mean the 100 ESP32 chips i just bought are garbage? This is quite frustrating.

..
The issue you seem to be having (judging from your other post) is related to the fact that after the initial RTCWDT reset the ESP32 can not load program from flash memory. I suggest that we proceed to troubleshoot that in the other topic you have opened or in the Github issue (i assume it is also opened by you).
..

if you mean your other post

1+
i see the same like ESP_igrr wrote.

btw:
( exampl. see the startup and rst here with the last ESP-IDF )

[WiFive]

I don't see register write bug mentioned about CAN peripheral listed in document.

[rudi ;-)]

I don't see register write bug mentioned about CAN peripheral listed in document.

Not sure is this general :

.. I'm not sure if the CAN controller is affected by this, but it may be good to keep this in mind...

perhabs we note this here for keep this in mind as a possible "workaround" :
src

if you write the registers too quickly, the 2nd write may be discarded.
This can be alleviated by putting a

Code: Select all

__asm__ __volatile__("nop;nop;nop;nop;nop;nop;nop;nop;");

line between writes, if memory serves.

and the next revision of the docu can append this then.

best wishes
rudi

[ESP_Sprite]

The warning for the CAN peripheral actually is the same bug as of 3.3. This document suggests working around it by writing these registers through a slower bus, which in essence has the same effect as putting a bunch of nops after the write. CAN isn't mentioned explicitly here because we are not sure if it suffers from this; I put in the warning so anyone trying this out would at least be aware of the possibility of this bug happening in the CAN controller as well.