How to initialise a CR95HF (from M24LR-DISCOVERY) for a M24SR02 in my project?

[Spencer.Andrew]

I am trying to configure the CR95HF (using either CR95HF.dll V0.9 or V1.2) to communicate with an M24SR02-Y, with an eventual view to read/writing NFC Forum Type 4 NDEF files. All I2C coding has been completed for "internal" access to the EEPROM/NDEF files. I now need to get things going from the RF interface.

I'm struggling to get information on the correct sequence of commands to be sent. In particular, the meaning of the various parameters and responses (e.g. the whole anti-collision algorithm) would be useful. The CR95HF datasheet gives examples (e.g I've tried to follow D.1.5), but I come unstuck with Anti-collision and RATS/ATS commands.

I can see that once past these, the remaining commands are very similar to the I2C commands.

Any help would be much appreciated!

[NFC/RFID Customer support]

Hello,

Using CR95HF development software (www.st.com search for "STSW-95HF001"), you will be able to drive the CR95HF and communicate with the M24SR02 IC.

I suggest you to watch the Log window at the bottom of the software. It will help you to understand the ISO14443-A anticollision process. Launch anticollision and follow the log to understand how it is managed. You can also read the ISO14443-3 specification that explain iso14443-A anticollision and ISO14443-4 specification that handles RATS command and parameters.

Just few words to help : one tag anticollision is quite easy to to :

• send REQA : 07 (7-bit data =  CR95HFDLL_SENDRECEIVE, 26 07)
  • M24SR tag response

send Anticol 1 command : 93 20 (CR95HFDLL_SENDRECEIVE, 9320 08)

• M24SR tag response (7 bytes UID) = 88 XX YY ZZ TT

send Select 1 command : 93 20 88 XX YY ZZ TT + CRC (CR95HFDLL_SENDRECEIVE, 937088XXYYZZTT 28)

• M24SR tag response (7 bytes UID) =04
• send Anticol 2 : 95 20 (CR95HFDLL_SENDRECEIVE, 9520 08)
  • M24SR tag response (7 bytes UID) = MM NN OO PP QQ

send Select 2 command : 95 20 MM NN OO PP QQ+ CRC ( CR95HFDLL_SENDRECEIVE, 9570MMNNOOPPQQ 28)

• M24SR tag response (7 bytes UID) =20

send RATS command : E0 80 + CRC (CR95HFDLL_SENDRECEIVE, E080 28)

• M24SR tag response

Now your chip is able be be manage as I2C protocol : 1st send Select Application, the Select file, etc .... .

Just for your information, a new software is also able to drive CR95HF board (www.st.com search for "ST25PC001").

An application note can help to develop your own software : www.st.com search for "AN3954"

Best regards,

RFID/NFC customer support

[Spencer.Andrew]

Thank you! This was a great help in getting me going along the right path. I've slowly added information from ST, NXP, TI, "NFC for dummies", nfc-tools.org and others.

I'd really appreicate it if you could give some comments/answers to these further questions though:

1) When setting the protocol, I use CR95HFDll_Select to send ‘02000280’. CR95HF.pdf has lots of examples sending ‘02000180’. Is this 02 = ISO/IEC 14443-A (Table 11), ‘00’ for byte 0 Parameters (Tx and Rx data rates) (Table 12), PP = ‘02’ and MM = ‘80’ ? If so, how would I best know PP and MM values?

2) The ATQA response that I get is : 80054200280000. This means 80 = OK, 05 = 5 bytes of data. Is the 280000 part of a CRC?

3) Replies to REQA, ANTICOL and SELECT commands normally come back with Error code '80'. I have encountered '90'. This seems to be defined in 4.3 and 4.4 of CR95HF.pdf, but the meaning of '90' is not really clear. (When I got '90' response, the last 3 bytes were not 280000 but 270000 or 260000)

4) Why does AN3954 Appendix A Table 1 show two bytes in the Error code column? It should surely only show the first byte. The second byte is typically the length. (There is also no '90' as encountered above)

5) I see that to actually get ISO/IEC 14443-3:2018, you have to pay CHF178. Wow!

6) The DLL offers CR95HFDll_STCmd as a "Transparent" command. Following the initial "01" (transparent command header byte) there appears to be a "command" byte. There appears to be no information on what the various options are - only two examples for RdReg (08) and Protocol Select (02)

7) I think there is a misstype in your "Select 1 command" line. It should read "93 70 88 XX YY ZZ TT", as detailed later in the same line.

8) With RATS : Your suggestion is E08028, example software sends E04028 and D.1.5 in CR95HF datasheet sends E05028. Where do I find reference for these values?

I have not looked at the PPS yet, so there will probably be more comments/queries......

Thanks!

[NFC/RFID Customer support]

Hello,

1) 0280 parameters are best configuration for CR95HF demo board and ISO14443-A.

2) Refers to datasheet page 29 table 15 :

80: result code Ok

05 : length of data (received data + 3 bytes control)

... received tag data

28: where 8=last byte length in bits and 2=CRC error

When receiving the tag answer , the CR95HF compare the 2 last bytes of the tag answer to the CRC calulation of the other byte. This bit is set if the 2 last bytes doen't match with calucaled CRC. The answer of Anticol123 commands and REQA/WUPA commands doesn't embed CRC. The CR95HF doesn't know that the Anticol123 commands and REQA/WUPA commands are sent (sendreceive is transparent mode), so it check CRC and rise CRC error bit. Don't care about this bit when sending this commands. Check ISO14443 specification to understand command and answer formats

00: index of first byte collision

00: idex of first bit of first byte collision

3last bytes are used to detect frame error or to manage anticollision process for multi tag (follow iso14443 specifications).

3) 90 code means that 270000 or 260000 : last byte has less then 8 bits (can occurs with error framing too)

4) 0000 and 8000 are mistakes in AN3954. For other error codes, 00 means that there is no additional bytes (length 0) after error code

5) !

6) No need to use CR95HFDll_STCmd, except using CR95HF PC Software and using commands already managed by it.

7) Yes

8) RATS is command from ISO14443-4 specifications.

Second byte first digit is the maximun number of bytes that a RF frame can support : 4=48 5=64 8=256. DLL 0.9 manage only up to 64 bytes (less USB framing) ... 48 is the best to use. DLL 1.2 and firmware 3.7 manage 256 bytes RF frames.

PPS is a command used to change Rx/Tx data rate (optional command when playing @106K/106K)

Best regards,

RFID/NFC customer support