CR95HF ISO14443A stop reading one card and read another

[Philip Lane]

I am using a CR95HF chip with ISO14443A cards. I can select the card, read it's UID and all the data storred on the card without any errors.

The problem is when I remove one card out of the field and place another card in the field, it refuses to respond. The only way I can get it to respond to the next card is to reset the chip.

Both cards are functional, the first card is allways read ok, but the second card allways errors no matter which card I scan first.

Is there a "deselect" command ?

Also what are the responce codes ? (section 5.1 of the datasheet). i.e. you send a command to the chip and get a responce code back. i.e. I think 0x87 is "bad length parameter"

Thanks!

[Brian TIDAL · Accepted solution]

Hi Philip,

I would suggest you use ST X-CUBE-NFC3 library: this provides the technology detection procedure, the anticollision procedure , etc. The porting effort should be limited as your SPI communication is already operational. The demo included in this package is able to read several tags and we do not have issues to read a second tag after a first one.

Anyway, would you please send me the traces of the Command you sent to the CR95HF with the answer from the CR95HF? I will have a look.

Rgds

BT

[Philip Lane]

Here is a complete transcript od the process :

cr95hf_Select_protocol()

Tx : 00 02 02 02 00

Rx : 0E 00 00 00 00 00 00 00 00 00

--- Polling---

Tx : 00 04 02 26 07 00

Rx : 0D 80 05 44 00 28

--- Reading---

cr95hf_read_card()

Tx : 00 04 06 09 04 3A 00 58 04

Rx : 0C 00

Tx : 00 04 06 09 04 68 01 01 D1

Rx : 0C 00

Tx : 00 04 02 26 07 00 00

Rx : 0D 00 80 05 44 00 28

Tx : 00 04 03 93 20 08

Rx : 0C 00 80 08 88 04 C1 BD F0 28 00 00

Tx : 00 04 08 93 70 88 04 C1 BD F0 28

Rx : 0C 80 06 04 DA 17 08 00 00 00 00 00

Tx : 00 04 03 95 20 08

Rx : 0C 80 08 FA 2D 61 80 36 28 00 00 00

Tx : 00 04 08 95 70 FA 2D 61 80 36 28

Rx : 0C 80 06 00 FE 51 08 00 00 00 00 00

UID : 04 C1 BD FA 2D 61 80

Tx : 00 04 03 30 00 28 2D 61 80 36 28 00 00 00 00 00 00 00 00 00 00 00 00 00

Rx : 0D 80 15 04 C1 BD F0 FA 2D 61 80 36 48 00 00 E1 10 06 00 5F 4F 08 00 00

Tx : 00 04 03 30 03 28 2D 61 80 36 28 00 00 00 00 00 00 00 00 00 00 00 00 00

Rx : 0D 80 15 E1 10 06 00 03 2D D1 01 29 55 04 79 6F 74 6F 2E 56 2A 08 00 00

Wait for card to go...

cr95hf_read_card() - [done]

UID and data have been read, how do I now detect when the card has been removed and place the chip into a suitable mode to listen for a new card ?

[Brian TIDAL]

Hi Philip

my comment

Tx : 00 02 02 02 00 ProtocolSelect ISO14443A 106kbps

Rx : 0E 00 00 00 00 00 00 00 00 00 Should be 00 00 only. Why do we have trailing 00? Only <Len> bytes should be read after <RespCode><Len>

--- Polling---

Tx : 00 04 02 26 07 00 REQA

Rx : 0D 80 05 44 00 28 ATQA

--- Reading---

cr95hf_read_card()

Tx : 00 04 06 09 04 3A 00 58 04 What's this?

Rx : 0C 00

Tx : 00 04 06 09 04 68 01 01 D1 What's this?

Rx : 0C 00

Tx : 00 04 02 26 07 00 00 REQA

Rx : 0D 00 80 05 44 00 28 ATQA

Tx : 00 04 03 93 20 08 ANTICOLLISION

Rx : 0C 00 80 08 88 04 C1 BD F0 28 00 00 ANTICOLLISION response

Tx : 00 04 08 93 70 88 04 C1 BD F0 28 SELECT LEVEL1

Rx : 0C 80 06 04 DA 17 08 00 00 00 00 00 SAK UID not complete

Tx : 00 04 03 95 20 08 ANTICOLLISION

Rx : 0C 80 08 FA 2D 61 80 36 28 00 00 00 ANTICOLLISION responsz

Tx : 00 04 08 95 70 FA 2D 61 80 36 28 SELECT LEVEL 2

Rx : 0C 80 06 00 FE 51 08 00 00 00 00 00 SAK (T2 tag)

UID : 04 C1 BD FA 2D 61 80

Tx : 00 04 03 30 00 28 2D 61 80 36 28 00 00 00 00 00 00 00 00 00 00 00 00 00 READ. Why do we have trailing stuff (underlined)?

Rx : 0D 80 15 04 C1 BD F0 FA 2D 61 80 36 48 00 00 E1 10 06 00 5F 4F 08 00 00

Tx : 00 04 03 30 03 28 2D 61 80 36 28 00 00 00 00 00 00 00 00 00 00 00 00 00 READ

Rx : 0D 80 15 E1 10 06 00 03 2D D1 01 29 55 04 79 6F 74 6F 2E 56 2A 08 00 00

Wait for card to go...

cr95hf_read_card() - [done]

As per NFC Forum Type 2 Tag Technical specification § 5.7 : The Reader/Writer MAY check whether a T2T is still present in the Operating Field by sending a READ Command with BlNo = 0 for the active sector, waiting for at least 200ms between 2 consecutive commands.

So you just need to send SendRecv commands with a T2T READ BlNo=0 until you receive 87 00 EFrameWaitTOut answer. Then you send a ProtocolSelect (FieldOff command) and wait for a tFIELD_OFF duration. Then you can restart the technology detection and the anticollision procedure.

I am just curious about why you prefer not to use our RFAL library. Any particular reason?

Rgds

BT