RC522 - what qualifies as a card read?

Projects General Guidance
1

Am trying to troubleshoot some lockups on an RC522 on an ESP8266, and have already done some remedial work (Convert String to char[] arrays).

I still get some lockups and wanted to confirm something. The instructions say that the PICC_HaltA should be run after reading the card, does the “mfrc522.PICC_GetType” command count as a ‘reading’? Also, I have a delay before the PICC_HaltA, to prevent re-reading of the swipe and give the user time to remove the fob. Should I place this affer the PICC_HaltA or remove it entirely and let the swipe sensor modules detect a change?

(I don’t want to post the entire project, it’s 1100+ lines, I am after clarification on best practice at the moment).

Thanks, Ian

void RfidScan(){
    // Reset the loop if no new card present on the sensor/reader. This saves the entire process when idle.
  if ( ! mfrc522.PICC_IsNewCardPresent()) {
    return;
  }

  // Select one of the cards
  if ( ! mfrc522.PICC_ReadCardSerial()) {
    // Serial.println("Card detected");
    return;
  }

  Serial.print(F("\nPICC type: "));
  MFRC522::PICC_Type piccType = mfrc522.PICC_GetType(mfrc522.uid.sak);
  Serial.println(mfrc522.PICC_GetTypeName(piccType));

  // Check is the PICC of Classic MIFARE type
  if (piccType != MFRC522::PICC_TYPE_MIFARE_MINI &&  
    piccType != MFRC522::PICC_TYPE_MIFARE_1K &&
    piccType != MFRC522::PICC_TYPE_MIFARE_4K) {
    Serial.println(F("Your q                                                                                         / is not of type MIFARE Classic."));
    return;
  }
  .....
// Wait so card can be removed- 1 second
  delay (1000);
  
  // Halt PICC
  mfrc522.PICC_HaltA();

  // Stop encryption on PCD
  mfrc522.PCD_StopCrypto1();
}
2

I am afraid I will be no help, but others might be able if you told what a “lockup” is and how you determined it happened.

3

OK, ‘lockup’ is a bad phrase, perhaps “blank” where fobs are repeatedly swiped but not detected.

4

For context : a PICC stands for "Proximity Integrated Circuit Card." It refers to the RFID tag or card that communicates with the reader. The PICC contains a small integrated circuit and an antenna that can receive power and data from the reader's electromagnetic field, allowing it to exchange information wirelessly over a short range.

The PICC_HaltA is a command sent from the reader to a selected RFID tag (ie the PICC) to put it into a halted state. When a PICC receives the Halt command, it stops responding to most subsequent commands until it is reactivated by the reader again. This is used to prevent a tag from continuously communicating when multiple tags are present, allowing the reader to manage several cards in the field without collisions.

So in a nutshell, you need to call PICC_HaltA after you have finished interacting with a specific RFID tag and no longer need it to respond.

Now to your question: the advantage of open source is that you can read the source code and you can see in

that the function itself does not interact at all with the equipment, it just translates the sak you pass into a keyword and won't change the active status of your PICC ➜ so that function has nothing to do with activating a PICC. It's just ancillary.

That being said, and as documented in the code, the mfrc522.uid.sak parameter you pass comes from the PICC_Select() call you have done indirectly before through PICC_ReadCardSerial()

which requires you to call PICC_IsNewCardPresent(), PICC_RequestA() or PICC_WakeupA() beforehand.

Those three calls do make the PICC you detected in an ACTIVE state and so PICC_HaltA() should indeed be called — not because you used PICC_GetType() but because if you are there, you did activate the PICC.

makes sense ?

PS/ as a side note, I found that SPI communication errors are a very common cause for misbehavior. The MFRC522 is sensitive to signal integrity and timing. Incorrect SPI clock speed, unstable wiring, or improper chip select handling can cause the reader’s FIFO or command register to stall, which manifests as the library blocking while waiting for IRQ flags.

The other frequent issue comes from power supply instability and source of freezes. The MFRC522 requires a very stable 3.3 V supply with sufficient decoupling. Brownouts or noise on VCC can leave the chip in an undefined state.

The ESP8266 is mono core and if you drive heavy WiFi stuff at the same time, that might challenge the timings or available power depending on how you power your circuit and MRFC.