Brownout detected since v2.0.10+

[joysfera]

Board

ESP32

Device Description

plain ESP32 WROOM 32UE module with HT7833 LDO

Hardware Configuration

nothing else is attached

Version

v2.0.9

IDE Name

Arduino

Operating System

Ubuntu 22

Flash frequency

40MHz

PSRAM enabled

no

Upload speed

115200

Description

I've got a complex application running web server, web SSL client, MQTT client, OneWire scanning and more. All Arduino cores from 1.0.0 to 2.0.9 work correctly and can run my app stable for hours, days and months.

However, every Arduino core from 2.0.11 up to 2.0.17 causes Brownout detection randomly within seconds after powering the device up (please note that Arduino core 2.0.10 cannot compile so it's not listed). Sometimes it ends up in kind of a boot loop where it brownouts several times in a row, sometimes it runs semi-stable for two-three minutes and then brownouts.

It seems related to underlying SDK change (4.4.4 for 2.0.9, 4.4.5+ for 2.0.10+).

It looks like a change in SDK caused higher current spikes in Arduino core 2.0.10+ that my LDO does not handle well and the voltage drops below brownout level. So it is partially a hardware fault but can be fixed easily by downgrading the Arduino core to 2.0.9 or below.

I wish to find out what has changed in SDK 4.4.5+ or Arduino core 2.0.10+ and change it back so that the application running on my hardware would be stable again and I could use the latest Arduino core features and bug fixes.

Perhaps WiFi TX Power has changed in the SDK 4.4.5+ that causes it? I've noticed there used to be
CONFIG_ESP_PHY_REDUCE_TX_POWER defined in sdkconfig.h in Arduino core 2.0.9 but it is no longer defined in newer cores. Could this be a hint?

Sketch

Unfortunately I don't have a minimal sketch. Even if I had you wouldn't have the hardware with LDO I've got so it wouldn't help, anyway.

Debug Message

Brownout detection

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[me-no-dev]

I will suggest that you ask this same thing in the ESP-IDF issue tracker. We are in a sense only consumer of the SDK.

BTW have you tried erasing the flash before uploading newer version? And surely you should think of large cap on the power or changing the LDO to something that can handle larger currents (1A)

[joysfera]

The hardware cannot be changed (easily), it is deployed in the field in many copies already. BTW, larger caps make it worse (unless the cap is insanely large so it handles the complete WiFi power spike - that requires more than 5000 µF).

Will ask in ESP-IDF, thanks, but perhaps it is not related to SDK - that is just my guess.

[joysfera]

Just tried erasing the complete flash and that brought kind of a funny issue: since my WiFi credentials are gone the application starts WiFi Manager and that causes immediate and 100% reproducible Brownout.

So now I could provide a minimal sketch for you: just enabling the WIFI_AP causes the Brownout as well.

Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision v3.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 44:17:93:5b:43:b0
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...
Chip erase completed successfully in 17.2s
Hard resetting via RTS pin...

Brownout detector was triggered

ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:13260
load:0x40080400,len:3028
entry 0x400805e4

[me-no-dev]

perhaps it is not related to SDK

such changes can only be related to the SDK WiFi driver. In Arduino we just enable and start it. Have you tried 3.0.1 yet?

[joysfera]

Tried 3.0.1 yesterday, spent quite some time fixing libraries' incompatibilities but in the end didn't manage to build my app. Will try again in a moment, perhaps the library managers will catch up in the meantime.

EDIT: now that I know WiFi Manager is enough for testing I'll give it another try with simpler sketch.

[me-no-dev]

you can at least try to start the WiFi and see if it behaves better. Should have a newer WiFi driver

[joysfera]

Thanks, will report back if 3.0.1 happened to help. Going to try asking in ESP-IDF and add a link here just for reference.

[JAndrassy]

you could try to reduce the WiFi TX power with WiFi.setTxPower(WIFI_POWER_8_5dBm)

[Jason2866]

@joysfera The solution is to stay at the version you are. Since the part which is responsible for wifi stuff is closed source (in IDF) nothing can be done. Using different older wifi libs will fail since the are not compatible (you get linker errors, or wifi fail silently).

Edit: The wifi closed source libs do have changed often. If you want to track down there is a lot of trying work ahead.

If the Onboard LDO is a 500mA type you are lucky that it ever worked reliable.

[joysfera]

@Jason2866 I think 500mA LDO should be OK:

[Jason2866]

@joysfera "is no less than 500mA" -> 500mA is everything else than a safe value.

[joysfera]

@JAndrassy didn't help, unfortunately. I've even tried different values but to no effect.

[everslick]

Another thing you could do (it's risky though!!!) is to disable the brownout handler. This only works, if you have control over the linker flags though:

Add -Wl,-wrap,esp_brownout_init to the linker flags, then add

void __wrap_esp_brownout_init() {
}

to your code.

This might bring you over the WiFi init phase and you can than call __real_esp_brownout_init(); later on.

[joysfera]

Disabling the brownout at runtime (before enabling WiFi) using
WRITE_PERI_REG(RTC_CNTL_BROWN_OUT_REG, 0);
stops the boot loop but my OneWire bus with sensors powered via the same 3.3V rail as the ESP32 stops working.
Thus I suspect the power spikes on SDK 4.4.5+ are real and the only fix is to return back to SDK 4.4.4.

[spyder0069]

Curious. If you perform a reset via the EN pin instead of a power cycle does everything work? In this scenario power is already stable. Just looking for confirmation that it works and that the issue is only during a power-up. Did you try additional reset commands on your onewire? What onewire sensors are you using?

[kevinjterry]

I'm having a nearly identical issue. Brownouts on an LDL1117S33R LDO. Adding a lot of capacitance (> 440uF) helps, but does not fix the issue. Cold starts runs for a bit longer, then it essentially boot loops at wifi begin once warm. I've tested a handful of other LDO's and all have the same issue. I've also verified there is a short sag in voltage (2.8v- 3.0v) as wifi.begin occurs.

WiFi.setTxPower(WIFI_POWER_8_5dBm) did not help.

I'm unsure how to downgrade the arduino core below 2.0.9 to test that.

[joysfera]

@spyder0069 the power spikes repeat every few seconds when WiFi is active so the power is never stable.

@kevinjterry in Arduino IDE in "Board Manager" you'll find "esp32" from Espressif and in a drop down you can pick any version you wish. Then click "Install" and that's it.

[kevinjterry]

@kevinjterry in Arduino IDE in "Board Manager" you'll find "esp32" from Espressif and in a drop down you can pick any version you wish. Then click "Install" and that's it.

ah, understood. Thank you. I'm using platformio -- I didn't find anything obvious for swapping core versions when searching. I'm going to swap the regulator for a switching regulator and give that a shot as well.

In case it's helpful for anyone else looking into it, I've attached the voltage dip I'm seeing.

[joysfera]

Before swapping regulators please don't miss the chance to confirm my issue - downloading Arduino IDE takes few minutes only and for the test you could just upload any example from the provided ones.

[Jason2866]

@kevinjterry No need to install anything else than Platformio.
Simply do

platform = espressif32 @ ^6.7.0
platform_packages = platformio/[email protected]

You find the available versions here https://registry.platformio.org/tools/platformio/framework-arduinoespressif32/versions?

[kevinjterry]

@kevinjterry No need to install anything else than Platformio. Simply do

platform = espressif32 @ ^6.7.0
platform_packages = platformio/[email protected]

You find the available versions here https://registry.platformio.org/tools/platformio/framework-arduinoespressif32/versions?

Thank you -- that worked great.

Sadly, espressif32@^6.7.0 and [email protected] was no different and the brownout condition continued.

[joysfera]

@kevinjterry Could you please, just to ensure, include the following line in your program (if it ever gets to printing something on serial):

Serial.println(ESP.getSdkVersion());

[kevinjterry]

@joysfera Absolutely, I included it and received SDK Version: v4.4.4

Regardless of the version option I specify in the platformio.ini file, I receive v4.4.4 back from that function call. For example using 4.3.0 (confirmed in the build process) still seems to print back v4.4.4. I'm not unsure why the build is reverting back to 4.4.4.

[JAndrassy]

I have an older Wemos D1 ESP32 mini with this problem. It resets on enableSTA(). With ETH it works without problems. I didn't test older versions now but I know it works with 2.0.9.

I tested it with esp hosted fg firmware. It had brown-out too, but setting CONFIG_ESP_PHY_REDUCE_TX_POWER=y in sdkconfig helped.

With Arduino I didn't find a solution. Reducing TX power is only possible after enableSTA() or enableAP().

(my newer ESP32 D1 mini works ok with 3..0.1)

[joysfera]

@JAndrassy please clarify it for me as the ethernet confused me: does your Wemos D1 ESP32 mini work with WiFi on stock Arduino core v2.0.9 correctly or not?

[JAndrassy]

does your Wemos D1 ESP32 mini work with WiFi on stock Arduino core v2.0.9 correctly or not?

yes it does

as the ethernet confused me

it was to clarify that there is no other problem with 3.0.1 with that board. without WiFi everything works.

[joysfera]

@JAndrassy thanks, so you're confirming this issue is real. Seems like the default TX power has increased in SDK 4.4.5+ and that causes instability on boards with less capable power circuits, that are in fact 100% reliable on SDK 4.4.4 or older.

So in theory rebuilding the current SDK with the CONFIG_ESP_PHY_REDUCE_TX_POWER (as I've pointed out in the original Description as the visible difference between Arduino core 2.0.9 and 2.0.10+) would allow us to use latest Arduino core again? Judging from your test in ESP-IDF where you said setting the CONFIG_ESP_PHY_REDUCE_TX_POWER helped.

Sounds like there's a chance for newer Arduino cores to be less power hungry again? @me-no-dev

[me-no-dev]

Will be enabled in 3.0.2 espressif/esp32-arduino-lib-builder#185

[JAndrassy]

CONFIG_ESP_PHY_REDUCE_TX_POWER didn't help for my older ESP32 D1 mini

[joysfera]

@JAndrassy Last week you wrote literally the opposite:
"setting CONFIG_ESP_PHY_REDUCE_TX_POWER=y in sdkconfig helped."

[JAndrassy]

@JAndrassy Last week you wrote literally the opposite: "setting CONFIG_ESP_PHY_REDUCE_TX_POWER=y in sdkconfig helped."

with an IDF 5 project (esp_hosted_fg firmware)