This NXP demo is a combination of two demos running on the MIMXRT1050-EVK board, showing USB Type-C power delivery and a GUI with touch interface running on the i.MXRT1050 MCU. See video of demo below.   First example is USBPD demo from the MCUXpresso Software Development Kit (SDK) for the kit. This SDK can be downloaded from https://mcuxpresso.nxp.com. The SDK USBPD project is included at \SDK_2.3.0_EVK-MIMXRT1050-OM13588\boards\evkmimxrt1050_om13588\usb_examples\usb_pd. This demo uses the FreeRTOS version. Generic description of this demo is included here in the SDK at \SDK_2.3.0_EVK-MIMXRT1050-OM13588\docs\usb\MCUXpresso SDK USB Type-C PD Stack User's Guide.pdf. Second example is a washing machine GUI using TouchGFX. This example is provided by Draupner Graphics with source code in their TouchGFX release, with more details shared here: https://touchgfx.com/nxp-semiconductors/i-mxrt1050-display-kit/ Here is a video overview of using this combined demo: Hardware Requirements ===================== For the full demo shown in the video, the following hardware is required: MIMXRT1050-EVK - eval kit for i.MXRT1050 MCU LCD - comes with MIMXRT1050-EVK OM13588 (x2) - USB Type-C shield board, two shields required FRDM-K64F - Kinetis K64 Freedom development board 0.1" female headers for Arduino connectors, not included Cables: USB Type-A to male micro-B (2 cables needed) USB Type-C male to Type-C male 9V power supply with barrel connector (2 supplies needed). Come with OM13588 kits Software Details ================ This demo was built with the following software versions: IAR Embedded Workbench for ARM v8.20.2 MCUXpresso SDK_2.3.0_EVK-MIMXRT1050-OM13588, Build Date: 2017-12-11 MCUXpresso SDK_2.3.0_FRDM-K64F-OM13588, Build Date: 2018-01-10 TouchGFX v4.9.0 Setup Video NXP Recommend Product Link USB Type-C Shield Board for Kinetis® Freedom and LPC Boards OM13588: USB Type-C Shield Board | NXP  i.MX RT1050 Evaluation Kit i.MX RT1050 Evaluation Kit | NXP  Freedom Development Platform for Kinetis® K64, K63, and K24 MCUs FRDM-K64F Platform|Freedom Development Board|Kinetis MCUs | NXP 

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

This post entry provides a detailed description of how 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

Demo NXP’s Smart Defrost Solution is the newest way to defrost food. From frozen solid to sliceable food in minutes. Our solution uses RF and a smart tuning unit to evenly defrost food. The NXP Smart Defrost reference design consists of the following:    Defrost Appliance Concept                              Smart Defrost Reference Design Block Diagram Reference Design Features • RF creates the energy used to raise food temperature • Smart Tuning Unit intelligently adjusts operation for properties of the food within the defrost chamber • Electrodes provide the delivery of energy into the defrost cavity • Defrost cavity is a shielded, enclosed space for defrosting frozen food • Host control for main appliance control and user input interface Benefits • Reduced time-to-market • Simple integration into system • Predictable repeatable results • Creates even defrost environment • Reliable • Cost-effective interconnection • Minimum software needed for control Links https://www.nxp.com/pages/defrosting:RF-DEFROSTING-PG   Fact Sheets https://www.nxp.com/docs/en/fact-sheet/SmartDefrostRDFS.pdf  https://www.nxp.com/docs/en/fact-sheet/SDS31300FS.pdf

Demo Need to increase the power of your system? Check out our MRFX1K80H design reuse video to see the benefits of 65 V technology in action. In this video, Danny Molezion, FAE from Richardson RFPD and Jim Davies, NXP Applications Engineer swap out NXP’s 1250 W device with the MRFX1K80H device using the same PCB. Product www.nxp.com/65V www.nxp.com/MRFX1K80H   Links http://www.richardsonrfpd.com/NXP65V Press Release|NXP 

Demo NXP, the number one supplier of high power RF power transistors, has a new 5G cellular base station concept alongside many other innovative cellular infrastructure solutions and technologies that is being shown at industry events. Product innovations from NXP are in the areas of 5G, from Gigabit LTE leading up to 5G using GaN and silicon LDMOS for macro and small cell base stations. Learn more about the steps that NXP is taking toward enabling the 5G wave Features Smaller footprint to reduce installation costs Network infrastructure evolution Active antenna rise Power consumption Multiple standards to support with 3G, 4G to 5G Link  5G Infrastructure|NXP 

Demo i.MX RT1050 from NXP showing three different Storyboard Suite demo applications; Washing Machine, Home Automation and Medical demos. Based on the Arm ®  Cortex ® -M7, the i.MX RT series bridges the gap between the performance of applications processors and the usability of MCUs, without compromising low-power or low cost. Video Overview (Click here) NXP Products Product Link i.MX RT1050 Evaluation Kit i.MX RT1050 Evaluation Kit | NXP  4.3" LCD Panel 4.3" LCD Panel RK043FN02H-CT | NXP 

Winners! NXP received a number of creative submissions over the course of the MRFX Design Challenge. We appreciate the enthusiasm from the community as designers were hard at work on their RF projects. Now is the moment everyone's been waiting for as NXP proclaims the MRFX Design Challenge winners. First Place Winner  Russell Kendrick | Bio + Full Project Description Project Video: MRFX1K80H 50 MHz Project Brief This amplifier is intended to be driven with a modern transceiver with 100 watts output on 50 MHz. To protect the MRFX1K80H from overdrive a series of RF pads are used to reduce the input to the proper level. The input matching is accomplished by using a 9:1 conventional RF transformer formed on an Amidon BN 61-202 core. An 82 nH inductance is in series with the high impedance winding of the transformer. This arrangement yielded an input match of 1.3:1 SWR over the entire 6-meter Amateur band when measured without the pads. Shunt gate resistance is used to prevent oscillation at low frequencies. This is the same approach used in the 27 MHz test circuit from NXP. Bias will be supplied by a DAC driven by the microcontroller that will manage the finished amplifier Second Place Winner        Floris Roosen | Bio                                                                         Project Video: Roosen Single-Ended Broadband (87-110 MHz) RF Design         Third Place Winner Mike Mysliwiec | Bio Project Video: 2xMRFX1K80H 1.8-54 MHz HF Amplifier   Overview  NXP is hosting an RF power amplifier design contest. Applicants will record a video of their power amplifier/demo using NXP’s new 65V LDMOS 1800 W RF Power transistor, MRFX1K80H The contest is open to students, professional engineers, companies or individuals Key Dates Contest kick-off: October 30, 2017 Submit a video (3-5 minutes in length) no later than Friday, January 26, 2018, by sending a link to any video website, such as YouTube, YouKu or others to rfindustrial@nxp.com Results will be announced on Monday, February 12, 2018 Prizes • 1st prize: $3,000 cash award + 15 MRFX1K80H samples. Showcase designer bio and video in an NXP blog • 2nd prize: $1,000 cash award + 10 MRFX1K80H samples • 3rd prize: $500 cash award + 10 MRFX1K80H samples The prize amounts are before tax All accepted videos will be posted on www.nxp.com/videos  Judging Criteria How to enter the competition Please click on the link below for the latest details and to access the MRFX Design Challenge page www.nxp.com/MRFXdesign 

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

Demo This demo shows an intelligent and efficient automotive system which encompasses surround view (360 Video camera) paired with a LIDAR (360 Laser surround view) for pedestrian detection, traffic sign recognition, speed detection, etc. Products Links NXP BlueBox https://www.nxp.com/design/development-boards/automotive-development-platforms/nxp-bluebox-autonomous-driving-development-platform:BLBX?&fsrch=1&sr=2&pageNum=1 QorIQ® LS2088A Reference Design Board https://www.nxp.com/design/qoriq-developer-resources/qoriq-ls2088a-reference-design-board:LS2088A-RDB?&lang_cd=en S32V230 Family of Processors https://community.nxp.com/external-link.jspa?url=http%3A%2F%2Fwww.nxp.com%2Fproducts%2Fautomotive-products%2Fmicrocontro…  S32R Radar Microcontroller - S32R27 https://community.nxp.com/external-link.jspa?url=http%3A%2F%2Fwww.nxp.com%2Fproducts%2Fautomotive-products%2Fmicrocontro…  32-bit Automotive General Purpose MCUs https://community.nxp.com/external-link.jspa?url=http%3A%2F%2Fwww.nxp.com%2Fproducts%2Fautomotive-products%2Fmicrocontro…  Other Links ADAS & Autonomous Driving|NXP  V2X Communications|NXP 

Demo Wheel rotation is controlled by the SB0400 DC motor pre-driver. When the wheel is stopped manually, the Wheel Speed Sensor -KMI23- detects it & sends a signal to the SB0400 motor pre-driver & S32K MCU to activate the electromagnet Products 32-bit Automotive General Purpose MCUs|NXP Motorcycle Two-Wheel Antilock Braking (ABS)|NXP KMI23_KMI25|NXP  Links Motorcycle Two-Wheel Antilock Braking (ABS)|NXP  Analog Expert Software and Tools|NXP  Recommended product Link S32K144EVB https://www.nxp.com/design/development-boards/automotive-development-platforms/s32k-mcu-platforms/s32k144-evaluation-board:S32K144EVB?&fsrch=1&sr=1&pageNum=1

Demo Enable Your Device with Amazon® Alexa®  Quickly integrate Alexa voice capabilities into your product Reference design based on i.MX 7Dual applications processor Easily create high-performance, far-field voice experiences with Echo-quality performance using Amazon’s best-in-class 7-microphone circular array Technology for “Alexa” wake word recognition Beam forming Noise reduction Acoustic echo cancellation Barge-in capabilities Products i.MX 7Dual Arm Cortex-A7 Processor|NXP  12-Channel Configurable PMIC|NXP  Link Amazon Alexa Reference Design based on the Pico i.MX7 Dual|NXP  Training Voice Control Solutions: Creating Amazon® Alexa® Devices with i.MX 

Demo On this demo, we are showing a comparison between CAN-FD and classic CAN on the LPC54618 microcontroller. The LPC board is doing a firmware update using both CAN protocols Dual LPC54618 microcontroller CAN-FD kits illustrate the speed benefits of CAN-FD versus classic CAN One board acts as the vehicle console display and the other emulates a radio which serves the HMI over the CAN link Selecting between CAN and CAN-FD demonstrates the benefits in the display updates and in a simulated firmware update transfer Product Link LPCXpresso54618 CAN-FD kit OM13094 | LPCXpresso Development Board | LPC Microntrollers (MCUs) | NXP  LPC546XX LPC546XX Microcontroller (MCU) Family | NXP  Block Diagram

Demo See how NXP integrates automotive and microcontroller technology to develop next-generation drones including high reliability, industrial quality, and additional security with drone-code compliant flight management unit running PX4. Video Features Electronic speed controllers with Field Oriented Control of BLDC (Brushless DC motors) TJA110 2-wire  Automotive Ethernet PHY Transceiver|NXP  SCM-i.MX6 Training https://register.gotowebinar.com/rt/9153317036356506113  Find our more at www.nxp.com/uav

Demo Low-cost evaluation board running a PMSM motor Products Links S32K144 Evaluation Board https://www.nxp.com/design/development-boards/automotive-development-platforms/s32k-mcu-platforms/s32k144-evaluation-board:S32K144EVB?&fsrch=1&sr=1&pageNum=1 Low-Cost Motor Control Solution for DEVKIT Platform https://www.nxp.com/design/development-boards/automotive-development-platforms/hardware-tools-accessories/low-cost-motor-control-solution-for-devkit-platform:DEVKIT-MOTORGD?&fsrch=1&sr=1&pageNum=1 FreeMASTER Run-Time Debugging Tool FreeMASTER Run-Time Debugging Tool | NXP  Model-Based Design Toolbox https://www.nxp.com/design/automotive-software-and-tools/model-based-design-toolbox:MC_TOOLBOX?&&&code=MC_TOOLBOX&nodeId=0152109D3F12B8F6F8 Model-Based Design Toolbox for S32K14x Automotive MCU rev2.0  Model-Based Design Toolbox For Panther (MPC574xP) Family of Processors 2.0  Learning Model-Based Design Toolbox Motor Control Example Motor Control Class: Motor Control System Motor Control Class with Model-Based Design

Demo This is an ideal tri-radio system solution. The demo shows one board with 3 Wi-Fi radios. They are 2.4GHz, 5 GHz, 802.11AC working in conjunction with BLE devices, then running a virtual IoT network where different virtual machines will handle different parts of the processes. One of the virtual machines will handle all IoT communications (from the BLE devices). Another virtual machine will take care of the DLNA  (Video streaming to a wireless tablet) and the last virtual machine will run the firewall system. All data that is being transferred through the platform can be visually displayed on the GUI for each of the instances shown. Products Product Link QorIQ® LS1043A reference design board QorIQ® LS1043A-RDB | NXP  Freedom Development Kit for Kinetis® KW41Z/31Z/21Z MCUs https://www.nxp.com/design/development-boards/freedom-development-boards/wireless-connectivy/freedom-development-kit-for-kinetis-kw41z-31z-21z-mcus:FRDM-KW41Z?&fsrch=1&sr=8&pageNum=1 Training Containers 

Demo In this demo, we are showing an 802.11AD 60GHz Wireless Demo with 3Gbps throughput using two LS1046ARDB (ARM Cortex A72 Quad Core) gateways and an LS1012ARDB gateway. These gateways simulate communication between stations. Products Product Link QorIQ® Layerscape 1012A Low Power Communication Processor Layerscape LS1012A Communication Processor for the IoT | NXP  QorIQ® LS1012A Development Board https://www.nxp.com/design/qoriq-developer-resources/qoriq-ls1012a-development-board:LS1012A-RDB?&fsrch=1&sr=2&pageNum=1 QorIQ® Layerscape 1046A and 1026A Multicore Communications Processors QorIQ® Layerscape 1046A | NXP  QorIQ® LS1046A Development Board QorIQ® LS1046A Development Board | NXP  Training New Kid on the Block - 60 GHz Wi-Fi 

Demo Neural network classification method based on SqueezeNet. Images are captured by the camera processed and classified by the S32V processor and then displayed on the TV monitor with a confidence percentage calculated for each object visualized. Based on SqueezeNet, 501x fewer parameters than AlexNet Low power consumption - Less than 10 watts total Average top 1 accuracy of 58% and top 5 accuracies of 92% CNN built with APEX-DNN library Product Link S32V Vision and Sensor Fusion Evaluation Board https://www.nxp.com/design/development-boards/automotive-development-platforms/s32v-mpu-platforms/s32v-vision-and-sensor-fusion-evaluation-board:SBC-S32V234  S32V234 S32V234 Vision Processor | NXP 

Demo Watch as the i.MX 8 development vehicle takes data in from the camera and uses one GPU and applies an image segmentation algorithm. The info is then fed to another GPU dedicated to a neural network inference engine which recognizes the traffic sign Products i.MX 8 Series Applications Processors|NXP  Training i.MX 8 Applications Processors Family Overview: i.MX 8, i.MX 8X, i.MX 8M  i.MX 8M Processor Overview and the Road Ahead  Micron’s Memory Solutions for the New i.MX 8 Microprocessor   

Demo NXP’s new MRF13750H transistor delivers 750 W CW for 915 MHz applications. Based on 50 V silicon LDMOS, the MRF13750H is an attractive alternative to vacuum tubes for very high power industrial systems. Applications range from industrial heating/drying, curing, and material welding, as well as particle accelerators Product MRF13750H 750 W CW 915 MHz Applications Industry’s highest power for 915 and 1300 MHz 50 V LDMOS 915 MHz reference circuit 750 W CW Gain 19.5 dB Efficiency 63%