ST25R95 Tag Read UID sequence

[PDIhawk]

I am developing a device that uses the ST25R95.  The end processor will be an ATTINY88 but for development purposes I am using an Arduino UNO and the X-NUCLEO development board.  I am developing the code in Arduino.  The main goal is to use the device in ISO15693 mode and read the value off of a tag.  In the future, I would like to try different protocols.

 

I have good communication because I am able to get a good response from the Echo command and I can retrieve the IDN.

However, I am not able to read the information from a tag.

 

On boot up, I run the ECHO command to make sure I have communication, read the IDN, setup the tag protocol, then start trying to read from a tag.

To set the tag protocol, I send 000202010D.

Is there some way to confirm what protocol the IC is using to make sure I set it correctly?

To try and read a tag, I send 000403260100.  If i don't send the first 00, I get a response of 136 which the datasheet tells me is a start of frame error.  Currently, I get a response code of 0x88.

Is there something else that I need to do to get the ST25R95 setup to read a tag?

[Brian TIDAL]

Hi,

For your information, there is an existing port of the ST25R95 RFAL middleware on Arduino. See https://www.arduino.cc/reference/en/libraries/stm32duino-st25r95/. This provides support of the various protocols (ISO14443A/B, NFC-F and ISO15693).

Regarding your question "Is there some way to confirm what protocol the IC is using to make sure I set it correctly?" : as soon as the device has returned 0x0000 after the protocolSelect command, you can assume that the protocol is properly selected. Using a scope, connect the gnd of the probe to the tip of the probe and put the probe in the field and you should be able to capture the field.

Regarding "To try and read a tag, I send 000403260100.  If i don't send the first 00, I get a response of 136 which the datasheet tells me is a start of frame error." Each SPI frame has to start with one the 4 control bytes defined in §4.1.1 of the ST25R95 datasheet. Sending a frame without the proper control byte causes unexpected result. Note that the error codes defined in §4.2 are only related to the various commands (IDN, protocolSelect, sendRecv, etc.) ; they are not related to wrong SPI control byte usage.

Regarding "Currently, I get a response code of 0x88" which tag is being used (manufacturer and model)? make sure to wait the proper GTv guard time before sending the first command after field on (typically GTv >= 5ms). I guess this is the cause of the 0x88 error code (i.e. the tag starts to answer but does not yet have enough energy inside its tank capacitor to send a full answer).

Here is the the typical sequence:

MOSI : MISO, MOSI : MISO, etc.
0 : 6,2 : 6,2 : 6,1 : 6,D : 6 // protocolSelect ISO15693
2 : E,0 : 0,0 : 0 // response 0x0000 = ok
<WAIT 5MS GUARD TIME>
0 : 6,4 : 6,3 : 6,26 : 6,1 : 6,0 : 6 //sendRecv Inventory
2 : C,0 : 80,0 : D,0 : 0,0 : 2,0 : C,0 : A2,0 : E6,0 : 1B,0 : 66,0 : 24,0 : 16,0 : E0,0 : EB,0 : EC,0 : 0 // Response

Rgds

BT

[PDIhawk]

Hi Brian,

I am aware of the ST25R95 RFAL Arduino port but I thought it is only valid with stm32 based boards.  I am using a plain old UNO that is based on the ATMEGA328P for purposes of code development, with the goal in my mind that it also has to work with my target of an ATTINY88.  So I'm not sure that, I am able to directly use that library.  I have dug through it and used it for reference but there are some intricacies that haven't been able to replicate yet with the Arduino Wire functions.

 

I believe I understand what you are saying in the sequence.

I was disregarding the responses but added some prints to print out the responses.  I am getting E as a response when I am sending 0, 2, 2, 1, D not 6.  What does that response mean?

 

I will also add the guard time and double check that I am sending the right commands.

Thanks!

-Andrew

[Brian TIDAL]

Hi Andrew,

I believe the ST25R95 RFAL Arduino port can be reused on non stm32 devices (the original C RFAL library is designed to be portable on different MCU).

Regarding your question "What does that response mean?": During an SPI Send command (0x00), the data on the MISO are not meaningful. The datasheet indicates XXXXXXXX for each MISO bytes and the content is unspecified. Anyway, one can easily guess that the response byte being used seems to be the flag response used in the polling response (see table 5 in the datasheet of the ST25R95). Having an xxxx11xx instead of xxxx01xx probably means that the answer of the previous command has not been fully read or a bit flip on the MISO or misconfiguration of the SPI. Make sure to have an SPI clock lower that 2MHz and CPOL=CPHA.

If my previous suggestion on the guard time solves your issue, do not hesitate to click on "Accept as solution" otherwise feel free to send me a logic analyzer trace (SPI + IRQ_IN + IRQ_OUT).

Rgds

BT

[PDIhawk]

I have a bunch of other projects going on right now and haven't had a chance to try these things.

I just want to give an update to keep this thread alive.

[PDIhawk]

Ok, I have my SPI set for 2MHz and SPI Mode 0, so CPOL=CPHA=0.

Spoiler

Arduino Code: SPISettings(2000000, MSBFIRST, SPI_MODE0)

Just narrowing the scope of my question down to setting the Protocol, I have captured the sequence of sending 0,2,2,1,D to setup ISO15693. MISO is responding C,C,C,D,D

 

the 0 is the first little box

I don't know why there would be such variability in the time between frames but I also don't know if it matters.

 

Even though MISO is responding differently than 6, I can put the scope loop by the antenna and measure the 13.56MHz field after sending this sequence.

 

[Brian TIDAL]

Hi,

as explained in my previous post, make sure to have a GTv Guard Time (>5ms) between the ProtocolSelect command that enables the field on and the first SendRcvd command. Then fill free to send me the raw file from the logic analyzer (make sure to include the startup sequence, the protocolSelect and the SendRcvd commands).

Rgds

BT

[PDIhawk]

Hi Brian,

I now have Guard Time, is it supposed to be 5s like you said in that last post or the 5ms that you said previously?

I am using an Analog Discovery by Digilent for my logic analyzer.  As far as I know, I can only really grab one sequence at a time like pictured and I don't believe I have any raw file to share.

I am now able to enable the ISO15693 because I get the 0x0000 response after setting it and I can see the 13.56MHz on my scope.

I think my main problem is that I wasn't initializing the ST25R95 properly.  To check communication, I run the Echo command and I was only getting a good Echo response if I cycle the power.  I added the Reset Control during initialization.  Now I get a good Echo response every time I boot and I successfully enable the protocol.

I added the SendRecv sequence that you mentioned above.  After sending the last data byte of that sequence, the processor reboots and loops this reboot.  I tried the example from the datasheet of 0x0403022000 and the same thing happens.

Any ideas?  Maybe this should be the start of a new thread?

Thanks!

[Brian TIDAL]

Hi,

sorry for the typo (I've fixed it): this is 5ms. 

Regarding the startup sequence, you may find useful information on this community (see for example https://community.st.com/t5/st25-nfc-rfid-tags-and-readers/cr95hf-error-0x71-spi-interface/m-p/329870)

Regarding the reboots, I would suggest to check the power supply and make sure there is no power drop when the ST25R95 starts to emit the field. If support is needed on this topic, I would suggest to create a new thread.

Rgds

BT