This demo consists of the Pico 6UL evaluation SOM and Hobbit carrier board from TechNexion running Brillo OS and the Weave application protocol.  An air sensor module from MicroElecronica is attached to the board via the MicroE Clicks expansion header.  The Air Quality sensor module monitors the surrounding environment and an alert is triggered if the quality of the air falls below a predetermined level.  The data is transferred from the board to an external device utilizing the weave protocol that is present on both the Pico6UL and the corresponding android device. The alert is shown via an app on android build on the Weave API.   Features:   Hardware: 1)      Pico i.MX6UL SOM and Hobbit carrier board from TechNexion 2)      Air Quality Click from Mikore http://www.mikroe.com/click/air-quality/       3)       An Android based tablet   Software: 1)      Brillo OS 2)      Weave application protocol 3)      APK file showing UX based on Weave API   _________________________________________________________________________________________________________________   Featured Products: Hardware partners page Google Brillo developers portal Weave

See how to use the Tower Kinetis 70 development hardware and programmed with PEG GUI, MQX Software Solutions RTOS and processor expert software development tools to create this touch screen controlled, wireless motor control demonstration.   Features Hardware and software modular system that NXP provides for the Kinetis Microcontrollers K series One TWR-K70F120M board communicates with another TWR-K70F120M board wirelessly and then the second TWR-K70F120M board controls a motor Usage of LCD touch panel to control the speed of the motor   Featured NXP Products CodeWarrior Development Tools|NXP Processor Expert Software and Embedded Compon|NXP Kinetis K70 120 MHz Tower System Module|NXP MQX

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  

Near Field Communication (NFC) is hot. It is available in hundreds of millions of smartphones, tablets, and other consumer electronics, and enters more and more the industrial space as well. This article shows how to implement the demos of our "Industrial NFC Demonstrator", first exhibited at embedded world 2017 in Nürnberg.           Parameterization & Diagnosis This demo shows how you can use an NFC phone to parameterize/configure a DIN rail module (or any other piece of electronics) with an NFC phone - even if the module is completely unpowered. The smart phone app lets you set the behavior of the lamps and also the language of the display. After the configuration (a simple tap) you switch on the main power, and the device comes up as configured. And NFC also lets you read out diagnostic data - no matter whether the device is powered on or off. So you can even replace your service UART by NFC. Thirdly, the demo shows how easy it is to even flash your firmware via NFC. Again, this works even when the device is switched off. This application is based on the NTAG I²C plus passive connected tag IC. See here a video from embedded world 2017 showing this demo.   Find a detailed description and all source codes here: https://community.nxp.com/docs/DOC-333834  Interested how this looks like in a commercial product? Watch this video showing how easily the Schneider Zelio NFC Timer Relay can be configured via NFC.   Device-to-device communication In this demo you see how NFC can establish a communication between 2 devices with up to 40 kbit/s. The angular position of the rotating disk is measured, communicated to the main board via NFC and displayed on an LED ring. The nice thing: The rotating disk is without battery. Energy harvesting via NFC provides supply power up to 15mW. This principle of using NFC as a cable replacement is especially interesting in cases where you want to communicate with fully sealed, isolated, moving or rotating units. The communication is bi-directional, and the data can be static (a button press, or configuration data) or dynamic (sensor measurements). The demo is based on the CLRC663 plus reader on the main unit and the NTAG I²C plus passive connected tag on the rotating disk. See here the video from embedded world 2017 demonstrating this application.   Find a detailed description and all source codes here: https://community.nxp.com/docs/DOC-333917       Access control In the Physical Access Control demo, we show a simple implementation of a basic access control solution using a Type 4 tag and a CLRC663 plus based reader, based on the public NFC Reader Library. NXP recommends for a complete real-life access control solution to use MIFARE DESFire credentials as with the MIFARE DESFire EV2 card. Supporting software library is under NDA. In this video from embedded world 2017 you see access control in action.   Download the source code here: http://nxp.com/assets/downloads/data/en/software/RC663Demo_ReadNdefT4T_v1.2.zip           1-tap Bluetooth Pairing This demo shows how easy it is to pair wireless devices to your phone with NFC - using an example of the Kinetis KW41 Freedom board (BLE MCU), with an NTAG I²C plus kit for Arduino® pinout for the NFC function. This new NTAG I²C plus kit is suitable for any board featuring an Arduino-compatible header, including LPCXpresso, Kinetis and i.MX boards. It is the ideal tool to evaluate and design-in an NTAG I²C plus tag chip in an embedded electronic system. Find a detailed description and all source codes here: https://community.nxp.com/docs/DOC-335241     Automation with Hexiwear A nice example of how to build versatile applications, is shown in the automation demo with the Hexiwear IOT development platform. Based on Kinetis MCUs and hundreds of available click-boards (plug-ins with sensors, actuators, transceivers - and of course also NFC), you can quickly build a prototype of your application. Two NFC-based click-boards are available: 1) A reader board based on PN7120 2) A board with NTAG I²C plus The automation demo uses 3 different Hexiwear base boards, connected between them via Zigbee. The NFC unit identifies a technician's badge, and also the tools he uses for his job. The second unit drives the instrument panel, and the third one the big LED screen. A video from embedded world 2017 shows how this works.   Find more information on Hexiwear at www.hexiwear.com.   Our partners in the NFC industrial demonstrator We would like to extend a special thanks to our partners who contributed to this demonstrator: Lab ID and Arti Grafiche Julia: NFC/RFID cards, tickets, labels and inlays Kronegger: Demo on logical access control, NFC reader modules and customized solutions Neosid: Small NFC/RFID transponders for tool identification and authentication   Find out more Discover NFC Everywhere: www.nxp.com/nfc All about MIFARE: https://www.mifare.net Get your technical NFC questions answered: https://community.nxp.com/community/nfc

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

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

The Cypherbridge Systems SDKPac is a collection of embedded device SDKs and Toolkits that can be used out of box to add secure device connectivity to a target project. The SDKPac includes features and standards based protocols for secure IoT connect-to-cloud, gateway, embedded servers and clients, secure file transfer protocols, and electronic data privacy. This SDKPac demo kit contains applications for the FRDM-K64F Freedom Development Board to demonstrate: uSSL/TLS server demo - connect to the FRDM-K64F Development Board from desktop browser. uSSH server demo - connect to the FRDM-K64F Development Board from uSSH client. uFTP secure FTP file transfer client - connect from the FRDM-K64F Development Board to FTPS server using FTPS secure file transfer protocol. uMQTT subscribe and publish examples interfacing to broker service Just drag and drop any of these pre-built binary applications on the FRDM-K64F Development Board to hit the ground running with your SDKPac demo today.   https://community.nxp.com/players.brightcove.net/4089003392001/default_default/index.html?videoId=4282648281001   Features uSSL SDK micro-content HTTPS server uSSH SDK server for secure telnet replacement uFTPS Secure file transfer Toolkit and command line client uMQTT client mmCAU Crypto Engine Support Integrated with MQX/RTCS 4.1 OpenSDA CMSIS-DAP Debug using SWD connection USB Serial Port Interface 10/100 Ethernet   SDK Connectivity uSSL/TLS 1.2 server and client, X.509 uSSH 2.0 server and client uSCP Secure Copy Protocol uFTPS RFC 959, 2228, 4217 uMQTT 3.1 Client subscribe and publish Links SDKPac Follow up System Diagram Software Diagram  

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 NXP has developed a whole vehicle multi-layered approach to vehicle security.  This demo will demonstrate the NXP security products in action, and show the 4 steps to securing an automotive electrical architecture, and how these 4 steps provide a barrier to the recent public vehicle hacks.   Features: Try to hack a typical automotive network. Enable and disable NXPs security layers to see how they work to protect the vehicle. Demonstrates various NXP security IP, including: A700x family secured MCUs, MPC5748G connected gateway and HSM/CSE security engines. ___________________________________________________________________________________________________________________________   NXP Recommends MPC5748G|NXP A700x|NXP   ___________________________________________________________________________________________________________________________      

Demo Owner Mike Stanley   Tire Pressure Monitoring Systems (TPMS) help drivers with precise direct tire pressure measurement by providing individual tire readings – including the spare. NXP's world’s smallest, lowest-power, with highest memory for customer use TPMS is highly integrated with a pressure sensor, temperature sensor, accelerometer, MCU and a transmitter. Watch Mike Stanley explain the pressure sensor readings, temperature sensor display and the accelerometer/motion readings. These readings are time based periodic measurements where the data is given as an output to the driver.   Features Simulation that portraits the TPMS as if it were inside the vehicles tires and sending reports to the vehicle's display unit about tire pressure Module has the following: Pressure sensor, accelerometer, temperature sensor, low-frequency radio, Microcontroller   Featured NXP Products FXTH87 product page FXTH87 Fact Sheet Links Tire Pressure Monitoring Sensors Pressure Sensors Block Diagram  

Near Field Communication (NFC) is already present in more than 1.5 Billion smartphones. Well-known applications like payment and access control are enabled by NFC, but also emerging and innovative use cases which are just appearing on the horizon now. This article gives you more information, background and how-to guides around our NFC demos, first exhibited at embedded world 2018 in Nürnberg - to help you put NFC Everywhere. Accessories and consumables Identifying and authenticating accessories and consumables can add significant value to a product, and for the first time we show live how this works: The demo showcases tool identification via NFC for 3 different kinds of tools: A drill bit, a standard flat-blade screwdriver and a Phillips screwdriver. Each of the tools has an embedded NTAG213 NFC tag, and the electric drill contains an NFC reader (CLRC663 plus). As soon as a tool is inserted, the main unit reads the tool type and usage (wear). Based on this information, it can reject non-genuine or worn-out tools, and adjust internal settings like max/min speed based on the tool type. The demo is based on the brand new NFC Nutshell kit by our partner GMMC, and the demo shows how easily an existing product can be retrofitted with NFC using this kit. Find a detailed description of accessory and consumable identification and authentication here: https://community.nxp.com/docs/DOC-340283 Parameterization, Diagnosis and Firmware update This demo shows how you can use an NFC phone to parameterize/configure a DIN rail module (or any other piece of electronics) with an NFC phone - even if the module is completely unpowered. The smart phone app lets you set the behavior of the lamps and also the language of the display. After the configuration (a simple tap) you switch on the main power, and the device comes up as configured. And NFC also lets you read out diagnostic data - no matter whether the device is powered on or off. So you can even replace your service UART by NFC. Thirdly, the demo shows how easy it is to even flash your firmware via NFC. Again, this works even when the device is switched off. This application is based on the NTAG I²C plus passive connected tag IC.   Find a detailed description and all source codes here: https://community.nxp.com/docs/DOC-333834. Interested how this looks like in a commercial product? Watch this video showing how easily the Schneider Zelio NFC Timer Relay can be configured via NFC. Access Management In the Access Management corner, we demonstrate the ultimate contactless connectivity for residential or hospitality applications through NXP NFC and BLE solutions and a superior contactless experience and security with MIFARE ® DESFire ® credential on cards, mobile devices and wearables. Our demonstrator is based on the PN7462 family, the all-in-one full NFC controller, the QN9021, a low power BLE system-on-chip, and the PCF8883T, capacitive proximity switch with auto-calibration, for very low power consumption. We also show two commercial products by our partners: 1) The Salto XS4 range of smart doorlocks, a simple to use and very efficient access control system. 2) A modular access control solution by Kronegger, using their tiny NFC reader boards. We also reveal a very small footprint complete reader board based on the new BGA package (VFBGA64; 4.5x4.5 mm²) for the PN7462 family complementing the existing HVQFN64 package.   NFC Tandem - The Best Of Two Worlds If you need NFC functionality both in powered and unpowered state, have a look at the NFC Tandem demo: An NFC reader (PN7150) and a passive connected NFC tag (NTAG I²C plus) sharing one antenna. A user can interact with the device when it is powered off (through the NTAG I²C plus); when the device is powered, it can read cards, tags or other connected tags. Find design files, a user manual and further downloads here: https://community.nxp.com/docs/DOC-340244 Single-Chip Integrated Solution: LPC8N04 MCU with passive NFC interface In this demo, we show our latest integrated NFC solution, the LPC8N04, a cost-effective MCU with integrated (passive) NFC connectivity. This MCU offers multiple features, including several power-down modes and a selectable CPU frequency of up to 8 MHz for ultra-low power consumption. The demo showcases its features in a conceptual clock format: - Easily set current time/date of the clock via an NFC phone - Real-time clock with optional alarm, programmed and controlled using an Android app - GPIO controlled bar graph indicating programmable "safe operating range" - I2C controlled OLED user display - Data (temperature) logging, configured using an Android App To learn more about this device, please visit: www.nxp.com/LPC8N04 Single-Chip Integrated Solution: NTAG SmartSensor NTAG SmartSensor allows consumers and brand owners to confirm that temperature sensitive products – like fish, wine or pharmaceuticals – have been properly handled. The NTAG SmartSensor allows for temperature sensing at the item level, so each individual product can be confirmed as safe to use. And a single tap with your NFC smartphone is all that's needed to read out the temperature history of the NTAG SmartSensor. Learn more about NTAG SmartSensor on our webpage or watch the video. If you are looking for a ready-made logger using the NTAG SmartSensor, here is a list of manufacturers offering NTAG SmartSensor based loggers. Electronic Shelf Labels With NFC-enabled Electronic Shelf Labels (ESL), wrong price indication, non-transparent processes, and unsatisfactory customer interactions are a thing of the past. In this demo we show labels from 2 manufacturers, one commercial electronic shelf label from SES Imagotag and one ePaper label from MpicoSys. Find more information in the article by Fabrice Punch, Senior Marketing Manager at NXP. Why NFC on ePaper label? NFC allows for creating a product with no batteries, so no recharging, and labels can be in constant use  No cables and connectors - labels can be fully sealed and made waterproof NFC is a well-proven and widely-supported standard  Allows for easy integration with both PC and smartphones    Applications for PicoLabel - MpicoSys ePaper labels Logistic labels (warehousing, supply chain management)  ID Badges (show image on employee, visitor and conference badges)  Authentication badges (identity, authentication, cryptographic security) Door signage (shared offices, conference centers) Manufacturing (replacing paper labels) NFC Cube The NFC Cube is the universal demo for NFC applications: It shows communication between a device and a card/tag, between a device and a phone, and between two devices. It uses the PN7462AU single-chip NFC controller with integrated Cortex M0 core. The NFC Cube kit is interoperable with our NTAG I 2 C plus Explorer board, which enables you to demonstrate how 2 devices can communicate via NFC. NFC Portfolio and Package Options Find here an overview of the package options of our NFC reader and connected tag ICs. Our Partners In The NFC Everywhere Demonstrator We would like to extend a special thanks to our partners who contributed to this demonstrator: Lab ID: NFC/RFID cards, tickets, labels and inlays Kronegger: Demo on logical access control, NFC reader modules and customized solutions Salto: Smart door lock demo GMMC: NFC Nutshell Kit for easy demonstration, retrofitting and development of small NFC reader solutions SES Imagotag: Commercial electronic shelf label with customer interaction via NFC MpicoSys: Commercial PicoLabel based on ePaper and content update via NFC Find out more Discover NFC Everywhere: https://www.nxp.com/nfc All about MIFARE: https://www.mifare.net Get your technical NFC questions answered: https://community.nxp.com/community/identification-security/nfc List of Approved Engineering Consultants (AEC) for NFC: https://nxp.surl.ms/NFC_AEC NFC Everywhere Brochure: https://www.nxp.com/docs/en/brochure/NFC-EVERYWHERE-BR.pdf 

Demo Owner AngelC This demo shows the ability to control various wireless devices within a home network with a smart phone / Tablet. This is done by having a so-called gateway system consisting in Tower System TWR K60 Kinetis development module connected via Ethernet/Wi-Fi with a wireless router,  plus a Kinetis KW2x MCU device controls a ZigBee-based home automation 1.2 and a TCP/IP network using a single radio (Dual PAN) . In brief, the Android application running in the tablet connects via Wi-Fi to the gateway, which translates every command to both ZigBee HA 1.2 and TCP/IP networks, thus enabling any Wi-Fi enabled device to control several devices even if using different communication protocols. Features ZigBee and TCP/IP connection Android application Featured NXP Products Product Link Kinetis® K60-100 MHz, Mixed-Signal Integration Microcontrollers based on Arm® Cortex®-M4 Core Arm® Cortex®-M4|Kinetis K60 100 MHz 32-bit Microcontrollers|NXP | NXP  Kinetis K60 100 MHz MCU Tower System Module TWR-K60D100M|Tower System Board|Kinetis MCUs | NXP 

本文说明在S32G上如何修改eMMC时钟，来避开200Mhz的或及倍频的频率EMI干扰检查点。 目录 1    背景说明和需要的资料... 2 1.1  背景说明... 2 1.2  需要的资料... 2 2    eMMC的硬件连接... 3 3    eMMC时钟初始化方法... 4 3.1  eMMC时钟源说明及修改目标... 4 3.2  M7+Bootloader方法(可选项) 6 3.3  ATF初始化方法... 7 4    修改eMMC时钟... 9 4.1  ATF的修改... 9 4.2  Uboot相关的修改... 9 4.3  非整除时钟的修改考虑... 10 5    测试结果... 11 update to V2，增加分数分频： 6    分数分频... 13 6.1  调试方法... 13 6.2  代码修改... 14 6.3   测试结果   15

本文说明S32G在Linux中如何使用内存读写工具来发起一个HSE Server服务请求，以确认HSE是否正常工作。本说明的目的旨在在极端缺少Debug手段的情况下，确认HSE的状态。 目录 1    背景说明与参考资料... 2 1.1  背景说明... 2 1.2  参考资料... 2 2    启动包含HSE的Linux镜像... 3 3    HSE服务代码逻辑与寄存器状态... 3 3.1  HSE Demo示例... 3 3.2  IDEL情况下MU寄存器状态... 6 4    使用Linux memtool命令来访问HSE. 10 4.1  检查HSE状态... 10 4.2  准备hseSrvDescriptor_t数据结构... 10 4.3  申请HSE服务... 11 5    其它建议... 12

本文说明如何配置MCAL UART模块为DMA模式。 默认的MCAL UART模块是使用的PIO模式。 本文采用软件版本为MCAL RTD 4.0.2。 目录 1    背景与资料说明... 2 1.1  背景说明... 2 1.2  所需资料说明... 2 2    创建UART工程... 2 2.1  打开工程... 2 2.2  修改波特率... 3 2.3  编译... 3 2.4  默认工程说明与运行... 4 3    配置UART DMA模式... 5 3.1  参考资料... 5 3.2  增加并配置MCL模块... 5 3.3  修改UART模块... 6 3.4  修改Platform模块... 7 3.5  处理Cache相关问题... 7 3.6  测试结果... 8

本文说明如何配置MCAL ICU模块为GPIO Input。 默认的MCAL ICU模块是使用FTM输入为示例的。 本文采用软件版本为MCAL RTD 4.0.2 目录 1    背景与资料说明... 2 1.1  背景说明... 2 1.2  所需资料说明... 2 2    创建ICU工程... 3 2.1  打开工程... 3 2.2  编译与运行... 3 2.3  默认工程说明... 4 3    增加GPIO输入支持... 6 3.1  修改说明... 6 3.2  修改Port模块... 6 3.3  修改ICU模块... 7 3.4  Platform模块... 8 3.5  主测试程序修改... 9 3.6  测试结果... 10

本文说明S32G3 M7核Standby MCAL demo 详细情况及定制，并在进入Standby之前 调用QSPI 接口将QSPI NOR flash配置进入 deep power down模式，以节省用电。 目录 1    参考资料说明... 2 2    G2和G3 Demo的区别... 2 3    G3 MCAL Demo的实现... 4 3.1  修改UART驱动... 4 3.2  实现时钟关闭代码... 4 3.3  配置电源模式切换驱动... 5 3.4  配置唤醒源... 5 3.5  加入PMIC驱动... 6 3.6  主函数逻辑实现... 7 3.7  运行测试... 7 3.8  未来开发计划... 8 4    将QSPI NOR设置进入Deep Power Down模式... 8 4.1  Fls层的修改... 10 4.2  中间层的修改... 10 4.3  QSPI_IP层的修改... 13 4.4  主测试函数调用... 16 4.5  Fls驱动的测试... 17 5    将Deep Power Down功能集成到STANDBY工程中并测试    18 5.1  EB配置... 18 5.2  主测试函数与编译修改... 20 5.3  运行测试... 21

现在越来越多的客户，对于S32G PFE在master/slave的使用有了需求。 但是，PFE只有4个HIF接口，HIF0~HIF3，而PFE有3个EMAC口，以及LLCE2PFE也需要要给HIF，从而HIF成为一个关键资源。 同时，有些客户需要从A核，M核的业务考量，A核和M核的网络不仅要和外部设备进行通信，同时A核和M核内部也有通信需求，并且需要把业务报文和管理报文分离，这就对PFE master/slave的使用场景有了更多变化，以及对各种配置有了更多需求。 因此，针对PFE/Slave的几种使用典型的使用场景，进行配置。

在进行时钟同步时，目前S32G2/G3有一种很典型的使用场景： Grand master clock  <-> S32G PFE <-> 其余连接在PFE 某些 eMAC口上的设备 外部的grand master clock，连接在PFE的一个eMAC上，要同步S32G以及连接在PFE其余eMAC上的设备时钟。 但是S32G2/G3的PFE仅仅是支持timestamp，对于将S32G PFE设置成交换机使用时，PFE不能实现Transparent clock的功能。 因此，本文讨论将PFE + S32G SoC当作Transparent clock，以及将PFE + S32G当作boundary clock，来同步S32G以及其余部件的时钟。