ESP32 reset loop with wifi connection

[Eric Vanderhoof]

Hi there! I am a high school robotics teacher with 14 student ESP32s running Microblocks for robot control. I am running into an issue in which the ESP32’s connection icon in Microblocks blinks green and the board becomes unresponsive after any instance of using the wifi connect block. To recover the board, I have to perform a flash erase and reinstall of the firmware. I have performed the recovery perhaps six times now. I had seen this issue once or twice earlier in the year, but it has become much more pronounced recently. My first thought is a brownout with the added power requirements of the wifi radio, but I have tried a 9V, two different manufacturers of USB cables, and a battery eliminator circuit from an RC car electronics speed control without any improvement. I know the wifi library was recently updated - is there any chance this could result from the changes to the code? I am excited to try out the new wifi radio library, but I need to resolve this issue before rolling it out to my students. Any help you could supply would be greatly appreciated. I am using this version of the ESP32: https://www.amazon.com/AITRIP-ESP-WROOM-32-Development-Bluetooth-ESP32-DevKitC-32/dp/B0B82BBKCY/ref=sr_1_10?crid=226A3PYJA6TUC&keywords=ESP32&qid=1701638149&sprefix=esp32%2Caps%2C92&sr=8-10

[John Maloney]

Hi, Eric. I'm sorry you're having problems with your ESP32s resetting.

Which version of MicroBlocks are you using? Are you running the MicroBlocks webapp or a stand alone version? What operating system is it running on?

Although I do not know of any issues with WiFi on ESP32s, it is possible that the recent stable release broke something. As a test, you could try reverting the ESP32 firmware by enabling "show advanced" blocks, selecting "install ESP firmware from URL" from the gear menu, and pasting in this URL:

https://microblocks.fun/downloads/v1.2.24/vm/vm_esp32.bin

That is the ESP32 firmware from the previous stable release.

Another diagnostic is to run the MicroBlocks webapp, open the Javascript console, and then try to connect to WiFi. It's possible that a useful error message will be displayed -- although if the board is actually resetting it might just say something about having lost the connection.

I have an ESP32 board similar to the one you have. What are the steps to reproduce this problem? Does it fail as soon as you connect to a WiFi network?

Is there any external hardware connected that might be drawing power? If so, try disconnecting that hardware -- or perhaps remove the ESP32 board from the expansion board. Does it still fail in that case?

Finally, try the same test with a different ESP32 board. It's possible the one you are using has developed a problem (e.g. a failing voltage regulator).

[Eric Vanderhoof]

Hi John! I am using the current web app version of microblocks on a chromebook. I don’t have any other devices connected other than the electronic speed controller that is providing power. I will try the steps you outlined and get back to you as to whether any of them resolve the problem. Thank you for your help!

[Eric Vanderhoof]

The error occurs any time I use the connect to wifi block - even if that and a wait command are the only pieces of code present.

[John Maloney]

Thanks for the info. I will see if I can reproduce this with my ESP32 board. Did you have a chance to test with a different ESP32s board?

[Eric Vanderhoof]

I have tried three ESP32s from different students. I did get one to work, but perhaps intermittently? I need to test more.

[John Maloney]

I just tested with my ESP32, which is a WROOM board similar to your but with the older USB micro connector. It works perfectly for me, so this does not appear to be a bug in MicroBlocks.

My first thought is that it is a hardware problem.

However, another possibility is that there is a bug in the low-level WiFi code that is causing the ESP32 operating system to crash and reset. (The ESP32 actually has a little operating system from Espressif that runs the WiFi stack.)

A program with a WiFi connect block in a "when started" script, the board would run that code and crash every time it was powered up. In that case, your simple test of the WiFi connect block by itself should cause a crash but would not force you to erase flash to recover. Is that what you observe?

But if this is, indeed, the problem, why is it failing for you but not for me or for ESP32 users? Is there anything unusual about your router configuration? For example, perhaps your network doesn't require a password or perhaps it uses a less common form of authentication.

To test this hypothesis, you could try connect the board several other WiFi networks to see if the failure only occurs on certain networks.

If this is a bug in the low level Espressif code, you may be able to work around it by using your phone as a local hotspot or by buying a cheap WiFi router for your classroom.

The first step to is figure out what the problem is. That will require doing some more experiments. Let me know what you find out.

[Eric Vanderhoof]

Here’s the log from the javascript console:

Log Link It seems like it is a brownout. I tried connecting the ESP32 only to USB out of its expansion board with no change in results. I will try the old firmware and additional boards and see what I find out.

[Eric Vanderhoof]

1. Tried not using a “when started” block but including the wifi block. ESP32 did not crash, but also did not run wifi.
2. Tried using the firmware link you provided. Behaved similarly to most recent firmware.
3. Tried 3A high quality USB power supply. Still stuck in brownout loop.
4. Tried attaching 1000 uF capacitor across the 3v3 volt and ground pins. Same behavior.
5. Swapped out ESP32 for a new one. No brownout loop!

It looks like a significant percentage of my boards cannot provide enough current to use wifi. Since they are only a few dollars each, I will add checking this to my quality control inspection of the student kits at the beginning of the year and use lower-performing units for projects that don’t require wifi. Thanks for all your help! The wifi radio library is really a lifesaver as well. We had spent several days trying to get real-time robot control through the UDP libraries, but would have needed static IP addresses from our IT department for the approach to be practical. The new wifi radio library just works! Thank you!

‌

[Eric Vanderhoof]

Connection issue was a brownout loop due to under-performing ESP32 board hardware. Replacement of inexpensive hardware resolved the issue.

[John Maloney]

Glad you figured it out. I'm guessing the issue is an underpowered voltage regulator on the ESP32 board itself. It's right on the edge, so some work and some do not.

I've had good luck with this board:

https://esphome.io/devices/nodemcu_esp32.html

but the boards you got were probably less expensive, especially if you got them from Ali Express.

I hope you find enough boards that work with WiFi in your set. Good luck with the class!