ESP32-D0WD-V3 wifi.begin() does not connect but fine on ESP32-D0WDQ6

[AussieMakerGeek]

Board

Generic ESP32 WROOM Module

Device Description

Various - Hardware independent other than specific ESP Chip

Hardware Configuration

No External connections

Version

v2.0.5

IDE Name

Arduino IDE 1.8.16

Operating System

Windows 10

Flash frequency

80Mhz

PSRAM enabled

no

Upload speed

921600

Description

Testing Generic wifiClient Example
Entering known good SSID/Pass code
ESP32-D0WD-V3 it does not connect to wifi
ESP32-D0WDQ6 Immediately connects with identical code

Loading the WiFiScan example lists all of the wireless networks around me with no issue on both ESP32 Versions.

I have discovered though that the WiFiMulti.addAP()/WiFiMulti.run() method DOES allow connecting to the network with the newer chip.

Sketch

/*
 *  This sketch sends data via HTTP GET requests to data.sparkfun.com service.
 *
 *  You need to get streamId and privateKey at data.sparkfun.com and paste them
 *  below. Or just customize this script to talk to other HTTP servers.
 *
 */

#include <WiFi.h>

const char* ssid     = "MySSID";
const char* password = "MyPassword";

const char* host = "data.sparkfun.com";
const char* streamId   = "....................";
const char* privateKey = "....................";

void setup()
{
    Serial.begin(115200);
    delay(10);

    // We start by connecting to a WiFi network

    Serial.println();
    Serial.println();
    Serial.print("Connecting to ");
    Serial.println(ssid);

    WiFi.begin(ssid, password);

    while (WiFi.status() != WL_CONNECTED) {
        delay(500);
        Serial.print(".");
    }
    // *** Never Gets here with ESP32-D0WD-V3 ***
    Serial.println("");
    Serial.println("WiFi connected");
    Serial.println("IP address: ");
    Serial.println(WiFi.localIP());
}

int value = 0;

void loop()
{
    delay(5000);
    ++value;

    Serial.print("connecting to ");
    Serial.println(host);

    // Use WiFiClient class to create TCP connections
    WiFiClient client;
    const int httpPort = 80;
    if (!client.connect(host, httpPort)) {
        Serial.println("connection failed");
        return;
    }

    // We now create a URI for the request
    String url = "/input/";
    url += streamId;
    url += "?private_key=";
    url += privateKey;
    url += "&value=";
    url += value;

    Serial.print("Requesting URL: ");
    Serial.println(url);

    // This will send the request to the server
    client.print(String("GET ") + url + " HTTP/1.1\r\n" +
                 "Host: " + host + "\r\n" +
                 "Connection: close\r\n\r\n");
    unsigned long timeout = millis();
    while (client.available() == 0) {
        if (millis() - timeout > 5000) {
            Serial.println(">>> Client Timeout !");
            client.stop();
            return;
        }
    }

    // Read all the lines of the reply from server and print them to Serial
    while(client.available()) {
        String line = client.readStringUntil('\r');
        Serial.print(line);
    }

    Serial.println();
    Serial.println("closing connection");
}

Debug Message

No Errors generated

Other Steps to Reproduce

Consistently on the newer ESP32 V3 chip across various different dev boards, it will not connect with WiFi.begin()

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[me-no-dev]

Please enable core debug to level Verbose and post the logs from UART

[Jeff-Jordan]

Same problem here (arduino 1.8.19), with the ESP32-D0WD-V3.
Even when I flash the D0WD-V3, using esptool, with the binary flash dump of a working ESP32-D0WDQ6, the new chip doesn't connect.

I just compiled the WiFiClientBasic example (with verbose debug level), but when the new D0WD-V3 chip tries to connect to my wifi network, it simply doesn't work.

Got the following log (anonymized):

---

[ 4][D][esp32-hal-cpu.c:244] setCpuFrequencyMhz(): PLL: 480 / 2 = 240 Mhz, APB: 80000000 Hz
[ 35][I][WiFiMulti.cpp:84] addAP(): [WIFI][APlistAdd] add SSID: mynetwork

Waiting for WiFi... [ 50][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 0 - WIFI_READY
[ 146][V][WiFiGeneric.cpp:340] _arduino_event_cb(): STA Started
[ 148][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 2 - STA_START
[ 6355][V][WiFiGeneric.cpp:383] _arduino_event_cb(): SCAN Done: ID: 128, Status: 0, Results: 4
[ 6355][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 1 - SCAN_DONE
[ 6360][I][WiFiMulti.cpp:114] run(): [WIFI] scan done
[ 6364][I][WiFiMulti.cpp:119] run(): [WIFI] 4 networks found
[ 6370][D][WiFiMulti.cpp:149] run(): ---> 0: [1][98:9B:CB:xx:xx:xx] mynetwork (-60) *
[ 6378][D][WiFiMulti.cpp:151] run(): 1: [1][54:67:51:xx:xx:xx] othernetwork1 (-73) *
[ 6386][D][WiFiMulti.cpp:151] run(): 2: [2][24:65:11:xx:xx:xx] othernetwork2 (-75) *
[ 6395][D][WiFiMulti.cpp:151] run(): 3: [11][EC:A8:1F:xx:xx:xx] othernetwork3 (-87) *
[ 6403][I][WiFiMulti.cpp:160] run(): [WIFI] Connecting BSSID: 98:9B:CB:xx:xx:xx SSID: mynetwork Channel: 1 (-60)
[ 6414][V][WiFiGeneric.cpp:97] set_esp_interface_ip(): Configuring Station static IP: 0.0.0.0, MASK: 0.0.0.0, GW: 0.0.0.0
[ 7507][V][WiFiGeneric.cpp:362] _arduino_event_cb(): STA Disconnected: SSID: mynetwork, BSSID: 98:9b:cb:xx:xx:xx, Reason: 2
[ 7507][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 5 - STA_DISCONNECTED
[ 7515][W][WiFiGeneric.cpp:955] _eventCallback(): Reason: 2 - AUTH_EXPIRE
[ 7521][D][WiFiGeneric.cpp:975] _eventCallback(): WiFi Reconnect Running
....
..,,

---

So the reason seems to be something like an expired authentication ....
What does this tell us?

Actually boards with the new chip (like the Wemos D1 R32) can not be used as expected.

From my point of view, this is a major issue !

edit#1:
Additional information: when the WiFi is not encrypted, which means: open, the connection works.

Log with connection to open "MyIoT-Test":

---

[ 4][D][esp32-hal-cpu.c:244] setCpuFrequencyMhz(): PLL: 480 / 2 = 240 Mhz, APB: 80000000 Hz
[ 27][I][WiFiMulti.cpp:84] addAP(): [WIFI][APlistAdd] add SSID: MyIoT-Test

Waiting for WiFi... [ 34][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 0 - WIFI_READY
[ 125][V][WiFiGeneric.cpp:340] _arduino_event_cb(): STA Started
[ 126][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 2 - STA_START
[ 6334][V][WiFiGeneric.cpp:383] _arduino_event_cb(): SCAN Done: ID: 128, Status: 0, Results: 9
[ 6334][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 1 - SCAN_DONE
[ 6338][I][WiFiMulti.cpp:114] run(): [WIFI] scan done
[ 6343][I][WiFiMulti.cpp:119] run(): [WIFI] 9 networks found
[ 6348][D][WiFiMulti.cpp:151] run(): 0: [1][98:9B:CB:xx:xx:xx] mynetwork (-48) *
[ 6356][D][WiFiMulti.cpp:149] run(): ---> 1: [1][F6:CF:A2:xx:xx:xx] MyIoT-Test (-49)
[ 6364][D][WiFiMulti.cpp:151] run(): 2: [1][54:67:51:xx:xx:xx] othernetwork1 (-71) *
[ 6372][D][WiFiMulti.cpp:151] run(): 3: [2][24:65:11:xx:xx:xx] othernetwork2 (-72) *
[ 6381][D][WiFiMulti.cpp:151] run(): 4: [1][CA:52:61:xx:xx:xx] othernetwork3 (-87)
[ 6390][D][WiFiMulti.cpp:151] run(): 5: [1][CA:52:61:xx:xx:xx] othernetwork4 (-88)
[ 6398][D][WiFiMulti.cpp:151] run(): 6: [1][C8:52:61:xx:xx:xx] othernetwork5 (-88) *
[ 6406][D][WiFiMulti.cpp:151] run(): 7: [6][E8:DF:70:xx:xx:xx] othernetwork6 (-89) *
[ 6414][D][WiFiMulti.cpp:151] run(): 8: [6][9C:C8:FC::xx:xx:xx] othernetwork7 (-91) *
[ 6422][I][WiFiMulti.cpp:160] run(): [WIFI] Connecting BSSID: F6:CF:A2:68:9E:DC SSID: MyIoT-Test Channel: 1 (-49)
[ 6450][V][WiFiGeneric.cpp:97] set_esp_interface_ip(): Configuring Station static IP: 0.0.0.0, MASK: 0.0.0.0, GW: 0.0.0.0
[ 6477][V][WiFiGeneric.cpp:355] _arduino_event_cb(): STA Connected: SSID: MyIoT-Test, BSSID: f6:cf:a2:xx:xx:xx, Channel: 1, Auth: OPEN
[ 6478][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 4 - STA_CONNECTED
[ 6684][V][WiFiGeneric.cpp:369] _arduino_event_cb(): STA Got New IP:172.217.28.98
[ 6685][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 7 - STA_GOT_IP
[ 6688][D][WiFiGeneric.cpp:996] _eventCallback(): STA IP: 172.217.28.98, MASK: 255.255.255.0, GW: 172.217.28.254
[ 6698][I][WiFiMulti.cpp:174] run(): [WIFI] Connecting done.
[ 6703][D][WiFiMulti.cpp:175] run(): [WIFI] SSID: MyIoT-Test
[ 6709][D][WiFiMulti.cpp:176] run(): [WIFI] IP: 172.217.28.98
[ 6714][D][WiFiMulti.cpp:177] run(): [WIFI] MAC: F6:CF:A2:xx:xx:xx
[ 6720][D][WiFiMulti.cpp:178] run(): [WIFI] Channel: 1

WiFi connected
IP address:
172.217.28.98
....
....

---

Curious, isn't it?

By the way, my "mynetwork" uses WPA+WPA2.

---

edit#2, update:

The problem seems to be related to the WPA+WPA2 password. My genuine password was a string with 16 numerical characters (like "1234567890123456" as an example).

But when I use a different password, like "Hokuspokus", it works like magic.
It even works when I append a non numeric character to my 16 numericals, so that it looks now like "1234567890123456X".

Hope this observation helps to track down the problem.

[mrengineer7777]

Interesting. I wonder if the numeric nature of the password makes the library think it's a PSK? Worth digging into the Arduino and IDF libraries.

[TD-er]

And what if you only use HEX characters?
Maybe the code interprets it as a WEP key, which can be upto 26 HEX digits.

[mrengineer7777]

16 bytes is a valid WEP key length. https://www.speedguide.net/faq/what-is-a-valid-wep-key-110
Does it work with 17 chars? Also WEP was recently deprecated in this Arduino project.

[Jeff-Jordan]

It doesn't seem to be an arduino related problem. I guess there's something fishy with the RTOS of the new core.
When I copy the flash content of a working ESP32-D0WDQ6 into the -D0WD-V3, the D0WD-V3 refuses to connect to a wifi network with purely 16 numerical characters, while the D0WDQ6 (with the same flash content) works fine.

[dvarrel]

i try several tests with ESP32-D0WDQ5 Rev 3 (WEMOS D1 R32):

• open-AP ,
• changing the key with alphanumeric, just alpha, just numeric...
  also try with wifiMulti example

it didn't connect

:-(

[Jeff-Jordan]

There's something really fishy going on with these -V3 chips.

I've got an AZ-Delivery ESP32 Dev KitC V4 ESP32-WROOM-32, where I made several tests and was able to connect to my wifi with the restrictions mentioned above.
Now I've got another board here, a WEMOS D1 R32, with exactly the same type of ESP32 (i.e. D0WD-V3).
This board still doesn't connect to my wifi.

The verbose log shows a lot of different "reasons" for the disconnection:

---

[108959][V][WiFiGeneric.cpp:362] _arduino_event_cb(): STA Disconnected: SSID: MyIoT-Test, BSSID: f6:cf:a2:68:XX:XX, Reason: 202
[108970][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 5 - STA_DISCONNECTED
[108977][W][WiFiGeneric.cpp:955] _eventCallback(): Reason: 202 - AUTH_FAIL

but other reasons occur as well:
.....
[117600][W][WiFiGeneric.cpp:955] _eventCallback(): Reason: 203 - ASSOC_FAIL
.....
[117668][W][WiFiGeneric.cpp:955] _eventCallback(): Reason: 5 - ASSOC_TOOMANY
.....
[118102][W][WiFiGeneric.cpp:955] _eventCallback(): Reason: 8 - ASSOC_LEAVE
.....
[ 84846][W][WiFiGeneric.cpp:955] _eventCallback(): Reason: 2 - AUTH_EXPIRE
.....
[217418][W][WiFiGeneric.cpp:955] _eventCallback(): Reason: 5 - ASSOC_TOOMANY
.....
[335704][W][WiFiGeneric.cpp:955] _eventCallback(): Reason: 15 - 4WAY_HANDSHAKE_TIMEOUT
.....

---

[Jeff-Jordan]

i try several tests with ESP32-D0WDQ5 Rev 3 (WEMOS D1 R32):

Thats a general issue with a lot of the D1 R32 boards (arduino UNO design).
I ran into the same problem here.

But sohtamei and Ibernstone figured out that there is a design error at the WEMOS D1 R32 boards.
Soldering a 330 Ω resistor between GPIO0 and +3,3V cures the problem. Would be a good idea to solder another one between RST (EN) and +3,3V as well, so that the ESP32 won't be driven out of specification.

Problem is that the D1 R32 has a CH340C on board and drives these two pins through a transistor logic, so that you don't need to press a button, when uploading a sketch. But unfortunately the chinese engineers didn't notice that the CH340C runs with 5V and that this leads to approximately 4.1V at the collectors.
The 330 Ω resistors limit the voltage to about 3.45V.

Look here: #2144.

Anyway, the problem with the D0WD-V3 and the wifi passwords (as described above) still persists.

[dvarrel]

thank you.
i've tested it.
you're rigth, anyway, the problem with the wifi passwords still persists.

[dvarrel]

Thank You Jeff,
i've tested with 330 resitor to RST and iO0. It solve the problem for The wemos D1 R32 ! :-)

[TD-er]

Just to make sure I do understand it well...

The higher voltages applied to GPIO-0 and RST on those boards, causes issues with WiFi?

[Jeff-Jordan]

Just to make sure I do understand it well...

The higher voltages applied to GPIO-0 and RST on those boards, causes issues with WiFi?

At least the higher voltage at GPIO-0 (which is a "touch" capable pin as well).
Weird, isn't it?

It really is a pita, when you try to track down the wifi connection problems and you run into a further problem (design issue of the D1 R32) that affects the behaviour too.

It reminds me of a saying from my doc: "you can have lice and fleas at the same time."

[TD-er]

Not that weird. The WiFi RF calibration relates to the voltage supplied to the ESP.
If this is slightly offset by some protection diodes between GPIO pins and Vcc, which try hard to limit the voltage on those pins to prevent damage, then I can imagine the RF calibration will also be based on this offset.
However this is a relatively low current and thus the actual offset voltage will be highly depending on the current draw of the ESP.
Since the RF calibration itself draws by far the most current (short spikes upto 600 mA), it will probably be based on a lower voltage compared to normal operations.

This makes me realize why on some nodes I may get a good and stable WiFi connection when running in AP+STA mode and not in STA mode.
In AP+STA mode, the WiFi radio never is turned off, so the current draw is much more constant and higher.

[Jeff-Jordan]

Yes, as you've mentioned, usually the IO-pins are protected with diodes to +Vcc and GND (the latter in case of negative voltages).
But I guess the internal diodes of the ESP32 are only ordinary pn-diodes, because for hot-carrier diodes you need an additional semiconductor / metal transistion.
Instead of a 330 Ω resistor, I just soldered a schottky diode (1N1587) between GPIO-0 (at the edge of the ESP32 module) and +3,3V. This cures the problem more elegant than a simple resistor, which restricts the use as I/O pin.

[TD-er]

Do you have any idea/guess about the current drawn through this diode?

[Jeff-Jordan]

Do you have any idea/guess about the current drawn through this diode?

Ok, just desoldered the diode to measure the current.
In operation the current is ridiculously low with 0.47 mA. But it's enough to tie GPIO-0 to approximately 3.45 V, so that the ESP32 is able to succeed it's wifi calibration.

[TD-er]

Thanks a lot!

I will also have a look at the datasheet of the CH340 to see what pins should be set to what level to set the chip into "3V3 mode"
Perhaps those pins are also an easy option to fix these kinds of issues?

[dvarrel]

Do you have any idea/guess about the current drawn through this diode?

Ok, just desoldered the diode to measure the current. In operation the current is ridiculously low with 0.47 mA. But it's enough to tie GPIO-0 to approximately 3.45 V, so that the ESP32 is able to succeed it's wifi calibration.

so you think it's better to sold diode rather than resistor ? and for RST pin ?

[Jeff-Jordan]

I don't care about the RST pin anymore, because it doesn't affect the wifi calibration and is still protected by the internal diodes of the ESP32.
For the choice of the cure (resistor vs. schottky diode), the low current of 0.47mA is not the relevant parameter (the 330 Ω resistor draws the same current at a 0.15V drop between GPIO-0 and +3.3V), but the useability of the I/O pin defines the choice.

When you cure the problem using the resistor and you like to drive some load between the GPIO-0 pin and GND (like a resistor / LED combination), the load will always get some current through the resistor (i.e. the LED will emit light), even if the ESP32 doesn't drive the pin with output = high.
And in fact, when programming the pin as output and you'll set the output to low, you'll draw always 10mA through the resistor. Ok the latter is not a problem for the ESP32, because it doesn't exceed the pins specifications (max. 40mA), but it is unnecessary and might restrict you with the rest of what you want to drive with it.

[TD-er]

I was just thinking about how the 2 transistors are wired for toggling the RST and GPIO-0.
So I just looked at the NodeMCU schematic and I realized I don't understand how the voltage over GPIO-0 can be pulled up by using a CH340 in 5V mode.

N.B. I know this isn't guaranteed the same schematic as on those boards on the photo, so it is just an assumption it is probably wired like this.

Where does the higher voltage on GPIO-0 come from?
What happens to the NPN transistor if base voltage > collector voltage? Won't it get damaged?

Edit:
Ah forgot about the "diode equivalent" schematic representation of a NPN transistor:

This explains where the higher voltage comes from.

Edit2:
This also explains why the current only is 0.45-ish mA, as it is limited by the 10k or 12k resistor connected to the RTS pin on the CH340.

[Jeff-Jordan]

Really don't know why the board designers didn't hook up the CH340G's Vcc pin (#16) to the output of the 3.3V voltage regulator (AMS1117 3.3) and connected V3 (pin #4) to +3.3V as well.
If they did, there were no issue with the voltage at the GPIO-0 and EN/RST pins.

Might be that they were ancious about the additional current for the CH340G... but it's only max. 7mA more load for the regulator.
Or they didn't manage to get the routes at the pcb.

So a fix without any schottky diodes or resistors would be to lift up pin#16 of the CH340G, connect it to V3 (pin #4) and then to the +3.3V.

---

Update: just removed the diode and made the fix described above.
It was quite easy, the +3.3V from the voltage regulator and the V3 pin (pin#4) from the CH340G are quite nearby and in very short distance to the UART chip.
Everything that was required is a small soldering iron, approx. 2cm of small hookup wire and a steady hand.
Be careful when you lift pin#16 of the UART chip.

---

Everything works nice now. Uploading a sketch works as previously (without pressing any "boot mode button") and the wifi calibration seems to work perfect as well.
Voltage at the GPIO-0 and EN/RST is now approximately 3.2V.

[mrengineer7777]

@AussieMakerGeek Is this issue related to Wemos hardware, or is there also a software issue with 16 character numeric passwords?

[Jeff-Jordan]

The problem with the 16 character numeric password seems to be related to the D0WD-V3 chip itself.
It persists with the (fixed) WEMOS board and all other boards that I've tested so far and that use the D0WD-V3 Chip.

The fix for the WEMOS board only targets the problem, that the ESP32 doesn't connect to some routers and access-points, because of an unsuccessful calibration sequence of the wifi hardware during the bootup sequence.
It might appear at other ESP32 developer boards in "arduiono uno board"- design as well.

The reported bug with the encryption password is still an issue with the D0WD-V3 chip.

So, you can call the WEMOS board problem the flea and the password issue a louse.... according to the above mentioned saying.

[dvarrel]

Thank you, it did the job. Also put wire between pin#16 - pin#4 - 3.3V
on 3 wemos D1 R2, it's ok

[Jeff-Jordan]

... Also put wire between pin#16 - pin#4 - 3.3V on 3 wemos D1 R2, it's ok

I'm just waiting for two more D1 R32 boards as well. But they are actually in transit from China to Germany :-P.

[mrengineer7777]

RE: 16 char password issue
Looking at set_esp_interface_ip() in WiFiGeneric.cpp, there is nothing hardware specific in the Arduino code. The problem is likely in the IDF or silicon itself. Unfortunately I haven't been able to find source code for the IDF WiFi config functions, only the header declarations.

[Jeff-Jordan]

Yeah, meanwhile I don't think that the issue is library / arduino related.
It must be a bug in the RTOS of the new -V3 chips.

[TD-er]

I have read in some errata document that the older revisions needed some extra NOP operations to make sure things are consistently read and processed.
This is then fixed in the latest silicon and thus no longer needed.
Maybe these extra delays did also "fix" some other issues?
Still doesn't explain why numerical-only passwords apparently don't work while other passwords do.
But maybe there are several issues present here?

[Jeff-Jordan]

At the time beeing, I can't rule out that the "numerical-only password" issue is related to the chip anymore. Could be an issue of my router (Fritz!Box7590) as well.

[TD-er]

Still, if it does work on older silicon revisions and doesn't work on newer revisions, then there is still some causal relation between silicon revision and WiFi connection issues.

[AussieMakerGeek]

@Jeff-Jordan
The password that I was using for my testing was 11_testing_22.

I am not sure what conclusion can be drawn from your experience and mine. I don't think we can rule out or whittle it down any more from where we're at.

Ultimately, it would appear that this is an issue in the RTOS or something like that, but does not explain why the other method of connecting is working ok. It may be that there is not a fix, but a workaround in the back end of the wifi.connect() function to use the same method as WiFiMulti.run() instead so it's just transparent to the user.

[Jeff-Jordan]

@AussieMakerGeek
I totally agree to your point of view.

[Totoche95]

Hello,
I agree with Jeff-Jordan, i had the same problem with an ESPDuino-32.
No wifi connection and no USB connexion , it was only working with a long USB cable that reduce power supply from 5.04V to 4.6V, because there is no 5V-3.3V adaptation between CH340 and esp32.
I had to do two things to work normally
A 4.7KOhms between GND and IOC (GPIO-0), so i have 3.04V on IOC/GPIO-0
A 10µF capacitor between GND and reset.
All is working normally like that.

[MabuClou]

@Jeff-Jordan > 1N1587

Are you sure about 1N1587? Shouldn't it be 1N5817 instead?