Lolin32 mit SD (SD_MMC) und PN5180 als RFID-Leser

Hallo @biologist
Du schreibst in der Readme PN5180 muss mit 3,3V und 5V versorgt werden . Ich habe mir gestern mal die Schaltung angesehen . Das Board sollte auch mit 3,3V gehen . Die 5V sind auf einen internen Spannungsregler geschaltet , welcher daraus dann 3,3V macht . Die meisten 3,3V Verbindungen sind nicht beschaltet ( siehe Foto eines PN5180 , die Brücken fehlen ), bis auf die zu VBAT und PVDD. Dort ist ein interner LDO der dann 1,8V macht . Laut Datenblatt von NXP arbeitet der Chip mit 3,3V . Hast du , oder jemand anderes , das mal ausprobiert ? Also entweder 3,3V oder 5 V nicht beides gleichzeitig beschalten. Wenn es nicht geht evtl. die Brücken R14 aus und R15 einlöten .

VG

Dann muss ich die Beschreibung wohl verständlicher anpassen. Also es war tatsächlich so gemeint, dass man die 3.3V an 5V UND 3.3V hängen muss. So macht es mein PCB auch.
Mich hat es auch irritiert muss ich zugeben. @tueddy hat das Ganze ja ins Laufen gebracht und mich mit dem PN5180 „bemustert“. Irgendwie lief es nicht und dann meinte er zu mir, dass man beide Pins mit 3.3V beschalten müsse.

Ja, das ist schon komisch . Es gibt ein Evaluation board von NXP , auch da ist der Jumper per default auf 3,3V , nix gleichzeitig . Der Ausgang des 3,3V LDO_OUT ist ja auch garnicht beschaltet , R10 fehlt . Für mich funktioniert das Board alleine mit 5V nicht , erst wenn man R10 beschaltet . Ich habe auch schon länger gegoogelt , finde aber nichts .

Evt. hilft der Schaltplan (R14/R15?):

Bei mir läuft der Leser komplett mit 3,3V. Der 5V Anschluss muss aber in jedem Fall auch mit Strom versorgt werden, Also Anschlüsse 3,3V & 5V beide an 3,3V

Schaltplan und Dokumentation zum PN5180 hier…

Also so wie ich schon geschrieben habe , Brücke R14 aus und R15 einlöten .

Ich habe in den letzten Tagen diese Platine bestückt und in Betrieb genommen. Leider gab es erst mal keine Tonausgabe, obwohl in der Debug-Ausgabe das Abspielen einer Sound-Datei angezeigt wurde. Ich habe keine Kopfhörer-Platine, die entsprechenden Kontakte auf dem PCB sind daher einfach offen.

Das Problem war letztendlich, dass am MAX98357 am Pin SD eine zu geringe Spannung anlag. Mein MAX98357 ist nicht von Adafruit [1], sondern von AliExpress. Gemessen habe ich an dem Pin eine Spannung von ca. 0,05 V, was laut [2] eben ein Shutdown des Amps bewirkt (" If SD is connected to ground directly (voltage is under 0.16V) then the amp is shut down"). Die Spannung sollte ja eigentlich höher sein, da auch auf diesem Breakout-Board ein 1 MOhm Widerstand nach VCC geht, und intern im Chip ein 100 kOhm Widerstand nach GND geht (SD_MODE Pulldown Resistor).

Ich habe dann mit verschiedenen Widerständen auf dem PCB-Board zwischen HP_Detect (ist mit SD des Amps verbunden) und 3,3 V am Ausgang für die Kopfhörer-Platine experimentiert, und ein 100 kOhm Widerstand hat die Spannung an SD auf 0,48 V gebracht (für den „(Left + Right)/2“ Modus). Damit kam dann endlich zuverlässig der Sound am Lautsprecher an. (Größere Widerstände, die nach der Berechnungsformel im Datenblatt eigentlich passender wären, haben nicht zuverlässig funktioniert).

@biologist : Evtl. sollte man den Hinweis oben („Info: liegt hier GND an so schaltet MAX auf lautlos“) und auf Github noch ergänzen, dass hier ein zusätzlicher Pull-Up-Widerstand erforderlich sein könnte, zumindest wenn es Probleme mit dem Sound gibt. Die Spannung muss > 0,355 V sein, sonst geht der Amps auf Shutdown.

Insgesamt ist dieser SD Pin ja schon recht merkwürdig. Vier Funktionen auf einen Anschluss zu legen - zu aktivieren mit festen Spannungsbereichen - führt sicherlich öfters mal zu Problemen.

[1] Overview | Adafruit MAX98357 I2S Class-D Mono Amp | Adafruit Learning System
[2] Pinouts | Adafruit MAX98357 I2S Class-D Mono Amp | Adafruit Learning System

1 „Gefällt mir“

Ich hatte das gleiche Problem, allerdings war es ausreichend einfach HEADPHONE_ADJUST_ENABLE zu aktivieren, damit HP_DETECT auf Input geschaltet wird, auch wenn man die Kopfhörer-Platine nicht verwendet.

1 „Gefällt mir“

Ui, das ist mir noch gar nicht aufgefallen.
Das nehme ich auf jeden Fall an verschiedenen Stellen auf.

Danke für den Hinweis.

Aha - danke für den Hinweis. Dann zieht der nicht initialisierte Port bei mir die Spannung so weit runter? (Ich hatte die Spannung tatsächlich nur auf dem PCB komplett aufgesteckt gemessen.)

Laut dem ESP32 Pin List Dokument ist GPIO13 nach dem Reset auf Input und Pulldown. Das erklärt auch das Verhalten. Mit dem HEADPHONE_ADJUST_ENABLE wird dann der Pulldown deaktiviert.

Wofür sind eigentlich diese 3 JP1 Löcher oben hinter dem ESP32? Ich finde JP1 sonst nur auf dem Schaltplan vom
pn5180. Muss da noch irgendwas rein?

Zitat von oben. Also den Jumper musst du auf jeden Fall setzen.
EDIT: Im einen Fall wird dauerhaft der PN5180 mit Spannung versorgt „3.3 V“ und im anderen Fall wird er durch die Mosfets abgeschaltet, wenn der ESP im Deepsleep ist „M_SW3.3“.

Ah super danke! Das hatte ich schon gesucht. Hast du mal gemessen was der PN5180 an Strom im standby zieht?

The PN5180 supports an external silicon system-power-on switch by using the energy
of the RF field generated by an NFC phone to switch on the system, like it is generated
during the NFC polling loop. This unique and new Zero-Power-Wake-up feature allows
designing systems with a power consumption close to zero during standby.
vom datasheet https://www.nxp.com/docs/en/data-sheet/PN5180A0XX-C1-C2.pdf

Finde leider kaum Informationen darüber.

Hänge leider beim Update fest. Habe die REQ mit dem next button verbunden und kann auch auslesen das ich die Firmware 3.5 am laufen habe.

#define PN5180_RST_PIN      22
#define PN5180_BUSY_PIN     16
#define PN5180_REQ_PIN      4
#define PN5180_NSS_PIN      21
#define STM32_MOSI_PIN      23
#define STM32_MISO_PIN      19
#define STM32_SCK_PIN       18

Habe es geschafft dieses NFC Cockpit zu installieren. Dafür musste man sich bei NXP anmelden und es ist erschreckend was die alles wissen wollen. Meine Unsinnsdaten hat das Ding aber geschluckt. Die Firmware findet sich dann unter nxp\NxpNfcCockpit_v5.9.0.0\firmware\PN5180_SFWU im Installationsverzeichnis.

Wo kommt dann das ganze Hex zeug hin? Die Anleitung sagt ich soll das in einem header speichern.

Edit: Okay ich bin blind. Das wird in #define PN5180_FIRMWARE in firmware.h deklariert. Man muss also doch nicht das ganze geraffel mit NXP machen.

Allerdings bekomme ich folgende Fehlermeldung beim compilen:

Arduino: 1.8.13 (Windows 10), Board: "WEMOS LOLIN32, 80MHz, Default, 240MHz (WiFi/BT), 921600"

FirmwareUpdate:24:1: error: 'PN5180_Firmware' does not name a type

 PN5180_Firmware Pn5180(PN5180_RST_PIN, PN5180_BUSY_PIN, PN5180_REQ_PIN, PN5180_NSS_PIN, STM32_MOSI_PIN, STM32_MISO_PIN, STM32_SCK_PIN);

 ^

C:\Users\Braindance\Documents\PN5180_Updater_ESP32-master\FirmwareUpdate\FirmwareUpdate.ino: In function 'void setup()':

FirmwareUpdate:30:3: error: 'Pn5180' was not declared in this scope

   Pn5180.Begin();

   ^

C:\Users\Braindance\Documents\PN5180_Updater_ESP32-master\FirmwareUpdate\FirmwareUpdate.ino: In function 'void loop()':

FirmwareUpdate:47:3: error: 'Pn5180' was not declared in this scope

   Pn5180.End();

   ^

exit status 1

'PN5180_Firmware' does not name a type

Ignorier die Anleitung. In den Github wurde das schon gemacht und die Firmware liegt schon im passenden Format vor. Du musst es nur aufspielen und die Boards passend angebunden haben.

@Jonas
Danke, das hatte ich zeitgleich aus herausgefunden, es spuckt jedoch noch Fehlermeldungen beim compilen.

Hast du die Dateien aus dem src-Ordner zur ino kopiert?

@Jonas Ja und auch eingebunden.

Ok, da fehlt ein
#include „PN5180_Firmware.h“
am besten nach dem
#include „Firmware.h“
Ist etwas Schade das der Code in dem Github leicht defekt ist.

In diesem Github wurde es behoben: GitHub - simsasaile/PN5180_Updater_ESP32 at patch-1

1 „Gefällt mir“

aaaah jetzt macht es sinn. Danke !!!
Gute Nacht!

Genau, das ist von mir, hatte das Problem auch, deshalb hab ich den Patch dort als merge request eingereicht. Scheint leider noch nicht im master angekommen zu sein.