ESP8266 Developer Zone

Re: Inconsistent sleeping with SDK 2.1.0 uint64_t sleep times

2017-06-30T03:56:45+08:00

ok if I reformulate

Code:

(max time_in_us / cali) << 12 = 2^31 - 1

taking <<12 for multiply by 2^12 (4096) I get

Code:

max_us = ((2^31-1)/2^12)*cali

or approx

Code:

max_us < 2^19*cali

with system_rtc_clock_cali_proc() returning values in the range 22300 - 23100 (even varying on continous readings w/o reboot ???)
taking 22000 for safety, this gives max deep sleep of ~11500s ~~ 3.2h

Statistics: Posted by schufti — Fri Jun 30, 2017 3:56 am

Re: Inconsistent sleeping with SDK 2.1.0 uint64_t sleep times

2017-06-19T10:04:05+08:00

Hi Bremer,

The deep sleep 0 issue has been solved, please have a try with the latest SDK. https://github.com/espressif/ESP8266_NONOS_SDK

Thanks for your interest in ESP8266!

Statistics: Posted by ESP_Faye — Mon Jun 19, 2017 10:04 am

Re: Inconsistent sleeping with SDK 2.1.0 uint64_t sleep times

2017-06-18T20:45:09+08:00

I found another problem with system_deep_sleep(0)

Statistics: Posted by Bremer — Sun Jun 18, 2017 8:45 pm

Re: Inconsistent sleeping with SDK 2.1.0 uint64_t sleep times

2017-06-15T17:51:58+08:00

The latest doc changed to (time_in_us / cali) << 12 = 2^31 - 1
Mine is 3.5 hours.

Statistics: Posted by Her Mary — Thu Jun 15, 2017 5:51 pm

Re: Inconsistent sleeping with SDK 2.1.0 uint64_t sleep times

2017-06-01T12:51:59+08:00

If thats the case then the longer sleep times should be fine, right? So why aren't they working for me? Could someone else here just try a deep sleep for 21600000000 (six hours) and see if it works for them or not?

Statistics: Posted by torntrousers — Thu Jun 01, 2017 12:51 pm

Re: Inconsistent sleeping with SDK 2.1.0 uint64_t sleep times

2017-06-01T14:13:39+08:00

I think the "<< 12" means "bit11 ~ bit0 are decimal"... So the "cali" should not be "6", but 6xxxx...
It is "cali = system_rtc_clock_cali_proc()", not "cali = system_rtc_clock_cali_proc()>>12".

Statistics: Posted by Her Mary — Thu Jun 01, 2017 11:26 am

Re: Inconsistent sleeping with SDK 2.1.0 uint64_t sleep times

2017-05-31T16:08:40+08:00

I'm having trouble with the maths. In the API guide in system_deep_sleep in 3.3.9 it says:

The theoretical maximum value of time_in_us can be calculated by formula:
(time_in_us / cali) << 12 = 2^32 - 1
• cali = system_rtc_clock_cali_proc(), the cali is the RTC clock period (in us)

In system_rtc_clock_cali_proc in 3.3.22 it says:

RTC clock period (in us); bit11 ~ bit0 are decimal.
Example os_printf("clk cal : %d \r\n",system_rtc_clock_cali_proc()>>12);

When I try that printf on an ESP8266 it outputs "clk cal : 6"

So (time_in_us / cali) << 12 = 2^32 - 1
So time_in-us = ( (2^32 - 1) >> 12 ) * 6
= 6291450

Which is just 6 seconds! Clearly wrong as it sleeps for longer than that fine. Can anyone do the maths better?

Statistics: Posted by torntrousers — Wed May 31, 2017 4:08 pm

Re: Inconsistent sleeping with SDK 2.1.0 uint64_t sleep times

2017-05-31T13:57:53+08:00

May it be the maximum limitation of sleep time?
It is mentioned in the non OS API guide.

Statistics: Posted by Her Mary — Wed May 31, 2017 1:57 pm

Re: Inconsistent sleeping with SDK 2.1.0 uint64_t sleep times

2017-05-30T16:35:49+08:00

Were you able to recreate this? Should be pretty easy - just try a deepSleep for 6 hours and it should wake up right away instead of sleeping.

Statistics: Posted by torntrousers — Tue May 30, 2017 4:35 pm

Re: Inconsistent sleeping with SDK 2.1.0 uint64_t sleep times

2017-05-28T21:41:21+08:00

Reset cause 2 means that you are getting the reboot due to reset pin activation.
Ensure that this has nothing to do with loose connections, if you are working on a prototype. Meanwhile I will let you know if I can reproduce this exact problem.

Statistics: Posted by Guest — Sun May 28, 2017 9:41 pm

Inconsistent sleeping with SDK 2.1.0 uint64_t sleep times

2017-05-27T16:56:08+08:00

I'm trying the extended deepSleep times available with the latest ESP8266 SDK 2.1.0. Some sleep time values work fine but some don't seem to work and the ESP wakes up almost immediately. Bit strange.

For example, calling system_deep_sleep with these works as expected:
uint64_t sleepTime = 10000000; // WORKS: 10 seconds
uint64_t sleepTime = 7200000000; // WORKS: 2 hours
uint64_t sleepTime = 9000000000; // WORKS: 2.5 hours
uint64_t sleepTime = 86400000000; // WORKS: 24 hours

But calling system_deep_sleep with values like these doesn't work and the ESP8266 wakes up almost immediately:
uint64_t sleepTime = 21600000000; // FAILS: 6 hours
uint64_t sleepTime = 74049000000; // FAILS: bit over 20 hours

In all cases system_deep_sleep is returning true, and the ESP8266 wakes up with rst cause:2, boot mode:(3,6).

What could be wrong, is this a bug?

Statistics: Posted by torntrousers — Sat May 27, 2017 4:56 pm