How to Speed NFC Integration in OS-Based Applications

Contributed By Digi-Key's North American Editors

Developers have historically faced a series of challenges in optimizing RF performance, hardware design, and software in near-field-communications (NFC) designs. Now, however, the availability of monolithic NFC solutions and comprehensive software support has significantly changed the nature of incorporating NFC functionality into designs for home electronics, wearables, and devices for the Internet of Things (IoT).

As a result, developers can add a wealth of application features with little impact on design footprint, power consumption, or project schedules.

NFC’s bidirectional communication is unique in its ability to provide simple, inherently secure, low-power proximity wireless connectivity. Communications are only possible when two devices are brought close together, so message interception is unlikely and potential cyberattack vectors are minimized. Furthermore, only one of the two devices needs to be powered at a time for communications, so average power consumption remains low.

Indeed, NFC can provide significant benefits to a wide range of smart-home and IoT applications. Users can complete Bluetooth or Wi-Fi pairing simply by bringing an NFC-enabled smartphone near an NFC-enabled product. NFC can serve as the underlying enabler for device personalization and simplify smartphone tasks such as configuring settings, transferring data, or registering products.

Embedded NFC

A subset of radio-frequency identification (RFID), NFC operates at 13.56 MHz and performs many of the same functions as conventional RFID tags and contactless smartcards. At the same time, NFC offers further flexibility with its ability to operate in one of three communication modes: card emulation, peer-to-peer, and read/write.

In card-emulation mode, an NFC device functions as a contactless smartcard, allowing its use in a wide range of existing applications including ticketing, access control, transit, tollgates, and contactless payments. Peer-to-peer mode allows two NFC-enabled devices to connect and exchange information. For example, users can use an NFC-enabled smartphone to set Bluetooth or Wi-Fi setup parameters in other devices, or commission their use in trusted networks. In read/write mode, an NFC device can read data from another NFC device. For example, an NFC-enabled smartphone can read URLs or other data such as sales coupons embedded in promotional signage at a retail store.

Connected to the host processor within a product, an embedded NFC device serving as a tag operates similarly to dual-port memory. One of the memory ports is accessed wirelessly through an NFC interface. The other port is accessed by the embedded system via an I2C interface. As a result, an external source such as a smartphone can pass data to the embedded system. In turn, the host processor can update data stored in the NFC device, making it available to the external NFC-enabled device even when the product is powered down.

Developers can use this approach in any application that requires data transfer between an embedded system and an external system such as an NFC-enabled smartphone. In fact, developers can use this approach to update the embedded system's data or even firmware, using the NFC device's wireless connectivity for communications and its on-chip memory for temporary storage during the download process.

Monolithic NFC controller

In the past, designers looking to add NFC features to an MCU-based design faced significant challenges in both hardware and software. Hardware engineers using conventional NFC devices needed to ensure that the design met critical timings between the NFC device and host, maintained low power requirements, and minimized design footprint and the bill of materials (BOM). Perhaps the greatest impact lay on the software side, however, where engineers often had to write their own code to handle the many low-level transactions that can make up a single application-level NFC operation.

Advanced NFC devices, such as the NXP Semiconductor PN7150, are designed to simplify the inclusion of NFC functionality in an IoT design, or any embedded system. The PN7150 combines an RF frontend with a low-power ARM® Cortex®-M0 core, memory, and I/O peripherals (Figure 1).

Diagram of NXP Semiconductors PN7150 NFC controller

Figure 1: The NXP Semiconductors PN7150 NFC controller combines a complete RF frontend, an ARM Cortex-M0 device host, and integrated firmware. (Image source: NXP Semiconductors)

The device largely eliminates traditional hardware-integration problems by ensuring optimal timing between embedded device host and the RF frontend, while supporting higher RF output power. In addition, the integrated I2C interface is compatible with NXP's NTAG I2C Plus for sensors, light fixtures, and other devices associated with smart-home networks. Furthermore, the device helps reduce power requirements: The PN7150 can automatically transition to low-power mode, while letting the host remain in sleep mode until RF communication is required.

Along with simplifying hardware design, the PN7150 offers significant advantages on the software side. NXP preloads the device's embedded data and code memory with extended support for the NFC controller interface (NCI). Managed by the NFC Forum, the NCI technical specification defines the logical interface between an NFC controller (NFCC) and a device host (DH) running a high-level OS such as Android, Linux, or Windows IoT.

The PN7150's embedded NCI firmware lightens the software development burden by reducing certain host interactions and providing a higher level of abstraction for NFC application software developers. By moving low-level code to firmware, the PN7150 also reduces the application-code footprint on the host side.

Drop-in solution

With its integrated hardware and software, the PN7150 is designed as a drop-in NFC solution for developers working in Android, Linux, or Windows environments (Figure 2). In fact, developers new to NFC development can take advantage of available PN7150 demo kits for Arduino (NXP OM5578/PN7150ARDM), BeagleBone Black (NXP OM5578/PN7150BBBM) and Raspbery Pi (NXP OM5578/PN7150RPIM). Each kit includes a PN7150 NFC controller board, a dedicated interface board, and a NFC sample card.

Diagram of NXP PN7150 (click for full-size)

Figure 2: The NXP PN7150 requires few additional components to deliver a complete NFC subsystem that integrates easily with the host MCU through a simple hardware interface and with host software through the NCI protocol. (Image source: NXP Semiconductors)

Designers need few components to create a complete NFC subsystem for an existing MCU-based design. In fact, in some cases, engineers can further reduce the BOM by eliminating or combining some passive components in the antenna matching circuit (Figure 3).

Diagram of PN7150 as the NFC controller (NFCC)

Figure 3: Using the PN7150 as the NFC controller (NFCC), designers can further reduce the BOM in some applications by simplifying the antenna matching circuit. (Image source: NXP Semiconductors)

In a typical antenna circuit design, RQ damping resistors on the antenna leads are needed to lower an excessively high antenna quality factor, which can negatively impact the generated signal shaping. In a design with a nominal antenna quality factor, designers can remove these RQ damping resistors from the antenna ends. In the matching circuit itself, designers can replace the pair of parallel capacitors with a single capacitor (and eliminate the connection to the EMC filter) when a particular design exhibits a sufficiently low maximum peak-to-peak voltage at the antenna leads. In the typical application, where a small antenna is connected to the PN7150, the peak-to-peak voltage generated at the antenna leads will be relatively low. Consequently, designers can also simplify the Rx path by removing the decoupling Crx capacitors and directly connecting the Rrx resistors to the antenna.

Simplified software

From the software perspective, the PN7150 offers a simple execution model that further speeds product development (Figure 4). The device host architecture combines a transport layer driver, NCI driver, and NFC execution environment (NFCEE) middleware containing the reader/write, peer-to-peer, or card emulation libraries. For NFC operations, the host only needs to send high-level NCI operations to the PN7150 through the I2C interface. In turn, the PN7150's firmware executes the detailed transactions required in the NFC protocol.

Diagram of NXP PN7150's embedded NCI firmware

Figure 4: The NXP PN7150's embedded NCI firmware reduces the software footprint on the device host (DH), which only needs to send NCI commands through the I2C hardware interface for execution of detailed NFC transactions on the PN7150 NFC controller (NFCC). (Image source: NXP Semiconductors)

Indeed, from the developer's point of view, NFC applications development proceeds at a high level thanks to the comprehensive software platform available from NXP. For NFC-enabled IoT applications, a common operation involves exchange of data formatted in NFC data exchange format (NDEF). Managed by the NFC Forum, NDEF is a standardized data format that can be used to exchange information such as URIs or plain text between any compatible NFC device and another NFC device or tag.

The NXP linux_libnfc-nci library provides a simple application programming interface (API) that abstracts low-level transactions into higher-level applications-oriented operations. For example, developers can write to a tag with a simple call to a WriteTag routine (Listing 1). The library uses a series of lower-level routines to decompose this application-level request into the series of steps required to validate, format, and transmit the data (msgToPush in Listing 1).

int WriteTag(nfc_tag_info_t TagInfo, unsigned char* msgToPush, unsigned int len)

{

            int res = 0x00;

           

            res = nfcTag_writeNdef(TagInfo.handle, msgToPush, len);

            if(0x00 != res)

            {

                        printf("Write Tag Failed\n");

                        res = 0xFF;

            }

            else

            {

                        res = 0x00;

            }

            return res;

}

Listing 1: NXP provides NCI software such as linux_libnfc-nci, which is a Linux NFC library for use with the PN7150. Developers can create NFC applications using simple calls such as WriteTag, which calls lower level routines to handle NFC messaging-protocol details. (Listing source: NXP Semiconductors)

A device host uses NCI control messages to interact with an NFC controller. A particularly important NCI command sequence provides a mechanism for an NFC controller to find other cards, readers, or peers. This command sequence, called RF Discovery, causes a compliant NFC device, such as the PN7150, to alternate between listening for other transmitting devices and transmitting (poll phase) to find a remote card or tag.

As with any RF technology, transmission requires significantly higher power than radio reception (Figure 5). Indeed, in the poll phase, the PN7150 consumes about 30 mA, depending on antenna characteristics. During the listen phase, the PN7150 is waiting for an externally generated RF carrier and current consumption drops to around 20 μA when standby mode is enabled.

Diagram of NXP NFC devices

Figure 5: NFC devices can exhibit relatively high power requirements due to an extended poll phase in the standard NFC Forum RF Discovery sequence. (Image source: NXP Semiconductors)

Typically, the poll phase lasts about 20 ms while the listen phase is 300 ms to 500 ms in length. For a 500 ms listen phase, average power consumption then becomes:

(30 x 20 + 0.02 x 500) / 520 = 1.17 mA.

To reduce power requirements for RF Discovery, the NXP N7150 offers a proprietary mechanism called low power card detector (LPCD) mode. In LPCD mode, the PN7150 looks for changes in antenna impedance due to the magnetic coupling that results when another device enters its proximity. If the change in impedance is higher than a pre-defined threshold, the PN7150 automatically enters the standard NFC Forum RF Discovery sequence. Consequently, this "event-driven" approach can significantly reduce the duration of the RF Discovery phase, resulting lower average power consumption (Figure 6).

Diagram of NXP PN7150

Figure 6: The NXP PN7150 can significantly reduce power consumption for the RF Discovery loop by using a special detection mode to reduce the duration of the power-draining poll phase. (Image source: NXP)

Conclusion

NFC offers secure, low-power connectivity that can significantly enhance ease-of-use for connected products in home electronics, wearables, and other IoT devices. By simply bringing an NFC-enabled smartphone near a connected product, users can commission the product, load access information, and retrieve information stored on the product. In the past, however, NFC implementation in MCU-based systems brought design challenges for both hardware and software integration. In contrast, integrated NFC devices such as the NXP PN7150 provide a near drop-in solution for NFC designs, simplifying both hardware and software development of NFC-enabled applications. 

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this publisher

Digi-Key's North American Editors