ESP_igrr wrote:Please don't consider the BOD of ESP32 a bullet-proof production grade protection measure.
Thanks for the clarification.
ESP_igrr wrote:
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.
ESP_igrr wrote: 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.