rfalNfcvPollerExtendedReadMultipleBlocks () returns RFAL_ERR_NOMEM

Daan1 · ‎2024-07-26

Dear Team,

Under what scenarios does the api rfalNfcvPollerExtendedReadMultipleBlocks () return RFAL_ERR_NOMEM ?

I am reading a maximum of 15 blocks always and the flags is RFAL_NFCV_REQ_FLAG_DEFAULT.

Most of the times this works as expected and it fails rarely (example: 1/100 times). Could you please tell the scenarios this could happen ?

RFAL version used is 2.8.0

regards,
Daan

Ulysses HERNIOSUS · ‎2024-07-26

Hi Daan,

if this happens at a low rate then I suspect an analog issue, maybe also position dependent.

This could happen if the demoduator/stream mode decoder produces more bits as expected. You would need to analysis (maybe based on SPI traces) the number of bytes received.

If you find a position dependence than maybe you could just reduce the default gain a bit.

BR, Ulysses

Daan1 · ‎2024-07-26

Hi @Ulysses HERNIOSUS ,

By 'position dependence', do you mean the distance between the reader and the tag ? It is kept very close (it does touch each other).

"If you find a position dependence than maybe you could just reduce the default gain a bit."

How can we know the issue is because of the position dependence ?

Few more observations:

There is a retry mechanism (5 times) if the api fails. In this case, it fails all the 5 times with the same error code.
When the api fails, the read buffer has the following values: 0x00, 0x02, 0x1D, 0x00, 0x02

Ulysses HERNIOSUS · ‎2024-07-26

Hi Daan,

just move 1 or 2cm further away, if you get then 100% success then it looks analog and obviously position dependent.

The buffer you are showing is already some of the decoded data (decoding likely in SW). I think you would need to go one level deeper and observe the bytes received from FIFO of the reader chip. Which chip are you using? Which demo, or your own board? Own antenna?....

BR, Ulysses

Daan1 · ‎2024-07-26

just move 1 or 2cm further away, if you get then 100% success then it looks analog and obviously position dependent.

I will try this.

Which chip are you using? Which demo, or your own board? Own antenna?....

ST25R3916 with our own board. Antenna is TAOGLAS - FXR.2020.A 2239. Tag is st25tv16k

The buffer you are showing is already some of the decoded data (decoding likely in SW).

The received length from the api was 5 and the data is 0x00, 0x02, 0x1D, 0x00, 0x02. The response flag is 0x02 which means error detected as per the datasheet, and the error code makes no sense

I think you would need to go one level deeper and observe the bytes received from FIFO of the reader chip.

Does this buffer "gRFAL.TxRx.ctx.rxBuf" give enough information ?

Ulysses HERNIOSUS · ‎2024-07-31

Hi Daan1,

what is the good response and what is the bad response?

As SOF will be truncated I presume the response flag is the 0x00 followed by 1 EEPROM word.

You will need to debug around the code line

gRFAL.TxRx.status = RFAL_ERR_NOMEM;

Look at gRFAL.fifo.bytesTotal, possibly read out the remaining bytes in FIFO and inspect them. See what happens if you don't set the error RFAL_ERR_NOMEM. If everything works, then I presume some modulation after the EOF being received.

BR, Ulysses