Why does my CR95HF respond with 0x87 (timeout or no tag) after successfully writing to a NTAG216 NFC Forum Type 2 compliant Tag

[PDiet]

We use a CR95HF on our system and communicate with it using SPI. I've already successfully selected a NFC216 tag, read its UID and can read its memory. I'm using the ISO-14443-A protocol and don't make any adjustments to the CR95HF's registers.

Writing to memory using the NFC WRITE (0xA2) command

>>> 0x0407a20ddeadbeef28
<<< 0x87 (timeout or no tag)

fails with error 0x87, despite data being successfully written to the tag.

Instead using the NFC COMP_WRITE (0xA0) gives similar results:

>>> 0x0403a00d28
<<< 0x90040a240000 (ACK)
>>> 0x0411deadbeef00000000000000000000000028
<<< 0x87 (timeout or no tag)

However, the data was written in both cases:

>>> 0x0403300d28
<<< 0x8015deadbeef000000000000000000000000b244080000

Is this expected behavior? According to the NFC Forum Type 2 Tag specification, the tag should respond with ACK after a successful write.

[Brian TIDAL · Accepted solution]

Hi Peter,

the ACK reply is sent by the tag after a certain delay called TACK. The maximum value of this TACK delay is specified in the tag datasheet from the tag manufacturer.

On CR95HF side, the Frame Delay Time has to be adjusted to wait for this maximum TACK delay. If the FDT is too small, a timeout error (0x87) will occur.

The FDT can be modified through the PP:MM:DD parameters of the ProtocolSelect command.

As an example, with PP=0x00, MM=0x21, DD=0x00, FDT = 10ms.

Let me know if using those values fixes your timeout issue.

Feel free also to share more details about your issue such as:

• what are the values of the ProtocolSelect parameters
• do you use ST library or your own implementation of the CR95HF driver

Rgds

BT

[PDiet]

Hi Brian,

thank you! These values fixed my issue.

I'm using my own driver to communicate with the CR95HF.

I was using the following ProtocolSelect before (which selects the default FDT of 86/90μs):

>>> 0x02020200
<<< 0x0000

Using your values, my ProtocolSelect now looks like this:

>>> 0x02050200002100
<<< 0x0000

Now, I am able to correctly receive the tag's ACK response.