Wifi connection not working on newer ESP32 WROOM boards

[gkzsolt]

This is a duplicate of #10377. I am sorry, but cannot help it to be somehow desperate about Micropython not working on the newer WROOM revision 3 dev boards. In a nutshell, network.WLAN().connect works on ESP32D0WDQ6 (revision 1) boards, but not on ESP32D0WDQ5 (revision 3), where a board reset occurs.
My electronics provider says that:

"Q5" és a "Q6" refer to the IC packaging. Between revision 1 and 3 the latter is the newer, where the manufacturer issued several fixes, which could lead to the errors encountered.

They provided a link to the ESP32 Series SoC Errata, which did not help much. It might be useful to MicroPython developers though. Is any developer following this?

I tried all versions available at the download page, with firmware compiled with ESP-IDF v3.x or v4.x. Up to v1.11 the code just block without returning; higher versions all were resetting the board (tried also nightly builds: e.g. v1.19.1-812-g67097d8c2 (2023-01-18) .bin)

Unfortunately - or well, fortunately - the C/C++ compiled code from Arduino IDE works well, so this is a MicroPython issue.

I would prefer the board with the older chip to use in my projects, but the distributor does not have those. And when you order a board from a distributor, you cannot know the chip version used.

Is there any hope for this to be considered/tackled in the future? What can I do?

Thank you,

[robert-hh]

I have a board here with a WROOM module, which reports to esptool.py chip_id with Chip is ESP32-D0WD-V3 (revision 3). And that one works well with micropython. What does you device report on esptool.py chip_id?

[robert-hh]

I received a board today, using the link you gave me. Unfortunately, it is not the same as yours, even if I told the shop to deliver the same one. The one I got is a standard Revision 1 model, which seems not to work as expected either: the espressif mode of switching to bootloader fails. So it's a good candidate for trash.

esptool.py v3.1-dev
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting........_____....._
Chip is ESP32-D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 3c:e9:0e:4c:30:28
Uploading stub...
Running stub...
Stub running...
Warning: ESP32 has no Chip ID. Reading MAC instead.
MAC: 3c:e9:0e:4c:30:28
Hard resetting via RTS pin...

[cve2022]

I received a board today, using the link you gave me. Unfortunately, it is not the same as yours, even if I told the shop to deliver the same one. The one I got is a standard Revision 1 model, which seems not to work as expected either: the espressif mode of switching to bootloader fails. So it's a good candidate for trash.

Hello @robert-hh , I did not follow the discussion, but I will hazard a guess about the problem you just described.

Some of these ESP32 has a flaw in the hard reset system. In a nutshell, depending on the sequence of the UART's DTR and RTS, a short spurious RESET pulse is generated (I scoped once, it lasts 1 to 2us AFAIR) and that wrecks the ESP32 logic havoc (it is too short).

The uggly solution is adding a reset button to the EN pin (it works despite the switch bounce). A less inelegant solution is adding a 10uF capacitor between the EN pin and GND. The capacitor stops the spurious short reset pulse. Some boards already has this fix, from some posts I have seen.

Some links about the matter:
https://electronics.stackexchange.com/questions/569788/how-esp32-auto-upload-issue-has-been-fixed-by-adding-capacitor
https://randomnerdtutorials.com/solved-failed-to-connect-to-esp32-timed-out-waiting-for-packet-header/

HTH

[robert-hh]

Thank you for the hint. Adding a 10µ cap helped. I soldered it between EN and 3V3, since these pins are next to each other.

[bulletmark]

I've bought a number of ESP32 devkit clones with this problem and find it always get's solved by me soldering a cap (or adding one to my parent circuit). Here is an image I posted some time ago showing 3 clones I have bought at various times: https://imgur.com/a/YWYB2AO. Note the bottom left corner of each board. The left board has the problem, the middle board has had a cap added crudely near the EN switch, and the right board has cleaned the alignment of that cap up. I always try to ensure the board I am buying has that cap.

[cve2022]

Thank you for the hint. Adding a 10µ cap helped. I soldered it between EN and 3V3, since these pins are next to each other.

How many pins does yours have? I am asking because mine are similar to the leftmost one at @bulletmark 's picture and the VP pin is next to EN but it is not 3V3. I mounted my ESP32 DEVKITV1 on a small protoboard and I placed the capacitor on the protoboard between EN and GND, in parallel with a button. Connecting the capacitor between EN and 3V3 must work fine too.

I've bought a number of ESP32 devkit clones with this problem and find it always get's solved by me soldering a cap (or adding one to my parent circuit). Here is an image I posted some time ago showing 3 clones I have bought at various times: https://imgur.com/a/YWYB2AO. Note the bottom left corner of each board. The left board has the problem, the middle board has had a cap added crudely near the EN switch, and the right board has cleaned the alignment of that cap up. I always try to ensure the board I am buying has that cap.

This is the picture I remember having seen showing the different versions of the board, with a rework in the middle one and the final fix on the rightmost. Thank you for posting it, BTW. I took the liberty to reproduce it here.

It is possible to solder the capacitor (I am assuming a leaded electrolytic) between the pin of the switch (like the middle board above) and GND or 3V3 (the large pin of the LDO near the GND pin on the left side of the boards. Or, over the resistor next to the EN switch ( hilighted above) between EN and 3V3.

[robert-hh]

@gkzsolt Can you make a close-up picture of your non-working device and the label of the bag in which is was shipped? I try to get the same one from the shop.

[davefes]

All my boards have the 10K and a 100nF to ground, in which case, my comment above should be "adding the 1uF cap probably had nothing to do with the 'flaky' behaviour I may have thought I had"!

[robert-hh]

You could test with esptool.py --chip esp32 chip_id. If that works fine, then the transistor logic works as expected.

b.t.w.: The google discussions logic with hierarchical responses is irritating; I do not like it.

[davefes]

Yes, that works.
Thanks for a way to confirm behaviour.

[cve2022]

This is the truth table of the logic:

This logic allows the flasher to automate the boot vs run mode. The Arduino IDE uses it and I remember seeing some articles in the internet about adding this circuit to boards that do not have it to automate the IDE debugging process.

What I observed with Thonny (on Linux) a while ago is RTS was asserted a couple of us before DTR during when I pressed the stop icon. That caused a short (2.5us IIRC) negative pulse and I believe that caused the problem as it probably violates the reset minimum width requirement (this is a supposition because Espressif's documents are terse about characteristics of the processor and I could not find info about minimum reset width in some datasheets, but it is around a tens of us (from memory) with some ST's STM32 I worked with).

The 1uF/10uF capacitor filters the pulse so that the EN never reaches the reset threshold level (top trace below). I guess, with 0.1uF, the voltage drop is higher (bottom trace) and the reset threshold is reached and it wreaks havoc the microcontroller internal logic.

That could explain why some boards may not work even with this 0.1uF capacitor. I made a quick estimation of the voltage drop with 1uF and 3us spurious pulse assuming hFE of the transistors around 300, which make the collector current 90uA and in this scenario the voltage drop is around 300mV. With 0.1uF, it would be around 3V.

The RTS before DTR assertion may be a Linux driver thing, according with the Thonny's developer, as Thonny closes and opens the port during the stop process. I am guessing it may be happening with the esptool too. The ESP32 board becoming unresponsive after a STOP happens on Thonny with Windows too, though.

I apologize if it is too much information, it may not even be the cause of the problems, but given the solution proposed in the internet (adding the capacitor) anecdotally solved the posters problems, the above could explain why it works.

[robert-hh]

I looked at the signals now with Wemos LoLin32 pro board. Somehow they manage to have both EN and GPIO0 low at the same time(!). The two transistor logic has no resistors It uses a two transistor package with built-in resistors of 4k7 Ohm. Screen shot below. Both boards have a short pulse on GPIO0 at the start of the sequence, like 6 µs for the NodeMCU, 2-3µs for the Wemos board. The screen shot below shows is split vertically. The upper window shows the foll EN (yellow) and GPIO0 (green) trace, the lower the Zoom on the pulse.

[davefes]

Thank you. I started with 1uF but ran-out of them. I will change my 10uF to 2u2F. Another case for "bigger is not better"!

[davefes]

@robert-hh Would you please confirm whether or not that the board that you did your testing on has the dual-transistor "Downloader" configuration?
Thanks

[robert-hh]

It has indeed the standard dual transistor logic. Sometimes boards come along which do not have that. Confusingly they have the pads for the transistors, but none soldered.

[davefes]

Good, at least we are dealing with similar hardware.

[gkzsolt]

Hi guys,

It's been a while since I posted my question and I learned that it has a workaround and perhaps an explanation. I think I will incorporate a capacitor to EN/VCC or GND, although I did not have to so far. A big thanks to all of you, especially @robert-hh, @cve2022 and @davefes. Is good to know electronics professionals worldwide.