2024-02-17 05:55 AM - edited 2024-02-17 05:55 AM
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.
Why is a NULL passed here ? What is an I2C api supposed to do when a NULL is passed ?
Solved! Go to Solution.
2024-02-20 04:29 AM
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
2024-02-20 12:53 AM
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
2024-02-20 03:09 AM - edited 2024-02-20 03:15 AM
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.
2024-02-20 04:29 AM
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