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,

[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

[Ulysses HERNIOSUS]

Hi Luis,

in the traces there is no CLEAR_FIFO command: Yes it displays 0xdb but this is a display artifact of incorrect SPI configuration inside Logic Analyzer.

In the RW mode we are using STOP(0xc2) command which does the same as CLEAR_FIFO and much more. In your traces of I2C I don't find these commands, could it be your I2C driver is dropping I2C requests? 

BR, Ulysses

[Ulysses HERNIOSUS · Accepted solution]

Reviewing your latest traces: The number of commands for C4, C5, C2 D5 are not matching. Before every transmission (C4,C5) a sequence of C2 + D5 is triggered inside RFAL. Not seeing these commands for me means some requests on I2C/SPI are being dropped within your port/driver system.

BR Ulysses

[LJimé.1]

Hi,

Thank you for your information Ulysses. I will check deeply every single transmission to find out why the number of C2+D5 executions does not match with the C4,C5 sequence.

Regards,

Luis