ST25R95 Tag Detect Calibration Problems

[PDIhawk]

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:

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?

[Brian TIDAL]

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

[PDIhawk]

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]

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

 

 

[PDIhawk]

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]

Hi 

Binary and CSV should be fine.

Rgds

BT

[PDIhawk]

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]

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

 

 

[PDIhawk]

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]

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