This is the third installment/blog on the CR95HF, a near field communication IC manufactured by ST Micro. NFC is a short range RF communication protocol commonly used with smart cards for touch-less information exchange. New cell phones are being built with NFC hardware integrated making consumer applications more likely to be ubiquitous in the near future. Examples of applications might be vending machines or secure access systems. Here’s a Wikipedia summary of NFC.
Previous blogs were…
I covered the CR95HF communication protocol in detail in part 2. Once communication is established with the chip, and the RF protocol is established, communicating with ISO-15693 cards is pretty easy. For my test board I interfaced with ST’s smart cards and their dual interface enabled EEPROM. Both of these are ISO 15693 parts, and the protocol I implemented is described in ISO 15693-3. The EEPROM is neat because you can write/read to it from one side with a microcontroller and retrieve the memory from the NFC side with something like a smart phone, or in my case a test board and software.
Most communication to the ISO 15693 parts will use the CR95HF send/receive command. The datasheet section for this command is shown below.
The CR95HF Send Receive command basically wraps around the ISO 15693-3 implementation. The CR95HF strips off the wrapper and handles the RF side of NFC communication, and when it returns a response it wraps the NFC response in another wrapper.
For example, an ISO 15693 Inventory Command can be assembled with 3 bytes; 0×26 (request flags), 0×01 (mask length), 0×00(mask value). When wrapped in the CR95HF Send Receive command this looks like…
Red is data to the CR95HF, and blue is to the NFC device. All ISO 15693-3 commands are sent this way. The response is similar.
CR95HF->PC: 0×80, length of response, ISO 15693 response to command
ISO 15693-3 Commands:
The ISO 15693-3 document describes in detail a number of commands and methods for communicating with NFC enabled cards or devices. The interface can be complicated. You can imagine an application where numerous NFC smart cards are passed over a single reader. The reader would need to implement an anti-collision protocol and force communication with only one card at a time. This is done with UID’s and masks.
I’m going to simplify the discussion and just focus on reading data from a single NFC smart card. So I’ll ignore addressing and anti-collision efforts. To start we’ll take a look at a short list of ISO 15693 commands.
Let’s start with the Inventory command. This is used to find out if a card is present and to get information about the card. I’ve got the Inventory command definition below from ISO 15693-3. The CR95HF IC is going to handle all of the RF communication and the CRC16 generation. So we can ignore the start-of-frame (SOF), end-of-frame(EOF), and cyclical-redundancy checking (CRC16). Additionally, there are some some optional data that we can ignore.
The inventory byte, is simply the command code, or 0x01. The mask length is 0x00 since we’re not going to worry about addressing. That leaves the Flags byte to worry about.
ISO 15693 Request Flag definitions are shown below. Bit’s 1 and 2 are defined by your “protocol”, and in our case where using a single sub-carrier and high data rate. These should match the settings I showed in part 2 where you configure the CR95HF for the protocol you are using. We’re implementing the Inventory command so bit 3 is set, and we’re not using a protocol extension, bit 4 is clear. Bits 4 through 1 are 0,1,1,0 or hex 0x6. The definitions for bits 5-8 depend on whether or not you are sending an inventory command. We are so we use the second table.
Starting with bit 5, we are not going to use the AFI field. AFI stands for application family identifier and can differentiate between devices used for specific purposes. Some examples of AFI types include financial, gaming, and medical codes. The CR95HF has one inventory slot, so bit 6 is a 1. Bits 7 and 8 remain or 0. Therefore, bits 8 through 5 are 0,0,1,0, or hex 0x2.
When you put the upper nibble (bits 8-5) with the lower nibble (bits 4-1) you get the byte value for our flags byte 0x26.
Referring back to our previous example,
Red is data to the CR95HF, and blue is to the NFC device. You can see how the Flags byte, Inventory byte, and the Mask byte relate to the inventory command format. You can also see how this data is embedded in the CR95HF Send Receive command.
The inventory response format is shown below. Again, the CR95HF does some of the work for us. We can ignore the framing and error checking. Keep in mind though that you need to configure the CR95HF to implement CRC16’s when you tell it which protocol to use.
If an NFC card is in close proximity to the CR95HF the response would be something like…
The response flags are defined below. If no card is present you would get an error from the CR95HF in its response to the Send Receive command, not an error code from the 15693 protocol. If a card is present your response Flags register in general should be 0.
DSFID byte is the data storage format identifier that indicates how the data is structured in the NFC devices memory. It is typically 0x00, and not something we need to worry about. The UID contains the device manufacturer and serial number data. If implementing an anti-collision protocol you would use this information to single out a specific card. This data might also be used in conjunction with a database to associate specific cards with people or privileges.
For my test software I polled using the inventory command until I received a response.
CR95HF->PC: 0×80, 0x0A, 0x00, 0x00, 0xE0, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??, 0x??
That’s about all I’ve got time for this morning. Next blog I will try to cover the get system information command from ISO 15693-3 that is useful in finding our the block size and number of memory blocks in an NFC device.