ST25DV64KC: FTM: Mailbox buffer contains EEPROM data

[OpusOne]

Hello,

I'm developing a system based on a ST25DVxxKC (tag side) and a ST25R3916B (reader side) and I need to use the FTM feature.

This is what I'm currently testing:

- The reader detects the tag. (That part works fine.)

- When detected, the reader sends a message to the tag using FTM. (That part also works fine, at least no RFAL error.)

- The tag detects it (I set up GPO wtih RF_PUT_MSG_EN and  RF_GET_MSG_EN), the flag in IT_STS is RF_PUT_MSG as expected.

- The tag then reads the message length (MB_LEN_Dyn register) via I2C. The length is correct, it's the exact length of the message sent by the reader (in my case, 152 bytes).

- The tag then reads the mailbox buffer @address 0x2008. Successful, no NACK.

- But the content I read is NOT the data sent by the reader, but the first NDEF record that is stored into the tag's EEPROM (followed by zeroes).

This could be due to a bug on my side, but I don't explicitely read any EEPROM user data in this test, neither from the reader nor from the tag itself, so puzzled where this data could come from. What could explain this is if I actually read at the wrong user memory address, such as at address 0x0000 instead of 0x2008, but I double checked and reading dyn registers from 0x2000 to 0x2007 works fine with the same reading function.

I'm using RFAL 2.8.0 (which ships with en.x-cube-nfc6).

Any idea what could be wrong?

[OpusOne · Accepted solution]

Ok, I feel sorry now. This was a bug on my side. :D

I have a function which encapsulates reading the mailbox buffer, and in it, I was mistakenly casting the read address (which is the base address + the offset) to uint8_t, which just truncated it. (Probably from a habit to deal with 8-bit register addresses with many I2C devices.) So, indeed, it was reading at address 0x08... instead of 0x2008....

But the base 'register read' function was correctly sending a 16-bit address, which is why it worked for reading all dyn registers.

Yes, that happens to anybody. I guess.

Anyway, now it works great. Sorry again. :D

[Cedric Dalban]

Hello,

we are happy you eventually found the issue root cause and it works great.

It can happen indeed to anybody :D

best regards,

Cedric.

[OpusOne]

Hi, yes. Now, while working on bidirectional transfer with FTM, I have some feedback:

• The rfalST25xVPollerReadMessage() and rfalST25xVPollerFastReadMessage() from RFAL do return the mailbox message length + 1 (rcvLen parameter). The first byte returned in the buffer, as far as I have gathered, is the response flags of the NFC response. This isn't clearly documented. The doc merely states: "rxBuf: buffer to store response (also with RES_FLAGS)". I think the doc should be a bit more explicit about it.
• The ST25DVxxKC chips block any RF communication when I2C communication is active, and conversely. This point is documented in the datasheet, so it doesn't come as a surprise, but I think it's a limitation that turns out relatively unconvenient. I understand that some operations could not happen at the same time (like accessing the mailbox buffer from both RF and I2C at the same time), but reading some registers should be fine and that would be useful. As it is, it's pretty annoying - requires some "ad hoc" synchronization means with manual delays and/or retrying in a loop, which is kind of wasteful in many cases. Just a thought for maybe a future version of this chip.