What are the NAK value meanings for CR95HF?

[henryj]

I am using x-nucleo-nfc03a1 on the nucelo-f446re board and i can't figure out why i keep getting a NAK value of 04 when trying to use sendrecv function.

cr95hf's is always response: 90 4 4 24 0 0.

0A is defined in documentation as ACK and 00 as NAK and everything else falls under NAK, but i can't find any further specifications what might 04 or any other error mean.

[Brian TIDAL]

Hi Henry

the decoding of the response returned by the CR95HF to the SendRecv command is the following:

90 Result code: "Residual bits in last byte. Useful for ACK/NAK reception of ISO/IEC 14443 Type A."

04 Length of the complete data field (i.e. data received from tag + status and collision bytes)

04 Data received from tag

24 00 00 status and collision bytes:

24 = CRC error (due to absence of CRC, so error not meaningful) and 4 significant bits

00 00 collision bytes not meaningful as colision bit =0

So "04 " is the short frame 4-bits data returned by the tag to the command sent.

In case of a type 2 tag, this is a NACK answer returned by the tag. The meaning is not defined by the CR95HF but by the tag manufacturer. We recommend that you check in the tag documentation from the manufacturer the exact meaning of 0x04.

Feel free to also share more details such as:

• tag manufacturer and model
• command sent to the tag causing the NACK answer

Rgds

BT

[henryj]

Thanks for the reply.

I don't know the exact model, but based on the ATQA and SAK answers it should be a NXP mifare classid 1k tag.

NXPs docs say that 0x04 is an invalid operation, which doesnt help me much.

The same answer is returned from different tags as well, though they're mifare classics aswell (these i can id as mf1ics50 and mf1s50), so the problem could be with all mifares.

I am using the X-NUCLEO-NFC03A1 example code as the base and using this function from lib_nfctype2pcd.c for sending the data

command should be this, can't check anymore today:

DataToSend[0] = SEND_RECEIVE;//0x04

DataToSend[1] = Length; //3

DataToSend[2] = 0x30 ;// PCDNFCT2_READ

DataToSend[3] = 0; //blocknbr

DataToSend[4] = 0x28; //SEND_MASK_APPENDCRC|SEND_MASK_8BITSINFIRSTBYTE

should be this based on PCD_SendRecv function in lib_pcd.c

[Brian TIDAL]

Hi Henri

the tag you are using requires a proprietary authentication procedure before issuing any Read or write commands. Trying to send a Read command without having performed this mandatory step leads to receiving a NACK answer from the tag.

Such tags are not Type 2 compliant and the proprietary authentication is not available from ST.

If your want to simply perform Read/Write commands, Type 2 compliant tags will fulfill your needs.

Feel free to gives us more details about your application so that we can help you to choose the most appropriate protocol and most appropriate tag from ST portfolio.

Rgds

BT

[Brian TIDAL]

Hi Henri,

This is a normal behavior as explained in CR95HF Datasheet §5.5 "Before sending this command, the Host must first send the ProtocolSelect command to select an RF communication protocol"

After the startup sequence, the CR95HF is in Ready state. In this mode, the RF is OFF and the CR95HF waits for commands (e.g. ProtocolSelect). Once the ProtocolSelect is done, the CR95HF enters in Reader mode where communication with a tag is possible.

See https://www.st.com/resource/en/datasheet/cr95hf.pdf

Rgds

BT

[henryj]

i only mentioned this because the example code sets the protocol when the type is detected but i still had trouble with it.