cancel
Showing results for 
Search instead for 
Did you mean: 

X-NUCLEO-NFC03A1 Send Receive Command not detecting RFID tag

ClosedBridge
Associate II

Hello,

I'm using the X-NUCLEO-NFC03A1 dev kit with the CR95HF RFID chip. The protocol to talk to the chip I'm using is SPI, and the ISO configured is 15693. I can confirm SPI comms are working as both the ID and ECHO commands work. I also seem to get the correct response from the chip with the protocol is selected and configured for 15693. Unfortunately it seems like RFID tags are not getting detected. 

I can confirm the RFID tags are programmed and work as expected as I can used my phone's RFID scanner to detect the tag, and the protocol is detected to be 15693. I've attached a Saleae capture of the SPI comms between the MCU and the CR95HF when using a Send/Receive command. The error code that is returned by the CR95HF is 0x87, which corresponds to not detecting an RFID tag.

Currently I'm using the default 15693 protocol config of 0x00, but have tried lowering the protocol bit rate and waiting for SOF.

Help would be greatly appreciated!

 

ClosedBridge_0-1733692765377.png

Capture of configuring the protocol

 

ClosedBridge_1-1733692793280.png

Capture of Send/Receive Command

1 ACCEPTED SOLUTION

Accepted Solutions

Hi Alex,

the ProtocolSelect 02 02 01 00 is configured to not append the CRC and therefore the frame are transmitted without CRC except if you manually add the CRC in the transmit buffer. As the CRC is missing, the tag ignores the received command.

I would suggest to use 02 02 01 0D for the ProtocolSelect. This should fix your issue.

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

12 REPLIES 12
Brian TIDAL
ST Employee

Hi,

the sendReceive command in the trace (0x04 0x00) contains an empty payload. Therefore the device only sends an isolated EOF. Thus no tag replies.

I would recommend to use the various libraries and demos provided on st.com web site rather that reimplementing the protocol.

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.

Thanks for responding. Is the necessary payload described by the RFID tag manufacturer?

Hi,

the various commands are described in datasheets of tag manufacturer based on mandatory commands from the ISO 15693 standard, optional commands from the ISO 15693 standard and proprietary/custom commands defined by the tag manufacturer.

I would suggest to use the X-CUBE-NFC3 package or the ST25 embedded NFC library package that provide supports for usual ISO 15693 commands for tag inventory and data exchange.

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,

Sorry for the late reply, I do appreciate the response! I've added a payload (Figure 2) as specified by the data sheet (Figure 1) for my RFID tag for an inventory command. The response from the ST RFID chip is still that no chip is detected (Figure 3), perhaps I'm missing something like a checksum?

ClosedBridge_0-1737081807177.png

Figure 1. Command set for RFID tag

ClosedBridge_1-1737081825727.png

Figure 2. Command sent to ST RFID chip

ClosedBridge_2-1737081917041.png

Figure 3. Response from ST RFID

 

 

Brian TIDAL
ST Employee

Hi,

the command being sent to the tag is 06 01 00 which is a 16 slots inventory as defined in ISO/IEC 15693-3. The tag will reply into the appropriate slot according to its UID.Thus it is needed to send the EOF after each slot (i.e. after a response is received or a timeout is received in the current slot) until reaching 16 slots. EOF can be transmitted by sending an empty frame with SendRecv command after each slot.

As you probably don't need to manage complex anticollision with 16 slots, I would suggest to use a 1 slot inventory command (26 01 00), i.e. all tags will reply in the same single slot.

Again, I suggest to use the X-CUBE-NFC3 package or the ST25 embedded NFC library package. 

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,

Here is a capture with the modified payload. Based off your comment on the EOF, I assume there's only the initial SendRecv command required and not an additional after sending the payload? I'm still not detecting a tag present it seems. I'm avoiding using the provided STM library as I will need to port this driver to a non-ST MCU.

ClosedBridge_0-1737121102610.png

Figure 1. SendRecv Command

ClosedBridge_1-1737121203410.png

Figure 2. Response

 

Thanks,

-Alex

 

Brian TIDAL
ST Employee

Hi Alex,

can you send me your Salae log file so that I can have a look to the parameters used in your ProtocolSelect command (I bet one of the parameter is incorrect).

"I'm avoiding using the provided STM library as I will need to port this driver to a non-ST MCU": our library is written to be scalable and portable on different MCU. It has been ported by different customers on different MCU.

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,

Here is the Saleae log, thanks again for looking into this! I had to throw the log into a drive folder since ST forums won't accept .sal files (and complains if I try to trick it by renaming it to a .csv).

Link to logs folder 


Hi Alex,

the log does not include the ProtocolSelect command but only the sendRecv command. Can you send the trace from the power up up to the SendRecv including the ProtocolSelect?

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.