Skip to main content
A
andy_long
Graduate
February 17, 2024
Solved

read maximum data from st25tv16k

  • February 17, 2024
  • 2 replies
  • 1200 views

Hi,

Reader IC - ST25R3916
RFAL version - 2.8.0

Serial interface - I2C

I am trying to read the entire memory (2KB) from ST25tv16k using the api rfalNfcvPollerExtendedReadMultipleBlocks.

eg:-

 

 

err = rfalNfcvPollerExtendedReadMultipleBlocks(flags, NULL, blockNum, 75, rxBuf, 2050, &rcvLen);

 

 

In the above code, I am trying to read 75 blocks. This api returns ERR_NOMEM.

What is the maximum data I can read from the tag in a single fn call?

Also, the code breaks if the "numOfBlocks" is more than 75 in the above api. The reason found is that this will call the function st25r3916ReadFifo() with parameter buf as NULL and it is causing issue in my code.

 

andy_long_2-1708177876605.png

andy_long_1-1708177783756.png

Why is a NULL passed here ? What is an I2C api supposed to do when a NULL is passed ?

    This topic has been closed for replies.
    Best answer by Ulysses HERNIOSUS

    Hi andy_long,

    yes, please increase as much as you think good for you.

    Historically we considered it not really a use case to transfers such long frames. The gain of transferring one time 2K vs eight times 256bytes I expect to be rather marginal. And if a single bit flips in the 2K you need to re-transfer the whole thing.

    Pure transfer time for 2K at 26kbps: 630ms.  So if you assume an overhead of maybe 3ms for setting up a transfer this adds then 7*3 = 21ms additional time for the extra transfers.

     

    BR, Ulysses

    2 replies

    U
    Ulysses HERNIOSUS
    Technical Moderator
    February 20, 2024

    Hi  andy_long,

     

    For size limitations please see:

    https://community.st.com/t5/st25-nfc-rfid-tags-and-readers/getting-err-nomem-when-implementing-custom-quot-fast-read/m-p/166860#M3205 (3911 and 3916 are in this respect identical).

    I2C API in  case of NULL is supposed to read the number of bytes specified over the bus and just discard them in MCU.

     

    BR, Ulysses

    A
    andy_longAuthor
    Graduate
    February 20, 2024

    Thanks @Ulysses HERNIOSUS .

    The post says that the maximum supported size is 255 bytes.

     

     

     uint8_t codingBuffer[((2 + 255 + 3)*2)]; /*!< Coding buffer, length MUST be above 257: [257; ...] */

     

     

    Is it okay to increase 255 to 2048 ? 

    Also, it would have been nice if the size parameter was exposed to the user in any config.h file so that user can configure the size according to their application.

    U
    Ulysses HERNIOSUSAnswer
    Technical Moderator
    February 20, 2024

    Hi andy_long,

    yes, please increase as much as you think good for you.

    Historically we considered it not really a use case to transfers such long frames. The gain of transferring one time 2K vs eight times 256bytes I expect to be rather marginal. And if a single bit flips in the 2K you need to re-transfer the whole thing.

    Pure transfer time for 2K at 26kbps: 630ms.  So if you assume an overhead of maybe 3ms for setting up a transfer this adds then 7*3 = 21ms additional time for the extra transfers.

     

    BR, Ulysses

      Terms & ConditionsAccessibility statement