ich hatte endlich etwas Zeit, um meinen Testaufbau von letzten Herbst in ein Gehäuse zu verfrachten. Dabei habe ich auch gleich den aktuellen Stand von master gepullt und geflasht.
Nun habe ich das Problem, dass der Espuino sofort wieder aufwacht, wenn er aus gemacht wird. Das hatte ich beim Testaufbau noch nicht gehabt.
Beim Starten kommt im Serial-Monitor „Wakeup caused by push-button“.
Ich habe bereits versucht, alle Buttons, Leds und den Rotary-Encoder nacheinander bzw gleichzeitig zu entfernen. Das Problem war immer das gleiche.
Ich habe hier im Forum nur etwas dazu bei den Known-Issues für Arduino 2.0 gefunden, aber das ist ja in master offenbar noch nicht standardmäßig aktiv.
Hat jemand eine Idee woran es liegt oder was ich noch testen könnte? Danke!
(Ich verwende das Komplettpaket von biologist, also Portexpanderboard und LFP-Esp. Dazu einen PN5180.)
Um den Fehler einzugrenzen würde ich zunächst den offiziellen Master verwenden, der basiert auf Arduino 1.0.6.
Arduino 2.x ist noch experimentell und hat z.B. Probleme beim Abspielen von Musik mit Umlauten im Dateinamen.
Warscheinlichste Ursache ist dann aktiviertes LPCD: Dein Leser löst einen falschen Aufwachalarm aus und dieser Impuls geht an einen „push-button“ am PortExpander. Also erstmal hierPN5180_ENABLE_LPCD auskommentieren und clean-build durchführen.
Klappt es dann mit dem deep-sleep?
Das ist der Fall, habe ich vllt missverständlich formuliert. Ich hatte zwischendurch mal Arduino 2 probiert, was nichts geändert hatte, weshalb ich das wieder rückgängig gemacht habe.
Vergessen zu erwähnen, dass ich das bereits gemacht habe. Allerdings ohne clean vor dem build, das habe ich nun noch nachgeholt. Mal sehen.
Es ist nämlich so, dass das Problem nach einem Flashvorgang erst so nach 5-10 Minuten auftritt und dann aber dauerhaft.
Danke für die Idee, aber komplett stromlos hatte ich ihn mittlerweile sehr oft. Und wie gesagt benutze ich eigentlich kein Arduino 2.0, ich hatte das vor allem erwähnt, weil ich darüber per Suche gestolpert bin.
Ja, hatte ich ebenfalls vergessen zu erwähnen. In meinem Testaufbau hatte das aber eigentlich einwandfrei funktioniert. Evtl. hatte ich damals aber zu kurz getestet. Ich war übrigens der Typ aus diesem Thread.
Es liegt offenbar am PN5180, aber nicht an LPCD. Trotz deaktiviertem LPCD (mit clean build) tritt das Problem auf. Wenn ich den PN5180 vom Board abziehe bleibt das Gerät aus.
Ich werde (hoffentlich) morgen mal die Verkabelung prüfen. Evtl. hat sich da mittlerweile ein Wackelkontakt eingeschlichen. Obwohl ich die Drähte am PN5180 eigentlich gelötet habe. Vllt gabs da aber durch die Bewegung beim Einbauen irgendwo trotzdem nen Bruch.
Sehr merkwürdig. Wenn der PN5180-Leser funktioniert hängt es nur am IRQ-Pin für das aufwachen → „push-button“. Alles deutet darauf hin das Du LPCD noch aktiv hast. Eine Stolperstelle ist auch oft das verwendetete Profil/HAL beim compilieren, war da auch schon im falschen Film…
Hast Du das gecheckt?
Die Änderung bewirkt, dass der IRQ nicht mehr über den Port-Expander läuft sondern stattdessen über einen GPIO. Das hat den Vorteil, dass offenbar das Aufwecken kein Problem ist. Und wenn doch, dann legt sich der ESP32 direkt wieder schlafen, weil dieses Event dediziert behandelt wird.
Hmm ja leider. Es gibt auch keine gute Kalibrierung um den PN5180-Leser verbünftig einzuregeln.
Habe aber evt. dazu in Kürze eine Lösung, werde sie dann hier vorstellen…
Danke, das werde ich testen wenn ich nicht mehr weiter weiß. Eigentlich wollte ich 32 für den Hallsensor benutzen. Bei meinen Tests wegen dem Problem hier habe ich den Hallsensor natürlich auch als Quelle untersucht und abgesteckt. Softwareseitig habe ich den Hallsensor auch noch gar nicht konfiguriert.
Ist das so zu verstehen, dass prinzipbedingt ein PN5180 mit LPCD bzw entsprechend gesetzten Lötbrücken in Bezug auf Deep Sleep gar nicht am PE funktionieren kann und ich das so umsetzen muss wie von dir vorgeschlagen? Oder könnte mein Problem doch noch eine andere Ursache haben?
Also grundsätzlich ist es so, dass an einem PE erstmal alle Anschlüsse Inputs sind. Möchte man einen Output, dann muss man das konfigurieren. Kommt es an einem Input-Pin zu einer Pegeländerung, dann wird ein Interrupt geworfen. Dieser Interrupt wird vom ESP32 im laufenden Betrieb ausgewertet und dann alle Eingänge eingelesen - so ist dann klar, warum es einen Interrupt gab. Beim Deepsleep ist das anders: Da wird der ESP32 halt einfach aufgeweckt. Insofern geht das Aufwecken per Button oder RFID.IRQ den gleichen Weg und löst die gleiche Aktion aus: aufwecken.
Vorteil: PE-Eingänge hat man genügend
Nachteile: Man kann RFID.IRQ nicht unterscheiden und offenbar funktioniert das Ganze nicht 100% zuverlässig (obgleich ich selbst keine Probleme hatte).
Für LPCD ist jedoch eine erweiterte WakeUp-Routine in ESPuino implementiert, eine zweite Form des WakeUp quasi. Und nur LPCD benutzt diesen, wenn man dafür einen dedizierten GPIO verwendet (hier 32). Der ESP32 wacht dann auf und schaut, ob es ein Falschalarm war oder ob die „vermeintliche Karte“ tatsächlich existiert. Wenn ja, dann wird die Peripherie (SD, Neopixel…) angeschaltet und der ESP32 weckt alles auf. Wenn nein, dann legt er sich direkt wieder nach wenigsten Sekunden pennen.
In einem anderen Thread hier hat diese Lösung für eine bessere Deepsleep-Stabilität gesorgt. Und selbst wenn der ESP32 aufwecken würde, dann würde er direkt wieder Heia machen. Es kostet halt einen GPIO.
Müssen tust du das nicht. Aber in nem anderen Falle hier hat es auf jeden Fall funktioniert. Ich hatte mit Deepsleep am PE zumindest unter Arduino1 keine Probleme. Mit Arduino2 schon, aber mit der neuen mini 4L nicht mehr. Die verwendet allerdings auf jeden Fall den GPIO32 und keinen PE mehr - aus dem hier beschriebenen Grund. War mir halt damals nicht bewusst, sonst hätte ich das nicht an den PE gehängt.
Könnte ich auch GPIO5 dafür nehmen? Der ist wohl für IR vorgesehen, was ich nicht benutzen werde und zudem am PE-Board herausgeführt. GPIO0 sieht auch noch frei aus?
Du benötigst einen echten RTC Pin, GPIO0 und GPIO5 „könnten“ problematisch sein.
Hier gibt es eine sehr schöne Erklärung zu den einzelnen PINs, ich schage dort immer wieder nach:
„outputs PWM signal at boot“ ist da sicher nicht förderlich.
Generell frage ich mich gerade ob der PN5180 IRQ am Port-Expander nicht genauso funktionieren kann wie an einem echten GPIO? Beim Aufwachen müsste dann der Portexpander abgefragt werden ob der IRQ der Auslöser war- Also welcher Knopf gedrückt wurde. Wenn das der LPCD IRQ war wird die Kartenerkennung durchgeführt. Falls keine Karte erkannt legt der ESP sich wieder schlafen. Genauso wie bei einem echten GPIO.
Müsste das nicht so klappen oder habe ich da etwas übersehen?
Die Seite habe ich mir tatsächlich auch schon angeschaut. Ich habe aber nicht verstanden was „outputs PWM signal at boot“ genau heißt und beim überfliegen auch keine Erklärung gesehen.
Was genau meinst du mit „könnte“?
Das bedeutet ich habe keine Ahnung ob das klappt Du musst es mal ausprobieren.
„outputs PWM signal at boot“ verstehe ich so das auf dem PIN beim Startvorgang HIGH/LOW Signale anliegen. Das könnte die Erkennung erschweren. Daher würde ich diede GPIO’s nicht dafür verwenden.
Hi,
GPIO5 ist leider eines der wenigen, die kein RTC-Pin sind. Da wird ein Wakeup nicht gehen. Auch ist der ein strapping pin, d.h. sein Pegel entscheidet über das Timing beim Ansprechen des externen Flashes:
GPIO0 wird wahrscheinlich auch nicht funktionieren (ausprobiert habe ich es aber nicht). Wenn der beim Booten Low ist, geht der ESP in den Programmiermodus. Der IRQ ist Aktive-Low, hier könnte dann passieren, dass er aufwacht, aber halt nicht in den normalen Betrieb geht.
Alle GPIOs bei denen ein Wakeup möglich ist, sind auf der Webiste von tueddy in dem Kapitel " RTC GPIOs" aufgelistet.
Ich habe aber nicht verstanden was „outputs PWM signal at boot“ genau heißt und beim überfliegen auch keine Erklärung gesehen.
Du musst es mal ausprobieren.