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:

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 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

Android Open Accessory support allows external USB hardware (an Android USB accessory) to interact with an Android-powered device in a special accessory mode. When an Android-powered powered device is in accessory mode, the connected accessory acts as the USB host (powers the bus and enumerates devices) and the Android-powered device acts in the USB accessory role. This ADK library is based on NXP Kinetis Microcontroller KL26, It implements some functions to communicate with android phone.  

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

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 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

Demo Running NXP’s i.MX6SX application processor, Earthquake warning system proof of concept is able to warn citizen about Earthquake. Data are gathered from local sensor, remote sensors based on K64F NXP’s controllers and seismology servers from Internet. Features: Give citizens warning against Earthquakes Runs on the NXP i.MX6SX application processor with Linux® OS. Presents i.MX6SX asymmetrical architecture features, where data are measured locally by Cortex-M4 with FreeRTOS and displayed and presented by Cortex-A9 core with Linux® OS. Cortex-M4 can measure in real-time and monitor Linux part. Cortex-A9 can sleep to save power and be waked up by the quake detected by Cortex-M4. Communication between cores via RPMsg. Remote sensor’s accelerometer data are measured running K64F microcontrollers Seismology server’s data are displayed and analysed ___________________________________________________________________________________________________________________________ Featured NXP Products: Product Link Freedom Development Platform for Kinetis® K64, K63, and K24 MCUs FRDM-K64F Platform|Freedom Development Board|Kinetis MCUs | NXP  i.MX 6SoloX Processors - Heterogeneous Processing with Arm® Cortex®-A9 and Cortex-M4 cores i.MX 6SoloX Applications Processors | Arm® Cortex®-A9, Cortex-M4 | NXP  __________________________________________________________________________________________________________________________

What’s it like to sit in a state-of-the art eCockpit? Put on a virtual reality headset and find out! Here, the virtual world meets the real world as live video content from 4 displays -- a HUD, cluster, infotainment and rear seat entertainment systems – is processed and streamed realtime from a single i.MX 8 applications processor.  i.MX 8 series will transform interactions in ways you’ve never imagined   NXP product recommended i.MX 8 ARMCortex-A53 Processor|NXP 

Demo Features: Based on latest SOM Colibri i.MX7D 512 MB from Toradex Heterogeneous architecture: Qt on top of Linux on ARM® Cortex®-A7 core Realtime control loop on FreeRTOS on ARM® Cortex®–M4  Balancing control loop and mechanics by Antmicro  Face emotions using Qt 5.6 beta done by The Qt Company ______________________________________________________________________________________________________________________ NXP Featured Products: NXP i.MX 7 - Computer | System on Modules ______________________________________________________________________________________________________________________ C78

The purpose of this project is the control of a RGB LED panel using the FlexIO peripheral included in the Kinetis K82 microcontroller. The FlexIO peripheral offers a great advantage, unloading the CPU in the process of refreshing the LED color and brightness information, comparing with other control methods using GPIO bit-banging or PWM + DMA. I will use different method. The panel will use LED stripes with the WS2812B controller. We will also have a simulation platform for developing the applications. Hardware: 30 x16 LED WS2812B Panel Multiplexer board FRDM-K82 Uctronics QVGA display Software: IAR Workbench 7.50.1 SDK 1.3 for the Kinetis K82 FreeRTOS eGUI graphic library You can watch the video with the LED panel working: Video Link : 4707 Part 1: Building the LED Panel Part 2: LED control method using the FlexIO Part 3: Software for LED Panel emulation Part 4: Software for panel control

Demo Owner Mike Stanley     Features Measuring the output from sensors, then computing the orientation of the device with the KL25 Kinetis Microcontrollers using advanced filtering techniques such as: Kalman filtering, Indirect Kalman filtering Built a representation of the current orientation of the device, linear acceleration Fusion software incorporated in standard OS systems Windows, iOS, Android Software library, visualization tools and full development suite are available for customers Featured NXP Products FXOS8700CQ (6- Axis Accelerometer + Magnetometer) FXAS21002 (3-Axis Gyroscope) Development Hardware Used FRDM- KL25Zhttps://community.nxp.com/external-link.jspa?url=http%3A%2F%2Fwww.nxp.com%2Fproducts%2Fsoftware-and-tools%2Fhardware-development-tools%2Ffreedom-development-boards%2Ffreedom-development-platform-for-kinetis-kl14-kl15-kl24-kl25-mcus%3AFRDM-KL25Z FRDM-FXS-MULTI Design Resources Sensor Fusion Library for Kinetis MCUs Sensor Fusion Toolbox for Android Sensor Fusion Toolbox for Windows Training Hands on Workshop: Sensor Fusion Library for Kinetis MCUs Links Sensor Fusion NXP Community: Sensors Best of Sensors Expo (2014 Sensor's Expo)  

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.

Demo Kinetis KW4x MCU is an ultra low power, highly integrated single-chip device that enables Bluetooth low energy (BLE) connectivity for portable, extremely low-power embedded systems.     Features iBeacon Location-based Messages The KW4x is an ultra low power, highly integrated single-chip device that enables Bluetooth low energy (BLE) or IEEE Std. 802.15.4/ZigBee RF connectivity for portable, extremely low-power embedded systems. Applications include portable health care devices, wearable sports and fitness devices, AV remote controls, computer keyboards and mice, gaming controllers, access control, security systems, smart energy and home area networks.  The KW4x SoC integrates a radio transceiver operating in the 2.36GHz to 2.48GHz range supporting a range of FSK/GFSK and O-QPSK modulations, an ARM Cortex-M0+ CPU, 160KB Flash and 20KB SRAM, BLE Link Layer hardware, 802.15.4 packet processor hardware and peripherals optimized to meet the requirements of the target applications.  The KW4x’s radio frequency transceiver is compliant with Bluetooth version 4.1 for Low Energy (aka Bluetooth Smart), and the IEEE 802.15.4-2011 standard using O-QPSK in the 2.4 GHz ISM band and the IEEE 802.15.4j MBAN frequency range spanning from 2.36 GHz to 2.40 GHz. In addition, the KW4x allows the Bluetooth Low Energy protocol to be used in the MBAN frequency range for proprietary applications. Enabled by Kinetis KW4x MCUs Discover location-based context A Bluetooth® Smart low-power application   Bluetooth Smart and 802.15.4 Dual Mode Communication BLE heart rate sensor on a KW40Z connecting, pairing and exchanging data with an iPod while the 802.15.4 end device (on the same KW40Z chip) associates and exchanges data with a coordinator. The OTA packets are displayed in sniffer applications on a Windows PC.  The KW4x is an ultra low power, highly integrated single-chip device that enables Bluetooth low energy (BLE) or IEEE Std. 802.15.4/ZigBee RF connectivity for portable, extremely low-power embedded systems. Applications include portable health care devices, wearable sports and fitness devices, AV remote controls, computer keyboards and mice, gaming controllers, access control, security systems, smart energy and home area networks.  The KW4x SoC integrates a radio transceiver operating in the 2.36GHz to 2.48GHz range supporting a range of FSK/GFSK and O-QPSK modulations, an ARM Cortex-M0+ CPU, 160KB Flash and 20KB SRAM, BLE Link Layer hardware, 802.15.4 packet processor hardware and peripherals optimized to meet the requirements of the target applications.  The KW4x’s radio frequency transceiver is compliant with Bluetooth version 4.1 for Low Energy (aka Bluetooth Smart), and the IEEE 802.15.4-2011 standard using O-QPSK in the 2.4 GHz ISM band and the IEEE 802.15.4j MBAN frequency range spanning from 2.36 GHz to 2.40 GHz. In addition, the KW4x allows the Bluetooth Low Energy protocol to be used in the MBAN frequency range for proprietary applications. Concurrent communication on BLE and 802.15.4 Suited for configuring 802.15.4 devices from your smart phone Automatic synchronization completely transparent to the application   BLE-enabled Smart Zumo Robot The Smart Zumo Robot is powered by the new Kinetis KW40X MCU and is enabled by Bluetooth Low Energy (BLE) technology. Low-power, Bluetooth Low Energy (BLE) application Running simple control implementation over BLE to interact and control with the robot Highly-integrated radio solution with scalable memory options   Featured NXP Products   Product Link Bluetooth Low Energy/IEEE® 802.15.4 Packet Sniffer USB Dongle for Kinetis® KW40Z/30Z/20Z MCUs Bluetooth Low Energy/IEEE® 802.15.4 Packet Sniffer USB Dongle for Kinetis® KW40Z/30Z/20Z MCUs | NXP      Development Hardware Used   Freedom Development Platform for Kit Bluetooth Low Energy/IEEE® 802.15.4 Pack

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

Smart Thermostat reference demo is based on Kinetis family MCU (K70F120M) and KW24D512 zigBee coordinator. The demo kit has an HVAC application which controls the heat/cool temperature, hvac mode etc of the remote temperature sensor via zigBee coordinator. The demo kit Connects to WAN via Ethernet or wifi. The wifi module used is a wifi module from Qualcomm.  The embedded DeviceCloud cloud agent provides firewall agnostic instant cloud connectivity. The device can be registered and authenticated with DCIO cloud platform and the remote temperature sensor can be monitored and controlled through DCIO Mobile Application.   The K70 application is built for MQX RTOS v4.0.2 and uses our PEG graphics library for the user interface displayed on an LCD. The K24 application is built on MQX-Lite RTOS, uses our BeeStack ZigBee stack. The demo will also connect with an off-the-shelf ZigBee light bulb and wirelessly controls it.   The reference design provides guidelines for building solutions using connected devices that can be managed, provisioned and monitored from Cloud and Mobile applications.   Features Kinetis Smart Thermostat Qualcomm-Atheros GT 202 Carrier board MQX Software Solutions RTOS 4.0.2 BeeStack ZigBee stack HVAC application deviceCloud.io's cloud agent deviceCloud.io's Mobile App deviceCloud.io's web based solution   NXP Products Product Link Kinetis® KW2x Tower System Modules TWR-KW2x|Tower System Board|Kinetis® MCUs | NXP  Kinetis K70 120 MHz Tower System Module TWR-K70F120M|Tower System Board|Kinetis MCUs | NXP  Links Connected HVAC Demo with deviceCloud.io Cloud Solution   System Diagram Hardware Diagram Software Diagram Connectivity Diagram  

Demo This demo showcases the Bluetooth Low Energy Mesh solution on Kinetis KW41Z devices, leveraging the Kinetis Bluetooth LE v4.2 stack. The audience will be able to interact with remote nodes of the mesh via a single laptop console. The remote nodes offer feedback via a RGB LED array.     Features: Bluetooth® LE Mesh software implementation over the Kinetis BLE stack v4.2 Mesh nodes made up of FRDM-KW41Z evaluation boards with Adafruit NeoPixel LED shields Interactive configuration and control of the mesh nodes with feedback on the LED arrays Sensor data sent via the Mesh to the cloud _______________________________________________________________________________________________________   Featured NXP Products: KW41ZlKinetis BLE & 802.15.4 Wireless MCU|NXP _______________________________________________________________________________________________________    

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

This post entry aims at explaining the debugging process oriented to EMVCo Contactless certification of a device integrating NXP's PN5180. The structure is the following: PN5180 Antenna design considerations Before going into the debugging process for the EMVCo Contactless Analog tests we will see some important considerations for an antenna design and impedance tuning oriented for an EMVCo compliant device. Antenna tuning recommendations The first recommendation is that with the Dynamic Power Control feature the PN5180 allows us to perform symmetrical antenna tuning instead of the typical asymmetrical tuning. This symmetrical tuning provides us with a better transfer function, being able to drive more power to the antenna. The following figure shows the Smith Chart with the S11 parameter plot of a device using a symmetrical antenna tuning:   The only disadvantage of the symmetrical tuning is that we need a current limiter to avoid destroying the chip because of exceeding the chip’s limits. In the case we are documenting today, the PN5180 DPC feature is used to limit the supply voltage and therefore the transmitter current depending on the load detected by the chip. Regarding the EMC filter, the inductor should fit with the following condition to guarantee a good relation between the AGC and the ITVDD: Another consideration is about the resistor used in the reception branch. This resistor controls the receiver sensibility and as a starting point is recommended to use a value to obtain an AGC in free air of: Reader Mode only design: AGC value in free air around 600dec Full NFC design: AGC value in free air around 300dec Finally, EMV contactless transactions are performed at 106kbps which would allow us to work with a high Q factor of the overall system. This means that the power gain can be higher, but at the same time it might also lead to some issues because of the lower bandwidth. In light of this, we have to bear in mind, that if the Q factor is too high it may lead to problems in the waveform tests. PN5180 DPC calibration The Dynamic Power Control is a feature that uses the AGC value to establish different power configurations depending on the load applied to the antenna. As I mentioned before, the main goal is to protect the chip from a transmitter current level that might destroy it. The first step before calibrating the DPC is to check the correlation between the AGC value and the transmitter current or ITVDD when different loads are applied to the antenna. Basically, we will play with the distance between the load and the device to get several points with different AGC values. Based on those measurements, we can plot a graph like the following: Normally we would use a reference PICC and a metal plane or phone to check that the behavior is linear and with no big difference between those loads. Once we have checked the correlation we can proceed with the calibration process, which can be done very easily with the NFC Cockpit software. Here the important thing is to control the ITVDD and keep it always below the chip’s limit. As you can see in the figure below, without the DPC, this symmetrical tuning would lead to a voltage above the limit for positions close to the reader antenna. However, with DPC we can control that voltage at any moment. Another consideration is that we have to make sure that the DPC is calibrated to have maximum power when the reference PICC is far from the reader to avoid a lack of power in the tests at those positions. EMV L1 Analog Tests Debugging process We are going to divide this debugging process into 3 main phases which are the power tests in the first instance, followed by the waveform tests and the reception tests. The reason why we set this order is to first debug the tests that may require HW modifications which have a strong impact on the other tests. This way, for example, if you have passed all power and waveform tests, debugging the reception tests may not have an impact on the results obtained previously. Power tests Tests setup In order to debug the power tests, we will need just an oscilloscope and an EMVCo reference PICC. We will need to connect the outputs J9 and J1 of the EMVCo reference PICC to the oscilloscope and set the jumper J8 of the reference PICC in non-linear load mode. The J9 of the EMVCo reference PICC is the DC_OUT output that we will use to measure the power received by the antenna. The J1 is the LETI_COIL_OUT output and we will use it to capture the command in the oscilloscope. The overall setup is depicted in the figure below. Performing tests We have to use the trigger to capture the REQA command sent from the DTE when the reference PICC is in the position we want to test. This capture can be seen in the two figures below. The yellow channel is the LETI_COIL_OUT of the EMVCo reference PICC and the blue channel represents the DC_OUT obtained from the J1 connector. As said previously, we will use the DC_OUT to measure the voltage in the period of the signal where there is no modulation, like this part highlighted with the red squared. We have zoomed into the period to get the average value using the oscilloscope measurement features. We will use this same procedure to evaluate the power tests in all positions. Depending on the position tested, the specifications define and certain range where the voltage measured should be fitted. In this sense, the maximum voltage level is common for all planes, but the minimum voltage allowed will decrease for positions further from the terminal.  In order to identify the critical positions for the power tests, we have to identify two different scenarios, the first one with the positions that might not reach the minimum voltage established, and the positions that might exceed the maximum value. For the first scenario the critical positions are the outer positions of the plane z = 4cm and the plane z=3cm as the external positions for plane z= 3cm have a bigger radius. The other scenario is that where you can be exceeding the maximum level. This situation can happen in the central positions of the lower planes, like plane z=1 or z=0. Debugging hints In order to overcome possible issues, we will give some tips that can be used for your design. Regarding a case of lack of power, first, we have to make sure that the DPC is correctly calibrated, meaning that you are operating in gear 0 for the external positions of planes 3 and 4 and that gear 0 is operating with full power. If we have verified those two things and we still have issues, we would need to change the tuning of the antenna and reduce the target impedance. This is graphically represented in the following Smith Chart: By reducing the impedance we increase the current that the PN5180 is driving to the antenna so the voltage would increase. Is important to always verify that we are working within the recommended operating range of the chip and that we are not exceeding the transmitter current limit. In a worst-case scenario, if we cannot achieve the voltage with these HW changes we would need to evaluate changes in the hardware design, like adding a ferrite sheet or changing the antenna dimensions or position. On the other hand, if the problem comes because we are exceeding the maximum voltage allowed by the specifications we can easily solve it by reducing the power configuration of the gear used in that specific position. Waveform tests Test setup For the waveform group of tests, we will use a setup consisting of the EMVCo reference PICC along with an oscilloscope and a PC software to evaluate the signal obtained from the oscilloscope. In our case, we will use the Wave Checker software from CETECOM. We need to connect the output J9 of the EMVCo reference PICC to the oscilloscope and set the jumper J8 of the EMVCo reference PICC in the fixed load position. The oscilloscope needs to be connected to the PC or laptop, so the software is able to get the waveform and analyze the parameters needed. Type A tests The waveform group of tests for Type A consists of the following test cases: TA121: t1 TA122: Monotonic Decrease TA123: Ringing TA124: t2 TA125: t3 and t4 TA127: Monotonic Increase TA128: Overshoot Some of these test cases are directly related to the parameters defined for the specific modulation phase for Type A at 106 kbps. This modulation phase along with the respective parameters is depicted in the figure below. When the Wave Checker gets the oscilloscope capture, it automatically analyzes the signal, performing all the measurements and comparing them with the specifications limits. Debugging hints for Type A The PN5180 has a few registers and parameters to control the wave shape generated by the NFC chip and transmitted by the antenna. These are the most relevant ones: TX_CLK_MODE_RM (RF_CONTROL_TX_CLK register) Rise and Fall times (RF_CONTROL_TX register) TX_OVERSHOOT_CONFIG register From all the different test cases we will show how to debug the t3 and t4 test case as it is usually the most problematic. For this purpose, we will start from a certain configuration where the waveform tests show the following results, with a fail in the t3 and t4 test case. In order to tackle this problem, we will rely on the TAU_MOD_RISING parameter from the RF_CONTROL_TX register of the PN5180. In this case, as the timings are slightly above the maximum allowed in the specifications we will decrease the TAU_MOD_RISING 3 points and execute again the tests. The results after the modification show that all test are passing with a certain margin:   Another parameter that the PN5180 has and can be used for the waveform tests is the TX_CLK_MODE_RM parameter from the RF_CONTROL_TX_CLK register. Below you can see two graphs that clearly illustrate the effect of this parameter over the waveform.  As you can see from the two figures, by changing the default high impedance configuration of 001, to a low side pull configuration the waveform results in a smoother decay of the envelope. Type B tests For Type B waveform, the specifications define the following test cases:  TB121: Modulation Index TB122: Fall time TB123: Rise time TB124: Monotonic Increase TB125: Monotonic Decrease TB126: Overshoots TB127: Undershoots Again, these tests are based on the different parameters that can be identified for the modulation phase of the Type B commands: Debugging hints for Type B The register and parameters that the PN5180 includes to control the waveform for type B are: TX_RESIDUAL_CARRIER (RF_CONTROL_TX register) TX_CLK_MODE_RM (RF_CONTROL_TX_CLK register) TX_UNDERSHOOT_CONFIG register TX_OVERSHOOT_CONFIG register For Type B, we will study the modulation index test case, as it is the one that needs to be adjusted more often. In this case, we start from a situation where the device presents problems in the modulation index at 1 cm, with a value below the limit. In order to make corrections of the modulation index we will use the TX_RESIDUAL_CARRIER parameter from the RF_CONTROL_TX register. This parameter controls the amplitude of the residual carrier during the modulated phase. For the present problem, we will increase it by 4 points and rerun the test. As you can see in the picture below, the modulation index is within the specifications limits with margin.  Adaptative Waveform Control The PN5180 has another interesting feature called Adaptative Waveform Control that is used to set a different transmitter configuration depending on the gear and protocol used at any moment. This way we can easily debug by positions and use specific configurations for a certain group of positions without the need of rerunning all the tests for the rest of the positions. With the AWC feature we can control the: TAU_MOD_FALLING TAU_MOD_RISING TX_RESIDUAL CARRIER We can see in the table an example of an AWC configuration for Type B. Where we have changed the Residual Carrier from gear 2 onwards. As you can see, It is also configured with a change in the falling and rising times from Gear 1. As you can see this Adaptative Waveform Control feature along with the DPC represent a powerful tool to easily debug waveform tests without a change in the HW. Reception tests The reception tests purpose is to evaluate the ability of the device to identify and correctly demodulate the responses from the PICC when this response comes in the limits of the specifications for amplitude and polarity of the modulation.  Tests setup The tools and setup needed to debug the reception tests for EMVCo are depicted in the following figure: Oscilloscope to capture the signal received by the reference PICC. Arbitrary Waveform Generator to generate the response of the PICC. PC Software to control the AWG and load the EMVCo responses to the EMVCo reference PICC. For our case, we will use the Wave Player software from CETECOM. EMVCo reference PICC. This time, we will use the output J9 of the reference PICC to the oscilloscope to capture the command from the reader and trigger the injection of the response from the waveform generator to reference PICC, connected to J2. We should connect the waveform generator to the computer that has the Wave Player software installed to load the EMVCo responses. Performing tests As said previously, the reception tests aim at testing the ability of the device to correctly interpret the response when it is generated at the limit of the amplitude and polarity of the modulation. Considering the positive and negative polarity and the maximum and minimum amplitude of the modulation we have the following four test cases that are performed both for Type A and Type B: Tx131: Minimum positive modulation Tx133 - Maximum positive modulation Tx135 - Minimum negative modulation Tx137 - Maximum negative modulation To debug these tests with the PN5180 we will use: RX_GAIN (RF_CONTROL_RX register) RX_HPCF (RF_CONTROL_RX register) MIN_LEVEL (SIGPRO_RM_CONFIG register) MIN_LEVELP (SIGPRO_RM_CONFIG register) The procedure is basically to use the Waveplayer to set the amplitude and polarity of the response and check in the device is the response was correctly received and demodulated. Debugging hints To debug the reception we will test different configuration for the RX_GAIN and RX_HPCF parameters that control the reception filters, amplifier and ADC blocks from the receiver branch. These receiver blocks are pictured in the diagram below. Depending on the values used for the RX_GAIN and RX_HPCF parameters, the filter will be defined accordingly. The following table shows the filter characteristics in relation to those values: If we don’t find a correct value to pass the test at a certain position, we should modify the Rx resistor in order to increase or decrease the receiver sensibility. Adaptative Receiver Control In the same line as the Adaptative Waveform Control, the PN5180 includes the Adaptative Receiver Control that can be used to define different reception configurations depending on the gear and protocol used. With the ARC we can control all the registers involved in the reception and apply a correction to the preconfigured value depending on the gear used.  We can see an example of the Adaptative Receiver Control configuration in the following table, where we have defined a correction of -1 to the MIN_LEVEL and the HPCF parameters from gear 1. We can also see that the RX_GAIN parameter has a correction of +2 from gear 0. The ARC is very useful when we can't find a proper configuration for all positions and we need a different set of values depending on the positions tested. Rx Matrix tool Another interesting tool for debugging the reception tests is the Rx Matrix tool. This tool is used to launch and tests different receiver configuration in an automated way. The Rx Matrix tool is integrated into NXP's NFC Cockpit and you can control the Arbitrary Waveform Generator to set the amplitude of the modulation used for the tests. We can select which parameters we want to change and in which range we want them to be tested and the Rx Matrix will automatically run all the possible combinations in a sweep.   With the Rx Matrix tool, we can select the expected response and the number of iterations we want to try for every possible configuration. That way we can obtain a success ratio for the communication and easily identify the best configuration for the position tested. An example of the Rx Matrix is given in the figure below. We have fixed the RX_GAIN and RX_HPCF parameters and performed a sweep for the MinLevel, testing it from a value of 0 to 8. We have set the Rx Matrix to execute 50 iterations for every configuration, obtaining the success ratio results plotted below. As you can see the Rx Matrix along with a Waveform Generator is a powerful tool to find the optimum receiver configuration in a short time and in an effortless way. PN5180 Ecosystem The PN5180 comes with a complete and useful product support package including: The demokit, that can be used to get introduced to the product and check its features. The NFC Cockpit, that we have talked about during this article, and that represents a powerful tool to control the PN5180 with a very intuitive and useful interface. We srongly recommend that you integrate this tool in your final device as it may save you a lot of time during the debugging phase. A complete documentation including the updated product datasheet, or a set of application notes to guide you through all the designing process, from the antenna design guide to the DPC configuration or use of the Rx Matrix tool. Last but not least, the NFC Reader library which is the recommended software stack for NXP's NFC frontends and NFC controllers with customizable firmware. NFC Reader Library The NFC Reader Library comes with built-in MCU support, but it can also run on different MCU platforms, as well as non-NXP. The library has been built in such a way that you can adapt it and implement the required driver for your host platform. Other characteristics are: It is free of charge and you can download the latest release from NXP’s website. It is a complete API for developing NFC and MIFARE-based applications. Includes an HTML-based API documentation for all the components, which is generated from source-code annotations.  Finally, the release includes several examples and applications. Among the examples and applications included in the NFC Reader Library we can highlight two applications that are very useful for the preparation of the Device Test Environment required for the EMVCo certification:  The SimplifiedAPI_EMVCo for the digital testing The SimplifiedAPI_EMVCo_Analog for the Analog testing. You can control all the parameters involved in both applications using the phNxpNfcRdLib_Config.h configuration file. The identification and modification of these parameters should be very easy as the code is well documented, like you can see in the code chunk in the image: 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