Inconsistent sleeping with SDK 2.1.0 uint64_t sleep times

[torntrousers]

I'm trying the extended deepSleep times available with the latest SDK 2.1.0 from #3278

Some sleep time values work fine but some don't seem to work and the ESP wakes up almost immediately. Bit strange. Here's a sketch that shows the problem:

extern "C" {
  #include "user_interface.h"
}
 
void setup() {
  Serial.begin(115200); Serial.println(); 
  Serial.print("rtc proc: "); Serial.println(system_rtc_clock_cali_proc());

  // uint64_t sleepTime =  60000000; // WORKS: 60 seconds
  // uint64_t sleepTime =  7200000000; // WORKS: 2 hours
  // uint64_t sleepTime =  9000000000; // WORKS: 2.5 hours
  uint64_t sleepTime = 21600000000; // FAILS: 6 hours
  // uint64_t sleepTime = 74049000000; // FAILS: bit over 20 hours
  // uint64_t sleepTime = 86400000000; // WORKS: 24 hours
  
  Serial.println("deepSleeping ..."); 
  system_deep_sleep(sleepTime);
  delay(100);
}

void loop() {
  // shouldn't get here
  Serial.println("loop");
  delay(1000);
}

[igrr]

That's a good observation, however would it make more sense to report this at bbs.espressif.com, given that this is looks like an issue in an SDK function?
Does system_deep_sleep produce some error message for the "FAILS" cases, if you enable Serial.setDebugOutput(true);?

[torntrousers]

No error with setDebugoutput(true), and system_deep_sleep is returning true in both cases and both cases wake up with rst cause:2, boot mode:(3,6).

Yes I suppose you're right about raising it at bbs.espressif.com, i'll go do that.

[torntrousers]

The bbs.espressif question is over here: http://bbs.espressif.com/viewtopic.php?f=7&t=4771
Nothing so helpful there yet. Could someone else here just try a deep sleep for 21600000000 (six hours) and see if it works for them or not?

[torntrousers]

From this calculation it looks like 3.2 hours is the max sleep time even with 64 bits.

[5chufti]

just to let dev's know: allthough the 2.1.0 branch has the new sdk libs, the deep_sleep in esp core still is uint32_t only and lacks system_rtc_clock_cali_proc().

here a patch

[pieman64]

@5chufti can you please advise what the maximum deepSleep time is, in seconds, with your patch?

Does it come out to around 3.2 hours or 48 hours?

[5chufti]

Hi,
didn't take the time to check actual result of my calculations. But my calculations (~3.2h) fit well with torntrouser's observations.

[pieman64]

@torntrousers can we assume the following was incorrect?

// uint64_t sleepTime = 86400000000; // WORKS: 24 hours

[pieman64]

@5chufti I am using the master branch of the Arduino ESP8266 core and I then used your patch.
But whenever I go over the 4294 maximum seconds I am getting:

time selected mod 4294 seconds

Any idea why the patch isn't giving me the new maximum durations?

[5chufti]

because the master branch still is on sdk 2.0.0 ???

[pieman64]

@5chufti I think you are probably right. What I did from the @igrr pull #3278 was look through all the changes and manually edited the relevant files that referred to deepSleep. But what I didn't do was select any of the new binaries. I will ask on the pull request which library changes are deepSleep related but do you know which ones they are or did you just use all of 3278 pull?

[5chufti]

@pieman64 I would suggest to swap everything under tools/sdk (to get sdk 2.1.0)
you'll never know cross dependencies inside the sdk binary blobs and want to avoid "frankenstein" sw

[pieman64]

Hi @5chufti

Returning to this thread as it's dedicated to deepSleep. Thanks for your patience on this.

I decided to do a separate portable install of Arduino IDE and use 2.1.0 SDK right from the off.
For a long time I was still struggling with system_deep_sleep() and ESP.deepSleep() but now I am making progress as shown in Serial Monitor output below:

Current time: 16:41:14
Trigger time has already passed for today
Sleeping for maximum time
RTC speed: 25187
I'm going to Sleep for 13000 seconds
I'm going to Sleep for 13000000 milliseconds (or X 1000 microseconds)

This is using your patch so we can call Serial.println(ESP.cali_proc()) and ESP.deepSleep().
Still got a few hours to go before I can confirm 13000s is OK (maximum is around 13200 depending on cali) but at least it's not doing the modulus dance anymore.

[pieman64]

Triggered around 360s early against the 13000s deepSleep duration. So a little under 3% "early" as was always the case with deepSleep(). 13000s it a bit tight and needs a cali of 25000. Most of the time my ESP's are above this but to be safe I'm dropping down to 12600s exactly 3h30m and required a cali of 24000.

[5chufti]

considering the overall results, I see no need for ESP.cali_proc. cali varies to much even during same loop that there is no benefit knowing it. After all one could use
system_rtc_clock_cali_proc(); after including user_interface.h instead.
just think of 3h30 being a reasonable limit.

[pieman64]

@5chufti it serves the purpose of defining an approximation of the maximum deepSleep without using the user.interface.h

[Tech-TX]

You can probably close this one. Using Anthony's code from the first post, the code falls through system_deep_sleep(sleepTime); with values > 4 hours (including his original 24 hour number). It doesn't "wake up almost immediately", rather it doesn't sleep at all as it hits loop(), which will never happen if it sleeps correctly. With cali_proc() values in the range of 23500 to 25500 on one board I can get 3 hours 45 minutes maximum sleep time, although that will be erratic with other CPUs and temperatures; 3.2 to 3.5 hours will be more reliable.