RFAL: How to influence isoDep retries?

[OliM]

We found that a specific card type (Mifare Desfire EV1) became unusable with the RFAL after a format. But I was able to "resurrect" it by using a Phone or a reader with a different IC.
Since debugging showed that the gIsoDep.state was always getting stuck in ISODEP_S_DSL, I saw that the default retires for deselect are zero. And as the Standard states "When the PCD fails to receive an S(DESELECT) response the PCD may retry the deactivation sequence.", I increased them by manipulating RFAL_ISODEP_MAX_DSL_RETRYS inside the lirbraries headers.
As a result the card also worked again on my ST25R3961b based device. 

But I would very much like to not change the library code and instead use officially provided interfaces. That interface seems to be rfalIsoDepInitializeWithParams(). But it is explicitly called inside rfal_nfc.c with the default parameters, just before starting the RATs. So where do I intervene to get my own settings in? Is that even possible?

[Brian TIDAL]

Hi Oliver,

what is the RFAL version (see RFAL_VERSION in rfal_rf.h) in your project?

Could you explain what you mean by "a format" (restore factory settings?)?

Regarding "getting stuck in ISODEP_S_DSL", this sounds strange. Could you connect a logic analyzer on the SPI (CLK, MOSI, MISO, CS) and IRQ_ST25R3916 and provide a trace? Could you provide a trace with a tag before "format" and a trace of a tag after "format"?

According to NFC Forum [DIGITAL] specifications, nISODEP,RETRY,DESELECT can be in the range [0-5]. This is encoded as RFAL_ISODEP_MAX_DSL_RETRYS. Before changing this value, let's understand the issue.

Rgds

BT

[OliM]

Format as in sending the Mifare Desfire FormatPICC command 0xFC.
I can not easily trace the SPI in the moment, but I could trace internal signals of the RFAL (v4.0.0 by the way) if that helps.

[Brian TIDAL]

Hi Oliver,

as far as I know, all AIDs are deleted once a FormatPICC command has been issued. In this formatted state, which command APDU do you send to the tag before sending the S(DESELECT)? Maybe some delays are needed by some of those commands before deselecting the tag.

Regarding the ISODEP_S_DSL, a no response timer (FWTISODEP,DEACTIVATION ~5.3ms) expires when the tag does not reply. Thus, unless the fwt value gets corrupted, it is unlikely to be stuck in ISODEP_S_DSL. Let's see the SPI traces when possible.

Rgds

BT

[OliM]

Stuck might habe been the wrong word. The stack was not hung up at that point but the freshly formatted card was stuck and not responding at that point before adding retries.
An stuck on the cards side meaning there was no responses to general requests even outside of AIDs like getting the version, free memory etc. Even if it was removed from the readers field and entered again. Nothing after RATS worked. 
That issue is very much an NXP one and not an ST one (and seems to be only present in the EV1 generation), but since we have to support those cards I have to deal with them. And what I can attest is, that those retries resurrect the otherwise uncooperative card. And only those retries. Increasing any other timeouts/retries did not bring a change.

Which brings me back to the original question: How do I/Can I alter that setting without changing the RFALs internal headers?

[Brian TIDAL]

Hi Oliver,

When you have to work around an abnormal problem, the solution can also be a bit "abnormal". The rfal_nfc high layer is designed for standard cases and provides convenient API to select a tag, send/receive data and then deselect. I see 2 possible workarounds:

1. change RFAL_ISODEP_MAX_DSL_RETRYS to (1U) or (2U) in rfal_isoDep.h
2. when the application detects a tag stuck in a "formatted" state, just use the rfalTransceiveBlockingTxRx (or rfalStartTransceive/rfalGetTransceiveStatus if non-blocking is preferred) to "manually" send S(DESELECT) frames to "resurrect" the tag.

By the way, it seems other users face similar issues with those tags: https://community.nxp.com/t5/NFC/DESFire-EV3-Formatting-Issue/m-p/1993225

Make sure to report your issue to the tag manufacturer.

Rgds

BT