Hallo, ich habe mir bei AZ-Delivery ein paar ESP8266 geholt. Quasi die Wemos D1 Mini clones. Nun wollte ich den deepsleep aktivieren, allerdings wachen die Teile nicht wieder auf, bzw mit viel Glück nur einmal. Zuerst habe ich einen Sketch verwendet, der schon auf anderen D1 läuft. Als das nicht funktionierte, habe ich mich an ein einfaches Beispiel gehalten (https://randomnerdtutorials.com/esp8266-deep-sleep-with-arduino-ide/) und einen einfachen Sketch aufgespielt. /* * ESP8266 Deep sleep mode example * Rui Santos * Complete Project Details https://randomnerdtutorials.com */ void setup() { Serial.begin(115200); Serial.setTimeout(2000); // Wait for serial to initialize. while(!Serial) { } // Deep sleep mode for 30 seconds, the ESP8266 wakes up by itself when GPIO 16 (D0 in NodeMCU board) is connected to the RESET pin Serial.println("I'm awake, but I'm going into deep sleep mode for 30 seconds"); ESP.deepSleep(30e6); // Deep sleep mode until RESET pin is connected to a LOW signal (for example pushbutton or magnetic reed switch) //Serial.println("I'm awake, but I'm going into deep sleep mode until RESET pin is connected to a LOW signal"); //ESP.deepSleep(0); } void loop() { } Egal wie viele Sekunden ich auswähle, nach Ablauf der Schlafzeit leuchtet die blaue LED kurz auf, wie als würde ich den Kontroller an den Strom hängen. Mehr passiert nicht, auf der console erscheinen nur kryptische Zeichen und das war's. Kein nächster deepsleep. Ich habe RST und D0 mit einem Draht verbunden. Strom bekommt das ganze gerade über USB vom PC. Wie gesagt, das gleiche Setup funktioniert mit einem D1 von einem anderen Anbieter ohne Probleme seit Wochen. Habt ihr noch eine Idee, wo ich ansetzen muss?
ändere mal auf 74880 baud und setze den Pull-up
1 | Serial.begin(74880); |
2 | pinMode(D0, WAKEUP_PULLUP); |
:
Bearbeitet durch User
Zwischen den Timer Ausgang und dem Reset Eingang gehört ein 470 Ohm Widerstand. Wenn du dazu die Lötbrücke auf der Rückseite der Platine verwendest hast du ihn dabei. Und füge hinter deepsleep einen delay(100) ein, das soll manchmal auch helfen.
:
Bearbeitet durch User
Ich habe den Code wie von euch geschrieben angepasst. Serielle Geschwindigkeit auf 74880, den Pull-up gesetzt und am Ende nach ESP.sleep einen Delay eingebaut. Nun sehe ich zwar etwas auf der Konsole, aber der Controller wacht nur einmal nach 30 Sekunden auf. Das erscheint, nachdem das Teil Strom bekommen bzw. über den Reset Knopf gestartet wurde:
1 | load 0x4010f000, len 3584, room 16 |
2 | tail 0 |
3 | chksum 0xb0 |
4 | csum 0xb0 |
5 | v2843a5ac
|
6 | ~ld |
7 | I'm awake, but I'm going into deep sleep mode for 30 seconds |
Und das erscheint nach 30 Sekunden:
1 | ets Jan 8 2013,rst cause:2, boot mode:(3,6) |
Im Anschluss habe ich noch einen 470 Ohm Widerstand zwischen die beiden Pins gesteckt. Erstmal nur auf einem Steckbrett, aber es hat nichts an dem o.g. Ergebnis geändert.
Monk schrieb: > Und füge hinter deepsleep einen delay(100) ein, das soll manchmal auch > helfen. versuch's mal andersrum bzw im void loop() { }
:
Bearbeitet durch User
Ist das ein originales Wemos D1 Mini Board? Wenn nicht, haben die vielleicht Bauteile um den Reset Pin herum eingespart. Siehe http://stefanfrings.de/esp8266/index.html#deepsleep
Mir fällt da gerade ein, dass hier mal jemand von Flash Speichern berichtete, mit denen der Chip aus dem Deep-Sleep Modus nicht mehr richtig aufwachen konnte. Das Fehlerbild war das gleiche, wie bei dir. Siehe Beitrag "ESP01s + deepsleep"
Das hier steht in der Beschreibung der Bestellung: "Der AZ-Delivery D1 mini ist ein Mini-NodeMcu WiFi Board basierend auf einem ESP-8266-12F mit Micro-USB-Anschluss." Morgen schreibe ich dem Anbieter mal eine Mail mit dem Fehlerbild.
Angehängte Dateien:
-
ESP_Bot.jpg
110 KB -
ESP_Top.jpg
130 KB
Hallo, ich bin vor einigen Monaten in die gleiche Falle getappt, ebenfalls bestellt bei AZ Delivery. Und ja, es scheint etwas mit der Flash-Bestückung zu tun zu haben. Hab auch ewig mit Oszi und unterschiedlichsten R,C Bestückungen am besagten GPIO16-Kanal rumgespielt, ohne Erfolg. Daraufhin hab ich testweise nochmal eine Handvoll ESP01-S diesmal bei Roboter-Bausatz Dot de bestellt. Und mit denen funktionierte der DeepSleep! Ich habe mal zwei Bilder der unterschiedlichen Versender angehängt. Auffällig ist der unterschiedliche Aufdruck (sowohl Bottom als auch Top). Ausserdem wurden die ESPs von R-B einzeln in ESD Blistergurtstücken geliefert. Steve PS: nicht wundern, ich hab ein unmodifiziertes Modul von AZ für das Foto verwendet. PPS: ok, sehe grade, dass es sich um ein D1 mini handelt und nicht um ein ESP01-S
:
Bearbeitet durch User
Wie ich bisher sehen konnte, ist das Deep-Sleep des ESP eine absolute Krücke und überhaupt nicht vergleichbar, z.B. mit dem Power-Down eines AVR. Eine genaue Beschreibung des Deep-Sleep konnte ich leider nirgends finden, sondern nur rudimentäre Beispiele. Wie es aussieht, muß man den Resetpin über einen IO-Pin für eine bestimmte Zeit extern ziehen und darin liegt wohl das Hauptproblem. Der Pin schaltet sich durch das Reset natürlich selber wieder ab, d.h. der Puls wäre zu kurz und daher bleibt der ESP im Nirwana hängen. Empfohlen wird ein RC-Glied (470R+100nF) zur Verlängerung. Ob das immer sicher ausreicht, um vom Flash neu in den RAM zu booten, wissen die Götter. Das könnte jedenfalls die Abhängigkeit vom Flash-Typ erklären, daß manche etwas länger brauchen zu Aufwachen. Bei Problemen würde ich daher erstmal das RC-Glied vergrößern. Ich würde zum Stromsparen einen erheblich besser ausgerüsteten µC benutzen (z.B. AVR) und nur zum Funken den ESP unter Strom setzen. Falls jemand einen Link zum Datenblatt des ESP8266 kennt, welches die Bezeichnung auch verdient, immer her damit. Das mit nur 117 Seiten verdient es jedenfalls nicht.
Ich würde mal versuchen GPIO7 mit einem Pull-up high zu ziehen, das ist der zweite Kontakt unten, nicht nach außen geführt da verbunden mit dem Flash Speicher. https://github.com/esp8266/Arduino/issues/6007#issuecomment-2024041618 andere Möglichkeit: im Deep Sleep muss ja eine RTC aktiv sein. der Reset wird ja auch direkt nach 30 sek getriggert. kann es sein dass es so konzipiert ist dass das setup() im RAM den (zu kurzen) Reset überlebt? Dein loop() ist ja leer, also weißt Du nicht ob er wach ist oder sich aufgehängt hat. It's not a bug it's a feature. Ich würde das testen.
:
Bearbeitet durch User
Die nächsten Tage werde ich eure Tipps und Vorschläge mal testen, ich komme leider nicht jeden Tag dazu. Zwischenzeitlich habe ich mich mit AZ Delivery in Verbindung gesetzt und das Fehlerbild geschildert. Als Antwort kam folgendes: "Unsere technische Abteilung geht von einem Hardwaredefekt aus." Ich bekomme jetzt eine Rückerstattung. Was ich noch hinzufügen möchte: Mit anderen ESP8266, bestellt beim schnellen Ali, habe ich überhaupt keine Probleme mit dem DeepSleep. Nur habe ich da inzwischen leider 2 von 5 defekten Kontrollern. Sie lassen sich nicht mehr flashen. Deshalb habe ich mich diesmal für "Markenteile" entschieden. ;-)
Carsten schrieb: > Nur > habe ich da inzwischen leider 2 von 5 defekten Kontrollern. Sie lassen > sich nicht mehr flashen. Ich denke mal nicht, daß die wirklich defekt sind. Da wirds irgendwie die Bootfunktion im Flash gerissen haben. Viele ARM haben einen Ur-Bootloader über die UART, der über bestimmte Pins aktiviert wird. Damit kann man einen defekten Custom-Bootloader im Flash wieder reparieren, d.h. neu programmieren. Dazu müßte man aber ein Datenblatt haben, wo beschrieben steht, wie das geht. Die ESP scheinen doch ziemlich mit der heißen Nadel gestrickt worden zu sein.
Peter D. schrieb: > Da wirds irgendwie die Bootfunktion im Flash gerissen haben. Der Bereich wird als ROM bezeichnet. Ob das in Realität ein Flash ist, weiß ich nicht. Es liegt auf jeden Fall nicht in dem Flash Baustein, in dem das Programm oder SPIFFS steckt. Habe aber noch nie davon gehört, dass "eingebaute Bootloader" kaputt geht, oder gar repariert werden könnte. Einen Weiteren Bootloader gibt es üblicher weise nicht, wenn man von dem OTA Verfahren mal absieht.
Der Bootloader ist unveränderlich. Das esptool lädt zunächst einen "Stub" von der Festplatte des PC in den RAM des ESP und startet ihn. Dieser übertragt dann erst die Firmware in den Flash Speicher. Laut Doku von ESP dient der Stub auch dazu, Bugs des festen Bootloaders zu umgehen. https://docs.espressif.com/projects/esptool/en/latest/esp8266/esptool/flasher-stub.html Peter D. schrieb: > Die ESP scheinen doch ziemlich mit der heißen Nadel gestrickt worden zu > sein. Den Eindruck habe ich auch.
:
Bearbeitet durch User
Hi, Bei meinen ESPs lag es am Flash, der ist nach dem Deep Sleep nicht mehr aufgewacht und das Programm konnte vom Bootloader nicht geladen werden. Das Fehlerbild war wie beim TO. Geholfen hat der Sleep Modus von https://github.com/esp8266/Arduino/issues/6318#issuecomment-706386677 Gruß JackFrost
Bastian W. schrieb: > Geholfen hat der Sleep Modus von > https://github.com/esp8266/Arduino/issues/6318#issuecomment-706386677 Also magische Zahlen an magische Adressen schreiben. Einfach nur gruselig. Da bin ich ja heilfroh, keinen ESP gekauft zu haben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.