Static IP WiFi connect 6 times slower with SPIFFS

[torntrousers]

Edit: It turns out this isn't to do with the core release its something to do with the SPIFFS option when doing the sketch upload. For most modules i try the static IP connect is slow unless uploaded with "Generic ESP8266 module" selected and the Flash size set to 512K (no SPIFFS).

With a NodeMCU V1 board it connects slow when uploaded with "NodeMCU 1.0 (ESP-12E Module)" selected but the board connects fast when the code is uploaded with "Generic ESP8266 Module" selected and 512K (no SPIFFS). Similar with a NodeMCU 0.9 board it connects slow when uploaded with "NodeMCU 0.9 (ESP-12 Module)" selected but connects fast uploaded with "Generic ESP8266 Module" selected and 512K (no SPIFFS).

----- old text:
Using the sketch included here on an ESP-12 and the staging release from the 9th of Nov it connects to the WiFi access point in about 170 milliseconds, and thats always consistent and reliably close to that 170ms time (plus or minus a few milliseconds).

With the same ESP-12 and same sketch (only change adding the c_str() on WiFi.SSID()) using the 2.0.0 release its much slower and consistently connects at about 1060 milliseconds (again plus or minus a few milliseconds) - thats six times slower!

Interestingly, not all the ESPs i try with that 9th of Nov staging code connect fast, a lot are the slow 1060 millisecond connect time with either code release. But the ESPs that do connect fast will only work fast with that 9th Nov code and always connect slow with the 2.0.0 release.

Also, the very first connect after power up is a bit slower so with the fast board/9thNov code the first connect takes about 2197 milliseconds and then subsequent connects after a deepSleep take 170ms. On the Slow ones its always about 3070ms for the first connect and 1060 ms for the subsequent ones after deepSleep.

Odd eh? Any ideas?

#include <ESP8266WiFi.h>
extern "C" {
  #include "user_interface.h"
}

const unsigned long SLEEP_INFTERVAL = 15 * 1000 * 1000; // 15 sec

const char* ssid = "BTHub5-72W5";
const char* password = "xxxxxxxxxx";

long setupStartMillis;

void setup() {
  setupStartMillis = millis();

  Serial.begin(115200);
  Serial.println();

  Serial.print("Setup start millis: "); Serial.println(setupStartMillis);

  Serial.print(", Mac: "); Serial.println(WiFi.macAddress());

  WiFi.mode(WIFI_STA);
  Serial.print("Connecting to: "); Serial.println(ssid);
  if (strcmp (WiFi.SSID(),ssid) != 0) {
//  if (strcmp (WiFi.SSID().c_str(),ssid) != 0) {
     WiFi.begin(ssid, password);
  } else {
 //   WiFi.begin();
  }

  WiFi.config(IPAddress(192,168,1,13), IPAddress(192,168,1,254), IPAddress(255,255,255,0));

  int timeout = millis()+10000;
  while ((WiFi.status() != WL_CONNECTED) && (timeout > millis())) {
    delay(1);
  }

  if ((WiFi.status() != WL_CONNECTED)) {
     Serial.println("WiFi FAILed to connect");
  } else {
     Serial.print("WiFi connected in: "); Serial.print(millis()-setupStartMillis);
     Serial.print(", IP: "); Serial.print(WiFi.localIP());
     Serial.print(", Mac: "); Serial.print(WiFi.macAddress());
     Serial.println();
  }

  Serial.println("delay(10000)...");
  delay(10000);

  Serial.print("Deep sleep for ");
  Serial.print(SLEEP_INFTERVAL / 1000000);
  Serial.println(" secs...");
  ESP.deepSleep(SLEEP_INFTERVAL);
//  system_deep_sleep_set_option(0);
//  system_deep_sleep(SLEEP_INFTERVAL);
//  delay(1000); // needed as sleep seems to tak a little while to happen
}

void loop() {
   // should never get here
}```

[zenmanenergy]

I'm having a similar problem. I thought it was something in my code, but now if I load up the WiFiAccessPoint.ino example the same thing happens. For me, it takes 30 seconds for the first web request to happen.

But once that request is made it's fast again...unless I disconnect from the esp. When I connect again, the first web request takes 30 seconds.

[igrr]

I think SPIFFS is not the direct cause. When you switch flash size, SDK config is mapped into different sectors. What may be happening, is that SDK config sectors which correspond to larger flash size contain some (erroneous) setting which makes connections slower.
When you select 512k flash option, other sectors get loaded for SDK config, and they do not contain this problematic setting. Could you please make a dump of your flash memory and upload it somewhere so I can try to reproduce this?

esptool.py -p /dev/tty.usbserial read_flash 0 4194304 flash.bin

[torntrousers]

Thanks for looking @igrr. Here is that. This is from a NodeMCU 1.0 board which is showing the slow connect problem.

flash.bin.zip

[antelder]

Noticed the reference from #1177 so reading that saw the suggestion to erase the flash so gave that a go.

Using a NodeMCU 0.9 board first tested it was really a slow connecting board, then uploading with no SPIFFs made it connect fast, then uploading as NodeMCU 0.9 made it slow again, then python esptool.py --port COM4 erase_flash. Now uploading as NodeMCU 0.9 - its still slow to connect, then uploading as Generic with no SPIFFs - also still slow again!

So now nothing i try gets it to connect fast again :(

[asetyde]

use old stable 1.6.5

On 10 dic 2015, at 11:04, antelder [email protected] wrote:

Noticed the reference from #1177 #1177 so reading that saw the suggestion to erase the flash so gave that a go.

Using a NodeMCU 0.9 board first tested it was really a slow connecting board, then uploading with no SPIFFs made it connect fast, then uploading as NodeMCU 0.9 made it slow again, then python esptool.py --port COM4 erase_flash. Now uploading as NodeMCU 0.9 - its still slow to connect, then uploading as Generic with no SPIFFs - also still slow again!

So now nothing i try gets it to connect fast again :(

—
Reply to this email directly or view it on GitHub #1147 (comment).

[torntrousers]

Ok yes using an old version of the Arduino/ESP IDE code gets it fast again. Reflashed with the original 1.6.1 code and it went back to doing the fast connect, then back to the latest 2.0.0 code and it works fast when using the Generic / no SPIFFS upload and slow connect when using the NodeMCU 0.9 upload.

[Links2004]

please retest with the latest git.
WiFi management is has been reworked #1323

[torntrousers]

Yes, this does appear to be fixed in the latest 2.1.0-rc1 code. Thanks!