Simplest Reader and Reader/Writer ICs?

[Ricko]

Hi,

as part of an upgrade to a number of products, we are looking at integrating 13.56MHz RFID capabilities into a number of products. Some require only to read an RFID card and others need to read and write such RFID card (no mobile devices or anything else). The RFID card type/protocol we can choose based on the IC (the ISO14443A looks a common one).

In all products the RFID reader/reader-writer ICs will be interfacing with an STM32.

Time to market is very important so we are looking at some solutions that already have drivers available for at least the basic functionality which is just to:

- program an RFID card with a person name or just their ID

- read such RFID card details (Unique ID and person name or person ID)

That is it... It is just to display data customised to a user preference in a dispensing system. So it does not need to be secure or have extra checks or have any other special feature. Low cost and quick time to market are more important than features.

Ideally we would like to have a driver take care of reading the data automatically when a card is placed in the antenna reading range and then signal the application layer when the data has been read. Nothing more than that.

The devices we are looking at at the moment are:

- ST25R95-VMD5T
- ST25R100-CMET

They seem to be SPI only but if there are other low cost alternatives (perhaps ST25R3918 ?) that meet the requirements that have I2C interface we would prefer them (speed is not important).

Do they have ready-to-use STM32 drivers for the basic functionality?

If not, which ICs do?

If both of the two parts I listed above meet all criteria, is there any advantage in using one over the other specifically for the application I described?

Thank you:)

[Brian TIDAL]

Hi Ricko,

All readers from the ST25R family (ST25R95, ST25R100, ST25R3918, etc.)  support the same RF Abstraction Layer library (RFAL) and have their own drivers.

Expansion kits are available for each of these readers:

• X-NUCLEO-NFC03A1 for the ST25R95
  
• X-NUCLEO-NFC09A1 for the ST25R100
• X-NUCLEO-NFC06A1/X-NUCLEO-NFC08A1 for the ST25R3916(B) series.

Those expansion kits can be plugged on top of STM32 NUCLEO boards.

Firmware packages are available for each expansion kit with some ready to use demos on STM32 MCU:

• either the ST25 embedded NFC library with various demos
• or X-CUBE-NFC9 (ST25R100) / X-CUBE-NF6 (ST25R3916(B) series) that are integrated with STM32CubeMX with a polling demo

As the RFAL provides the same API for each reader, the same application can run if you migrate from one reader to another one: the application just needs to be recompiled with the appropriate drivers.

Regarding the communication interface,

• ST25R95 supports SPI and UART
• ST25R3916(B) series devices support SPI and I2C
• ST25R100 supports SPI.

I would suggest to prototype your application with one or several of the X-NUCLEO-NFC expansion kits and to assess the performances.

Rgds

BT

[Ricko]

Thank you @Brian TIDAL

we also just looked at the CR95HF. Is it correct that then comparing the ST25R100 to the CR95HF one major difference is that the ST25R100 needs the micro to do all the communication handling while the CR95HF does it in hardware? in other words the the full stack is implemented in software for the ST25R100 while it is implemented on the transponder IC for the CR95HF?

If so, how can we quantify the amount of overhead taken by the driver?

Also when you say "X-CUBE-NFC9 (ST25R100) / X-CUBE-NF6 (ST25R3916(B) series) that are integrated with STM32CubeMX with a polling demo" why using a polling instead of an interrupt driven demo? And is the polling just checking the IRQ line from the reader IC or checking via software?

Also for future reference, is there a detailed comparison table for all NFC ICs like those mentioned above?

Thank you

[Tesla DeLorean]

By and large "demos" are provided as an illustration of "look it works", and not commercially deliverable products with all the arguments over "what" and "how" something needs to do it in the real-world application of the technology.

You are likely going to need to add the "VALUE" or pay for the "VALUE", I'd assume most of this stuff would take a significant amount of engineering effort to be simple.

Perhaps there's a local sales office or rep for the ST NFC/RFID lines that you can have more specific conversations with, and engineering resources they can direct you too?

[Brian TIDAL · Accepted solution]

Hi Ricko,

ST25R3916(B) and ST25R100 are Analog Front Ends (AFE). They manage the RF modulation/demodulation, the bit coding/decoding etc. and need to be controlled by an host that configures the various protocols, read and write the NFC frames from the device FIFO.

ST25R95/CR95HF has an internal MCU but basically acts as an Analog Front End and need as well to be controlled by an host. The working model is different e.g the host does not read or write directly into the device FIFO but uses a sendReceive command to request the sending of a frame and will receive the tag response as a response to this sendReceive command. At the end, an host MCU is needed to sequence the various commands.

So even if the ST25R95/CR95HF has an internal MCU, the command/response part of the NFC protocol runs on an host MCU and this is the same code that is used on all ST25R devices. The only difference is the driver part. For ST25R3916(B) or ST25R100 drivers, a light overhead can be foreseen but it has never been an issue for real customer applications.

Regarding the polling demo, I am sorry about the confusion. In NFC terminology, an NFC reader/writer is called a "poller". The "polling" demo demonstrates the way this poller works: detection of tags for various technologies, collision resolution to retrieve the identity of the various tags being in the operating value, activation of one of the tag and then some basic communication (e.g. to read the content of some blocks of the tag memory). The demo automatically performs all those activities and displays the UID of the tag on the serial console. This "polling" demo is often used by customer as a basis for their own application. 

Regarding your last request: on https://www.st.com/en/nfc/st25-nfc-readers.html, the overview tab provides a comparison of the various devices from the ST25R NFC reader portfolio based on the output power. The product selector tab provides detailed comparison based on the various features and the various packages.

If you hesitate between different products, do not hesitate to assess them thanks to the X-NUCLEO-NFC expansion kits.

Rgds

BT

[Ricko]

Thank you @Tesla DeLorean 

for these projects but I am developing the software and because time to market is important, I am trying to understand the products and options as much as possible. What I need to understand is the functionality and what is available in terms of ST libraries/drivers. That is why I was asking the additional questions following @Brian TIDAL feedback.

Thank you

[Brian TIDAL]

Hi Clive,

yes, a demo is a demo and of course this can not cover all the aspects of a real application. In addition to "look, it works!", our demos demonstrate the support of the various NFC activities (technology detection, collision resolution, device activation, data exchange and device deactivation), demonstrate various use cases (card detection and wake-up mode, card emulation, NDEF read/write, etc.) and provide information on the various API and on how to use the various API. The code that is provided to customer with the demos has been used during the NFC certification of the ST25R3916 and ST25R3911B device (see https://nfc-forum.org/products/certified-products/).

On top of those demos (in particular on top of the polling demo), customers can build their own application with our strong support and as you said, the difference between the demo and the real application is the added value.

Kind regards

BT

[Ricko]

Thank you @Brian TIDAL for the detailed reply. Much appreciated! :)