cancel
Showing results for 
Search instead for 
Did you mean: 

RFAL function stuck in infinite loop (rfalIsoDepPollAHandleActivation)

B.Laszlo
Associate

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:

  • rfalIsoDepPollAHandleActivation calls rfalIsoDepRATS function
  • rfalIsoDepRATS sends a RATS command by calling the rfalTransceiveBlockingTxRx function
  • rfalTransceiveBlockingTxRx sends the RATS command successfully and then calls the rfalTransceiveBlockingRx function
  • rfalTransceiveBlockingRx calls rfalWorker function from a while loop and that loop never exits
  • rfalWorker always calls rfalTransceiveRx, in which a state machine is implemented
  • working progress (state changes and occured PCD interrupts) in the state machine:
  1. RFAL_TXRX_STATE_RX_IDLE
  2. RFAL_TXRX_STATE_RX_WAIT_RXS
  3. irqs: ST25R3911_IRQ_MASK_NRE | ST25R3911_IRQ_MASK_RXS | ST25R3911_IRQ_MASK_RXE
  4. RFAL_TXRX_STATE_RX_ERR_CHECK
  5. irqs: ST25R3911_IRQ_MASK_CRC
  6. RFAL_TXRX_STATE_RX_WAIT_RXS
  7. ... no IRQ happens anymore and there is not any running sw timer => infinite loop

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

1 ACCEPTED SOLUTION

Accepted Solutions
Grégoire Poulain
ST Employee

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

View solution in original post

2 REPLIES 2
Grégoire Poulain
ST Employee

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

B.Laszlo
Associate

Hi Grégoire,

Thank you very much for your quick and useful response.

Best regards

Laszlo