2020-08-05 06:45 AM
Hello everybody!
I use an X-NUCLEO-NFC05A1 (based on ST25R3911B) as a PCD.
My test application uses the RFAL V2.0.10 library.
After successfully selecting a MIFARE Classic 1K PICC, my test application call the rfalIsoDepPollAHandleActivation function that stuck in an infinite loop. (I know that this PICC is not ISO-DEP, so in this scenario it simply replies with a NAK response.) Interestingly if I change rfalSetErrorHandling's parameter from RFAL_ERRORHANDLING_EMVCO to RFAL_ERRORHANDLING_NFC in the beginning part ofrfalIsoDepPollAHandleActivation then the rfalIsoDepPollAHandleActivation function returns ERR_INCOMPLETE_BYTE (I think it is the correct, expected behavior).
The following things happen when I call the rfalIsoDepPollAHandleActivation function:
The 5-->6 state transition happens in the rfalErrorHandling function, because of the RFAL_ERRORHANDLING_EMVCO mode. I think that at the 6th step some sw timer should have started (with t-recovery running time) according to the "EMV Contactless Book D - EMV Contactless Communication Protocol Specification v2.6 - 4.9.2 chapter"
My question is: how to fix the infinite loop problem safely? Does this issue caused by an RFAL lib error (either becouse of wrong error handling mode usage in rfalIsoDepPollAHandleActivation or because of the mentioned timeout usage is missing). Or am I misunderstanding something?
Thanks for any response.
Laszlo
Solved! Go to Solution.
2020-08-05 08:07 AM
Hi Laszlo,
Thank you for your detailed analysis.
The issue occurs when the incomplete byte reception triggers the SW EMD suppression during ISO14443-4 activation.
In case the EMD supression takes place after the NRT has expired, then the re-enabling of the receiver is too late.
In this situation, the ST25R3911B will wait endlessly for a reception that will not happen which causes the behaviour reported.
This issue has been identified and fixed on the RFAL version just after the one you are currently using (v2.1.0).
The NRT status (nrt_on) is now verified ahead of the receiver re-enabling.
Our recommendation is to always make use of the latest RFAL version (STSW-ST25RFAL001) for new developments.
Hope it helps
GP
2020-08-05 08:07 AM
Hi Laszlo,
Thank you for your detailed analysis.
The issue occurs when the incomplete byte reception triggers the SW EMD suppression during ISO14443-4 activation.
In case the EMD supression takes place after the NRT has expired, then the re-enabling of the receiver is too late.
In this situation, the ST25R3911B will wait endlessly for a reception that will not happen which causes the behaviour reported.
This issue has been identified and fixed on the RFAL version just after the one you are currently using (v2.1.0).
The NRT status (nrt_on) is now verified ahead of the receiver re-enabling.
Our recommendation is to always make use of the latest RFAL version (STSW-ST25RFAL001) for new developments.
Hope it helps
GP
2020-08-06 08:04 AM
Hi Grégoire,
Thank you very much for your quick and useful response.
Best regards
Laszlo