ESP.deepSleepMax() - "deep sleep too long"

[artua]

• Hardware: [ESP-12]
• Core Version: [ff74813]
• Development Env: [Arduino IDE]
• Operating System: [MacOS]

Settings in IDE

• Module: [Generic ESP8266 Module]
• Flash Mode: [qio]
• Flash Size: [4MB/1MB]
• lwip Variant: [v2 Lower Memory]
• Reset Method: [nodemcu]
• Flash Frequency: [40Mhz]
• CPU Frequency: [160MHz]
• Upload Using: [SERIAL]
• Upload Speed: [115200]

Problem Description

ESP.deepSleep(ESP.deepSleepMax()) not working, returns "deep sleep too long".

MCVE Sketch

void setup() {
    Serial.begin(74880);
    uint64_t deepSleepMax = ESP.deepSleepMax();
    ESP.deepSleep(deepSleepMax, WAKE_RF_DISABLED);
}

Debug Messages

SDK:2.2.1(cfd48f3)/Core:2.4.1-130-gff74813d/lwIP:2.0.3(STABLE-2_0_3_RELEASE/glue:arduino-2.4.1-13-g163bb82)/BearSSL:6d1cefc
deep sleep too long
scandone
error: pll_cal exceeds 2ms!!!
no esp_update found, reconnect after 1s
reconnect
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!
error: pll_cal exceeds 2ms!!!

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

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
vff74813d
~ld

SDK:2.2.1(cfd48f3)/Core:2.4.1-130-gff74813d/lwIP:2.0.3(STABLE-2_0_3_RELEASE/glue:arduino-2.4.1-13-g163bb82)/BearSSL:6d1cefc
deep sleep too long
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

[devyte]

CC @marcvtew

[Marc-Vreeburg]

@artua I'm currently testing/investigating what deepSleepMax() really means. I'll post the results of my testing probably this week at #4936

[Marc-Vreeburg]

I am using git version of master branch from last week with sdk v2.1.0-10-g509eae8.
ESP.deepSleep(ESP.deepSleepMax(), WAKE_RF_DEFAULT) just compiles without error.
I see you're using SDK:2.2.1(cfd48f3). Try using sdk v2.1.0-10-g509eae8 and see if the error still pops up.

In your sketch you should add delay(1000); after ESP.deepSleep(deepSleepMax, WAKE_RF_DISABLED);

[artua]

I have no problem with compiling it. It just tell me “deep sleep too long” in serial log...

…

On Mon, Jul 30, 2018 at 3:08 PM marcvtew ***@***.***> wrote: I am using git version of master branch from last week with sdk v2.1.0-10-g509eae8. ESP.deepSleep(ESP.deepSleepMax(), WAKE_RF_DEFAULT) just compiles without error. I see you're using SDK:2.2.1(cfd48f3). Try using sdk v2.1.0-10-g509eae8 and see if the error still pops up. In your sketch you should add delay(1000); after ESP.deepSleep(deepSleepMax, WAKE_RF_DISABLED); — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4969 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGV_3ePlUnl0KSNf7V8oADBASJ5xaIicks5uLvckgaJpZM4VkOwI> .

[devyte]

Interesting, we don't have such a message, so it must come from the sdk.
But if there is a check inside the sdk, what causes the never waking up again?

[artua]

I never said it causes "never waking up", for me it causes "never sleep", or sleep for unknown period. Should be deep tested here.

…

On Mon, Jul 30, 2018 at 11:52 PM, Develo ***@***.***> wrote: Interesting, we don't have such a message, so it must come from the sdk. But if there is a check inside the sdk, what causes the never waking up again? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4969 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGV_3TKnLD1jTaaixlInITgFfPzLi96Aks5uL3HygaJpZM4VkOwI> .

[earlephilhower]

Arduino/cores/esp8266/Esp.cpp

Lines 117 to 124 in 75a6a3f

	//this calculation was taken verbatim from the SDK api reference for SDK 2.1.0.
	//Note: system_rtc_clock_cali_proc() returns a uint32_t, even though system_deep_sleep() takes a uint64_t.
	uint64_t EspClass::deepSleepMax()
	{
	//cali*(2^31-1)/(2^12)
	return (uint64_t)system_rtc_clock_cali_proc()*(0x80000000-1)/(0x1000);
	}

Is it simply a matter of checking the latest SDK docs and verifying this calculation is still valid, or if it's changed? Seems like deepSleepMax() should work no matter what (c.f. #4936 where people are saying it doesn't actually give the right number and are experimentally trying things)...

[5chufti]

the lastest SDK document is - regarding max deep sleep and cali_proc - even more questionable than the ones before.

If I look at the output of the formula

s_printf("cal: %d.%d \n", ((cali1000)>>12)/1000, ((cali1000)>>12)%1000 ); (c.f. A.2)

for system_rtc_clock_cali_proc() =
0x6249 it returns 6.142 us
0x60d9 it returns 6.52 us

higher "decimal" value for lower hex value?

but even if one regards the "interger" part only, defining the highest 4 bits as integer part of cali,

cali = system_rtc_clock_cali_proc(), the cali is the RTC clock period (in us); bit11 ~ bit0 are decimal. For more details about the cali, please see the API: system_rtc_clock_cali_proc (c.f 3.3.50)

cali translates to values in the range 5<periode<7 µs.

Further assuming that 2^32-1 from

The theoretical maximum value of time_in_us can be calculated by formula:
(time_in_us / cali) << 12 = 2^32 - 1 (c.f. 3.3.50)

indicates a 32bit timer, then the max sleep time would be 0xFFFFFFFF * periode giving something between 21474.8 to 30064.8 s.

So the ~12000s returned by deepSleepMax() should be safe ???

[devyte]

um, the deepSleepMax() formula is implemented as (time_in_us / cali) << 12 = 2^31 - 1

[5chufti]

that may explain the factor 2 in the result ;)

just updated from git and tried
ESP.deepSleep(0x500000000); // hex for 21474.836480s
w/o any error message - but I'm not going to wait for the wakeup.

edit: but I don't get any error with the MCVE sketch either ...

[devyte]

@5chufti said:

then the max sleep time would be 0xFFFFFFFF * periode

aren't you forgetting the divide by 2^12? The max sleep time would be period * 0xFFFFFFFF / 0x1000, which is the same as what is implemented in deepSleepMax(), except for the ^31<->^32 difference.

[5chufti]

what I tried to do is not calculating by formula but having an educated guess of what can be the intention behind the questionable

(time_in_us / cali) << 12 = 2^32 - 1 (c.f. 3.3.50)

and I concluded that most likely it should be

time_in_us / (cali >> 12) = 2^32 - 1

relying on the only sensible information that the single periode of the timer is ~5-7µs, roughly calculated from system_rtc_clock_cali_proc() by shifting right by 12, thus only regarding the integer part. With this period value being allways shorter than the real one, one is on the safe side regarding 32bit overflow when calculating max deepsleep time.

so, coming back to your question: no, the divide by 12 (cali >> 12!!!) is allready taken care in using 5..7 for periode.

this whole datasheet is of worst quality I have seen for a long time and the only one to deteriorate from version to version. They even still recommend shorting gpio16 to rst for deepsleep when it is commonly known to be the worst possible solution.

[devyte]

@5chufti very interesting theory! It neatly answers a question I had pending about the integer/decimal parts. I'll have to spend some quiet time (hard to find for me the these days) to analyze it, and contrast against the datasheet.
Also, I think I'll make a quick PR for testing.

As a side note: I was also under the impression that shorting gpio16 to rst is what's supposed to be done. I just saw the new wemos/lolin boards, and they come with two contacts ready to bridge for that purpose. What's a better solution? This is the kind of thing we should have documented somewhere.

[d-a-v]

To prevent any loss of precision, I think

(time_in_us / cali) << 12 = 2^32 - 1 (c.f. 3.3.50)

should be read as:

• time_in_us < (cali << (32-12))
• time_in_us < (cali<<20)
• time_in_s * 1000000 < cali * 1048576
• time_in_s < cali * 1.048576

this is always satisfied by (which induces a small loss but not of precision)

• time_in_s < cali

That said, datasheet (I have v2.1.1 2018) states:

3.3.22. system_rtc_clock_cali_proc
Function      Get RTC clock period.
Prototype     uint32 system_get_rtc_time(void)
Parameter     none
Return        RTC clock period (in us); bit11 ~ bit0 are decimal.
Example       os_printf("clk	cal	:	%d	\r\n",system_rtc_clock_cali_proc()>>12);
Notes
• RTC clock period has decimal part.
• RTC clock period tends to drift with changes in temperature, so RTC timer is not very precise.
• See RTC demo in Appendix.A.

not very precise, decimal part in bits 0..11, and the confused function naming (system_rtc_clock_cali_proc vs system_get_rtc_time) are questionable.

What do you think of this time_in_s < cali
(or time_in_s < ( cali & ~((1<<12)-1) ) since whe should not consider bits 0..11 ?

[5chufti]

having a closer look I have to admit that

(time_in_us / cali) << 12

should be the same (even with better accuracy) as

time_in_us / (cali >> 12)

as

(t/1)/(c/k) == (t/1)*(k/c) == t*k/c*1 == (t/c)*k (k=2^12)

so everything boils down to

(t/c)*k=2^32-1 == (t/c)*k=0xFFFFFFFF == (t/c)=(0xFFFFFFFF/0x1000) == t=0xFFFFF*c
or
tmax(us)=0xFFFFF*system_rtc_clock_cali_proc()

which is in line with the implemented deepSleepMax() appart from the factor 2 error.

And as I had no error thrown at me trying 0x500000000 or deepSleeppMax() with yesterdays git, I cannot reproduce the OPs error, maybe he should recheck?

n.b: unfortunately tmax is a moving target. Knowing that, maybe something more on the safe side should be implemeted? Like lowering the 0xFFFFF constant by the average deviation measured on some sample boards (at various temps)?
edit: see also #4936 (comment)