ST25R3911B No Response Data After Sending APDU Command

[Marius Celliers]

Posted on January 30, 2018 at 16:01

Hi All. I am Using The Nucelo-NFC5A1(ST25R3911B) board with STM32-Nuceo-F410RE board.

(Using the X-Cube-NFC5 middleware RFAL).

I am not getting any responses from my APDU commands sent to a card. ( Also no Error Codes from the rfalIsoDep functions I use).

I have selected the NFC card and activated it. I have written a function to send the APDU command to the PICC.

After calling the  rfalIsoDepGetApduTransceiveStatus() until it is not busy anymore, I find that the rxbufferLength is 0.

I would expect that even when my APDU command is incorrect, I should at least get a response of 0x90 0x00.

I have added  rfalWorker() into my loop for

rfalIsoDepGetApduTransceiveStatus() as

 I assume it is required for the response.

Also: According to documentation(rfal.chm + x-cube-nfc5.chm), the rfal is modifying the Txbuffer.prologue, or should I also configure this? 

I could not see in any example that the prologue needs to be configured.

code is as folllows:

err =

rfalIsoDepPollAHandleActivation

(RFAL_COMPLIANCE_MODE_NFC_11,RFAL_ISODEP_FSXI_512,RFAL_ISODEP_NO_DID,RFAL_BR_424,&isoDepDevice);

if( err != ERR_NONE ) return false;

rfalIsoDepApduTxRxParam myParam;                     

//Param to be passed to rfalIsoDepStartApduTransceive(param)

rfalIsoDepApduBufFormat apduCommand;            

// Struct that contains prologue + APDU Buffer

rfalIsoDepApduBufFormat apduResponse;            

// Struct that contains prologue + APDU Buffer

uint8_t DDF2[] = '2PAY.SYS.DDF01';

uint8_t headerLen = 5;

uint16_t 

ddflen = sizeof(DDF2);

//Setup APDU Command

apdu

Command

.apdu[0] = 0x00;          

//CLA

apdu

Command

.apdu[1] = 0xA4;          

//INS

apdu

Command

.apdu[2] = 0x04;          

//P1

apdu

Command

.apdu[3] = 0x00;          

//P2

apdu

Command

.apdu[4] = ddflen - 1;    

//P2

//INS

for (uint8_t i;i<ddflen;i++) {

     

apdu

Command

.apdu[i + headerLen]= DDF2[i];   }

/

/Setup ISODEP APDU Command

myParam.FWT = isoDepDevice.info.FWT;

myParam.dFWT = isoDepDevice.info.dFWT;

myParam.FSx = RFAL_ISODEP_FSX_KEEP;      

//myParam.FSx = isoDepDevice.info.FSx;

myParam.DID = isoDepDevice.info.DID;              

// RFAL_ISODEP_NO_DID

myParam.ourFSx = isoDepDevice.info.FSx;

myParam.txBuf = &

apdu

Command

;

myParam.rxBuf = &

apdu

Response

;

myParam.rxBufLen = &myADPURxLen;

myParam.txBufLen = ddflen;

// Start TX RX of APDU Command

err =

rfalIsoDepStartApduTransceive

(

myParam

);

// CHEK for Response if completed with ERR_BUSY

for (uint8_t b=0;b<30;b++)

{

rfalWorker();

            result =

rfalIsoDepGetApduTransceiveStatus();

            if (result == ERR_BUSY) {

                  logUsart('.');

                  HAL_Delay(250);

                  }

            if (result == ERR_NONE) {

                  logUsart('RX Done \r\n');

                  break;

                  }   

}

logUsart('R-APDU responded with %d Bytes \r\n',

myADPURxLen

);

//Here I receive 0 Bytes in the rxBuflen field

#x-nucleo-nfc05a1 #st25r3911b #iso14443a-iso-dep #rfal #apdu #x-cube-nfc5

[Marius Celliers]

Posted on January 30, 2018 at 17:32

Hi. It Seems that I Just had some issues in my APDU command.

But what I just wanted to make sure, is about the

rfalWorker();

Does it have to be called after every command such as :

   1) 

rfalIsoDepStartApduTransceive

(

myParam

) and 

rfalIsoDepGetApduTransceiveStatus();

[Ulysses HERNIOSUS]

Posted on February 01, 2018 at 08:21

Hi Marius, 

yes rfalWorker needs to be called repeatedly - as long as

rfalIsoDepGetApduTransceiveStatus(); 

returns ERR_AGAIN. Please also make sure that you called it something like once a Millisecond as the rfalWorker is also responsible for e.g. FIFO handly and if you need to certify at some point according to NFC Forum or such  it also needs to handle EMD suppression. So probably best to call it in a dense loop.

Ulrich

[Ulysses HERNIOSUS · Accepted solution]

Posted on February 01, 2018 at 08:25

Hi Marius,

regarding the prologue field: You don't need to do anything on it - it will be handled internally. The remark merely explains why the parameter is not const. The prologue is there to avoid extra buffer allocation for getting a linear buffer for the lower layers as the isodep needs to add some bytes in front (the so-called PCB). 

Ulrich