No WiFi connection after upload - odd workaround needed

[ullixesp]

I got an ESP-WROOM32 dev kit running well with a somewhat complex sketch, and then put it aside for some months. Now after purchasing an ESP-WROVER-KIT_V4.1 I compared the two and now found strange behaviour in both of them: after uploading a sketch, both failed to connect to WiFi, waiting in a WiFi.status() loop endlessly. But after pressing the Reset button, both would connect to WiFi almost instantaneously. So, my code seems ok.

I managed to reduce the code down to the minimum to demonstrate this effect with the WROVER. It has no connection of anything to any of its IO pins, and no SD-card inserted - it is as naked as possible:

Code: Select all

// Wifi connection problems
#include <WiFi.h>

const char*     ssid            = "mySSID";
const char*     password    = "myPW";

void setup() {
  Serial.begin(115200);
  Serial.println("\nConnecting to WIFI");

  WiFi.begin(ssid, password);  // 1st
  delay(10);                          // 2nd #  5ms: not ok, 8ms: often ok,  10ms: ok
  WiFi.begin(ssid, password);  // 3rd

  while (WiFi.status() != WL_CONNECTED) {
    Serial.print(".");
    delay(200);
  }

  long rssi = WiFi.RSSI(); // RSSI (Received Signal Strength in dBm)
  Serial.printf("Successfully connected, getting RSSI: %li \n", rssi);
}

void loop() {
  Serial.print("Looping ");
  delay(2000);
}

Note the three lines commented with 1st, 2nd, and 3rd! When 2nd and 3rd were commented out, this is the result in the Serial Monitor after upload:

Connecting to WIFI
...................................................................................

There is no end to the dots (indicating a wait for connection). The very same results come when I comment out only line 2nd, i.e. I have two subsequent WiFi.begin() commands. But when I un-comment 2nd, and thereby have a delay of 10ms between the two WiFi.begin() commands, it works all the time, like this:

Connecting to WIFI
.Successfully connected, getting RSSI: -26
Looping Looping Looping Looping Looping Loo

In fact, it still works most of the time with an 8ms delay, but it does not work with only a 5ms delay.

It looks like the WiFi code is giving up too quickly? Obviously, something has changed during the time I didn't touch my old ESP. Was it some (Arduino) code? or was it my router, a Fritz!Box 7490 (it may have received an upgrade during that time, but I am not sure).

[ullixesp]

The Fritz!Box company had just released an update to the router firmware, and so I upgraded Fritz!OS from 07.11 to 07.12, and tested for any impact on my ESP32 issues. I was more thorough this time and ran a few dozen connections on both the WROVER and the WROOM.

This workaround is not perfect, but there is clearly a dependence on the length of the delay between the two WiFi.begins. I'll give the delay which is successful 9 out of 10 times:

The WROVER was similar to before, but the 9/10 delay is 20ms. Perhaps an effect of the router, but more likely a more critical measurement on my part.

The WROOM was different (not tested in detail before) the 9/10 delay is 150ms; it fails nearly every time at 20ms!

That looks strange; I had expected the two ESPs to be very similar at least in this aspect?

A long delay does not seem to do any harm so to not adapt the code to the module in use I am now using 200ms delay in my real sketches for both the WROOM and The WROVER.