Do I need to worry about interface arbitration?

[TimLong]

I'm working on code that uses the Windows DLL that came with the "Discovery kit for the ST25R3916B" and ST25DV04K tags.

The tag is hosted within an embedded system, and I'm working on Windows PC software that communicates with the EVAL boards/reader.

In the tag data sheet I noticed a section titled "interface arbitration" that seems to imply that the RF and i2c inbterfaces are mutually exclusive. This potentially has some rather interesting implications.

Is this something I need to worry about when using the DLL in Windows, or is it all handled correctly by the DLL? Since there is neither source code nor documentation for the DLL I cannot determine this for myself, but I suspect I might be running into some issues when the tag is hosted by a slower device.

Regards,

Tim long

[Ulysses HERNIOSUS]

Hi TimLong,

The DLL from ST25R3916B ends for NFC-V with interfaces doing single NFC frame transceives. The interface arbitration of RF vs I2C is one layer above so the responsibility of your application code.

BR, Ulysses

[TimLong]

OK good, thanks. That's good to know.

What I'm seeing in my code is that at some point I don't get a reply, and often a nonsensical error code such as "no memory". I _presume_ that is the clue that interface arbitration has occured. What would I need to do to recover from that situation, because simply re-trying doesn't seem to work. For example polling the mailbox control register to see if the host has put a message into the mailbox - my code retries in a loop and just keeps trying forever never getting any reply. So I'm thinking maybe I would need to take some remedial action, but I haven't found any clues as to what that might be or even whether I'm on the right track here.

Thanks again for your help and experience.

Tim Long

[Rene Lenerve · Accepted solution]

Hi TimLong,

Reader cannot receive the information from the tag that I²C is currently exchanging data with the chip, the only information you will received in that case is an error code of 0x0F.

So, you need to manage it from I²C side.

If you just want to wait until ST25DV is available for I²C communication you can poll with a device select command only until you received an ACK (when RF is busy you'll received a noACK). You can managed that also with the GPO by reading the level of that pin if you configure the RF_ACTIVITY or use an interrupt on the MCU by using RF_INTERRUPT configuration.

In your description, you seemed to use the mailbox feature, so if you want to know when a message is available in the mailbox written by the RF, you can use the RF_PUT_MSG / RF_GET_MSG option from the GPO configuration.

There is a paragraph that described this topic in the Datasheet (5.1 Fast transfer mode).

Be careful that polling with I²C too often (or sending permanently I²C commands) may limit the access on RF side. That imply using GPO interrupt will help when you use both interfaces.

Kind Regards.