ST28R3911B - RFAL Middleware : ERR_PROTO (11) Response when sending APDU Command

[Marius Celliers]

Where to I start to debug the RFAL middleware if I receive ERR_PROTO (11) when I call err= rfalIsoDepStartApduTransceive(P); or rfalIsoDepGetApduTransceiveStatus();

I receive ERR_PROTO from the RFAL when I send a card a specific (APDU) , For some cards it works and for others it doesn't. The only thing that I think could be the problem ( By looking at the responses from another NFC reader) is that it works when the response message is smaller than 128 bytes. Cards with R-APDU response lengths of 77 bytes work, but when I use a card that should return 133 bytes (R-APDU), I get the Error message (ERR_PROTO) from the function rfalIsoDepGetApduTransceiveStatus();

[Ulysses HERNIOSUS]

Hi Marius,

one shot in the dark:

• the FSx parameter of rfalIsoDepPollAHandleActivation() / retrieved from it does not match with the ones ([our]FSx) in rfalIsoDepTxRxParam/rfalIsoDepApduTxRxParam

otherwise to debug this:

• put breakpoints to all uses of ERR_PROTO in rfal_isoDep.c
• Do an RF sniff or logic analyzer trace of the SPI communication with the ST25R3911B

Regards, Ulysses

[Marius Celliers]

Hi Ulysses.

Thank you for your reply.

The rfalIsoDepPollAHandleActivation provides the following in the rfalIsoDepDevice.rfalIsoDepInfo

( Just after Activation)

FWT = 524288

dFWT = 16

FSxI = 8

DID = 0

FSx = 256

I log the settings (to uart)of the rfalIsoDepDevice just before sending the command :

Just before I send any APDU command, I also set the following:

(where P =is a new rfalIsoDepApduTxRxParam for sending a command)

(and dev = the rfalIsoDepDevice on activation)

P.ourFSx = RFAL_ISODEP_FSX_KEEP ; // where RFAL_ISODEP_FSX_KEEP = 255

P.FWT = dev.info.FWT; //

P.dFWT = dev.info.dFWT; //

P.FSx = dev.info.FSx;

Here is the Failed Card response (with Parameters used when sending):

SENDING APDU >> 80A80000238321F620C00000000000000100000000000007100000000000071020012800FDA00AA500  Bytes = 41

(P Params used. viewed just after sending)

APDU DID 0

, FWT 524288

, dFWT 256

  FSx 255

  ourFSx 524288

PROTOCOL ERROR [11]

And here is the Working Card Response:

SENDING APDU >> 80A80000238321F620C00000000000000100000000000007100000000000071020012800FDA00AA500 Bytes = 41

(P Params used. viewed just after sending)

APDU DID 0

, FWT 524288

, dFWT 256

  FSx 255

  ourFSx 524288

<< APDU Receive Success (77 Bytes)

77498202000094040801010057134548581342346394D22092010000013946000F9F100706070A03A020009F2608E8CC15F41AB9187B9F2701809F360200219F6C0220009F6E04207000009000

I will Add mentioned breakpoints now as per your message and try to narrow the issue down a bit more.

Thank you.

[Marius Celliers]

Just a response to my issue on the Error 11 "Protocol Error" when sending APDU Commands:

As a test, I have changed the Le byte to 0xFF in my APDU command and then the response was returned correctly.

It seems that if the response length is below 127 bytes, Le can be 0x00 but with responses that is larger than 127bytes it gives and error If I do not change it to a much higher value( Such as 0xFF)

So I had to change for example:

SENDING APDU >> 80A80000238321F620C00000000000000100000000000007100000000000071020012800FDA00AA500

to

SENDING APDU >> 80A80000238321F620C00000000000000100000000000007100000000000071020012800FDA00AA5FF

And then it worked when my responses have larger array lengths.

My thought was that I could leave Le always on 0x00 for any APDU command. Or do I have a wrong setting somewhere?

( RFAL_ISODEP_APDU_MAX_LEN is 1024 as set in rfal_isoDep.h)

[Ulysses HERNIOSUS]

Hi Marius,

the Le parameter is part of ISO7816-4 and not part of isoDep.

But it may be that the smart card interprets it somehow and then starts to violate the isoDep protocol. For this I would need to see all the low level frames being sent and received - SPI trace or breakpoint in rfalStartTransceive().

I don't have much experience with Le, to which values (except for ReadBinary) it should be set and the actual interpretation may also depend on the addressed applet.

Regards, Ulysses

[Marius Celliers]

Thank you.

I don't think that the SmartCard violates isoDep Protocol as the card Is a VISA credit card. I know the APDU Command is Valid so something else is causing an issue (Same Command as my Android test app) . I know I get valid Error responses( APDU Error Codes) when The APDU Command is not correct, but I am Starting to pull my hair out trying to resolve this why rfalIsoDepStartApduTransceive(.) is returning Error 11. when there is large data.

So by putting breakpoints on all the ERR_PROTO results I found that the Function isoDepHandleControlMsg(,) is creating the error message in switch case :

switch( controlMsg )

{

........

    /*******************************************************************************/

    case ISODEP_S_WTX:

      if( gIsoDep.cntSRetrys++ > ISODEP_MAX_S_RETRYS )

      {

        return ERR_PROTO;

      }

}

All I can think of is that it is a Timing Issue or time parameter on the response command.

Am I heading the right way?

Regards Marius.

[Ulysses HERNIOSUS]

Hi Marius,

we know from past experience that some payment cards issue a good number of S(WTX). We are typically limiting this number in our applications but I could imagine that this card is starting to issue more S(WTX). Our EMVCo demos even use infinity for this as some test tools keep repeating S(WTX) for a very long time.

Please try to configure the isoDep with: rfalIsoDepInitializeWithParams( RFAL_COMPLIANCE_MODE_EMV, 1, 2, RFAL_ISODEP_MAX_WTX_RETRYS_ULTD, 0, 2, 0 ); (i.e. setting .maxRetriesSWTX=RFAL_ISODEP_MAX_WTX_RETRYS_ULTD) )

Regards, Ulysses

[Marius Celliers]

Hi Ulysses. Thank you.

I'll see what I can do as my application use RFAL V1.0.0 / 15-March-2017... and the rfalIsoDepInitializeWithParams was not yet implemented in the code. (also the gIsoDep struct is different)

I have written a test app on a nucleo board (with NFC5A) using V2.0.10 / 25-Jun-2019 and the rfalIsoDepInitializeWithParams is implemented in the code, but I could not find any defines for RFAL_ISODEP_MAX_WTX_RETRYS_ULTD in the source code . Do you know what this value should be?

In my Initial app for our product I still use RFAL V1.0.0 / 15-March-2017. could i just replace the files with the latest RFAL ? or would this cause issues as I see there are quite a lot of changes and file changes in the newer version.

[Ulysses HERNIOSUS · Accepted solution]

Hi Marius,

the referred params can be found in RFAL v2.1.2 available as STSW-ST25RFAL001.

For older RFAL you could try to substantially increase ISODEP_MAX_S_RETRYS to e.g. 20 or even more but this may have a bad effect on DESELECT retrys causing unnecessary delays.

Probably better to just remove above cited checking:

        case ISODEP_S_WTX:
            //if( gIsoDep.cntSRetrys++ > ISODEP_MAX_S_RETRYS )
            //{
            //    return ERR_PROTO;
            //}

In any case I recommend to eventually move to latest RFAL if you are still somewhat early in your project. You may have to set/change some config defines but overall the effort should be limited.

Regards, Ulysses

[Marius Celliers]

Hi Ulysses. Thank you.

I did increase the ISODEP_MAX_S_RETRYS this morning and it did fix my Issue on RFAL V1.

I also think it would be best to Move to the latest RFAL version. (Will take some time as the project is quite large)

Thank you for all your assistance.

It is very much appreciated.

Regards

Marius