WT32-ETH01 hangs on boot after PSU power up

Hardware
1

I’m currently working on a solution to power some SK6812 LED strips using a WT32-ETH01 Board which has an ethernet port I intend to use to improve reliability of my lighting.
I am using 2x 470 uF Capacitors with a 8A Fuse (which matches max output for my currently used PSU) for shared power to the strip/ESP32 and a 68R for the data line. PSU is Meanwell LPV-60-5. This seems to be in line with the recommendations and I expected it to work. It does, kind of, until the PSU loses power from a switch or outage or whatever and you want the ESP32 to come back to life.

As soon as my mains power line to the PSU is cut, the ESP32 on my board refuses to boot up after mains power is restored unless 5V line is also cut and restored after PSU power up. I suspected an issue I had read about GPIO12 and flash memory set into low power mode causing a brownout on boot but this does not seem to be the issue.
This also happens when the ESP32 is directly connected to the PSU, though not all the time as oppsosed to my full wiring, I assume capacitors are responsible for that.

ESP32 NodeMCU as well as any ESP8266 I tried show no issues at all using the same PSU.

I now suspect the voltage ramp up to be too slow, causing the ESP32 to brownout on boot. I’m not much of an electronics guy so I would not be able to make accurate measurements, I just used a cheap multimeter seeing 5V output at 4.6V before going to 5.15V. From what I have read, ESP32 might be a bit sensitive to low voltage on boot and this board in particular has to power not only the wifi module but also the ethernet module. For me this would be more of a timing problem than an actual problem with the voltage but this behaviour does counter my goal to improve reliability using ethernet.

Question is, do you think this issue could be resolved with another and hopefully more quality PSU? I haven’t tried disabling the brownout protection entirely which doesn’t seem to be a good idea anyway. As long as I can make the ESP32 boot, it works flawlessly.

I already have another PSU on the way but you guys might have another idea I haven’t thought about yet?

2

I mention this as you seem like you want to hardware tinker and are capable of doing so.

As a test, find a broken toy with 3 AA battery capacity so you can harvest the battery holder. Stuff it with 3 AA’s so you get ~4.5VDC output. Don’t have the LED strip +5V powered / connected to anything. Just the battery box and the esp32/esp8266.

Now use the battery box and connect to your esp board. If it powers right up without a problem every time you test it, just the next test - which might bork your board, but not likely. Wiggle one battery in and out of the holder so it makes and breaks contact very quickly. That capacitor should hold up the voltage a little, but at some point it will droop too low and power off and immediately restart the esp when the battery makes good contact again.

After doing this a few times while observing the NodeMCU’s on-board LEDs, you should have a feel for whether it boots, or hangs, and maybe have a feel for how to prevent it. You can test it right away with the battery holder. You can try a push type toggle switch to toggle the power lead if you want a little more consistency in the on/off/on times.

3

I have been doing something similar with the 5V output, though not battery powered. Until now my only finding is, the Board boots every time, as long as the PSU has been powered on about 1s before connecting 5v to the board. Thats why I assumed there might be an incompatibility with this type of PSU.
I might try with batteries to see if it has any effect, I assume it will boot just fine.

Second PSU didn’t help. As this was the same type and vendor, just with slightly different specs I now have ordered yet a third PSU which also allows 5v voltage regulation. I have also ordered another Board from China to double check if theres an issue with the particular one I am using. But I’ll have to wait a few weeks for the board to arrive.

4

Some more info here. I read through this thread: Due won't start after power off-on, have to reset - #88 by renatodnts - Arduino Due - Arduino Forum
That gave me the idea to simply connect a capacitor between EN and GND which effectively delays the time to reset on boot. That actually helped. I ended up using a 470uF cap, 100uF did not seem to be enough. There is a very noticeable delay, maybe 1.5 - 2 sec and the boards boots just fine, no matter what I do with the PSU on mains side. Problem solved for now (don’t mention my soldering skills…).

IMG_0855
IMG_08554032×3024 2.48 MB

I wanted to see if I could solve the problem not in hardware, but in code (as proposed in the linked thread as well) and therefore compiled WLED with a 1000ms delay in the setup function.
Then I proved myself an idiot. Just as I wanted to flash the custom compiled firmware I accidentally missed the pins for 5V and GND by one and saw the boards VRM go up in magic smoke. Damn, I really should stop late night tinkering with electronics…
Good news is, I might be able to get my hands on another board faster than I thought. Will keep testing.

5

Read through this Power supply for the ESP32 - #6 by Andreas - Stromversorgung / Power supply - Hiveeyes
and what i experienced seems to be a very common problem with ESP32 boards for which the best solution seems to be the capacitor I added. Not sure why the vendors couldn’t address this with a tiny smd cap on the board but at least I can get the board to boot now.

6

Hi @peer69,

Thought you might appreciate the following additional information and I had some questions on potential causes.

There’s a repository on GitHub that has both a WT32-ETH01 Schematic and datasheet.

Bootstrap Pins

As you know, there are six bootstrapping pins that can affect boot: 0, 2, 4, 5, 12 (MTDI), and 15 (MTDO). Here are some expandable sections, so you can skip stuff you know:

How IOs 0, 2, 4, 5, and 15 (MTDO) affect boot

IO0 IO2 Boot Mode
0 0 Download Boot
0 1 Undocumented test modes
1 0 SPI Boot (default)
1 1 SPI Boot

For undocumented test modes, IO4, IO5 and IO15 (MTDO) select which of the undocumented test mode is entered. See this post. Additional details are not, however, known to me.

When in “Download Boot” mode, the chip will accept either SDIO or UART input for boot. In this situation, the SDIO falling/rising edge configuration is determined from IO15 and IO5:

IO15 IO5 SDIO sample SDIO output
0 0 Falling-edge Falling-edge
0 1 Falling-edge Rising-edge
1 0 Rising-edge Falling-edge
1 1 Rising-edge Rising-edge

When in “SPI Boot” mode, IO15 (MTDO) instead defines whether U0TXD outputs debug log during boot.

IO15 BootRom Debug Log output
0 Disabled
1 Enabled
How IO12 (MTDI) affects boot

IO12 (MTDI) is the most interesting pin for this discussion, as it controls the default voltage of the internal LDO. Importantly, the general ESP32 datasheet has the following note:

For ESP32 chips that contain an embedded flash, users need to note the logic level of MTDI. For example, ESP32-D2WD contains an embedded flash that operates at 1.8 V, therefore, the MTDI should be pulled high.

  • IO12 (MTDI) – This defines the voltage of the internal LDO (high = 1.8V, low/default = 3.3V). ESP32-D2WD has internal flash that runs at 1.8V, so MTDI must be pulled high on those boards, for example.
  • IO12 is also known as: ADC2_CH5, TOUCH5, RTC_GPIO15, MTDI,
    HSPIQ, HS2_DATA2, SD_DATA2, EMAC_TXD3
Original firmware bootstrap pins

Pin Value Notes
IO12 0 3.3V flash voltage
IO0 1 SPI_BOOT
IO2 0 SPI_BOOT
IO4 0 not used
IO15 1 Debug output enabled
IO5 1 not used
Testable: Is IO12 the culprit?

On WT32-ETH01, the only bootstrap pin of interest is IO12 (MTDI), as it can cause the voltage supplied to the internal flash to be too low if it reads high.

On the WT32-S1, the schematic shows that IO12 is left floating, with a trace bringing the pin to the exposed header, so only the internal pull-down is keeping the signal low. If you have connected IO12 to a peripheral, then perhaps the peripheral is holding the line high and/or there’s too much capacitance to drain quickly enough for boot?

The good news is that the voltage regulator settings that are affected by IO12 can be forced … using efuse settings. After verifying your WT32-ETH01 board’s settings, you could force them via efuse settings. If the problem persists, then it’s not a problem with the bootstrap value of IO12.

Most likely, it’s not the bootstrap pins, but it’s a possibility often overlooked. Instead, as you suggest, perhaps with ethernet attached, there’s just too high a surge of current required.

If true, that would explain why the large capacitor helps, as it would provide a buffer for those surges. But, that leaves me somewhat uncomfortable as the capacitor size is a guess, and there’s no guarantee it’d be enough for edge cases.

Was there ever a true cause discovered?

7

Hello,

sorry for digging this up, but I’ve the same issue here with my WT32-ETH01. Maybe together we can find some software solution to it.

I’ve tried to add a timeout to WLED, to delay boot but this was not successful. Now I’ve attached the console to enable to debugging and what I can see is:

If it is working (resetting DC power) I can see:
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)

When it’s not working (resetting AC power) I can see:
rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))

So it seems, the device is booting into “programming mode” and waiting for firmware.

@henrygab you’ve talked about efuses, but I haven’t found anything useful yet. So I was not able to configure anything. Maybe you can help, so I can try out a few things?

I’ve set up VS Code with PlattformIO to compile WLED and it seems working fine, I’ve build a few binaries already.

Thanks a lot in adavance.

8

What is connected to GPIO 0? Try moving that to another pin that is boot friendly.

9

NOTE: This only fixes the problem where it can’t read the flash, because the bootstrap pins configured the device to use 1.8V for the on-board flash. Setting these three efuse should result in a final output line:

Flash voltage (VDD_SDIO) set to 3.3V by efuse.

You can get the python script from Espressif’s depot on github.

The relevant fuses on my WT32-ETH01:

Config fuses:

XPD_SDIO_FORCE Ignore MTDI pin (GPIO12) for VDD_SDIO on reset  = 1 R/W (0x1)
XPD_SDIO_REG   If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset = 1 R/W (0x1)
XPD_SDIO_TIEH  If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V = 1 R/W (0x1)

WARNING!

You can PERMANENTLY mess up your WT32-ETH01 device (or any ESP32, really) by applying incorrect efuse settings. Once set to a non-zero value, it cannot be set back to a zero value.

WARNING!

I make no representation, other than it worked for me. Seriously, don’t do this if you aren’t willing to brick your device.

Presuming you can program your WT32-ETH01 using esptool.py...
Serial port WT32-ETH01
RTS EN
DTR GPIO0
RXD TX0
TXD RX0
You'll want to do something along the lines of: 
python ./espefuse.py --port COMx burn_efuse XPD_SDIO_TIEH
python ./espefuse.py --port COMx burn_efuse XPD_SDIO_REG
python ./espefuse.py --port COMx burn_efuse XPD_SDIO_FORCE

Alternative I just learned about:

python ./espefuse.py --port COMx set_flash_voltage 3.3V
10

Thank you so much for your help.

I’ve tested a little today and found, if I connect 3,3 V to IO0 , it’ll boot flawlessly. If I ground GPIO 0, it’ll go to programming mode and wait for firmware as expected.

Other than the reset jumper, nothing is connected to GPIO0

Looks like some undefined voltage on power up. Any idea how to solve it, other than connecting 3,3V?

11

Pull-up resistor between pin and 3.3v?

12

I believe GPIO0 is connected on the WT32-ETH01. According to the schematic, and the WLED supporting code, GPIO0 is connected to the RMII clock for ethernet. That means if the oscillator isn’t properly shut down before boot, it could interfere with boot.

You could try adding a really large capacitor between ground and the enable pin. This will cause boot (at power-up) to be delayed until the capacitor is charged sufficiently.

Pins used on WT32-ETH01

ESP-WROOM-32 Pin Warnings:

IO0 == Used for Ethernet (RMII_EMAC_REF_CLK)
IO1 == TXD (Debug Output at boot)
IO3 == RXD (Goes high at boot), OK for INPUT
IO5 == Outputs a PWM signal at boot

IO6..IO11 == Integrated SPI flash

IO6 == SCK/CLK
IO7 == SDO/SD0
IO8 == SDI/SD1
IO9 == SHD/SD2
IO10 == SWP/SD3
IO11 == CSC/CMD

IO13 == Used for Ethernet (RMII_EMAC_RX_ER)
IO16 == Used for Ethernet (OSC_EN)
IO17 == Blue LED4 connected, turns on when pin low.
IO18 == Used for Ethernet (RMII MDIO)
IO19 == Used for Ethernet (RMII EMAC TXD0)
IO20 == ?? Not exposed ??
IO21 == Used for Ethernet (RMII EMAC TX EN)
IO22 == Used for Ethernet (RMII EMAC TXD1)
IO23 == Used for Ethernet (RMII MDC)
IO24 == ?? Not exposed ??
IO25 == Used for Ethernet (RMII EMAC RXD0)
IO26 == Used for Ethernet (RMII EMAC RXD1)
IO27 == Used for Ethernet (RMII EMAC CRS DV)
IO28…IO31 == ?? Not exposed ??

Pins that may be available on WT32-ETH01

IO2, IO4, IO14, IO15 == AVAILABLE for input and output
IO12 == AVAILABLE for input and output, but if not using EFuse to set the flash voltage, then boot will fail if the pin is high at boot.
IO32 == Probably available for use? Marked as “IO32_CFG” in schematic, but nothing connected
IO33 == Probably available for use? Marked as “IO33_485_EN” in schematic, but nothing connected
IO34..IO39 == Input-only pins, but nothing appears connected to them in schematic

Hope that helps…

1 Like
13

Hi,
I’ve stumbled accross this thread as i’m also having issues with the WT32-ETH01 booting on AC PSU power on. if i disconnect the DC supply, power the PSU, and then connect the PSU output to the WT32-ETH01, all is fine. but if AC power is just applied to the complete assembly, the WT32 won’t boot properly.
I’m just wondering how the solutions in this thread have been getting on. @peer69 is the cap trick on your May 28th post proving to be reliable?
Maybe @fefaul 's pull up resistor for IO0 is a good thing to try.
WLED is driving LEDs on pin 2 (default)
Thansk for any help you are able to offer
MSE

14

Haven’t been digging into this much more as there was too much to do in the house beyond lighting.
The Capacitor I added has proven to be reliable to me. I don’t switch AC very often but as PSUs aren’t easy to reach this keeps me from losing my mind, whenever I need to switch AC power or whenever an outage may occur.
Still not sure whether this might be the best solution but for my boards this works flawlessly with the cap added as described.

15

I’ve given up on using the WT32-ETH01 boards for any “real” use, because I found them too unreliable.

I still keep them around, as the form factor is great for quick projects, where I always have easy access to toggle power. Price is unmatched for those quick projects.

For “real” projects, I would consider spending a bit more:

  • TwilightLord sells an ESP32 board (d1 mini32 form factor) with 16MB on-chip flash, heavy-duty LDO (and he sells an ethernet shield too)

  • QuinLED-Dig-Quad provides five(!) output ports, with fusing, and has an ethernet option.

  • The wESP32 looks amazing, and would work well for props with lower wattage requirements.

But, if it’s just a quick prototype that will remain on your workbench, the WT32-ETH01 works OK … but definitely add the capacitor.

16

To echo @henrygab, I am seeing too many issues with the WT32-ETH01 board for it to be considered reliable. I simply swapped out an ESP8266 with the WT32-ETH01 (for the better wired bandwidth) and have had issues with it constantly resetting as well as this power-up issue. I’m going with a Dig UNO or Dig Quad instead for my display.

1 Like
17

Sorry to post on an ancient thread, but if anyone else comes here looking for answers, I have notes here, including a discussion of the reset circuit issue: GitHub - egnor/wt32-eth01: Bits and bobs related to Wireless-Tag's WT32-ETH01 board. Maybe it’s helpful.

2 Likes
18

I was having similar issues with my WT32-ETH01. My solution was to use one of these £0.05 Padauk micros to hold the enable pin low for a few seconds while the rest of the board powers up.

19

i note that this board is now on version 1.4 on AliExpress: https://www.aliexpress.com/item/1005001930750808.html
…but i can’t see what’s changed. could the improvements improve the ‘hang of boot’ issue?
(my boards are version 1.3)

1 Like
20

There’s a version with POE? possible?
this is the EVO version WT32-eth01 EVO