Problems connecting to WiFi

[deti__]

To clarify, are you saying that you couldn't connect to WiFi before you completely erased flash?

Yes, exactly that's it. It seems that the esp32 development kit boards have been preflashed with an older sdk version. Thus it is necessary to erase all data in flash to get a newer app working.
See https://nodemcu.readthedocs.io/en/maste ... -init-data

The SDK reserves space in flash that is used to store calibration and other data. This data changes between SDK versions, and if it is invalid or not present, the firmware may not boot correctly.

Deti

[MartyMacGyver]

Erasing flash made a difference for me, though I'm not sure why (I'll be updating the ticket accordingly).

All I did was run "make erase_flash flash" which erased the flash and then flashed the program onto it. It connected successfully after that.

[kolban]

Deti,
The docs you pointed at and the story about erasing flash memory used by the SDK is a true story ... for the ESP8266. I wasn't aware that there was a similar story for the ESP32 (and maybe there isn't). The "SDK" for the ESP32 is called "ESP-IDF" and changes weekly while it is being cooked. When one builds an ESP32 app today, one downloads the ESP-IDF, writes your own app code and then compiles and link edits both your code and the whole of the ESP-IDF. The result (all of it) is then flashed to the ESP32. As such, there really doesn't appear to be anything in ESP32 flash that can't be over-written nor dependent upon from one flash to the next. The major exception to this is the area of storage in flash known as "NVS" or "Non Volatile Storage" which does appear to be preserved between app flashes as it is outside of the scope or app, and bootloader and partitions areas. However, and this would be the key area for us to focus on ... there is nothing yet known to be stored in NVS that affects the operation of ESP-IDF based applications.

[ESP_Angus]

Thanks for updating Marty.

I've replied on the github issue, but just to provide the same information here: this appears to be a bug where values stored by the wifi libraries in NVS cause WiFi to stop working after an update.

"make erase_flash" is a temporary workaround.

I have a copy of the "invalid" NVS data from Marty and we will fix the underlying bug ASAP.

I'll post on the github issue from now on, but I'll update this forum thread once the underlying bug is fixed:
https://github.com/espressif/esp-idf/issues/207

[MartyMacGyver]

I'm glad I noticed all this now - my ESP32-WROVER-KIT will be here in a couple of days and I'd have really wondered what was up if it didn't work (especially since it will have the same ESP-WROOM-32 module on it - though I eagerly await the upcoming ESP32-ROVER module, other than the extra PSRAM I believe it's basically the same). Meanwhile, I'm grateful for the quick assistance on this.

[jshep321]

I have 2 HUZZAH32's -- one newer one (mid-2020) and one from march 2019.

My new one has worked fine, but the older one was unable to get on some of my wifi networks (specifically-- netgear orbi 3 mesh with up-to-date firmware). I am flashing software with vscode and/or Arduino IDE.

The underlying problem, best I understand it, is that some of the ESP-IDF firmware parts don't get updated. In order to make this work, I did this:
1. download esptool (WSL or linux): sudo apt install esptool
2. erase flash -> esptool -p /dev/ttyS[COM PORT #} erase_flash for wsl or esptool -p /dev/ttyUSBXX (linux)
3. download and install the ESP-IDF as described here: https://docs.espressif.com/projects/esp ... rt-project
4. make and upload a program to the device (I did hello world, obviously).
5. re-upload your target binary from vscode or arduino IDE.

If anyone has a better procedure to fix this or some insight, please add!