Tests with silicon V1

[ikerbelloso]

Hi,
I've finally received samples of ESP32 V1 and I've been testing their response to browout.
I've modifyied kconfig to enable brownout and set BROWNOUT level to 2.1 V and delay to the maximum.
With this silicon now I'm able to see the BOR and RTCWDT_BROWN_OUT_RESET but in my tests I'm being able to leave the device locked:
I'm producing 10ms DC gaps into the power supply so it translates to falls into the VDD of the module under the Brownout level that last for about the same amount of time, but it doesn't fall to zero thanks to the decoupling capacitors.
I repeat the process with VDD stable periods of 10 seconds, so the ESP32 is able to boot normally between them.
In many repetitions it works as expected and the BOR, relaunches correctly the device but in some others I'm facing a system block that can't be recovered unless y remove the input power.
This is what I see into the log terminal:

Code: Select all

ets Jun  8 2016 00:22:57

rst:0xf (RTCWDT_BROWN_OUT_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_RJaiting for download
 2016 00:22:57

rst:0xf (RTCWDT_BROWN_OUT_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
 2016 00:22:57

rst:0xf (RTCWDT_BROWN_OUT_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
 2016 00:22:57

rst:0xf (RTCWDT_BROWN_OUT_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
 2016 00:22:57

rst:0xf (RTCWDT_BROWN_OUT_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
 2016 00:22:57

rst:0xf (RTCWDT_BROWN_OUT_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
 2016 00:22:57

rst:0xf (RTCWDT_BROWN_OUT_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
 2016 00:22:57

rst:0xf (RTCWDT_BROWN_OUT_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
 2016 00:22:57

rst:0xf (RTCWDT_BROWN_OUT_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download

I would add that I have a pull up into the IO0 to reinforce the strap to SPI BOOT.

Any help to prevent this blocking?
Thank you

[rudi ;-)]

Hi,
I've finally received samples of ESP32 V1 and I've been testing their response to browout.
...
Any help to prevent this blocking?
Thank you

hi
which ESP32 you use?
ESP32-D0WDQ6
ESP32-D2WDQ5
..
and what is your manufacture mark on the chip?
??2017

do you use bare chip on your own PCB or Wrover V4 or Wrover V5 module?

best wishes
rudi

[ikerbelloso]

hi
I use ESP32-D0WDQ6 provided by distributor in south Europe, ASTONE.

V1 silicon

image1.JPG (176.53 KiB) Viewed 13729 times

I've confirmed through efuses that it is V1. Then, I'm using it replacing the V0 version ESP32-D0WDQ6 of a ESP-WROOM-32.
Then the module is running on a proprietary board and checked that all other functionality is working.
These are captures of the input voltage and the IO0 voltage :

VDD in green IO0 in pink

image2.JPG (651.43 KiB) Viewed 13729 times

VDD in green IO0 in pink

image3.JPG (657.82 KiB) Viewed 13729 times

Thanks and regards

[tommeyers]

This is a year old but it seems it is not resolved.

I am experiencing brown out recovery problems too. My tests are not as structured but they are: I power my esp32 v1 wroom dev board with a 3.3 v regulator battery/solar cell and deep sleep 1 hr, wake take an adc measure, send an mqtt message, sleep again, ... .

I don't recover from the sleep.

Reset recovers.

Has this been accepted as a problem w/bod/bor? Should I change my methods. Please advise.

Tom Meyers

[ESP_Sprite]

As I mentioned in the other thread: the BOR is not very good for ramping power supplies; it's intended to guard against situations where the power supply can't deliver enough current. In your situation, we'd advise to use an external voltage monitor / reset chip.