Skip to main content
M
Marius Celliers
Visitor II
January 29, 2020
Solved

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

  • January 29, 2020
  • 2 replies
  • 1995 views

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();

    This topic has been closed for replies.
    Best answer by Ulysses HERNIOSUS

    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

    2 replies

    U
    Ulysses HERNIOSUS
    Technical Moderator
    January 29, 2020

    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

    M
    Marius CelliersAuthor
    Visitor II
    February 26, 2020

    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)

    U
    Ulysses HERNIOSUS
    Technical Moderator
    February 26, 2020

    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

    M
    Marius CelliersAuthor
    Visitor II
    January 29, 2020

    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.

    Terms & ConditionsAccessibility statement