Closed Karshilistic closed 4 years ago
Commenting out the blocking (and honestly almost pointless) while
loop in PCD_Reset()
is allowing the code to continue without crashing, and the device re-initializes correctly.
To check for reader responsiveness, I'm checking the modem status in Status2Reg
instead of the version.
The library tries to reset by..
If 1. fails it automatically fallbacks to 2.
So if you disconnect mfrc hardware code alwas runs into case 2.
The software reset MFRC522::PCD_Reset()
is not perfect. It has no timeout, so the program stuck. As you mentioned: removing this part will solve your problem. 👍
Step 1: Describe your environment
Step 2: Describe the problem
I am attempting to program a method to allow for the reinitialization of a disconnected and reconnected MFRC522. I am prompted to do this after finding that the reader sometimes stops working even if the rest of the program is working alright. It can be as simple as detecting if the reader has been disconnected and restarting to reinitialize, or if possible reinitialize the reader without a restart (favourable) I am using ESP-RFID as the base project. RFID relevant methods are in
rfid.esp
.1. I don't know if this is at all possible; is it either a limitation of SPI or MFRC522 (hardware or library) and can't be done?
In my attempts, I ran into the issue where calling
mfrc522.PCD_Init(rfidss, UINT8_MAX);
again after having called it once in the beginning of the program causes an Exception (9) reset (Load or store to an unaligned address)(see EDIT 1). UsingPCD_PerformSelfTest()
has the same effect. Onlymfrc522.PCD_ReadRegister(mfrc522.VersionReg)
can be called reliably to detect if the reader is present, but the reader can disconnect between two consecutive calls of this function and, even if the reader is unresponsive to card reads, the function would return the correct version.EDIT 1: this is actually misleading. Adding a
delay(150)
anywhere in the periodic check, which is what thePCD_Reset()
function takes approximately, causes the same reset, which leads me to believe it's just the ESP8266 being finicky.2. Any suggestions on how I can achieve this, given the trials and info provided? Should I add debugging outputs to the library methods to try and trace where exactly the program hangs? EDIT: already tried adding some debug serial prints and I've observed the following:
PCD_Init()
is called, everything is fine.PCD_Init()
. I am precisely crashing at the first loop ofPCD_Reset()
before `delay(50)' (see code below; I get to "delay in loop!")3. How do I check if the reader is responsive for the case where the reader disconnects and reconnects between checks and the reset is not caught by
mfrc522.PCD_ReadRegister(mfrc522.VersionReg)
?Relevant Code:
The following are the functions that handle the reconnection. Obviously, as stated above, they don't achieve .. anything desirable. Purely a work in progress to give you a sense. They don't catch the biggest issue: the reader disconnecting and reconnecting between checks.