ESP deep_sleep Bug?

[Andreas Neumann]

Hallo,

dass die ESP8266 mit heisser Nadel gestrickt und nicht zu Ende entwickelt
wurden, ist ja keine Neuigkeit.

Neu für mich ist aber, dass *keiner* meiner ESPs (01, 07, 12) mit der
maximalen Deep-Sleep-Zeit läuft, die welche wo nach den dürftigen Angaben
von Expressif 71 Minuten sein soll (runde 4,2x10e9 ľsec).
Meine Kandidaten schaffen maximal 35 Minuten, also ziemlich genau die
Hälfte. WZT?!? Ist da unterwegs das MSB des Registers verdunstet?
Bescheissen die Chinesen jetzt schon damit und bauen 31bit-Register ein?
Oder hat etwa die Arduino-Library einen Bug?

Ich habe das jetzt mehrfach mit 4 verschiedenen Exemplaren probiert, keiner
kann länger als 35 Minuten schlafen; bzw. wenn ich mehr "will", bleiben sie
ganz einfach komplett weg, bis man sie manuell resettet.

Wäre es möglich, dass mit einem kürzlichen Library-Update ein Bug mitkam?
Ich bin mir nicht ganz sicher, ob das nicht früher schon mal funktioniert
hat mit meinen Teilen, ich habe schon länger nichts mehr damit gemacht und
erst die Tage wieder damit rumgespielt.
Ich behaupte mal frech, dass es nicht an mir liegt, immerhin sind zwischen
2100x10e6 (funktioniert) und 4200x10e6 (funktioniert nicht) nur 2 Ziffern
anders, ich denke das kann ich unfallfrei eintippen.

Kann das jemand bestätigen oder im besten Fall widerlegen? Ist dazu
irgendwas bekannt? Im Netz habe ich nichts dazu gefunden.

 

[Christian Zietz]

Andreas Neumann schrieb:

Neu für mich ist aber, dass *keiner* meiner ESPs (01, 07, 12) mit der
maximalen Deep-Sleep-Zeit läuft, die welche wo nach den dürftigen Angaben
von Expressif 71 Minuten sein soll (runde 4,2x10e9 ľsec).
Meine Kandidaten schaffen maximal 35 Minuten, also ziemlich genau die
Hälfte. WZT?!? Ist da unterwegs das MSB des Registers verdunstet?
Bescheissen die Chinesen jetzt schon damit und bauen 31bit-Register ein?
Oder hat etwa die Arduino-Library einen Bug?

Prüfe doch mal, ob da irgendwo (z.B. in Deinem Code oder in der Library)
ein "unsigned" fehlt. So ein Bug schreit förmlich danach.

Ich behaupte mal frech, dass es nicht an mir liegt, immerhin sind zwischen
2100x10e6 (funktioniert) und 4200x10e6 (funktioniert nicht) nur 2 Ziffern
anders, ich denke das kann ich unfallfrei eintippen.

Zum Thema "unfallfrei eintippen": Dir sicherlich klar, dass 10e6 nicht
eine Millionen ist (das wäre 1e6) sondern zehn Millionen (also 10e6 ==
1e7). Ich nehme aber an, dass Du hier 4200*1e6 und oben in Wahrheit
4.2e9 meintest.

Grüße
Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

 

[Andreas Neumann]

Christian Zietz wrote:

Andreas Neumann schrieb:

Neu für mich ist aber, dass *keiner* meiner ESPs (01, 07, 12) mit der
maximalen Deep-Sleep-Zeit läuft, die welche wo nach den dürftigen Angaben
von Expressif 71 Minuten sein soll (runde 4,2x10e9 ľsec).
Meine Kandidaten schaffen maximal 35 Minuten, also ziemlich genau die
Hälfte. WZT?!? Ist da unterwegs das MSB des Registers verdunstet?
Bescheissen die Chinesen jetzt schon damit und bauen 31bit-Register ein?
Oder hat etwa die Arduino-Library einen Bug?

Prüfe doch mal, ob da irgendwo (z.B. in Deinem Code oder in der Library)
ein "unsigned" fehlt. So ein Bug schreit förmlich danach.

Das klingt plausibel, danke für den Tip.

Ich behaupte mal frech, dass es nicht an mir liegt, immerhin sind
zwischen 2100x10e6 (funktioniert) und 4200x10e6 (funktioniert nicht) nur
2 Ziffern anders, ich denke das kann ich unfallfrei eintippen.

Zum Thema "unfallfrei eintippen": Dir sicherlich klar, dass 10e6 nicht
eine Millionen ist (das wäre 1e6) sondern zehn Millionen (also 10e6 ==
1e7). Ich nehme aber an, dass Du hier 4200*1e6 und oben in Wahrheit
4.2e9 meintest.

Erwischt, da hast du natürlich recht...

 

[Christian Zietz]

Andreas Neumann schrieb:

> Das klingt plausibel, danke für den Tip.

Noch etwas: wenn ich mir die ES8266-Arduino-Lib, respektive die letzte
Änderung am Deep-Sleep-Modus angucke, sehe ich, 1.) dass das Argument
kürzlich auf uint64_t geändert wurde und 2.) dass eine Funktion
deepSleepMax() gibt, die die maximal unterstützte Deep-Sleep-Zeit in ľs
zurückgibt:
<https://github.com/esp8266/Arduino/commit/8da1d78cb4b68d6bebac50892b9b8be1092b8654#diff-2162e3da48a10d5899c93c262576c28e>

Hast Du geprüft, dass Du hier wirklich gut 4,2 Milliarden (also 2^32-1)
zurückbekommst und nicht vielleicht nur gut 2,1 Milliarden?
Offensichtlich hängt die maximale Deep-Sleep-Zeit vom Kalibrierwert der
RTC (system_rtc_clock_cali_proc()) ab.

Grüße
Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

 

[Christian Zietz]

Ich schrieb:

Hast Du geprĂźft, dass Du hier wirklich gut 4,2 Milliarden (also 2^32-1)
zurĂźckbekommst und nicht vielleicht nur gut 2,1 Milliarden?
Offensichtlich hängt die maximale Deep-Sleep-Zeit vom Kalibrierwert der
RTC (system_rtc_clock_cali_proc()) ab.

PS: Espressifs offizielle API-Dokumentation dazu:

bool system_deep_sleep(uint64 time_in_us)
time_in_us: the duration of time (Îźs) when the device is in Deep-sleep.
The theoretical maximum value of time_in_us can be calculated by
formula: (time_in_us / cali) << 12 = 2^31 - 1
• cali = system_rtc_clock_cali_proc(), the cali is the RTC clock period
(in us); [...]
• The input value of time_in_us should be less than the theoretical
maximum value.

Bleibt die Frage: Welchen Wert liefert system_rtc_clock_cali_proc() bei
Deinen Boards zurĂźck? Daraus ergibt sich die maximale Deep-Sleep-Zeit.

Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

 

[Hans-Peter Diettrich]

Am 07.04.2018 um 19:25 schrieb Andreas Neumann:

Neu für mich ist aber, dass *keiner* meiner ESPs (01, 07, 12) mit der
maximalen Deep-Sleep-Zeit läuft, die welche wo nach den dürftigen Angaben
von Expressif 71 Minuten sein soll (runde 4,2x10e9 ľsec).
Meine Kandidaten schaffen maximal 35 Minuten, also ziemlich genau die
Hälfte. WZT?!? Ist da unterwegs das MSB des Registers verdunstet?

Nein, die Hälfte ist der übliche Kompromiss für solche Rechnungen.
Sobald die Sleep-Zeit nicht durch einen Überlauf beendet wird, kann man
die Zeitdifferenz nur mit Vorzeichen rechnen (vor/nach gewünschter
Zeit), und muß damit auf die Hälfte des möglichen Bereichs verzichten.

DoDi

 

[Andreas Neumann]

Christian Zietz wrote:

Hast Du geprüft, dass Du hier wirklich gut 4,2 Milliarden (also 2^32-1)
zurückbekommst und nicht vielleicht nur gut 2,1 Milliarden?
Offensichtlich hängt die maximale Deep-Sleep-Zeit vom Kalibrierwert der
RTC (system_rtc_clock_cali_proc()) ab.

Die Funktion wirft einen Fehler:
error: call of overloaded 'print(uint64_t)' is ambiguous
Das übersteigt meine C-Kenntnisse; ich habe trotzdem einfach mal
Klein-Erna-mässig auf uint32_t gecastet und bekam tatsächlich was
zurückgeliefert. Interessanterweise bei jedem Versuch was anderes:
3227516922, 2909274106, 2894069754

Was auch immer diese Zahl nun bedeuten mag...

Bleibt die Frage: Welchen Wert liefert system_rtc_clock_cali_proc() bei
Deinen Boards zurück? Daraus ergibt sich die maximale Deep-Sleep-Zeit.

system_rtc_clock_cali_proc():
error: 'system_rtc_clock_cali_proc' was not declared in this scope
Auch hier reichen meine Kenntnisse nicht, um das korrekt einzubinden.


Dann habe ich einfach mal deepSleep() auf 32bit gecastet; das half aber
nicht, über 35min steht das Teil weiterhin.
Als nächsten Versuch habe ich den Datentyp von deepSleep() in ESP.cpp und
ESP.h auf uint32_t gesetzt.
Und siehe da: es läuft! Ich habe bisher je einen Durchlauf mit 40 und 50
Minuten geschafft, momentan läuft der 60-Minuten-Test. Das zieht sich halt
immer bis ein Ergebnis da ist, mal sehen ob ich bis zu den 71 Minuten
komme.
Jedenfalls scheint sich zu bestätigen, dass der Fehler mit einem
Library-Update kam, ich meine mich doch zu erinnern dass es früher schon
mal ging.

Ich bedanke mich recht herzlich für die Hilfestellung, von alleine wäre ich
da nicht drauf gekommen, wie gesagt spielt sich das an oder gar über der
Grenze meiner C-Fähigkeiten ab.

Was mich völlig ratlos lässt: warum definiert man deepSleep() als 64bit,
wenn das Register nur 32 hat? Wie kommt man auf so eine Idee?

 

[Christian Zietz]

Andreas Neumann schrieb:

zurückgeliefert. Interessanterweise bei jedem Versuch was anderes:
3227516922, 2909274106, 2894069754

Was auch immer diese Zahl nun bedeuten mag...

Die maximal von Deiner Hardware unterstützte Wartezeit in ľs. Sind also
weniger als 4*10^9 ľs.

Was mich völlig ratlos lässt: warum definiert man deepSleep() als 64bit,
wenn das Register nur 32 hat? Wie kommt man auf so eine Idee?

deepSleep übergibst Du die Zeit in Mikrosekunden, in das HW-Register
wird offensichtlich aber der Wert in RTC-Perioden geschrieben.
Dazwischen wird mit dem Resultat von system_rtc_clock_cali_proc()
umgerechnet. Um überlaufsicher zu sein, wird hier einfach mit dem
nächstgrößeren Datentyp uint64_t gerechnet.

Grüße
Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

 

[Andreas Neumann]

Christian Zietz wrote:

Andreas Neumann schrieb:

zurückgeliefert. Interessanterweise bei jedem Versuch was anderes:
3227516922, 2909274106, 2894069754

Was auch immer diese Zahl nun bedeuten mag...

Die maximal von Deiner Hardware unterstützte Wartezeit in ľs. Sind also
weniger als 4*10^9 ľs.

Den Gedanken hatte ich natürlich auch, aber 1. ändert sich der Wert bei
jedem Upload am *selben* Modul, 2. läuft der ESP07 seit gestern die Nacht
durch stabil mit 1h sleep time, also 3,6*10^9 ľs, was offensichtlich
deutlich mehr ist als obige Werte.
Das kann es also nicht sein. Möglicherweise kommen diese Werte durch meinen
blauäugigen cast auf 32bit und haben diesbezüglich keinerlei Aussagekraft.

Was mich völlig ratlos lässt: warum definiert man deepSleep() als 64bit,
wenn das Register nur 32 hat? Wie kommt man auf so eine Idee?

deepSleep übergibst Du die Zeit in Mikrosekunden, in das HW-Register
wird offensichtlich aber der Wert in RTC-Perioden geschrieben.
Dazwischen wird mit dem Resultat von system_rtc_clock_cali_proc()
umgerechnet. Um überlaufsicher zu sein, wird hier einfach mit dem
nächstgrößeren Datentyp uint64_t gerechnet.

Wenn das so einfach wäre, sollte man meinen das funktioniert, tut's aber
nicht...


Meine weiteren Versuche gestern ergaben, dass durch die Änderung auf 32bit
wieder, so wie früher, bis zu 71 Minuten geschlafen werden kann. Ab 71min
gibt es einen Rollover. Ein Test ergab 1min sleep time bei "eingestellten"
72 Minuten, immerhin bleibt er nicht komplett weg.