2024-12-08 01:22 PM
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!
Capture of configuring the protocol
Capture of Send/Receive Command
Solved! Go to Solution.
2025-01-17 11:51 AM
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
2024-12-09 01:20 AM - edited 2024-12-09 01:20 AM
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
2024-12-19 04:26 PM
Thanks for responding. Is the necessary payload described by the RFID tag manufacturer?
2024-12-20 01:58 AM
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
2025-01-16 06:46 PM
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?
Figure 1. Command set for RFID tag
Figure 2. Command sent to ST RFID chip
Figure 3. Response from ST RFID
2025-01-17 01:12 AM
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
2025-01-17 05:40 AM
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.
Figure 1. SendRecv Command
Figure 2. Response
Thanks,
-Alex
2025-01-17 05:52 AM
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
2025-01-17 06:27 AM
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
2025-01-17 08:04 AM
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