Skip to main content
PDiet
PDiet
Associate
January 23, 2019
Solved

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

  • January 23, 2019
  • 2 replies
  • 1749 views

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.

    This topic has been closed for replies.
    Best answer by Brian TIDAL

    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

    2 replies

    Brian TIDAL
    Brian TIDALBest answer
    ST Technical Moderator
    January 24, 2019

    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

    In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
      PDiet
      PDietAuthor
      Associate
      January 25, 2019

      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.

      Terms & ConditionsAccessibility statement