How to Rapidly Add NFC Capability to Any Application

Contributed By Digi-Key's North American Editors

To meet the growing demand for near-field communications (NFC) capability, developers are being asked to quickly create optimized designs. Conventional approaches slow development as designers work though challenges such as RF circuit optimization, NFC protocol management, power consumption, and minimal design footprint.

To help developers overcome these challenges, companies such as NXP have introduced ICs and support hardware and software that provide a simpler approach to adding NFC capability to an application.

This article will briefly discuss how NFC has evolved beyond basic point of service (POS) applications. It will then introduce the NXP LPC8N04 NFC solution before discussing how to go about using it to create efficient NFC designs able to support a broad range of applications.

Why NFC

NFC has emerged as an important feature in applications beyond its original use in point of sale payment scenarios. Developers are leveraging ubiquitous support for NFC in smartphones and other mobile devices to simplify control of equipment in consumer, industrial, and other segments.

Simply by bringing their smartphone close to a smart toy, home appliance, or network device, users can easily and securely configure and control the target system. The smartphone RF field from the initiator, called the proximity coupling device (PCD), energizes the target, called the proximity inductive coupling card (PICC).

With this approach, any ISO 14443-compatible PCD and PICC can perform two-way communications by modulating the RF field with data according to modulation and coding schemes specified in the standard.

NFC MCU

The NXP LPC8N04 MCU provides a cost-effective solution for NFC design. Based on an Arm® Cortex®-M0+ processor core, this 4 x 4 mm 24-pin MCU combines a complete NFC/RFID subsystem with serial interfaces, GPIOs, and memory, including 32 Kbytes of flash, 8 Kbytes of SRAM, and 4 Kbytes of EEPROM. Along with its inherent low-power requirements, its ability to operate solely off harvested RF energy makes it well suited for batteryless connected systems for the Internet of things (IoT), smart tags in standalone systems, or any application requiring an optimized NFC solution.

To simplify development, the LPC8N04 integrates the Arm Nested Vectored Interrupt Controller (NVIC) and Serial Wire Debug (SWD). Implemented here with two watchpoint comparators and four breakpoint comparators, SWD provides a bidirectional data connection for JTAG test and debug, as well as run-time access to system memory without requiring additional software on the device. In addition, the LPC8N04 firmware provides a complete application programming interface (API) for erasing flash sectors, copying data to flash, reading the factory programmed unique device serial number, and more.

Of course, the functionality of primary interest for this article resides in its NFC subsystem. Intended to support the growing set of NFC-enabled applications, the device provides complete NFC two-way communications capability using 13.56 MHz proximity signaling. The device is compatible with a wide range of NFC specifications including NFC/RFID ISO 14443A, NFC Forum Type 2, and MIFARE Ultralight EV1 PICC standards.

The subsystem provides a simple interface model for both hardware and software connections (Figure 1). For the hardware interface, the subsystem’s 50 picoFarad (pF) internal capacitance is compatible with standard NFC antennas such as the Molex 1462360021. Consequently, developers can attach an off-the-shelf antenna to the LPC8N04’s LA-LB pins. Furthermore, the device recovers its clock from the RF field, eliminating the need for additional clock components.

Diagram of NXP LPC8N04 MCU’s integrated RF subsystem

Figure 1: The NXP LPC8N04 MCU’s integrated RF subsystem provides antenna connection at its LA-LB pins, and a software interface that accesses registers and SRAM. (Image source: NXP)

Functionally, the registers (CMDIN, DATAOUT, SR) and SRAM used in NFC READ/WRITE operations all map to shared memory with access managed by an integrated arbitration unit. During a communication session, the external NFC/RFID initiator reads and writes the registers or SRAM. In turn, firmware running on the LPC8N04’s Arm Cortex-M0+ core accesses the registers and SRAM, parses the messages, and replies as appropriate using the same shared resources. To protect the communication channel, developers can use the MIFARE protocol’s password authentication method to allow or block access as needed.

This entire communications sequence starts when the external initiator transmits an RF field within range of the LPC8N04. The RF field can be used to wake the LPC8N04 from low-power sleep modes and serve as its sole power source, as described below.

Power management

Power consumption is typically a critical concern in these applications. In the past, developers have often found themselves forced to compromise functionality and performance to minimize power. With the LPC8N04, developers can utilize a number of device features to tune power utilization and performance to meet requirements.

Among typical approaches for reducing power, developers have routinely modified the system clock frequency. With the LPC8N04, developers can use this approach to significantly reduce power consumption (Figure 2). At its maximum 8 MHz clock frequency, the LPC8N04 consumes approximately 900 microamps (µA). A reduction to a 1 MHz clock rate drops power consumption to around 200 µA. Besides adjusting system clock rate, developers can also take advantage of a number of different power modes that reduce power consumption by selectively shutting down portions of the LPC8N04.

Graph of reducing NXP LPC8N04 current consumption by reducing the system clock frequency

Figure 2: Developers can significantly reduce LPC8N04 current consumption by reducing the system clock from its 8 MHz maximum frequency (curve 6) to 4 MHz (5), 2 MHz (4), 1 MHz (3), 500 kHz (2), or even 250 kHz (1). (Image source: NXP)

As with most complex devices, the LPC8N04 organizes subsystems into distinct power domains for memory and analog peripherals; for the digital core and peripherals; and for circuits such as the real-time clock (RTC) and brown-out detector (BOD) that need sustained power (Figure 3). In turn, an integrated power management unit (PMU) enables and disables the low-dropout (LDO) regulators that power the analog and digital power domains.

Diagram of NXP LPC8N04 MCU’s power architecture

Figure 3: In the NXP LPC8N04 MCU’s power architecture, a power management unit (PMU) supports multiple low-power modes by selectively enabling or disabling low-dropout (LDO) regulators supplying analog and digital power domains. (Image source: NXP)

By setting bits in the LPC8N04 power control (PCON) register, developers program the PMU to control power to these domains in three low-power modes:

  • In sleep mode, the PMU maintains power to both domains – providing power reduction while permitting rapid resumption of processor function and instruction execution.
  • In deep sleep mode, the PMU disables only the analog domain – providing the lowest power mode that retains processor state, peripheral registers and internal SRAM, but requiring incremental power-up time for access to non-volatile memory.
  • In deep power-down mode, the PMU shuts down both analog and digital domains, reducing power consumption to only 3 µA at the cost of a longer delay for restoration of processor state and instruction execution.

In all three of these low-power modes, the PMU shuts down the processor core. As a result, the use of low-power modes incurs an incremental wake up time for returning to full active mode. Of course, that wake up time grows longer with deeper low-power modes. In practice, however, wake up times are likely to be fast enough for most NFC applications. In the worst case, the total startup time for achieving active mode from the application of power and power-on reset is only about 2.5 milliseconds (ms).

RF energy harvesting

The LPC8N04’s relatively fast wake-up time provides developers with an opportunity to take advantage of the device’s ability to harvest energy from the initiator’s RF field itself. When VNFC (the voltage extracted from the RF field) rises above threshold, a source selector in the device’s power architecture automatically switches the device’s power supply from a battery to the harvested energy supply (see Figure 3 again). Developers can operate the LPC8N04 solely from this source or just use RF energy harvesting as a battery-backup source. Although the source selector unit automatically chooses the best source, developers can force selection of VBAT or VNFC as application requirements dictate.

In practice, the ability to power the LPC8N04 from harvested RF energy depends on the RF field strength emitted by the external reader, and the efficiency of the receiving antenna circuit connected to the LPC8N04. As noted earlier, developers need only connect a suitable antenna to the LPC8N04’s LA-LB pins. In practice, however, the ability to maximize received energy depends on an optimally designed antenna circuit.

As with any RFID/NFC design, the inductance of the antenna forms a resonance circuit with the RF front end’s total input capacitance (antenna, receiver, and connection parasitics). The total resistance of that assembly defines the quality factor, which relates to the resonance circuit’s performance and field strength. For example, higher connection resistance lowers the quality factor, reducing the effective transmission range for the RF transmitter.

A further complication in designing a suitable antenna arises from the dependence of the input capacitance and input resistance on the input voltage (VLA-LB for the LPC8N04). As input voltage changes, the associated change in input capacitance results in a change in the resonance frequency, while the associated change in the input resistance results in a change in the quality factor. Antenna design experts typically account for these changes by designing to the minimum input voltage.

Rapid development platform

Although simple in concept, implementation of an efficient NFC design from scratch can slow developers looking to rapidly deploy applications that leverage the widespread availability of NFC-enabled smartphones. Rather than create their own system, developers can immediately begin developing NFC applications by building on the NXP LPC8N04-based OM40002 development board. The combination of the LPC8N04 board and associated NXP software development package provide an immediate NFC solution, as well as a platform for creating custom hardware designs and software applications.

The OM40002 board comprises two sections separated by a breakable interface (seen as the vertical line between notches in Figure 4). The main processor (MP) section includes an LPC8N04 on the top of the board (Figure 4A, right) and integrated antenna on the bottom (Figure 4B, right). The debug probe (DP) section includes an NXP Arm Cortex-M0 LPC11U35FHI33 MCU and debug resources (Figure 4A, left). On the bottom of the DP section (Figure 4B, left), a 5 x 7 LED array and a surface mount speaker provide a simple user interface mechanism for the sample application included in the development package. During development, engineers can use the full board as a complete system. For custom designs, developers can use the full board to debug their application software and later detach the MP section to use as a standalone NFC subsystem.

Image of NXP OM40002 board

Figure 4. The NXP OM40002 board combines a debug probe (DP) section (left side of A and B) and main processor (MP) section, allowing developers to detach the MP section to add this complete NFC subsystem to their own designs. (Image source: NXP)

The board comes pre-loaded with a sample application running as firmware on the LPC11U35FHI33 MCU. Using the board’s LED array and speaker, the application demonstrates bidirectional NFC data exchange format (NDEF) messaging between the LPC8N04 and an NFC-enabled smartphone running a free Android app provided by NXP. Used by most NFC-enabled smartphones and other mobile devices, NDEF is a lightweight format that encapsulates arbitrary data into a single message. With the sample Android app, developers can gain a clearer understanding of the type and size of data that can exchanged via NDEF between their smartphones and the OM40002 board.

NDEF processing

Beyond its straightforward demonstration of capability, however, the sample application provides developers with key design patterns for using the LPC8N04 to process NDEF messages. Included in the NXP software development package, low-level service routines handle register level transactions, while a sample application illustrates higher level operations. Included in the development package, a main routine shows how developers would initialize the LPC8N04 hardware and associated software structures prior to a main processing loop (Listing 1).

int main(void)

{

                int temp;

                uint16_t decPosition, digit, prevDigit, index, textSize;

                uint32_t tempSpeed;

                bool initDispStarted = false;

                PMU_DPD_WAKEUPREASON_T wakeupReason;

    Init();

    wakeupReason = Chip_PMU_PowerMode_GetDPDWakeupReason();

    if(wakeupReason == PMU_DPD_WAKEUPREASON_RTC) {

                /* Blink LED for second */

                LPC_GPIO->DATA[0xFFF] = 0xE60U;

                Chip_TIMER_SetMatch(LPC_TIMER32_0, 2, 1000*100 + Chip_TIMER_ReadCount(LPC_TIMER32_0));

                Chip_TIMER_ResetOnMatchDisable(LPC_TIMER32_0, 2);

                Chip_TIMER_StopOnMatchDisable(LPC_TIMER32_0, 2);

                Chip_TIMER_MatchEnableInt(LPC_TIMER32_0, 2);

                __WFI();

    }

    else {

    . . .

      /* Wait for a command. Send responses based on these commands. */

      while (hostTicks < hostTimeout) {

    . . .

        if ((sTargetWritten) && takeMemSemaphore())  {

          sTargetWritten = false;

          if (NDEFT2T_GetMessage(sNdefInstance, sData, sizeof(sData))) {

            char * data;

            uint8_t *binData;

            int length;

            NDEFT2T_PARSE_RECORD_INFO_T recordInfo;

            while (NDEFT2T_GetNextRecord(sNdefInstance, &recordInfo)) {

              if ((recordInfo.type == NDEFT2T_RECORD_TYPE_TEXT) && (strncmp((char *)recordInfo.pString, "en", 2) == 0)) {

                data = NDEFT2T_GetRecordPayload(sNdefInstance, &length);

                strncpy(g_displayText, data, (size_t)length);

                g_displayText[length] = 0;

                g_displayTextLen = (uint8_t)length;

                eepromWriteTag(EE_DISP_TEXT, (uint8_t *)g_displayText, (uint16_t)(((uint16_t)length+4) & 0xFFFC));

                startLEDDisplay(true);

              }

              else if((recordInfo.type == NDEFT2T_RECORD_TYPE_MIME) && (strncmp((char *)recordInfo.pString, "application/octet-stream", 24) == 0)) {

                binData = NDEFT2T_GetRecordPayload(sNdefInstance, &length);

                if(binData[0] == 0x53) {

                  extractMusic(&binData[1]);

                  eepromWriteTag(EE_MUSIC_TONE, (uint8_t *)&binData[1], (uint16_t)(((uint16_t)length+2) & 0xFFFC));

                  if(musicInProgress) {

                    stopMusic();

                    startMusic();

                  }

                }

                else if(binData[0] == 0x51) {

                  Chip_TIMER_MatchDisableInt(LPC_TIMER32_0, 0);

                  desiredSpeed = (uint8_t)(binData[1] + 5U);

                  if((desiredSpeed < 5) || (desiredSpeed > 30)) {

                    desiredSpeed = 20;

                  }

                  Chip_TIMER_SetMatch(LPC_TIMER32_0, 0, 1000*LED_REFRESH_RATE_MS + Chip_TIMER_ReadCount(LPC_TIMER32_0));

                  Chip_TIMER_MatchEnableInt(LPC_TIMER32_0, 0);

                  eepromWriteTag(EE_SCROLL_SPEED, (uint8_t *)&binData[1], (uint16_t)(((uint16_t)length+3) & 0xFFFC));

                }

              }

            }

          }

          releaseMemSemaphore();

    . . .

Listing 1: The NXP LPC8N04 development software package provides a complete set of libraries and sample application software demonstrating basic design patterns for key NFC operations such as reading a NDEF message as shown in this code snippet. (Code source: NXP)

When first invoked, the main routine first tests to see if it started because of a specific RTC event (wakeupReason == PMU_DPD_WAKEUPREASON_RTC) indicating the wake-up counter has expired. If not, the routine enters its main loop, testing for various commands from the reader and performing appropriate actions in response. The routine times out eventually if no NFC activity occurs because the smartphone is no longer in range, for example.

Although simple in concept, the sample application and underlying service routines provide a comprehensive introduction to NDEF message handling using the LPC8N04. As illustrated in Listing 1, the sample application’s main loop illustrates the sequence of operations for working with NDEF messages.

In normal operation, the appearance of a new NDEF message in the LPC8N04 shared memory invokes an interrupt that sets a flag (sTargetWritten). In this semaphore-based architecture, the main routine waits until it can claim the semaphore (takeMemSemaphore()) before loading the message (NDEFT2T_GetMessage) into its buffer. The routine works through the NDEF message (NDEFT2T_GetNextRecord), extracting the payload, and parsing the result.

In this application, if the payload is a text string, it writes the data to EEPROM (eepromWriteTag) and starts the LED display (startLEDDisplay). If instead the payload is mime type "application/octet-stream" it checks the value of binData[0] to see if the data is music (binData[0] == 0x53) or a scroll speed adjustment (binData[0] == 0x51). If the latter, it saves the new scroll speed in EEPROM. If the former, the routine extracts the music data (extractMusic), writes the data to EEPROM, and restarts the music player (startMusic), if the user has the music player running.

The software package provides complete source code for the application and service routines. For example, developers can examine the source code in the NDEFT2T_GetMessage() and NDEFT2T_GetNextRecord() functions to learn the specifics of reading and processing NDEF messages. In many cases, developers will likely be able to use the service routines without modification, focusing instead on the main() routine and the details of their own application.

Conclusion

Applications for near-field communications are finding their way into a growing number of segments beyond point of sale systems. For developers, however, the challenges associated with optimizing RF performance while minimizing power consumption can stall even the most experienced engineers.

By integrating a complete NFC subsystem, the NXP LPC8N04 MCU eliminates much of the complexity of NFC design. For developers looking for a rapid solution, the NXP LPC8N04-based development board and software provide a complete application ready for immediate use, as well as a development platform for creating custom NFC solutions.

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