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

[Stasevich]

By the way !

The LOG from the logic analyzer at the moment when the ST25R3916, in 14443A emulation mode, receives an APDU request for reading a record (00b2041400) or any other request expecting a 255-byte response + 0x90 0x00, and then sends that response! Because the whole trick revolves around how to properly send the 9000. Maybe someone will have the opportunity to capture such data.

Please.

This would resolve all questions. I figured out the same way how ST25R3911B-Disco reads long packets (even though it shows an error).

[Brian TIDAL]

Hi,

in NFC-A mode, the ST25R3916 card emulation demo emulates a T4T tag. A T4T tags contains an NDEF application. Once the NDEF application has been selected, the Capability Container file is read. This file contains MLc and MLe parameters to define respectively the Maximum data size that can be written by the Type 4 Tag in one WRITE Command and the Maximum data size that can be read from the Type 4 Tag in one READ Command. Those parameters are set to 7Fh in the ST25R3916 card emulation demo. Thus an NFC compliant reader application has to request no more that 7Fh bytes in a read binary command with ST25R3916 card emulation demo. When more that <MLe > bytes needs to be read, the reader application has to send several Read binary command with the relevant size and offset. See NFC Forum Type 4 Tag Technical Specification [T4T]. If more that <MLe > bytes are requested, the behavior of the T4T tag is not specified but likely the tag returns no more than <MLe>.

Can you provide more information about your use case? Which reader do you use in front of the ST25R3916 Card Emulation demo? Which application is being used: NDEF? 

Rgds

BT

[Stasevich]

Hardware :

Reader : STEVAL-25R3916B  GUI 1.4.18.0 

Perfectly handles the reading of the original EMV card  even 257 bytes . 

ISO-DEP  > Discover >  Custom APDU / [00b2041400]  Send  ...  Receive > 257 bytes: [70 81 FB ....90 00] .

What indicates the fact that the reader successfully receives such long frames.

I wanted to pull off a trick and set up FSCI in the GUI in card emulation mode to a 16-byte value to observe, using an analyzer, how the algorithm for splitting into short frames and sending them in a chain works. However, as it turned out, the GUI in this version doesn’t support the chain data transmission mode except for a maximum of 256 bytes. To see the following step-by-step: here the transmission of the first frame  ended with the direct command C4, and then the sequence of commands for transmitting the subsequent frame. 

If the concept of "chain transmission" implies repeating actions similar to sending the first frame within a timeout until an interrupt is triggered due to exceeding the data reception timeout, it doesn't work that way. Setting a value exceeding 256 bytes in registers 0x22 and 0x23 and then sending short frames in a loop also doesn't work.

[Ulysses HERNIOSUS]

Hi,

on STEVAL-25R3916 GUI: 

1. ISO14443A  tab: Discover and activate ST25TA with FSD: 16 bytes
2. ISODEP: NDEF Select App, Select NDEF File
3. ISODEP: ReadBinary - receives 17bytes of APDU which due to the FSD = 16 will be received using multiple frames.

Attached trace (DigiView) details the exchanged frames at marker 1,2,3,4.

BR, Ulysses

[Stasevich]

Hello .

The example you provided shows 3916 in reader mode . Ask -> 03 00 B0 00 00 0F  and  Rep. sent by tag in several frames.

But the whole question of the topic is : how to make 3916 in emulator mode transmit more than 256 bytes in chain to the reader .

[Ulysses HERNIOSUS]

Hi,

yes, the SPI trace is from the reader. But it also shows clearly all the PCD and PICC frames exchanged for this ISODEP chaining. You will need to replicate PICC frames. As this question was about how to perform chaining the traces are sufficient.

Ulysses