Crash at wlan.active(True)

[n0npr0phet]

Hi All,
I have two ESP32 boards that are slightly different. The first from AZDelivery.de works great. The second from miniduino which slightly stouter (no 3v3 and gnd pins at the back) crashes with wifi usage. Using the standard do_connect() script and typing in the lines one at a time it crashes at wlan.active(True). I read some posts here talking about power, capacitance, and cables and so I ran the do_connect() script on both boards on two different computers with two different usb cables and the problem follows the miniduino board.


Finally I used the Arduino IDE (WifiClient example) and was able to run and boot without issue (but without micropython or honor )

I also tried the lobo fork and it crashes too.

When it crashes it sometimes says something about RF calibration but it always kills the serial connection.

[code]>>> do_connect()
I (108259) wifi: wifi driver task: 3ffcae0c, prio:23, stack:3584, core=0
I (108259) wifi: wifi firmware version: 7aac1f9
I (108259) wifi: config NVS flash: enabled
I (108259) wifi: config nano formating: disabled
I (108269) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (108279) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (108299) wifi: Init dynamic tx buffer num: 32
I (108299) wifi: Init data frame dynamic rx buffer num: 64
I (108299) wifi: Init management frame dynamic rx buffer num: 64
I (108309) wifi: Init static rx buffer size: 1600
I (108309) wifi: Init static rx buffer num: 10
I (108309) wifi: Init dynamic rx buffer num: 0
[/code]

espefuse does show a mac address.

I was ready to switch to Arduino but then I put a huge cap from 3v3 to gnd and the problem was resolved. With the cap in place days of hassle melted away. Clearly the second board lacked capacitance.

Why does the Arduino built firmware run without the big capacitor?

[yssob88]

Hi,

I do have the same problem. Wemos lolin32 with OLED, bought from banggood. I know I´ve done a mistake before, as I flashed it with micropython for esp8266 and with the wrong command options at esptool.
After that I did it right, but I cannot get the wifi working:

[code]
>>> import network
>>> station = network.WLAN(network.STA_IF)
I (151807) wifi: wifi firmware version: ebd3e5d
I (151807) wifi: config NVS flash: enabled
I (151807) wifi: config nano formating: disabled
I (151807) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (151817) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
I (151837) wifi: Init dynamic tx buffer num: 32
I (151837) wifi: Init data frame dynamic rx buffer num: 64
I (151837) wifi: Init management frame dynamic rx buffer num: 64
I (151847) wifi: wifi driver task: 3ffcb08c, prio:23, stack:4096
I (151847) wifi: Init static rx buffer num: 10
I (151857) wifi: Init dynamic rx buffer num: 0
I (151857) wifi: wifi power manager task: 0x3ffcfcdc prio: 21 stack: 2560
W (151867) phy_init: failed to load RF calibration data (0x1102), falling back to full calibration

Brownout detector was triggered

Guru Meditation Error: Core 0 panic'ed (IllegalInstruction)
. Exception was unhandled.
[/code]

[quote]
I was ready to switch to Arduino but then I put a huge cap from 3v3 to gnd and the problem was resolved. With the cap in place days of hassle melted away. Clearly the second board lacked capacitance.
[/quote]
Is it a solution also for my problem?
What capacitor did you try?
Let you stay it in place permanently?

And there is another problem. Every time I had a connection to it with ampy, esptool, terminal or so on, I cannot establish a new connection without restarting the board.
I tried also a Wemos D1 mini with micropython. It is working fine.

All help is welcome
Greetings, Schöne Grüße....
Peter

[Greyhnd001]

I have the same issue
I will try the capacitor add like you said and see what it does.
Thankyou.

[McMoe]

Same problem here. Really wierd. Its a fresh board Esp32-WROOM-32 from AZ-Delivery flashed with custom made micropython 1.15 firmware. My firmware is running on most of my boards but crashing on this one when it runs the command station.active(True).

Errormessage is "Connection lost (EOF)".

Its not a memory issue. All of my code is frozen in the firmware. So i have 102144 (gc.mem_free()) when i run into this issue. This board just dont want to do the wlan thing.

[McMoe]

Ok fixed this on my side. I had a Max7219 connected to it. Most of my boards are connected to Pin 2 as CS. I read the pin documentation from AZ-Delivery and changed this connection to pin 15. Now everything works fine. So this error seems occur when certain pins from the board are connected. Hope that helps someone wasting time.

[vlasoveqn]

I have encountered this behavior with a custom-built ESP32 board (using the WROVER module flavor). Specifically, activating the WiFi radio when the unit is only powered via serial port (analogue of USB--my board doesn't use the latter) sometimes caused a reboot due to brownout conditions and sometimes did not, depending upon the board (I have multiple PCBs). As I also have the capability of powering each board using an AC-DC converting power supply, when using AC power there's no problem whatsoever.

Because of a related problem (rebooting under certain conditions--in this case, a relay switching under AC load controlled by one of the GPIO ports), I investigated the problem using an oscilloscope. The relay-related rebooting was being caused by AC 'hash' getting into the ESP32 power pins--i.e., inadequate bypass capacitance. Also observed on the 'scope was the behavior of the ESP32 3.3V power rail when the WiFi radio was switched on _or off--there was usually an 'instantaneous' positive or negative 'delta function spike' in the rail voltage, sometimes up to +/-0.3V from the nominal rail voltage. The voltage then decayed back to the rail voltage with a certain time constant (I've forgotten the magnitude) reminiscent of (or exactly like) the capacitive decay profile of RC circuit theory.

So, IMHO, there needs to be adequate capacitive decoupling on ALL ESP32 power pins (i.e., more than one value capacitor on the PCB, laid out with very short GND & 3V3 traces) to bleed off any AC prior to it entering the module, _and_ the capacitance between 3V3 and GND needs to be adequately large so as to minimize deviations from the power rail in the case of the WiFi radio (comparatively a power-greedy portion of the microcontroller) turning on or off. That's why the large-value capacitor between power and ground eliminated the problem. As to why some boards exhibit this behavior and some don't? Your guess is as good as mine, but mine is that some boards are designed better than others--in other words, the problem's with the hardware, not with firmware or software behavior. I'm using some prototype PCBs, so there are future design improvements being made to eliminate these problems.

[Zoot]

There are a bunch of ESP32 boards out there recently that have inappropriately sized 3.3V regulator chips that can only source 150ma for a device that calls for 500ma worst-case. When transmitting with WIFI the power usage will go up to something like 250ma by default and BOOM, you reset with the brownout indication.

Adding a big cap to handle the surges in current, or replacing the regulator, or providing your own regulated 3.3V are all rather unsatisfying workarounds.

It seems *possible* to work with these boards if you micro-manage the power usage. You are right on the edge if you're using only bluetooth or using WIFI in passive receive mode, and if you don't power up the network hardware it can run the CPU alone just fine.

For WIFI, what we probably want is a new network.WLAN().config('txpower') which would interface to

https://docs.espressif.com/projects/esp ... wer6int8_t

and let you reduce the WIFI power to the low end of its range which might let you communicate reliably though obviously with reduced performance due to the lower power.

Or you can buy a not-crap ESP32 module

[20100]

hi, sorry for the deep dig.

I have exactly the same problem (wlan.active(True) crash) and I found this only topic talking about that. I'm working on an Espressif board, ESP32-S3-DevKitC-1 (demo board from the SoC supplier ), and very surprised that this bug has not been fixed since long months it seems to occur.
Any other possibilities than fixing the hardware ?
When I tried with ESP-IDF (without MicroPython), it worked like a charm, so why only Python WLAN API would encounter this bug ? MicroPython would be very useful to reach my final goal.

[Jibun no kage]

So what is the fix for this?

[davef]

For boards that I want the CP2102 running a 1000uF low-ESR cap on the 3V3 pin sorts it for me. Even using the AMS regulator.

For the remote sensors a single Li-ion cell with a HT7333 regulator and a 1000uF directly to the 3V3.