cancel
Showing results for 
Search instead for 
Did you mean: 

ST25R95 Jumps out of IDLE without tag - Custom Hardware

PDIhawk
Associate III

I am working off of Custom Hardware using the ST25R95 and I can read tags but I am trying to keep the device into IDLE mode but can't get it to work.

I have ran tag detect calibration without a tag in the field and came up with a result of 0x5C. (See attached Traces from boot)

I used 0x5C as the base for IDLE mode and use the +/-0x08 to setup the thresholds.

Using 0x5C, the device keeps telling me that there is a tag and starts to read a tag, goes into IDLE and repeats without a tag in the field. (See attached Traces from boot).

Do you have any ideas why this will not stay in IDLE?

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 IDLE command is erroneous:

BrianTIDAL_0-1709800801309.png

the command contains only 07 and then zeroes.

Therefore, the device does not enter into WFE mode.

I've seen also a second issue: the protocolSelect(fieldOFF) command is erroneous and the device replies 0x82 00 (invalid length).

BrianTIDAL_1-1709801038156.png

BrianTIDAL_2-1709801134147.png

The proper command is 00  02020000 (the example in the Datasheet is obviously erroneous).

Also, I've seen that the SPI CS signals seems to stay low for more than 4ms after the sending of the  ProtocolSelect command (between event 11 and 12 in the SPI_monitor_Leaves_IDLE trace). This is not erroneous but just an odd behavior.

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

3 REPLIES 3
Brian TIDAL
ST Employee

Hi,

the IDLE command is erroneous:

BrianTIDAL_0-1709800801309.png

the command contains only 07 and then zeroes.

Therefore, the device does not enter into WFE mode.

I've seen also a second issue: the protocolSelect(fieldOFF) command is erroneous and the device replies 0x82 00 (invalid length).

BrianTIDAL_1-1709801038156.png

BrianTIDAL_2-1709801134147.png

The proper command is 00  02020000 (the example in the Datasheet is obviously erroneous).

Also, I've seen that the SPI CS signals seems to stay low for more than 4ms after the sending of the  ProtocolSelect command (between event 11 and 12 in the SPI_monitor_Leaves_IDLE trace). This is not erroneous but just an odd behavior.

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.

Wierd. I don't understand why the IDLE command is almost all zeros.  It must be the for() loop that i am using to spit out the IDLE commands because I send out the Control Send, the Command Idle, then use a for() loop to send out an array holding the rest of the bytes.  For troubleshooting, I sent out the bytes without the for() loop.  Now the trace is showing the correct bytes and the device stays in IDLE.  It doesn't jump out of IDLE with a tag in the field but that is for another thread if I can't figure it out.

I also implemented the Field OFF command that you mentioned above and it is happy about that.

As for the Chip Select being held low for 4ms after, I can't see a reason for that.  I don't have any delays built in after sending bytes and releasing the CS.

Thanks for your help again!!

Brian TIDAL
ST Employee

Well done! The logic analyzer should also help you in your future investigations.

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.