Hmm, muss ich mir dann wohl noch mal anschauen. @tueddy hast du das Problem auch?
Auf jeden Fall ein ganz schön aufwändiges Feature muss ich sagen (von der Zeit, die ich da schon investiert habe) für gar nicht mal sooo viel Ertrag 
.
Es gibt ja zwei Möglichkeiten den ESPuino aufzuwecken, über den Button (EXT0) oder über Auflegen einer Karte (IRQ-Pin EXT1). Beim Start wird ja in der Konsole der Aufwachgrund ausgegeben. Ist das wirklich der Button? Ist der Button Pin kompatibel mit EXT0? Und PN5180 IRQ-Pin kompatibel mit EXT1?
So eine Schleife habe ich nicht, allerdings wacht mein ESP alle 2 Sekunden auf, prüft auf Karte und legt sich wieder schlafen. Das scheint mit dem Umdrehen der Logik auf dem IRQ Pin zusammenzuhängen, muss ich noch genauer anschauen.
Nur als Hinweis an den Rest: Normalerweise ist es so, dass der PN5180 den GPIO auf LOW zieht und im Falle eines Interrupts dann auf HIGH. Das hat sich für den Anschluss an einen Pin des Port-Expanders jedoch als unpraktisch erwiesen. Durch Schreiben in ein spezielles Register kann man dieses Verhalten jedoch umkehren:
Also für mich sieht es schon so aus wie von mir beschrieben. IRQ hängt an 33 und funktioniert eben auch für ISO-14443 tags. EDIT: Der ESPuino stürzt immer ab, auch wenn nur ein 14443-Tag aufgelegt wird. Der wird danach aber sofort gelesen.
Nur eben wenn eine ISO-15693 aufgelegt wird hängt er sich auf. Mir ist eben auch aufgefallen dass das anschließende lesen eines 14443-Tags den Fehler nicht behebt, sondern zu einem Absturz und Neustart führt.
Vielleicht könnt ihr ja aus dem Log den ich angehängt habe noch etwas rauslesen.
espuino_log.txt (6,2 KB)
Kannst Du das einmal compilieren mit
monitor_filters = esp32_exception_decoder
Also in der Platform.ini:
[env:ttgo_t8]
;https://docs.platformio.org/en/latest/boards/espressif32/esp-wrover-kit.html
board = esp-wrover-kit
;board_build.partitions = huge_app.csv
board_build.partitions = custom_4mb_noota.csv
build_flags = -DHAL=5
-DBOARD_HAS_PSRAM
-mfix-esp32-psram-cache-issue
-DLOG_BUFFER_SIZE=10240
monitor_filters = esp32_exception_decoder
Dann bekommst Du den Aufrufstack. Evt. kann man dann mehr sehen.
Cool, das wusste ich gar nicht. Hab das immer umständlich via Arduino IDE gemacht.
Der Fehler wird irgendwo in freertos geworfen in diesem Funktionsaufruf…
xQueueSend(gRfidCardQueue, cardIdString.c_str(), 0); // If PAUSE_WHEN_RFID_REMOVED isn't active, every card-apply leads to new playlist-generation
Backtrace: 0x40096594:0x3ffbb1d0 0x4009680d:0x3ffbb1f0 0x40097b56:0x3ffbb210 0x400d705d:0x3ffbb250 0x4009825e:0x3ffbb2a0
#0 0x40096594:0x3ffbb1d0 in invoke_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715
#1 0x4009680d:0x3ffbb1f0 in abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715
#2 0x40097b56:0x3ffbb210 in xQueueGenericSend at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/queue.c:2520
#3 0x400d705d:0x3ffbb250 in Rfid_Task(void*) at src/RfidPn5180.cpp:49
#4 0x4009825e:0x3ffbb2a0 in vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355
Update: gRfidCardQueue ist an dieser Stelle null, wurde vorher aber initialisiert…
Nachdem ich mir das jetzt eine Weile angeschaut habe, bin ich zu dem Schluss gekommen, dass es eine race condition zwischen Queues_Init(void) und lesen der RFID Karten gibt. Bei mir werden konsistent die RFID Karten schneller initialisiert und gelesen als die Queues erstellt werden können.
Warum das nur bei mir ist kann ich nicht verstehen.
Diese Theorie kann ich bestätigen, indem ich beim drücken des Reset-Knopfs (also sauberer Boot, kein Deepsleep) einen Tag auflege. Dann stürzt der ESPuino ebenso ab (aber nur 14443).
Also: Den Crash habe ich behoben. Das Problem mit der Aufwachschleife besteht weiterhin.
Kannst mal kurz runterschreiben, wie du das gefixt hast? Denke das sollte ich schon aufnehmen.
Ich kann den Crash hier nicht nachstellen, aufgelegte 14443 Karte + Hard-Reset → Musik wird sofort abgespielt…
Klar, einfach Queues_Init(); in der setup() weiter nach oben setzen. Ich habe es direkt nach Log_Init() geschrieben. Besser wäre vielleicht in Rfid_Init() zu warten bis die queue nicht null ist, aber mir reichte der Workaround.
Ja, ich finde auch mysteriös, dass das nur bei mir auftritt… Vielleicht liegt das am WROVER-E den mein Board hat?
Hallo,
ich habe das Verhalten das mein PN5180 „zu empfindlich“ ist…
D.h. wackeln an der Box/Hand vor den Leser halten lässt den ESP aufwecken, der dann bis zum eingestellten Sleep zeit aktiv bleibt… irgendwie doof…
Kann man da was einstellen?
btw ich hatte mal die LPCD aktiv, hab das aber wieder rausgenommen, scheint aber trotzdem weiterhin aktiv zu sein…
Aufbau: Lolin D32 pro mit SD_MMC, PN5180, max. fünf Buttons und Port-Expander (SMD)
@JHB hast Du ein Metall-Implantat in Deiner Hand? 
Der PN5180 misst sich im LPCD Mode selbst ein und wacht dann nur bei Änderungen im RF-Feld auf.
Verrwendest Du den aktuellen Master? Da wurden für LPCD noch kleinere Fehlerkorrekturen gemacht.
Wenn Du LPCD deaktiveren möchtest geht das ja in den Settings.h mit PN5180_ENABLE_LPCD.
Evt. hilft dann ein Clean + Build. Danach sollte das Feature deaktiviert sein.
@tueddy Ich habe tatsächlich auch manchmal den Eindruck, dass das ne ganze Weile im PN5180 persistiert, ehe es wieder weg ist.
Also ich bleibe dabei: UNFASSBAR VIEL AUFWAND FÜR SO EIN KLEINES FEATURE 
.
@JHB Ganz grundsätzlich haben wir hier halt das Problem, dass der IRQ auf den Port-Expander geht. Der PE wirft dann einen Interrupt und der ESP32 wacht auf. Das Event unterscheidet sich nicht von den Buttons. @tueddy hat das Feature aber eigentlich etwas anders entworfen. Denn dort kriegt der IRQ einen eigenen Button und damit kann man auch ein dediziertes Event „Wake-Up kam von PN5180 feststellen“. Denn wird dieses Event geworfen, dann wird geschaut, ob das Ganze ein Fehlalarm war. Wenn ja, dann geht der ESP32 direkt wieder pennen.
Also ja, ist etwas suboptimal, ist aber auch den begrenzten GPIOs geschuldet. 5 und 0 sind noch frei. Mit 5 kann den ESP32 nicht aufwecken, mit 0 muss man ein bisschen aufpassen, weil ggf. starte der ESP32 nicht mehr, wenn da beim Booten der falsche Logiklevel anliegt: 📗 Die GPIOs des ESP32: Welche eignen sich für was?.
1 „Gefällt mir“
einmal ein clean/build hat das Verhalten auf jeden Fall gebessert, ganz weg ist es immer noch nicht, aber so wie jetzt kann ich damit leben…
(Ich hab eh noch einen Schalter in die Akku Leitung gebaut um HW mäßig abzuschalten, AUS ist AUS!)
Ja, das kann ich sporadisch bestätigen, aber nur auf dem master. Auf dem DEV ist es mir noch nicht aufgefallen.
[ 2460179 ] RSSI: -81 dBm
[ 2460454 ] RFID-Karte erkannt: (ISO-15693) ID: 92-fd-f5-07
[ 2460463 ] RFID-Karte empfangen: 146253245007
[E][Preferences.cpp:472] getString(): nvs_get_str len fail: 146253245007 NOT_FOUND
[ 2460469 ] RFID-Karte ist im NVS nicht hinterlegt.
[ 2460533 ] RFID-Karte erkannt: (ISO-15693) ID: c9-fe-fa-03
[ 2460554 ] RFID-Karte empfangen: 201254250003
[ 2460655 ] Playlist-Generierung: cached
[ 2460730 ] Freier Speicher: 92396
[ 2460730 ] Gebe Speicher der alten Playlist frei.
[ 2460735 ] Freier Speicher nach Aufräumen: 92396
[ 2460736 ] Anzahl gültiger Files/Webstreams: 12
[ 2460737 ] Modus: Hoerspiel
Das werden wohl fehlerhafte Lesungen sein, denn ich habe keine Karte mit dieser ID?
Wie gesagt, auf dem DEV wohl nicht mehr vorhanden, von daher braucht es wohl keinen Bugreport.
der pn5180 zeigt bei mir keine Reaktion.
ich habe das forum mehrfach durchgeschaut und folgendes gefunden:
verkabelung:
mini4l platine → pn5180
5V → 3.3v
3.3V → 3.3v
RST → RST
CS → NSS
MOSI → MOSI
MISO → MISO
SCK → SCK
BSY → BUSY
IRQ → IRQ
GND → GND
GPIO, AUX & REQ auf pn5180 bleiben frei
JP1 (2+3), sowie JP4 sind gesetzt
settings.h
//#define RFID_READER_TYPE_MFRC522_SPI // use MFRC522 via SPI
//#define RFID_READER_TYPE_MFRC522_I2C // use MFRC522 via I2C
#define RFID_READER_TYPE_PN5180 // use PN5180 via SPI
sowie
#ifdef RFID_READER_TYPE_PN5180
#define PN5180_ENABLE_LPCD // Wakes up ESPuino if RFID-tag was applied while deepsleep is active. Only ISO-14443-tags are supported for wakeup!
#endif
settings-lolin-d32-pro-sdmmc-pe.h
// RFID (via SPI)
#define RST_PIN 99 // Used as dummy for RC522
#define RFID_CS 21 // GPIO for chip select (RFID)
#define RFID_MOSI 23 // GPIO for master out slave in (RFID)
#define RFID_MISO 19 // GPIO for master in slave out (RFID)
#define RFID_SCK 18 // GPIO for clock-signal (RFID)
#ifdef RFID_READER_TYPE_PN5180
#define RFID_BUSY 33 // PN5180 BUSY PIN
#define RFID_RST 22 // PN5180 RESET PIN
#define RFID_IRQ 32 // Depending on your configuration this needs to be adjusted to 32.
#endif
Firmwareupdate auf 4.1 vom pn5180 habe ich erfolgreich gemacht.
ich habe mehrfach auf kalte lötstellen überprüft.
Auch ohne LPCD einstellungen bekomme ich keine karten gelesen.
hat jemand einen hinweis, was ich falsch mache?
hatte anfänglich die 5v von der platine auf die 5v des pn5180 gelötet und hatte schwierigkeiten beim flashen, da die sd karte nich gemountet werden konnte. nach behebung funktioniert soweit alles bis auf das karten lesen, was durchaus elementar ist:)
@fts Verkabelung & Pins scheinen zu passen. Ich hatte eine schlechte Lötstelle an der Steckleiste und sporadische Aussetzer aber das kann hier wohl auch ausgeschlossen werden.
Kompilierst Du wirklich mit dem richtigen Profil?
Ob mit oder ohne LPCD solltest Du im Log die PN5180 Firmware-Version sehen:
D [145] PN5180 firmware version=4.1
Du könntest noch die Spannung am 3.3/5V Pin des Lesers messen ob die Power Einstellungen passen & der MosFET richtig einschaltet
die firmware version wird mir auch angezeigt und an den pins habe ich auch 3.27 v, daher gehe ich davon aus, dass der leser grundsätzlich erkannt wird. das enviroment ist auch korrekt.
ebenso habe ich es mit mehreren tags getestet, d.h den zwei mitgelieferten, sowie eigenen, die von der iso passen müssen
Ja OK dann kann der ESP-32 auch mit dem PN5180 kommunizieren.
Wenn dann kein Tag erkannt wird hat entweder Dein 5V Pin keine Spannung (Spannungsversorgung des HF-Teils) oder Du hast den HF-Teil des PN5180 geschrottet.
Edit: Letzte Möglichkeit wäre noch ein Stützkondensator z.B. 100-470uF um Spannungseinbrüche auszuschließen.