This demo shows how to load the different demo codes for the kit FRDM-K64 with FRDM-FXS-MULT2B boards, to access the different sensors included in the card and use it to create your own applications. This demo runs on a K64 freedom board and uses the MCUXpresso IDE, the FRDM-K64 with MULT2B SDK and a serial terminal, in this case TeraTerm. Video: Software Links: Driver FRDM-K64: http://developer.mbed.org/media/downloads/drivers/mbedWinSerial_16466.exe MCUXpresso (requires NXP account): https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools/mcuxpresso-integrated-development-environment-ide:MCUXpresso-IDE SDK Builder (requires NXP account): https://mcuxpresso.nxp.com/en/select_config_tools_data TeraTerm: https://osdn.net/projects/ttssh2/releases/ NXP Product Link Freedom Development Platform for Kinetis® K64, K63, and K24 MCUs FRDM-K64F Platform|Freedom Development Board|Kinetis MCUs | NXP  Freedom Development Platform for NXP® Sensors with Bluetooth®. Freedom Development Platform Bluetooth® | NXP 

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

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

Based on Continua Health Alliance standards for healthcare devices, a Kinetis MCU encapsulates the data using the IEEE® 11073 standard. In this example, a Freedom development platform operates as the near field communication board that bridges between the NFC antenna and the manager. Features Emulation of blood glucose module Low Power  technologies specific for healthcare NFC reading from blood glucose monitor Continua compliant demo (IEEE 11073) Featured NXP Products Product Link Kinetis® L Series Kinetis L Series Microcontrollers - Arm® Cortex™-M0+ Core | NXP  Freedom Development Platform for the Kinetis® KL05 and KL04 MCUs FRDM-KL05Z|Freedom Development Platform|Kinetis® MCU | NXP 

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

Overview In this demo we show how to load an example of an NFC reader using the combination between the UDOO NEO card and the development kit for the PN7150. PN7150ARD kit is a high performance fully NFC compliant expansion board compatible with Arduino Compatible Interface platforms. It meets compliance with Reader mode, P2P mode and Card emulation mode standards. The board features an integrated high-performance RF antenna to insure high interoperability level with NFC devices. Video Required Items UDOO NEO Compatible MicroSD card of at least 4 or 8 Gb memory size Micro USB cable UDOO Neo demo image file PN7150 NFC Controller Board         Links   Step by Step guide (Inlclude all links): https://www.nxp.com/docs/en/application-note/AN11841.pdf    NXP Product Link Development Kits for PN7150 Plug’n Play NFC Controller NFC Development Kits for Arduino and more | NXP 

Experience an audio framework that provides an integrated and configurable system of media components to enable rapid system integration. This solution supports digital audio streaming, audio processing, device connectivity, media library management and browsing with GUI and hardware IU. NXP's audio solutions framework is a scalable framework supporting Kinetis Microcontrollers to i.MX application processors.       Features Scalable multimedia platform set of Middleware APIs developed by NXP Able to run on different silicon (i.MX6, @Vibryd, Kinetis Microcontrollers with different operating systems (MQX Software Solutions, Linux) Featured NXP Products i.MX6 Vibryd Kinetis K70 Links Embedded Linux for i.MX Applications Processors NXP MQX™ Software Solutions  

Demo This demo features NXP’s new Sensor Toolbox - The complete ecosystem for product development with NXP sensors. It encompasses NXP's wide spectrum of new sensor boards and software tools across various compatible Kinetis microcontrollers, enabling ‘out of box’ sensor demonstrations, sensor evaluation, sensor application development and prototyping. Check out a variety of impressive 'Out of Box' Sensor Demonstrations and Sensor Fusion, all enabled by NXP’s new Sensor Toolbox.  Also, don’t miss the Sensor Fusion Demo now running on the LPC platform Features Plug and Play ‘Out of the Box’ Demonstrations with 6 different sensor hardware demo kits using the Sensor Toolbox Community Edition (STB-CE) software. Showcasing the ease of quickly visualizing sensor data. 6 Sensor Demo kits include : FRDM-K64F-AGM01  (Sensor Toolbox Demo Kit for 9-Axis Solution) FRDM-K22F-SA9500  (Sensor Toolbox Demo Kit for FXLC95000CL Intelligent Motion Sensor) FRDMKL25-A8471 (Sensor Toolbox Demo Kit for FXLS8471Q  3-Axis linear Accelerometer) FRDMKL25-A8491 (Sensor Toolbox Demo Kit for MMA8491Q  3-Axis Digital Accelerometer) FRDMKL25-P3115 (Sensor Toolbox Demo Kit for MPL3115A2 Pressure Sensor/ Altimeter) RD-KL25-AGMP01 ( Sensor Toolbox 10-Axis Data Collection Board) Sensor Fusion Demo (Part of the Sensor Toolbox-CE software) Demo showcasing device orientation detection in real time using 3, 6 and 9-Axis Sensor Fusion options. (Rotating 3D PCB display) Showcasing no cost, open source and the most complete Sensor Fusion solution available. Showcasing sensor fusion running on both Kinetis and LPC MCU platforms with NXP’s 9-axis sensor board  (AGM01-Kinetis Board and AGM01-LPC Board) _______________________________________________________________________________________________________ Featured NXP Products: Sensor Toolbox|NXP _______________________________________________________________________________________________________

Description A gamepad is a device used to interact with a videogame through a PC or console.  This gamepad in particular, includes an LCD display and touch panel for a better gaming experience. In addition, as the play environment becomes more mobile and a game can easily be connected to any network (at a friend’s house, an Internet café, a community gaming center or even an amusement park) NXP offers secure, connected devices and technologies. Add in our sensing solutions with high-performance sensing capability, processing capacity and customizable software, power management ICs and wireless charging solutions to get a complete system solution.   Features   LCD Display Touch Panel NFC Pair BLE connectivity USB Type C LED driver Smart amplifier for speaker     Block Diagram       Products   Category Name 1: MCU Product URL 1 LPC546XX Microcontroller (MCU) Family | NXP  Product Description 1 Offering the ultimate in flexibility and performance scalability, the LPC546xx MCU family provides up to 220 MHz performance while retaining power-efficiency as low as 100 uA / MHz. Its 21 communication interfaces makes it ideal for the HMI and connectivity needs of next-generation IoT applications.   Category Name 2: Drivers Product URL 1 PCA9955BTW | NXP  Product Description 1 The PCA9955B is an I2C-bus controlled 16-channel constant current LED driver optimized for dimming and blinking 57 mA Red/Green/Blue/Amber (RGBA) LEDs in amusement products. Product link 2 9.5 V boosted audio system with adaptive sound maximizer and speaker protection | NXP  Product Description 2 The TFA9890A is a high efficiency class-D audio amplifier with a sophisticated speaker boost and protection algorithm. Product link 3 TEA172x | NXP  Product Description 3 These highly integrated devices enable low no-load power consumption below 10 mW, reduce component count for a cost-effective application design, and provide advanced control modes that deliver exceptional efficiency. Product link 4 Logic controlled high-side power switch | NXP  Product Description 4 The NX5P2190 is an advanced power switch with adjustable current limit. It includes under-voltage and over-voltage lockout, over-current, over-temperature, reverse bias and in-rush current protection circuits.   Category Name 3: USB Product URL 1 USB PD and type C current-limited power switch | NXP  Product Description 1 The NX5P3290 is a precision adjustable current-limited power switch for USB PD application. The device includes under voltage lockout, over-temperature protection, and reverse current protection circuits to automatically isolate the switch terminals when a fault condition occurs. Product link 2 PTN5150 | NXP  Product Description 2 The PTN5150 enables USB Type-C connector to be used in both host and device ends of the Type-C cable. It can support Type-C to USB legacy cables and adapters defined in USB Type-C Spec.   Category Name 4: Wireless Product URL 1 PN7150 | High performance NFC controller for smart devices | NXP  Product Description 1 PN7150 is the the plug andn play NFC solution for easy integration into any OS environment, reducing Bill of Material (BOM) size and cost. Product link 2  NTAG213F, NTAG216F | NFC Forum Type 2 Tag compliant IC with field detection | NXP  Product Description 2 The NTAG213F offers innovative functionalities such as: the configuration of a field detection, the SLEEP mode, the FAST_READ command, and a configurable password protection. These capabilities fit perfectly for applications in electronics that require the following features: connection handover, Bluetooth® simple pairing, Wi-Fi protected set-ups, device authentication or gaming. Product link 3 QN908x: Ultra-Low-Power Bluetooth Low Energy System on Chip (SoC) Solution | NXP  Product Description 3 QN908x is an ultra-low-power, high-performance and highly integrated Bluetooth® Low Energy (BLE) solution for Bluetooth Smart applications such as human interface devices, and app-enabled smart accessories.   Documentation Connecting TFT LCD with LCD controller of LPC MCU:  https://www.nxp.com/docs/en/nxp/application-notes/AN12027.zip    Tools Product Link OM13098: LPCXpresso54628 Development Board OM13098 | LPCXpresso Development Board | LPC Microntrollers (MCUs) | NXP 

Description   Sigfox is a French company founded in 2009 that builds wireless networks to connect IoT devices. Their original focus was on industrial/professional applications such as water meters. Sigfox has recently been applying their technology to consumer applications such as smart watches and home alarms. The key parameters for the application is the requirement to exchange continuously and securely small amounts of data. A wireless base station is a transceiver that connects other devices to one another and/or to a wider area. In this particular application we are implementing a Sigfox base station.   Features Low power Securely Small amounts of data Securely transmitting small amounts of data   Block Diagram     Products   Category Name 1: MCU Product URL 1 Layerscape LS1012A Communication Processor for the IoT | NXP  Product Description 1 The QorIQ® LS1012A processor, optimized for battery-backed or USB-powered, space-constrained networking and IoT applications.   Category Name 2: Wireless Product URL 1 Low-Power Multi-Channel UHF RF Wireless Platform | NXP  Product Description 1 The OL2385 device is a radio frequency transceiver with an embedded MCU designed for a wide range of industrial and home applications requiring a very high link budget for bi-directional RF communication.   Category Name 3: Power Management Product URL 1 VR5100 Multi-output DC-DC for COMM Processor | NXP  Product Description 1 The VR5100 is a high-performance, multi-output DC-DC regulator designed to power single or dual core LS1 processors like LS1012A and LS1024A.   Category Name 4: Peripherals Product URL 1 Logic controlled high-side power switch | NXP  Product Description 1 The NX5P2190 is an advanced power switch with adjustable current limit. It includes under-voltage and over-voltage lockout, over-current, over-temperature, reverse bias and in-rush current protection circuits. Product URL 2  TJA1101 | 2nd generation PHY Transceiver | NXP  Product Description 2 TJA1101  offers 100Mbit/s transmit and receive capability per port over up to at least 15m of unshielded twisted pair (UTP) cable.   Tools   Product Link OM2385/SF001 - OL2385 Wireless sub-GHz Transceiver SIGFOX Development Kit with KL43Z OM2385/SF001 - SIGFOX Development Kit | NXP  Layerscape FRWY-LS1012A board FRWY-LS1012A Development Platform | NXP  KITVR5100FRDMEVM: Evaluation Kit for VR5100 Power Management Integrated Circuit Evaluation Kit for VR5100 Power Management Integrated Circuit | NXP 

App-based accessory demo for an iPod remote control using the Tower System with TWR-DOCK module. Demonstrates an example of how you can build audio accessories such as speaker docks, soundbars and car audio systems.     Features Designing electronic accessories for devices such as the iPhone®, iPad® and iPod® 30-pin dock connector for iPhone, iPad, or iPod devices USB A port for iPhone, iPad or iPod connection over standard USB to Apple Lightning® and 30-pin dock connector cables Analog stereo audio line out (RCA) Analog video out (composite, S-Video and component) Digital audio input and output transferred via USB connection Interface software for iPhone, iPad, and iPod devices Power input connector (2.1A, 1A) for device charging Interface software optimized for Kinetis MCUs, hardware supports a wide range of MCU and MPU Tower Modules Compatible with Tower peripheral modules Featured NXP Products TWR-DOCK: Tower System Dock Module TWR-DOCK2: Tower System MFi Interface Module Design Resources TWRDOCKFS: TWR-DOCK Fact Sheet TWR-DOCK-K60 kit contains: TWR-DOCK module with power supply and global adaptor TWR-K60N512 Kinetis K60 MCU Module TWR-PROTO Prototyping Module with perfboard area TWRPI-MPL115A Pressure Sensor Plug-In TWR-ELEV Elevator Modules TWR-DOCK-K60LCD kit contains: TWR-DOCK module with power supply and global adaptor TWR-K60N512 Kinetis K60 MCU Module TWR-LCD graphical LCD module TWR-AUDIO-SGTL audio module TWR-ELEV Elevator Modules

KL25Z    FRDM-KL25Z|Freedom Development Platform|Kinetis MCU|NXP K64F FRDM-K64F|Freedom Development Platform|Kinetis MCUs|NXP Links to MBED FRDM-KL25Z | mbed FRDM-K64F | mbed

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 _______________________________________________________________________________________________________    

Demo This demo demonstrates the Mobility software (PDCP-GTPU) as VNF in virtualized environment, virtio-PDCP device for PDCP Security offload to H/W accelerator. The guest application is real time implementation of PDCP-GTPU layers of LTE data plane using DPDK library.       Features: Accelerated PDCP-GTPU VNF for Cloud RAN Deployments. DPDK integrated solution for high performance on ARM cores. Accelerated PDCP security processing by offloading to NXP SEC accelerator via virtio-interface (virtio-pdcp) Option to offload Virtio backends to AIOP Cores on NXP LS platforms.   _______________________________________________________________________________________________________   Featured NXP Products: QorIQ Processors Based on ARM Technology|NXP QorIQ LS2085A Communication Processors |NXP _______________________________________________________________________________________________________ Related Link https://community.freescale.com/videos/3994     N11

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

Demo This demo shows how the FRDM-K82F board along with an OV7670 Camera module can be utilized to create a USB web camera application. The demo application software is delivered as part of the KSDK software enablement. The FS USB video class demonstration can deliver images to PCs or tablets. Features: USB Video device class demonstration application included in Kinetis SDK Easy connection to PC or tablet  display and process video captured from the device FlexIO camera driver utilized to interface to OV7670 camera module _______________________________________________________________________________________________________ Featured NXP Products: ARM Cortex-M4 Cores|Kinetis K8x MCUs|NXP AN5275: Using FlexiO for Parallel Camera Interface AN5280: Using Kinetis FlexIO to drive a Graphical LCD _______________________________________________________________________________________________________