[ST25R95] The response time of the SendRecv command is too long(>500us)

[vgegok]

I am trying to use ST25R95 as an ISO14443-A card reader to read a standard Mifare classic 1K card. I am using a logic analyzer (Saleae) to detect that the card response time after sending the SendRecv command is about 500us or more, which is too high for my actual needs, The following is a screenshot of the logic analyzer：

Note: The MOSI pin in the figure is not connected to the logic analyzer, as connecting the MOSI pin will cause ST25R95 to fail to start, This issue can be ignored in this discussion for now.

Wait for 100ms after the startup sequence is completed.

The IDN command received the correct response.

The protocol selection command has received a response of 0x0000.

Send SendRecv command: (00) 04 02 26 07

After approximately 500us, IRQ_OUT asserts.

I'm not sure if this is a problem with the configuration I'm using or the original ST25R95 design, but I hope to shorten the response time.

[Brian TIDAL]

Hi,

the IRQ_OUT asserts when a response to a previous command is available. In the present case, the IRQ_OUT asserts when a response from the tag has been received  or when the Frame Waiting Time (FWT) timer elapses. See the protocolSelect command if you want to change this FWT.

I see a lot of 03h polling in your trace. This is not needed if you rely on IRQ_OUT handling. I do not see the reading of the response (02h).

Also, I guess you have your own SW implementation. I would suggest to base your development on the X-CUBE-NFC3 package that provides ready to use demos.

Rgds

BT

[vgegok]

I use polling to obtain responses, and IRQ_OUT is only for reference.

The ST kit I purchased has not yet arrived.

In my tracking, 0x02 is located at the end of the time measurement, after the IRQ_OUT assertion. The response time I measured is above 500us.

If you have measurement data, please let me know.

[vgegok]

This is a complete SendRecv waveform:

[vgegok]

The attachment is the result of my testing using STM32F103RB Nucleo and x-cube-nfc3.

[Brian TIDAL]

Hi,

what I see in your screenshot is a sendRecv of the command 60h. If I am not wrong, this is the Auth (with Key A) command that requires a 1ms timeout. This Frame Waiting Time can be configured thanks to the protocolSelect command. This timeout applies on the RF communication path (i.e. the IRQ_OUT notification for the timeout (0x87 0x00) or for the answer (0x80 xxxxx) is sent after some internal processing). 

Can you explain in more details what you would like to to do and why you try to rely on the sendRecv response time?

Rgds

BT

[vgegok]

The response of the SendRecv command "00 04 52 27" also exceeds 500us. You can view the exported data from the logic analyzer I provided above.

I need to quickly read card data, and the response time exceeding 500us is much longer than the requirements in the ISO14443A protocol.

I think it is due to the long data processing inside ST25R95 that caused the delay in data output.

[Brian TIDAL]

Hi,

can you provide more information about the ISO14443A protocol requirements you are referring to? As far as I know, ISO14443A protocol requirements apply to the RF interface.

The sendRecv command of the REQA (0x26) or WUPA(0x52) causes the following transmission on the RF interface:

The overall RF transmit and receive lasts 336µs. Once the last byte has been received and transferred into the internal FIFO, the device checks the CRC, adds the additional information bytes into the FIFO and signals that the received data can be read from the FIFO by setting the IRQ_OUT low. Therefore, having 500µs for the overall sendRecv command for REQA or WUPA is nominal. The device manages the FWT for you based on the value provided in the protocolSelect command. Attempt to use the IRQ_OUT for managing the FWT cannot work as the IRQ_OUT is set to low once the whole response is received from the tag.

Rgds

BT

[vgegok]

Your statement is correct. FWT doesn't make sense to me, I just hope that the SendRecV command responds as quickly as possible.

300us is too long for me, and if it's a long command and response, the time will be even longer，Even more than 1ms.

I want to transmit all communication data frames of the 14443A protocol in real time to another ST25R95 block, and then simulate them in real time.

[Brian TIDAL]

Hi,

"300us is too long for me": the ISO14443A defines a transmission rate at 106 kbps. I am afraid it cannot be expected to spend less than 336µs for a REQA/ATQA command/response.

Rgds

BT