ST25R95 Reboot Loop on Reading Tag

[PDIhawk]

I have been working on getting my Arduino based code running using an Arduino UNO SMD and the X-NUCLEO-NFC03A1 with the ST25R95.

I have good communication and can enable the ISO15693 protocol.

My next step is to read a tag and have implemented a SendRecv sequence of 0x0403260100. After sending the last data byte of that sequence, the processor reboots and loops this reboot every time it gets to the last data byte. I tried the example from the datasheet of 0x0403022000 and the same thing happens.

I checked power and found multiple issues.  First, I noticed that the X-NUCLEO-NFC03A1 board isn't completely compatible with the Arduino UNO because the 3.3V supply is tied to the IOREF pin.  On my UNO SMD, the IOREF pin is 5V and was back feeding 5V into the 3.3V regulator and pulling the whole 3.3V supply to 5V.  Thankfully the ST25R95 5V tolerant, so nothing is broken.

After bending back the IOREF pin so the NFC03A1 board doesn't see it, I found out that the 3.3V supply is only capable of 150mA.  Since the ST25R95 can pull up to 100mA during RX/TX, I was hitting the current limit and the 3.3V was significantly drooping.

I landed on bending the 3.3V pin on the NFC03A1 board to power it with the UNO 5V supply.  There is still a 0.1V droop but it is much better than the 3.3V supply.  I think this should still allow it to run but it is still stuck in a reboot loop when trying to do the SendRecv sequence.

What could I try next?

[liaifat85]

If possible, add some debugging output to your code to print out intermediate values or status information during the execution of the SendRecv sequence.

[PDIhawk]

Funny you should ask, here is a serial log:

Starting NFC Demo
SPI Begin
Boot NFC
Echo Check
Start Polling
14
Done Polling For: r
Dummy resp: 0x55
Good COMMs
Error byte 1: 0x0
Error byte 2: 0x0
Getting IDN
Start Polling
12
Done Polling For: r
RespCode: 0x0
len: 15

IDN: NFC FS2JAST4
Control Response: E
Command Response: E
ISO15693
Start Polling
12
Done Polling For: r
Error byte 1: 0x0
Error byte 2: 0x0
Start Loop
Interrogating Tag
Control Sent: 0x0
Control Response: 0xC
Command Sent: 0x4
Command Response: 0xC
Length Sent: 0x3
Response: 0xC
Data Sent: 0x26
Response: 0xD
Data Sent: 0x1
Response: 0xD
Data Sent: 0x0
Response: 0x9
StaStarting NFC Demo

View more

Directly after the response of the last data byte, the serial log should say "Start Polling" because it goes into the polling routine to check if the ST25R95 is ready to retrieve the data that it got from the tag.  However, it looks like it starts printing "Start Polling" but chokes at "Sta" and starts back at the beginning.

I believe the Polling routine works as it should.  Looking back at lines 5, 13, and 23 where I used it previously in the code shows it running without crashing.

[Brian TIDAL · Accepted solution]

Hi,

the X-NUCLEO-NFC03A1 is designed for 3V3. The IOREF (CN6.2) and the 3V3 (CN6.4) are internally connected. When a 5V IOREF is used on the MCU board, the IOREF pin should be bent to prevent injecting 5V to 3V3.

The  Arduino Uno Rev3 SMD can be supplied through the USB or through the VIN. I guess the USB is being used in your case.

Can you try to supply through the VIN with a lab supply?  See the Power chapter on the https://store.arduino.cc/products/arduino-uno-rev3-smd web page regarding the recommended 7V-12V range for VIN.

Rgds

BT

[PDIhawk]

Hi Brian,

I am a little bit at a loss right now.

I was powering off USB only but added an external power supply plugged.  It was only a 5.9V supply in and it wasn't helping probably because it was too low for the LDO on the UNO.

However, as I was playing around with some of the code, it just started working.  I don't know why any of the code changes would have fixed this reboot cycle, but, no matter what I do, I can't get it to go back into the reboot cycle.

I even unbent the 3V3 pin to the X-NUCLEO-NFC03A1 and it is running on the 3V3 of the UNO.

I don't feel completely comfortable with this because I don't know what fixed it but it appears to be working.  However, this is just evaluation hardware and I think that this was probably a hardware problem.

Next, I will want to try out another protocol.

Thanks!

-Andrew