Multiple ESP32 boards randomly reboot

[Daro66]

Hi,

As always, any help is greatly appreciated.

I’m having a reboot issue on a few different ESP32s dev boards. They reboot circa every 4 to 15 minutes, but even in the “off state” they reboot, which is annoying especially if a sleep timer is set…

This is the case with all audio-reactive builds from 14.4 - 15.0-B5

I’ve tried changing GPIO pins, adding and removing the inline resistors to the LEDs, turning most options under “Sync options” and “Led preferences” off in case it’s a memory issue, and disconnecting the LEDs in case it’s a power issue.

I don’t know if there’s an option to activate debug output, but this is what I get when I connect a terminal to the USB port:

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (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:DOUT, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
▒Ada
abort() was called at PC 0x4014e6be on core 1

ELF file SHA256: 0000000000000000

Backtrace: 0x4008b610:0x3ffb1e40 0x4008b96d:0x3ffb1e60 0x4014e6be:0x3ffb1e80 0x401bba34:0x3ffb1ea0 0x401bb9f9:0x3ffb1ec0 0x4012b40f:0x3ffb1ee0 0x401379d6:0x3ffb1f20 0x4011b999:0x3ffb1f40 0x4011bf5e:0x3ffb1f90 0x4013cc89:0x3ffb1fb0 0x4008d3f6:0x3ffb1fd0

Rebooting...
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x13 (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:DOUT, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5828
entry 0x400806a8
Ada
abort() was called at PC 0x4014e6be on core 1

ELF file SHA256: 0000000000000000

Backtrace: 0x4008b610:0x3ffb1db0 0x4008b96d:0x3ffb1dd0 0x4014e6be:0x3ffb1df0 0x401bba34:0x3ffb1e10 0x401bb9f9:0x3ffb1e30 0x4012b40f:0x3ffb1e50 0x40115872:0x3ffb1e90 0x4011b90e:0x3ffb1f40 0x4011bf5e:0x3ffb1f90 0x4013cc89:0x3ffb1fb0 0x4008d3f6:0x3ffb1fd0

Rebooting...

and so on…

EDIT 1: this is what the reboot transition looks like. Unfortunately videos can’t be uploaded… Segment 2 mostly lights up white, but segment 1 stays frozen. After a brief pause both segments return to the boot preset.

[divsys]

Where are you getting your builds from?
Have you set (remove if set) the “Disable WiFi sleep” option in Config->WiFi?
What do your power connections (and/or general wiring) look like?

What happens if you load a non-SR version of WLED?

[Daro66]

Thank you @divsys!

@divsys

Where are you getting your builds from?

When flashing the new modules, I use the PC and the official web installer. There I select the current beta and select the audio reactive option. After they are installed, I get the current binary from GitHub and install it with the Manual OTA Update option. The most current is from @blazoncek’s dropbox (WLED_0.15.0-b5_ESP32_audioreactive.bin).

@divsys

Have you set (remove if set) the “Disable WiFi sleep” option in Config->WiFi?

I haven’t before, but I just tried, and toggling the setting makes no difference.

@divsys

What happens if you load a non-SR version of WLED?

I installed the WLED_0.15.0-b5_ESP32.bin version from the UI, but that doesn’t seem to make a difference so far.

@divsys

What do your power connections (and/or general wiring) look like?

Where you see two wire connectors together, there’s a 220 ohm resistor inline with the LEDs’ data inputs.

This one runs directly from a usb plug

This one is a bit more power hungry:

I have two of the smaller version and the bigger one. I set the three to do UDP sync on a non standard port so they can share the same effects, palettes, and segment configuration (ie. mirrored, reversed, etc.). If it were only these three, I’d think it was related to that, but I have some strips on my bed with a different controller, that doesn’t listen on UDP, that does the same thing, even if none of the three are powered up.

[Daro66]

I just realized something that might be relevant. I’ve been doing quite a few projects, and decided to have an (1) ESP32 for setups. I’d get everything going the way I want, and then export the configuration. Then I’d flash the permanent ESP32 and restore the exported configuration, change any pins, the server description, and mDNS name.

Perhaps there is something else than needs to be unique?

On the other hand, there are devices that work fine, so that kind of defeats the case, unless there are some internals that could make it a realistic scenario…

[divsys]

I’d drop the 220R resistor, but definitely add a proper levelshifter.

The USB setup definitely looks a little lightweight for driving LEDS. Best to try and give the ESP (and/or the LEDs) a proper power supply.

As far as copying the configuration forward, you could try and load a board from scratch and manually entering the config data. Even if you do a very “cut-down” version for testing.
That way you can eliminate possibilities from your full config.

I’d also start with a base WLED install to debug the reset issue. Once that’s resolved you can go back up to SR and your full config.

[Daro66]

@divsys

I’d drop the 220R resistor, but definitely add a proper levelshifter.

I put an oscope on it and the signal looks fine. I did try skipping the first led to achieve a level shifter, but that also didn’t help…

I could try adding a “real” one, but that’s going to take a while.

@divsys

The USB setup definitely looks a little lightweight for driving LEDS. Best to try and give the ESP (and/or the LEDs) a proper power supply.

I measured the current at the levels I use, and there is no concern there. There is barely voltage drop until the LED runs.

@divsys

As far as copying the configuration forward, you could try and load a board from scratch and manually entering the config data. Even if you do a very “cut-down” version for testing.
That way you can eliminate possibilities from your full config.

I’d also start with a base WLED install to debug the reset issue. Once that’s resolved you can go back up to SR and your full config.

I’m going to try that next, but it’s going to be a few days before I can peruse this any more.

Thank you for your input!

[Jinx]

A year or so ago in discord someone was having issues with their Esp’s rebooting and myself and another person strongly suggested they add a level shifter. The person was quite hard headed and at first was not wanting to do so. Finally they listened and added one and their rebooting issue went away. So it’s worth a try as your setup seems similar. Edit: Actually I think they may have also added a capacitor as well (as described below). I can’t remember.

Another possible thing could be that sometimes your Fx draw more current for a second than the power supply/wire can supply resulting in a power dip to the Esp causing a brownout and the Esp rebooting. That fix would be thicker wire and or a better power supply or the not so great fix of adding a capacitor by the Esp to handle that split second power dip. A good test would be to see if the Esp stays working for a while without any LEDs connected. Just leave the Esp running and check the Info to see it’s UpTime. If it has not rebooted You know the cause is likely power related.

[Daro66]

Thanks for your input @Jinx!

@Jinx

Finally they listened and added one and their rebooting issue went away. So it’s worth a try as your setup seems similar

One of the devices with the issue has logic shifters.

@Jinx

Another possible thing could be that sometimes your Fx draw more current for a second than the power supply/wire can supply resulting in a power dip to the Esp causing a brownout and the Esp rebooting.

The reboots happen even if the power state is off, so I don’t think that is the issue.

[Jinx]

Just for future reference, that I2C shifter you are using a lot of times does not work well with addressable LEDs. A test of different ones can be found here: Levelshifter Analysis

As for them still rebooting when the LEDs are off (black), I would still try disconnecting the LEDs from the controller/power supply just to see if the board still reboots.

Do you have these setup with Home Assistant? If you do HA has been known to poll the Esp too frequently causing lock-ups and reboot issues.

[Daro66]

@Jinx

HA has been known to poll the Esp too frequently causing lock-ups and reboot issues.

No. I don’t use HA.

[Daro66]

Honestly, im a bit confused. I found one more setting that was unique in the interface settings. I’m away from home at the moment, but I think it’s for MQTT, and at first glance resembled a name with a portion of the MAC address. I changed that too, and rebooted all of the devices via their web interfaces. I didn’t expect anything to change as MQTT is deactivated (afaik). The issues continued, and I left for a few days.

When I got back and plugged everything back in, I had no issues. I tried many things, but the ESPs no longer reboot. Now I don’t know exactly what helped, unless the UI reboot doesn’t reset really everything… Curious…

Edit 1:
MQTT was correct.

[Daro66]

@Jinx

Just for future reference, that I2C shifter you are using a lot of times does not work well with addressable LEDs. A test of different ones can be found here: Levelshifter Analysis

Interesting. I guess all my projects until now have fallen in the category of will work with or without level shifters. I just did a project with panels of 2304 LEDs and it flashes and flickers all the time. I added an I2C level shifter, and it got worse. Adding 10k Ohm pull up resistors to the shifter’s outputs immediately got things working properly.

On a side note, and equally interesting is that using 68 Ohm resistors between the GPIOs and data in lines OR skipping the first LED in each segment also solves the issue. The big difference is that all else equal, subjectively the LEDs are brighter with the level shifter or skipping the first LED in each segment. I assume the latter is because the skipped LED acts as a Schmitt Trigger and takes the place of the level shifter.

Although I don’t feel it’s always a necessity, now that I’ve experienced it, I won’t blow it off as a one off… Thanks again!

[divsys]

I2C shifters are not worth the effort to “try and make them work” IMHO.
a 74AHCTxxx device is no more expensive and guaranteed to be more reliable when used properly.

Save yourself some grief in the future and change over now.

[Daro66]

Thanks @divsys. When you say:

@divsys

Save yourself some grief in the future and change over now.

do you mean that they go bad, or that they are a hassle to get working? I have a bunch of them laying around, so if it’s just a matter of more difficult, I can live with that. I’ll definitely go with the 74AHCTxxx after that.

A question about those shifters: Ignoring the package type, there are still several different models, which is best suited for general purpose LED applications?

[divsys]

In general, the design specs of the I2C based shifters is marginal at best. They’re too close to “not working” to be a reliable solution.

The 74AHCTxxx devices are very robust, their design specs are far better than what’s needed for LED data, they need only a 5V supply, they’re very effective, and to top it off, they’re cheap.

As far as the “best device” there are literally hundreds of possible devices, any of the simple logic gates in the 74AHCT family will work equally well. It really depends on how many data channel you need, here’s a list of more common choices.

• 74AHCT32 4 channel OR gate => handles up to 4 data lines
• 74AHCT125 4 channel Tri-State buffer => handles up to 4 data lines
• 74AHCT245 8 channel Tri-State buffer => handles up to 8 data lines

The KB has wiring diagrams for all of those types.

I personally like the '32 or the '245. I’ll order them in their SOIC packages (SMD, very small) and then use a small SOIC->DIP adapter board to make it easier to wire them to projects. Gives the best of both worlds (SMD size vs ease of wiring) IMHO.

[Daro66]

Thank you!