Aircoookie
WT32-ETH01 Error 8 Effect RAM depleted
What happened?
If you install v 15.1 or 16 alpha (I didn't try 15.2 but I suspect it's the same) and go and enable the WT32-ETH01 Ethernet type and then power cycle the board, it then presents that error at the main GUI page and is nonfunctional.
To avoid this issue:
- Install with web installer at https://wled-install.github.io/ -Key step to avoid error Before enabling the Eth type: Go to LED Pref' and change the default gpio for output one (I changed from 16 to 2, but I think anything would work)
- Save
- Go back to Wifi settings and enable Ethernet Type: WT32-ETH01
- Power cycle the board and the error is not present.
To Reproduce Bug
Install from https://wled-install.github.io/ Enable Eth type WT32-ETH01 Power cycle board Visit main GUI
Expected Behavior
There should be no error
Install Method
Binary from WLED.me
What version of WLED?
15.1, 16a
Which microcontroller/board are you seeing the problem on?
Other
Relevant log/trace output
Anything else?
No response
Code of Conduct
- [x] I agree to follow this project's Code of Conduct
@x-Jinx-x I agree with you that "RAM depleted" is a very unexpected reaction to enabling ethernet. It could be that the ESP32 has some other troubles due to ethernet, and "ram depleted" ist just an erratic and random consequence of a bigger issue.
I found this older problem report that explains an ESP32 hardware bug that affects ethernet boards, maybe that's related:
- https://github.com/wled/WLED/issues/4703
If you want to help us reproduce your problem, please upload cfg.json and presets.json from your board.
We can put these files directly onto one of our developer boards and check if the problem can be reproduced.
If you have privacy concerns, no problem you can replace the wifi name and ip adresses by dummy values before uploading your files.
@softhack007 I have flashed 6 different WT32's in the past month and all of them would do the error 8 if I did not edit the gpio before enabling the Ethernet. I wasn't fully able to test my solution till now, as I was flashing first 5 for my light show. With some of them I even removed all the audio reactive pin assignments as part of my 'getting it to work answer lol'. Along with that I also flashed 14.4 and then OTA to 15.1 and 16a (on 1 of them).
-The 6th one I flashed yesterday now that I have more time and don't 'need' the board, to confirm my solution and to also aid in helping a couple people in the WLED FB group that are/were having issues.
All boards were new 100% default installs. No presets and no wifi configured. I was setting them up from WLED-AP and did not enter wifi details, as I had planned to use them wired and did not want any conflict. Also never touched the ESP Now settings.
2 different PC's were used. Some flashed with one and some with another.
1 WT32 was from Amazon and the rest were from Ali express. The ones from Ali were from 3 different sellers and are not all exactly the same stamping on the heat shield. I think all 6 of them say v1.4 on the pcb (including the one from Amazon). -I can check if it matters?
For the bug to happen there is no need to ever connect a ethernet cable.
- Just flash the board
- Power cycle it
- Connect to WLED-AP
- Enable Eth Type: WT32-ETH01
- Save
- Power Cycle
- Connect to WLED-AP
- Click 'To the controls'
- Main GUI loads with error 8
If I edit the LED Output 1 GPIO and save before step 4 the error does not appear.
With this board #6 I flashed it with 16a and did the above 9 steps to make sure the error would happen. It did
So I reflashed it; steps 1-3 and did my edit output 1 from 16 to 2 and saved it then did the rest of the steps 4-9 Only this time when the GUI loaded there was no error 8.
To make sure I wasn't crazy lol. I then reflashed it again with steps 1-9 without doing my fix and bam error 8 was back.
I can still provide you with the config and presets if you like, but they are 100% vanilla. I never even added wifi details.
- I am going to run another test and see if it works. 1 person I gave my first advice to about the flashing 14.4 and OTA'ing and also removing all the audio reactive pins said he got a previously flashed one that had error 8 working when he removed the audio pins w/out changing the LED gpio. I will test that in a min and post back :)
@softhack007 Ok just did another test to see if what someone said about removing audio reactive pins fixed things and what I tried didn't work so I think they must have edited LED output 1 and just forgot they did so... :
Steps 1-9 on tonight's nightly 16a and got the error.
After seeing the error I went directly to Usermods and removed all the pins for AR and hit save. Went to LED Pref and was going to edit LED 1 and saw/remembered something: *Once you have error 8 and you go into LED Pref there is no longer an LED Output 1 configured. It is gone. If you try to add one and try to type in 16 for the pin it turns red. If you try to save, it pops up saying: Sorry, pins [6,7,8,9,10,11,24,28,29,30,31,21,19,22,25,26,27,16,23,18,0] can't be used. Again fresh install none of those pins were configured for anything by me.
So I tried entering IO 2 as it was not listed in that popup. It let me enter it and save, but when I go back into LED Pref' there is again no LED 1 Output. (error 8 still present at main GUI)
Next test:
Steps 1-3 Then: Went to LED Pref and did not edit output 1 IO. All I did was hit save (to test if editing the value was even required). Did steps 4-9 and error8 is there. So just hitting save in LED Pref is confirmed to not be enough to fix the bug. Looks like the IO value must be edited.
Another test:
Steps 1-3 Then Went to Usermods and removed all AR pins and hit save. Did steps 4-9 and still error 8. So confirmed changing AR pins does not fix the problem.
Last test to reconfirm:
Steps 1-3 Then did my fix of changing LED output1 IO from default 16 to 33 this time, just to make sure my value of '2' is not the fix and that changing the value is the true fix. Did steps 4-9 and no error 8. So it looks like entering any new value for the IO will fix it.
I lied 1 more test for science lol
Steps 1-9 BUT I flashed 14.4 Eth build without AR mod and there is no error 8. Cheers!
TY Dev's WLED is amazing. If there is anything else I can provide just let me know.
P.S. I could flash this thing with my eyes closed now 😂
I just noticed something from reading the other recent Ethernet bug report someone made and noticed something in networks.cpp
// WT32-EHT01 // Please note, from my testing only these pins work for LED outputs: // IO2, IO4, IO12, IO14, IO15 // These pins do not appear to work from my testing: // IO35, IO36, IO39 { 1, // eth_address, 16, // eth_power, 23, // eth_mdc, 18, // eth_mdio, ETH_PHY_LAN8720, // eth_type, ETH_CLOCK_GPIO0_IN // eth_clk_mode
It says IO 16 is eth_power So the board having a default config with 16 in LED Output 1 is likely causing the conflict when you enable WT32' as the Eth' type. Back in v 14.4 The default LED Output 1 is defined, but the IO is left empty for the user to config and on 14.4 if I try to enter IO 16 it turns red and is unable to be used (guessing because it's used for eth_power?) 🙂
Pins that work for WT32-ETH01 are 2,4,12,14,15,17,5,33. You can also probably use 32 as an output. If you use any of the Ethernet pins you'll run into issues. When I compile for the WT32 I go to my platformio override file and just define those pins as LED outputs so there aren't issues. Pin 16 would be one to avoid.
On Wed, Dec 3, 2025 at 10:39 PM x-Jinx-x @.***> wrote:
x-Jinx-x left a comment (wled/WLED#5155) https://github.com/wled/WLED/issues/5155#issuecomment-3610356765
I just noticed something from reading the other recent Ethernet bug report someone made and noticed something in networks.cpp
// WT32-EHT01 // Please note, from my testing only these pins work for LED outputs: // IO2, IO4, IO12, IO14, IO15 // These pins do not appear to work from my testing: // IO35, IO36, IO39 { 1, // eth_address, 16, // eth_power, 23, // eth_mdc, 18, // eth_mdio, ETH_PHY_LAN8720, // eth_type, ETH_CLOCK_GPIO0_IN // eth_clk_mode
It says IO 16 is eth_power So the board having a default config with 16 in LED Output 1 is likely causing the conflict when you enable WT32' as the Eth' type. Back in v 14.4 The default LED Output 1 is defined, but the IO is left empty for the user to config and on 14.4 if I try to enter IO 16 it turns red and is unable to be used (guessing because it's used for eth_power?) 🙂
— Reply to this email directly, view it on GitHub https://github.com/wled/WLED/issues/5155#issuecomment-3610356765, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGGPSXHQM5RFT324JOXCLCD377CKDAVCNFSM6AAAAACN3TOBHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMJQGM2TMNZWGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Exactly. The issue is that the default build for Esp32 with Eth is setup with 16 as the default LED pin and if someone enables Eth type WT32-ETH01 before changing it, it breaks the firmware. Someone enabling Eth before configuring their LED pins is a very plausible thing, seeing that setting up your network settings is normally the first thing you do in WLED.
and Yes 32 works. I use it for my relay.
Pins that work for WT32-ETH01 are 2,4,12,14,15,17,5,33. You can also probably use 32 as an output. If you use any of the Ethernet pins you'll run into issues. When I compile for the WT32 I go to my platformio override file and just define those pins as LED outputs so there aren't issues. Pin 16 would be one to avoid. …
it looks like the problem is caused by the default LED pins?
Well this might get complicated. To have a solution that works for all ethernet boards, we need to avoid any PIN which is needed for at least one of them. I've tried to summarize the situation in this table, also considering the source code comments about "other PINs that seem to work":
To have a save default pins configuration for all possible ethernet boards:
- LEDPIN = 4
- disable all audioreactive PINS
- disable button 0
- disable I2C and SPI
- disable Relay and IR
- disable esp-now remotes support (crashes for ethernet boards that use esp32 as the PHY clock source ==> #4703 )
- disable WLED-AP ?? (same reason - some boards will crash)
- not sure which second PIN to use for "dotStar" type 4-wire LEDs
All the "WLED default pins" can be changed, however to have a safe initial configuration for ethernet, most default pins in WLED would become "-1" = unassigned.
Yea, I'm not sure of the best solution aside from not assigning a default pin and just leaving the field empty for the user to input it like on 14.4. I guess it could be programmed for the pin assignment to change when the user selects their Eth type, but that could cause the user to lose their configured pins if they happened to set those before enabling Eth.
Maybe have a warning above the Eth drop down saying that when enabling Eth all pin assignments are cleared and need to be reassigned by the user and have it clear all assigned pins upon Eth type selection/save?
Well, we could change the [env_esp32_eth] build environment in platformio.ini, to disable and remove all the features i've listed above. this can be done without any extra coding.
A few things could become a PITA, like not having button0, and not having WLED-AP or any esp-now support due to this stupid esp32 chip error related to PHY clock.
assigning a default pin and just leaving the field empty for the user to input it like on 14.4.
My concern is that, while this would be good for Ethernet, it would be a step backwards for all other users.
Our new usage statistics shows that ethernet is an important use case, but - with reference to an important book from the 1980's 😉 :
I don't know. lol
I would have to think the most likely problem for a user to encounter would be that default IO16, because normally the first thing you do is setup your network. As for the PHY clock thing....... That may need to be just in the docs stating that you can't use the wifi/esp-now at ALL if Eth cable is connected?
Unless the firmware can be somehow programmed to sense when Eth is connected and then disables the Wifi chip till Eth is disconnected. (guessing unlikely)
I can understand that the current # of Ethernet users is way below the regular Esp32 users, but why would someone buy a board with ethernet and want to use wifi?
don't think too much about the numbers - it was meant with a "smile". The book was "The Hitchhiker's Guide to the Galaxy" 😇
The main reason for the problematic LED pin is that LEDs drivers are started very early, while the ethernet drivers are coming in late, around 5-10 seconds after boot. So the LEDs driver has already "grabbed" pin 16 and started to send ws2812b data to it, causing all kinds of crazy stuff.
I don't know if there is a way to sense ethernet presence, but it would surely be an option to use pin 4 as default LED pin for ethernet builds. Plus disable button0 because it conflicts with ethernet clock input.
don't think too much about the numbers - it was meant with a "smile".
Gotcha 😊
but it would surely be an option to use pin 4 as default LED pin for ethernet builds.
Yes, as long as the AR assignments don't conflict with other Eth boards 😂 I'm thinking things would only break if the user turned AR on for that to happen though?¿?
I'm thinking things would only break if the user turned AR on for that to happen though?¿?
yes - but AR (and all other usermods) reserve their PINs at startup, even when the usermod is disabled (a very old problem). So AR can prevent ethernet from starting on some boards.
We can solve that by adding -D SR_DTYPE=-1 to the build flags, wich "forces" AR startup to fail and give back all pins.