Skip to main content
V
Vyacheslav Popov
Visitor II
September 30, 2019
Solved

CR95HF periodic card detection problem

  • September 30, 2019
  • 2 replies
  • 898 views

Hi there.

Sometimes I receive form CR95HF result which I can't interpret.

Here is full dump of data exchange:

(TX) 02 02 00 00

(RX) 00 00

(TX) 02 02 01 00

(RX) 00 00

(TX) 02 02 00 00

(RX) 00 00

(TX) 02 02 01 00

(RX) 00 00

(TX) 02 07 02 00 00 00 00 02 02

(RX) 00 00

(TX) 09 04 3a 00 5a 04

(RX) 00 00

(TX) 09 04 68 01 01 df

(RX) 00 00

(TX) 04 02 26 07

(RX) 80 05 44 00 28 00 00

(TX) 04 03 93 20 08

(RX) 80 08 88 04 15 24 bd 28 00 00

(TX) 04 08 93 70 88 04 15 24 bd 28

(RX) 80 06 04 da 17 08 00 00

(TX) 04 03 95 20 08

(RX) 80 08 8a 16 3c 81 21 28 00 00

(TX) 04 08 95 70 8a 16 3c 81 21 28

(RX) 90 05 00 1e 25 00 00

(TX) 04 08 95 70 8a 16 3c 81 21 28

(RX) 87 00

The question is what means message 90 05 00 1e 25 00 00 in response. And in which cases message (0x90) with not integer bytes of data is receive from CR95HF? How to correct handle this message?

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

    Hi,

    in ISO/14443, Anticollsion frames are bit oriented. Therefore, a non integer amount of bytes can be received (see case SPLIT BYTE in ISO14443-3 standard). In that case a 0x90 Response Code is returned.

    0x90 response code is also returned when a type 2 tag sends a 4-bits ACK or NACK reply.

    0x90 response code can also be returned when a tag sends a partial answer (RF loss or power loss on tag side).

    For Anticollision frames, the total length (part 1 from the PCD + part 2 from the VICC) shall be 56. As per NFC Forum Digital Protocol Technical Specification 2.0 requirement 6.7.2.12, invalid part 2 length shall be treated as a syntax error. This is the likely case here (seem the tag started to sent the SAK and 5 bits of the CRC before stopping replying).

    When a 0x90 reply is received, you can retrieve the number of valid bits of the last data byte thanks to the 3 additional bytes (e.g. 25 00 00 --> 5 valid bits). See ST25R95 datasheet table 17. In case of Anticollision frame, you can then compute the length of the part 2 and behave accordingly.

    For your information, X-CUBE-NFC3 v2.0.0 fully manage 0x90 response code. Do you use your own driver or the X-CUBE-NFC3 v2.0.0 library?

    Rgds

    BT

    2 replies

    B
    Brian TIDALAnswer
    Technical Moderator
    September 30, 2019

    Hi,

    in ISO/14443, Anticollsion frames are bit oriented. Therefore, a non integer amount of bytes can be received (see case SPLIT BYTE in ISO14443-3 standard). In that case a 0x90 Response Code is returned.

    0x90 response code is also returned when a type 2 tag sends a 4-bits ACK or NACK reply.

    0x90 response code can also be returned when a tag sends a partial answer (RF loss or power loss on tag side).

    For Anticollision frames, the total length (part 1 from the PCD + part 2 from the VICC) shall be 56. As per NFC Forum Digital Protocol Technical Specification 2.0 requirement 6.7.2.12, invalid part 2 length shall be treated as a syntax error. This is the likely case here (seem the tag started to sent the SAK and 5 bits of the CRC before stopping replying).

    When a 0x90 reply is received, you can retrieve the number of valid bits of the last data byte thanks to the 3 additional bytes (e.g. 25 00 00 --> 5 valid bits). See ST25R95 datasheet table 17. In case of Anticollision frame, you can then compute the length of the part 2 and behave accordingly.

    For your information, X-CUBE-NFC3 v2.0.0 fully manage 0x90 response code. Do you use your own driver or the X-CUBE-NFC3 v2.0.0 library?

    Rgds

    BT

    V
    Vyacheslav PopovAuthor
    Visitor II
    October 2, 2019

    Thank you for your helpfull answer.

    At the moment used some ST library (I do not know which one. 2015 year in files header). Additionaly I tried to look Linux driver for СR95HF from ST site, but it not handle 0x90 messages too.

    I will try to use X-CUBE-NFC3 v2.0.0 library. Thank you!

    Terms & ConditionsAccessibility statement