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 

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

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

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

This doc explain how to modify the bootloader to boot linux&mcal, to solve the conflict between bootloader, mcal and linux   本文说明在S32G2 RDB2板上如何定制开发Bootloader，本文示例主要实现功能是： Bootloader启动一个M核，MCAL驱动测试程序，本文分别测试了MCU，DIO，UART的MCAL驱动示例代码。 Bootloader同时启动A53 Linux 目录 1    需要的软件，工具，文档与说明... 3 1.1  软件与工具... 3 1.2  参考文档... 3 1.3  开发说明... 3 2    测试软件安装编译说明... 4 2.1  安装RTD_MCAL驱动... 4 2.2  编译MCAL驱动测试程序(以MCU为例) 5 2.3  优化重排M7 demo镜像及与MPU设置的配合... 5 2.4  去掉CLOCK INIT. 7 2.5  去掉MCU相关INIT. 8 2.6  DIO MCAL程序去掉PORT INIT. 9 2.7  UART MCAL程序去掉PORT INIT. 10 2.8  UART MCAL程序修改CLOCK TREE.. 10 2.9  解决中断冲突... 11 2.10 准备A53 Linux镜像... 12 3    Bootloader工程说明... 13 3.1  关掉XRDC支持... 13 3.2  关掉eMMC/SD支持(可选) 14 3.3  关掉secure boot(可选) 14 3.4  增加MCAL驱动所需要的PORT的初始化... 15 3.5  解决Bootloader,MCAL与Linux的clock冲突... 17 3.6  配置A53 Boot sources: 34 3.7  配置M7 Boot sources: 35 3.8  关闭调试软断点：... 36 3.9  编译Bootloader工程... 37 3.10 制造Bootloader的带IVT的镜像... 38 3.11 烧写镜像... 41 4    测试... 42 4.1  硬件连接... 42 4.2  MCU MCAL+Linux测试过程... 42 4.3  DIO MCAL+Linux测试过程... 43 4.4  UART MCAL+Linux测试过程... 43 5    Bootloader源代码说明... 43 6    Bootloader定制说明... 45 6.1  QSPI NOR驱动说明... 45 6.2  eMMC/SDcard启动支持... 46 6.3  DDR初始化... 46 6.4  Secure Boot支持... 46 7    调试说明... 46 7.1  Bootloader的调试... 46 7.2  MCAL驱动的调试... 46   add one more doc to explain how to modify atf to boot on G3.

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

Demo This demo showcases an OpenWRT based Thread Border router running on i.MX6UL and the various options to configure and use routing, firewall and out of band commissioning for Thread networks in combination with WiFi, Ethernet and NFC. OpenWRT is an open source Linux distribution for embedded devices specifically designed for residential gateways and routers. When enhanced with the Kinetis Thread protocol it offers the perfect solutions for creating a Linux based Thread Border Router Large and dense mesh network consisting in 64+ Thread nodes Each node is router capable, network decides dynamically which nodes become active routers Multiple application functionality run in parallel: Device addressing and identification Lighting demonstration with multicast Occupancy sensing demonstration Border Router with Network management web GUI   Features: Application layer communication based on generic CoAP framework CoAP messaging aligned with current ZigBee or OIC frameworks Kinetis KW2xD and Kinetis KW41 ARM Cortex-M4/M0+ MCUs with large on-board memory (up to 512KB flash/128 KB RAM) enable multiple applications to run on a common Thread IP network fabric. 1 i.MX6UL ARM Cortex-A7 with Kinetis KW2xD Linux Border Router used for interfacing with network management GUI Network management and interoperable Thread diagnostics framework used to monitor node state Nodes are enabled for OTA Updates _____________________________________________________________________________________________ Featured NXP Products: Product Link i.MX6UltraLite Evaluation Kit i.MX6UltraLite Evaluation Kit | NXP  Freedom Development Platform for Kinetis® KW2x MCUs FRDM-KW24D512|Freedom Development Platform|Kinetis | NXP  _____________________________________________________________________________________________

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

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

Explore the MC34937, an industrial-grade 3-phase gate pre-driver for BLDC and PMSM motor control. The MC34937 can support 12V, 24V, and 36V motor control applications and easily interfaces to standard MCUs and DSPs. The demo shows the implementation of the MC34937 with Kinetis Microcontrollers E in a 36V battery-operated electric bike (eBike) application. This same system can be modified to be used in other industrial applications such as electric garden tools, industrial fans and pumps, and electric wheelchairs. Features Demo shows capability of Kinetis KE02 connecting to an MC34937 Motor Driver MC34937 able to drive 12V, 24V, 36V, 48V systems Featured NXP Products Kinetis E - KE02Z64 MC34937 3-phase gate pre-driver Block Diagram MC34937 Schematics and Software:

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

This MQX demo re-uses the standard MQX web_hvac demo with the GT202 Wi-Fi module setup in SoftAP mode. This example shows MQX RTCS, DHCP server, and web server running in the Kinetis MCU with the Atheros drivers. The client will be able to connect to the Soft Access Point, receive an IP address, and then use a web browser to view the web_hvac web pages.  The User Guide is included in the ZIP file.

  Overview NXP digital signal controllers provide a switched-mode power supply solution that maximizes efficiency while reducing system costs through bill-of-materials savings. Our solution dynamically compensates for system disadvantages such as component aging and operational variability due to changing load conditions.   Reference Designs Product Name Link Features 3-Phase PMSM Control https://www.nxp.com/design/designs/3-phase-pmsm-control:PERMANENT-MAGNET-MOTOR The 3-Phase Permanent Magnet Synchronous (PMSM) Motor Control Reference Design is based on Kinetis V Series MCUs and intended to provide the example for 3-phase sensorless PMSM motor control solutions. The Reference design utilizes a closed-loop field-oriented vector speed (FOC) control mechanism. KV Series Full-Bridge DC-DC Switch Mode Power Supply (SMPS) https://www.nxp.com/design/designs/kv-series-full-bridge-dc-dc-switch-mode-power-supply-smps:FULL-BRIDGE-SMPS  Full Bridge DC-DC Switch Mode Power Supply   Block Diagram     Recommended Products   Category Products Features DSC Kinetis® V Series: Real-time Motor Control & Power Conversion MCUs based on Arm® Cortex®-M0+/M4/M7 | NXP  Kinetis V Series MCUs are based upon the Arm Cortex-M0+, Cortex-M4, and Cortex-M7 cores and are designed for a wide range of BLDC, PMSM, and ACIM motor control and digital power conversion applications. Temperature Sensor I²C Digital Temperature/Voltage Sensors | NXP  NXP I2C Temperature/Voltage monitors offer best-in-industry precision to fit any thermal management need.

Overview In the industrial world, it is critical to incorporate fail-safe technology where possible in applications such as crane steering machines, robotic lift, and assembly line robots to name a few. By doing so, you ensure you meet Safety Integrity Level (SIL) standards as found in the IEC 61508 standard. Also, you significantly increase human safety and protect products and property. This fail Safe Motor Control solution incorporates the MPC574xP family of MCUs that delivers the highest functional safety standards for industrial applications. The MPC574xP family incorporates a lockstep function that serves as a watchdog function to flag any problems with the MCU including a programmable Fault Collection and Control Unit (FCCU) that monitors the integrity status of the MCU and provides flexible safe state control. Also, this device is a part of the SafeAssure® program, helping manufacturers achieve functional safety standard compliance. Block Diagram Recommended Products Category Products Features Power Switch 12XS2 | 12 V Low RDSON eXtreme Switch | NXP  Watchdog and configurable Fail-safe mode by hardware Authentication time (on-chip calculations) < 50 ms Programmable overcurrent trip level and overtemperature protection, undervoltage shutdown, and fault reporting Output current monitoring Pressure Sensor MPXHZ6130A|Pressure Sensor | NXP  The MPXHZ6130A series sensor integrates on-chip, bipolar op amp circuitry and thin-film resistor networks to provide a high output signal and temperature compensation for automotive, aviation, and industrial applications. Temperature Sensor https://www.nxp.com/products/sensors/silicon-temperature-sensors/silicon-temperature-sensors:KTY8X High accuracy and reliability Long-term stability Positive temperature coefficient; fail-safe behavior MOSFET Pre-driver GD3000 |3-phase Brushless Motor Pre-Driver | NXP  Fully specified from 8.0 to 40 V covers 12 and 24 V automotive systems Extended operating range from 6.0 to 60V covers 12 and 42 V systems Greater than 1.0 A gate drive capability with protection Power Management and Safety Monitoring MC33908 | Safe SBC | NXP  Enhanced safety block associated with fail-safe outputs Designed for ASIL D applications (FMEDA, Safety manual) Secured SPI interface   Evaluation and Development Boards   Link Description MPC5744P Development Kit for 3-phase PMSM | NXP  The NXP MTRCKTSPS5744P motor control development kit is ideal for applications requiring one PMSM motor, such as power steering or electric powertrain. Evaluation daughter board - NXP MPC5744P, 32-bit Microcontroller | NXP  The KITMPC5744DBEVM evaluation board features the MPC5744P, which is the second generation of safety-oriented microcontrollers, for automotive and industrial safety applications

This application note explain how to run M kernel PFE master and A kernel PFE slave demo without bootloader support. chinese version: 在真实的产品中，一般会使用一个基于M7_0核的bootloader来启动M和A核，这个bootloader负责所有M核和A核资源的初始化，解决M核和A核的资源冲突，并且启动M和A核。所以理论上运行M PFE Master Mcal驱动加A PFE Slave Linux驱动也是需要一个bootloader的。参考文档《S32G_Bootloader_V*》，Johnli，可以在公开community上搜索获得。 本文讨论一种简易的办法，就是： S32G3 RDB3板子配置为SDcard启动，插入SDcard，里面放有PFE SLAVE驱动的Linux镜像。 上电启动后运行PFE Master工程的lauterbach调试脚本：run_main_G3_REV1_1.cmm，这个脚本会重启整个S32G3。 然后在脚本中用wait 10S的操作，这个时候Linux已经启动，并且使用Uboot的代码调用ATF来完成PFE相关pre-init, partition reset和时钟与管脚初始化(如上分析， EMAC0~2的RGMII IOMUX已经配置好)，然后Slave驱动会等待一段时间，等MCAL Master驱动加载，继续运行PFE Master MCAL代码后，Linux端Slave驱动也加载正确。然后就可以测试整个M Master/A Slave Demo。 总结：以上办法实际上是把bootloader应该做的PFE相关硬件初始化工作由Linux来完成，以便快速搭建Demo，这样客户在做真实的产品开发时，可以做为一个NXP release的标准参考。

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

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

I am using Adafruit LED stripes with 60 LED's per meter. Each LED integrates the W2812B controller. WS2812B uses a serial protocol, and you can control each LED individually. The strip is made of flexible PCB material, and comes with a weatherproof sheathing.   https://www.adafruit.com/products/1138   WS2812B is an intelligent control LED light source that the control circuit and RGB chip are integrated in a package.   The data transfer protocol use single NZR communication mode. After the pixel power-on reset, the DIN port receive data from controller, the first pixel collects initial 24bit data, then send to the internal data latch, the other data is sent to the next cascade pixel through the DO port.   LED's in cascade: My LED panel uses 16 rows x 30 columns = 480 leds.   In a first approach, in order to generate the bit stream, a timer in PWM mode could be used and generate two different duty cycles for sending a "0" logic or "1" logic. Using PWM's + DMA can unload the CPU in the generation of each single bit. FlexIO module in the Kinetis K82 can do that in a very effective mode and generate 8 channels simultaneously.   But my objective is to unload the CPU as much as possible in the bit stream generation task and find an easy method of multiplexing the 8 FlexIO outputs. In this way, we can control more LED rows and get a minimum number of interrupts and CPU intervention.   I will use the FlexIO internal data shifters to send the data bit stream. One shifter for each row. As we only have 8 shifters, I can use external multiplexor to increase the number of rows. Unloading the CPU for the LED refresh process, we can mux several rows in each shifter output. The limit of LED’s will be the refresh time of the full panel.   FlexIO block diagram:     How are the "1" and "0" generated?   Each pixel needs 24 bits of Red-Green-Blue value (RGB)   For each row, I need to send 30 x 24 bits of RGB information. But I have to encode the data in the NZR/PWM protocol. I use a lookup table to transform 24 bpp information in 24 x 3 = 72 bits per pixel.     In this way the  DMA can send 30 x 24 x 3 = 1440 bits (A full row)  in 60 transfers of 24 bits into the shifter. We get only one DMA interrupt for each row:       Multiplexer implementation:       Frame Buffer LED:   typedef union { uint32_t  rgb;     struct{       uint8_t  b;       uint8_t  r;         uint8_t  g;       uint8_t  a;     }bytes; }ledrgb;   Extended LED encoded data:   typedef struct {   uint32_t g;   uint32_t r;   uint32_t b; }ledrgb_ext;     Lookup Table:   void init_conv_matrix(void) { videoconv[0]=0x92492400; videoconv[1]=0x92492600; videoconv[2]=0x92493400; videoconv[3]=0x92493600; videoconv[4]=0x9249A400; videoconv[5]=0x9249A600; videoconv[6]=0x9249B400; videoconv[7]=0x9249B600; videoconv[8]=0x924D2400; videoconv[9]=0x924D2600; videoconv[10]=0x924D3400; ... };   Part 3: Software for LED Panel emulation Or Return to Project page: LED Panel control with FlexIO

Demo Owner: Derek Snell   This demo combines several solutions from NXP and our partners. The demo is a thermostat application, using the Kinetis family as a communication gateway between a ZigBee network and connecting to the cloud. The demo runs on the MQX Real-Time Operating System (RTOS). It also uses the NXP PEG graphics library for the user interface displayed on an LCD. The ZigBee communication uses NXP’s BeeStack ZigBee stack, and connects with an NXP wireless development board programmed as a remote temperature sensor. The demo will also connect with an off-the-shelf ZigBee light bulb, and wirelessly controls it. The demo network connection is setup for Wi-Fi, using a Wi-Fi module from Qualcomm. The cloud connection allows the thermostat to be monitored and controlled remotely with mobile devices, and uses a solution provided by deviceCloud.io.     NXP Products Product Link Shield Adapter Module for the Tower System Shield Adapter Module for the Tower System | NXP  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  Serial (USB, Ethernet, CAN, RS232/485) Tower System Module Serial (USB, Ethernet, CAN, RS232/485) Tower System Module | NXP  Graphical LCD Tower System Module with RGB Interface Graphical LCD Tower Module with RGB Interface | NXP    Design Resources Getting Started Guide Development Tools Thermostat Demo Software Firmware updated to v1.0 on 9/9/14      - DCIO Cloud agent now uses SSL from WolfSSL.  This improves WebSocket connections to cloud server through some protected networks. Firmware updated to v0.8 on 7/15/14      - Updated to support latest GT202 shield hardware from Qualcomm.  Rev 1.3 and newer boards changed pinout of CHIP_PWD signal. Firmware updated to v0.7 on 6/20/14      - Updated to use new SNTP server.  Previous server stopped responding and prevented cloud connection. Getting Started guide updated to v0.4 on 7/15/14