cancel
Showing results for 
Search instead for 
Did you mean: 

ST25R95 Tag Detect Calibration Problems

PDIhawk
Associate III

I am using the X-NUCLEO-NFC03A1 board with the ST25R95 and an Arduino UNO as the development hardware.  I am not using libraries but I can currently read personal data from an ISO14443-A tag.

I believe I am on the final leg of my ST25R95 code and trying to implement Tag Detection Calibration.  I am failing to get past the first step of the procedure.  This step sets DacDataH at 0x00 and I should get a response of 0x00, 0x01, 0x02 telling me that it woke up from a tag.  However, I get an empty response from my idle command 0x00, 0x00, 0x00.  My polling routine seems to take longer on this response but it doesn't error out.

To start out the Calibration procedure I send:Screenshot 2024-02-21 134247.png

With every byte sent, I get the response of 0x06, so I think the ST25R95 likes the bytes I send.

In my code, I boot the ST25R95 by sending the RESET control and the IRQ pulse, then I do an Echo command to check communication, then I retrieve the IDN.  After IDN, I do a 10ms pause and jump into Tag Detect Calibration.  I read that Protocol doesn't matter, I don't do Protocol Selection.

What could I be missing?

This discussion has been locked for participation. If you have a question, please start a new topic in order to ask your question
1 ACCEPTED SOLUTION

Accepted Solutions
Brian TIDAL
ST Employee

Hi,

the trace shows that last frame (the Idle command with DacDataH = 0xFC) is incomplete: the last byte is missing.

Make sure to send the proper number of bytes.

Rgds

BT

 

 

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

9 REPLIES 9
Brian TIDAL
ST Employee

Hi,

the idle command is not correct. The <WUPeriod> should be 0x00 and the <WuCtrl> should be B801. See ST25R95/CR95HF wake up from tag detector without tags for the comprehensive calibration sequence.

Also, make sure to properly follow the startup sequence described in the DataSheet §3.2.

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
PDIhawk
Associate III

Hi Brian,

That is strange, I used the example in the datasheet and AN3433 to get that string of commands.

I changed <WUPeriod> to 0x00 and the <WuCtrl> to B801.  I now get 0x00, 0x06, 0x0C as a response and it doesn't make any sense to me because the length of data for the response shouldn't be more than 0x01 and the current response I am seeing is 0x06.  Not to mention, it still doesn't work.

Thanks!

-Andrew

Brian TIDAL
ST Employee

Hi,

using <WUPeriod>=20h increase the duration of the tag calibration whereas there is no real needs for such a period.

Do you properly wait for IRQ_OUT being low before reading the answer? Can you provide a logic analyzer trace (SPI CLK/MOSI/MISO/CS + IRQ_OUT + IRQ_IN) from power-on up to calibrate command?

Rgds

BT

 

 

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hi Brian,

Yup, my problem was that I wasn't waiting for IRQ_OUT.  I forgot that I need to rely on the IRQ_OUT signal when using the IDLE command and was relying on Polling.

This got me past the first check but now I am stuck on waiting for IRQ_OUT on the second step of calibration where I set DacDataH to 0xFC and it waits for the timeout response.  If I comment out this section, the calibration procedure completes and gives me 0x98 as a result. 

It also sounds like I need to get more familiar with my Analog Discovery.  Looking into it, there is a logging function.  What format do you need to review the trace? I can do a binary file, CSV and tab delimited TXT.

Thanks!

-Andrew

Brian TIDAL
ST Employee

Hi 

Binary and CSV should be fine.

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
PDIhawk
Associate III

Hi Brian,

I am still working to get a trace that includes IRQ_I and IRQ_O but I can at least share the SPI communication from boot.

This device has some pretty cool features that I didn't know about and I hope I can figure out how to capture the IRQ lines with the SPI soon.

Does the attached txt file help you to help me?

Thanks!

-Andrew

Brian TIDAL
ST Employee

Hi,

the trace shows that last frame (the Idle command with DacDataH = 0xFC) is incomplete: the last byte is missing.

Make sure to send the proper number of bytes.

Rgds

BT

 

 

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Wow, I see that now.  I had an error in the for loop that cycles through and sends the array containing the string of data for that second step of the Cal rouitine.

Now I get a result of 0x98.

The datasheets say that the dev board would likely use 0x64 for DacDataL and 0x74 for DacDataH.  Going off the recommendation of a 0x08 guard band, I would be at DacDataL of 0x90 and DacDataH of 0xA0.

Is that high for using the X-NUCLEO-NFC03A1 dev board?

Brian TIDAL
ST Employee

Hi,

the calibration value is influenced by the environnement. 0x7C is the usual value when the X-NUCLEO-NFC03A1 is plugged on a Nucleo-64 MCU board. In your application, the MCU board is different and therefore the calibration value can be different.

Rgds

BT

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.