ESPuino schaltet sich von selbst ein?!

Hallo,

ich habe diese Version gebaut :

Mit 6 Tasten (vor, zurück, Pause/Play, Lauter, Leiser) und nur den Taster vom Rotary Switch.
Jetzt kommt es manchmal vor, dass sich der ESPuino selbstständig einschaltet? Ich weiß nicht warum und wodurch. Tasten werden auf alle Fälle nicht gedrückt. RFID Tags sind alle weit weg.
Lässt sich aus einem LOG-File herausfinden, wodurch er/es/sie aufgeweckt wurde :slight_smile:

Bin echt ratlos, was mich stützig macht, dort steht „Neue Lautstärke empfangen via Queue: 5“, was hat das auf sich?

Hier der Inhalt vom LOG :

Maximale Inaktivitätszeit wurde aus NVS geladen: 5
RFID-Tags koennen jetzt gescannt werden…
Port-expander gefunden
Interrupt für Port-Expander aktiviert
Zyklus für Batteriemessung fuer Neopixel-Anzeige aus NVS geladen: 10 Minuten
Unterer Spannungslevel (Batterie) fuer Neopixel-Anzeige aus NVS geladen: 3.00 V
Oberer Spannungslevel (Batterie) fuer Neopixel-Anzeige aus NVS geladen: 4.20 V
Spannungslevel (Batterie) fuer Niedrig-Warnung via Neopixel aus NVS geladen: 3.40 V
Spannungslevel (Batterie) fuer Kritisch-Warnung via Neopixel aus NVS geladen: 3.10 V
Lautstärke vor dem letzten Shutdown wird wiederhergestellt. Dies überschreibt die Einstellung der initialen Lautstärke aus der GUI.
Initiale Lautstärke wurde aus NVS geladen: 5
Maximale Lautstärke für Lautsprecher wurde aus NVS geladen: 21
Lautsprecher eingeschaltet
Initiale LED-Helligkeit wurde aus NVS geladen: 16
LED-Helligkeit für Nachtmodus wurde aus NVS geladen: 2
Versuche SD-Karte wird im SD_MMC-Modus (1 Bit) zu mounten…
SD-Kartengröße / freier Speicherplatz: 15193 MB / 12217 MB
FTP-User wurde aus NVS geladen: esp32
FTP-Passwort wurde aus NVS geladen: esp32
Hostname aus NVS geladen: espuino
RFID-Tags koennen jetzt gescannt werden…
Aktuelle IP: 192.168.1.19
Synchronisiere Uhrzeit via NTP…
Freier Heap-Speicher nach Setup-Routine: 109344
PSRAM: 4194204 bytes
Flash-size: 16777216 bytes
RSSI: -48 dBm
Neue Lautstärke empfangen via Queue: 5
Letzte RFID konnte nicht aus NVS geladen werden
Aktuelle Batteriespannung: 3.46 V
no cover image for SD-card audio
build filelist finished: 73 ms
no cover image for SD-card audio
build filelist finished: 73 ms
no cover image for SD-card audio
Keine Bootschleife erkannt. Wunderbar :slight_smile:

An meinem Schreibtisch habe ich u.a. die Lötstation und auch die Hot Plate. Ganz selten kommt es mal vor, dass ein ich glaube Ausschaltvorgang den ESPuino zum Einschalten bringt. Gut möglich, dass die Anschlussleitungen hier irgendwie als Antenne wirken. Im Port-Expander sind ganz schwache (was auch immer das heißt) PullUp-Widerstände und da könnte man ggf. an jeden Button einen 100k PullUp zusätzlich hängen. Es erhöht halt nur den Strom, der im Deepsleep fließt.

Danke für den Hinweis, werd ich mal ausprobieren.

Eine andere Frage, aktuell kann jede Taste den ESP aufwecken.
Lässt sich das auf nur eine Taste ändern? (hätte noch einen freien Taster frei).
So wie ich das verstanden habe müsste das ein Pin nicht auf dem PortExpander sein.
Welcher Pin/GPIO wäre denn da noch frei, bzw. verwendbar.
Mit
#define WAKEUP_BUTTON 36
lässt sich das doch konfigurieren, oder?

Ich brauch eigentlich den Rotary Encoder nicht, also den könnte ich locker opfern - falls das hilft.

Jein. Also per Default sind alle Eingänge des Port-Expanders (PCA9555) Inputs. Und alles, was als Input konfiguriert ist, wird ausgewertet. D.h. ist der ESP im Deepsleep und es ändert sich auf einem Input-Pin des PCA der Level von HIGH nach LOW, dann wirft der PCA einen Interrupt und der ESP wacht auf.

Man hat jetzt zwei Möglichkeiten:
a) Man hängt den WAKEUP-BUTTON auf einen anderen GPIO, an dem dann ein Button direkt hängt. Mit 36 geht das jedoch nicht bei deinem Board (oder zumindest mal ist es nicht empfehlenswert), weil der wird auch als Interrupt-Pin für den PCA verwendet. Den PCA ohne Interrupt-Auswertung zu verwenden würde ich nicht machen, weil das recht langsam ist. Ne Möglichkeit wäre auf das neuere mini zu wechseln, da hier die Ansteuerung des Mosfets hier altermativ durch den Port-Expander erfolgen kann. Dadurch wird GPIO32 frei, den man dann für WakeUp konfigurieren könnte.
b) Man konfiguriert den PCA vor dem Deepsleep um. D.h. man konfiguriert Kanäle, auf die er nicht reagieren soll, auf Output um. Tatsächlich mache ich das sogar schon für HP_DETECT und GPIO_PA_EN: ESPuino/src/Port.cpp at 42d6ca80f9cd8099c8b90de3548e13ed5a17b416 · biologist79/ESPuino · GitHub. Ich denke wenn du hier deine Buttons dazunimmst, mit denen nicht geweckt werden soll, dann müsste das klappen.

Hallo zusammen,

mir ist leider nicht so ganz klar, wo genau der Pull-Up-Widerstand hin muss, um das Problem zu lösen. Ich benutze den PN5180 mit LPCD. Wenn ich das richtig verstehe müsste der Widerstand dann also zwischen den PIN IO0_6 des Portexpanders und 3,3V, richtig? Aber wie habt ihr das räumlich gelöst? An welcher Stelle bietet sich das an? Hat jemand Beispielbilder vielleicht?

Ich habe übrigens folgendes ausprobiert:

  • USB-C angeschlossen / LPCD aktiv → Espuino schaltet sich von selbst wieder ein
  • Akkubetrieb / LPCD aktiv → Espuino schaltet sich nicht von selbst wieder ein
  • USB-C angeschlossen / LPCD inaktiv (JP1 und JP4 entsprechend umgelötet) → Espuino schaltet sich nicht von selbst wieder ein
  • Akkubetrieb / LPCD inaktiv (JP1 und JP4 entsprechend umgelötet) → Espuino schaltet sich nicht von selbst wieder ein

Da sehe ich spontan zwei Möglichkeiten:
a) Direkt am PN5180 einen 10k-Widerstand zwischen IRQ und 3.3 V.
b) Unten auf der mini-Platine von JP4 ein 10k-Widerstand auf 3.3 V des PN5180-Konnektors.

Aber gut aufpassen, dass dabei kein Kurzschluss passiert. Weil wenn das passiert, dann kann der Festspannungsregler kaputt gehen. Tut er das, dann liefert er im besten Fall 0 V und nix geht mehr. Im blödesten Fall liefert er anschließend jedoch zu viel Spannung und reißt den ESP32 mit in den Tod.

War mir ehrlich gesagt aber nicht bewusst, dass es hier ein Problem gibt. Muss ich mir mal anschauen.

Habe mich für Variante a entschieden. Zunächst sah es 15 Sekunden lang so aus, als ob das Problem behoben wurde, aber dann schaltete sich der ESPuino doch wieder ein.

Wenn ich das richtig verstanden habe, kann so gut wie jeder Knopf, der an den Portexpander angeschlossen ist, den ESPuino aus dem Deepsleep holen, wenn LPCD aktiviert ist, oder? Ansonsten sollte dies planmäßig nur noch der Taster vom Rotary-Encoder tun. Ich werde jedenfalls LPCD jetzt einfach deaktivieren, denn für die Benutzung ist das finde ich eher unerheblich, und die ESPuinos sind überfällig. Würde mich für zukünftige Updates trotzdem interessieren, wie man das Lösen kann.

Hmm, jein :slight_smile:.
Beim Port-Expander (PE) ist es so, dass alle 16 Pins unabhängig voneinander als Eingang oder Ausgang konfiguriert werden können. Konfiguriert man nichts, dann hat man 16 Eingänge.

Kommt es zu einer Änderung an einem Eingang des PEs, so wirft dieser einen Interrupt, der dann im Gegenzug vom ESP32 registriert wird. Und wenn dieser pennt, dann wacht er auf. Deswegen kann man auch mit allen Tastern den ESP32 aufwecken.

LPCD ist am PE halt einfach nur ein Eingang, wie jeder andere auch. Durch das Schließen von JP4 wird der Interrupt-Ausgang des PN5180 mit dem PE verbunden. Das habe ich insbesondere deswegen so gemacht, weil der PN5180 im Normalbetrieb ständig (ich glaube alle 300 ms) Interrupts wirft. Da wir diese aber nicht auswerten und LPCD nur wenige Leute nutzen, halte ich das per Default vom PE halt fern.

Wenn man jetzt Pins hat, aufgrund deren kein Interrupt geworfen werden soll, so muss man diese als Output konfigurieren - anders geht das beim PCA9555 nicht. Das habe ich tatsächlich auch schon gemacht: ESPuino/src/Port.cpp at 266b3eb62abb2e6f46417609ce9185416b44576d · biologist79/ESPuino · GitHub. Und zwar weil mir eine angeschlossene Kopfhörerplatine sonst Probleme macht, wenn der ESP32 in den Deepsleep geht.

Hallo zusammen,

ich habe leider auch das gleich Problem. Alle paar Minuten geht der ESP automatisch an.
Verwende die selber HW. Nur das deaktiviere des LPCD löst das Problem.
Nur leider habe ich PN5180 entschieden um die Box durch auflegen zu wecken.

Update: Hatte noch die Firmware 4.0. Nach dem Update auf 4.1 scheint es jetzt zu funktionieren (Außer während des Ladens…)
Update 2: Funktioniert doch nicht…

Vielleicht ergibt sich hier eine Lösung.

Habe die Funktion jetz erstmal nochmal zrückgebaut und werde da die nächsten Tage / Wochen mal weiter debuggen. Vom jetzigen Kentnissstand folgende Ideen:

  • Metall in irgendeiner Form in der Nähe des Readers?
  • Kalibrierung kann angepasst werden, ist aber extrem fummelig. Will da erst noch weiter kommen bevor ich konkrete Vorschläge mit den EEPROMs und den Registern sende.
  • Wenn du den Port-Expander verwendest gibt es keine Möglichkeit die IRQs zu unterscheiden.
    Der Umbauvorschlag von Thorsten (Kleinere bugs/issues - #18 von biologist) löst dieses Problem, dannn ist es auch nicht mehr wichtig, ob der IRQ fälschlicherweise kommt (was je nach Umgebung / Aufbau / Parametrierung häufig vorkommt).

Hoffe bald noch mer dazu beitragen zu können…

Viele Grüße

Hast du da jetzt eigentlich einen PullUp-Widerstand eingelötet?
Ich bin gerade dabei, die mini-Platine nochmal etwas zu überarbeiten. Ich könnte prinzipiell natürlich hingehen und den IRQ-Pin umverdrahten auf 32 und als Power würde man dann immer 115 nehmen müssen (was aber ok ist).
Ich tue mir nur ein bisschen schwer damit, dass bei POWER per Default (aus Kompatibilitätsgründen) 32 drinsteht aktuell und damit ist es halt ein Ausgang. Wenn man das, ohne das vorher umzuflashen, per Lötbrücke mit PN5180.IRQ verbindet, dann ist das uncool. Da müsste ich einen Serienwiderstand reinmachen, ich muss nur mal in Erfahrung bringen, wie groß der sein darf. Wenn ich den Maximalstrom auf sowas wie 20 mA begrenzen wollte, dann müssten es mind. 165 Ohm sein.

Habe es ohne PU verwendet. Hatte mir die Spannungen aber angeschaut und das war super stabil und hat sich auch bei umdrehen der Polarität nicht geändert (auf active high). Daran liegt es sehr sicher nicht.

Verstehe deine Bedenken. Sobald es ein Eingang ist, spielt die Größe ja fast keine Rolle. Also kannst du ja bedenkenlos 1k oder auch größer nehmen…

Hi zusammen,

gibt es dazu schon etwas neues?

Nutzt du LPCD? Wenn ja, dann sollte es helfen, den IRQ-Pin des PN5180 nicht an den Port-Expander zu hängen (wie vorgesehen) sondern stattdessen auf GPIO32. Das setzt allerdings voraus, dass JP5 auf 2+3 gesetzt ist, damit GPIO32 frei ist.

nutze LPCD, funkltioniert auch super. Bis auf die automatischen WackeUps.
Leider ist alles fest verbaut und mir aktuell zu aufwändig, den Port umzulöten. Daher habe ich auf eine SW Lösung gehofft…
Aber vllt. komme ich die Tage dazu, das umzubauen. Werde hier berichten

Nur zur Einordnung:

  • Ich selbst nutze LPCD nicht, hatte jedoch, wenn ich es getestet habe, keine Probleme mit WakeUps.
  • Standardmäßig ist es beim mini-Board eigentlich nicht vorgesehen, den IRQ-Pin auf GPIO32 zu legen. D.h. du musst die Anschlussleitung, die vom JST-Stecker kommt und an IRQ geht, am PN5180 ablöten. Zusätzlich brauchst du eine neue Verbindungsleitung, die an GPIO32 und PN5180.IRQ geht. GPIO32 findest du am ext-Anschluss.
  • Es wurde hier schon berichtet, dass das Ganze über GPIO32 besser funktioniert. Was du auf jeden Fall mindestens gewinnst ist die Tatsache, dass das WakeUp per LPCD dediziert behandelt wird. D.h. selbst wenn es zum Aufwecken kommt, so wird sofort erkannt, dass keine Karte vorhanden ist und der ESP32 geht sofort wieder pennen. Das sind nur wenige Sekunden und man sieht davon auf dem LED-Ring auch nix.
  • Der IRQ-Pin steht aktuell auf 99, es spielt beim Port-Expander auch keine Rolle, was da steht. Wenn du aber 32 verwenden willst, dann muss da 32 hin.

WICHTIG WICHTIG WICHTIG!!!
Wo du allerdings unbedingt aufpassen musst: Solltest du 32 derzeit als Power-Pin verwenden, dann arbeitet der GPIO als Ausgang. Das verträgt sich natürlich nicht damit, dass ein IRQ-Pin ebenfalls als Ausgang arbeitet. Das muss unbedingt vorher umgeflasht werden, bevor man das anschließt. Aber so ziemlich alle Boards, die ich rausgeschickt habe, verwenden 115 als Power-Pin, d.h. 32 wird nicht benutzt. Da GPIO32 standardmäßig in settings-lolin_d32_pro_sdmmc_pe.h als Power-Pin drin ist und man die Änderung bei einem erneuten Flashen ggf vergessen kann, sollte man vielleicht überlegen, einen Widerstand zwischen GPIO32 und PN5180.IRQ einzulöten, um den dann anfallenden Strom zu begrenzen. Vielleicht so 220 Ohm, dann können nicht mehr als 15 mA fließen im Fehlerfalle. (Müsste man nochmal mit dem IRQ-Pin des PN5180 abgleichen, aber für den ESP32 wäre das absolut ok).

Edit: Habe gerade im Datasheet des PN5180 gesehen (Table 131), dass dort PullDown-Resistance mit 0,4 bis 0,7 MOhm definiert ist.

@tueddy Dann wäre das mit den 220 Ohm, was ich oben angesprochen habe, vermutlich überflüssig, oder? Weil der PN5180 würde den Strom ohnehin sehr stark begrenzen (500kOhm wären 6,6 µA bei 3.3 V).

Ich denke der Vorwiderstand zwischen GPIO32 & PN5180 IRQ ist überflüssig und kann direkt beschaltet werden. Im Falle einer falschen Konfiguration GPIO als Output „sollte“ nichts passieren.

Hoffe das sich jetzt niemand ein Board zerschießt :sunglasses:

1 „Gefällt mir“