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]

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