ST25R3917 not receiving 9000 answer to APDU (AID)

[LJimé.1]

Hello,

We are trying to implement the isodep functionality in one of our developments with the ST25R3917, acting as reader/PCD. We have implemented the libraries included in the STSW-ST25R018 firmware (https://www.st.com/en/embedded-software/stsw-st25r018.html) .

By other side, we have an Android App with a customized AID, already tested and working. It answers with 0x9000 when it receives the APDU containing the AID previosuly configurated. We have checked it with the ST25R3916 Discovery Board with the firmware version 1.4.3 (see following picture)

However, when we try to communicate with the App, using the libraries that I mentioned before, the answer to the APDU containing the AID (00 A4 04 00 07 XX XX XX XX XX XX XX) is 0xF208, which seems to be a S-Block message indicating the WTX period. In the libraries the behaviour to this answer is to send the same message received to the PICC (our smartphone in this case), until the PCD (our device) receives the right answer (0x9000). But when the ST25R3917 sends this message, it recives nothing from the  PICC.

I have checked that all the previous steps have been completed succesfully:
-The field is on

-The answer to the WUPA command is 0x0400

-The answer to the RATS command is 0x0578804400 (TL: 0x05, T0: 0x78, TA: 0x80, TB: 0x44, TC: 0x00) 

-The APDU is sent correctly with one pcb byte at the beginning (02 00 A4 04 00 07 XX XX XX XX XX XX XX)

Do you know what could be the problem?

Thank you in advance.

Regards,

[Ulysses HERNIOSUS]

Hello LJimé.1,

helpful for debugging would be a Logic Analyzer trace of SPI + IRQ - the working case triggered from the GUI (I assume from ISODEP tab) and the non-working case. It allows to analyze all settings and timings.

Otherwise I can only guess and ask a few more questions: Which APIs from STSW-ST25R018 are you using? Where is the spot where you inserted your APDU? 
I presume the transfers are going through rfal_isodep? Could be a misconfiguration by not getting the right params into ISODEP (rfalIsoDepPollAStartActivation/rfalIsoDepPollAGetActivationStatus). Are these being used?

Fully qualified examples of ISODEP usage are available as part of the ST25 Embedded NFC lib.

BR, Ulysses

[LJimé.1]

Hello Ulysses,

Thank you for your answer. I will try to analyse the SPI+IRQ signals for both the development kit board and our board.

The APIS of the STSW-ST25R018 we are using are the ones included in the Middlewares/ST/RFAL folder, and we have tried to reproduced the same steps that the ones followed in the "BSP_NFCTAG_Activate_NfcA" function, which is included in st25_discovery_st25r.c. I thought that this was the function used by the Isodep tab in the ST25R3916 Discovery GUI, because I want to have the same behaviour.

The APDU is inserted just after the  rfalIsoDepPollAHandleActivation function, which includes the two functions that you mentioned before (rfalIsoDepPollAStartActivation and rfalIsoDepPollAGetActivationStatus).

As for the examples of the ST25 Embedded NFC lib, in the 1.5.0 version, I have found only one example (exampleRfalPoller.c), but it has the same process that the BSP_NFCTAG_Activate_NfcA function. Are there any others?

Regards,

Luis

 

[Ulysses HERNIOSUS]

Hi Luis,

from a quick glimpse at STSW-ST25R018 the code for handling activation looks unsuspicious. Did you also port to a different MCU / change the platform timer handling? Because then it might also be the sanity timers inside RFAL timing out? Which error is returned by the transceive? (In case of sanity timer it would return ERR_IO).

But if you have a logic analyzer, do first some traces it should give most definite answers.

ST25 Embedded NFC lib uses the more modern rfal_nfc layer which internally handles also the activation.

BR, Ulysses

[Brian TIDAL]

Hi,

when a S(WTX) request is received by the PCD, an S(WTX) response is sent to the PICC as an acknowledgement and the PCD waits for next response frame with the adjusted frame waiting time. If no answer is received from the PICC, there is likely an RF issue. I guess you use a custom board and a custom antenna with the ST25R3917 (please confirm). In that case, make sure to follow AN5276 (Antenna design for ST25R3916/16B, ST25R3917/17B, ST25R3918, ST25R3919B, and ST25R3920/20B devices). 

Also, can you connect a logic analyzer on the SPI (CLK/MISO/MOSI/CS) + ST25R_IRQ and provide a trace on both the discovery board (communication ok) and your board (communication failure)?

Thanks

Rgds

BT

 

[LJimé.1]

Hi Brian,

Thank you for the explanation about WTX. I have tried to wait more than the time indicated in the S(WTX) request, but I still do not receive anything.

As you say we have designed our custom board and custom antenna, following the AN5276 document. It perfectly works with NTAG213 cards, and the rest of the negotiation until the APDU exchange works without problem, so it does not seem to be and RF problem.

As I have said to your colleague Ulysses I am going to analyse the SPI+IRQ signals for both the development kit board and our custom board.

Regards,

Luis

[Brian TIDAL]

Hi,

feel free to send us the logic analyzer log files (digiview/picoscope/salae or other) and we will as well investigate. After the S(WTX) request frame has been received and the S(WTX) response has been sent, check the various interrupts in the trace. You should see an I_txe (end of transmission of the S(WTX) response) then an I_rxs (start of reception) and an I_rxe (end of reception). If you see an I_nre (non response timer), this means that the reader has received no answer from the tag. You can then measure the duration between the I_txe and I_nre and check it is aligned with the requested frame waiting time. I bet you will see a I_nre with your custom board.

Rgds

BT

[LJimé.1]

Hi Brian,

I will definitely do it.

Indeed, after sending the S(WTX) response I get the I_txe, and then, when the time configured as non response time (Registers 0x10 and 0x11: RESPONSE TIMERS) is up, I get the I_nre, meaning there was no answer.

If I modify the non response time to a different value, I get this value as the difference of time between the I_nre and I_txe events, as you bet.

Regards,

Luis

[Brian TIDAL]

Hi,

I guess the Discovery board behaves identically when receiving the S(WTX) request and send exactly the same S(WTX) response and configure the same NRE timer. But with the discovery, an answer is received from the phone whereas when using the custom board the phone does not answer.

So I tend to conclude this is an RF issue (antenna, matching circuit, 27.12MHz crystal, power supply,... in a nutshell, the usual suspects).

Rgds

BT

[LJimé.1]

Hi Brian,

The logs of the ST25R3916 Discovery GUI do not show all the protocol exchange, in fact they show only the answer to the main commands (RATS and APDU), so I can not assure if there is a S(WTX) request-answer.

When I analyse the SPI+IRQ signals I will let you know. However, as I told you few answers before, it perfectly works with NTAG213 cards, which they are supposed to have the same RF frequency because all of them works under the ISO14443-A.

Thank you.

Regards,

Luis

[LJimé.1]

Hi again,

I have checked the differences between the analyzer files, and I have found that in the "rfalPrepareTransceive" function, the development board is sending the CMD_CLEAR_FIFO direct command, meanwhile in our custom board we are not sending it. Forcing this function to send this command, it works and the board receives the 0x9000 from the smartphone and answer to the following APDUs I send!!

Looking at the function, it seems strange to me because the function only clears the FIFO if the device is in a PICC mode, however, we are using the chip in a PCD mode. Here is the beggining of the function:

static void rfalPrepareTransceive( void )

{

    uint32_t maskInterrupts;

    uint8_t  reg;

   

    /* If we are in RW or AP2P mode */

    if( !rfalIsModePassiveListen( gRFAL.mode ) )

    {

        /* Reset receive logic with STOP command */

        st25r3916ExecuteCommand( ST25R3916_CMD_STOP );

   

        /* Reset Rx Gain */

        st25r3916ExecuteCommand( ST25R3916_CMD_RESET_RXGAIN );

    }

    else

    {

        /* In Passive Listen Mode do not use STOP as it stops FDT timer */

        st25r3916ExecuteCommand( ST25R3916_CMD_CLEAR_FIFO );

    }

...

 

Thank you again for all the help you have provided to us.

Regards,

Luis

[Ulysses HERNIOSUS]

Hi Luis,

we are a bit surprised by your findings which we currently cannot explain. Could you share your logic analyzer traces, please! 

BR, Ulysses