ST25R3916 FTM RF Message Read Failed

[ADant.1]

Hello,

I am using ST25R3916 based X-Nucleo-NFC06A1 with Raspberry-Pi to read data from ST24DC64KC tag (which is custom board) using FTM. I am able to read the message using  rfalST25xVPollerReadMessage(), But only if length is below 128. If I am trying to read message with length more than 128, I am getting ERR_RF_COLLISION. I am able to read same message using SR25R3916 Discovery Board.

What can I do to read complete FTM Message with length around 250 Bytes?

Thank you.

[Ulysses HERNIOSUS]

Hi ADant.1,

likely this is an effect of different RFAL versions being used. At some point we updated inside the RFAL the so-called codingBuffer to cope with longer NFC-V frames. 

Which versions of the software packages are you using? 

BR, Ulysses

[Ulysses HERNIOSUS]

Hi ADant.1,

after some discussion with  @Brian TIDAL in that case a different error should have been returned. Best if you can provide traces of SPI + IRQ for us to analyze. Could be related to code execution time or buffer issues as well.

Also does the issue also appear with say 240 bytes or immediately at 129 bytes?

BR, Ulysses

[ADant.1]

Hello Ulysses,

Previously I was using ST25R3916 version 2.1.0. As You suggested in first message, I updated the ST25R3916 version to 2.8.0 and modified it for my code. But the problem was not resolved.

Then I debugged the platform file for SPI. There in spiTxRx function, length parameter is defined with uint8_t.

For messages more then 128 bytes the FIFO(with is max 512 bytes) is more than 256 bytes and SPI message maximum length is 256 bytes. I updated length in spiTxRx  function to uint16_t and i was able to read/write message more than 128 bytes. now my question is;

Is there any particular reason for defining length parameter with uint8_t?

if No then in spiTxRx function length parameter should be updated to uint16_t.

Previous : HAL_statusTypeDef spiTxRx(const uint8_t *txData, uint8_t *rxData, uint8_t length)

Updated : HAL_statusTypeDef spiTxRx(const uint8_t *txData, uint8_t *rxData, uint16_t length)

Thank you and best regards,

Amrut Dant

[Ulysses HERNIOSUS · Accepted solution]

Hi Amrut,

no reason for this. In our STM32 based code this was already at 16-bit length.

Sorry for struggling with this. I repaired this in our code base and it will be integrated into new versions.

BR, Ulysses