2019-11-29 04:48 AM
I am working with Mifare Ultralight Ev1 (Iso14443A Type 2 tag). NFC Reader is CR95HF.
When I execute this command I get different answers. At first I only checked on if the answer started with 80, so they both succeed. However now I am getting in more detail on how answers work, and I see that sometimes I get a long response while at others I get 8000.
Example:
---------CR95HFDll_SendReceive strRequest:
---------952008
---------CR95HFDll_SendReceive strAnswer:
---------8000
---------CR95HFDll_SendReceive strRequest:
---------952008
---------CR95HFDll_SendReceive strAnswer:
---------80085A734D80E4280000
What causes this difference in response and what does it mean?
-------------------------------------------------------------
Also I am getting into CRC. I see that sometimes response ends with 280000, but it seems the command has been executed properly. Should I always retry unless the answer ends with 080000?
Solved! Go to Solution.
2019-12-03 05:05 AM
Hi,
MB1054B is the latest revision of the board with the latest revision of the CR95HF (NFC FS2JAST4). Only the MCU FW needs to be updated from 3.6.0 to 3.7.1 thanks to the STSW-M24LR007 package.
Rgds
BT
2019-12-02 02:37 AM
Hi,
would you please share more details about your setup:
9520 is ANTICOLLISION Level 2 Command. As bit oriented anticollision frame does not include a CRC, the CRC error bit in the information bytes is always 1 and is not meaningful (i.e. has to be ignored). Therefore information bytes 280000 means no collision, full 5 bytes received from the tag.
8000 answer is not common for ANTICOLLISION commands. It looks like the tag has started to reply to the Anticollision command but has not completed. I would suggest to manage this case as a timeout or an error.
Rgds
BT
2019-12-03 01:08 AM
Hi, thank you for your response.
I work with my own C++ driver based on the ST CR95hfDll file.
The NFC reader is the CR95HF.
When I execute the getHardwareVersion I get 00074D423130353478.
When I execute the getDLLRev I get 1.2
When I execute the getMCURev I get 0003030600
I am working with a genuine Mifare Ultralight EV1 NFC tag. The UID is 044AE45A734D81
The Anticollision sequence is as follows:
>> 2607
<< 80054400280000
>> 932008
<< 800888044AE422280000 (but sometimes 8000)
>> 937088044AE422E08208
<< 800604DA17080000
>> 952008
<< 80085A734D81E5280000 (but sometimes 8000)
>> 95705A734D81E5AD1B08
<< 800600FE51080000
However this isnt only in this command. For example in read commands (for example 300628) at one time I get 8000 (so no data read) at other times a full response with the data read and 080000 or 280000 at the end.
8000 answer is not common for ANTICOLLISION commands. It looks like the tag has started to reply to the Anticollision command but has not completed. I would suggest to manage this case as a timeout or an error.
I will, thank you :) .
2019-12-03 01:34 AM
Hi,
"When I execute the getMCURev I get 0003030600" ==> The MCU revision is 3.6.0. I would suggest to update to the latest one (3.7.1). See STSW-M24LR007 Firmware for RF transceiver board included in the M24LR-DISCOVERY kit.
Can you also
Thanks
Rgds
BT
2019-12-03 02:44 AM
Its MB1054B.
The response of the IDN commaned is
"000F4E4643204653324A41535434002ACE"
which is equal to your assumed response.
2019-12-03 05:05 AM
Hi,
MB1054B is the latest revision of the board with the latest revision of the CR95HF (NFC FS2JAST4). Only the MCU FW needs to be updated from 3.6.0 to 3.7.1 thanks to the STSW-M24LR007 package.
Rgds
BT