ISO 14443A - CR95HF - and the CRC bit

[Lon Glazner]

Posted on July 13, 2018 at 02:03

Hi everyone,

I have what I hope is a quick question about using an ISO14443A type 2 card with the CR95HF.

Page 53 of the CR95HF datasheet shows the output of an anticollision algorithm (copied below).  And I've implemented similar functionality using the CR95HF and an NTAG216 (NXP NTAG). 

In the responses in my system, and the CR95HF datasheet example, there is a 0x28 that sometimes follows the data received from the tag.  This byte seems to mean that there is a CRC error, and that the 'first byte' has 8 significant bits (page 22 of the CR95HF datasheet).  I have no idea which byte is the 'first byte', but assume it is related to collisions.

I'm most curious where the CRC error is occurring.  It seems to be ignored in the output of the anticollision example, as though it doesn't matter.  And there seems to be no CRC error associated with the Select 1 command (response is 0x08, not 0x28). 

I also see that the comments section says 'Note that collision information is only valid when bit ‘Collision is detected’ is set'.  So I'm pretty unclear on what these 3 bytes are supposed to be telling me and when what they are telling me is valid.

I was curious if anyone could shed some light on these last few bytes the CR95HF returns.  What do they really mean?

Thanks.

------ ISO14443-A STARTING ANTICOLLISION ALGORITHM ------

ISO14443-A REQA>>> CR95HFDLL_SENDRECV, 26 07<<< 80 05 0400 280000ISO14443-A ANTICOL 1>>> CR95HFDLL_SENDRECV, 9320 08<<< 80 08 08192D A29E 280000ISO14443-A SELECT 1>>> CR95HFDLL_SENDRECV, 937008192DA29E 28<<< 80 06 20 FC70 080000--> UID = 192DA29E , TAG selected

[NFC/RFID Customer support · Accepted solution]

Hi,

What you point here is the response of the CR95HF after a Send Receive commands (this answer embed the tag answer). This CR95HF command and his expected response are described in the chapter 5.5 of CR95HF datasheet page 25 and following pages. (please download the lastest version of the datasheet on www.st.com if needed).

Table 15 (page 28) describes the format of the response of the CR95HF transponder reporting a tag answer:

1st byte : 80

2nd byte : Length of CR95HF response

3rd byte : answer received from tag

...

N-2th byte (08 or 28) : informations for on Tag answer validity (Collision,CRC, Parity,Last byte format)

N-1th byte : first byte collision (only if N-2 bit 7 = 1)

Nth byte : first bit collision (only if N-2 bit 7 = 1)

(bytes N-1 & N have to be checked ONLY if bit 7 is set (Collision is detected))

Before sending back the Tag answer to the Host, the CR95HF calculates the expected CRC from the Tag answer (most of the time Tag answer = data + 2 bytes CRC) ... then sends the status of the CRC comparison in his response.

0x08 means no CRC error (the last 2 bytes of the tag response is the correct CRC of data), 0x28 means that the 2 last bytes of the tag response are not the CRC of the data (tag response - 2 last bytes).

In ISO14443-A RF protocol, a standart frame is most of the time, DATA + CRC. But some specifics commands have a response without CRC value (the 2 last bytes of tag answer are data ... no CRC). This is the case of WUPA, REQA and ANTICOL commands.

Issuing a SendReceive command , the CR95HF doesn't check which command is send, and in all cases, compute expected CRC and compare it to the last 2 bytes. This is the reason why the CR95HF indicates CRC error when this commands are sent.

I hope this will answer to your question,

Best regards

NFC/RFID Customer support

[Tesla DeLorean]

See Also https://community.st.com/s/question/0D53W000016PRpZSAW/crc-polynomial