Secure Microcontrollers NFC Overview

Introduction

This application note provides an overview of Analog Devices secure microcontrollers with near field communication (NFC). While readers are expected to have some knowledge regarding NFC and contactless payment technologies, minimal background is included to clarify terms and concepts. Our secure NFC microcontrollers are designed to support payment systems, specifically Eurocard^®, Mastercard^®, Visa^® (EMV^®) contactless, and function as a reader or proximity coupling device (PCD). They do not support card emulation, which is often used by cellular phones as a payment method, such as Apple Pay^® and Samsung Pay^®, or peer-to-peer communication, such as data exchanges between two cellular phones.

This application note is a primary point of reference for questions that may arise during development with Analog Devices' secure NFC microcontrollers.

MAX32560

Analog Devices' first-generation NFC reader was originally designed to support EMV version 2.6a. It also supports EMV 3.0 in most designs. Full part details are found on the MAX32560 product page. It supports EMV contactless protocol for type A and B (ISO 14443 A and B), PBM Classic (MIFARE Classic^®), and JIS X 6319-4 (Felica).

MAX32570

Analog Devices' next-generation NFC reader has substantially increased field power to meet demanding designs and requirements of EMV 3.0. Full part details can be found on the MAX32570 product page. It supports EMV contactless protocol for type A and B (ISO 14443 A and B, Proximity), PBM Classic (MIFARE Classic), JIS X 6319-4 (Felica), and ISO 15693 (Vicinity).

NFC Overview

NFC commonly refers to a wide variety of products, devices, specifications, and software. Many different companies developed unique products with various communications methods that became highly fragmented. Several efforts to standardize different products into cohesive groupings have been met with some success, including ISO specifications, EMV contactless, and NFC Forum. However, many proprietary devices, communications, software applications remain outside of these groupings. NFC applications are commonly organized by device types, physical layer types, standards, and governing bodies.

Fundamentals of NFC

At its most basic, NFC is an established wireless communications method that offers security and convenience.

Security

Most wireless communications (FM radio, cellular, Bluetooth^®, Wi-Fi) rely on far-field antenna effects. Far field begins at a distance of λ/2p from an antenna, where λ is the wavelength of the signal emitted from the antenna. In this region, the signal energy is radiating away from the antenna. Other antennas at far-field distances have a negligible effect on each other. This is beneficial for AM/FM radio in order to receive enough signal to listen to the radio during rush hour traffic. However, it poses security risks for a payment system. Anyone with an antenna could eavesdrop on a conversation, and it would be difficult to control which card in your wallet is used for payment.

Near field is close to the antenna and defined as less than λ/2p. Energy is largely stored in the antenna's primary field rather than radiated. For NFC systems, this distance is about 3.5m, but with low power systems and small antennas, typical NFC operating distances are limited to 4cm or less. In this region, an antenna receiving the signal affects the transmitting one. This unique behavior of near field effects allows for NFC. The result is the payment card or devices must be close to the terminal to process, making it extremely unlikely for communications to be intercepted, since any listening antenna close enough would be visible to the card holder. It also means that a payment card in your pocket will not be detected and charged inadvertently.

Convenience

In addition to the communications distance, near field antenna effects allow power delivery from the reader to the card. This means NFC cards do not need batteries or other means of self-powering like a radio or a cellular phone does. This allows the cards to function much the same way as credit cards have worked for decades. Imagine having to charge your credit cards or change their batteries before going shopping. This ability to harvest power allows the cards or tags to be simple in design and inexpensive to produce, facilitating use in a wide range of applications, including inventory management systems where thousands of tags are deployed into books, boxes, etc. This is a simplified explanation of electromagnetic theory and behaviors of near and far field antennas.

Device Types

Device types organize products and their associated technologies in groupings based on functionality.

• PCD (proximity coupling device): Readers and terminals generate the near field used to power PICCs and provide a communications medium. Analog Devices' NFC micros implement this type.
• PICC (proximity IC card): Payment and identity cards, tags, smart stamps, etc. are devices powered when entering a near field.
• Card emulation: Devices supporting this functionality are similar to PICC's but can provide their own power. Cellular phones use this for payment schemes, such as Apple Pay.
• Peer to peer: Typically used to exchange data between two devices capable of generating their own field, such as two cellular phones.

Physical/RF Layer Types and Standards

Another common way to sort NFC devices is by the physical layer type they support, modulation scheme, and utilized bit encoding. Analog Devices only supports types using a 13.56MHz carrier frequency. There are other carrier frequencies in use for various applications, but they are beyond the scope of this document. These types are often referred to by their standard but have some aliases. Furthermore, there is overlap between the various types.

NFC devices communicate by modulating the amplitude of the field between the PCD and PICC, which is known as amplitude shift keying (ASK). The PCD does this by varying the output power for the field it produces. The PICC increases or decreases its load on the field, known as load modulation. PCDs transmit using either 100% ASK or 10% ASK depending on the type. 10% ASK is a bit of a misnomer, as the actual amplitude requirements vary depending on type and distance from the field generating antenna. For purposes of this document, all ASK less than 100% will be referred to as 10%. Load modulation by the PICC is much smaller in amplitude than the transmitter's modulation. It can be difficult to see, even with an oscilloscope attached to the PCD antenna reception pins. Recall that load modulation communication is only possible in the near field.

The following list provides basic details regarding the various physical device's types. Each type is defined by the named standard and can be consulted for complete details. Figure 1 shows the various types and provides product examples of each. It also illustrates the complexity and fragmentation of NFC products and technology.

ISO/IEC 14443 A

This type is referred to as proximity due to requirements to operate at distances of 4cm and less from the PCD antenna. It also differentiates it from the ISO/IEC 15693. This type is also known as type A or NFC-A. PCD to PICC uses 100% ASK modulation with a Modified Miller bit encoding. PICC to PCD utilizes a subcarrier with on off keying (OOK) and Manchester bit encoding.

ISO/IEC 14443 B

Types A and B, also known as NFC-B, are defined together in the same 14443 specification. Type B PCD to PICC uses 10% ASK modulation with a non-return to zero (NRZ) bit encoding, like serial UART. PICC to PCD utilizes a subcarrier with binary phase shift keying (BPSK) and NRZ-L bit encoding.

FeliCa

Developed and popular in Japan, this type is also known as type F, type C, NFC-F, and JIS X 6219-4. Unlike types A & B, type F uses the same Manchester bit encoding for both communications directions. PCD to PICC uses 10% ASK, and PICC to PCD uses load modulation with no subcarrier.

ISO/IEC 15693

This type is referred to as vicinity, since it is designed to operate further away from the reader antenna than types A and B, also known as NFC-V. This technology is primarily used for radio frequency identification (RFID) and inventory tracking. Type V includes many different modes to allow the reader to tailor communications methods to the application. Vicinity coupled device (VCD) to vicinity IC card (VICC) uses either 100% or 10% ASK. 100% provides higher signaling amplitude for a noisy environment, while 10% allows devices far away to maintain a constant amount of power delivery. Bit encoding uses either 1 out of 256 or 1 out of 4. When activating communications, the VCD configures the VICC to use either single or dual subcarrier modulation, each with unique bit encodings and low or high data rates.

ISO/IEC 18092

This type is also known as peer to peer and is based on ECMA-340. It uses some parts of type A and type F, depending on communications speed. It allows devices to be initiators or targets and active or passive communications.

Communications Speeds

Each type supports multiple communications speeds. The speeds are defined by the number of carrier periods in each bit denoted by 1/fc where fc is 13.56MHz. The subcarrier (fs) used with types A and B for PICC to PCD communications is fc/16 or 848kHz. At the default 106Kbps rate, each bit time is 8 subcarrier periods fs/8 or fc/128. The allowable speed ranges are 106, 212, 424, and 848Kbps; each higher speed using less subcarriers per bit time. Therefore, higher speeds are less robust than lower speeds. Further complicating this, at rates above 106Kbps, type A PICC to PCD communications typically use BPSK like type B PICCs, but with different framing. In practice, 424Kbps is usually the highest speed used. Note that Analog Devices' NFC micros currently only support the default rate of 106Kbps for types A and B.

Type F default rate is 212Kpbs and supports 424Kpbs. Analog Devices' NFC micros currently only support the default rate of 212Kpbs.

Type V speeds are slightly more complex, since VCD to VICC speeds are 1 of 4 at 26.48Kbps, and 1 of 256 at 1.65Kbps. VICC to VCD uses a low speed of ~fc/2048 or 6.6Kbps and a high speed of ~fc/512 or 26Kbps. These VICC to VCD rates change slightly if dual subcarrier is used.

ISO 18092 nominally defines rates of 106, 212, and 424Kbps. It also lists higher speeds but does not specify modulation or bit encodings for these speeds.

EMV

Eurocard, Mastercard, Visa (EMV) is the dominant governing body for payment cards. It provides specifications for contact cards (smart cards) as well as contactless (NFC payment cards), among others. The EMV contactless level 1 specification includes types A and B. Level 1 handles card identification, activation, and communications from application protocol data units (APDUs) to RF modulation. It is important to know that, while these are adopted from the ISO 14443 types, they are not identical. EMV does not allow more than one card to be in the field at a time. If a collision is detected, usually from multiple cards in the field, the transaction is terminated. ISO 14443 details procedures to allow individual cards to be identified and communicated with when multiple cards are in the field. EMV specifies that communications will be at the default rate of 106Kbps only.

Certification

EMV also requires rigorous certification testing for both PCD and PICC devices to be compliant with the EMV contactless standard. To achieve passing EMV level 1 certification, analog, digital, and interoperability tests must all be completed successfully. Note that various card vendors, such as Visa and Mastercard, also have detailed certification tests for level 2 to validate payment vendor specific applications and procedures. Analog Devices' provided DTE (device test environment) example software is designed to be used during level 1 testing.

MIFARE

MIFARE is a product developed by NXP^® and is the most common type of NFC card, having sold more than 10 billion card devices. There are many different types and sizes of MIFARE cards, including MIFARE Classic (the most common), Plus^®, Ultralight^®, Ultralight C, 1K, 2K, 4K, and DESFire^®. Some of these types are fully compliant with ISO 14443 type A, while some are only partially compliant. Classic cards, such as the 1K and 4K, use an encryption scheme that enciphers the parity and data bits of transactions. This prevents use of standard type A communications procedures. The DESFire cards, however, are fully compliant with ISO 14443 type A.

NFC Forum

The NFC Forum is a nonprofit industry association founded by NXP, Sony^®, and Nokia^®. They have attempted to organize the fragmented field of NFC technology and enforce quality standards by grouping cards into different tag numbers based on the behavior and physical/RF types they support.

Other Types and Standards

There are many other card technologies, including Calypso^®, GTML (e.g., type B prime or Innovatron^®), Topaz, Jewel, iClass^®, that are beyond the scope of this document. Analog Devices' NFC micros do not provide example code or support for these technologies or other technologies not mentioned above. Some of these can be implemented using the lowest interface levels provided by the RF driver, but support is left as an exercise to the reader and is not guaranteed.

Drivers, Software and Stacks

Analog Devices' secure micros with NFC are primarily targeted towards payment applications and do not attempt to support all types of NFC devices and technologies. Figure 2 shows the earlier NFC type and tags chart with an overlay illustrating where the software provided by Analog Devices is used. This chart is intended as an overview and is not a definitive representation of the software and capabilities.

The physical and RF layer are provided by the analog front end (AFE), digital base band (DBB) and the RF driver (libnfc_pcd_rf_driver, cyan). Above this, are various protocol, activation, and data transport protocols. EMV and ISO 14443 devices are supported by the libnfc_pcd_emv_l1_stack (green). MIFARE Classic device activation and encrypted communications are provided by libnfc_pcd_pbm (purple). Note that there is no support for Topaz, Jewel, GTML, FeliCa, ISO 18092, and ISO 15693 above the RF driver. Currently, ISO 15693 is only available for beta level evaluation on the MAX32570 and is not available on the MAX32560.

RF Driver

Access to the contactless radio on Analog Devices devices is provided by a hardware abstraction layer (HAL) referred to as the RF driver in our documentation. The RF driver provides a straightforward API to the complex underling radio hardware without loss of functionality or configurability. The RF driver handles protocol framing, AFE tuning, and low-level timing requirements. It is agnostic of the software and stacks above it, allowing use of either the included EMV level 1 (L1) stack or a 3rd party L1 stack, if desired. There is a different RF driver for the MAX32560 and MAX32570, as they have different capabilities and support some different types. However, the API they present is virtually identical.

Full API documentation, resource usage, integration guidance and version history are included in a Doxygen-based Compiled HTML (CHM) file distributed with every release of the contactless support package (CSP). The RF driver is released primarily in binary library form (closed source). Some functionality is implemented in the source available file mml_nfc_pcd_port.c. The porting file allows for customization and integration of the RF driver into a specific application.

Transceive

After activation of the field, all communications start with a PCD transmit and await a PICC reply. Every transceive operation is determined by the following parameters provided to the RF driver:

• Protocol: One of the physical/RF types defined above and supported by the micro.
• Frame type: Most types use the standard framing consisting of 8-bit characters with CRC. Type A uses special short frames during activation.
• Data: Transmit data and length, pointers to store received data and length.
• Timing: Three timing parameters are used to enforce and validate protocol requirements.

Framing

Each type has its own framing requirement, including start of frame (SOF), end of frame (EOF), parity, start stop bits, CRC, bit order, preambles, trailers, intercharacter delays, etc. The RF driver's transceive function provides all of these framing requirements. Before transmission, the data is encapsulated as required, to fulfill the framing requirements of each protocol/type. During reception, framing is validated, then stripped from the received data. Much of the framing added to the communications at this level is designed to prevent and detect communications issues, as any wireless connection is an inherently unreliable connection. If any framing is incorrect, the RF driver will report it as an error in the status returned from the transceive function. To provide maximum debugging and visibility, every framing requirement and potential error source have unique error codes with over 70 error codes.

The RF driver also provides a raw interface referred to as transceive bits. This interface uses all the same parameters as the above transceive function, except for frame type. This mode bypasses the bulk of protocol/type framing. It is primarily used for type A, allowing bitwise anticollision procedures and encrypted PBM (MIFARE) communications. Currently, only type A protocol is supported in bit mode since no other type requires this low-level form of communications for normal operation.

Timing

The RF driver uses three timing parameters to enforce and validate protocol requirements. These parameters are given descriptive names to help explain their purpose. They are in 1/fc units (aka fc) for convenience. Most timing parameters in protocol/type specifications use this as the base time unit. Whenever idle and possible, the RF driver will call into the porting function mml_nfc_pcd_task_sleep to allow other critical system and application operations to occur, such as updating LCD, etc. The three timing parameters to the transceive function are detailed below. Figure 3 further illustrates each parameter and how it is used.

• delay_till_send: Provides a mechanism to precisely control the timing between two consecutive PCD operations. This can be used to enforce spacing between two transmissions (FDTpcdmin) or allow the required amount of time (5.1ms) for PICC to warm up when the field is first energized. This time applies before the PCD transmission begins. It is measured from the previous valid operation: the end of a valid PICC response successfully received or the end of the last PCD transmit. Enabling the RF field also starts the timer allowing precise control of the power-up time for cards in the field. Figure 3, Figure 4, and Figure 5 show these various timing situations.
• timeout: Maximum allowed time limit between when the PCD transmission ends and a valid PICC response is received. If expired the RF driver returns with no data and a timeout error code. Each protocol has specific framing steps and requirements for what must be received to be considered valid and before a timeout occurs. For instance, if a reception starts close to the timeout, but the SOF is received before timeout occurs, the response will be considered valid if it does not have any other communications errors.
• early_limit: Protocol specifications have specific requirements for how quickly after reception of a PCD message the PICC can respond. This is enforced by the early_limit parameter. If a reception starts before this time, it will be considered invalid, even if all other checks pass. Note that in EMD mode, detailed below, a complete message can be received and ignored if it arrives in this deaf time.

Error Handling

Every potential PICC response must be validated and checked for an assortment of error conditions. Errors detected are reported to the calling software, which determines how they must be handled. The error types returned are roughly grouped as follows:

• Success
• Timeout. In addition to the standard timeout detailed above, there are a few other timeout related error codes that can occur. Refer to the RF driver API documentation for further details.
• Transmission Error. This is the largest group of error codes due to the difference between types/protocols. A response can have errors at several different layers, including invalid framing, bit encoded symbols, parity, start, stop, preamble, etc. Even if these low-level checks pass, incomplete data can occur, or the CRC for the packet can be invalid. After validation of these potential pitfalls, the packet can still have violated required timing conditions.
• Collision. Each type/protocol has its own method for detecting collisions, which occur when more than one card is in the field. Note that these type-specific collision detections only detect when two or more cards of the same type are found in the field. The level 1 technology polling procedure is designed to detect collisions with devices of different types, such as type A and B.
• Electro Magnetic Disturbance (EMD) is a special case with its own error handling requirements. This specific type of error only applies to EMV communications. EMD handling is enabled for a given transceive function using the frame type FT_STANDARD_CRC_EMD as detailed in the API documentation. Refer to the EMV L1 specification for details on specific conditions that cause a response to be considered EMD. If a response is short enough and has some type of error, it must be considered EMD. In EMD mode, the RF driver is required to drop this packet and immediately prepare for any subsequent responses. The required turnaround time (tRECOVERY, 1280fc) and the API for the transceive function require the RF driver to handle these cases directly, which occurs in the RF driver's interrupt service routine (ISR). Figure 6 illustrates a case of EMD. Note that all EMD packets are dropped, and there may not be a valid response before timeout.

Portability

To support different product and use case requirements, some portions of the RF driver reside in the file mml_nfc_pcd_port.c. This file is released as source, while most of the RF driver is binary only. These functions allow system integrators to decide how each function is best implemented for their system. Applications using a real-time operating system (RTOS) have dedicated routines for critical section entry and exit, along with task yielding functionality that can be employed during calls to sleep. Refer to the API documentation on porting for more details. Review the example implementations of the porting file available in the DTE (single-threaded) and the FreeRTOS demo.

Analog Configuration

The last primary function of the RF driver is allowing configuration of the analog front end (AFE) on a per-transceive function basis. To maximize configurability, the transceive function calls into a public porting function mml_nfc_pcd_field_level_detection_callback. It must determine the analog parameters to use for the transceive currently in process. The RF driver provides the protocol type to the function, as each type can require a different analog configuration depending on the unique challenges of a specific design.

Field-level detection is often abbreviated in the API as FD. The FD level indicates the strength of magnetic coupling between the antenna coils of the PCD and PICC. The FD can be thought of as representing distance between the coils, but this is only one factor in the coupling. The orientation, offset, and active loading (power harvesting) between the coils also contribute to the loading.

Typically, the function mml_nfc_pcd_field_level_detection_callback utilizes a matrix containing settings for a specific design at specified FD levels. It calls into the RF driver function mml_nfc_pcd_detect_loading to determine this level, then chooses the analog configuration for the current transceive function. Note there are differences in the analog configuration parameter structure between the MAX32560 and the MAX32570 due to different feature sets.

This dynamic control of the analog configuration is a powerful tool allowing customization of all communications with cards. Figure 7 displays a calling tree diagram explaining how this functionality works. Refer to the documentation included with the CSP and SDK install, the NFC PCD AFE Tuning Guide, PCD Antenna Matching Design Guide, EMV DTE User's Manual, and the EMV 3.0 Application Note for further details.

PBM MIFARE Compatible Classic Library

The PBM library is designed to be compatible with MIFARE Classic cards, often referred to as 1K or 4K cards. These cards are widely used in transportation, access control, event ticketing, etc. There are many different types of MIFARE cards including DESFire, Ultra-Light, UL C, Plus and Plus EV1, etc. Many of these types are known to use compliant low-level transport and do not require use of the PBM library. The PBM library is released in binary form only. Note that Maxim does not currently provide example code demonstrating activation and communications with any MIFARE cards other than Classic. MIFARE card types that are not Classic are more compliant with standards. Therefore, applications can use standard RF driver transceive function commands and some portions of the EMV L1 stack to communicate with them.

MIFARE Classic cards utilize a proprietary cipher to protect data exchanged between the PCD and the PICC. This cipher is publicly acknowledged as compromised and should not be depended on to ensure data security. The cipher methodology results in communications not compliant with ISO 14443, although they observe most stipulations of type A cards. The primary differences are the framing and application-level data exchange. The ciphered communications encrypt both the data byte and the associated parity bit, which is required by the ISO 14443 book 3 framing. This means the parity bit is no longer an actual parity bit during low-level active communications, and the entire packet must be enciphered before communications and deciphered after reception; hence, the term Parity Bypass Mode (PBM) is used. This is quite different from the other protocols, which have a clear division of responsibilities for each layer, such as the network OSI model. The Classic card type responses to the Select command with bit 6 cleared indicate they do not support ISO 14443-4, the half-duplex block transport protocol using APDUs. Instead, these cards use a proprietary command response protocol.

Activation

Although MIFARE Classic cards are not fully compliant with ISO 14443-3, they still utilize most of the activation and initialization procedures detailed therein. The same polling routines used for EMV cards are used to find and activate these cards; however, the polling routine returns the error code TYPE_A_NON_ISO14443_4_READY. To determine proper communications procedures, MIFARE application notes describe the required procedure to determine the exact type of MIFARE card found in the field. Refer to the card manufacturer's data sheets and user's guides for full activation and communications details.

Commands

MIFARE Classic data and file structure details are beyond the scope of this document. Refer to the card manufacturer provided user guides and data sheets for full structural and feature details of these cards.

Analog Devices provides raw command access to MIFARE Classic cards. These commands provide access to all card data and features and are demonstrated in the device test environment (DTE) example application P. Transport Classic (PBM) menu item. Analog Devices' DTE User Manual, Appendix A provides details on these commands and includes two example usage flows to access data on the card.

After reception of a valid select acknowledge (SAK), it is necessary to authenticate the desired block for access. This requires application knowledge of the block key, which is written into the sector trailer. Without application knowledge of this key, the PBM library will not complete authentication of the targeted data block and cannot access it. Note that empty or unformatted cards are typically manufactured with empty block keys as well (i.e., a 64-bit key of all ones: 0xFFFFFFFFFFFF). The DTE example defaults to using this key for all PBM communications. This can be changed through menu options or overwritten by example modification.

EMV L1 Stack

Analog Devices' secure micros are primarily targeted to payment applications. The EMV level 1 (L1) specification is the most widely used in the contactless payment industry. Support for EMV L1 is the prime function of the NFC DTE example code available for each device. Combined with a device evaluation kit, it is a complete solution capable of completing required EMV L1 certification testing, analog, digital, and interoperability.

Analog Devices' EMV L1 stack is released as source along with the rest of the DTE example code, allowing customization for any unique application requirements, such as cards with non-compliant timing, responses, etc.

The L1 stack consists of two parts, the polling code and the half-duplex transport protocol defined in the EMV L1 specification and based on ISO 14443-4. Polling routines are typically accessed by application code to locate potential cards in the field, while the L1 stack is typically tied into level 2 stacks for EMV applications.

Polling

The term polling is the algorithmic procedure used to identify and activate cards in the NFC field. The required polling procedure specified by ISO 14443 and EMV is similar. It is designed to sequentially find cards of multiple types in the field; however, there are some important differences. For ISO 14443, the expectation is to find and identify all possible cards in the field using complicated anticollision procedures designed to allow all cards to respond with their unique identification numbers. These cards can then be indexed and individually selected by application code to find the desired card. In EMV, more than one card found in the field is considered a collision and is not allowed. EMV L1 provides specific requirements for dealing with collisions found during multi-technology polling and the anti-collision phase of activation, typical with the polling and activation procedure being aborted.

The DTE's polling routine is provided in the file EMV_polling_and_loopback.c. It is important to note that this file contains two separate card polling routines: singleemvl1exchange is used in loop back mode for L1 certification testing, and emv_poll_for_card is used for final applications. The primary differences are that the application mode resets the field when no cards are found. After a card is found, it is returned and successfully activated. The testing mode automatically enters loopback mode as detailed in the EMV DTE specification. The proximity payment system environment (CAPDU PPSE) is sent and RAPDUs are resent as the next CAPDU, unless there are special exit case codes or an error occurs. The PPSE command is typically the first command sent to activated EMV cards, and the response identifies the card vendor.

Note that while the EMV L1 spec allows the PCD to poll for other technologies, such as FeliCa, etc., the DTE only polls for EMV types A and B. The DTE's functionality is to implement EMV requirements. It does not provide support for ISO 14443 style multi-card detection and processing. Although the RF driver provides all necessary mechanics to perform ISO 14443-3 multi-card anti-collision procedures, there is currently no support for this in the level 1 stack or DTE example.

APDU Transport

Application protocol data units (APDU) are detailed in the Contact EMV specifications. They are the border between applications and level 2 stacks, and the lower level 1 functionalities. APDUs can be either command APDUs (CAPDUs) or response APDUs (RAPDUs). Most card user guides and data sheets detail supported CAPDUs, along with the structure of expected RAPDUs. The format and decoding of these are features of level 2 software.

During the activation stage, the PICCs respond with answer to select (ATS) containing various communications parameters, which the L1 stack must conform to. These parameters include how long to wait for PICC responses, the size of block packets the PICC can receive and transmit, etc. The stack adjusts the transceive function packets to accommodate these card requests, if they are within specified ranges; otherwise, it begins exception handle procedures. The L1 specification allows cards to request additional time for operations and provides for acknowledgement (ACK) and negative acknowledgement (NAK) procedures to facilitate retries. As a matter of course, most operations in the L1 stack can be retried up to three times before declaring an error. This functionality enhances the robustness of the wireless connection and the low-level EMD handling routines.

Level 2 and Beyond

There are many sequential CAPDUs and RAPDUs exchanged between the PCD and PICC necessary to complete any transaction, such as a purchase. The exact sequence and format of these APDUs, and the format of the data in both the command and responses, is part of the functionality provided by level 2 stacks. Different credit card companies have their own specifications for their payment applications. These specific applications are often referred to as kernels. EMV details seven different L2 kernels. Each corresponds to a different payment company, such as Visa, Mastercard, American Express, etc.

Unlike EMV level 1, the EMV level 2 kernels are less of an industry standard. Most major credit companies, including Visa (payWave^®) and Mastercard (PayPass^®), have their own specifications for level 2 kernels and their own certification process separate form EMV.

Above level 2 things are less clearly defined and is referred to as the application level. The application level is responsible for all system tasks, including screen updates, pin entry, host communications (USB, Bluetooth, Wi-Fi), payment method identification (NFC, contact, MSR, etc.), cryptographically secure communications to payment servers, and other remote assets.

Amadis

Analog Devices does not support the NFC application beyond level 1. We are partnered with Amadis, an industry leader in level 2 payment software.

Examples

Analog Devices provides two examples for each secure NFC microcontroller. The DTE example implements the device test environment as required by and detailed in the EMV DTE specification. This is the prime example and exposes most features to the contactless radio. This is the starting point for any NFC related development for either supported micro. Each EV kit ships with a demonstration example, which is also available in the SDK. This includes software to exercise the primary EV kit functions, such as LCD, touchscreen, secure pin pad, MSR, smart card/contact EMV, and NFC. The demonstration example differs significantly from the DTE example, as it uses FreeRTOS instead of being single threaded. A different implementation of mml_nfc_pcd_port.c is provided, interfacing with the FreeRTOS API.

The demonstration example is setup to read any payment card that enters the field. Any cards found are activated. If they support ISO 14443-4, the PPSE CAPDU is executed. All EMV compliant payment cards respond to this command. The response contains the application identifier code (AID) and often an ASCII byte array with the payment company name (i.e., Visa, Mastercard, etc.). If there is no text name, the demonstration searches for the received AID code in a table of known providers. In either successful reading case, the AID and provider name are displayed on the LCD with a success beep. Note that any cards without a valid payment applet/application installed will return error codes when sent the PPSE. If so, the LCD displays Card doesn't handle PPSE, meaning it was successfully activated, but lacks a EMV payment applet. The demonstration also attempts to identify any MIFARE cards discovered in the field. Note that this is only intended for demonstration purposes and does not work with every NFC card or device. Currently, it only attempts to discover type A and B cards.

Hardware Considerations

Although the EMV level 1 stack and RF driver attempt to remove low-level complexities through hardware abstraction, hardware configuration must be considered in every system and application. Due to the nature of near-field antenna effects, system mechanicals and design require careful antenna placement, matching, and analog front-end (AFE) tuning.

Antenna Size and Placement

It is crucial to consider antenna size early in the design process of a point of sale (POS) terminal. Antenna size and location are highly dependent on the physical shape and mechanical design of a given solution. Many design choices occur before printed circuit board (PCB) design or application software development begins. Having an antenna that is too small or located in a problematic area of a design can make it impossible to achieve the desired NFC performance range.

Generally, smaller antennas have more difficulty successfully passing level 1 certification and performance criteria. It is suggested that designs using the MAX32560 should use antennas 5cm x 5cm or larger, while MAX32570 antennas should be 4cm × 4cm or larger. Optimal design of the contactless antenna for a given design is extremely complex and beyond the scope of this document.

Furthermore, care should be taken to optimize the placement of the contactless antenna. Due to near field effects, any ferrous or conductive metal within the range of the antenna (~4cm radius) will reduce the radiated power available to power PICCs. Combining a small antenna while locating parasitic mechanicals close to the antenna will result in poor performance. Ferrite materials can be utilized to mitigate the loading effect of various parasitic metals near the field.

Refer to the PCD Antenna Matching Design Guide and NFC PCD AFE Tuning Guide for more information. Note that antenna design is an advanced specialty topic, typically requiring years of education, experience, electromagnetic design, and use of simulation tools. Some NFC antennas are available for purchase off the shelf and can be utilized for prototyping purposes. There are also third-party companies who specialize is custom antenna design.

Coupling Effects

Although PCD and PICC must be in close proximity for NFC communications to be successful, extremely close ranges compromise signal integrity severe enough to violate EMV level 1 requirements and reduce communications reliability. This coupling effect between the two antennas increases as the size of the PCD antenna is reduced and when PCD and PICC antennas are closer in size.

Physical system design enforces some distance between the two antennas, as the PCD antenna is typically behind a display or inside a plastic enclosure. It is recommended to have around 5mm of separation or a gap between the two coils. This distance is a good compromise, allowing reasonable signal integrity at close distances without sacrificing read range and power delivery at far ranges. However, optimal separation will be unique for every design.

Power Delivery

Power delivered from the PCD to PICC is perhaps the most crucial parameter to consider. The operating volume required by EMV level 1 is quite large compared to volumes required for other specifications. It is made even more demanding by changes made between EMV 2.6 and 3.0. While the specification has increased the required power, design trends towards compact and portable POS devices compromise the available power (i.e., smaller antennas and parasitic metal material moving closer to the antenna).

To combat this, the MAX32570 was designed to deliver significantly more power to the PCD antenna. Further guidance on achieving power requirements is detailed in the Contactless PCD Application Note – EMV 3.0 Level 1 Analog application notes for each device.

Matching Network

The matching network connects the output of the 13.56MHz field generator (transmitter, Tx) pins of the microcontroller to the NFC antenna. It is composed of two sections: the electromagnetic compatibility (EMC) filter and the impedance matching section. Since every system has unique environmental parasitics, antenna design, and placement, the matching network must be custom tailored to the application as well. Detailed guidance on tuning is provided in the PCD Antenna Matching Design Guide. It is important to note that environmental and enclosure parasitics will affect the matching condition of the antenna. It is recommended to perform the matching procedures with a design prototype that is as complete as possible to avoid significant replication of work if the system tuning changes later.

Analog Devices recommends the EMV filter portion of the network be as close to the secure microcontroller as possible to minimize signal loss, distortion, and radiated electrical noise. The matching section is recommended to be close to the antenna, with the traces between these sections allowed to be longer, if necessary. Overall, trace length from the micro to the antenna should be as short as possible to maximize power delivery.

AFE Tuning

After the NFC antenna is selected and placed, and the matching network is tuned for optimal performance, the final stage of analog front-end (AFE) tuning can begin. The AFE tuning procedure often requires the most development time on the hardware side of system integration. AFE tuning is iterative. While initial values can provide reasonable performance, passing the EMV L1 analog test suite requires modifications that can result in several iterations of tuning to ensure robust performance. Refer to the Contactless PCD AFE Tuning Guide and Contactless PCD Application Note – EMV 3.0 Level 1 Analog for details and guidance. Note that more challenging systems (i.e., smaller antennas and increased loading effects from enclosed parasitics) require longer and more difficult AFE tuning.

Completion of AFE tuning creates a mml_nfc_pcd_analog_params_matrix_t array that is used by application software to support a given system antenna. The DTE ships with an analog settings matrix for the included NFC antenna and applies this matrix at boot. To support a different antenna, the DTE example and final application must override this matrix with the carefully tuned version of AFE settings designed to support the specific antenna and system. The DTE provides menu commands to adjust the analog settings while tuning, which are detailed in the Contactless PCD AFE Tuning Guide and the EMV DTE User Manual. After finalizing the AFE settings in the DTE, use the menu command P. Print Current Matrix as C structure to copy and paste the currently configured matrix into the DTE or application source code.

This matrix is used by the mml_nfc_pcd_field_level_detection_callback function in the mml_nfc_pcd_port.c file to dynamically choose the correct analog settings for the current protocol type. Effective distance provides detailed parametric control of every communication with a PICC.

SDK, Libraries, and Example Installation

To work with Analog Devices' secure microcontroller with NFC, the required software development kit (SDK) must be installed and updated with the latest NFC plugin or libraries. The contactless support package (CSP) software and documentation work with the SDKs released for the respective devices. The SDKs are available through the Analog Devices website under the Design Resources tab of the Device pages. For the MAX32560, the CSP is an archive combining an Eclipse^® plugin with a documentation file (compiled html, .chm) and plugin installation guide. The MAX32570 uses a different SDK. The NFC product lib can be installed through the Analog Devices micros software development kit maintenance tool but requires the NFC repository URL to be installed. Since the NFC support package requires a nondisclosure agreement (NDA), contact Analog Devices for installation instructions and the repository URL.

CSP Included Documentation

The documentation included in the CSP is built into a single file for easier viewing. It combines several markdown documents, white papers, and Doxygen library API details.

• EMV DTE User Manual
  
  
  • This manual accompanies the DTE and explains how to use the example: board inspection, connection, powering, menu options and troubleshooting.
• PCD Antenna Matching Design Guide
  
  
  • This guide steps through design decisions and issues to get optimum analog performance for the contactless interface. It is critical that this is done properly for every contactless design.
• Matching Design Calculations
  
  
  • This spreadsheet should be used in conjunction with the PCD Antenna Matching Design Guide. It provides easy to use equations to solve for antenna matching component values.
• NFC PCD AFE Tuning Guide
  
  
  • This guide covers the final analog tuning required for contactless designs. It should be used after optimal antenna matching.
• EVKIT EMV L1 Test Reports
  
  
  • These analog and digital reports are generated using an in-house Micropross EMV level 1 tester.
• Implementation Conformance Statement (ICS)
  
  
  • This form is required by EMVCo for every unique design/product submitted for certification. It provides specific details of behaviors of the level 1 stack and hardware in the secure microcontroller. It is provided for reference purposes.
• RF Driver Documentation
  
  
  • The markdown page for the RF driver includes links to API documents. It offers significant guidance on resource usage, including timer utilization, IRQ, and portability configuration details. Portability refers to the methods implemented and modified during system integration with customer applications.
• Analog Devices EMV L1 Stack Documentation
  
  
  • The EMV L1 stack markdown page includes some high-level descriptions of the stack features and links to API documents etc.
• PBM Library Documentation
  
  
  • The PBM library markdown page includes some high-level descriptions of the library features and links to API documents, etc.
• Device User Guides
  
  
  • The user guides provide detail on all parts of the secure microcontroller beyond the NFC/contactless peripheral.

Application Notes

• MAX32570 Contactless PCD Application Note – EMV 3.0 Level 1 Analog
• MAX32560 Contactless PCD Application Note – EMV 3.0 Level 1 Analog
  
  
  • These application notes are supplementary and designed to help with specific issues faced during EMV level 1 analog certification and are available from the part landing page.

Troubleshooting

Analog Devices has made efforts to provide information and tools necessary to facilitate design and development of a contactless solution. As with any sufficiently complex system, issues can be encountered depending on the relative difficulty of the RF design.

Analog Performance Issues

Many issues and situations can arise due to the unique analog challenges of every design using the secure microcontroller with NFC. Optimal performance is not guaranteed on new designs automatically. Antennas and filtering connections used in one design may not work on another. It is critical to use the design procedures detailed in the following documents. Note there are versions of each document for the MAX32560 and MAX32570, as these devices have some different features. However, most of the information is the same.

• PCD Antenna Matching Design Guide
• NFC PCD AFE Tuning Guide
• EMV 3.0 Level 1 Analogue Application Note

In addition to this document and the FAQ section in it, always refer to the above documents and procedures for guidance when encountering performance issues. It is important to identify issues as soon as possible while corrective actions (design modifications) can still be taken. Analog performance issues are often not discovered until a design is subjected to a certification debugging test. These issues include but are not limited to:

• Inadequate power delivery over the operating volume of the field.
• Failure to receive weak PICC transmissions from maximum distances inside the operating volume.
• Excessive loading conditions at very close-range, causing violations of signal integrity tests.
• Violation of modulation depth at various locations around the operating volume.

If a specific issue cannot be resolved with careful implementation and consideration of the procedures in the above documents, submit an issue report and request for support from Analog Devices. Include the following information:

• A detailed description of the issue, such as what is failing, how often, how to replicate the issue, specific test case, etc.
• Analog waveforms and logs captured by either tester or oscilloscope showing the problem
• Whether or not the behavior is significantly different from the EV kit

Logging of EMV Level 1 Stack Transactions

The EMV stack includes a robust logging mechanic, implemented by logging.c and logging.h. It supports seven levels from 0 (no logging or debugging) to 6 (full debug displaying all logging, errors, warnings, and informational and debug messages, including contents of the Rx buffer). The default level is 1 logging and produces the information EMVCo requires the DTE to display during testing procedures. The level is easily changed in the DTE example by code modification or through the L. Change Logging Level option in the settings menu of the DTE.

The logging, while required during certification testing, can be disabled using level 0 in application mode to improve throughput performance of the EMV stack. Note that, like all menus of the DTE, the logging messages are displayed serially. For some level 2 tests, full transaction sequences must be completed within a required time period. Reduction of logging is typically required to meet this time constraint. Recall that every UART bit at 115200bps is 8.68µs long, and with 10 bits per character, the time required to display this data adds up quickly. For instance, the previous two sentences are ~300 characters and would take about 26ms to transmit. If the logging level is too high, the increased time required for serial transmission causes some EMV L1 tests to fail due to unmet timing requirements.

Logging is a great first step to use when problems are encountered during testing. Viewing the sequence of events and cause of a failure provide insight to locate issues quickly.

RF Driver Trace Mode

In some extreme cases of troubleshooting, it can be necessary to view debug information in the RF driver. This step is a last resort normally only used by Analog Devices engineers for internal development. If it becomes necessary to obtain support outside of Analog Devices, a separate build of the RF driver is provided. Debug of RF driver operations is difficult due to the timing requirements it must meet. The serial logging used in the stack and higher layers causes massive issues in the RF driver, dropping packets, missed events, etc. To trace and debug operations in the RF driver, a special build writes a trail of data into RAM and processes this data section just before returning from mml_nfc_pcd_transceive. Even this rapid debug operation changes some timing checks in the RF driver that must be modified, requiring the special build. It is impractical to provide optional enabling of this feature into the compiled RF driver library.

FAQ

Why is RF Driver Closed Source?

The contactless peripherals on the MAX32560 and MAX32570 are complex with hundreds of registers. Many of the configuration registers and bits can affect operations in unexpected ways. The RF driver is timing sensitive and must complete certain tasks in short order. Modifications can result in an inability to meet these requirements. The peripherals are also very different between the two device generations. It was determined that providing the source would result in increased customer confusion and support workload without obvious benefit.

What is PBM?

Parity bypass mode (PBM) is an internal name for the MIFARE Classic compatible library. The term is based on the functionality of sending and receiving type A data while ignoring low-level framing, specifically regarding the requirement of the odd parity bit after each 8-bit character.

Why is PBM (MIFARE Compatible) Library Closed Source?

While the library is compatible with MIFARE cards, and details of activation and communications encryption are in the public domain, MIFARE is a registered trademark. Analog Devices is unable to release implementation details.

What is the Memory Footprint of the Contactless Libraries?

The memory usage of the contactless libraries changes with every release of the contactless support package (CSP). Because of this, Doxygen documentation accompanies each release includes a section on contactless library memory usage. The output of arm-none-eabi-size is shown for various files used in the RF driver, PBM library, and EMV L1 stack.

How is the Contactless Library Checksum Created?

EMV level 1 certification requires a library checksum as part of the DTE and certification paperwork. Details are not included for how this checksum is generated. In the DTE example, the files of the RF driver, PBM library, and EMV L1 stack are combined into a binary blob using the cat command, then a sha1sum is generated for this blob. The resulting hash is included in the DTE example code and user guide. Note that this hash/checksum will change with every build of the example as timestamps, etc. are included in the binary files. Refer to the Contactless Library Memory Usage section in the Doxygen documentation accompanying each release for details.

EMV L1 Digital Test Timing Failures

Many of the L1 digital tests are timing related since various timings are negotiated between the PCD and PICC. Some of these times can be up to several seconds. Although there is some allowed margin on these times, the requirements remain tight. The PCD (MAX32560 or MAX32570) requires an accurate time base to meet these requirements. This time base is provided on the MAX32560 by the external 27.12MHz crystal, and on the MAX32570 by the external 27.12MHz crystal, 32.768KHz, and internal 150MHz ring oscillator. The accuracy of the external crystals requires proper compensation with capacitors. Refer to the MAX32560 and MAX32570 datasheets, crystal datasheet, and EV kit schematics for details on the proper capacitance. Due to environmental temperature, improper loading, and normal crystal variances, the accuracy of the system clock can vary by 100ppm or more. This is normally not an issue, as most event timings are so small that the 100ppm only amounts to a minimal number of nanoseconds. However, some of the negotiated delays and wait times can be several million counts. To help compensate for this, the EMV L1 stack has a function pad_for_crystal_margin, which adds a small amount of extra time to long time parameters.

Note that on the MAX32570, the 150MHz internal ring oscillator (IRO) is not as accurate as an external crystal. It is recommended that the calibration routine for it be enabled at device boot. This routine uses the external RTC crystal to regularly tweak the IRO, providing the necessary accuracy. More recent versions of the RF driver for MAX32570 use timers running from the external 27.12MHz for low-level timing. Calibration is still beneficial for system performance.

Other timing failures can be caused by other application code utilizing system timers that are reserved for the RF driver and stack. Refer to the timer section in the RF driver integration guide in the Doxygen documentation accompanying each release.

The RF driver and EMV L1 stack depend on proper implementation of the functions in mml_nfc_pcd_port.c. Particularly, the function mml_nfc_pcd_task_sleep is expected to return after the requested number of milliseconds. Returning excessively early or late can result in timing failures. The RF driver function mml_nfc_pcd_block_for_us is used for many timing operations in the RF driver and stack. It is implemented using one of the system timers detailed in the documentation. If timing issues are detected during testing, it can be useful to call these timing routines directly from test code while toggling external pins or LEDs for various times to verify correct timing through an oscilloscope.

What MIFARE Types are Supported?

The primary MIFARE type supported by the DTE example and PBM library is MIFARE Classic. See the above PBM MIFARE Compatible Classic Library section for more details.

Low-Power, Low-Frequency Operation

An NFC PCD is an inherently high-power device, it is required to broadcast significant power from its antenna to energize the volume of space required by EMV and other specifications. The actual amount of power used by the device to energize the field depends on many variables, including the matching quality of the antenna, parasitics in the field, analog settings, environmental temperature, and supply voltages. Power usage is more critical in battery operated devices but less of a concern in permanently mounted point of sale (POS) terminals that typically have AC power sources available. Reducing system frequency can reduce power but prevents the contactless peripheral from operating correctly; therefore, it should be avoided during NFC operations.

The best way to reduce the power usage of the secure microcontroller with NFC is to limit the amount of time the field is on. The DTE example polling mode is designed as required by the EMV DTE specification. It leaves the field on for the entire time polling is activated to allow test hardware to easily synchronize with the PCD under test; however, this is not the way applications should operate. In fact, leaving the field on for long periods of time can have negative effects as detailed in the Device Self Heating and Dissipation section. Instead, the minimum polling time for the field to be on in EMV applications is a little over 10ms (milliseconds). This provides 5.1ms for cards in the field to power-up, polling for type A cards, 5.1ms until polling for type B cards, and timeout occurs. Assuming no cards are discovered, the application is free to power down the field and enter sleep or idle modes on the microcontroller for several hundred milliseconds before waking up to begin the polling procedure again. The longer time between polling, the less power is expended, although excessive down time can cause noticeable lag in accepting payment. An application note detailing low power NFC/contactless operation will be available soon.

Device Self Heating and Dissipation

Due to the large currents required to generate the NFC field, internal heating of the secure microcontroller can occur as long the field is active. This heat is dissipated through the various pins on the package into the PCB; however, too much heat can decrease output power of the NFC field. During normal operation of the device, when the field is not continuously energized, no loss of performance is expected. Additionally, if the antenna is improperly matched, excessive power can be reflected back into the transmitter. Care must be taken to avoid such a circuit damaging the secure microcontroller. As mentioned in the previous FAQ, continuous operation of the field, as required by the DTE specification for testing, does not reflect real world operation. If the DTE polling and loopback mode is used for too long, excessive heat can slightly degrade performance, potentially causing test failures if inadequate margin is available. Certification test operators should be directed to disable the field periodically allowing cooling and avoiding such situations.

Card Removal Detection

Card removal is one feature provided by the EMV level 1 stack through functions iso_14443_3a_remove and iso_14443_3b_remove. As required by the EMV L1 specification, this command looks for cards continuously, until three sequential wake up commands (WUP) timeout. Use this command after successful card communications and payment sequences, but before proceeding back to normal polling mode. Removal commands are used while in standard EMV loop back testing mode and in the interoperability loop back routines, as required by the DTE.

Abort Operations

Some level 2 kernel certifications have tests where a PICC/card negotiates without completing a transaction. In this and other cases, make use of the set_abort_check_callback. After every call to the RF driver's transceive function, this callback is checked to determine if the current operation (typically an APDU transport) should be aborted if requested by a user or an application timeout. If an operation is aborted, it will return the status ISO14443_3_ERR_ABORTED. Note that due to timing constraints and implementation details, there is no support for aborting calls to the RF driver's transceiver function. It will return after a reception or when the timeout expires.

Release Versions and Change History

When new software versions are released, the version number is increased. For every release, major changes are detailed in the version history for the libraries and DTE example. This history is best viewed in the Doxygen documentation. The actual information is recorded in the following header files: RF driver header file: mml_nfc_pcd_rf_driver.h, EMV stack and DTE example header file iso14443_3_common.h, and PBM Library header file pbm_command.h.

Analog Settings Matrix Size

In a recent release of the CSP, the default analog settings matrix size was increased from 3 to 10. This is a direct result of the changes required to support EMV 3.0 due to the increased complexity caused by the requirements to support three different PICCs with three different loading filters. This required more configurability for nontrivial antenna and system designs. Most designs do not need to use all 10 columns of the matrix. Any columns not required should be filled with the contents of the last unique column, to avoid any unexpected analog behaviors. The matrix size (i.e., number of columns) can be modified as necessary using the define FD_THRESH_NUM_STEPS in mml_nfc_pcd_port.h and updating all mml_nfc_pcd_analog_params_matrix_t structures.

EMV Level 1 Test Reports

Each release of the CSP includes EMV level 1 analog and digital test reports generated in-house on a Micropross contactless test station. They are compiled into the Doxygen generated documentation file NFC_PCD_CSP.chm accompanying each release.

Test Equipment Differences

Analog Devices validates EMV compliance of each CSP release on our secure microcontrollers using the EMV level 1 analog and digital test suites on a Micropross contactless test station. Many different vendors provide PCD test tools, including Keolabs, Comprion^®, CI Labs, Keysight^®, and others. While each of these vendors is compliant with and certified by EMVCo, small differences are found between them, such as slightly different analog loading conditions, speed of testing, and some tests passing on one system but failing on others. Different certification laboratories use different vendors for test equipment; some have their own test solutions developed in-house. Due to these differences, consider which laboratory to use based on the equipment used in-house. Once selected, continue to use that lab to minimize certification issues.

Non-EMV Cards and Responses Disallowed by the Stack

Although the prime target for the EMV L1 stack provided by Analog Devices is to support EMV payment cards, it can be used to communicate with other cards compliant with ISO 14443 books 1 to 4. However, not all features are provided by the stack which some non-EMV cards support or require. For instance, EMV does not allow multiple cards in the field simultaneously and is only expected to operate at the slowest rate of 106Kbps. Furthermore, some cards return activation parameters that can be rejected by the stack. For example, SCOSTA Indian transport cards have ATTRIB responses, including high information filed (INF) data. This is not allowed in EMV, and results in errors with the ATTRIB command.

Other cards violating requirements (e.g., not obeying timing requirements) can also be supported, but doing so requires modification of the stack.

How to Meet EMV 3.0 Field Power Requirements

EMV 3.0 requires significantly more field power than previous versions. Meeting these requirements can be difficult for some designs, such as the MAX32560, which was designed to meet EMV 2.5 requirements. See the Power Delivery section for more details. Extensive guidance on achieving the power requirements is detailed in the Contactless PCD Application Note – EMV 3.0 Level 1 Analog application note for each device.

Recommend Antenna Parameters

There are unique concerns regarding size, shape, placement, etc. when selecting an antenna. The inductance should be between 1 and 1.5µH @ 13.56MHz, in general. If the antenna is too small, power can fail at longer distances. If it is too large, the integrity of the signal at close distances can be compromised. Impedance and resistance can be kept relatively low if using a PCB antenna, usually 1µH and 1Ω. Excessive resistance decreases tuning flexibility in terms of Quality Factor (Q).

How to Select EMC Filter Inductors

The purpose of the EMC filter is to reduce radiated signals to below EMC compliant thresholds. Consider the following requirements:

• Product design, overall size, and profile limitations can dictate which inductors are selected based on their package size.
• Analog Devices recommends a cutoff frequency of 20MHz which can be achieved with 270nH inductors and 240pF capacitors. Other combinations are available to achieve the same cutoff frequency, such as 470nH and 130pF. Larger value inductors can cost more, especially if using wire-wound power inductors.
• Inductors are the largest and most critical component in the EMC filter. Since the inductor is in a series connection in the circuit, adequate current handling capability is important. We recommend the inductors tolerate 1A or more. Higher Q at 13.56MHz is critical to achieving maximum power delivery to the field. Lower Q increases effective resistance in the transmit circuit and reduces available power. The output voltage of the transmitter is 3.3V, meaning the current of the circuit greatly effects field power.
• Tolerance of the inductor should be as tight as possible to reduce device-to-device variation. This is true for most components in the matching network where 1% capacitors and 2% inductors are recommended. Use of looser tolerance components can result in excessive performance variation in the final product.

Matching Network PCB Trace Width Recommendations

At the 13.56MHz operating frequency, PCB trace width and length is not the key factor of matching in general. The top consideration is current handling vs. PCB trace width and thickness. A typical 1oz copper thickness PCB design with 10mil (0.25mm) trace width can tolerate 1A current. In Analog Devices' 65mm × 65mm evaluation antenna board, the antenna trace width is 0.4mm. As every design is different, ideal PCB design can vary with design constraints and restrictions. Verify adequate power handling with the PCB vendor.

Total Matching Impedance is Higher Than Suggested Value (6Ω—10Ω)

The calculation tool is not perfectly accurate, and SMD components do have some variation. For slightly off (~2Ω or less), tune the de-Q resistor to make it match. In more extreme cases, verify the values from the calculation tool and measure the component values used in the actual circuit. Although the matching calculation tool is not perfectly accurate, it should still be close; however, an excessively high impedance can indicate an issue, such as incorrect component in the circuit.

What is the Optimal or Recommended Q Value for Contactless Antennas?

Ideally, the antenna Q value should be larger than 60, which is relatively easy to achieve. Given 1µH of inductance, the resistance should be less than 1.42Ω, which typical PCB design and vendors can easily achieve. While this is not a strict requirement, it provides adequate tuning flexibility with de-Q resistor and Rmatch selection.

Issues at 0cm

While adequate power delivery is of prime concern at far operating volume distances, extremely close-range tests at 0cm signal integrity are the most difficult tests and performance metrics to achieve. Specifically, EMV L1 analog test suite parameters t3 and t4 can have issues (e.g., t3 is too fast), along with overshoots in signal integrity. These issues are exacerbated as loading effect increases, particularly with the EMVCo test PICC2 with HLZ. PICC1 can exhibit similarly, but PICC2 is the worst. The most straightforward solution is adding a 5mm or less offset at 0cm to decrease the coupling without hardware. This occurs often with normal physical product design since the coil is enclosed to some degree. Otherwise, redesign of the PCD antenna (smaller L), matching, and EMC filter (i.e., lower cut-off frequency) may be required. The offset at 0cm applies to all test positions unreachable by EMVCo reference PICCs due to the shape of the terminal. If the offset is below 5mm, the qualification lab can measure and apply it during type approval testing to all applicable test positions. Include this information in the type approval report. If the offset is 5mm or more, it must be communicated to EMVCo prior to the type approval session. Refer to section 6.2.2 of the Analogue Test Bench and Test Cases Requirement v3.0a test cases for more information.

Are FeliCa Cards Supported?

Yes and no. FeliCa cards, also known as type C, NFC-F, and JIS X 6219-4, are not part of EMV. As such, the EMV level 1 stack provided by Analog Devices does not support FeliCa cards. However, the RF driver provides low-layer support for them at the transceiver function level. The DTE example provides an activation example using the command ATQC and interprets the response. It also provides a loop test routine required for FeliCa reader/writer RF performance testing, which if roughly equivalent to the EMV level 1 analog testing. Full support for polling, activation, selection, secure handshaking, and higher-level data transport are not provided by Analog Devices and must be implemented. Alternatively, FeliCa stack software supporting these higher-level features can be procured separately from other vendors and interfaced to the RF driver.

What Software Does Analog Devices Provide to Support EMV, MIFARE, FeliCa, and Vicinity Cards?

Analog Devices provides example software demonstrating support for EMV, MIFARE, FeliCa, and Vicinity with the MAX32570 only. Since the primary target for these devices is payment, we provide more support for EMV cards and devices provided by the EMV L1 stack code released as part of the DTE and demo examples. Low-level support is provided for MIFARE, FeliCa, and Vicinity cards, as well as non-EMV ISO 14443 cards through the RF driver for each secure micro. For MIFARE Classic cards, the PBM library provides basic command and authentication processing. See the respective sections for more details on support for all these card types.

What External Circuitry is Required for the Contactless Interface?

A suitable antenna and tuned matching network with EMC filter are required for contactless communications. Exact external components depend on application and system design. Refer to the PCD Antenna Matching Design Guide, EV kit schematic, and gerber files for more details and example implementations.

Are Analog Devices' Secure Micros Compliant with EMVCo Contactless Version 3.0?

Yes, both the MAX32560 and MAX32570 are compliant and support EMV 3.0 requirements. Proven test reports from third party laboratories are available on request.

Does Analog Devices Provide EMV Level 2 Solutions?

Analog Devices EMV and payment application support ends at level 1. However, we partner with Amadis, an industry leader in level 2 software and payment application software.

Level 2 Test Issues

Several level 2 certification suites include special test cards and mobile devices with required percentages of successful read attempts. These cards and devices are not available for in-house testing and are not publicly documented. The payment provider is responsible for the level 2 test supplies, test cards, and devices, which are updated periodically and kept confidential. For these tests, Analog Devices cannot provide direct assistance. Even after passing level 1 testing with the three required test PICCs with different load conditions and EMV L1 interoperability testing, designs are not guaranteed to cover all the cases. Some of the test devices and cards can be difficult to work with but can usually be supported with careful adjustment to the analog matrix parameters. These test devices can differ between certification laboratories. Select one lab and use debug sessions to optimize the required settings before certification submission at the same lab.

Collision Detection

Each physical type specification provides its own mechanism for collision detection. Some level 2 certifications (i.e., PBOC) require demonstration of collision detection by a POS terminal. Note that collision detection works better for some types than others. Due to the nature of PCD use cases, typically as POS or ticketing, collision detection is only considered from multiple PICCs in the field. It is beyond test and most specification considerations to look for other active fields in range of the primary reader. This is normally enforced with physical security and the relatively small size of the communications field. This is not true for the ISO 18092 specification, which allows for multiple initiators (i.e., readers, field generating devices). There are several methods of collision detection of multiple PICCs in the field.

• Collision can be detected based on protocol type bit encoding methods. Type A PICC to PCD only allows the first half of a bit time modulated (sequence D), the second half (sequence E), or no modulation (sequence F). If modulation is present for the entire bit time, it is considered a collision. Note this is only possible during the activation phase of communications with type A cards. Card responses are required by specification to begin simultaneously for all cards in the field, meaning all card responses are stacked on top of each other for each bit time.
• Simultaneous transmission of more than one PICC degrading signaling can cause framing or CRC errors. For instance, if type B is requested to respond simultaneously (as required by EMV L1 procedures within timeslot 0, N = 1), the dueling subcarrier can degrade and combine in ways that result in start and stop bit errors or gaps appearing in the received data. This is not a reliable method, since a PICC with strong signaling (i.e., high amplitude field modulation) can have 10 times as much signal as weak cards at the periphery of the field, especially when close to the PCD antenna. The high amplitude signal from one card can conceal the weaker response.
• A collision can be detected by following the anticollision polling procedures detailed in each type's specification. For type A, all cards in the field begin transmitting their unique identifier (UID) simultaneously, until a bit-wise collision is detected. For types B and F, multiple response timeslots are provided for cards to randomly choose to respond in. Multiple rounds of these procedures identify unique cards, which can be targeted specifically and silenced while more cards are searched for. After enough rounds, and no more cards are discovered, activation can continue for the found cards. Again, EMV does not allow this, requiring all cards in the field to respond in one time slot. Any collision detected requires resetting the field and polling again.
• Finally, the polling loop is used to determine when multiple devices of different physical types are present in the field. EMV L1 does not allow activation if more than one device of any type is found in the field. The polling loop example provided and used for EMV mode does not poll for other technologies besides EMV A and B types. This can be extended as applications require.

While EMV requires type B cards in the field to respond in the first time slot (N = 1), it expects that the asynchronous responses will cause a transmission error. Refer to the EMV L1 Specification for more information. Although this can happen, it is not guaranteed. EMV does not require direct collision detection testing of this at level 1; however, some level 2 tests do require it. Depending on the testing condition, a collision may or may not be detected. If such a test is required, it is recommended that the test operator be informed of this. If still required, use two cards of the exact same type with similar or identical load modulation amplitude. This is more likely to cause transmission errors, as one card will not be able to mask the other's signal. As a last resort, it is possible to tweak the analog settings matrix sufficiently to detect the area of collision where the two PICC amplitudes combine to distort the waveform.

It is more reliable to use the probabilistic time slot collision detection method for type B. Since this requires N > 1, it is not allowed by EMV for, at least, level 1). It can be allowed for other certifications, such as level 2, etc.

Interrupt Usage and Data Loss on Non-NFC Peripherals

While the RF driver on the MAX32560 is actively transmitting and receiving, it enters a critical section. Although the active time (i.e., duty cycle) is low compared to the overall polling time, during active communications, such as APDU transport and purchase sequences, interrupt service is delayed for significant amounts of time. If other system peripherals rely on ISRs to process fifo data or respond to commands within tight timing requirements, this can lead to data loss, missed communications, excessive ACK/NAKs, etc. Some peripherals that can suffer from this behavior include serial UART, SPI, I2C, USB, smart card, and MSR. It is recommended to use DMA with application critical peripherals to avoid potential data loss. The system may function better utilizing a polling methodology versus interruption, but this depends on the individual system and application requirements. Currently, the RF driver on the MAX32570 only enters critical sections for short amounts of time; however, this can change in the future. Review change history for each new CSP release version for such potential changes.

Trademarks

• Apple Pay^® is a registered trademark of Apple Inc.
• Bluetooth^® is a registered trademark of Bluetooth SIG, Inc.
• Calypso^®is a registered trademark of Calypso Technology, Inc.
• Comprion^® is a registered trademark of GmbH
• DESFire^® is a registered trademark of Koninklijke Philips Electronics
• Eclipse^® is a registered trademark of the Eclipse Foundation
• EMV^® (Eurocard^®, Mastercard^®, Visa^®) is a registered trademark of EMVCo
• FeliCa^® is a registered trademark of Sony Kabushiki Kaisha TA Sony Corporation
• iClass^® is a registered trademark of HID Global Corporation
• Innovatron^® is a registered trademark of Innovatron Solutions Corporation
• Keysight^® is a registered trademark of Keysight Technologies, Inc.
• MIFARE^® is a registered trademark of NXP B.V.
• MIFARE Classic^® is a registered trademark of NXP B.V.
• MIFARE Plus^® is a registered trademark of NXP B.V.
• MIFARE Ultralight^® is a registered trademark of NXP B.V.
• Nokia^® is a registered trademark of Nokia Corporation
• NXP^® is a registered trademark of NXP B.V.
• PayPass^® is a registered trademark of MasterCard International Incorporated
• payWave^® is a registered trademark of Visa International Service Association
• Samsung Pay^® is a registered trademark of Samsung Electronics CO., Ltd.
• Sony^® is a registered trademark of Kabushiki Kaisha TA Sony Corporation