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

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

I just wanted to add a +1 for having the 470uf capacitor connected across 3v3 & ground.

My newer WLED setups (probably built within the last year or two) took v16 without issue and do not have the 470uf capacitor (Lolin ESP32 S2 Mini, ESP32 C3 Super Mini [external antenna], and QuinLED-ESP32 [onboard antenna]).

Some of my other WLED setups are very, very, old (MH-ET Live ESP32 [probably clones?]) and I wasn't aware the capacitor was recommended; I don't think that page existed when I originally built them.

I had 3 built with these MH-ET Live boards and all 3 were experiencing the brownout issue on v16 but adding the capacitor 100% fixed them and they work perfectly again!

Thank you for th…

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

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/

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

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: ***@***.***>

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

#5571 (comment)

@SirRob008

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

cheap LDO + cheap radio design (especially on cheap "mini" and "supermini" boards)
Higher current draw especially during wifi activity (including wifi scan / re-connect / wakeup from wifi sleep)
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.

@softhack007

@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.

@DedeHai

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

A little update from myself, one of the users on the Discord server added a cap in the following manner and for him it solved the not being able to run WLED v16 issues. I'm slightly confused by that because there is plenty of capacitance on the board and from all signs it seemed to be the DC-DC circuit on the Dig-Uno/Quad, not the ESP32 board (since it worked from USB) but whatever the case, this might be a quick hardware fix you can do if you can solder.

Exact same thing I did to my two boards.

Confirming, just fixed 6 AE versions of the boards with this.

Awesome to hear it, still apologies this is needed, although it's hard to predict what happens 4 years later, I do try to build my hardware as robust as possible!

Just chiming in to say I have a number of A1-SLWF-03 WLED boards that are having this issue as well. I'm not sure of the exact model of ESP32, but after flashing to 0.16.1, regardless of powering via USB-C or DC-12V/5A power supply, the device seems to continually crash every time it tries to connect to or start up a WiFi AP. 0.15.4 seems to work fine still. I'm guessing more devices will pop up with this issue as time goes on.

If there's some mitigation on the software side that could be done to deal with it, it would be nice.

I have a number of Gledopto GL-C-010WL (ESP32) devices which were exhibiting similar symptoms described in this issue. I found that the problem mainly manifested when used with a set of 50 bullet led string with both 16.0.0 and 16.0.1, previous version 0.15.4 worked with no problems. Under 16.0.1 the CPU would appear to lock up/hang and in some cases the LED's pattern would freeze. After experimenting with the MAX TX power (changed from 19.5dBm to 8.5dBm) and unticking the "disable WIFI Sleep" I was able to get the GL-C-010WL to work as expected - I suspect unticking the disable WIFI sleep was my actual fix. Hope that might help, your mileage may vary.

In the run up to holiday season I did some testing:

Dig-Uno boards v2r6b, v3r7 and v3.5r3 with a Mini32 v1.0.0 ESP32 board.
None would boot WLED 16.0.1 and connect to WiFi or do any LED animation. When removed from the Dig-Uno and connected to USB the ESP32 would boot and connect to wifi successfully.

I've not tried the capacitor fix.

In my case, having "Disable WiFi sleep" ticked or unticked didn't make any noticeable difference.

For me, changing WiFi "Max TX power" to 8.5 dBm or lower seems to work. I don't know if this will be stable over time. With 13.5 dBm configured running in the v3.5r3 I got a notice about a brownout on the wled admin web page.

v3.5r3 is the latest board revision according to https://quinled.info/quinled-dig-uno-pre-assembled-revision-history/

For those of us running Dig-Uno, can we expect a revised board any time soon? Have there been any reports of v16 failing to boot on Dig-Next-2, which could be an alternative. I have one on order and will update if I experience any issues.

@mike2038

I've not tried the capacitor fix.

For me, changing WiFi "Max TX power" to 8.5 dBm or lower seems to work. I don't know if this will be stable over time. With 13.5 dBm configured running in the v3.5r3 I got a notice about a brownout on the wled admin web page.

@mike2038 a brownout warning is actually a strong indication that you should add the capacitor. A brownout only happens when the 3.3V voltage drops below minimal voltage, and a capacitor can help to stabilize the 3.3V power rail.

@mike2038

Interesting @mike2038 Having all those revisions fail probably points to something else not keeping up, like the PSU you are using. There are lots of users running WLED v16 on the QuinLED boards over various revisions although the really old versions do seem to show more issues with v16.

I have done some tests using my bench power supply and some meanwell power supplies and I actually haven't been able to get them to brownout at all, even when running at 5V (which is likely the voltage that would be the most difficult).

There is an upcoming v4 revision which does have a new DC-DC stage on there but not so much for the reason of this issue since we haven't really seen any reports with the current revision.

@intermittech

@intermittech I have several dig-quad boards (some v2 some v3) running lights at my house and another v3 running lights at my parents' house. They're all running WLED 0.14.1 and I was looking at upgrading to WLED 16 and ran across this issue. I'm running all of them with 5v constant with a relayed 12v PSU.

You mentioned above that we could fix the problem by hardwiring in a buck converter into the main 12v input and taking its output and plugging that into the ESP32 board. Will that solve the problem for the case where the 12v PSU is connected through a relay? Because then the ESP32 won't be powered from the buck converter until the 12v PSU is enabled when the relay turns it on. Does this problem not happen when the dig-quad is only powered by 5v and not by the main 12v?

Also, it sounds like this has something to do with power spikes during a wifi scan, does this affect dig-quads running with RJ45 hats on the ESP32 unit that are hard wired?

Thanks!

@slideroi

@slideroi Ah, for the case where you have a 12V PSU that is switched off and only a 5V remains it becomes a bit more complicated. The idea is to give the ESP32 board a stable power source over it's USB-C so that when for whatever reason the DC-DC converter on the Dig board can't keep up, it's kept alive basically.

The issues are surrounding the ESP32 WiFi scan which uses more power since the new IDF. I do not know if using Ethernet solves that issue since I haven't really been able to reproduce the issue reliably over here.

I thought that might be the case. So maybe the solution for me would be to not only provide the dig-quad board with constant 5v but also a direct 5v to the ESP32 as well. Makes it a bit more complicated of a setup, but if it let's me upgrade to WLED 16 without frying anything I think it'll be worth it.

Thanks!

I’ve done further testing.

Using the mini32 v1.0.0 module on top of Digiuno versions I mentioned above I had issues with wled v16; both not booting reliably but also occasional brownout warning messages.

Using QuinLED-ESP32 v2r2 modules running wled v16 with the same Dig-Uno boards worked reliably for me.

Reducing the WiFi TX power did help improve the mini32 module stability.

Adding a 470uF to the mini32 module (across 3.3V and GND) seems to have fixed the stability issues.

I don’t have any suggestion that the issues I experienced are due to the Dig-UNO boards themselves but rather the ESP32 module on top.

Given the ESP32 chips only run on 3.3V this suggests a 3.3V regulator issue and this isn’t on the diguno board itself. Still doesn’t explain why my module works when connected via usb. Maybe there is some electrical separation between 5V sources from the module pins vs from the usb connector.

@mike2038

Aaah ok, that makes more sense @mike2038 !

So there are 2 things that can come into play to cause these issues.

The DC-DC circuit on the Dig-Uno/Quad can be too slow to keep up with the new high transients (quick spikes), early versions of the Dig-Uno/Quad seem to have this issue sometimes, more recent versions (last few years) do not as far as I'm aware of.
The 3.3V circuit on the ESP32 module can't keep up and brownout. Again my modules from the last few years should not suffer from this but even my first modules have large capacitances to try and prevent this. Modules such as the mini32 are indeed known for it, which is why I stopped using those at designed my own many years back.

Likely the 470uF on the ESP32 board is the fix for both, it gives the 3.3V rail enough buffer that if whatever is powering it (the 3.3V LDO or the DC-DC circuit) can't keep up for a split milisecond it comes back before the big capacitor is empty thus not browning out.

@intermittech

@intermittech
If it helps to have any other examples, I have a QuinLED v1r3 white board, in a Dig-Quad, with external antenna, and get this issue. Works fine powered by USB-C but not when in the Dig-Quad.

I added a 470uF 35V capacitor across 3.3V and GND but still seem to have the same issue.

I power the board with an external 5v PSU in case that affects anything - maybe I need a capacitor on the 5v rail too?

I'll just revert back to v15 for now, but happy to try other options if you want them testing 🙂

Navigation Menu

Repository navigation

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

What happened?

To Reproduce Bug

Expected Behavior

Install Method

What version of WLED?

Which microcontroller/board are you seeing the problem on?

Relevant log/trace output

Anything else?

Code of Conduct

51 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	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

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

Description

What happened?

To Reproduce Bug

Expected Behavior

Install Method

What version of WLED?

Which microcontroller/board are you seeing the problem on?

Relevant log/trace output

Anything else?

Code of Conduct

Activity

SirRob008 commented on May 5, 2026

DedeHai commented on May 5, 2026

netmindz commented on May 5, 2026

SirRob008 commented on May 5, 2026

DedeHai commented on May 5, 2026

softhack007 commented on May 5, 2026

DedeHai commented on May 6, 2026

softhack007 commented on May 6, 2026

51 remaining items

intermittech commented on Aug 22, 2026

Ragingfire105 commented on Aug 23, 2026

7oku commented on Aug 24, 2026

intermittech commented on Aug 24, 2026

maxgoldberg commented on Aug 30, 2026

tvgriffith commented on Sep 7, 2026

mike2038 commented on Oct 4, 2026

softhack007 commented on Oct 4, 2026

intermittech commented on Oct 6, 2026

slideroi commented on Oct 7, 2026

intermittech commented on Oct 8, 2026

slideroi commented on Oct 9, 2026

mike2038 commented on Oct 9, 2026

intermittech commented on Oct 10, 2026

StephenGoodall commented on Oct 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions