This post entry provides a detailed description of how the Device-to-device communication demo was developed so that you can leverage this knowledge to integrate NFC into your own system. This document has been structured as follows:   Introduction Device-to-device communication demo functionality NFC for communication with a batteryless unit NFC for communication between two devices mounted in close proximity NFC for communication with a rotating part as a cable replacement solution Hardware details Base board based on CLRC663 plus Rotating disk based on NTAG I2C plus Application logic Reader module to rotating disk communication Rotating disk to reader module communication MCU code details NTAG I2C plus pass-through mode data exchange synchronization considerations Reader module MCU code NTAG_Device2DeviceDemo  application workflow Rotating disk MCU code NTAG_I2C _Explorer_01_LEDs_ButtonXample application workflow Video recorded session Available resources Introduction The Device-to-device communication demo shows how NFC can be used as a cable replacement between two units or devices. It is based on the CLRC663 plus NFC Frontend and the NTAG I 2 C plus connected tag solutions. It demonstrates how NFC is used for: Wireless communication with a batteryless unit. Wireless communication between two devices mounted in close vicinity that need to be completely isolated (e.g. dust or water proof). Wireless communication with a rotating part and as a cable replacement solution.   Device-to-device communication demo functionality The purpose of the demo is to illustrate how to enable device-to-device communication via NFC. It consist of: A base board of 14x12 cm, which embeds the CLRC663 plus NFC reader IC for the RF field generation. A sensor embedded on a separate, rotating sensor disk of 8 cm diameter, which embeds the NTAG I 2 C plus connected tag.   The base board and the rotating sensor disk communicate via NFC and optionally, a tablet display can be connected via a Bluetooth Low Energy (BLE) connection (the BLE connection is beyond the scope of this post entry).     NFC for communication with a batteryless unit The first scenario demonstrates the use of NFC for communication with a batteryless unit or sensor. Energy from the RF field generated by an NFC reader can be harvested to power up small devices so that a battery or other power supply no longer needs to be included.   In this demo, only the base board is powered using a 5V supply input (e.g. USB battery bank) while the rotating disk electronics are powered using only the harvested energy from the RF field generated by the base board. To maximize energy transfer and avoid possible interference caused by the electronics, both the rotating disk and base board antennas are placed on the edges. In the following video, you can observe how as soon as the base board is supplied, it starts generating an RF field and automatically. Then,  all the electronics on the rotating disk are powered and its LED turns GREEN.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/f54/f54337d597118_12181097.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb54387b9f NFC for communication between two devices mounted in close proximity The second scenario demonstrates the use of NFC for communication between two devices mounted in close proximity. For instance, any machine or device where sensors are inside or in close vicinity and the sensor needs to be completely sealed (e.g. waterproof, dustproof, etc).   In this demo, the bidirectional communication between the two units is demonstrated using push buttons, which light up LEDs on the opposite unit. For the base board to rotating disk communication direction: While action button 1 is pressed, the LED on the rotating disk turns BLUE. While action button 2 is pressed, the LED on the rotating disk turns RED. While action button 1 and button 2 are pressed, the LED on the rotating disk turns WHITE.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/912/912db3bd13b06_12160248.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb54387c99 With the other way around, for the rotating disk to base board communication direction: While action button 3 is pressed, a pattern on the LED circle will appear.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/d0b/d0b0072da0120_12160391.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb54387e98   NFC for communication with a rotating part as a cable replacement solution The third and last scenario demonstrates the use of NFC to communicate wirelessly with two moving parts where cables may break. For instance, any solution consisting of a main unit and a sensing part recording mechanical-stress readings on moving parts.   In this demo, the accelerometer on the rotating disk continuously sends its coordinates to the base board, which lights up a specific LED according to the calculated angle between the two units. In the following video, you can see that the LED circle "follows" the movement of the rotating disk.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/c0e/c0e3daf347aed_12160349.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb5438709a   Hardware details This section shows the architecture and main components of the base board and rotating disk.  The PCB schematics are attached at the end of this post entry.   Base board based on CLRC663 plus The disk has been dismounted so you can better appreciate the different components of the base board. The base board is driven by an LPC11U68 MCU, which is a low-cost Cortex-M0 USB solution, with 256 kB of flash memory, up to 80 GPIOs and several host interfaces (more details on the LPC11U68 product website).   From the LPC11U68 MCU, some of the GPIOs are used to connect the action buttons and the 12 LEDs of the circle, an SPI port is used to connect the CLRC663 plus NFC Frontend and, a USART port is used for connecting a BLE chip based on NXP's QN9021 chip.     The NFC functionality is provided by our CLRC663 plus reader IC, an NXP high performance multi-protocol reader. It is the evolution of CLRC663, with a larger LPCD detection range, more output power (2x times higher transmitter current), larger temperature operating range and pin-to-pin compatibility with the former version.   Rotating disk based on NTAG I 2 C plus The rotating disk is based on NXP solutions as well. This PCB board is driven by an LPC11U24 MCU, which is a low-cost Cortex M0 32 bit MCU, with 32 kB of flash memory, up to 40 GPIOs and several host interfaces (more details on the LPC11U24 product website).   From the LPC11U24 MCU, some of the GPIOs are used to connect the action button 3 and the RGB LED. In addition, an I 2 C interface port is shared to connect a temperature sensor, the accelerometer and the NTAG I 2 C plus.     The NTAG I 2 C plus is a family of connected NFC tags that combines a memory, a passive NFC interface with a contact I 2 C interface.  Functionally, the NTAG I 2 C plus behaves as a dual port memory. Therefore, the data can pass from an external NFC device to the embedded system. In addition, to this dual interface solution, it has more features: A field detection pin, to send a wake up signal The Energy harvesting, to power external devices The SRAM, a memory without writing cycles limitation The pass-through mode, for fast data exchange between interfaces Several memory access management settings from both NFC and I2C interfaces And an originality signature, to protect against clones.   Application logic This section describes how data is exchanged between the reader module (base board) and the rotating disk using NTAG I 2 C plus as a bridge (pass-through mode) between the two embedded systems.   Reader module to rotating disk communication In this demo, the reader module sends data to the rotating disk when any of its two action buttons are pressed. The NTAG I 2 C plus is configured in pass-through mode and the SRAM memory is used as conduit between the twto units.  The figure below illustrates a simplified representation of NTAG I 2 C plus memory seen from the NFC perspective (organized in pages of 4 bytes each). The red area represents the EEPROM memory while the yellow one represents the SRAM memory location. While the button 1 is pressed: The GPIO 4 of the LPC11U68 is in high level. The CLRC663 plus writes one byte into the SRAM memory (last page, value = 0x01). The LPC11U24 on the rotating disk reads the SRAM. The LPC11U24 changes the GPIO 18 status to high level. The RGB LED turns blue.   The operation that takes place while button 2 is pressed is pretty similar. Basically, it changes: the data written by the CLRC663 plus in the SRAM and the GPIO activated by the LPC11U24 on the rotating disk. More precisely, the steps are: The GPIO 5 of the LPC11U68 is in high level. The CLRC663 plus writes one byte into the SRAM memory (last page, value = 0x02). The LPC11U24 on the rotating disk reads the SRAM. The LPC11U24 changes the GPIO 16 status to high level and sets GPIO 18 to low level. The RGB LED turns red.     In the same way, while the two buttons are pressed at the same time: The LPC11U68 detects that GPIO 4 and 5 are in high level The CLRC663 plus programs a different value on the last SRAM byte (0x03). The LPC11U24 on the rotating disk reads the SRAM. The LPC11U24 sets to high the three GPIOs (16,17,18) controlling the RGB LED. The RGB LED turns white The key message is that: what it is written in the SRAM controls the behavior of the rotating disk LED, demonstrating wireless data exchange between the two embedded systems.   Rotating disk to reader module communication In this demo, the rotating disk keeps sending data to the reader module for as long as it is powered by the RF field. Precisely, it continuously sends the disk position (via the accelerometer axis coordinates) and the measured temperature value. Additionally, an extra byte is sent while the button 3 is pressed. The actual steps are: First, the LPC11U24 MCU triggers a read operation to the temperature sensor and accelerometer. The temperaturre reading occupies 2 bytes while the accelerometer axis coordinates occupy 6 bytes. This data is transfered the LPC11U24 via the I 2 C shared bus. The LPC11U24 writes these 8 bytes into the SRAM in page addresses 0xFD, 0xFE and 0xFF (see the figure below). The CLRC663 plus reads the SRAM when the LPC11U24 has finished writing it. With the read information, the LPC11U68 base board MCU calculates the angle and sets the appropriate GPIO to high level. Since the LED circle contains 12 LEDs, the base board is able to represent position changes of 30 degrees (360º / 12 LEDs).   As mentioned, this data transfer keeps going for as long as the disk is powered. The key concept here is that the LED circle operation is directly controlled by the disk position and the axis coordinates which are exchanged via the NTAG I 2 C plus SRAM at any given moment. To illustrate this, the disk is rotated 90 º clockwise. The steps that take place are: The LPC11U24 MCU triggers the next reading command, the accelerometer axis coordinates have changed to different ones representing the new disk position (in red in the memory map figure below). The LPC11U24 writes into the SRAM again these 8 bytes (now with the updated accelerometer axis coordinates) The CLRC663 plus reads the SRAM when the LPC11U24 has finished writing it. With this new reading, the LPC11U68 MCU recalculates the angle and applies a different GPIO configuration (which leads to a different LED turned on in the circle).     Last, while button 3 is pressed: The LPC11U24 GPIO 12 is set to high value. The LPC11U24 checks GPIO 12 pin status before writing into the SRAM. While it is high level, it adds an additional byte into the SRAM (third byte on page 0xFF- value=0x01). The CLRC663 plus reads the SRAM, getting the latest data from the moving part. With the current firmware, while the third byte on page address 0xFF is set to 0x01, the LPC11U68 performs a LED pattern activating all the GPIOs simultaneously (all the LEDs are ON).     MCU code details This section explains the firmware implementation details for both the base board (CLRC663 plus) and the rotating disk (NTAG I 2 C plus). Before going into the firmware implementation details, a few considerations for data exchange synchronization when using the NTAG I 2 C plus pass-through mode are explained.   NTAG I 2 C plus pass-through mode data exchange synchronization considerations In the demo, the pass-through mode is used to exchange data between the base board and the rotating disk. The pass-through mode provides the SRAM for data communication and the mechanisms for the synchronization of the data transfer. This signalling can be done through the field detection pin or by polling the equivalent registers over the I 2 C interface. For the NFC to I 2 C direction, the synchronization can be done: By checking the SRAM_I2C_READY register to learn if new data has been written by the RF interface. By checking the filed detection pin changing from HIGH to LOW voltage.   For I 2 C interface to NFC direction, the synchronization can be done: By checking the SRAM_RF_READY register to learn if new data has been written by the I 2 C interface. By checking the filed detection pin changing from LOW to HIGH voltage.   The following table includes register bits which can be used for communication synchronization. In addition, there is a dedicated application note providing more details on how NTAG I 2 C plus can be used for bidirectional data communication.   Register bit Use PTHRU_ON_OFF Detects if the pass-through mode is still enabled (gets reset in case of RF or I2C power down). TRANSFER_DIR Defines the data flow direction for the data transfer. I2C_LOCKED Detects if memory access is currently locked to I2C. RF_LOCKED Detects if Memory access is currently locked to RF. SRAM_I2C_READY Detects if there is data available in the SRAM buffer to be fetched by the I²C side. SRAM_RF_READY Detects if there is data available in the SRAM buffer to be fetched by the RF interface. RF_FIELD_PRESENT Shows if a RF field strong enough to read the tag is there.   Reader module MCU code The MCU firmware was developed using our LPCXpresso platform, which provides a complete development environment for LPC MCU and LPC boards. In the source code, there are five project folders: The FreeRTOS project folder, which is an open source real-time operating system (RTOS) for embedded systems supporting many different architectures and compiler toolchains The Lpc_chip_11u6x_lib and nxp_lpcxpresso_11u68b project folders, which belong to the LPCOpen libraries supporting the LPC11U68 MCU and PCB board, the MCU chip integrated in the Explorer board. If you use another MCU, you should replace them by the specific LPCOpen libraries. The NTAG_Device2DeviceDemo  project folder, which implements the logic supporting the device-to-device communication demo for the reader module. The NxpNfcRdLib project folder, which is the NXP's NFC Reader Library software stack supporting the implementation of the demo, the contactless protocols, the LPC MCU host interfaces and the CLRC663 drivers.   The reader module MCU code leverages on the NFC Reader Library. The NFC Reader Library is a software stack for creating and developing contactless applications for NXP's NFC readers. This API facilitates the most common operations required in NFC applications such as: reading or writing data into contactless cards, exchanging data with other NFC-enabled devices and emulating cards.   In order to use the NFC Reader Library, a stack of components has to be built up from the bottom to the top layer. Precisely, the application requirements define which modules need to be enabled and which do not. For the reader module firmware: The FreeRTOS is used. The SPI is used as host interface. A CLRC663 plus reader IC is used. And, communication with NTAG I 2 C plus is needed ( ISO14443 Type A card and NFC Forum Type 2 Tag compliant)   As a result, the software components that need to be enabled within the NFC Reader Library are depicted in the following picture: NTAG_Device2DeviceDemo  application workflow The reader module firmware starts its execution as soon as it is connected to the power bank. The firmware initializes the GPIOs, the UART for the tablet connection and the NFC Reader Library for the contactless operation. After all these initializations, the firmware code generates a new thread in charge of dealing with the disk operation. In this separate thread, the discovery loop for detection of Type A and Type V cards is configured and started. After that, the firmware keeps listening until the NTAG I 2 C plus is detected (i.e. the disk is mounted). On detection, the operation with the rotating disk starts: The reader module waits until the SRAM is available for the RF interface. The SRAM is available for the RF interface while the pass-through mode is enabled (PTHROUGH_ON_OFF register is set) and the RF to I 2 C direction is set (TRANSFER_DIR register bit). The board buttons are checked and the SRAM is written with the corresponding information.   At this point, the program awaits to receive data from the rotating disk. For that, it keeps polling if new data was written in the SRAM by the I 2 C interface (SRAM_RF_READY register bit is set). If new data is available, the SRAM is read and the data is processed: The accelerometer axis coordinates are read, the angle is calculated and the appropriate LED on the circle is activated. While the button 3 is pressed, the MCU triggers the LED pattern on the circle. Optionally, if the tablet connection is established, data is also sent using the BLE channel.   The following figure depicts the reader module application workflow in detail:   Rotating disk MCU code The MCU firmware was also developed using the LPCXpresso platform.  In the source code, there are four project folders: The Lpc_chip_11uxx_lib and nxp_lpcxpresso_11u24h_board_lib project folders belong to the LPCOpen libraries supporting the LPC11U24 MCU and PCB board, the MCU chip integrated in the Explorer board. If you use another MCU, you should replace them by the specific LPCOpen libraries. The NTAG_I 2 C _API project folder is a library providing a set of functions and procedures that allow you to communicate with the NTAG I 2 C from the I 2 C interface. Among others, functions to perform memory operations on EEPROM, SRAM, registers and for enabling the pass through mode The NTAG_I 2 C _Explorer_01_LEDs_ButtonXample project folder implements the logic for the rotating disk of this demo.   NTAG_I 2 C _Explorer_01_LEDs_ButtonXample application workflow The rotating disk firmware starts its execution as soon as it harvests enough energy from the reader's module RF field. The first operation taken is to enable the pass-through mode. Then, the firmware stays on a loop for as long as it is energized.   In this loop, it sets the SRAM into RF to I 2 C direction (TRANSFER_DIR register bit) and waits until the base board has written data. After data has been written from the RF side, it reads the SRAM and checks the last byte: While the last byte value is 0x01, it means the button 1 is pressed and the firmware sets the RGB LED to blue While the last byte value is 0x02, it means the button 2 is pressed and the firmware sets the RGB LED to red While the last byte value is 0x03, it means the button 1 and 2 are pressed and the firmware sets the RGB LED to white.   After receiving data from the base board, it prepares to send data back. For that: it checks the button status, it reads the temperature value and the accelerometer position. Once all the data has been collected: It changes the SRAM to I 2 C to RF direction (TRANSFER_DIR register bit). It writes into the SRAM and waits until the RF has read the data (SRAM_RF_READY register is cleared).   This loop is repeated for as long as the disk is powered. The following figure depicts the rotating disk application workflow in detail:     Video recorded session On 9 March 2017, a live session explaining the device-to-device communication demo was recorded. You can watch the recording here:   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/149/149fee5f5e282_12181079.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb5439ff51 Available resources   Schematics Please see attached in the separate attachment section below. Device-to-device demo source code Please see attached in the separate attachment section below. Quick-start guide for showing the demo Please see attached in the separate attachment section below Android app The android app can be used on a tablet or smart phone connected via BLE to this demo to show additional parameters, and to have a bigger screen for demonstrations. You find it in Google play ("device2devicedemo") and attached below.  

This post entry provides a detailed description of how an NFC DIN rail demo was developed so that you can leverage this knowledge to integrate NFC into your own system. This document has been structured as follows: Introduction The NFC DIN rail demo shows how NFC can be used for handling complex device settings on a mobile touchscreen. It is based on the NTAG I 2 C plus solution and demonstrates how NFC is used for: Wireless parametrization and zero power configuration. Wireless product diagnosis and troubleshooting. Wireless firmware update. NFC DIN rail demo functionality Industrial equipment such as circuit breakers, time relays, power units, sensors, etc typically come with limited user interfaces but with advanced settings and configurations. As NFC use becomes universal in smartphones and other handheld devices, these devices can be used as an external touchscreen interface enabling sophisticated interactions and configurability at a little cost. The NFC DIN rail demo could represent industrial equipment in charge of controling a lighting system. As a simplification, here it controls only three light bulbs. This DIN module consists of a power switch (220 V), an NFC interface and an LCD screen. Additionally, a dedicated phone application has been developed to interact with the NFC DIN rail for enabling wireless parametrization, wireless diagnosis and wireless firmware update via NFC. Wireless parametrization and zero power operation NFC can be used to save configuration settings so that equipment may be customized at any moment during its lifetime. Additionally, the energy harvesting feature, intrinsic to NFC, allow us to save product settings even if the device is unpowered (also called zero-power operation). In this NFC DIN rail demo, the Android app let us set the light bulb status to ON, OFF or BLINKING and set the LCD language as well. After selecting the different settings on the screen, we tap the phones and the settings are saved into the module. The following video shows how this functionality works, also with the unit powered and unpowered. Wireless product diagnosis - Read light bulbs switching counters NFC can be used to get instant readouts of device status, usage, statistics and diagnosis data without dismounting the casing and even after a breakdown situation. In this NFC DIN rail demo, the Android app lets us retrieve the switching counter values (the number of times the light bulbs have been switched ON / OFF). The following video shows how reading NFC DIN rail product diagnosis only takes one tap. Wireless product diagnosis - Reset light bulbs switching counters Additionally,  the Android app lets us reset the switching counter values with a phone tap. Wireless firmware update With NFC, firmware upgrades can be done wirelessly, without cables, disks or other means of data transfer.  It therefore, saves time since it is not necessary to dismount the device. In this NFC DIN rail demo, the Android app lets us select the binary file to be flashed. This implementation is robust since you can retry as many times as needed, even if a failure occurs in the flashing operation. The following video shows how the NFC DIN rail firmware is updated to a firmware version introducing a faster light bulb blinking speed. NFC DIN rail hardware details Dismounting the DIN module is quite straightforward, especially if you are familiar with DIN casing. We unscrew and release the power wires coming from the power supply unit We unscrew and release the light bulb power wires We dismount the module from the rail and release it from the rail We open the boxing and see what is inside The NFC DIN rail module consists of three PCBs: the Transformer PCB, the switching PCB and the Explorer board with a flex antenna   Transformer PCB The transformer PCB includes three electromechanical relays that directly control the light bulbs. It also includes a transformer which converts the 220V AC supply from a standard socket to 12V AC. This 12V AC supply is used to power the switching PCB. Switching PCB The switching PCB converts the 12V AC to 12V and 3V DC voltage supply. The 12V DC voltage is used to control the electromechanical relays, which in turn switches the light bulbs ON/ OFF. On the other hand, the 3V DC output is used to supply the Explorer board. Explorer board and flex antenna The Explorer board and flex antenna are part of the NTAG I 2 C plus support package. The Explorer board comes with: 5 push buttons, a temperature sensor, an LPC11U24 MCU, JTAG interface, LCD and I 2 C connectors. The NTAG I 2 C plus comes embedded in the Class 6 Flex antenna All the design files for the Explorer board as well as the Flex antennas can be found in NT3H2111/2211|NXP  Application logic and how NTAG I 2 C plus solution is used Before going into the implementation details, we briefly describe the NTAG I 2 C plus product. NTAG I 2 C plus product features The NTAG I 2 C plus is a family of connected NFC tags that combine a memory, a passive NFC interface with a contact I 2 C interface. As such, it supports full bidirectional communication between an NFC-enabled device and the host system's microcontroller, making it an ideal solution for NFC implementations that interface with a wide range of electronic devices. Additional to this dual interface solution, it has more features: A field detection pin to trigger external / connected devices. The energy harvesting, to power low consuming devices from the RF field. The SRAM buffer, a volatile memory without writing cycles limitations. The SRAM mirroring, for dynamic content update. The pass through mode, for fast data exchange between interfaces. Several memory access management settings from both NFC and I 2 C interfaces. And an originality check to detect clones. More product details about NTAG I 2 C plus can be found at NT3H2111/2211|NXP and technical recorded videos are available in our training academy NFC Webinars|NXP. How the NTAG I 2 C plus is used for wireless parametrization and zero power operation The NTAG I 2 C plus EEPROM memory is used to store DIN module settings. The phone application is able to overwrite these bytes with the desired configuration. On power up, the MCU reads the saved settings and applies the corresponding configuration. In this demo, one byte is used to configure each light bulb status ('0' - light bulb ON, '1' - light bulb OFF, '2' - light bulb BLINKS) and one byte used for the language configuration ( '0'- Deutsch, '1' -Babarian, '2' - Swiss, '3'- English, '4' - French). Using the Zero Power Config Android app tab, we define the desired settings. With a tap, the phone writes 4 bytes into the EEPROM memory (page addresses 0x34 - 0x35) On power up, the NFC DIN module reads the EEPROM memory and: Changes the GPIO 17, 18 and 19 output configuration to HIGH or LOW accordingly Changes the language message on the LCD display. Finally, the MCU updates the light bulbs switching counters by writing the EEPROM memory. Two bytes are used for the counters (page addresses 0x35-0x37)- How the NTAG I 2 C plus is used for product diagnosis The product diagnosis provides two functionalities: read switching counters values and reset switching counters values. With a tap, the phone reads the EEPROM to retrieve the latest switching counter values. Clicking on the Reset button and with a phone tap, we are actually overwriting the EEPROM by setting the switching counter values to '0'. How the NTAG I 2 C plus is used for wireless firmware update The NFC wireless firmware update capability in this demo leverages on two main aspects: First, the LPCs MCU capability to re-program the flash in the field without being removed from the PCB. Second, the NTAG I 2 C plus tag as a bridge to transfer data between the phone and the DIN module MCU.   The MCU flash memory can be re-programed using these two methods: In-System programming (ISP), which can program the on-chip flash memory using the system primary boot loader and programming interface. For instance, in the Explorer board, this can be done by connecting it via USB to a laptop (could also be UART, serial interface, etc). In-Application (IAP) programming, means that the application itself, the end-user code, can re-program the on-chip Flash memory   The LPC11U24 flash memory is grouped in 8 sectors of 4 kB each. The flash memory should be reprogrammed at the sector level.  Another critical requirement is that the implementation must allow multiple FW updates and protection against failed FW update processes. For this, the firmware consists of two applications residing in flash: The first: the secondary bootloader application. This application is a piece of code starting at memory Sector 0. It implements the IAP functions allowing a certain flash memory area to be flashed and the logic to handle the NFC data transmission.  This source code occupies 4 sectors. The second: is the user application code. It starts at the next free memory sector (in this case, it resides in sector 4 onwards), and is the flash memory area, which is overwritten when the NFC wireless firmware update is performed.   In this approach, the secondary bootloader application is not overwritten. Thanks to this, it supports multiple FW updates or you can re-try as many times as needed without breaking the system. Regarding the NTAG I 2 C plus, it can be used as a bridge between NFC / I 2 C interfaces. The wireless firmware update consists of transferring the binary file to be flashed from one interface to the other. For transmission of large files, the NTAG I 2 C plus offers the pass-through mode, where the data is transferred using the 64 byte SRAM buffer. This buffer offers fast write access and unlimited write endurance as well as an easy handshake mechanism between the two interfaces. This buffer is mapped directly at the end of the Sector 0 of NTAG I 2 C plus (0x0F to 0xFF). The data flow direction must be set with the TRANSFER_DIR session register. These pass-through direction settings avoid locking the memory access during the data transfer from one interface to the SRAM buffer.  NTAG I 2 C plus introduces the FAST_READ command as FAST_WRITE command. With this new command, the whole SRAM can be written at once, which improves the total pass-through performance significantly.  There is a dedicated application note detailing how to use the NTAG I 2 C plus for bidirectional communication http://www.nxp.com/documents/application_note/AN11579.pdf. The wireless firmware update process goes as follows: The user selects from the phone application the binary file to be flashed. The phone splits the binary file in chunks of 64 bytes. With a tap, the phone writes 64 bytes in the SRAM. The MCU stores chunks of 64 bytes until it has one entire flash sector complete. Once a whole sector is received, the MCU executes the IAP functions to flash a memory sector This process is repeated until the whole binary file is transmitted MCU / Embedded software integration The MCU firmware was developed using our LPCXpresso platform, which provides a complete development environment for LPC MCU and LPC boards. If you import the source code, you will see 6 project folders.  The Lpc_chip_11uxx_lib and nxp_lpcxpresso_11u24h_board_lib project folders belong to the LPCOpen libraries supporting the LPC11U24 MCU and PCB board, the MCU chip integrated in the Explorer board. If you use another MCU, you should replace them by the specific LPCOpen libraries. The NTAG_I 2 C _API is a piece of code that provides a set of functions and procedures that allow you to communicate with the NTAG I 2 C from the I 2 C interface. The NTAG_Explorer_bootloader implements the secondary bootloader application we described previously. In this piece of code you will find the IAP functions implementation and the code handling SRAM data transfer.  And then, we include two end-user application examples: The NTAG_Explorer_demo, which implements the DIN module use cases The NTAG_Explorer_blink, which is a dummy application displaying a text message on the LCD when an RF field is detected. This application is provided to illustrate the NFC flashing functionality and its binary image is provided embedded by default into the Android app NTAG_I 2 C_Explorer_bootloader application workflow This is the first application executed when the Explorer board is powered up.  Then, this application decides the next step: If the right button is not pressed, it jumps to sector 4 and executes the DIN module application. Otherwise, if the right button is pressed, it enters in firmware upgrade mode As soon as the binary file is selected from the app, and we tap the phone, we start the transmission. The process goes as follows: The MCU reads chunks of 64 bytes of SRAM until a sector is received. Once a full sector is received, we flash an MCU sector using the IAP functions. When the entire file in transmitted, the flash operation status is shown on the LCD and the MCU is reset so that the new binary file flash takes effect. NTAG_I 2 C_Explorer_demo application workflow If the right button was not pressed, the NTAG_I 2 C_Explorer_demo application is executed. The first step executed by the MCU is to read the stored EEPROM configuration and apply these settings accordingly.Then, using a dedicated NTAG I2C plus register, it checks whether an RF field is present: If RF field is present, it means the user is currently configuring the DIN module. Thus, the memory access is locked so that the MCU cannot write on it. When the field is OFF, it means the user has finished the configuration. The MCU can read and apply the EEPROM settings once again. If there is no RF field present, the DIN module also allows a manual configuration using its buttons. These manual button configurations perform the following actions: While the left button is pressed, all the GPIOs are set to low, so the light bulbs are switched OFF While the middle button is pressed, all the GPIOs are set to high, so the light bulbs are switched ON While the right button is pressed, the board LED is switched ON. At any moment… if an RF field is detected, this loop is skipped and access to memory is locked for the I 2 C side since the user is configuring via the NFC interface Phone / NFC device software integration There is an Android project available which can be easily imported into Android Studio IDE. The app is developed so that it is supported by any phone running an Android version 4 and beyond. The source code is organized in such a way that you can clearly distinguish the different activities from the NTAG I 2 C API. In the NTAG I 2 C API, you will find functions for: All the NFC commands are implemented. So you can easily perform read / write operations using the READ/ WRITE and FAST READ / FAST WRITE commands. But also, the SECTOR_SELECT or PWD_AUTH Dedicated functions to READ / WRITE the registers Additional functions specially developed to make the read/write operations on SRAM easier. NFC DIN rail Android demo application workflow The Android phone application consists of a splash activity that leads us to a main activity with three tabs on the top side. If we keep the zero power configuration tab on, the desired settings can be selected. As soon as the phone is tapped, it executes a WRITE EEPROM command to save the configuration If we go to the diagnostics tab, a READ EEPROM operation is performed as soon as the phone is tapped. Or a WRITE EEPROM operation to overwrite the counters, if the reset button on the screen was pressed beforehand. Finally, if we go to the flash firmware tab, the binary file can be selected, and WRITE SRAM operations are used until the whole file has been transferred. Video recorded session On 21 February 2017, a live session explaining the NFC DIN rail demo was recorded. You can watch the recording here: Available resources I hope this entry has been useful. If you are interested in developing your own NFC solution, all the resources are available: NTAG I 2 C plus Explorer kit http://www.nxp.com/products/wireless-connectivity/nfc-and-reader-ics/connected-tag-solutions/ntag-ic-plus-explorer-kit-with-nfc-reader-development-kit:OM5569-NT322ER NTAG I 2 C plus Flex kit with additional antennas http://www.nxp.com/products/wireless-connectivity/nfc-and-reader-ics/connected-tag-solutions/ntag-ic-plus-flex-kit-containing-additional-flex-antennas:OM5569-NT322F Explorer board and Flex antenna HW design files http://www.nxp.com/documents/software/SW3641.zip http://www.nxp.com/documents/software/SW3639.zip http://www.nxp.com/documents/software/SW3638.zip NFC DIN module source code http://nxp.com/assets/downloads/data/en/software/DINRailDemo_SourceCode.zip NTAG I 2 C plus Explorer kit reference source code http://www.nxp.com/documents/software/SW3648.zip http://www.nxp.com/documents/software/SW3647.zip

This document describes step-by-step how to run NFC on Raspberry Pi platform. Hardware setup: You need:    - Raspberry Pi (any model) : https://www.raspberrypi.org/products/:        - OM5578(PN7150 demokit) in RPi configuration (or OM5577(PN7120 demokit)😞         Then simply assemble boards together, stacking OM5578RPI (or OM5577RPI) to Raspberry Pi expansion connector:       Software setup:   Use Raspbian  (https://www.raspberrypi.org/software/operating-systems/) or any other Linux distribution (guidelines to set up Linux environment on raspberry pi: https://www.raspberrypi.org/documentation/installation/installing-images/). Step by step procedure: Enable i2c support:        On Raspbian: Run "sudo raspi-config" Use the down arrow to select "5 Interfacing Options" Arrow down to "P5 I2C" Select "yes" when it asks you to enable I2C Also select "yes" if it asks about automatically loading the kernel module Use the right arrow to select the <Finish> button Select "yes" when it asks to reboot       The system will reboot. when it comes back up, log in and enter the following command "ls /dev/*i2c*".       The Pi should respond with "/dev/i2c-1" which represents the user-mode I2C interface.   Install necessary tools:         On Raspbian execute the command:    sudo apt-get install autoconf automake libtool git Clone Linux libnfc-nci library repository:         Execute the command:    git clone https://github.com/NXPNFCLinux/linux_libnfc-nci.git Configure the library:         Execute the commands:    cd linux_libnfc-nci    ./bootstrap    ./configure --enable-alt Build and install the library:         Execute the commands:    make       sudo make install    export LD_LIBRARY_PATH=/usr/local/lib Run demo application (built and installed together with the library during previous step):         To simply display all data collected from remote NFC device (Peer, reader/writer or card), run the demo application in poll mode executing the command:    nfcDemoApp poll         For more details about the demo application modes execute command:    nfcDemoApp --help   One step further: Set environment variable to reference library installation:         Execute command: export LD_LIBRARY_PATH=/usr/local/lib         You may wan't to make this setting permanent by adding it to your .bashrc file for instance : echo "export LD_LIBRARY_PATH=/usr/local/lib" >> .bashrc Write your own application:         Several simple examples demonstrating use of the linux_libnfc-nci library for different use cases (Reader, Peer to peer, Host Card Emulation) are given as reference: https://github.com/NXPNFCLinux/linux_libnfc-nci_examples        - Simply clone the repository    git clone https://github.com/NXPNFCLinux/linux_libnfc-nci_examples.git        - Browse to the targeted example:    cd linux_libnfc-nci_examples/xxx_example        - Build the example:    make        - Run the example    ./xxx_example   Additional information: Another Platform ?        Using UDOO NEO (with OM5577 or OM5578 in Arduino configuration) ?           -> Follow step-by-step procedure, just updating src/halimpl/pn54x/tml/i2c/phTmlNfc_alt.h file to set CONFIGURATION flag to value 2, before building the library        Using BeagleBone Black (with OM5577 or OM5578 in BBB configuration) ?           -> Follow step-by-step procedure, just updating src/halimpl/pn54x/tml/i2c/phTmlNfc_alt.h file to set CONFIGURATION flag to value 2, before building the library        Using other Linux platform or others OM5578/OM5577 demokits configuration ?           -> Follow step-by-step procedure, just updating src/halimpl/pn54x/tml/i2c/phTmlNfc_alt.h file to set CONFIGURATION flag to value 0 and defining I2C_BUS, PIN_INT and PIN_ENABLE flags according to the HW connection, before building the library Running Android ? -> Follow guidelines provided in the related documentation: https://www.nxp.com/docs/en/application-note/AN11690.pdf

This post entry provides a detailed information about the EMVCo L1 certification process for contactless payment devices. The structure is the following: EMV Introduction Objective When a company is developing a POS device, there are some challenges to consider for a successful deployment in the market: The device needs to have a good performance to provide the client with a good user experience. Moreover, the device should be able to operate seamlessly with other devices and cards in the market in a secure and reliable way.   These key characteristics are tackled by the EMV specifications. Summarizing, EMV is a group of specifications for smart payment cards and terminals that were created by EMVCo to guarantee interoperability and acceptance of secure payment transactions. EMV stands for Europay, Mastercard, and Visa, the three companies that originally created the standard. These specifications are now managed by EMVCo, an organization of six members – including Mastercard, UnionPay, Visa, AmEx, Discover, and JCB.   EMVCo organization We can see in the figure below the structure of the organization. EMVCo is managed by the Board of Managers that consists of two representatives of every member of the organization. On top of the Board of Managers, the Executive Committee provides guidance on the group’s long-term strategy.     From a more technical point-of-view, it is organized in several Working Groups, each of them dedicated to specific topics. EMVCo also has the Associates Program, so key industry stakeholders can provide input and feedback to the Board of Managers, Executive Committee, and Working Groups.   EMV Technologies EMV specifications encompass a wide range of technologies, including: Contact chip technology, where smartcards and readers provide with cryptographical security advantages in comparison with the traditional magnetic stripe. EMV specifications also regulate contactless payment devices based on NFC technology.  Mobile Transactions where the mobile phone would play the role of a contactless device. The QR code technology, where the transaction can be made using a QR reader. Payment tokenization, that enables to perform transactions without compromising sensible card information. And other technologies like Secure Remote Commerce, 2nd Gen or 3-D Secure.   EMV Contactless specifications EMV Contactless specifications is now on version 2.6 but planning to move to version 3.0 by the end of the year.   The EMV Contactless specifications are structured in three books and the Contactless Interface Specifications that substitutes the Book D from previous versions of the specs. The Book A describes the overall architecture of the system, and the instructions involved in the communication between the entry point and the kernel. The Book B addresses the specifications regarding the Entry Point, which is the piece of sw in charge of the transaction pre-processing, or protocol activation among other tasks. Book C consists of 6 different levels for each of the kernels that are defined in the specifications. The EMV Contactless Interface Specifications describe the minimum set of functionalities that are required for the correct operation between the PICCs and the PCD.   In addition we will mention other relevant documents like: The PCD Test Bench and Test Case Requirements, that describes the test cases that are carried out by the testing laboratory in order to evaluate the devices. Note that there are 2 different documents, one for the Analog L1 tests and another one for the Digital tests. Another document describes the Device Test Environment, which is the software needed to control the device during the testing phase Another document describes the requirements regarding the Contactless symbol that should appear in all EMVCo Contactless POS in the market.   PCD L1 Type Approval The following diagram summarizes the process for the PCD L1 Type Approval:     In the first step the Product Provider shall submit a Request for Registration form to EMVCo. Once EMVCo reviews and accepts the form, the product provider will receive a contract that has to be signed. Upon reception of this contract, EMVCo will assign a product provider registration number. In the second step the Product Provider will choose a Test Laboratory and complete a document called Implementation Conformance Statement in which it provides detailed information about the device and its features. The third step is the Product Validation phase. In this phase the laboratory performs the product testing, where the device goes through a set of tests to evaluate the digital and analog performance. In a final phase and considering the test reports from the Laboratory, the Product Provider might decide to send the product to EMVCo for approval. In that case, EMVCo would analyze the tests reports and grant with a Letter of Approval in case the reports demonstrate sufficient product conformance.   In our case we are going to focus on the Analog L1 PCD tests.    EMV Analog L1 PCD Tests Environment Before going directly to the actual set of tests, it worth it to explain some components about the testing environment to better understand the testing procedure. We have the following elements: Device Test Environment Contactless symbol Positioning conventions EMVCo Reference PICC   Device Test Environment (DTE) The Device Test Environment is a software application that is used to control the device under evaluation during the whole testing process. This application has to be developed by the product provider and shall be implemented in compliance with a set of requirements defined in the specifications. The software is submitted to the test laboratory along with the samples of the device under certification. The DTE shall implement different applications or modes of operation that would be used depending on the testing scenario. These application are:   PCD Controls: It allows the test operator to execute single basic commands from the ISO14443 standard (Carrier ON/OFF, WUPA, WUPB,..) Pre-validation application: This application is used to test the communication of the device with a set of actual EMV compliant cards. Loopback application: It is used to test the device for the majority of the Analog and Digital L1 PCD Tests. In this case the reader is communicating with a Card simulator connected to a reference antenna. Transaction send application: This application can be used by the laboratory to evaluate the compliancy of the device with the waveform requirements defined for the Analog L1 PCD Tests. The main characteristic of this mode of operation is that the device sends a sequence of commands without waiting the responses from the PICC.   Contactless symbol The contactless symbol is the logo that you can see in the lower image. It helps the user identify the area in the Point Of Sale where he has to tap the card in order to trigger the transaction. This symbol has to be visible in the device surface or screen before and during the transaction. The Contactless symbol is extremely important for the testing procedure as it marks the reference point for all the positions that the device should be tested.   Using this reference point EMVCo defines an operating volume.   Positioning convention All test position are included in this operating volume. Depending on the test case, it will be run in one or more positions. Every position is expressed with a set of 3 coordinates or parameters, representing the height, the radius, and the angle respectively.     In the figure above you can see the operating volume along with the different values that each parameter can have.   EMVCo Reference PICC The EMVCo Reference PICC is the reference antenna used to communicate with the PCD under test. It has 4 ports and 2 jumpers that are used to configure the PICC for different purposes. For example, jumper 8 is used to select between linear and non-linear load depending on the type of tests that are performed. In the same line, the MOD IN port where a Signal Generator will inject a certain modulation to emulate a PICC response. The DC OUT port is used to measure the voltage level in the power tests and the LETI COIL OUT is used to measure the waveform tests among others. In the figure below you can also see the reference point of the antenna where the two white lines crossed:   Power tests The power tests are evaluated in all positions with the purpose of guaranteeing that the device is emitting enough field in all the positions. Depending on the height the limiting values will differ. In the figure below you can see the different planes with the respective limiting values.     The critical positions for the power tests are usually the outer positions for plane z=4 and z=3 where the voltage measured may not be strong enough to pass the tests. On top of that and depending on the transmission configuration used, it can also happen that the voltage measured at positions (1, 0, 0) and (0, 0, 0) can exceed the maximum level.   Waveform tests The purpose of the waveform tests is to evaluate the wave shape of the modulation used in the commands from the PCD. That way, if the wave shape fits with the requirements an EMVCo compliant PICC would not have any problem understanding the commands sent by the PCD.   The waveform evaluation for Type A modulation include the following test cases: t1 (TB121) Monotonic Decrease (TB122) Ringing (TB123) t2 (TB124) t3 and t4 (TB125) Monotonic Increase (TB126) Overshoot (TB127)     In the same way, the Type B test cases are the following: Modulation Index (TB121)# Fall time (TB122) Rise time (TB123) Monotonic Increase (TB124) Monotonic Decrease (TB125) Overshoots (TB126) Undershoots (TB127)     Reception tests The objective of the communication or responsiveness tests is to guarantee that the PCD is able to properly finish a transaction when the response of the PICC is in the limits of the specifications in terms of amplitude and polarity.   That way we find 4 different tests: Minimum load modulation, positive polarity (Tx131) Maximum load modulation, positive polarity (Tx133) Minimum load modulation, negative polarity (Tx135) Maximum load modulation, negative polarity (Tx137)   In the two figures below we can easily check the difference in the load modulation level between the oscilloscope capture for the Tx131 and the Tx133.     Other tests Besides the power, waveform and communication tests there are other tests included in the EMVCo Analog L1 Test cases. Here is the list of these other tests:   Carrier frequency (TAB112) Field resetting (TAB113) Power off (TAB114) Polling sequence (TAB115) FDTA PICC (TA139) BitRate (TA141 & TB141) BitCodingPCD (TA142 & TB142) BitCodingPICC (TA143 & TB146) BitBoundaries (TB147) TFSOFF (TB145 & TB148)   EMV Contactless Specs v3.0 The most important change is that the tests will no longer be carried out with one specific EMVCo reference PICC but with three. The first two are Class 1 antennas tuned to 16.1MHz and 13.56MHz, and the third reference PICC is a Class 3 antenna tuned to 13.56MHz.     This is important since the device will need to pass the test for 3 different antennas, making the testing process between 2 and 3 times slower and the tuning of the device more difficult than for the 2.6 version of the specs.   Other changes are a second different load for the linear load tests and the modifications of some waveform tests limits.   NXP Product portfolio for POS The product portfolio that NXP offers for contactless POS device includes three main chips: CLRC663 plus: EMVCo 2.6 ready chip compliant both for analog and digital L1 requirements. The CLRC663 plus is able to work with a transmitter current of 350 mA and a limiting value of 500 mA. This feature allows us to increase the field strength radiated and overcome power issues because of the design of the POS or the antenna.  PN5180: The PN5180 chip is also an EMVCo compliant frontend, that supports highly innovative and unique features like the Dynamic Power Control that optimizes the RF performance even under detuned antenna conditions. Other features are the Adaptative Waveform Control or the Adaptative Receiver Control to automatically adjust the transmitter modulation or the receiver parameters. These and many other features turn the PN5180 into the best NFC frontend in the market. PN7462: It supports contact and contactless interface in the same chip. It is an NFC controller, so includes an MCU with a configurable host interface. For the contactless interface, it implements similar functionalities as the PN5180, like the Dynamic Power Control, the Adaptative Receiver Control, and the Adaptative Waveform Control.   Further Information You can find more information about NFC in: Our NFC everywhere portal: https://www.nxp.com/nfc You can ask your question in our technical community: https://community.nxp.com/community/identification-security/nfc You can look for design partners: https://nxp.surl.ms/NFC_AEC And you can check our recorded training: http://www.nxp.com/support/online-academy/nfc-webinars:NFC-WEBINARS   Video recorded session

This post entry provides a detailed description of how a Bluetooth Low Energy (BLE) pairing solution via NFC was developed using two of our reference development boards: The NTAG I 2 C plus kit for Arduino pinout The Freedom KW41Z board. This document has been structured as follows: NFC for easy one-tap pairing solution NFC pairing is one popular feature you can find in cameras, speakers, printer, routers, wearables and many more. Just bringing two NFC-enabled devices close together is all it takes to create a connection. Just to mention a few of examples, with just a swipe you can: Connect your phone to a wireless speaker. Connect your new devices to the home network. Connect accessories to the control unit. In all these scenarios… NFC and Bluetooth are a perfect combination, since the pairing process with NFC becomes: Faster compared to the traditional pairing methods. Easier, reducing technical support More reliable, making sure you connect to the right device. The technical basis for this “tap to connect” process is provided in the NFC Connection Handover specification running atop the NFC Forum protocol stack. It defines a framework of messages and data containers that allow bootstrapping of alternative (i.e., other than NFC) carrier connections in a standardized way. For this reason, NFC pairing solution offers a unified user experience and interoperability across different manufacturers.  NFC solutions to implement secure simple pairing There are two types of solutions recommended to add NFC pairing functionality to designs: NFC static pairing with NTAG 213 The first solution is embedding an NTAG 213 NFC label. In such a case, the pairing credentials need to be previously loaded in to the tag memory as well as in the device MCU during manufacturing. NFC dynamic pairing with NTAG I2C plus The second solution is embedding an NTAG I 2 C plus tag. In such a case, the pairing credentials can be dynamically updated by the device MCU during the product lifetime. In addition, other features such as an automatic wake-up field detection signal are possible. Precisely, the combination of a passive NFC interface with a contact I2C interface allows the product to behave as a tag and be read via NFC and to connect to a host or application processor via  I 2 C. In addition, NDEF messages can be generated and updated by the host MCU depending on the application requirements. Later, these NDEF messages can be read by any NFC phone, including iOS devices with the latest OS version. Hardware setup Mapping the previous diagram to the demo hardware, we have: The NTAG I 2 C plus tag, using the Arduino pinout kit The MCU, using Kinetis KW41Z. The applicatiob logic, which updates the NDEF contents based on different use cases. Some details about the hardware used in the next sections: Kinetis KW41Z The Kinetis KW41Z is a high integrated chip with multi-protocol radio features enabling Bluetooth Low Energy (BLE) and 802.15.4 radio protocols such as Thread. KW41Z has as large memory of 512KB that can support multiple radio protocols running in a single application instace and implements nine low-power modes and a wide operating voltage range (0.9V/4.2V), for optimum current consumption. Finally, the software support package includes: BLE, Thread and 802.15.4 generic network stacks, several sample demo apps, support for RTOS and full integration in MCUXpresso. The Kinetis KW41Z evaluation is supported with the FRDM-KW41Z development board. The board main components are: a reference crystal, an accelerometer, an Arduino header, some LEDs and buttons, a JTAG and OpenSDA connectors,and an external flash memory. NTAG I2C plus kit for Arduino pinout The NTAG I 2 C plus Arduino kit consist of two PCBs stacked together: The upper PCB is the antenna board with the connected tag The lower PCB is an interface adaptor board to the Arduino pinout. This kit can be used to connect and evaluate the NTAG I 2 C plus  into many popular MCUs with Arduino compliant headers, for example:  Kinetis (e.g. KW41Z, i.MX (e.g. UDOO Neo, i.MX 6UL, i.MX 6 ULL, i.MX 7D) and LPC MCUs (e.g. LPCXpresso MAX, V2 and V3 boards). The kit support package includes several software examples, including the BT pairing example based on KW41Z.  The OM29110ARD is a generic interface board which offers support for connection to any PCB implementing Arduino connectors. It exposes: 3.3V and 5V power supply pins. I 2 C , SPI and UART host interfaces. Generic GPIOs (e.g. to be used for field detect, interrupts, reset pins or others) As such, it allows the NTAG I 2 C plus to be plugged into Arduino devices seamlessly. Once the NTAG I 2 C plus  board is stacked on the KW41Z, the pining routing between the two boards is as follows. It uses:  The  I 2 C  interface pins. The 3.3V supply pin. One GPIO is routed for the field detection pin. The Vout, for the energy harvesting pin. The ground reference. BLE pairing with NFC on KW41Z and NTAG I2C plus This section details how the Bluetooth Low Energy (BLE) pairing with NFC on KW41Z and NTAG I 2 C plus works. The following block diagram is a simplified representation of the demo that shows: The Bluetooth and NFC interfaces The buttons and LEDs involved in the process. Starting BLE advertising After SW4 is pressed: The application goes from IDLE to searching mode, advertising the BLE device The LED 3 starts blinking in RED color. Writing BLE pairing NDEF message Once the BLE advertising is activated, the next step is for the KW41 to write the pairing message into the NTAG I 2 C  plus memory. After SW3 is pressed: The KW41 uses the  I 2 C interface with the NTAG I 2 C plus to load a pre-defined NDEF message with the BLE pairing details. At the same time, the LED 4 is set to GREEN. Pairing with the BLE device While the LED 4 is set to green, the BLE pairing message is exposed through the NTAG I 2 C plus  RF interface. During this interval, any NFC-enabled device: Can read out the NDEF pairing message. Pass the BT credentials to the Android system or the host processor. And automatically create a Bluetooth link according to the exchanged network credentials. In case of an Android system, no third-party implementation is needed on this part as long as the pairing message follows the NFC Forum specifications. Writing default NDEF message Once the pairing information is read out of the NTAG I²C plus, the KW41Z removes the pairing content and turns back to normal operation mode. In addition, in this specific demo, the NDEF pairing message is programmed to remain in the NTAG I²C plus memory for only ten seconds. After these 10 seconds: The green LED is switched off. And the pairing NDEF message is overwritten by the default NDEF about the NTAG I²C plus demo app. Video The following video shows how the Bluetooth Low Energy (BLE) pairing with NFC on KW41Z and NTAG I 2 C plus works. How to integrate NTAG I2C plus into FRDM-KW41Z hid_device sample project In this section, we describe, step by step, how NFC is integrated in an existing default demo application taken from the KW41Z support package.   FRDM-KW41Z startup In the board website, there are very clear instructions on how to get started www.nxp.com/demoboard/FRDM-KW41Z. For instance: How to test KW41Z. How to get the tools, in our case: MCUXpresso, and the SDK for KW41Z. How to import, build and runn the examples included in the SDK for KW41Z, in our case: the ones inside the wireless_examples folder Importing FRDM-KW41Z SDK and hid_device sample project After that, we import the FRDM-KW41Z SDK and we import the sample project used as a basis for adding NTAG I 2 C plus support, this is the hid_device example located under the wireless/Bluetooth folder. Importing NTAG I2C plus middelware The NTAG I 2 C plus  middleware can be easily imported as a new folder in the project tree using the MCUXpresso File / Import menu. Once imported, the internal structure of the middleware should have this structure: HAL_I2C: The HAL_I2C files support access to the Kinetis I 2 C interface. HAL_ISR:  The HAL_ISR files support the interrupt handling and callback registration for the Kinetis MCU. HAL_NTAG: The HAL_NTAG source files provide an API that allow you to communicate with the NTAG chip and implements the NTAG command set to perform memory access operations from the I 2 C interface.  For instance, this API can be used to perform: Read / Write memory operations on EEPROM and SRAM (for example, to read data, you just need to indicate the memory address and length of the data to be read) Read / Write access to NTAG I 2 C plus registers (for example, you just need to indicate the register macro to be read). Functions for enabling the pass-through mode and handling the data exchange between interfaces (setting the data transfer direction is as easy as using this function). HAL_TMR: The HAL_TMR files support access to the timing hardware of the Kinetis MCU. Adding / changing GPIO pin settings All pin and GPIO settings are defined within the pin_mux.c file. For our application, the I 2 C pins need and a GPIO for the field detection need to be enabled.  Regarding the host interface: the I 2 C  pins for NTAG communication are configured using the BOARD_InitI2C() function, it sets the required I 2 C  port (port 0 for this MC) and set the right mode for the clock (SCL) and data (SDA) lines. Regarding the field detection: it is defined within the source code even though it is not used so far. It is left defined for future use. Within the pin_mux.c file, there are other functions which initialize; for instance, the buttons, LEDs, etc. These functions are called during the hardware initialization. NTAG I2C plus software and hardware initialization We move to the main_application, where some pieces of code need to be added. All code that has been added, is inside the #ifdef NTAG_I2C clause. First, we added: The I 2 C_driver and the ntag_app header files . The ntag_handle handler declaration. Then, the HW initialization is performed calling I2C_initDevice and the NFC_Initdevice() function is called to fill the  ntag_handle software handler. HID_device demo extensions The BLE demo application is written in the hid_device.c file and the whole behavior is handled in this file. The C-code printout in the blue box  below shows the content of the BleApp_HandleKeys() function, which handles the BLE activity and the changes made related to the NFC use case. Similarly, all new code additions are within the #ifdef NTAG_I2C clause. Mainly, the BleApp_HandleKeys() function function was extended to: Copy the pairing NDEF message to the NTAG I 2 C plus chip when the button SW3 is pressed. Set the LED 3 to green while the pairing NDEF message is available. Start a timer counter from the moment the SW3 button is pressed In addition, when the time counter is expired (expiration was defined to 10 seconds): The memory content of the NTAG I 2 C plus chip is overwritten by default NDEF message. The LED 3 is set to off. NDEF message for BLE pairing definition The last part missing to cover the NFC integration into the KW41Z refers to the files created within the application to declare the NDEF pairing and NDEF messages. The NFC Data Exchange Format (NDEF) is the NFC Forum specification defining an interoperable, common data format for information stored in NFC tags and NFC devices. The spec also details how to enable tags to deliver instructions to an NFC device so that the device will perform a specific action when a particular tag is read (open a browser, initiate a phone call, pairing, etc.). Every NDEF message can be automatically processed by any NFC device and execute the appropriate action without requiring the installation of any customized software / application and independently of the hardware manufacturer. There are several NDEF record formats that you can use in your implementation. Each NDEF record indicates to the application processor which kind of payload the message carries. In our demo app, the default NDEF message used belongs to a smart poster record and the NDEF pairing message, follows the protocol defined in the NFC Forum connection handover specification. Going to the source code, two application files for the NDEF handling were created: The app_ntag.h declares the two NDEF messages used in this demo. The app_ntag.c, implements a function which writes the NDEF message into the tag. As mentioned, the NDEF used for this BLE pairing was built according to the Connection Handover and BT secure simple pairing specifications and rules. On the image below, we copied the declaration of the NDEF pairing message. This is actually the hex bytes that are written into the tag memory. To highlight son relevant parts: We find the capability container and the NDEF TLV. These two fields are used by the NFC device to detect if the tag is loaded with NDEF formatted data into a Type 2 tag (like the NTAG I 2 C plus). After that, we find the record type name. This is the MIME type for the Bluetooth out of band pairing (written in its ASCII representation). It is followed by the device Bluetooth MAC address, and the complete local name (Freescale HID). The terminator TLV In case you are interested to know more about the NDEF message structure, you can check the NFC Forum specifications The data (MAC address 00:04:9F:00:00:04 & device name FSL_HID) read by the NFC device is sent to the Bluetooth controller to establish the Bluetooth connection. Default NDEF message definition  The NDEF used as thedefault_ndef message consist of two records: The first record was built according to the SmartPoster specification from the NFC Forum, which describe how to store a plain message followed by an URL. The second record is what is called Android Application record. On the image below, we copied the declaration of the NDEF default message. To highlight son relevant parts:   As the NDEF BLE message, the first data fields we find correspond to the container and the NDEF TLV structure for a Type 2 Tag. Then, we find the smart poster record, which includes a text field. In this example, it codes the text “NTAG I2C Explorer”  and a URI field which codes a the NTAG Explorer kit website URL. After that, we find the Android application record, which is used to automatically launch the app  or, if the app is not installed, redirect the user to Google Play. Finally, the terminator TLV. After 10 seconds, the application removes the BLE pairing NDEF and replaces it by the above described NDEF message. This can be easily demonstrated by tapping the phone after these 2 seconds, and validate that the NTAG I 2 C plus demo is automatically opened. Video recorded session   Available resources BLE pairing with NFC on KW41 and NTAG I 2 C plus source code www.nxp.com/downloads/en/snippets-boot-code-headers-monitors/SW4223.zip NTAG I 2 C plus kit for Arduino pinout www.nxp.com/demoboard/OM23221ARD FRDM-KW41Z board www.nxp.com/demoboard/FRDM-KW41Z

This post entry provides a guide to designing antennas for the NTAG I2C plus. This article has been structured as follows: How the NTAG I2C plus works The NTAG I2C plus is what we call a connected NFC tag. It combines a memory, a passive NFC interface and a contact I2C interface. Additionally, it has more features such as: A field detection pin, to send a wake-up signal to a connected MCU The Energy harvesting, able to power external devices The SRAM, a memory without writing cycles limitation The pass-through mode, for fast data exchange between interfaces Memory access control options, available from both NFC and I2C interfaces And the originality signature, to protect your brand against clones As such, it supports bidirectional communication between an NFC-enabled device and the host MCU and it is an ideal solution for Industrial applications, IoT nodes, meters, consumer electronics and accessories among others.  To enable the NFC interface, the chip needs to be connected to an antenna coil using the two dedicated antenna pins. How to design this coil is the main goal for today. NTAG I2C plus antenna design files The NTAG I2C plus support package includes development kits, demo apps, sample code, application notes, and, the design files of the Class 4 PCB antenna, and the Class 6 Flex antenna, which are available for direct and free download from the website.   These design files include: The schematics  The Gerbers The BoM Therefore, if you do not have any antenna size or shape constrains in your application, the easiest is to just copy & paste these reference antennas. On the other hand, if you need to design your custom antenna, NXP also offers a coil design Excel sheet to help you. I will talk more about it along the article. Basic antenna theory for NTAG I2C plus tags The NTAG I2C plus is an 8-pin package, with: The field detection pin The Vout pin The I2C serial clock and data Iines to the MCU The ground The VCC wo antenna pins NTAG I2C plus electrical input capacitance The NTAG I2C plus equivalent circuit can be represented with: A resistor, representing its current consumption And a parallel capacitor, representing the chip internal capacitance For the NTAG I2C plus, this capacitance is 50pF for both the 1k and 2k memory versions. Precisely, the chip capacitance is the most important factor for the antenna tuning. Antenna coil electrical equivalent circuit The antenna coil itself is a resonant circuit with an input impedance. The electrical equivalent model of the antenna coil consists of: An inductance A capacitance And some resistive losses of the loop antenna itself. The actual impedance value depends on:  The antenna material The thickness of the turns, mainly affecting the resistance  The distance between the windings, mainly affecting the capacitance The number of turns, mainly affecting the inductance  And the nearby environment Tag with an NTAG I2C plus electrical equivalent circuit When the NTAG I2C chip and the antenna coil are assembled, we can consider a parasitic resistance and capacitance generated by the connections between the chip and the antenna. This parasitic impedance depends on the assembly process used and the antenna material.  As a result, what we can observe in the schematic of the figure is that the NTAG I2C plus capacitance together with the parasitic connection capacitance and the antenna capacitance forms a resonance circuit with the inductance of the antenna coil.   The self-resonance frequency of a system is given when the imaginary part of the circuit equivalent impedance is null, and the system is only purely resistive. Considering the antenna loop inductance, the parallel equivalent capacitance and the parallel equivalent resistance of the tag, the resonance frequency and the quality factor of the tag can be calculated by these formulas. Antenna design procedure for NTAG I2C plus tags The antenna design procedure for the NTAG I2C plus tags is:  Design the antenna coil. This is about the antenna specs in terms of number of turns, track width, spacing, shape, etc according to your application requirements. Characterize the antenna coil and find its R, L, and C parameters. Calculate the parallel capacitor value required to adjust the tag resonant frequency Assemble the calculated capacitor and measure the results. If the results are not accurate enough, fine-tune the capacitor value, assemble and measure again as needed. Design the antenna coil  As part of the ISO14443 standard, six PICC antenna classes are defined. Per each of the antenna class, the physical characteristics and dimensions are defined. For instance, Class 1 is the largest, with a size comparable to the size of a regular credit card, and Class 6, which is the smaller one. In addition, Class 3 to Class 6 define two antenna shapes: a rectangular and a circular one. However, tag manufacturers are not constrained to conform to any of these dimensions. Therefore, its use is optional and rather intended to improve interoperability. As such, you may consider using these antenna sizes as a reference for your designs. The major parameter of the antenna coil is the inductance. This inductance can be estimated based on geometrical parameters and the material properties such as: The diameter for a round antenna or the overall length and width for a rectangular shape. The track width The gap between track The thickness And the number of turns To avoid cumbersome formulas, NXP offers you an Excel-based coil calculation tool to estimate the inductance of rectangular and circular antennas. This tool uses some parameters related to the material used and the antenna dimensions. And with it, it estimates the antenna inductance for you. Typically, the coil design steps include: An estimation of the electrical parameters, like the operating frequency and the chip capacitance The definition of the target inductance, we define the dimensions, the track width, the gap between track, the thickness, etc that achieves our target inductance. The production of prototypes. Based on the matrix run, with different inductance values deviated between 10-20% plus and minus the original value. Characterization of the coil prototypes. Based on this characterization, select the one with the best parameters for your application.  If needed, you can execute a second matrix run, with new prototypes, based on the first results. Measure the antenna coil parameters The antenna characterization can be done using a network analyzer connected to the antenna pads, isolated from the rest of the circuit. For our case, a low-end solution, such as the miniVNA PRO is sufficient. This device is cheap compared with the high-end devices like Agilent but still, accurate enough for our needs.  As a remark, it is fundamental that this characterization is done with the antenna placed at its final mounting position, so that all environment effects, like metal plates or others, are considered. Calculate the resonant capacitor value We use a network analyzer to measure the system resonant frequency after connecting the NTAG I2C plus to the antenna coil. As I explained before, the self-resonant frequency of the tag is given when the system is purely resistive. Most likely, the actual resonant frequency will not be 13.56MHz as we would like, but some other value. If that is your case, calculate the system capacitance at the current resonant frequency based on the equation derived from the NFC tag equivalent circuit shown previously. At this point: We know the current resonant frequency We know the antenna inductance, because we measured it before with the network analyzer And, as design parameter, we define the target resonant frequency With this data, we can use once again, this formula to calculate which is the resulting capacitance that would make our tag resonate to our target resonant frequency. Knowing the required total capacitance and the actual capacitance, we can calculate the extra capacitance missing. This is given by this formula: Regarding the target resonant frequency, for single tag operation, a tuning slightly above 13.56 MHz would lead to maximum read-/write distance. However, due to manufacturing tolerances, a nominal frequency up to 14.5 MHz would still operate well. Assemble and measure resonant frequency Therefore, the last steps are: Solder the capacitor in parallel Connect the network analyzer And measure the new resonant frequency  If the resonant frequency measured is not the target one, repeat the process by fine tuning the capacitor value.  If the frequency is higher than expected, you can increase the capacitor value. On the other hand, if the frequency is lower than expected, you can decrease it. Example: Tuning for a 54x27mm PCB antenna Based on a real lab exercise, this section illustrates the steps to adjust the tuning of an antenna for the NTAG I2C plus. As described before, we need to start by characterizing our antenna coil. In this lab exercise, we have used a PCB antenna of 54 by 27 mm and, we have connected our miniVNA PRO to the antenna pads. The results that we have obtained from this measurement are that our PCB antenna has an inductance around 895 nH. After characterizing the antenna coil: We have soldered the NTAG I2C plus chip to this PCB antenna. Right after, we connect again the miniVNA PRO to measure the actual resonant frequency.  In this case, it returns a resonant frequency near 24 MHz. Using the formula, we calculate that the tag capacitance at 24 MHz is almost 50 pF. Note that, the actual capacitance is basically the chip capacitance as the antenna and connection capacitance is usually not impacting significantly. Obviously, a resonant frequency of 24MHz is way too high for a ISO14443 NFC tag like our NTAG I2C plus. Therefore, we need to add some capacitance to the system so that we can bring this resonant frequency down. As an example, for this lab exercise, we are adjusting the tag to around 13.6 MHz, intentionally a bit higher than the NFC operating frequency. With a target resonant frequency to 13.6MHz and an antenna inductance is around 895nH,  the result is that the tag needs a total capacitance of around 153 pF. This means that we need to solder an extra capacitance of 100pF to bring down the resonant frequency.  So we go to our component box, and select the closer commercial value (100pF). As a last step, it is worth to measure how well adjusted is our system after adding the 100pF. We connect the miniVNA to the system including the IC, the antenna and the 100pF. Now, the results obtained are that the resonant frequency is 13.8 MHz. In our case, we consider this as good enough. However, you are always free to repeat this process as many times as needed until you obtain the accuracy that you need. Summary The antenna tuning steps for the NTAG I2C plus that we followed are: Design the antenna coil. You can use the NXP reference antennas or design your own antenna coil using the NXP Excel-based calculation tool. Measure the antenna coil. Use a network analyzer connected to the antenna pads, without any other circuitry Calculate the extra capacitance. Measure the current resonant frequency, and we calculate the extra capacitance needed to achieve the desired operating frequency. Solder and measure. If the results are sufficient, you are done. Otherwise, repeat the process with a new capacitance value As you can see, the antenna tuning process is quite straight forward. Basically, it is a matter of adjusting the capacitance of the tag until the operating frequency is the right one. Further information You can find more information about NFC in: NTAG I2C plus website http://www.nxp.com/products/:NT3H2111_2211 NTAG antenna design guide support package https://www.nxp.com/docs/en/application-note/AN11276.zip NXP technical community: https://community.nxp.com/community/identification-security/nfc NXP design partners: https://nxp.surl.ms/NFC_AEC Video recorded session On 25 July 2018, a live session explaining this topic was delivered. You can watch the recording here:

Combining NXP's wireless MCU with NFC controller allows to build a BLE-NFC bridge. It allows demonstrating transmission of NFC data over BLE, acting then as a king of Magic NFC remote. This demonstrator is built assembling the OM5578: Development Kits for PN7150 Plug’n Play NFC Controller (OM5578/PN7150ARD version including Arduino compatible connectors). on top of the FRDM-KW41Z: Freedom Development Kit for Kinetis ® KW41Z/31Z/21Z MCUs (minimum version B1 since previous versions have a pin conflict on the Arduino connector) Alternatively the Rigado R41Z Eval Board can be used as replacement to the FRDM-KW41Z To complete the demonstration, an android phone is used as BLE counterpart. It shall run the modified version of Kinetis BLE Toolbox android application including the NFC demo part. This dedicated version of the Kinetis BLE Toolbox android application is available for download from the files attached to this document. Below is a video of the demo. As shown, it demonstrate capabilities to control the NFC discovery remotely (via BLE) from the phone. Then, if tapping a card on the bridge, the related information including the content is conveyed through BLE to the phone and get displayed by the app. Additionally, the app can configure a message to be shared whenever an NFC reader (e.g. NFC phone) tap the bridge. The K41Z firmware of this demo is built based on the wireless UART example from MCUXpresso Software Development Kit (SDK), and updated with the porting of the NXP-NCI MCUXpresso example. The complete MCUXpresso project is given in source code in the attached files. To replicate the demo, just import it in an MCUXpresso workspace by selecting "Existing Projects into Workspace", then browsing to the BLE-NFC_bridge_MCUXpressoProject.zip file. Select the frdmkw41z_BLE-NFC_bridge from the "Project Explorer" view, and click on the blue bug icon to build, flash and debug the program.

Speed development time when designing your portable medical device with NXP's Healthcare Analog Front End (AFE) reference platform which includes a complete hardware platform, schematics and software.  Based on the Kinetis Microcontroller K53 measurement. Demo Owner: dr.josefernandezv Demo Owner: aleguzman Features Speed development time when designing your portable medical device with NXP's Healthcare Analog Front End (AFE) reference platform which includes a complete hardware platform, schematics and software NXP offers a complete development platform based on the Tower System, which eases the development of medical applications with a fully integrated set of solutions that reduces the design effort The Medical suitcase is composed of six different analog front ends, each one focused on a specific medical application. Applications included are, 1-Lead ECG, pulse oximeter, blood pressure monitor, glucometer, spirometer, and ultrasound digital stethoscope Featured NXP Products K50_100: Kinetis K50 Measurement 100 MHz MCUs Healthcare Analog Front End( AFE) Block Diagram

Demo This demo showcases a bluetooth headset using NXP’s Near Field Magnetic Induction device NxH2280, enabling truly wireless streaming of voice, audio and data. The demo is built using the NxH2280 Application Development Kit for hearables Features: very power efficient audio and data streaming from ear-to-ear: HQ audio < 2.5 mW works through human body with ultra-low absorption: SAR is 100 times lower than Bluetooth ensures reliable and private communication _______________________________________________________________________________________________________ Featured NXP Products: NxH2280: Near Field Magnetic Induction radio|NXP LPC1102: low power, space efficient microcontroller|NXP NT3H1101: Energy harvesting NFC Forum Type 2 Tag for bluetooth simple pairing|NXP _______________________________________________________________________________________________________ Picture of demo: implemented using headphone shells Picture of NxH2280 ADK C11

This post entry provides a detailed description of how to port the NFC Reader Library to Kinetis K64F MCU. It is used a real porting example exercise to show the steps required to adapt the NFC Reader Library to a sample target MCU. The goal of this post is to serve as a guide for software developers requiring to port the NFC Reader Library to their MCU of choice for their designs. NFC Reader Library overview The NFC Reader Library is a software stack for creating and developing contactless applications for NXP’s NFC frontends and NFC controllers with customizable firmware. This library provides an API facilitates the most common operations required in NFC applications such as: reading or writing data into contactless cards, exchanging data with other NFC-enabled devices or emulating cards. The NFC Reader Library: It is based on a modular approach It has been designed with a flexible and multilayered architecture It is written in ANSI-C programming language It is supported in multiple design environments and platforms and it has been developed with a strong focus on portability. It is available for free download. The NFC Reader Library v5.02.00 currently supports: All our NFC frontends (CLRC663 plus PN5180) and PN7462 NFC controller. Their corresponding development boards, used as NXP reference HW (CLEV6630B, PNEV5180B, PNEV7662B) And built-in MCU support for LPC1769, LPC11U68, FRDM-K82F and Raspberry Pi. In addition, the release includes several examples to get familiar with the library and which can be used as reference for your developments and, it is also included an HTLM-based API documentation for all the components, which is generated from source-code annotations. NFC Reader Library architecture The NFC Reader Library is encapsulated into layers, differentiated by colors, and components, differentiated in boxes. From top to bottom, we have: The Application Layer (AL), which implements the command sets to interact with MIFARE cards and NFC tags. The NFC activity, which implements a configurable Discovery loop for the detection of contactless cards, NFC tags or other NFC devices. Next to it, the HCE and P2P components, for the emulation of Type 4 tags and P2P data exchange respectively. The protocol abstraction layer (PAL), which contains the RF protocol implementation of the ISO14443, Felica, vicinity and NFC standards. One level down, the hardware abstraction layer (HAL), which implements the drivers for controlling the NFC frontends RF interface and capabilities. Below, the Driver Abstraction Layer (DAL), newly introduced in the latest release, which implements the GPIO pinning, the timer configuration and the physical interface (BAL) between the host MCU and the reader IC. Finally, the OSAL module, in charge of abstracting the OS or RTOS specifics (handles tasks such as timers, events, semaphores and threads) This layered architecture is helpful for several reasons: The eleven software examples, the Application Layer (AL) and the Protocol Abstraction Layer (PAL) are HW-independent, so that can be used on top of any NFC frontend. The the Application Layer (AL), the Protocol Abstraction Layer (PAL) and the Hardware Abstraction Layer (HAL) are platform-independent, so that can run in any MCU without any additional change. In case the reader MCU is part of the built-in support, the examples can be directly imported and executed straight forward. On the other hand, in case the reader MCU is not supported by default, the major advantage is that only adaptations in the DAL and OSAL layers are required, while the rest of the layers can be used without any modification. The NFC Reader Library structure can be seen more clearly when imported in the MCUXpresso development environment. After completing the import wizard, all projects are listed in the “Project Explorer” window. As can be seen in the screenshot, it contains different folders: API documentation folder Driver Abstraction Layer FreeRTOS support The platform support (in the screenshot, corresponding to the LPC support) The software examples (11) The Reader Library implementation And the OS abstraction layer NFC Reader Library porting to FRDM-K64F steps In the existing NFC Reader Library v5.02.00 release there is no native support for Kinetis K64F. However, it is included a pre-compiled package for Kinetis K82F MCU. We use the K82F NFC Reader Library package as a reference project to start the porting to K64F MCU. This package can be downloaded from www.nxp.com/pages/:NFC-READER-LIBRARY. The steps required to port the library to Kinetis K64F are: Prearing the HW (i.e the pining between the Kinetis and the NFC reader board). Setting up the development environment (i.e workspace). Perfoming some changes in project configuration settings Performing some code modifications in the DAL and application code for adding Kinetis K64F support. NFC Reader Library porting to FRDM-K64F - Preparing the hardware The hardware used for this porting exercise is: A CLEV6630B board (CLRC663 plus) as an NFC transceiver  A FRDM-K64F board (Kinetis K64F) as host MCU, used to load and run the application logic. The CLRC663 plus evaluation board is connected by default to an LPC1769 µC via SPI. However, the board is made in such a way that the LPC1769 MCU can be bypassed to connect an external MCU easily. For doing so: Six resistors from the board need to be removed. These are highlighted in red. Use the SPI pin connectors available on the left hand side, on the board edge. Next, to connect the two boards together, the pining routing was done as follows: We use the Kinetis K64F jumper 2 pin line for the MOSI, MISO, chip select and clock lines of the SPI communication. The IRQ, interface selection and reset pins of CLRC663 plus are connected in jumper 1 pin line. And, one ground pin used for reference. Therefore no complex HW manipulation was required since all interfaces are easily accessible via dedicated headers or test points. NFC Reader Library porting to FRDM-K64F - Setting up the development environment Once the HW connection is prepared, we can move to setting up the development environment and workspace. Get the latest NFC Reader Library release From the software perspective, first we need to download the latest NFC Reader Library package. To do so: Go to NXP dot com slash pages slash NFC Reader Library (www.nxp.com/pages/:NFC-READER-LIBRARY) Go to the Downloads tab and click on the download button Click download on the NFC Reader Library for Kinetis K82Fpackage. Generate a downloadable SDK package for FRDM-K64F board As part of the NXP support, an SDK with drivers, middleware, RTOS demos and more is available for any of its Kinetis and LPC micros.We need to build the corresponding one to K64F SDK. For that: Navigate to www.mcuxpresso.nxp.com and select SDK builder option. Then, use the drop-down menus to customize your SDK configuration, middleware and optional software components be included in the package. Select Request build. In a few minutes, you will receive an email with a link to download the SDK package, very similar to the one showed in the figure below. Import the NFC Reader Library into MCUXpresso workspace Next step to configure the development environment is to import the library package in the workspace. The easiest way is to use the Quick Start Panel on the left hand side. Click on Import project from file system Then, browse the library package in your file system. Click Finish to import it all to your workspace. Install and link FRDM-K64F SDK into MCUXpresso workspace The last step is to import the K64F customized SDK we configured from the MCUXpresso tools. To do so: Just drag and drop the SDK into the installed SDKs tab of the MCUXpresso IDE. (It will appear in the bottom part, in the center) Import the SDK into the workspace and link it with the software examples. It will appear as another folder in the project explorer window. If the K64F SDK has been properly imported in the workspace, we should see a new drop-down menu for K64F. From there, we should select K64F and click Apply so that the memory details for K64F are set to the project example NFC Reader Library porting to FRDM-K64F - Project configuration changes At this point we have the hardware and the workspace for software development ready. In this step, we will start porting the NfcrdlibEx1_BasicDiscoveryLoop  software example provided as part of the NFC Reader Library release. Select FRDM-K64F SDK in the project MCU settings One of the first configurations to be changed is the project MCU settings. These settings indicate which target host device is running the application code. These settings can be found if: You right click on the project example > Properties In the left-hand list of the Properties window, open “C++ build” and select “MCU settings” In the right-hand panel, we can observe the corresponding settings for K82F micro. The left figure indicates the project configuration settings used by the default SW example prepared for K82F while the right figure indicates the final project configuration settings used by the SW example ported to K64F. Define FRDM-K64F SDK preprocessor symbols in the project After that, we need to change the compiler preprocessor settings, which can be found in C++Build > Settings. In the project examples of the NFC Reader Library, the conditional directives like #ifdef and #ifndef are used to include or exclude portions of the code from the actual compilation. The conditional codes are included in the program compilation only if the MACROs are defined in the project compiler preprocessor settings. In the left side we can see the defined macros for the original project. Among them, includes one which defines that the HW used is PN518 and K82F board. Therefore, in the ported project, we need to replace the macros corresponding to K82F with the new ones corresponding to K64F.  For instance, the PHDRIVER_K64_CLRC663 macro includes in the compilation the files related to the new HW used in the ported project (for the board pin and GPIO config, SPI settings or timers). Precisely, these files are included inside BoardSelection.h file in the Driver Abstraction Layer (DAL). Add include paths for FRDM-K64F SDK files When including header files into our project, the compiler must be told which directories must be searched to find those files. To do this: Open the project properties. In the left-hand list, open “C++ Build” and Select “Settings”. In the right-hand pane, choose the “Includes” section. Click the “Add icon”. In the left figure, we see the compiler include paths for the K82F SDK of the original example. In the ported example, the K64F SDK sources will not yet compile since we did not tell the compiler about all the new include paths. Therefore, we need to add the new include paths pointing to the K64F SDK and put them into the MCUXpresso IDE project. In the right figure, you can see the paths we included for this purpose. Mainly, these paths reference to the board system init, board drivers, CMSIS files and debug utils. Add include path for FRDM-K64F MCU assembler The last MCUXpresso settings to be changed is in the MCU Assembler. This can be found in the right-hand panel, choose the “MCU Assembler” and select “General”. In the original source code, a path is used to the K82F SDK. In the ported example, we just need to remove the previous include path and replace it with the corresponding one pointing to the K64F SDK in our workspace. NFC Reader Library porting to FRDM-K64F - Code changes So far, we have the HW, the development environment prepared and the project configuration settings changed. At this point, there are only a few code changes to be done before the porting is completed and the software example can be run in K64F. DAL driver adaptation for FRDM-K64F The layered architecture of the NFC Reader Library makes porting easier since only the lower drivers need to be adapted. This driver includes functions for: The physical link connection establishment between the CLRC663 plus and K64F The init functions for timers and interrupts so they are correctly used by the application layer. Going to the NfcrdlibEx1-BasicDiscovery loop project structure, it contains several folders. If we open the DAL > board folder, we can observe one source file per each supported platform (LPC with PN5180 and CLRC663, and the same for Raspberry Pi and Kinetis K82F). Our task for the porting would be to create an equivalent source file for the new supported board, the K64F together with the CLRC663 (e.g. Board_FRDM_K64FRc663.h). This file includes The related board pin and GPIO configurations The SPI configuration The timer configuration In addition, we need to include the board, pin_mux and clock config files. Use SDK examples to get FRDM-K64F board specific configuration Implementing these board specific files, in some cases, could be time consuming and may require experience. However, you do not need to do so but rather use the existing source files. For that, you can use any of the existing SDK software examples. You can easily import one SDK example by: Clicking the “Import SDK” example in the quick start menu > select the FRDM-K64F board. Selecting the demo example. Each example application has its own unique copy of the board, pin mux, and clock config files that you can reuse for the porting (Note: this process could be different depending on the MCU used). Add FRDM-K64F macro definitions in the source code Next, along the project tree, we need to add the #ifdef directives, indicating that K64F board files that need to be compiled. This is the case for: The BoardSelection.h file The ph_NxpBuild_App.h, which links the board with the reader IC by enabling the CLRC663 plus module in the HAL layer. The ph_AppInit.h so that the board is initialized when the reader device boots. Add FRDM-K64F CPU initialization code The ph_AppInit.h  file takes care of the code initialization and code specific to the HW used to run the example. As part of this ph_AppInit.h file, there is a function in charge of initialization the host MCU. Here, we need to implement the corresponding function for the K64F init, based on the SDK example source code selected earlier. If we look within this routine, we actually find functions for: Configuring the MCU clocks. Configuring the MCU pins. Configuring the interrupts (PIT). NFC Reader Library porting to FRDM-K64F: NfcrdlibEx1_BasicDiscoveryLoop execution After following the previous steps, the source code is succesfully ported to K64F. The following video demonstrates the correct execution of the NfcrdlibEx1_BasicDiscoveryLoop example in FRDM-K64F host MCU connected to CLRC663 plus NFC frontend (CLEV6630B). The video includes a webcam, which records the HW, including all the witing wiring between the K64F and the CLRC663 plus antenna. After the code is built and compiled, the video shows how some tags are tapped to validate that the example is working as expected (tag's UIDs are displayed in the MCUXpresso console). . General considerations to port the NFC Reader Library to your target MCU Overall, the general steps required to port the NFC Reader Library to your target MCU are: Adapt the MCU drivers to the DAL layer in the NFC Reader Library. This typically includes: timers, interrupts, pining and host interface configuration between the NFC reader and host MCU sides. Adapt the OS layer (i.e. you might need to port the FreeRTOS or to your target OS platform). Adapt the source code examples: project settings (macros, include paths, MCU configuration) and perform the required code modifications (Code for HW initialization, board files, etc). Available resources NFC Reader Library:  www.nxp.com/pages/:NFC-READER-LIBRARY CLRC663 plus: www.nxp.com/products/:CLRC66303HN CLRC663 plus development kit: www.nxp.com/demoboard/OM26630 FRDM-K64F board: www.nxp.com/demoboard/FRDM-K64F Video recorded session

This post entry provides a detailed description of how NFC can be used for authentication and identification of consumables and accessories. This document has been structured as follows: NFC for product authentication and identification NFC is a useful addition to verify product authenticity and identification. There are plenty of examples where NFC fits nicely, for instance: For anti-counterfeit protection and safe brand reputation. For identifying users and provide personalized interactions For sending notifications when accessories need to be replaced And to automatically adjust settings of the main unit based on the accessory attached. These are just a few examples so you grasp the potential of NFC in such scenarios. How NFC works in product authentication and identification Into the scope of a consumable or accessories authentication via NFC, there are always two components involved.  On the one hand, there is one main unit. This is the device where you can plug the part or the accessory. Typically, this main unit would include an active NFC reader. On the other hand, the consumable or replacement would include and NFC tag. The NFC reader in the main unit can detect when the removable part is connected. As soon as the replacement is connected, it reads the information stored in the tag and uses it to verify the accessory originality. Precisely, the information and security features implemented in the tag is what allows the main unit to: First, authenticate that is a genuine accessory And optionally, configure related settings depending on the accessory. Success stories The NFC authentication is not a proof-of-concept but rather a consolidated solution. There are already some success stories in the market. For example: A high-end blender that uses NFC to verifies the authenticity of the containers and cups used. In addition, the blender adjusts the speed parameters automatically per each different container. As mentioned, the NFC reader is part of the base unit while the tag is part of each container. Another example, a face brush that make sure that the brush head is genuine. As before, the reader in on the base while the tag is on each head brush. When a new head brush is connected it check its validity and adjust the settings. The third example is a fridge that discards non-original water filters and check if the fridge and filter models are compatible. How to implement the use case From a simplified block diagram perspective, the base unit embed an NFC reader, this NFC reader is made of an NFC frontend, generating the RF field and a Host MCU, loaded with the application firmware. On the other hand, the accessory, beds an NFC tag. The MFRC630 or our SLRC610 are recommended options from the reader side, while the NTAG and ICODE families are recommended from the tag side. The final product selection depends on your specific application requirements There are a few questions that you can ask yourself to know which product fits you best. First, what is your application about? Are you looking for brand protection? Or counterfeit detection? Or settings customization? Second, what kind of security you need? You need device identification, or you also would like encrypted data exchange? Third, what reading distance is required in your system? Are we talking about a centimeters or tenths of centimiters? And, in relation implementation details, are there any specific size constrains? Is there metal in the surrounding? Etc. NFC portfolio for authentication and identification applications I organized the security features for consumable authentication in three groups: There is a basic level security level where the tag UID is used for proof-of-origin. In this case, there is no crypto protocols applied and the verification consists on checking whether the UID is in our database or not. There is a second level, where the authentication is proven using an originality signature. Depending on the solution, this can be an NXP- signature or a customer-specific signature. There is a third level, that uses a cryptographic three pass mutual authentication as a verification mechanism. NXP originality signature The originality signature implemented in NTAG and ICODE families is based on standard Elliptic Curve Cryptography. NXP generates a ECC key pair (a public and a private key) that are stored in a secure server. In asymmetric crypto, a signature is generated by a signing algorithm given a message and a private key. During production, NXP takes care of provisioning a die-individual signature in each IC. This signature is generated using the tag’s UID and the NXP private key. Since each tag has a different UID, a unique signature is stored in each tag. Therefore, the tags leave the NXP factory already with this unique signature pre-programmed in the IC memory. These pre-provisioned tags are integrated by OEM into their final devices & accessories. On the field, the originality signature verification process is as follows: First, the reader unit reads the tag UID. Second, the reader retrieves the tag signature with the READ_SIGNATURE command. Third, the reader can verify this tag originality signature using the corresponding ECC public key and the tag’s UID. With this feature, it is possible to verify with confidence that the tag is using an IC manufactured by NXP and not a cloned IC. In case that the public key is stored in the reader, the entire process can be performed offline. The products supporting this functionality are: NTAG21x, NTAG413 DNA, NTAG I2C plus, NTAG21x F and ICODE SLIX2. OEM customizable orignality signature The NFC tags come pre-programmed with an NXP originality signature. However, some NTAG and ICODE family members also offer the possibility to customize the originality signature per OEM. The process is similar to the one described above, but in this case, the OEM provisions each tag with a die-individual signature, and lock it to avoid unauthorized overwriting. On the field, the tag originality signature verification is done in the same way: The reader retrieves the tag UID and tag signature The reader uses the corresponding OEM public key and tag UID to verify the signature. The main benefit of customizing the originality signature is that, in addition, it allows to verify that the product belongs to the OEM and not from another manufacturer. The products supporting customer originality signature are NTAG210u, NTAG 213 TT and ICODE DNA. Secure unique NFC message (SUN) One security level up, we find solutions like our NTAG 413 DNA which enable a new Secure Unique NFC message (SUN) feature. This SUN feature generates a unique, secure authentication code each time the tag is tapped. This tap-unique data consists of an NDEF formatted packet that includes: A URL The tag UID The tap counter And a AES-based CMAC calculated over the UID, the counter and the URL. This CMAC is dynamic and changes over each tap since the counter is increased every time. The cloud service verifies the authenticity of the message with the appropriate symmetric keys. With this tag, any NFC enabled device (including Android and the recent iOS 11 devices) can automatically connect to a web based service and based on the information contained in URL, the device can check the tags authenticity and verify the information validity. AES three-pass mutual authentication The last tag security feature is the AES mutual authentication, which is supported by our NTAG 413 DNA as well as the ICODE DNA. The mutual authentication: It is based on a shared secret key known by both endpoints It allows us to verify both ends of the communication (not just the accessory). . The AES 3 pass mutual authentication consist of probing to the other end the knowledge of a secret, in this case, the knowledge of a secret AES key. As we do not want to share in plain this secret over an unsecure channel, the mechanism is based on the encryption of random challenges using this secret key. If both ends are capable of verifying this random-challenge scheme, they demonstrate that the other end knows the secret, and therefore, they prove their authenticity. NFC tag security feature comparison The following table consolidates the different NFC tag security options:  The NTAG21x support NXP originality signature The NTAG210u is a cost optimized version with customizable originality signature The NTAG413 DNA offers the SUN feature as well as AES authentication and encryption Finally, the ICODE DNA comes with customizable originality signature and AES authentication. Therefore, the NTAG413 DNA and ICODE DNA are the strongest authentication options that we have right now in the tag portfolio. The reading distance will influence on the decision between NTAG or ICODE: NTAG is an ISO14443 compliant tag with a operating distance of a few centimiters. ICODE is an ISO15693 compliant tag with an operating distance of tens of centimers. NFC frontends comparison Regarding the NFC readers for the base unit side, we most ideal solutions are: The SLRC610 plus if your application needs a reading distance of tens of centimiters. The SLRC610 supports ISO15693 and is fully operational with our ICODE family. The MFRC630 if your applications needs a reading distance of a few centimiters. The MFRC630 supports ISO14443-A and is fully operational with our NTAG family. NFC Nutshell kit This section leverages on the NFC Nutshell kit to explain how to develop your own NFC authentication solution. This kit was developeb by GMMC an approved engineering consultant of NXP. The NFC Nutshell kit is a set of hardware modules that can be used for: NFC integration into new designs or retrofitting into existing products thanks to its small size. It can be used to build NFC demonstrators Or, it can be used for evaluation, development and testing of NFC applications The main benefits offered by the NFC Nutshell kit are that: It is made to provide designers with Nano sized hardware modules which can be configured and combined in a variety of ways. It was developed with flexibility in mind so that designers can easily combined different MCUs with different NFC frontends and multiple development environment easily. And, it is constructed and prepared to be compatible with NXP software tools. NFC Nutshell kit components The kit includes a good bunch of modules that be divided in 4 different groups: Host interface modules A USB plug that bridges the USB communication to the Host MCU A USB converter that is used to communicate over UART, I2C or SPI with the host MCU A host interface signal debug extender MCU modules: LPC1769 LPC11U68. NFC reader modules: CLRC663 plus PN5180 And soon, PN7462 and PN7150 Antenna PCBs of different sizes to test the performance over different antenna sizes (20x10mm, 20x20mm, 40x40mm, 72x48mm). All the modules are connected with flexible flat cables, and the hardware components are designed for minimal PCB area to demonstrate integration into space constrained products. Modes of operation for the USB protocol converter module In our case, out of the different host interface modules, we select the USB to I²C, UART and SPI converter. This single module itself has several configuration options. As part of the kit, a USB Protocol Converter Configure Tool is provided to easily configure the different operation modes of this component. The user can open this tool and check the different options: The first one is used when the converter is connected to an MCU. It configures the module for an in-system-programming, which means we can use NXP Flash Magic Tool to program the MCU flash memory.  The second option, the development PC communicates directly to the connected NFC frontend via UART.  Last, we have 3 bridge modes for single protocol conversion. The Host system can send the any command over the USB interface and it will be converted to the chosen protocol, either I²C, SPI or UART.  NXP development tools supported Another nice feature of this NFC Nutshell kit is its native support of NXP development tools. Using this kit, you can seamlessly run: The NFC Cockpit, an intuitive graphic user interface that lets you configure and adapt IC settings without writing a single line of software code. The RFIDDiscover PC tool, a user-friendly GUI for evaluation of NTAGs, ICODEs or MIFARE Cards. It is the software that is commonly used with NXP Pegoda reader. The NFC reader library, a complete SW support library for RF frontend ICs. The faster and more straightforward way to develop NFC applications. Consumable authentication using the NFC Nutshell kit This last section is meant to give insight on how to develop your own NFC authentication solution. For that, we will make use of the NFC Nutshell kit and existing software examples as a way to illustrate a possible development process.  The five steps that we followed to run a tag signature verification software example in the NFC Nutshell kit are: First, we select and connect the right modules together Second, we configure the host system interface according to our SW development environment. After that, we develop the application logic of our use case. When the code is ready, we build the project, and create the binary file. And last, we use the Flash Magic tool to install the binary file. Hardware preparation About the hardware preparation… the modules selected are: The USB protocol converter module, as an interface converter between the development PC and the reader host MCU. The LPC1769 as the reader host MCU The CLRC663 as NFC frontend And, the 40x400 mm PCB antenna. USB converter module configuration Before going to the software development itself, we need to configure the USB protocol converter. The USB protocol converter mode of operation configuration is a straight forward process. We just need to execute the Configure Tool provided in the kit, and select the mode compatible for Flash Magic.  In this case, this setting corresponds to the first choice as shown in the screenshot. Software development with the NFC Reader Library For the application software development, we leverage on our well know NFC Reader Library. The NFC Reader Libary is a complete API for developing NFC and MIFARE-based applications, it is free of charge and the latest release can be downloaded from www.nxp.com/pages/:NFC-READER-LIBRARY. Great news is that the NFC Reader Library has: Native support for the modules we selected out the NFC Nutshell kit (the CLRC663 plus and LPC1769) Supports the proximity and vicinity RF protocols. And also, the commandset of Type 2, Type 4 and Type 5 tags. Therefore, we can focus on developing the application logic rather than spending time on implementing drivers or the RF protocols. For that, we do not even need to start from scratch, because we can take as reference any of the eleven software examples. Each of these examples do not make use of the entire library, but just use the NFC Reader library components required for the use case demonstrate, allowing to reduce the overall memory footprint. NXP Originality signature verification We take the Basic Discovery loop example as a starting point for developing an piece of code for tag originality signature verification. If we have a look at the source code, this example: Initialize the library, this is initializing the SW components that will be used It configures the discovery loop for tag detection Keeps iterating until a tag is detected Once the tag is detected, we mentioned that the signature verification process consisted of: Retrieving the UID Retrieving the signature Use a signing verification algorithm to check the signature There are several libraries implementing ECC signature validation. As an example, we added an open source C library called nano-ECC into our project. The function call ecdsa_verify() can process the originality signature read from the tags. It is just as simple as passing as arguments, the UID the signature and the public key. In addition, the NTAG Originality signature validation application note provides code snipets and instructions for this process as well. Three-pass mutual authentication Another example for the implementation of a AES three-pass mutual authentication. Once again, we can take as a starting point the Basic Discovery loop example, which: Initializes the library, configures the discovery and iterates until a tag is detected. In addition, we need to add the crypto component in the NFC Reader Library handling the crypto calculation and key storage (in orange) Once the tag is detected, we can make a direct API function call of the corresponding tag type, whether it is a Type 5 (ICODE) or a Type 4 tag (NTAG 413 DNA) there is the right function call in the lib for that. All the crypto complexity of the three pass mutual authentication is just hidden behing a single function call. Build project with MCUXpresso The MCUXpresso tools is used to build and compile the solution by clicking in the hammer button down in the quick start panel. Create .hex file with MCUXpresso After that, we can also generate the .hex file. For that, we just need to right click on the binary file, go to binary utilities and click on create hex file option. Flash the MCU image with Flash Magic tool With the .hex file generated., the last step is to flash our MCU with this .hex file. In the Flash Magic tool menu, select: The MCU used, in this case LPc1769 The COM port, which can be found in the Windows device manager, in our case COM72 Select the path to the .hex file Click start Once the flashing is completed, the USB converter setting should be changed to I2C or SPI configuration. At this moment, the solution is running and the application will try to authenticate any tag presented in front of the reader. Debugging mode Optionally, the NFC Nutshell kit also incorporates a code debugging mode. For that, there is an extra HW module compatible with LC1769 and LPC11U68 that can be used to interface with an LPC-Link2 debug probe. Video recorded session On 22 February 2018, a live session explaining the NFC for consumable and accessories solution was recorded. You can watch the recording here: Available resources The available resources referred to this post explanation are:  Tags: NTAG 413 DNA NTAG 210μ NTAG 213 TT ICODE DNA Readers: MFRC630 plus SLRC610 plus Application notes: AN11350 NTAG Originality Signature Validation NFC Nutshell kit: GMMC

LPC54114 Audio and Voice Recognition Kit The LPC54114 Audio and Voice Recognition Kit provides a complete hardware and software platform for developers to evaluate and prototype with the LPC54114 processor family. It has been developed by NXP® to provide all that you need to develop an always-on low power voice triggering product. Features: LPCXpresso54114 (OM13089) development board with: LPC54114 dual-core (M4F and dual M0) MCU running at up to 100 MHz in LQFP64 package. Hi-speed USB based debug probe with CMSIS-DAP and SEGGER J-Link OB protocol options. Connectivity for external debug probes. Micro USB connector for LPC54114 USB device operation. Tri-color LED. Target Reset, ISP and interrupt/user buttons. On-board 1.8 V / 3.3 V or external power supply options. 8 Mb Macronix MX25R SPI flash. FTDI UART connector and built-in UART to USB bridge options. Built-in MCU power consumption and supply voltage measurement for LPC54114 device. UART, I²C and SPI port bridging from LPC54114 target to USB via Link2 device. FTDI UART connector. Digital Mic/Audio codec/OLED display (“MAO”) shield with: Knowles SPH0641LM4H digital microphone. Cirrus Logic (Wolfson) WM8904 audio codec with stereo line in/out sockets. Monochrome OLED display (160 x160 pixels). Demos: Include USB/I2S audio demo, as well as voice recognition demos leveraging partner technology (Malaspina and Sensory) http://cache.nxp.com/documents/application_note/AN11855.zip Videos: These videos showcase the NXP’s LPC54114 MCU in a kit designed for customers to evaluate its capabilities for audio and voice processing _______________________________________________________________________________________________________ Featured NXP Products: Product Link LPC54000 Series LPC54000|Power Efficient 32-bit Microcontrollers (MCUs)|Cortex®-M4 Core | NXP  LPC54114 Audio and Voice Recognition Kit https://www.nxp.com/design/microcontrollers-developer-resources/lpcxpresso-boards/lpc54114-audio-and-voice-recognition-kit:OM13090?&fsrch=1&sr=1&pageNum=1 _______________________________________________________________________________________________________

This post entry provides a detailed description of how to develop an NFC pairing solution for audio devices. For that, we will describe in detail an audio speaker prototype made by NXP. This post entry has been structured as follows: Use cases for Bluetooth and Wi-Fi pairing via NFC As the number of connected devices grow, the more important it becomes to connect them in a simple way. At the same, it is required to provide a consistent and pleasant user experience. NFC pairing is one popular NFC use case, just bringing two NFC-enabled devices close together is all it takes to create a connection. For instance: To connect to your TV, to transfer a video from your phone, or sharing screens between your tablet and the TV. To connect to your camera to transfer pictures. To connect your phone to a wireless speaker. To connect your new devices to the home network. To connect to your wearables to read your heart rate. Or, to set-up a multi-audio system with NFC. Precisely, this post will guide you through the implementation of the NFC pairing solution for a multi-audio system. Benefits offered by the NFC pairing solution There are several benefits to consider adding NFC to your consumer device. First, from the consumer perspective: It provides a faster and simpler way to link wireless devices, only one touch. The credentials for establishing this connection are exchanged in a secure way. The device is identified instantly, without conflicts. In addition, from the manufacturer perspective, the benefits come mainly from: Making the device more attractive, by adding a new feature. And making the device easier to use, reducing the cost associated to customer technical support. Overall, NFC pairing is an interesting solution since it combines the simple, one-touch setup of NFC with the higher speed, longer distance communication of BT or Wi-Fi networks Pair and unpair Bluetooth headsets with just a tap with NFC NFC pairing process steps To pair and send music to a BT headset is as simple as: Select and play a music track in our phone. Tap the BT headset with the phone. When doing so, the BT pairing credentials are exchanged securely via NFC without any manual settings. The phone automatically initiates a BT connection request. After a second, audio is streamed via BT to the headset without entering any manual configuration. Furthermore, this is not only restricted to phones and headsets, but in general between any two NFC-enabled devices. Therefore, it is also possible to pair and send music to two Bluetooth headsets at the same time, creating what is known as “a silent disco”. Again, the process is simple: First, tap the two headsets with NFC capabilities. When doing so, the headsets automatically exchange the pairing credentials. The headsets establish a BT connection. And audio is streamed between them without requiring any manual setting. Similarly, instead of creating a silent disco, wireless speakers can be paired together via NFC to create a multi-audio system.  As such, NFC offers a real one-touch solution. It works with any NFC phone and no dedicated app needs to be installed. NFC unpairing process steps To stop sending music and un-pair the headset is easy as well. A second tap is the only action required to disconnect the headsets. After the tap, the second headset automatically de-activates the audio streaming and switches off. Best of all, we have instant identification of the device to be disconnected. Therefore, zero chances to unpair the wrong device as might happen through the phone settings, where we can unintentionally pick the wrong one. Multi-audio wireless speaker demo with NFC pairing capabilities During the rest of this post, we will tear-down an NFC multi-audio wireless speaker prototype developed by NXP based on PN7120 NFC controller solution. Hardware architecture This demo consists of two speakers with the same components, and therefore, the same functionality. If we dismount one of the speakers, the components we can find in the device PCB are: A system on chip solution, with an application processor, embedded flash memory and BT wireless connectivity. A system crystal clock, the BT antenna and two audio speakers A power supply unit, which includes three 1.5V batteries providing a stable 1.8V output. A NFC reader module, based on PN7120 chip, with an integrated antenna and a compact form factor. Application circuit for Bluetooth power on by NFC triggering If we have a closer look to the power unit interface, we see that: The VBAT pin is directly connected to the batteries. (PN7120 it supports a wide range of power supply voltages, from 5.5V down to 2.75V) The pad supply (PVDD), for the host interface operation, is connected to the 1.8V from the PMU. A wake-up trigger is built so that the BT controller is powered when an RF-field is detected. Regarding the host interface between the NFC controller and the main system MCU: The PN7120 module is connected to the BT controller via I2C slave interface. It supports standard, fast and high speed I2C modes (100 kHz SCL, 400 kHz SCL, 3.4 MHz SCL) The corresponding pull-up resistors are connected on the data and clock lines (SDA and SCL). The IRQ pin is used for ensuring the data flow control between PN7150 and the BT controller. The VEN (RESET) pin, used for setting the device in hard power down mode.  And, in respect to the antenna interface: The PN7120 VGA package Some discrete components for the antenna matching And the antenna coil surrounding the PCB edge. Software architecture and NCI interface In this section, we detail the solution software stack and how the NFC application logic works within the overall system. Using the block diagram, we have added the software blocks in orange.First, the PN7120 module includes: The NCI firmware & transport mapping layer for I2C communication (nothing to take care of from the developer side, since this firmware already comes embedded in the chip). Similarly, the host controller side requires: The NCI driver & transport mapping layer to communicate with PN7120 On top of these layers, the application logic for the BT pairing is implemented. Finally, the BT stack for the audio streaming, , but this software piece is not detailed here as it is out of the scope of the NFC implementation. NFC controller interface (NCI) specification details NCI describes the internal interface between an NFC Controller and the main host platform (in this case, between PN7120 and the BT chip). NCI is defined by the NFC Forum organization. As such, it provides manufacturers with a standard interface they can use for whatever kind of NFC-enabled device they build (making integration easier, saving time and effort). The next figure represents the NCI architecture: At the bottom, we find the transport mapping blocks, which map the NCI protocol to an underlying physical connection (I2C, SPI, UART, etc) The NCI core defines the messages, commands and data format for the different communications On top, the NCI modules implement specific functionalities, like the RF discovery which configures the NFC controller to communicate with other NFC tags or devices. From the overall NCI architecture, this implementation makes use of: The transport mapping is the I2C block The RF discovery is configured so that the speaker iterates between the reader, card and P2P modes NFC controller interface: RF Discovery PN7120 firmware can combine the three NFC modes of operation using the RF Discovery as defined in NCI spec. The RF discovery is a cyclic activity which activates various modes of operation. This consists of a loop which alternates two phases: The polling and the listen phases. In the polling phase, the PN7150 acts as Reader or NFC Initiator for the P2P mode, searching for passive tags or an NFC target device. If no card or target was detected, it enters a listening phase, to potentially be activated as card or P2P target If no device to interact is detected in the polling or listening phase, it switches back to polling phase after a timeout. All RF technologies supported by PN7120 can be independently enabled within this discovery loop. However, the PN7120 is in poll phase generates RF field and consumes current. Therefore, the more technologies to be polled, the larger the average current consumption. Multi-audio speaker prototype: RF dscovery configuration To enable the speaker-to-speaker pairing functionality, each of the speakers needs: To have the capability to discover a remote speaker and initiate a pairing operation. Or the other way around, be discovered by a remote speaker to complete a pairing operation. To accomplish this, the speakers need to sequentially move from polling and listening phases. As such, the discovery loop configured in the application iterates between reader, P2P and card modes.During the polling phase, the speaker generates an RF field, and uses an NFC-A polling sequence looking for: A remote card or device in card emulation. If found, the NDEF data with the pairing info will be retrieved and processed. Next, it looks for a remote P2P device. If found, it pushes an NDEF message with the pairing info to this remote peer. On the other hand, during the listening phase, the speaker turns off its RF field and waits to be discovered by a remote device: If it is discovered while operating as P2P target, it will pull an NDEF message coming from the remote speaker. If it is discovered while operating in card mode, its NDEF message will be read by the remote speaker. The precise communication that takes place between the two speakers will differ every time. It will depend on the polling loop status of both speakers at the instant they are tapped. Application logic Until now, we have described how both speakers are discovered, and therefore, how they can start a communication to exchange pairing data via NFC. The next step is to  describe which data and which data format is used to exchange the pairing details. NFC Forum specifications The NFC Forum organization defined a set of specs explaining how to exchange pairing data over NFC in an interoperable way with just a tap, independent of the manufacturer and without installing any dedicated application for it. These are: Connection handover: This spec defines how two NFC devices can negotiate and activate an alternative communication carrier.  NDEF: The NDEF spec defines a message format to exchange data between NFC devices, including pairing data. Tag 1 Type to Tag 5 Type specs: These specs define how NFC devices can interact with five different types of tag technology. As a result, any NDEF message store in any of these five types of tags will be processed by any NFC-compliant device. NFC pairing: Static handover As mentioned earlier, how pairing data is transferred between the two speakers will depend on the discovery loop status. The static handover takes place when: One speaker is in reader mode / polling mode. (left hand side) The other speaker is in card mode / listening mode, showing a Type 4 Tag with an NDEF message on it (right hand side). The process is as follows: The speaker in reader mode activates RF field and generates a NFC-A polling sequence. The remote speaker in card mode responds to the polling command. The reader retrieves the NDEF data from the remote speaker, using the commands as defined in Type 4 tag NFC forum spec. The reader processes the carrier data from the NDEF message and establishes a BT connection according to BT protocol. The speaker in card emulation mode deploys a Handover Select NDEF record, advertising its BT carrier. In The NDEF message, we store: The BT device address (MAC address) Bluetooth local name (Friendly name for the user) Class of the device (e.g. headset, mobile, etc) This is the carrier data that will be used by the application to trigger the BT connection. After this proces, both devices start streaming music over BT. NFC pairing: Negotiated handover The other possibility is that when both speakers are tapped, they find themselves during the P2P operation. In such a situation, the pairing process will be conducted according to the Negotiated handover mechanism. One of them will take the role of initiator, the other the target role: The initiator will poll for target devices The target will respond to the initiator command The initiator will send a handover request message, with the carrier details The target will respond with a handover select message, indicating the selected carrier option. On the received data, the initiator will establish a connection according to BT protocol. After that, both devices start streaming audio over BT. In this case, both speakers exchange data with their alternative carrier capabilities, could be more than one. The initiator communicates to the target device its carrier capabilities with a Handover request record followed by an NDEF record per each available carrier (in this case, just one BT carrier). After that, the target replies to the initiator with the selected carrier to be used for the out of band data transfer. As before, the BT configuration in the NDEF message includes fields such as: BT address, device class, BT local name, and optional data if secure pairing according to BT spec is required.The key here is that, this negotiation protocol and these message formats are specified and defined in the NFC Forum specs, so they offer an interoperable solution for any compliant-platform Support package  This section details resources and information provided by NXP you can use to replicate your own multi-audio speaker solution with NFC pairing capabilities. PN71xx family of NFC controllers PN71xx family are solutions integrating an RF frontend together with an embedded microcontroller with dedicated FW and NCI interface. They fully comply with the NFC Forum, include Linux®, Android™, and WinIoT drivers and sample code for bare metal and RTOS integration. Additionally, they support direct supply from a battery, different power states and an ultra-low power polling loop. Their features make it ideal for NFC integration into any application, especially those with OS system. Hardware support From a hardware point of view, several demokits are available to evaluate PN71xx family. They interface into popular platforms, such as: Raspberry Pi BeagleBone Black Any board featuring an Arduino compatible header like LPCXpresso or Kinetis Freedom among others. In case you have to evaluate PN71xx into any other platform, these kits can be reused, The PN71xx board provides all required signal pins easily accessible so that you can design and build your own interface board for your target platform. Software support From a software support point of view,  device manufacturers can easily integrate PN71xx family in Linux, Android and Win IoT systems through the available SW drivers. But also, NXP supplies a set of code examples running on LPC and Kinetis MCUs for Bare metal RTOS integration. Precisely, the demo presented in this post, leverages on the NullOS/RTOS SW examples. The software example for PN71xx integration into RTOS / Bare metal system is made of 3 components: The NXP-NCI module offers an API for configuring, starting and processing the NFC device discovery The NDEF library offers an API for processing NDEF data over reader, card and p2p modes: The transport mapping layer providing HW abstraction for the host – NFC controller connection On top of it, developers can implement their own application. Available resources PN7120 product website: www.nxp.com/products/:PN7120 PN7120 demokits: www.nxp.com/products/:OM5577 PN7120 product website: http://www.nxp.com/products/:PN7150 PN7120 demokits: www.nxp.com/products/:OM5578 Reference source code and related documentation: https://www.nxp.com/doc/SW4325 and http://www.nxp.com/docs/en/application-note/AN11990.pdf  Video recorded session

    Description: Teensy 3.1 and Teensy-LC are a complete USB-based development tools featuring respectively the Kinetis 32-bit Cortex-M4 K20 and Cortex-M0+ KL26 devices running @ 72 and 48 MHz. Teensy 3.1 is equipped with 256KB flash and 64KB RAM. Teensy-LC board is equipped with 62KB flash and 8KB RAM.   Value Propositions * Very small footprint development tools * Very Low Cost dev tool * They are able to implement many different projects * Open source SDKs   Teensy board with very high extended-Arduino compatible performance levels and libraries taking advantage of Kinetis features like low power modes and internal DMA. Libraries for LED (WS2811) and 16bit 44.1kHz audio quality is where Makers go when they need quality, performance and small size. FEATURES Hardware Specifications Specification Teensy LC Teensy 3.0 Teensy 3.1 & 3.2 Units Processor MKL26Z64VFT4 32 bit ARM Cortex-M0+ 48 MHz MK20DX128 32 bit ARM Cortex-M4 48 MHz MK20DX256 32 bit ARM Cortex-M4 72 MHz Flash Memory 62 128 256 kbytes RAM Memory 8 16 64 kbytes EEPROM 1/8 (emu) 2 2 kbytes I/O 46, 5 Volt 34, 3.3 Volt 34, 3.3V, 5V tol Analog In 8 14 21 PWM 9 10 12 UART,I2C,SPI 1,1,1 3,1,1 3,2,1 Price $24.00 $19.00 $19.80 USD   Software Enablement Teensy 3.2 & 3.1: New Features https://www.pjrc.com/store/teensylc.html     RECOMMENDED PRODUCTS Product Description Kinetis K Microcontroller Kinetis L Microcontroller RESOURCES Title Type PJRC (Teensy Official Website) Web Page

NFC Tandem offers best of both worlds: An NFC reader and a passive connected tag sharing one antenna. A user can interact with the device when it is powered off (through the NTAG I²C plus); when the device is powered, it can interact with cards, P2P devices or other connected tags.                                                             NFC Tandem Uses Cases and Applications: One-touch pairing WiFi with phone, or card Bluetooth with phone, headset, speaker IoT network node commissioning User identification with badge or phone Authentication and configuration of consumable and accessory Zero-power parametrization Zero-power firmware update Zero-power diagnosis and maintenance NFC Tandem Demo: NFC Tandem concept is demonstrated using NFC Tandem reference board: The demo can run on either: UDOO Neo Download UDOO Neo demo image or Raspberry Pi Download Raspberry Pi demo image Video of the demo: <script src="https://players.brightcove.net/6153537070001/default_default/index.min.js"></script>(view in My Videos) NFC Tandem References: PN7150 High performance NFC controller, supporting all NFC Forum modes, with integrated firmware and NCI interface NTAG I²C plus NFC Forum Type 2 Tag with I²C interface NFC Tandem Documents: User Manual and reference schematics are attached to this document

Demo Hexiwear platform combines the style and usability found in high-end consumer devices, with the functionality and expandability of sophisticated engineering development platforms, making Hexiwear the ideal form factor for the wearable market, as well as other edge-node IoT solutions. Completely open-source and developed by MikroElektronika in partnership with NXP, the Hexiwear hardware includes the low power, high performance Kinetis K6x Microcontroller based on ARM Cortex-M4 core, the Kinetis KW40Z multimode radio SoC, supporting BLE in Hexiwear. The Hardware features included 6 on-board sensors such as Optical Heart Rate Monitor, Accelerometer and Magnetometer, Gyroscope, Temperature, Humidity, light and Pressure sensor's. Hexiwear also includes Color OLED Display, Rechargeable battery and External flash memory. $49 NXP Hexiwear, IoT and Wearables development platform – ARMdevices.net   Hexiwear is supported with its own application for Android and iOS, so customers can connect the device to the cloud straight out of the box, without any additional software development. Hexiwear uses FreeRTOS, the Kinetis software development kit (SDK) and the Kinetis Design Studio IDE. The Hexiwear platform is also expandable with the option to add nearly 200 different, additional sensors through click boards™      Features •       Eye-catching small form factor (smaller than 2” by 2”) board with open source hardware with 7 NXP components and 8 sensors on-board. •       Designed for wearable applications with the onboard rechargeable battery, OLED screen and onboard sensors such as optical heart rate, accelerometer, magnetometer and gyroscope. •       Designed for IoT end node applications with the onboard sensor’s such as temperature, pressure, humidity and ambient light. •       Complete software solution with open source embedded software, cell phone apps and cloud connectivity. •       Flexibility to let you add the sensors of your choice from 180+ plug and play add on boards. NXP Products Recommended ARM Cortex-M4|Kinetis K64 120 MHz 32-bit MCUs|NXP  ARM Cortex-M0+|Kinetis KW40Z 2.4 GHz 32-bit MCUs|NXP  FXOS8700CQ Accelerometer and Magnetometer FXAS21002 Gyroscope MPL3115A2R1 Altimeter MC34671 Battery charger Other Links Kickstarter Hexiwear Design Files Hexiwear|NXP     News Module Targets Rapid IoT Development | Embedded content from Electronic Design  NXP Accelerates Smart Wearable Product Development | Business Wire  Mouser Stocking the Hexiwear Open Source IoT Platform from MikroElektronika and NXP | Electronics360  Contest Hexiwear: The Do-Anything Device! - Hackster.io  Hexiwear: Quickly Build Quality IoT Devices - HWTrek  http://www.rs-online.com/designspark/electronics/eng/blog/test-drive-hexiwear-the-wearable-iot-development-kit  Blogs https://www.linkedin.com/pulse/hexiwear-complete-iot-wearable-development-solution-powered-kedia?trk=prof-post  Introduction to Hexiwear – a wearable development kit for the IoT era – HWTrek Blog  Win an Oculus Rift! Hexiwear Design Contest | mbed  https://mcuoneclipse.com/2016/07/12/hexiwear-teardown-of-the-hackable-do-anything-device/  Freedom development platform: Hackster.io conte... | element14 Community  JavaScript mobile apps for your NXP Hexiwear BLE device | Evothings 

Description    NXP’s Personal Network Attached Storage (NAS) solution enables portable personal storage to be shared through an internal protocol (IP) or Wireless network allowing users to share photos, data, stream music or videos, backup and recovery of data over the local area network in a completely secure environment. In addition, the solution can support gateway features such as packet forwarding, cloud connectivity via Ethernet, Wi-Fi or LTE. This NAS solution offers significant advantages to consumer and SMB environments, including: Hardware-accelerated Raid for data parity and recovery, a reduced bill of materials (BOM) and ease-of-use associated with an IP network that most business and consumers already find familiar. Based on the QorIQ Layerscape LS1012A processor and the Network Attached Storage Application Solution Kit (ASK), the personal/consumer NAS solution offered by NXP allows developers to easily build storage applications leveraging the highly-optimized and feature rich ASK software stack along with the small form factor, low-power consumption and packet processing capabilities enabled by LS1012A processor. NXP provides an integrated platform solution (SW and HW) helping the customer to reduce his time to market, increase security and increase performance by leveraging the packet accelerators within the QorIQ® Layerscape LS1012A processor while delivering high NAS performance and IP forwarding applications with reduced load on the Arm® core. In addition, NXP LS1012ARDB supports a full set of popular interfaces such as SATA, USB 3.0, PCIe and 2.5/1Gigabit Ethernet for LAN and WAN, allowing customers and operators to securely connect storage devices with the cloud. Features Integrated Platform Solution Commercial Market Proven Software Solution Hardware Offloading Popular Connectivity Flexible and Optimized Software Architecture Use Cases Personal Storage Consumer Network Attached Storage (NAS) Consumer Direct Attached Storage (DAS) Battery Powered Portable NAS Wireless Personal Storage Media Gateway Chip on Drive Wi-Fi SSD and Small/Portable Drive Ethernet Drives Block Diagram Products Category Name MPU Product URL Layerscape LS1012A Communication Processor for the IoT | NXP  Product Description The QorIQ® LS1012A processor, optimized for battery-backed or USB-powered, space-constrained networking and IoT applications Category Name DC Regulator Product URL MC34VR500 | Multi-Output DC/DC Regulator | NXP  Product Description The NXP® MC34VR500 power management solution for network processor systems is a high-efficiency, quad buck regulator with up to 4.5 A output and five user-programmable LDOs. Tools Product URL QorIQ® LS1012A Development Board QorIQ® LS1012A Development Board | NXP  Layerscape FRWY-LS1012A board FRWY-LS1012A Development Platform | NXP 

This post entry provides a detailed description of the OM29263ADK kit, a new antenna tuning development kit specially designed to facilitate the NFC antenna prototyping process. This document has been structured as follows: OM29263ADK kit contents This kit consists of a single PCB board that includes:  A pre-matched antenna of 2 turns and a size of 77 by 113 mm.  A second pre-matched antenna of 4 turns and a smaller size of 20 by 20 mm.  And, 8 extra boards to prepare the matching for custom antennas. As a result, this kit is a perfect resource for different purposes such as evaluating the RF performance of different antenna sizes and, for prototyping your custom antenna quickly. In addition, this NFC antenna development kit is compatible with our existing product support package. You can directly connect it to CLRC663 demoboards, as well as to PN5180 and PN7462 demoboards after a minor tuning. Using OM29263ADK kit with CLEV6630A or CLEV6630B The process is really straightforward… First, take one CLRC663 demoboard and separate the main PCB from the antenna & matching circuit. The board includes cut lines, so you can divide both sections easily by only using your hands. Second, break the kit OM29263ADK PCB so that you separate the pre-matched antenna from the other PCB parts. Then, it is just a matter of connecting the two parts together. The kit antenna includes pin male connectors while the CLRC663 board includes the corresponding female connectors. Therefore, hook up the antenna with the main board, solder the connectors and that’s all. We can observe that when we connect the kit large antenna to the reader PCB, the  impedance measured with our network analyzer shows that the tuning is adjusted to approximately, 19 Ohms. This is the result obtained without any hardware modification The same process applies for the smaller antenna: Similarly, we can observe that when we connect the kit small antenna to the reader PCB, the  impedance measured with our network analyzer shows that the tuning is adjusted to approximately, 36 Ohms. This is the result obtained without any hardware modification: Using OM29263ADK kit with PNEV5180B or PNEV7462C In case you are interested to connect the OM29263ADK kit antennas to the PNEV5180B or PNEV7462C boards, the preparation process is the following: First, separate the antenna and the matching section from the PN5180 or PN7462 demoboards, as before, using the cut lines. Then, take one kit sample, and separate the pre-matched antennas for the other PCB parts. And finally, adjust the EMC filter. The EMC filter adaptation is required because the kit antenna is prepared for asymmetric tuning while the PN5180 and PN7462 original antenna use a symmetrical tuning. The main difference between both types of tuning is the cut off frequency. The symmetric tuning uses a cutoff frequency around 15MHz, while the asymmetric can go up to 22 MHz. In practice, for this adaptation, we only need to change the value of the capacitor C0 in the main board. For instance, the existing 220 pF capacitor can be replaced for another one of 68 pF. Using OM29263ADK kit to connect your own antenna coil This section describes how to use the kit PCB boards for our custom antenna tuning. For this task, the list of material that we need is: A reader PCB board, in the example, we picked CLRC663 One of the PCBs for antenna matching included in the kit And, the any antenna to be matched  In our case, we have selected one sample antenna available in our lab. The following explanation will be guided using this antenna as a reference, but any antenna can be tune using the same process. The usual list of steps to tune a custom antenna are: First, we need to define target impedance and Q factor, as design parameters for our reader Then, we will characterize the antenna coil and find its parameters After that, we will design the EMC filter With this, we will calculate the matching components using an Excel sheet Afterwards, we will assemble the calculated components and measure the first results. We will take field measurements, which probably will show that it is not perfect, so we may need to adapt the matching values With these fine-tuned vales, we will re-assemble again And finally, we will design the receiver circuit. Define target impedance and Q-factor First, we start defining the target impedance and Q-factor. The target impedance is a design parameter, which needs to be chosen according to our needs whether we want to go for maximum field strength or minimum battery consumption or a trade-off in between. Typically, reasonable values are between 20 Ohms and 80. Another important design parameter is the Q factor. The Q factor is a dimensionless parameter indicating the performance of a resonant circuit. The higher the Q factor, the higher the read range. On the other hand, increasing the Q factor also reduces the bandwidth of the circuit. As a result, in practical implementation, Q-factor values below 30 are demonstrated to fit well for the ISO14443 wave form timing requirements and corresponding spectrum.  For our tuning exercise, the design parameters chosen are an impedance of 20 ohms and a Q factor of 25 Measure antenna coil Next step is to characterize the antenna coil. Any antenna coil has an input impedance. This input impedance is complex and consists of an inductance, capacitance as well as some losses represented by a resistance (R). The actual values depend, among others, on antenna material, thickness of conductor, distance between the windings, number of turns, etc.  The coil characterization needs to be done with a network analyzer. It could be a high end, such as Agilent or Rohde & Schwarz, which is powerful, accurate, easy to use, but expensive. Or we can also go for low end solutions, such as the miniVNA PRO, which is cheap compared with the previous ones, and accurate enough for our needs. In our case, the characterization of our lab antenna shows:  An inductance around 1.3 uH And a resistance of 2.5 Ohms Design EMC filter The next step is to design the EMC filter. As we are using CLRC663, we will go for an asymmetric antenna tuning. Good inductor values are between 330nH and 560nH. and 21MHz cutoff frequency is ideal for asymmetric tuning. Fixing this two parameters, we can easily calculate the required capacitor component for our EMC filter with the formula below. In our example, we need to use a capacitor of C= 122 pF. With this, we just pick up the closer commercial value from our components box Calculate matching circuit components We have characterized the antenna coil and completed the EMC filter. Now, we can calculate the matching network components. The matching components need to be calculated so that the maximum power from the reader is transmitted to the antenna. This happens when the equivalent impedance seen from the reader IC only has the real part, without the complex part. There are some complex calculation involved in the process. In order to avoid these cumbersome formulas, NXP provides a useful Antenna Tuning excel sheet that calculate the appropriate components for you. Below, you can see a screenshot of the Excel sheet in the slide. This sheet calculates C1 and C2 matching values according to the inputs expected from the user. These are The measured antenna coil parameters The EMC filter parameters. The target impedance and Q-factor of our design With these values, The Excel sheet calculates and outputs the value of the matching components: C0, C1, C2 and Rs. In our exercise, the output values calculated for the matching network by the Excel sheet are C1 around 43 pF and C2 around 144 pF Assemble and measure Typically, the calculated values do not match with commercial components. The easiest way is to add components in parallel to get as close as possible to the calculated values. If we take a closer look to the kit antenna matching PCB board, the pad location is the following: We have two slots for C0 – so we can have two capacitors in parallel to achieve a better accuracy on the capacitance value we need to achieve We also have two slots for C1, for the same purpose We have two more slots for C2 soldering We also have two slots for the dampening resistor, in case we need to reduce the Q-factor of our antenna. And finally, one slot for the receiver resistor circuit. After the first component assembly, it is worth performing a field measurement to find out how accurate our matching is in reality. Typically, the measured impedance is different than the impedance calculated in the simulation. Therefore, the calculated matching components were not 100% accurate. But we knew that in advance. We were aware that we were just getting a rough approximation to the antenna parameters. As a result, a good matching is achieved after a number of iterations according to the field measurements that we obtain. As a general rule,  C1 changes the magnitude of the matching impedance and C2 changes its imaginary part. In our exercise, after soldering the first components, the equivalent impedance is around 19 Ohms but it also has a significant imaginary part. As a result, it can be fine-tuned towards better performance. We modified C1 and C2 a couple of times until we found out the final values that work better. obtaining a impedance with only real part at 22 Ohms (C1= 36pF and C2=154 pF). Adjust receiver circuit The last step of tuning our antenna is to design the receiver circuit. The Rx circuit that consists of a voltage divider and a coupling capacitor connected from the output of the EMC filter to the RX pins of the NFC reader. The objective is to set the voltage level at the reception pins to achieve the compromise between a good sensitivity. For CLRC663 plus, the serial resistor is in the range of 7 and 15 kΩ. You can start with a 11 KOhm value, then, the resistor can be adjusted depending on the voltage measured in the Rx pins. If the voltage at Rx pin is higher than 1.7 V, it is recommended to increase the resistor value and if the voltage at Rx pin is below than 1.2 V, it is recommended to decrease the resistor value. Using OM29263ADK kit to evaluate the performance of different antenna shapes The section covers how you can use the antennas included in the kit for performance comparison. Please note that this lab exercise is shown only for illustrative purposes on how the kit can be used to evaluate the performance of different antenna shapes. As an example, we defined a sample scenario where we want to characterize how the field strength decreases with distance when using antennas of different size. For that, we used the following setup: A class 1 ISO14443 Reference PICC A scope A CLRC663 board connected to the small antenna A CLRC663 board connected to the large antenna A ruler to measure the distance The measurements were taken in this way: We tuned the large and small antennas to 20 Ohms We connected the board to the laptop, and we executed the NFC Cockpit tool to control the RF field. We measured with the scope the voltage level obtained by the ISO14443 Class 1 Reference PICC while we increased the distance. Background information Before actually showing you the results, it is worth it to review a couple of antenna design principles to properly understand the results. Coupling coefficient Before actually showing you the results, it is worth it to review a couple of antenna design principles to properly understand the results. The coupling coefficient is a parameter that indicates how much of the magnetic field generated by the reader is picked up by the card. The coupling coefficient takes a value between 0 and 1 If the coupling equals 1, it means we have a perfect coupling, all magnetic field lines are picked by the card If the coupling equals 0, it means we have no coupling at all, no magnetic field lines are picked by the card The key message is that the coupling coefficient is just a geometric quantity. It depends on: The reader and card antenna dimensions (both antenna radius) Their relative position (whether in parallel or perpendicular, they will pick a different amount of magnetic field lines) The distance between them And the magnetic properties of the medium Mutual inductance Very related to the coupling coefficient, we have the mutual inductance. The mutual inductance allows us to determine the voltage induced in the card antenna, that depends on: Coupling coefficient  Better coupling, higher the voltage Driver current  The higher the current we drive in the reader antenna, the stronger the magnetic field Antenna inductance Precisely, in this setup, we are going to measure the voltage perceived by the reference PICC when using two different antennas. Antenna tuning components used for the large antenna First, we prepared a tuning of 20 Ohms in the large antenna. This task was done using the process described above. As an example, we selected a low Q-factor of 10, which helped us to accommodate high bit rates for ISO14443. In the figure below, you can see the components we assembled to tune the large antenna near to 20 Ohms. Antenna tuning components used for the small antenna Second, we prepared a tuning of 20 Ohms in the small antenna so that the results are comparable. The same Q-factor and EMC filter values were used, but obviously, as the antenna size is different, we used different C1, C2 and Rs values to achieve the same equivalent impedance OM29263ADK large antenna vs small antenna The following graph shows the results we obtained: The blue line, represents the DC output voltage obtained from the Class 1 Reference PICC as we increase the distance from the reader using the large antenna… The green line, represents the DC output voltage obtained from the Class 1 Reference PICC but using the reader with the small antenna connected. As a result, what we see is that at close distance, both antennas are able to deliver the same field strength. However, as distance increases, the RF field of the small antenna starts to attenuate quickly from 2 cm distance of the reader while the RF field of the large antenna is more or less stable until 5 cm, after that, it starts to attenuate quickly as well. Potentially, what we can conclude is that for this setup, we might be able to get more reading distance with the large antenna. ISO/IEC14443 vs ISO/IEC15693 reader - Quality factor We need to bear in mind that our antenna is not only for energy transfer, but also it should match with the waveform requirements. Therefore, from the practical point of view, the Q factor of the system is limited by the bandwidth as if we increase the Q, we increase the field strength but we decrease the bandwidth. Our reader can be optimized whether we are designing a reader for ISO14443 or ISO15693 as the signals modulation and timing requirements of the rise and fall times for both RF protocols are different. Actually, in practice, ISO15693 allows us a higher Q factor because there is a lower bandwidth requirement as the waveform timings are more relaxed and, the power transfer requirement is lower than ISO14443. For such optimization, you can refer again to NXP antenna tuning excel sheet. If you recall, one of the input fields of the excel sheet is the Q-factor. Therefore, you can introduce here a value below 30 for ISO14443 readers or below 100 for ISO15693 readers. The excel will output reasonable matching values for the first components adjustment. After that, you can do a fine tuning according to the process I explained before. Further information You can find more information about NFC in: Our NFC everywhere portal: https://www.nxp.com/nfc You can ask your question in our technical community: https://community.nxp.com/community/identification-security/nfc You can look for design partners: https://nxp.surl.ms/NFC_AEC And you can check our recorded training: http://www.nxp.com/support/online-academy/nfc-webinars:NFC-WEBINARS Video recorded session On 21 June 2018, a live session explaining this topic. You can watch the recording here:

Wind River's Ka Kay Achacoso demonstrates VxWorks 7 with graphics on the i.MX6 series applications processor. Features Demonstration of Graphics using VXWorks 7 The drivers are taking advantage of the i.MX processor's GPU to render hardware accelerated 3D graphics Using the accelerometer to show the orientation of the board The display shows a 3D view of how the board is being positioned taking into consideration perspectives and lighting shadows Featured NXP Products ARM® Cortex®-A9 Cores: i.MX 6 Series Multicore Processors Links NXP Connect - Wind River

NXP Content: PN7462, NTAG I²C plus NXP Recommends: PN7462, NTAG I²C plus The NFC Cube is a universal demo with which all 3 basic NFC operation modes can be shown: Interaction between a device and a card or tag Interaction between 2 electronic devices (NFC as cable replacement) Interaction between a device and an NFC phone Value Propositions The NFC Cube is a universal NFC demo Support Under https://nxp.box.com/NFCcube you find more information and a video showing the NFC Cube in action.