ST25R3916 I want to improve the speed of reading block. How can I debug it?

[hanzigg]

Hello,I have a question need your help!

About :MCU L431(80MHz),SPI 5M,IC ST25R3916. NFC06A1

I use "rfalNfcvPollerReadMultipleBlocks()" read two blocks at a time,but I found that it takes 9 ms to read successfully. How can I shorten this time?

[Ulysses HERNIOSUS]

Hi,

I think most of the time is consumed in the air:

NFCV typically works at 26kbps. The request to read is either 6 bytes or 14 bytes (if addressed mode is used). Then after ~300us the tag will answer: 2 blocks: 8 bytes + flags + CRC without security status: 11bytes.

So in case you are using addressed this would be 25bytes * 8 / 26 = ~8ms

You can try optimizing this by:

• Using rfalNfcvSelect() and using the select flag
• Reading more blocks at once
• Going towards ST25TV/DV and its fast mode where you can receive at 52kbps.

BR, Ulysses

[hanzigg]

Thank you very much for your reply.

The function I use is "err = rfalNfcvPollerReadMultipleBlocks(reqFlag, NULL, block_addr+i, 1, &rfid_data.buff[(modbus.rfid_block_size+2) * i], (modbus.rfid_block_size*2+3), &rcvLen);"

The tag I use can read up to 2 block at a time.The reqFlag is DEFAULT.And I directly set the read uid to null.So it takes 9ms to execute once.

According to your suggestion ,I added the selection mode before reading the data:

#if DEMO_NFCV_USE_SELECT_MODE
 err = rfalNfcvPollerSelect( reqFlag, nfcDevice->dev.nfcv.InvRes.UID );
if( err == RFAL_ERR_NONE )
{
  reqFlag = (RFAL_NFCV_REQ_FLAG_DEFAULT | RFAL_NFCV_REQ_FLAG_SELECT);
  uid = NULL;
}
#endif /* DEMO_NFCV_USE_SELECT_MODE */

But,The time is longer now than before. Is there something wrong with my program?

And,I want to know how long it takes for ST25R3916 to discover NFCV.I'm 6ms now.

And,What is the shortest time to read two blocks (a block = 8 bytes) with this common tag?

Hope to get your reply.

[Ulysses HERNIOSUS]

Hi,

in your timings: Are you including the time for the Select itself? If so then it is clear to me - I had recommended this as I was assuming that you will call the read multiple more than once.

Otherwise there will be also the option to use the read multiple in broadcasted mode: Default flags + uid=NULL: The command will be sent to all tags in the field and will be answered by all of them simultaneously.

I am seeing that there are also commands for Fast Read Multiple which should give you a benefit as well. Please beware that the rfal_nfcv layer only uses the fast mode for well-known commands, for the Fast Read Multiple Blocks Unlimited you may need to perform changes in the driver.

One correction on my previous calculation: It was for 4 byte blocks. For 8byte blocks you need to further adapt.

Similar calculations you can do for Inventory commands: Calculate the sent and received bytes, calculate the duration and add 300us. For inventory you need to add some 5ms more, because this is the time you have to give the tag to power-up after enabling the field.

Regards, Ulysses

[hanzigg]

========================================================

#if DEMO_NFCV_USE_SELECT_MODE

/*

* Activate selected state

*/

  err = rfalNfcvPollerSelect( reqFlag, nfcDevice->dev.nfcv.InvRes.UID );

if( err == RFAL_ERR_NONE )

{

  reqFlag = (RFAL_NFCV_REQ_FLAG_DEFAULT | RFAL_NFCV_REQ_FLAG_SELECT);

  uid     = NULL;

}

#endif /* DEMO_NFCV_USE_SELECT_MODE */

if(modbus.rfid_block_size==8)

{

   for(i=0;i<blocks+1;i=i+2) 

  {

  err = rfalNfcvPollerReadMultipleBlocks(reqFlag, NULL, block_addr+i, 1, &rfid_data.buff[(modbus.rfid_block_size+2) * i], (modbus.rfid_block_size*2+3), &rcvLen);

  if (err != ERR_NONE) break;

 }

}

=========================================================

Does not include the selected time,Without using the fast read command, it takes 9ms to execute "err = rfalnfcvpollerreademploblocks" once. Is there any other way to shorten this time? Reading 100 bytes with other people's products is more than 70 ms, and mine is more than 80 ms. So this is the technical point I want to overcome.

Is there any corresponding information o or demo or case for reference?

[Brian TIDAL]

Hi,

see https://community.st.com/t5/st25-nfc-rfid-tags-and-readers/decrease-the-time-to-write-read-a-block-fro-a-nfc-tag/td-p/601357 for a similar question.

When using the Read Multiple Blocks command in non-addressed mode to read 2 blocks of 8 bytes, the request contains 6 bytes and the response contains19 bytes. When using 26 kbps bit rate:

6 bytes transmission	1.92ms
t1	0.320ms
19 bytes reception	6.04ms
t2 to next command	0.309ms

Total duration is 8.59ms for a Read Multiple Blocks command/ response with 2 blocks of 8 bytes. This is inline with your 9ms measurement.

As 100 bytes is not a multiple of 16 bytes, I assume 7 command/response pairs are needed, so the duration for reading 112 bytes is ~63ms. What is your starting point for your 80ms measurement?

If using the Fast Read Multiple Blocks, the request contains 7 bytes and the response contains19 bytes.

7 bytes transmission	2.22ms
t1	0.320ms
19 bytes reception	3.02ms
t2 to next command	0.309ms

Total duration is 5.87 to read 2 blocks of 8 bytes with fast mode, so about 35.2ms for 96 bytes

If using the Read Multiple Blocks Unlimited proprietary command to read for example 6 blocks:

7 bytes transmission	1.92ms
t1	0.320ms
51 bytes reception	15.7ms
t2 to next command	0.309ms

Total duration is 18.6ms to read 6 blocks of 8 bytes, so about 37,2 ms for 96 bytes

I would personally use this Read Multiple Blocks Unlimited proprietary command and read 4 or 6 blocks per requests.

Rgds

BT

[hanzigg]

Hi,

Compared with what you said, it takes me 9.1ms to use Read Multiple Blocks command and 7.3ms to use Fast Read Multiple Blocks command, both of which are slower than the theory.

But,The tag on the customer site may not support Fast Read, so I still have to use Read Multiple Blocks command.

Is this the fastest speed that can be achieved by using Read Multiple Blocks command? Is there any other way to improve it?I will provide you with what you need.

Finally, regarding the read multiple blocks unlimited proprietary command you mentioned, I didn't find this command in the demo. Where can I get this command demo?

Rgds

H

[Brian TIDAL]

Hi,

"Compared with what you said, it takes me 9.1ms to use Read Multiple Blocks command and 7.3ms to use Fast Read Multiple Blocks command, both of which are slower than the theory." the theoretical values are related to air transmission only.  MCU / device communications over SPI (registers configurations, FIFO write and read)  add some extra duration. So, your measurement are inline with the theoretical values + MCU / device communications duration.

"The tag on the customer site may not support Fast Read, so I still have to use Read Multiple Blocks command": please note that Read Multiple Blocks is an optional command from ISO15693 point of view so if your customer uses another tag, it may not support the Read Multiple Blocks command. It may also support another block size (e.g. 4 instead of 8 on MB89R118C) and may support a different maximum number of blocks for the Read Multiple Blocks command (when supported).

"Is this the fastest speed that can be achieved by using Read Multiple Blocks command?" Duration of the transmission on the air is defined by the standard.

"Is there any other way to improve it?" 

• read a greater number of blocks during read multiple blocks (e.g. use read multiple blocks unlimited command as the read multiple blocks on this tag is limited to 2)
• use Fast Read Multiple blocks
• use ST25TV tags that supports read multiple blocks and fast read multiple blocks with more than 2 blocks

"regarding the read multiple blocks unlimited proprietary command you mentioned, I didn't find this command in the demo" The read multiple blocks unlimited command is a proprietary command of the MB89R118C device. The demo provides the support of

• standard commands,
• proprietary command for ST tags.

Thus, the support of read multiple blocks unlimited command is not provided but one can easily add the support of this command.

Rgds

BT

[Ulysses HERNIOSUS]

Hi,

outside of the air time there is also a small time for performing communication with ST25R (setting registers, filling/emptying FIFO, etc.) I guess this accounts to some 9.1-8.59 = 500us. Also a little bit of time is still consumed by SOF and EOF.

IMO the timing is pretty good, little overhead. Throughput of the NFC link was not the priority goal of RFAL.

If one know what to do this could probably be further optimized in a specialized driver (e.g receiver settings could be written while transmitting, Filling FIFO while transmitting and not before, Emptying FIFO while receiving and not waiting for the end, .....)

BR, Ulysses