I am having difficulty reading tags

[Dcowa.1]

Hi,

I’m trying to use the CR95HF in what I think should be the simplest mode. Reading a 14443a tag.

I am controlling it from a pic micro. I have detailed exactly what I have done. Clearly the SPI is working but I am also missing something. Really appreciate it if somebody could have a look and suggest where I may have been going wrong. I know I have not been poling but I have been leaving quite a long time ( several seconds) between sending and attempting to receive. The board is bespoke but built according to ST recommendations. I have checked and there is a strong signal in the antenna.

1.      Reset

 Asserting Chip Select

Send 0x01

De asserting Chip Select

2.      Next I cyc le the /irq_in while SSI_0=1 and SSI_1=0 to select SPI mode

3.      To check the comms are working I do and IDN command

Assert Chip Select

Send 0x00                                                          Select direction from micro to CR95HF

Send 0x01                                                          Select IDN command

Send 0x00                                                        No additional bytes sent

De-assert Chip Select

Wait 1s

Assert Chip Select

Send 0x02

Get Data Length byte =0x0d

Get Data (13 times)

De-assert Chip Select

Result is correct “NFC FS2JAST4�?

4.      Next I need to select a protocol

Assert Chip Select

Send 0x00                                          direction from micro tom CR95HF

Send 0x02                                        set protocol command

Send 0x02                                        send 2 bytes

Send 0x02                                          select 14443A

Send 0x00                                          other parameter

De-assert chip select

Wait 1s

Assert chip select

Send 0x02                                          select direction from CR95HF to micro

Get byte                                           error code (0x00 as expected)

Get byte                                            No of bytes (0x00 as expected)

De assert chip select

5.      I programmed a 14443a tag using my phone with a string

6.      Next I tried to read it. It was placed on top of the loop

Assert the chip select

Send byte 0x00                               set direction from micro to CR95HF

Send byte 0x04                               send SENDRECEIVE command

Send byte 0x00                                no additional parameters

De-assert chip select

Wait 1s

Assert chip select.

Send byte 0x02                                set direction from CR95HF to micro

Read byte                                         comes back with 0x00 so no error

Read Byte                                        comes back with zero so no bytes were read

De-assert chip select.

[Brian TIDAL · Accepted solution]

Hi,

ST provides the X-CUBE-NFC3 firmware package for the CR95HF/ST25R95 device. It can be ported to many MCU including non ST MCU (as long as a ST reader device is used: see the licence agreement). The porting on other MCU can be achieved through the macros in platfom.h (only little effort needed). i would recommend to use this package rather than developing from scratch.

I see different issues in your trace

1. the read data from CR95HF (Control byte 0x02) is sent after a 1s timeout. This is not compliant with the communication protocol defined in the Data Sheet. You should either poll (control byte 0x03) for CR95HF readiness or wait for low level on IRQ_OUT. I recommend to use IRQ_OUT
2. the SendRecv (command 0x04) has no data, so no tag will respond. You should send a REQA (see exemple in table 16 of the Data Sheet e.g. 0x04022607)

Rgds

BT

[Dcowa.1]

I will have a look at the X CUBE.

I take your point regarding polling, I had assumed that by waiting long enough I could ignore polling because and leave a time so long that regardless the micro would have done all it was going to. I will implement polling but have no confidence it will help.

Am I correct in thinking that the memory on the device is static so once I have requested data in will be held until I read it or otherwise interrogate the device?

There is information which does not appear to be on the data sheet, like, for example, what do the numbers 2607 in your suggested command mean and where can I find this information?

[Dcowa.1]

I've had a look at the X Cube, and while I don't discount it, I'd really appreciate sufficient data to allow me to create a minimal interface. Adding such a library would really be quite a challenge for me.

[Brian TIDAL]

Hi,

2607: 0x26 is the ISO/IEC 14443-3 REQA command (see §6.4.1 in ISO/IEC 14443-3) sent in a short frame (7 data bits, thus the transmission flags is 0x07).

"Am I correct in thinking that the memory on the device is static so once I have requested data in will be held until I read it or otherwise interrogate the device?" I am not sure to understand your statement. The SendRecv is not a command to read the content of a tag but to exchange data with a tag in a command/response way.

If you want to create a minimal interface, you will have to implement the technology detection and anti-collision from the ISO/IEC 14443-3 standard. Then depending of your tag, you will have to implement READ/WRITE/SELECT SECTOR for Type 2 tags or ISO/IEC 7816-4 commands for Type 4 tags. In my opinion, porting the X-CUBE-NFC3 is probably simpler.

Rgds

BT

[Dcowa.1]

OK one more question. My application is such that it is not possible for 2 tags to be in close proximity to the reader. Is there a way to completely remove all anti-collision checks. (because I clearly don’t need them)
Thanks.
David Cowan
15 Hall Road, Nemphlar,
Lanark,
Scotland ML119JE
UK
01555664307

[Brian TIDAL]

Hi David,

I assume you will use a Type 2 Tag with a 7 bytes UID.

Before exchanging data with an ISO/IEC 14443 A tag, the reader has to set the tag in ACTIVE state:

PCD                                PICC
(Reader)                           (Tag)
 
---------------------------------------
 
REQA-->
                                <--ATQA
 
AC 
CASCADE L1-->
           <-- CT, UID0, UID1,UID2, BCC
 
SELECT
CASCADE L1-->
                                 <--SAK
 
AC 
CASCADE L2-->
           <-- UID3, UID4,UID5, UID6,BCC
 
SELECT
CASCADE L2-->
                                 <--SAK

Once SAK indicates that UID is complete, you can send Type 2 tag command such as Read or Write or Sector Select

Rgds

BT

[Dcowa.1]

Ok I think I am almost there. I got one of your discovery boards and that is showing very similar results to my bespoke board. These are the commands I send directly from the command log Setup Selecting 14443a tag >>> CR95HFDll_STCmd, 01 020402000280 <<< 0000 Setup the hardware (TimerW value) >>> CR95HFDll_STCmd, 01 09043A005804 <<< 0000 and (seting sensitivity and power) >>> CR95HFDll_STCmd, 01 0904680101d3 <<< 0000 Interaction with tag REQA: >>> CR95HFDll_STCmd, 01 04022607 <<< 80050400280000 ANTICOL1: >>> CR95HFDll_STCmd, 01 0403932008 <<< 8008CBBA6B756F280000 Select 1: The numbers in bold is the tag id. Add 9370 to the start and CRC (in bold)to the end and we get. The CRC was calculated using the CRC tool in your app. >>> CR95HFDll_STCmd, 01 040A9370CBBA6B756F535108 <<< 800608B6DD080000 Since this does not throw an error I am assuming the command and CRC are correct. I know if I change any bit of this command it does throw an error. and then just when I think I am getting somewhere I request the second anticollision. Which indicates that it does not recognise a TAG ANTICOL2: >>> CR95HFDll_STCmd, 01 0403950208 <<< 8700 Any suggestions??? If I am right this is the last stage before I can actually access the data on the tag. Thanks in advance. David Cowan 15 Hall Road, Nemphlar, Lanark, Scotland ML119JE UK 01555664307

[Brian TIDAL]

Hi David,

I was assuming your tag would have a 7 bytes UID. In such a case, the 7 bytes UID is segmented in Anticol1 response (CT, UID0, UID1,UID2) and Anticol2 response (UID3, UID4,UID5, UID6) with a specific CT marker in Anticol1 response.

It appears that your tag is a 4 bytes UID. In that case the 4 bytes are contained in the Anticol1 response (UID0, UID1,UID2, UID3 see line 9 below) and there is no need of a second level of anti-collision. After the Select1, the SAK response is 0x08 (see line 13) which means UID complete :

Interaction with tag
REQA
26                 ---->
                      <---- ATQA 
                            0400
 
ANTICOL1
9320               ---->
                      <---- CB BA 6B 75 6F 
Select 1:
9370CBBA6B756F(5351)---->
                      <---- SAK 
                            08(B6DD)
                            UID complete

So basically, you have succeeded. You can now issue Type 2 command to the tag.

Rgds

BT

[Dcowa.1]

I’m sorry, I have scoured all of the data sheets I can find.... but no luck.
I really appreciate your time but could you just give me a command or series of commands which would access (read) a specified part of the tag memory and tell me what the bytes mean.
Also, can you recommend any publication which gives a clear description of these things.
David Cowan
15 Hall Road, Nemphlar,
Lanark,
Scotland ML119JE
UK
01555664307