ST25R3911 No Response After second APDU Command

[Marius Celliers]

Posted on February 08, 2018 at 14:54

Hi .. I am currently sending an APDU Command to a card with the ST25R3911 and get a valid response.

I use the HAL drivers and middleware from ST-CubeMX ( CPU = STM32F401RE)

As soon as I try to send another APDU command ( or even the same one again) I receive 0 bytes from the card.

I start With rfalIsoDepPollAHandleActivation()

   then i set up may parameters (rfalIsoDepApduTxRxParam)

   then I send my first APDU Command. (rfalIsoDepApduBufFormat)

  err = rfalIsoDepStartApduTransceive(myParam);

   then I wait for the response in a loop with rfalworker()

for (int i=0;i<TIMEOUT;i++)

            {

               // Run the RFAL Worker

               rfalWorker();

              err = rfalIsoDepGetApduTransceiveStatus(); //Check The Status of the APDU Transceive

               if (err == ERR_NONE)

               {

                     logUsart('APDU Transceive Success\r\n');

                     rfalWorker();

                     HAL_Delay(20);

                     break;

                 }

               HAL_Delay(20);

               if (err == ERR_BUSY)

               {

                  logUsart('.');

               }

            }

after I received my rxBuf data,

   I change the txBufLen  and apdu command and send the data to the card, but now i get 0 bytes returned.

   also if i send the same apdu command to the card I also get 0 bytes returned.

my first apdu sending code is exactly the same as the second apdu sending code.

I also clear my Rx and Tx APDU buffers before loading the next C-APDU.

   ST_MEMSET(&apduCommand.apdu,0x00,sizeof(apduCommand.apdu));

      ST_MEMSET(&apduResponse.apdu,0x00,sizeof(apduResponse.apdu));

Is there any other initialization or,  setting of parameters, that I am missing ?

I believe that I should not try to run 

rfalIsoDepPollAHandleActivation() again (before the next APDU Transceive) as I am not disconnecting the card in any way.

#send-apdu #nfc #st25r3911b #apdu

[Ulysses HERNIOSUS]

Posted on February 09, 2018 at 14:40

Hi Marius,

yes, you should not try to reactivate the card. 

Not sure what is happening but a few ideas for more information:

• I assume you feed in the parameters received during activation (rfalIsoDepDevice->DID,FWT,dFWT and FsX) into the rfalIsoDepApduTxRxParam ? 
• What is the value of your err variable - when it is neither ERR_None nor ERR_Busy?
• The Hal_Delay(20) is too large, if the received APDU is larger then some 90+x bytes then this will overflow the FIFO of ST25R3911B

Regards, Ulysses

[Marius Celliers]

Posted on February 09, 2018 at 15:26

HI Ulysses

Thank you for your reply.

Yes, After Activation I use the parameters returned from tfalIsoDepDevice

err =

rfalIsoDepPollAHandleActivation(RFAL_COMPLIANCE_MODE_NFC_11,RFAL_ISODEP_FSXI_512,RFAL_ISODEP_NO_DID,RFAL_BR_424,

&isoDepDevice

);

myParam.DID = RFAL_ISODEP_NO_DID;     

//isoDepDevice.info.DID; //

myParam.FWT = isoDepDevice.info.FWT;

myParam.dFWT = isoDepDevice.info.dFWT;

myParam.FSx = isoDepDevice.info.FSx;

myParam.ourFSx = RFAL_ISODEP_FSX_KEEP ;

myParam.txBuf = &apduCommand;

myParam.txBufLen = apduTxLen; myParam.rxBufLen = &apduRxLen; myParam.rxBuf = &apduResponse;

On Sending a Second APDU to the Card :

I get No error when I transmit err = rfalIsoDepStartApduTransceive(myParam);

I Use a 'for' routine that runs ( 35 times.  I later changed it to 350 times) to get the Transceive status.

So after 350 times calling the rfalWorker(); and rfalIsoDepGetApduTransceiveStatus();

I still get ERR_BUSY after the 350 cycles. ( My response for the second APDU Command should be more or the same size as the first apdu command that I have sent)

I have changed my loop with a delay of HAL_Delay(1) and retries of 2000 ( TIMEOUT = 2000)

for (int i=0;i<TIMEOUT;i++)

{

               

    err = rfalIsoDepGetApduTransceiveStatus();

//Check The Status of the APDU Transceive

         HAL_Delay(1);

// Run the RFAL Worker

         rfalWorker();

         if (err == ERR_NONE)

         {

                  logUsart('APDU Transceive Success\r\n');

                  rfalWorker();

                  HAL_Delay(1);

                  break;

           }

         HAL_Delay(1);

         if (err == ERR_BUSY)

         {

//  logUsart('.');

         }

} 

// for loop end

logUsart('AID Receive Buffer have %d Bytes\r\n',apduRxLen); if (apduRxLen > 0) {       logUsart('Rx Data: %s\r\n',hex2Str(apduResponse.apdu,apduRxLen)); }

Just to be sure, I have written the all parameters again in the Param struct before sending the second APDU comand.

myParam.txBuf = &apduCommand;// &apduCommand;

myParam.txBufLen = apduTxLen;

myParam.rxBufLen = &apduRxLen;

myParam.rxBuf = &apduResponse;

myParam.DID = RFAL_ISODEP_NO_DID;//isoDepDevice.info.DID; //

myParam.FWT = isoDepDevice.info.FWT;

myParam.dFWT = isoDepDevice.info.dFWT;

myParam.FSx = isoDepDevice.info.FSx;

myParam.ourFSx = RFAL_ISODEP_FSX_KEEP ;

but still no response on the second apdu command, ( also,I removed the USART Write command from ERR_BUSY in case of timing issues)  but stays on ERR_BUSY.

[Ulysses HERNIOSUS · Accepted solution]

Posted on February 09, 2018 at 17:14

Hi Marius,

looks like the state machine of the driver is not advancing. Maybe an issue in the interrupt porting. Can you grab a multimeter and measure the INT pin of ST25R3911B? If it is high then the ISR is not exexuted. 

Regards, Ulysses 

[Marius Celliers]

Posted on February 12, 2018 at 07:25

Hi Ulysses. Thank you.

I will connect my logic analyser on the SPI Pins and INT Pin to see what is happening. 

Cause it is strange that sending and receiving the first APDU to the card is good, but as soon as I try to send another command to the card I get no response back (ERR_BUSY).