2019-01-15 07:34 AM
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.
Solved! Go to Solution.
2019-01-16 03:00 AM
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
2019-01-15 09:01 AM
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:
Rgds
BT
2019-01-15 11:06 AM
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
2019-01-16 12:22 AM
Specifying also that I have to call config for setting the protol before sending otherwise i will get error 87 everytime.
2019-01-16 03:00 AM
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
2019-01-16 03:10 AM
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
2019-01-16 05:37 AM
i only mentioned this because the example code sets the protocol when the type is detected but i still had trouble with it.
2019-01-16 05:41 AM
I did need read and write and having known nothing about nfcs i didnt really know some needed authentication and some didnt.
Tested with some other tags and they did indeed work without authentication.
Thanks for your help.