ST25R3916 14443A emul.mode. How to send more than 255 bytes as a respond to the reader ?

[Stasevich]

Hello!I'm completely lost in my search for a solution.

Question description: The 25R3916 in 14443A emulation mode. When sending data to the reader with a length of up to 255 bytes, everything works perfectly. However, if I need to send data longer than that (e.g., a response to an APDU read record request 00B2041400), which is 3 bytes longer (including the successful APDU response [x90_x00]), things start to get complicated.

What should the EMD suppression configuration register be set to, and what is the algorithm for sending the data?

[Ulysses HERNIOSUS]

Hi,

if you are talking about APDUs I assume you mean to smartcards. Typically frames are at most 256 (FSDI/FSCI) bytes but the ISODEP layer will need to take care of splitting and sending as chained package. 

Please beware that also the applet on top need to be able to cope with such large APDUs. NFCB imposes here an additional limit by means of MBLI.

To my knowledge nothing similar exists for NFCA.

BR, Ulysses

[Stasevich]

Yes, I mean the APDU from the smart card specifically. The original card provides a response (e.g., a public key) of 256 bytes, but to send these 256 bytes to the reader using the ST25R3916, you need to add 0x02/0x03 at the beginning and 0x90 0x00 at the end.

For lengths up to 255, it works as follows:

- The packet length is written to registers x22, x23.
- Then, send x80 [data].

But if 270 is written to registers x22, x23, after sending the first 255 bytes, an interrupt occurs on register x16 M_rx_rest.
How to send the remaining bytes after this? If you immediately issue the send data command x80 [data] without re-specifying the packet length, the reader will not combine the first and second packets together.

[Ulysses HERNIOSUS]

Hi,

what is your reader counter part? If you don't have that under control as well then it is unlikely that the reader side will accept more than 256 byte frames. During RATS it will send its FSDI and card needs to respond with its FSCI. Only if both indicate support for 512 bytes then your approach could work.

Otherwise you need to refrain to using ISODEP chaining. Change your PCB (currently 0x02/0x03) to include the chaining bit, then send the first part of the APDU. Then the reader needs to send an R(ACK) and then you can respond with the rest. Please refer to NFC Forum ISODEP or ISO/IEC 14443-4 Data Link Layer (T=CL).

I am also interested in your problems the other way. Could you share a logic analyzer trace of it. I_rx_rest is unexpected for me. EMD should only be active for PCD mode.

BR, Ulysses