[16.0.0] ESP32 crashes (?) when powered through something other than USB

[Prowler1000]

What happened?

After updating to WLED 16.0.0, my device would no longer function. I have TM1814 LED strips which entered their demo mode after the update and the web UI was no longer accessible. After connecting to USB to re-flash the firmware, as I assumed it was a failed OTA, I accidentally refreshed the page and found I could access the web UI again, so I did a small amount of testing and found that, when powered over USB, the device is accessible but when I reconnect the power supply, it becomes inaccessible, even when also powered over USB.

I re-flashed 0.15.5 and everything works as expected.

I originally updated through Home Assistant, but after reverting back to 0.15.5, I also manually updated through the web UI and had the same behavior. I have since reverted back to 0.15.5 again and things, again, returned to normal.

To Reproduce Bug

As said, this is likely to my specific hardware however the steps I take to reproduce it are

• Have a functioning 0.15.5 installation, powered through a buck converter from the same 24v supply as the LED strips being controlled
• Perform an OTA update to 16.0.0
• (Optinal) Get a headache from TM1814's demo mode after the ESP32 fails to boot

Expected Behavior

WLED successfully communicates with the LED strips and the web UI is accessible

Install Method

Binary from WLED.me

What version of WLED?

16.0.0

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

Anything else?

This is very strange, and likely specific to my hardware so I will be more than happy to provide whatever is needed. I do have an ESP32 dev board which I can use to read serial logs now, as compared to the last time I submitted an issue (I don't have a dedicated serial interface).

I do not know if

• The issue happens when manually flashing over a direct serial connection
• Whether the device is actually failing to boot or whether the web UI simply becomes inaccessible and lighting communication fails
• Whether the failure to communicate with my LED strips directly related as I haven't by-passed the controller to power the LED strips while only powering the ESP32 through USB. That's just work I didn't want to put in unless it was necessary to be quite honest.

It's unfortunate timing but I will be away tomorrow evening and won't be home until the day after (rough estimate of 8:00pm 2026-05-05 - 6:00pm 2026-05-06 UTC) so apologies in advance if I am slow to respond. That feels strange and out of place to say, especially since this isn't a professional communication, but since I suspect this is a fairly specific/isolated issue, it feels wrong to not include and simply go MIA for that time.

Code of Conduct

• I agree to follow this project's Code of Conduct

[SirRob008]

Hello
on my esp32 i have the same problem.
I user sk6812 Leds.
When i connect the leds the esp32 go offline on wled 15.5 no problems.
If the esp32 only on USB Power the esp32 is online.

lg
Peter

[DedeHai]

please check the newly added pin info for conflicting pins with your setup in 16.0. Also make sure you have it wired as recommended (especially the capacitors) https://kno.wled.ge/basics/wiring-guides/

[netmindz]

A few users in discord have reported that the brownout detector triggers when running 16 but not 0.15, fixing their incorrect power setup resolved their issue

[SirRob008]

Hello Why does this work with the old version and not with the new one? Lg Peter

…

________________________________ Von: Damian Schneider ***@***.***> Gesendet: Dienstag, 5. Mai 2026 08:27 An: wled/WLED ***@***.***> Cc: SirRob008 ***@***.***>; Comment ***@***.***> Betreff: Re: [wled/WLED] [16.0.0] ESP32 crashes (?) when powered through something other than USB (Issue #5570) [https://avatars.githubusercontent.com/u/6280424?s=20&v=4]DedeHai left a comment (wled/WLED#5570)<#5570 (comment)> please check the newly added pin info for conflicting pins with your setup in 16.0. Also make sure you have it wired as recommended (especially the capacitors) https://kno.wled.ge/basics/wiring-guides/ — Reply to this email directly, view it on GitHub<#5570 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXJ4FYVMFU675I3AGZQ5VUL4ZGCWXAVCNFSM6AAAAACYQ4EDQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNZWHE3TKNRXGE>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[DedeHai]

Why does this work with the old version and not with the new one?

#5571 (comment)

[softhack007]

Why does this work with the old version and not with the new one?

#5571 (comment)

@SirRob008 the typical driver of "brownout" resets is a combination of

1. cheap LDO + cheap radio design (especially on cheap "mini" and "supermini" boards)
2. Higher current draw especially during wifi activity (including wifi scan / re-connect / wakeup from wifi sleep)
3. too high or too low voltage supplied to the boards (some LDOs are very nasty about this - the sweet spot seems to hide somewhere between 4.9V to 5.2V - like the default USB voltage).

Our software has very little control over these factors - wifi is handled by espressif framework code where we cannot change anything. Adding capacitors to the 5V/3.3V rails provides a buffer for higher current draw (cheap LDO problem). That's why we recommend this as good practice. Some changes in 16.0.0 (different wifi scan method, plus changes in the tasmota framework (see #5568)) make WiFi activity "longer" in some environments. Normally the ESP32 can handle it, but it creates additional pressure for "cheap LDO" which may now need a capacitor to help stabilize internal voltage fluctuations.

[DedeHai]

@softhack007 I did some testing. Here is what I found:
the full wifi scan adds a lot of current spikes. This is the 3.3V rail on one of my ESP32 boards that uses the cheap LDO, no additional cap:

gray reference trace is before #5351 the yellow trace is with that PR (full wifi scan)

and here is latest main against that PR:

the spikes go on for much longer...
If I replace the WIFI_ALL_CHANNEL_SCAN with WIFI_FAST_SCAN in wled.cpp the spikes go away again.

Not to say this is the root cause but maybe there is a better way: if the scan could be delayed by 500ms they would not start right at the largest dip, which I assume is the wifi being switched on.

[softhack007]

the spikes go on for much longer...
If I replace the WIFI_ALL_CHANNEL_SCAN with WIFI_FAST_SCAN in wled.cpp the spikes go away again.

if the scan could be delayed by 500ms they would not start right at the largest dip, which I assume is the wifi being switched on.

@DedeHai wow heavy - maybe -D WLED_BOOTUPDELAY=400 would help?

please also test what happens if you comment out the "full wifi teardown" code for re-connecting.

WLED/wled00/wled.cpp

Lines 706 to 708 in c050973

	WiFi.mode(WIFI_MODE_NULL);
	apActive = false; // the AP is physically torn down by WIFI_MODE_NULL
	delay(5); // give the WiFi stack time to complete the mode transition