While the ESP8266’s DeepSleep mode is useful for conserving power, one ‘feature’ of it is that it resets the module.

Yes, you can store things in the “RTC” (not really an RTC!) memory, as that survives the reset, I was curious to know whether millis() (the number of milliseconds since the program commenced) also survived.

Simple sketch:

/*
 Generic ESP8266 Module
 80MHz CPU
 40MHz Flash
 DIO
 115200 Upload speed
 512K (no SPIFFS)
 ck reset method
 Disabled debug port
*/
#include <ESP8266WiFi.h>
#define SECONDS_TO_MICROSECONDS 1000000
void setup() {
 // put your setup code here, to run once:
delay(200); // short delay here allows time for UART to align, otherwise you get gobbledy gook
 Serial.begin(74880);
while (!Serial) {
 ; // wait for serial port to connect. Needed for native USB
 }
Serial.print("First stop, millis: ");
Serial.println(millis());
ESP.deepSleep(60 * SECONDS_TO_MICROSECONDS, WAKE_RF_DEFAULT);
 delay(100); // apparently this is needed after deepSleep - not sure why?!
}
void loop() {
 // put your main code here, to run repeatedly:
}

The output looked something like this:

First stop, millis: 26259

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
First stop, millis: 478

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
First stop, millis: 455

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld
First stop, millis: 453

If the second and third Serial.prints had been an increment of the first number then it would have suggested that millis() was fed by the RTC timer, and survived resets – but alas not. When you return from a DeepSleep it resets everything. As GPIO16 is tied to RST for this experiment, that also means that pressing RST would reset the millis() counter too – so it truly is milliseconds since the program commenced – not since the module was powered up.

That’s a real shame, as that means that when you come out of a sleep, you really need to make an NTP call (expensive power & CPU cycles & flash) if you need to know what the time/date is, rather than just doing it once and trusting the RTC time to carry things forward for you (albeit with temperature affected drift).