Is brownout detection usable now?

[eyaleb]

In my recent build I see the introduction of brownout detection CONFIG_BROWNOUT_DET. I enabled it in sdkconfig and set it to the lowest voltage. I now get a brownout reset every time the wifi is turned on.

Code: Select all

I (2959) wifi: wifi timer task: 3ffb8d50, prio:22, stack:3584
Brownout detector was triggered
ets Jun  8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

My setup measures Vdd and it reports about 3.2v. I know that it can momentarily dip to around 2.8v. The module (esp-wroom-32) is fed directly from a LiFePO4 battery (at times two in parallel) and there is a 470uF electrolytic (low ESR) cap on the power pins.

Hence my question: Should I trust the brownout detector? Does it need any special considerations? For example, my module is revision 0 which has a known issue with BOD, does the recent commit work around this?

TIA

[ESP_igrr]

With the recent change, BOD should be usable both on rev0 and rev1 chips.

There are still situations where it will "fail" — for example if GPIO0 strapping pin is sampled as "low" after reset, in which case the system will go into flash download mode. There is an issue report related to this on Github, however we haven't managed to reproduce that specific case. But we can't rule out this possibility completely.

Regarding voltage thresholds: ESP32's internal 1.1V reference voltage has variation around 100mv between units, which is around 10% (that is a ballpark value; i don't know whether that is one sigma or two sigma or something else). We plan to burn the offset into Efuses during production, but that will only affect new batches. So the brownout detector may trigger at at trigger +/- 10% of the desired threshold, depending on the individual chip.

If you see BOD triggered resets but you don't see the voltage going that low on a scope trace, you may want to add smaller capacitors (such as 0.1uF/1uF) close to the chip. If you still see the issue, use an adjustable power supply and start dialing down the voltage gradually, until BOR happens. Measure the voltage when BOD triggers using a voltmeter. In this case, a simple blink example would do, no WiFi needed.
We have enabled BOD in our CI test environment some time ago, and haven't noticed any issues so far. We use DevKitC boards with Wroom-32 modules, powered via USB.

[eyaleb]

I now enabled BOD:

Code: Select all

CONFIG_BROWNOUT_DET=y
CONFIG_BROWNOUT_DET_LVL_SEL_0=y
# CONFIG_BROWNOUT_DET_LVL_SEL_1 is not set
# CONFIG_BROWNOUT_DET_LVL_SEL_2 is not set
# CONFIG_BROWNOUT_DET_LVL_SEL_3 is not set
# CONFIG_BROWNOUT_DET_LVL_SEL_4 is not set
# CONFIG_BROWNOUT_DET_LVL_SEL_5 is not set
# CONFIG_BROWNOUT_DET_LVL_SEL_6 is not set
# CONFIG_BROWNOUT_DET_LVL_SEL_7 is not set
CONFIG_BROWNOUT_DET_LVL=0

I will feed power from a power supply and run the blink example.
The PS is a Siglent that I expect is providing good and stable power.
Power is fed directly to the 3.3v/GND pins on the module which is soldered to a plain plate. Originally power was routed through a breadboard and had a 470uF cap, this probably degraded the path to some extent. All of this was now removed.

Reading Max/Min on the DSO:
Feeding 2.40v: 2.48/2.40 many resets
Feeding 2.50v: 2.56/2.48 OK

Now back to running my app (with wifi).
Feeding 2.50v: 2.60/2.48 many resets
Feeding 2.60v: 2.68/2.60 many resets
Feeding 2.70v: 2.76/2.68 OK

How can I read the internal Vdd (the one BOD uses)? This can be a good way to take preventative action before it is triggered, rather than using the ADC.

[ESP_igrr]

Just to clarify, are you using an ESP-WROOM32 module, or some other one?

[ESP_igrr]

Update: indeed the values listed in menuconfig are not correct. Here are the levels measured on one of the chips:

Code: Select all

0	2,40
1	2,46
2	2,56
3	2,59
4	2,60
5	2,65
6	2,70
7	2,74

We'll do some more measurements to check variation between chips.

[ken2004]

Is it even possible to do brownout protection in software? Software could protect against high WiFi currents dropping the supply voltage but can software provide protection more generally?

ESP_igrr mentions one protection failure mode but software protection can't be applied until after the first stage boot which from memory runs for about 10 milliseconds. That may not seem long but noise on the supply at 50Hz could have the chip in first stage boot 50% of the time and there would be some supply conditions where brownouts always occurred in the first 10 milliseconds.

[ESP_igrr]

Please don't consider the BOD of ESP32 a bullet-proof production grade protection measure. It is mainly provided to help identify problems with inadequate power supplies, which were very common for ESP8266 and are still common with ESP32, sadly.
For this purpose, it serves quite well — you get an error message saying that brownout has happened, instead of a hard-to-parse exception.

[ken2004]

Please don't consider the BOD of ESP32 a bullet-proof production grade protection measure.

Thanks for the clarification.

It is mainly provided to help identify problems with inadequate power supplies, which were very common for ESP8266 and are still common with ESP32, sadly.

I'm pretty sure most people are experiencing problems on the ESP8266 that look like brownouts but are actually produced by a software error in the TCP stack which I reported and ESP_igrr acknowledged, a long time ago now.

It's not yet fixed. If Espressif fix this error I expect most brownout like problems with the ESP8266 will go away. It will certainly improve things for me and my use cases are likely to be typical.

What happens, is that as supply voltage drops the radio becomes flaky while the processor is still working fine. A flaky radio causes the software error to manifest which puts the processor into an endless loop that includes logic for feeding the watch dog so the ESP8266 sits there looking like its browned out.

you get an error message saying that brownout has happened, instead of a hard-to-parse exception.

You get no messages or exceptions in this case.

The software error also causes problems when the internet connection is flaky or the server to which it is talking fails in an unusual way. I thought it was brownouts for a long time and fiddled a lot with capacitors but it never made a difference. It dawned on me that it must be a software bug when all my devices got stuck about the same time even though they were in different locations on different networks with different electricity supplies. The only commonality was that they were all reporting to Thingspeak.

If I power the ESP8266 from 3 alkaline batteries in series it will usually happen when the batteries are around 2/3 discharged. It doesn't happen on every set of batteries but usually it does and capacitors don't help. Alkaline batteries are most prone to this as they have a high internal resistance and the battery voltage gradually reduces as the cell discharges. The high internal resistance causes a voltage dip when the radio is functioning. Eventually you get to the point where the supply voltage is sufficient to operate the CPU but the radio is flaky. If it gets stuck and I reboot without changing the batteries then it will work fine again for hours and may or may not fail the same way again before the batteries fully discharge. Once the battery voltage gets low enough the problem goes away as the radio will not function at all and it has to function but flakily for the software error to manifest. In normal use on a good network, with mains power the devices usually go a month or two without getting stuck. On a mobile phone network they usually get stuck every few days. These failures are mainly due to network glitches rather than unstable supply voltage. On the few occasions I've noticed a blip in the mains supply the ESP8266 restarted without issues.

I expect the watchdog timer will still usually cause a reboot if the CPU goes into brownout which is why I expect brownouts are not a major problem. However, I haven't tested this, I've been waiting for the software fix with the intention of observing whether my deployed devices still get stuck rather than trying to quantify whether some of the failures are due to CPU brownout rather than the software error.

To reiterate, I think most of the problems related to inadequate power supplies will cease to be a problem if Espressif fixes the software error that causes an ESP8266 to get stuck in some circumstances.

[ESP_Sprite]

FWIW, the issue with the ESP32 is usually 'weirdness' (often an illegal instruction exception) on WiFi bootup; unrelated to the TCP/IP stack or the drivers itself. It's separate from the ESP8266 issue.

[seatosummit]

With the recent change, BOD should be usable both on rev0 and rev1 chips.

There are still situations where it will "fail" — for example if GPIO0 strapping pin is sampled as "low" after reset, in which case the system will go into flash download mode. There is an issue report related to this on Github, however we haven't managed to reproduce that specific case. But we can't rule out this possibility completely.

Hi @ESP_igrr-

Can you please share an update on the status of the BOD failure mode in which GPIO0 is sampled low after reset causing the board to enter flash download mode unexpectedly? Was this something you were able to observe in the lab? Any recourse?

I'm also interested in some details on how the errata in rev0 could be solved in software?

Thanks for the clarification!