ST25R95 Reading Tags

PDIhawk · ‎2024-02-08

I am building on my Arduino based code for using the ST25R95.

I have successfully received data from an ISO15693 tag but I don't understand what it is reporting or what the data means that I sent with the SendRecv command to read from the tag. If it tells me in the datasheet, I don't see it.

With Brian Tidal's help, again, I send 0x0403260100.

Can you help me understand the data portion of what I am sending (0x260100)?

Also can you help me understand what I received back?

For instance, I receive: 0x00x00x280xFFFFFFEB0xFFFFFF900xFFFFFFF30x500x10x40xFFFFFFE00xFFFFFFF20x66
The serial number for that tag is 19:2D:5B:CA:50:01:04:E0

I am using an NFC Android app to get that Serial Number and I don't see a correlation with the data that I got back when reading with the ST25R95.

Additionally I would like to read from a ISO14443-A tag.

The datasheet recommends sending 0x04079370800F8C8E28, but again I don't understand the "data" aspect of what I am sending during the SendRecv command. Is this the correct sequence to send?

Ulysses HERNIOSUS · ‎2024-02-08

Hi,

this data is the NFC-V payload. You will find the details in ISO/IEC15693-3 or NFCForum Digital and T5T specs.

Likely you can also get details in the datasheet of the tag that you are using.

260100: 26: flag byte, 01: command inventory. etc.

If you want to implement everything from low level you will need to learn all these details. ST's RFAL driver also implement most of the necessary payloads and then you don't need to know all the details.

BR, Ulysses

PDIhawk · ‎2024-02-09

Hi Ulysses,

As you can tell, I am working on building my knowledge in NFC. I was under the impression that the data sent was specific to commands within the ST part.

Thankfully, I don't believe I need to implement everything from the low level, otherwise I would definitely be doing a rewrite and implementing ST's RFAL. I still might do that at some point but the end device only needs to be able to read one, maybe two different tags that are known ahead of time.

I am working on getting the datasheet of the tag/tags that will be used.

Thanks for your help!

PDIhawk · ‎2024-02-12

Hi Ulysses,

Are there any examples floating around out there on the using the STM32duino_ST25R95 library?

Edit Update: Nevermind. I just found the X_NUCLEO_NFC03A1_HelloWorld.ino example. I needed to modify a couple of things to compile on the UNO and found out that it GREATLY exceeds the space (Over 200%) on the UNO which has even more space than the ATTINY88 that I am targeting.

I will need to stay at the low level and use only the features that are needed to read the tags that I need to read and nothing more.

Right now I have my code looping the SendRecv command and I am getting some flaky performance. It doesn't immediately read the tag but after a couple of iterations of SendRecv, it will read a tag. After the tag leaves the field, the SendRecv runs a couple of times. When it goes to poll after those couple of times, the ST25R95 doesn't enable to ready to read bit and errors out after the 11 tries that I allow. On the reads, I pull out the second byte of the response and after the tag leaves the field, the length is usually read -120 once.

Is there a normal flow to reading tags?

For instance, should I be going to idle mode with tag detection instead of constantly running the SendRecv command, or does it matter other than current consumption?

Ulysses HERNIOSUS · ‎2024-02-13

Hi,

for NFC protocol you need to have a constant field on for >5ms. Could it be you are not guaranteeing the timing after the ProtocolSelect?

For the sequences, please try to follow what RFAL actually does. Potentially you can hard-code some frames, etc.

BR, Ulysses

PDIhawk · ‎2024-02-15

Hi Ulysses,

I have a 10ms delay built into my ProtocolSelect routine, so I am guaranteeing the guard time after setting the Protocol.

After looking into some of the RFAL, it looks like the device is in IDLE mode as a default. So I will be implementing an IDLE procedure with Tag Detection. This should probably solve some of the flakiness.

As far as reading the tags, I am finding it hard to figure out the correct commands to access the data that I need. The two tags that I am working with are the NTAG213 based ISO-14443-3A and the ICODE SLIX based ISO 15693.

I am able to get info from each tag but not the right info. Using an Android app, I can see that I need to access data at address 3 for the ISO 15693 tag and address 7 for the ISO 14443-3A tag.

I have looked at the datasheets for both and the ICODE SLIX refers me to the ISO standard and doesn't explain how to access specific data blocks. From what I understand of the NTAG213 datasheet, I should send 0x04, 0x06, 0x3A, 0x05, 0x08, 0x8E, 0x51, 0x28 (SendRecv, length, command, start address, end address, CRC_A, CRC_A, transmission flags) but I'm having issues.

Do you have any ideas of how I can access the specific data that I am trying to read on these two tags?

-Andrew

Ulysses HERNIOSUS · ‎2024-02-16

Hi Andrew,

I would propose that you have a look at stsw-st25r-lib and here at the STSW-ST25R017. If you get a NUCLEO-L474RG board you can run the examples there, e.g. NDEF demo which does read out the NFC Forum tags:

Inspect and instrument the code and look at the frames being exchanged with ST25R95.

BR, Ulysses

PDIhawk · ‎2024-02-16

Hi Ulysses,

Sounds good! My next move was going to be watching frames on a working device.

Is it the case that these commands for the NFC forum tags are behind a paywall and no one can share any part of it?

When I look for a NUCLEO-L474RG, I only find a NUCLEO-L476RG. Is that the correct board?

Thanks!

-Andrew

Ulysses HERNIOSUS · ‎2024-02-19

Hi Andrew,

sorry for my typo: Yes it is NUCLEO-L476RG.

Yes, nowadays NFC Forum specs need to be purchased or you need to be at least an associate member.

I assume details can also be found in some tag data sheets.

BR, Ulysses

PDIhawk · ‎2024-02-21

I have the ISO14443-A figured out.

The tag is in idle mode when it enters the field. One way to wake it up, is by issuing a REQA command {0x00, 0x04, 0x02, 0x26, 0x07}. Once it is out of idle, to read address block 7 data, I issue the READ command { 0x00, 0x04, 0x03, 0x30, 0x07, 0x28}. I was all worried about the CRC but it isn't necessary because the ST25R95 does it for you.

I will revisit the ISO15693 in a little while after I work on other aspects of the project.

Thanks!