RC522 en PN532 RFID-basis: 10 stappen

2024 Auteur: John Day | [email protected]. Laatst gewijzigd: 2024-01-30 11:17

OPMERKING: ik heb nu Instructables die Arduino-code bieden voor de RC522 en PN532.

Enige tijd geleden kocht ik drie verschillende RFID-modules om te experimenteren. In een eerder project heb ik beschreven hoe je een eenvoudige 125 kHz-module kunt gebruiken om een basisbeveiligingsfunctie uit te voeren. Dergelijke modules gebruiken alleen-lezen-tags, dus het proces wordt gescand op de ID, indien gewenst opgeslagen en vergeleken met opgeslagen ID's. De andere modules die ik heb gekocht, werken op 13,56 MHz en gebruiken tags die zowel kunnen worden gelezen als geschreven, dus het is een beetje zonde om ze gewoon te gebruiken voor basisbeveiliging. De twee gemeenschappelijke modules gebruiken de RC522-chip of de PN532-chip - beide gemaakt door NXP.

Als je een van mijn andere projecten hebt gelezen, weet je dat ik graag goedkope PIC-microcontrollers gebruik en programmeer in assembler. Dus waar ik naar op zoek was, was een reeks stappen die nodig waren om met de modules en de RFID-tags te praten. Hoewel er veel voorbeeldprogramma's online zijn voor de modules, zijn de meeste geschreven in 'C'-software voor de Arduino en gebruiken ze de SPI-interface. Ook de handleidingen voor de chips en voor de Mifare-tags zijn even ontcijferen. Dit bericht gaat voornamelijk over de informatie die ik wou dat ik had toen ik aan het project begon. Ik voeg ook PIC-assemblagesoftwareprogramma's toe voor het uitvoeren van de basisopdrachten die door elke module worden vereist. Zelfs als je geen PIC en/of assembler gebruikt, moet de broncode je op zijn minst een goed idee geven van de specifieke commando's die nodig zijn om elke stap uit te voeren.

Stap 1: Seriële interfaces

Beide chips die op deze modules worden gebruikt, kunnen worden gekoppeld via SPI, I2C of UART (HSSP). De PN532-module heeft een DIP-schakelaar die wordt gebruikt om de gewenste interface te selecteren, maar de MFRC522-module is bedraad voor de SPI-interface. Ik gebruik liever de ingebouwde UART van de PIC, dus ik ging online op jacht om te zien of er een manier was om de MFRC522-module in de UART-modus te krijgen. Wat ik ontdekte, was dat het knippen van één spoor op het bord de slag zou slaan. De snede verwijdert effectief 3,3 volt van de EA-pin van de chip. Technisch gezien zou de EA-pin dan met aarde moeten worden verbonden, maar niet veel mensen kunnen die soldeerprestatie leveren gezien de dichtheid van de chippen. Maar maak je geen zorgen, want de EA-pin heeft geen interne pull-up en "zweeft" niet zoals de oude TTL-logische ingangen. Raadpleeg het chipdiagram en de afbeelding van het bordgedeelte voor de te snijden plek. Zorg ervoor dat u alleen het korte spoor knipt dat rechtstreeks naar de EA-pin gaat.

Stap 2: Hardware

De hardware-aansluitingen voor UART-communicatie worden weergegeven in het bovenstaande diagram. De UART-aansluitingen voor de MFRC522 zijn niet gemarkeerd op het bord, maar, zoals weergegeven in het schema, ontvangt de SDA-pin UART-gegevens en verzendt de MISO-pin UART-gegevens. De PN532-module heeft de UART-markeringen aan de onderkant van het bord.

Beide modules werken op 3,3 volt en het logische niveau van 5 volt van de PIC TX-pin moet ook worden beperkt. De LCD-verbinding is de standaard 4-bits opstelling die in een aantal van mijn eerdere projecten is gebruikt. Het standaardformaat voor alle berichten is ingesteld voor het standaard 1602 LCD-scherm (16 tekens bij 2 regels). Ik heb ook een LCD-scherm van 40 tekens bij 2 regels dat ik gebruik voor onbewerkte gegevensdumps tijdens het debuggen, dus ik heb een definitie in de software opgenomen waarmee ik kan profiteren van de extra weergaveruimte.

Stap 3: Gegevensblokken

De Mifare Classic 1k-tags die voor dit project worden gebruikt, zijn geconfigureerd als 16 sectoren, vier datablokken per sector, 16 bytes per datablok. Van de 64 datablokken zijn er slechts 47 daadwerkelijk bruikbaar. Datablok 0 bevat fabrikantgegevens en blokken 3, 7, 11, 15, 19, 23, 27, 31, 35, 39, 43, 47, 51, 55, 59 en 63 worden Trailer-blokken genoemd. De Trailer-blokken zijn de laatste in elke sector en bevatten twee sleutels en de bloktoegangsbits. De sleutels en bloktoegangsbits zijn alleen van toepassing op de gegevensblokken in die sector, zodat u voor elke sector verschillende sleutels en toegangsregels kunt hebben. De standaardtoetsen zijn ingesteld op "FF FF FF FF FFh". Voor dit basisproject gebruik ik slechts één gegevensblok en behoud ik de standaardsleutels en toegangsbits. Er zijn veel documenten met betrekking tot deze kaarten, dus zoek gewoon online naar "Mifare" of bezoek de NXP-website als u ze dieper wilt verkennen.

Stap 4: Algemene bediening

Hoewel beide modules uniek zijn in de manier waarop ze worden geopend en de manier waarop ze toegang krijgen tot de tags, is er een algemeen proces dat nodig is om de klus te klaren. Voor dit project gaan we ervan uit dat de tags van het Mifare Classic 1k-type zijn en dat we in het antenneveld slechts één tag tegelijk toestaan. De basisstappen worden hieronder gedefinieerd.

· Initialiseer de module: In het algemeen vereist dit zaken als het schrijven van waarden naar registers in de chip, het verzenden van "wake-up"-commando's en het inschakelen van de antenne. In een op batterijen werkende toepassing zou u de antenne aan en uit willen kunnen zetten om de batterij te sparen, maar voor deze eenvoudige toepassing zetten we hem één keer aan en laten hem dan aan.

· Wis de crypto-vlag (alleen 522): wanneer een tag is geverifieerd, wordt een vlag ingesteld om de gebruiker te laten weten dat communicatie met de tag zal worden gecodeerd. Deze vlag moet vóór de volgende scan door de gebruiker worden gewist, zelfs als de gescande tag dezelfde is.

· Scannen naar een tag: de module vraagt in feite "Is er iemand daarbuiten?" en de tag antwoordt "Ik ben hier". Als de module geen snelle reactie krijgt, stopt hij met luisteren. Dat betekent dat we herhaaldelijk scanopdrachten naar de module moeten sturen totdat deze een tag vindt.

· Haal het gebruikersidentificatienummer (UID) van de tag op: de tag reageert op het scanverzoek met beperkte informatie, zoals het type tag. Dat betekent dat we mogelijk een ander commando moeten sturen om de UID te krijgen. De UID is vier bytes voor de Mifare Classic 1k-tags. Het kan langer zijn voor andere tags, maar dit project behandelt ze niet.

· Selecteer de tag (alleen 522): De UID wordt gebruikt om de tag te selecteren die de gebruiker wil authenticeren voor lezen en schrijven. Dit is gebaseerd op de mogelijkheid dat er zich meer dan één tag in het antenneveld bevindt. Dat is niet het geval voor onze eenvoudige toepassing, maar we moeten de tag toch selecteren.

· Authenticeer de tag: deze stap is vereist als we de tag willen lezen of schrijven. Als we alleen maar onderscheid willen maken tussen tags voor een eenvoudige beveiligingstoepassing, dan is de UID voldoende. Authenticatie vereist dat we de UID kennen en dat we de crypto-sleutel kennen voor de datasector van de tag waartoe we toegang willen. Voor dit project houden we het bij de standaardsleutels, maar mijn vervolgproject verandert de sleutels zodat de tag als elektronische portemonnee kan worden gebruikt.

· Lees of schrijf de tag: Lezen retourneren altijd alle 16 bytes van het gevraagde gegevensblok. Schrijfbewerkingen vereisen dat alle 16 bytes tegelijkertijd worden geschreven. Als u een ander blok in dezelfde datasector wilt lezen of schrijven, hoeft de tag niet opnieuw te worden geverifieerd. Als u een blok in een andere datasector wilt lezen of schrijven, moet de tag opnieuw worden geauthenticeerd met behulp van de sleutel voor die sector.

Stap 5: MFRC522 Module Toegangsvolgorde

De opstartroutine omvat deze basisstappen die in de meeste toepassingen die ik heb bekeken, te vinden zijn:

· Stuur dummy databyte (zie de volgende paragraaf)

· Zachte reset

· Stel RF-ontvangerversterking in (als iets anders dan de standaard is gewenst)

· Stel het ASK-modulatiepercentage in op 100%

· Startwaarde instellen voor CRC-berekeningen

· Zet de antenne aan

· Firmwareversie ophalen (niet vereist)

Om de een of andere onverklaarbare reden start mijn module op en denkt dat hij een schrijfopdracht heeft ontvangen zonder de databyte. Ik weet niet of dit alleen een probleem is met mijn module, maar ik heb er nergens anders naar verwezen. Ik heb geëxperimenteerd met zowel hardware- als software-resets en geen van beide loste het probleem op. Mijn oplossing was om een dummy read-aanroep toe te voegen om "0" (undefined) te registreren aan het begin van de module-initialisatieroutine. Als de module dit ziet als gegevens voor het onbekende schrijfcommando, lijken er geen nadelige gevolgen te zijn. Als het het als een leesopdracht ziet, gebeurt er niets nuttigs. Het stoort me dat ik het probleem niet volledig kan definiëren, vooral omdat een hardware-reset van alleen de module het probleem niet oplost.

De RC522-chip is samengesteld uit een aantal registers, waarvan de meeste zowel lezen als schrijven zijn. Om een schrijfbewerking uit te voeren, wordt het registernummer naar de module gestuurd, gevolgd door de te schrijven waarde. Om een uitlezing uit te voeren, wordt aan het registernummer 0x80 toegevoegd en dat wordt naar de module gestuurd. Het antwoord op een schrijfopdracht is een echo van het geopende register. Het antwoord op een leescommando is de inhoud van het register. De software maakt gebruik van die kennis om te controleren of de opdracht correct is uitgevoerd.

Stap 6: PN532 Module Toegangsvolgorde

De opstartroutine omvat de volgende vereiste stappen:

· Stuur een initialisatiereeks: Dit is specifiek voor de UART-interface. In de handleiding staat dat de UART-interface zal ontwaken op de vijfde stijgende flank die op de interface wordt gedetecteerd. Het raadt aan om 0x55, 0x55, 0x00, 0x00, 0x00, 0x00 te verzenden. Voor het grootste deel moeten er gewoon een voldoende aantal tekens met oplopende randen zijn en ze mogen er niet uitzien als een opdrachtaanhef (00 00 FF).

· Activeer de module: Begraven in de gebruikershandleiding blijkt dat de module initialiseert in een soort slaapstand genaamd “LowVbat”. Om deze status te verlaten, moeten we een opdracht "SAMConfiguration" verzenden.

De PN532 verwacht dat opdrachten worden verzonden in een gedefinieerd berichtformaat dat een preambule, het bericht en een postambule bevat. De antwoordberichten volgen hetzelfde formaat. De commando- en responsberichten bevatten beide een TFI (Frame Identifier) en een commandoversie. De opdracht gebruikt een TFI van 0xD4 en het antwoord gebruikt 0xD5. De commandoversies variëren, maar het antwoord zal altijd de commandoversie verhogen en teruggeven in de byte volgend op de TFI. Die consistentie zorgt ervoor dat de responsberichten gemakkelijk kunnen worden gescand op de relevante informatie.

Elk commandobericht (volgens de preambule) bestaat uit de berichtlengte, het 2-complement van de berichtlengte, TFI, commando, data, checksum en postamble. De software bouwt de individuele commando's en roept vervolgens een routine aan die de checksum berekent en de postamble toevoegt.

Het berichtformaat voor het antwoord is vergelijkbaar met dat van de opdracht. Een typisch antwoord omvat een ACK (00 00 FF 00 FF 00) gevolgd door het specifieke antwoord op de opdracht. Elk commando-antwoord begint met een preambule van 00 00 FF. Het antwoord moet ook een TFI-byte van D5 hebben, gevolgd door het opdrachtnummer verhoogd met 1. Voor ons "SAMConfiguration" -commando (14) zou dat 15 zijn. Het "SAMConfiguration" -commando krijgt dit antwoord: 00 00 FF 00 FF 00 00 00 FF 02 FE D5 15 16 00.

Er zijn andere modulespecifieke opdrachten die kunnen worden verzonden, maar deze zijn niet nodig voor deze toepassing. Ik heb echter een routine toegevoegd die kan worden aangeroepen om het versienummer van de firmware op te halen. Een typisch antwoord (na de ACK en preambule) zou zijn: 06 FA D5 03 32 01 06 07 E8 00. De "01 06 07" geeft firmwareversienummer 1.6.7 aan.

Stap 7: Toegangsvolgorde voor tags

Nadat de module gereed is, kunnen we opdrachten verzenden die specifiek zijn voor de tags. Om taggegevens te lezen of te schrijven, hebben we het identificatienummer (UID) nodig. De UID en sleutel worden dan gebruikt om een specifieke tag datasector te autoriseren voor lezen/schrijven. Het lezen/schrijven van taggegevens wordt altijd gedaan op alle 16 bytes in een bepaald gegevensblok. Dat betekent dat de typische toepassing het gegevensblok zal lezen, de gegevens naar wens zal wijzigen en vervolgens de nieuwe gegevens terug zal schrijven naar de tag.

Stap 8: Software

De interrupt handler-software wordt aangeroepen wanneer de PIC UART een byte aan gegevens ontvangt. In sommige van mijn eerdere UART-projecten kon ik gewoon de RX-interruptvlag pollen in plaats van een interrupt-handler te gebruiken. Dat is niet het geval voor deze software, zeker niet voor de PN532 die met een veel hogere baudrate communiceert dan de RC522. De UART-interface van de RC522 is beperkt tot 9600 baud, terwijl de standaard voor de PN532 115k is en kan worden ingesteld tot 1,288M baud. De ontvangen bytes worden opgeslagen in een buffergebied en het grootste deel van de software haalt ze op als dat nodig is.

De vlag New_Msg geeft aan dat er bytes zijn ontvangen en Byte_Count geeft aan hoeveel bytes. Ik heb een "Disp_Buff" -routine in de software opgenomen die kan worden aangeroepen om de inhoud van de ontvangstbuffer weer te geven tijdens het debuggen. Sommige van de retourberichten zullen een typisch 1602-scherm overlopen, maar ik heb een LCD-scherm van 40 tekens bij 2 regels dat ik vond op een online elektronica-site. De "Max_Line"-definitie kan worden ingesteld voor uw LCD-formaat. Als "Max_Line" is bereikt, gaat de routine "Disp_Buff" verder met het schrijven naar de tweede regel. Je zou een kleine code aan die routine kunnen toevoegen om door te gaan naar regel drie en vier als je een 4-regelig LCD-scherm hebt. Voor de PN532 is er een vlag die zo kan worden ingesteld dat de routine ofwel alle ontvangen bytes dumpt of alleen de 16 databytes van een leesreactie dumpt.

Het is niet nodig om de ontvangstbuffer of Byte_Count te wissen, omdat het wissen van de New_Msg-vlag ervoor zorgt dat Byte_Count wordt gewist door de interrupt-handler en dat is wat wordt gebruikt als de index in de buffer. New_Msg wordt meestal vóór elke opdrachtstap gewist, zodat de resultaten die specifiek zijn voor die opdracht gemakkelijk kunnen worden gevonden en geverifieerd. In de RC522 betekent dat dat de ontvangstbuffer meestal maar 1 tot 4 bytes heeft. In sommige gevallen, zoals het lezen van datablokken, moet het Read_FIFO-commando meerdere keren worden gegeven om de bytes van de FIFO naar de ontvangstbuffer te verplaatsen. Alle opdrachtresultaten voor de PN532 komen terecht in de ontvangstbuffer, dus er wordt een scanprocedure uitgevoerd om de specifieke benodigde bytes te lokaliseren.

De hoofdlus in de software scant naar een tag en verifieert vervolgens de tag voor lezen/schrijven. Voor de hier opgenomen testsoftware wordt de variabele Junk_Num elke keer door de hoofdlus gewijzigd en gebruikt tijdens het schrijven naar de tag. De geschreven waarden wisselen af tussen de waarde van Junk_Num en het 1-complement van Junk_Num. Ten slotte worden de 16 geschreven waarden gelezen en weergegeven. Er zijn displayberichten voor elke stap met uitgestelde routine-oproepen om tijd te geven om elk bericht te lezen. Er worden ook foutmeldingen gegeven, maar deze zouden normaal gesproken alleen moeten optreden als de tag tijdens een bewerking wordt verwijderd.

Een deel van de software-initialisatie is een codegedeelte dat alleen wordt uitgevoerd bij het opstarten en wordt overgeslagen als een softwarereset wordt gedetecteerd. De foutmeldingen eindigen over het algemeen met een software-reset als een manier om de hoofdlus te verlaten. De reset vindt plaats in de "Tilt"-routine die eenvoudig de Watchdog-timer inschakelt en vervolgens in een oneindige lus gaat, wachtend op de time-out.

Stap 9: MFRC522 Unieke software

De RC522-chip vereist meer instructies op laag niveau dan de PN532-chip om communicatie met tags tot stand te brengen. Het is een beetje zoals programmeren in assembler versus programmeren in "C". Een ander belangrijk verschil is dat de RC522 vereist dat communicatie met de tag via een FIFO-buffer wordt geleid. De routines "Write_FIFO" en "Read_FIFO" handelen deze taken af. De MFRC522-software bevat een sectie voor veel van de lagere commando's waaruit de hoofdfuncties zijn opgebouwd.

De controlesomberekening van de tagopdracht voor de RC522 is heel anders dan voor de PN532. Nadat de tag-opdracht in de FIFO is ingebouwd, wordt een moduleopdracht verzonden om de controlesom te berekenen. Het 16-bits resultaat wordt niet automatisch toegevoegd aan het tag-commando, maar kan worden gelezen uit twee 8-bits registers. De controlesomberekening wist de gegevens in de FIFO, zodat de vereiste volgorde als volgt is:

· Bouw de opdracht in de FIFO

· Voer een controlesomberekening uit

· Bouw de opdracht opnieuw in de FIFO

· Lees de CRC-registers en schrijf de checksum-bytes naar de FIFO

· Stuur ofwel een Transceive of Authenticate commando

Het Transceive-commando verzendt de FIFO-buffer en schakelt vervolgens automatisch over naar de ontvangstmodus om te wachten op het antwoord van de tag. Het Transceive-commando moet worden gevolgd door de instelling van het StartSend-bit in het BitFramingRegister om de gegevens daadwerkelijk te verzenden. De opdracht Authenticate heeft die vereiste niet.

Over het algemeen gebruiken de Arduino "C"-codetoepassingen die online beschikbaar zijn de interruptvlagregisters en het time-outregister om ervoor te zorgen dat het juiste antwoord tijdig wordt ontvangen. Naar mijn mening is dat overkill voor deze niet-tijdkritische toepassing. In plaats daarvan gebruik ik korte softwaretime-outs om op het antwoord te wachten en vervolgens te controleren of het correct is. De handleiding voor de Mifare-tags geeft de timing van de verschillende transacties weer en ook de tijd waarop het verwachte aantal bytes wordt ontvangen. Deze tijdvertragingen zijn ingebouwd in de meeste van de subroutines op laag niveau.

Stap 10: PN532 Unieke software

Nadat de module is geïnitialiseerd, worden de stappen die nodig zijn om de tag te vinden en te verifiëren, uitgevoerd door het juiste commando te schrijven, gevolgd door de benodigde gegevens. De scanopdracht retourneert de UID die vervolgens wordt gebruikt voor de authenticatie. Daarna worden bij het lezen en schrijven van de tag de 16 bytes voor het geadresseerde datablok verzonden of geretourneerd.

De initialisatievolgorde is eerder beschreven en dezelfde softwareroutine verzendt ook het SAMConfiguration-commando om de module uit de "LowVbat" -status te krijgen. De rest van de basiscommando's, zoals Scannen, Authenticeren, Tag lezen/schrijven, worden gewoon opeenvolgend gebouwd in de toepasselijke routines. De controlesom wordt berekend door gewoon de opdrachtbytes bij elkaar op te tellen, een complement te doen en vervolgens 1 op te tellen om er een 2's complement van te maken. Het 8-bits resultaat wordt net voor de postamble aan de opdrachtreeks toegevoegd.

Er is geen FIFO zoals in de RC522 dus de volledige responsberichten worden automatisch ontvangen. De routine "Find_Response" scant de buffer voor ontvangstgegevens voor de TFI (0xD5). De routine maakt gebruik van het weten wat de verwachte berichten zouden moeten zijn en negeert eenvoudige ACK-antwoorden die geen gegevens bevatten. Zodra de TFI is gevonden, zijn de gewenste antwoorden een bekende afwijking ervan. De commando-echo en commandostatusbytes worden opgeslagen door de "Read_Buff"-routine voor latere verificatie.

Dat was het voor dit bericht. Bekijk mijn andere elektronicaprojecten op: www.boomerrules.wordpress.com