Wemos D1 mini: sporadisches Aufhängen beim Booten nach Deep Sleep

Hallo zusammen,

nun bin ich mit meinen Ideen am Ende und hoffe, ihr habt einige Tipps für mein Problem...
Mein Wemos D1 bootet ab und zu nach einem Deep Sleep nicht richtig hoch. Zumindest hat dies den Anschein, laut den Printouts:

Der Code lief aber schon so 7 Monate durch. Den Wemos habe ich schon getauscht, doch das Problem blieb. Wenn der Controller nach dem Aufwecken (entweder über Reset-Button oder über Brücke RST mit D0) nicht korrekt hochfährt (letzte Zeile aus dem Screenshot), bleibt er dort für "immer" hängen.
Da er es aber nicht immer beim Booten hängt, kann es kein elektrisches Problem sein, oder?

Habt ihr eine Idee was es sein könnte?

Woran genau machst du das fest? Die „Prinouts“ sehen doch ok aus. Was ist für dich nicht richtig?

bau mal deine Ausgaben auf 74880 baud um,
lese die Serielle Schnittstelle mit 74880
und dann berichte, was er rausschreibt wenn er hängen bleibt vs. in den gut Fällen.

nachfolgende Printouts fehlen... "going to sleep.." und es folgen keine weitere wieder nache einer Minute

das ist ja cool! Diese "Funktion" kannte ich noch nicht. Der erste Reset war durch den "Reset" Button, der zweite durch sich selbst. Dann war schon wieder Schluss.

18:37:14.684 ->  ets Jan  8 2013,rst cause:2, boot mode:(3,6)
18:37:14.684 -> 
18:37:14.684 -> load 0x4010f000, len 1384, room 16 
18:37:14.684 -> tail 8
18:37:14.684 -> chksum 0x2d
18:37:14.684 -> csum 0x2d
18:37:14.684 -> v951aeffa
18:37:14.684 -> ~ld
18:37:14.731 -> 
18:37:14.731 -> DEBUG Messages on...
18:37:14.731 -> ControllerBoot_Cnt: 0
18:37:17.696 -> connected to WiFi - IP: 192.168.179.62
18:37:17.787 -> going to sleep....
18:38:14.528 -> 
18:38:14.528 ->  ets Jan  8 2013,rst cause:2, boot mode:(1,6)
18:38:14.528 -> 

und ein zweiter Test

18:45:05.957 ->  ets Jan  8 2013,rst cause:2, boot mode:(3,6)
18:45:06.004 -> 
18:45:06.004 -> load 0x4010f000, len 1384, room 16 
18:45:06.004 -> tail 8
18:45:06.004 -> chksum 0x2d
18:45:06.004 -> csum 0x2d
18:45:06.004 -> v951aeffa
18:45:06.004 -> ~ld
18:45:06.050 -> 
18:45:06.050 -> DEBUG Messages on...
18:45:06.050 -> ControllerBoot_Cnt: 0
18:45:06.287 -> connected to WiFi - IP: 192.168.179.62
18:45:09.111 -> going to sleep....
18:46:06.668 -> 
18:46:06.668 ->  ets Jan  8 2013,rst cause:2, boot mode:(3,6)
18:46:06.668 -> 
18:46:06.668 -> load 0x4010f000, len 1384, room 16 
18:46:06.668 -> tail 8
18:46:06.668 -> chksum 0x2d
18:46:06.668 -> csum 0x2d
18:46:06.668 -> v951aeffa
18:46:06.668 -> ~ld
18:46:06.716 -> 
18:46:06.716 -> DEBUG Messages on...
18:46:06.716 -> ControllerBoot_Cnt: 0
18:46:06.998 -> connected to WiFi - IP: 192.168.179.62
18:46:07.092 -> going to sleep....
18:47:05.749 -> 
18:47:05.749 ->  ets Jan  8 2013,rst cause:2, boot mode:(1,6)
18:47:05.749 -> 

es scheint was mit dem boot mode zu tun zu haben. Was bedeutet (1,6) hier?

Um mal Espressif zu Zitieren

Boot Mode Selection - ESP8266 - — esptool.py latest documentation (espressif.com)

Dein ESP scheint ab und zu zu versuchen ein Programm in den Flash zu laden.

hängt an gefährlichen Pins was an Hardware? Hast dort Pegel die das versachen können?

ja, ich habe am GPIO 0 was hängen. Wusste bis dato gar nicht, dass es "gefährliche Pins" mit GPIO 0, 2 und 15 gibt.
Was bedeutet das nun.. wann und wie sollte man diese nutzen?
Ich werde jetzt einen anderen Pin nehmen und dann sollte das Problem nicht mehr auftreten

ja halt nichts was dich in den Bootmodus bringen kann.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.