NXP Designs Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

NXP Designs Knowledge Base

Discussions

Sort by:
doc&project&patch&script explain to support GD qspi nor in lauterbach, flash tool,ivt,fls mcal, fls bootloader and linux/ chinese/english 目录 1    背景和参考资料... 2 1.1  背景说明... 2 1.2  参考资料... 3 1.3  硬件连接... 5 2    Lauterbach脚本驱动开发(可选) 5 2.1  准备参考脚本... 5 2.2  QuadSPI_ReadID.. 6 2.3  配置QSPI NOR为DOPI模式... 7 2.4  使用DOPI模式 READ_8DTRD.. 10 2.5  测试结果... 13 3    Flash tool算法镜像开发... 14 3.1  Flash SDK实现的算法... 15 3.2  开发新的flash源代码... 17 3.3  测试结果... 20 4    开发IVT参数头... 22 4.1  S32G QSPI控制器配置区别... 24 4.2  QSPI的配置区别... 28 4.3  测试结果... 29 5    开发MCAL Fls驱动... 30 5.1  MCAL Fls驱动工程说明... 30 5.2  FlsMem配置页... 34 5.3  MemCfg配置页... 35 5.4  测试结果... 49 6    开发Bootloader工程中Fls驱动... 51 6.1  Bootloader工程说明... 51 6.2  Bootloader与MCAL Fls驱动的不同点... 53 6.3  镜像打包... 54 6.4  测试结果... 56 7    开发Linux驱动(可选) 57 7.1  Linux GD驱动支持情况... 57 7.2  时钟相关的修改... 58 7.3  在DTS中增加GD flash的支持... 60 7.4  修改源代码增加flash信息结构体... 61 7.5  修改源代码中flash的fixup支持DTR模式... 62 7.6  Turning dummy值解决读错位的问题... 64 7.7  测试结果... 65   Content 1    Background and References. 2 1.1  Background. 2 1.2  References. 3 1.3  Hardware Link. 5 2    Lauterbach Script development(Optional) 6 2.1  Preparing the refer script 6 2.2  QuadSPI_ReadID.. 6 2.3  Configure QSPI NOR to DOPI mode. 8 2.4  Use DOPI mode  READ_8DTRD.. 11 2.5  Test report 13 3    Flash tool algorithm image development 15 3.1  Algorithms implemented by Flash SDK. 15 3.2  Develop new flash source code. 17 3.3  Test Report 21 4    Develop IVT Parameter Header 23 4.1  S32G QSPI Controllder configuration difference. 25 4.2  QSPI Configuration Difference. 30 4.3  Test Report 30 5    Develop MCAL Fls driver 31 5.1  MCAL Fls Driver Project Details. 31 5.2  FlsMem Configuration page. 35 5.3  MemCfg Configuration page. 36 5.4  Test Report 51 6    Develop Bootloader Project Fls Drivedr 52 6.1  Bootloader Project Details. 52 6.2  Difference of Bootloader and MCAL Fls Driver 54 6.3  Image Package. 56 6.4  Test Report 58 7    Develop Linux Driver(Optional) 59 7.1  Linux GD Driver Details. 59 7.2  Modification of Clock. 60 7.3  In DTS add GD flash Support 62 7.4  Modify source code and add flash information structure  63 7.5  Modify the fixup of flash in source code to support DTR mode  64 7.6  Turning Dummy Value to Solve the Misplacement Problem   66 7.7  Test Report 67
View full article
About this demo   Heads up! This article contains instruction updates due to changes in NXP's SDK and also on AWS website.   This demo will focus on the WIFI enablement and cloud connectivity through AWS by using MCUXpresso and an Amazon Alexa.   Amazon Web Services (AWS) is the world’s most comprehensive and broadly adopted cloud platform, offering over 165 fully-featured services from data centers globally. Millions of customers —including the fastest-growing startups, largest enterprises, and leading government agencies—trust AWS to power their infrastructure, become more agile, and lower costs. The LPC5500 used for this demo is the LPCXpresso55S69 development board which provides the ideal platform for evaluation of and development with the LPC55S6x MCU based on the Arm® Cortex®-M33 architecture. The board includes a high performance onboard debug probe, audio subsystem and accelerometer, with several options for adding off-the-shelf add-on boards for networking, sensors, displays, and other interfaces. The Alexa Skills Kit is a collection of self-service APIs, tools, documentation, and code samples that makes it easier to start building Alexa skills. Skills are like apps for Alexa, enabling customers to perform everyday tasks or engage with your content naturally with voice.   Block Diagram List of Products LPCXpresso55S69 WiFi 10 CLICK   Alexa Echo Dot USB A-to-Micro USB cable Step by Step Guides First, we need to create an account AWS and generate the “thing” that will be linked to the platform, this information can be followed step-by-step on this manual. Import AWS remote control WiFi Demo from the SDK Builder Select the LPCXpresso Board, click on the "Add software component" button, then select "Select All". Download the SDK Open MCU Xpresso and Import SDK examples, and then select the LPCXpresso 55 board and import into the aws_exaples find the aws_remote_control_wifi and also click on the UART for debugging. On the project find the amazon-freertos example, then demos and open the aws_clientcredential.h and change: The AWS IoT broker endpoint (Under thing settings “Interact” section) Write the “Things Name” And WiFi credentials. Replace the aws_clientcredential_keys.h with the one generated by the certification configuration tool from AWS, You can drag and drop it into the folder and then click overwrite. Build and download the application into your board. Video   External Links NXP Product Link LPCXpresso55S69 https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/general-purpose-mcus/lpc5500-cortex-m33/lpcxpresso55s69-development-board:LPC55S69-EVK WIFI 10 CLICK https://www.mikroe.com/wifi-10-click Amazon Web Services https://aws.amazon.com/?nc2=h_lg Alexa Skills Kit https://developer.amazon.com/en-US/alexa/alexa-skills-kit   Demo instructions update for 09/25/2020 Due to NXP's SDK updates, some file routes have changed inside the MCUXpresso project: The CertificateConfiguration Tool is located now on: SDKPackages\SDK_2.8.0_LPCXpresso55S69.zip\rtos\freertos\tools\certificate_configuration\ •Location of wifi_shield_silex2401.h \wifi_qca\port\shields\silex2401\wifi_shield_silex2401.h has changed location to wifi_qca\port\boards\lpcxpresso55s69\freertos\silex2401\wifi_shield_silex2401.h Additionally, there is now a clickboard define file available and these changes are already applied: #define BOARD_INITWIFI10CLICKSHIELD_PWRON_PIN 5U //Already done #define WIFISHIELD_WLAN_PINT_CONNECT (kINPUTMUX_GpioPort1Pin18ToPintsel) // IRQ Alexa_RC_json_skill.json.zip file changes:             AMAZON.StopIntent { "name": "AMAZON.StopIntent", "samples": [] },                
View full article
  Overview The NXP ®  Feature Phone reference design is designed to implement the Type 2 Feature Phone core. Includes support for on-hook GR-30 services such as Calling Number Delivery, Calling Name Delivery, Dialable Directory Number, Call Qualifier, and Visual Message Waiting Indicator Additional support for off-hook GR-30 services, such as Calling Identity Delivery on Call Waiting and Call Waiting Deluxe The Feature Phone reference design also includes a full duplex echo-cancelling speakerphone with solid sound quality; the demo is able to originate and terminate a call in full duplex speakerphone mode A HyperTerminal will be used to display the GR-30 messages Archived content is no longer updated and is made available for historical reference only.   Features DSP56858EVM and 5685X Digital Signal Controllers Telephony Daughter Card (TDC1) Microphone AKG Acoustics Type Q400Mk3, Code 2846Z003 Directional Mono Electret condenser microphone Use with Radio Shack adaptor: Stereo -to-Mono Headphone adapter number 274-374 Amplified Speaker On-Hook Data Transmission Protocol (GR-30-CORE) - CID_T1.DSP software module Adaptive Line Echo Canceller (SR-3004) - ALEC.DSP software module Off-Hook Data Transmission Protocol (SR-3004) - CIDCW_T2.DSP software module Acoustic Echo Cancellation Keypad LCD     IDE and Build Tools CodeWarrior® Development Tools for 56800/E DSC | NXP  Design Resources https://www.nxp.com/downloads/en/schematics/TDC1LD.zip
View full article
  Overview   NXP provides full solutions to power high-end payment terminals. NXP is at the forefront of contact and contactless payment solutions and is a leader in providing security solutions for the banking and payment industries. Combining NXP's portfolio of microprocessors, microcontrollers, interface peripherals and connectivity solutions can help to create a feature rich and easy-to-use payment terminal or tablet solution.   Block Diagram     Recommended Products   Category Name MCU Arm® Cortex®-M4|Kinetis K81 150 MHz 32-bit MCUs | NXP  Arm® Cortex®-M4 core + DSP up to 150 MHz, 16 kB CPU CacheAdvanced public key crypto and tamper detection. Low-power peripherals and DMA for continuous system operation in reduced power stat. Ideal for entry level, highly secure POS terminals. i.MX 6UltraLite Applications Processor | Single Arm® Cortex®-A7 @ 696 MHz | NXP  Cortex-A7 @ 696 MHz, 128 kB L2 cache. Security Block: TRNG, Crypto Engine (AES with DPA, TDES/SHA/RSA), Tamper Monitor, Secure Boot, SIMV2/EVMSIM X 2, OTF DRAM. Encryption, PCI4.0 precertification. Ideal for high-end, high-quality HMI POS terminals. LPC55S6x|Arm® Cortex®-M33|32-bit Microcontrollers (MCUs) | NXP  Cortex-M33 processor, running at a frequency of up to 100 MHz. Security features: Arm TrustZone, PRINCE module, AES-256, SHA2, Physical Unclonable Function, RNG, 128-bit UUID, and Secure GPIO. Ideal for entry level, highly secure POS terminals.   Category Name NFC Contact Readers | NXP  Highly versatile family of ISO7816 compatible contact reader ICs. NFC - Near Field Communication | NXP  Wide range of NFC and reader ICs for physical access systems, POS terminals, PC solutions, eGovernment applications, public transport schemes, Pay TV solutions, eMetering, gaming, industrial and white goods applications. PN5180 | Full NFC Forum-compliant frontend IC | NXP  Optimized for POS terminal applications, allows to achieve compliancy to EMVCo 3.0 analog and digital and implements a high-power NFC frontend.   Category Name Power Management DC-to-DC Solutions | NXP  Highly integrated and cost-effective power conversion solution. BC3770 | 2 A Switch-Mode Li-ion/polymer Battery Charger | NXP  Power Supplies and Package Programmable charge parameters via I2C compatible interface High-efficiency synchronous switching regulator Extensive protection Power Management Integrated Circuits (PMICs) | NXP  The new PF series of PMICs brings advanced levels of configurability and programmability in a system level PMIC solution, enabling a single device to be easily configured to provide power to a wide range of processors and peripherals.   Category Name Secure Arm® Cortex®-M0+|Kinetis KL8x Ultra-Low Power MCUs | NXP  The K8x Arm® Cortex®-M4 MCUs are designed with expandable memory & advanced security capabilities targeting IOT applications such as payment & identification. Kinetis® K8x Secure Microcontrollers (MCUs) based on Arm® Cortex®-M4 Core | NXP  The K8x Arm® Cortex®-M4 MCUs are designed with expandable memory & advanced security capabilities targeting IOT applications such as payment & identification.   Category Name Peripheral I²C LED Controllers ICs | NXP  Our I2C LED controllers enable core functions in some of today’s most ubiquitous devices and applications. Load Switches | NXP  Integrated Type C functionality, Fast Reverse Current Protection and Recovery, High Voltage Tolerance. Bluetooth®Smart/Bluetooth Low Energy | NXP  Highly integrated SoCs with up to 512 KB Flash and 128 KB RAM utilizing Arm® Cortex®-M4F cores. Ultra-low-power, 1.8 V, 1 deg. C accuracy, digital temperature sensor with I2C bus interface | NXP  Tiny WLCSP6 package Accuracy: 0.5 °C from 0 °C to +85 °C Low quiescent current: 30 μA Active and 1 μA Shut-down Supply range: 1.8 V ± 0.15 V Resolution: 12 bits
View full article
本文说明S32G HSE On-demand SMR验证的应用方法,本文演示的示例应用为: Secure Bootloader对Linux Bootloader fip.bin的验证 目录 1    背景说明与参考资料... 2 1.1  背景说明... 2 1.2  参考资料... 3 2    S32G On-demand SMR Verification说明... 4 2.1  SMR Verify的说明... 4 2.2  On-demand SMR Verify. 4 3    环境搭建... 5 3.1  EB配置说明... 5 3.2  ATF编译说明... 8 3.3  镜像烧写... 9 4    Bootloader代码开发... 9 4.1  OnDemand SMR install 9 4.2  OnDemand SMR verify. 13 5    测试... 16 5.1  Lauterbach跟踪... 17 5.2  Fip.bin破坏实验... 19 5.3  硬件确认... 19   This application doc explains the application method of S32G HSE On_demand SMR verification. The example application demonstrated in this doc is: Secure Bootloader verification of Linux Bootloader fip.bin This application doc explains the application method of S32G HSE On_demand SMR verification. The example application demonstrated in this doc is: Secure Bootloader verification of Linux Bootloader fip.bin Contents 1    Background Description and Reference Materials. 2 1.1  Background Description. 2 1.2  Reference Materials. 3 2    S32G On-demand SMR Verification. 4 2.1  SMR Verify. 4 2.2  On-demand SMR Verify. 4 3    Build the Development Environment 5 3.1  EB Configuration. 5 3.2  ATF Compiling. 8 3.3  Burn Image. 9 4    Bootloader Codes Development 9 4.1  OnDemand SMR install 9 4.2  OnDemand SMR verify. 13 5    Testing. 16 5.1  Lauterbach Tracking. 16 5.2  Fip.bin Broken Test 19 5.3  Probe the Hardware. 19
View full article
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
View full article
Overview This reference design describes the design of a 3-phase BLDC (Brushless DC) motor drive, which supports the NXP® 56F80X and 56F83XX Digital Signal Controllers (DSCs). The speed-closed loop BLDC drive using a Hall sensor is implemented The system is targeted for applications in both industrial and appliance fields (e.g. washing machines, compressors, air conditioning units, pumps or simple industrial drives required high reliability and efficiency) Features Voltage control of BLDC motor using Hall sensor Targeted for 56F80X, 56F83XX, and 56F81XX Digital Signal Controllers Running on 3-phase Motor Board Control technique incorporates: Voltage BLDC motor control with speed-closed loop Current feedback loop Both directions of rotation Motoring mode Minimal speed 500 RPM Maximal speed 1000 RPM (limited by power supply) Manual interface (Start/Stop switch, Up/Down push button control, LED indication) FreeMASTER software control interface (motor start/stop, speed set-up) FreeMASTER software monitor Block Diagram Board Design Resources
View full article
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
View full article
Overview The reference design demonstrates sensorless control of the 3-Phase Switched Reluctance (SR) motor using 56F80x or 56F83XX Digital Signal Controllers. It can also be adapted to 56F81XX Digital Signal Controllers. The concept of this application is that of a sensorless speed closed loop SR drive using flux linkage position estimation. An inner current loop with PI controller is included. The change in phase resistance during motor operation due to its temperature dependency creates errors in the position estimation and significantly affects the performance of the drive. Therefore, a novel algorithm for on-the-fly estimation of the phase resistance is included. The Digital Signal Controller runs the main control algorithm. Rotor position is evaluated using the sensorless flux linkage estimation algorithm. The actual flux linkage is calculated at the rate of the PWM frequency and is compared with the reference flux linkage for a given commutation angle. When the actual flux linkage exceeds the reference, the commutation of the phases is done; the actual phase is turned off and the following phase is turned on. Flux linkage error is used for estimation of the phase resistance at low speeds (US Patent No.: 6,366,865). The actual speed of the motor is determined using the commutation instances. Based on the speed error, the speed controller generates the desired phase current. When the phase is commutated, it is turned on with a duty cycle of 100%. Then, during each PWM cycle, the actual phase current is compared with the desired current. As soon as the actual current exceeds the desired current, the current controller is turned on. The current controller controls the output duty cycle until the phase is turned off (following commutation). Finally, the 3-Phase PWM control signals are generated. The procedure is repeated for each commutation cycle of the motor. Features Sensorless control of an SR motor using a flux linkage estimation technique Targeted for 56F80X, 56F83XX, and 56F81XX Digital Signal Controllers Running on a 3-Phase SR HV Motor Control Development Platform The control technique: current control with a speed closed loop Position estimation based on flux linkage estimation Phase resistance measurement during start-up Phase resistance estimation at low speeds Motor starts from any position with rotor alignment Encoder position reference for evaluation of sensorless position estimation Manual interface FreeMASTER software control interface and monitor Fault protection Block Diagram Board Design Resources
View full article
Overview This reference design enables development of a vector control algorithm for a three-phase AC induction motor implemented on NXP® digital signal controllers MC56F8013/MC56F8023. Targeted mainly at consumer and industrial applications Cost-effective and highly reliable, the algorithm implements a single shunt current sensing, eliminating the need for more than one sensor High range of motor operating speeds up to 18000RPM An adaptive closed loop rotor flux estimator enhances control performance and increases the overall robustness of the system A reference manual provides a detailed description of the application, including a design of hardware and software Features 3-phase AC induction motor drive Designed to fit into consumer and industrial applications Uses 56F8013 or 56F8023 32 MIPS Digital Signal Controller Running on a 3-phase High Voltage Power Stage Control technique incorporating: Vector control of three-phase AC induction motor with position encoder Closed-loop speed control Both directions of rotation Both motor and generator modes Reconstruction of three-phase motor currents from DC-Bus shunt resistor Closed loop current control Flux and torque independent control Adaptive rotor flux space-vector estimator Field-weakening for high speeds High-speed range, max speed – 18000 RPM (2-pole motor) FreeMASTER software control interface (motor start/stop, speed setup) FreeMASTER software monitor FreeMASTER software graphical control page (required speed, actual motor speed, start/stop status, DC-Bus voltage level, motor current, system status) FreeMASTER software speed scope (observes actual and desired speeds, DC-Bus voltage and motor current) FreeMASTER software high-speed recorder (reconstructed motor currents, vector control algorithm quantities) DC-Bus overvoltage and undervoltage, overcurrent protection Block Diagram Board Design Resources
View full article
        S32G just support serial download a M7 image to run by internal rom codes, our S32G DS IDE have a flash tools to use this feature to burn the image to external device. So current image burn method will divide into 2 step: 1: burn a uboot into the external device by S32G DS flash tools. 2: reboot the codes with uboot and run with network to burn the linux image into external device.      which need two working place on manufacture line, and customer wish to have a one time on-line tools, which means we need use serial port to boot uboot directly but S32G rom codes do not support it.       We have a reference tools of S32V but which IP difference is big between on S32V and S32G, So we can not reuse it and have to develop a new one.       The development working include: 序号 开发工作 说明 开发者 1 开发 根据S32G的serial boot协议要求,开发PC端的串口工具来下载M7镜像 John.Li 2 开发 根据自定义协议要求,开发PC端的串口工具来下载A核Bootloader到SRAM中 John.Li 3 开发 根据自定义协议要求,开发M7镜像的串口接收与Checksum逻辑 John.Li 4 开发 修改M7镜像支持串口0 John.Li 5 开发 开发实现M7镜像的串口单字节同步收发函数 John.Li 6 开发 开发实现A53启动功能 John.Li 7 调试与Debug 调试解决串口接收乱码问题(Serial boot rom codes仍然在回送消息串口) John.Li 8 调试与Debug 提供 解决A核启动串口halt思路(Serial boot rom codes仍然占用串口) John.Li 9 调试与Debug 优化M7镜像,缩小大小 Tony.Zhang 10 调试与Debug 根据M7镜像和A核 Uboot在SRAM中的内存分配要求,重排M7镜像位置,避免冲突 Tony.Zhang 11 调试与Debug 在M7中初始化SRAM空间 Tony.Zhang 12 调试与Debug 在M7中设置SRAM可执行空间 Tony.Zhang 13 调试与Debug 调试解决由于cache没有及时回写导致的下载镜像错误的问题 Tony.Zhang 14 调试与Debug 集成,调优与文档 John.Li   Pls check the attachment for the doc/codes/binary release which include:    Release      |->M7: Linflexd_Uart_Ip_Example_S32G274A_M7: S32DS M7工程。      |->PC: s32gSerialBoot_Csharp: PC端的Visual Studio的C#的串口工具工程。      |->Test:      |    |-> 115200_bootloader.bin: S32DS M7工程编译出来的bin文件,波特率为115200      |    |-> 921600_bootloader.bin: S32DS M7工程编译出来的bin文件,波特率为921600      |    |->load_uboot.bat: 运行工具的批处理文件,运行成功后打开串口可以看到Uboot执行,默认使用的波特率是115299         |    |->readme.txt:其它测试命令 |    |->s32gSerialBoot.exe:编译出来的PC端串口工具 |    |->u-boot.bin: BSP29默认编译出来的u-boot.bin.      Product Category NXP Part Number URL Auto MPU     S32G274     https://www.nxp.com/s32g    
View full article
NFC Tandem offers best of both worlds: An NFC reader and a passive connected tag sharing one antenna. A user can interact with the device when it is powered off (through the NTAG I²C plus); when the device is powered, it can interact with cards, P2P devices or other connected tags.                                                             NFC Tandem Uses Cases and Applications: One-touch pairing WiFi with phone, or card Bluetooth with phone, headset, speaker IoT network node commissioning User identification with badge or phone Authentication and configuration of consumable and accessory Zero-power parametrization Zero-power firmware update Zero-power diagnosis and maintenance NFC Tandem Demo: NFC Tandem concept is demonstrated using NFC Tandem reference board: The demo can run on either: UDOO Neo Download UDOO Neo demo image or Raspberry Pi Download Raspberry Pi demo image Video of the demo: <script src="https://players.brightcove.net/6153537070001/default_default/index.min.js"></script>(view in My Videos) NFC Tandem References: PN7150 High performance NFC controller, supporting all NFC Forum modes, with integrated firmware and NCI interface NTAG I²C plus NFC Forum Type 2 Tag with I²C interface NFC Tandem Documents: User Manual and reference schematics are attached to this document
View full article
  Overview Near Field Communication (NFC) is used for real-time precision marketing based on time, local inventory and the individual when embedded in product displays or the products themselves. NFC is also becoming the preferred method for payment either in smartphones or smart payment cards. In this particular deployment , the overall system consists of Backend Servers, Top Up station and Household Meter. The Backend Server roles are to activate the new installed meter, to collect meter usage data and behaviors, to implement new tariff based on user behaviors, and to allocate energy usage in effective way. Top Up Stations are NFC Reader with SAM and they are connected to local Computer, Tablet or Mobile phone. They are located at retailers near by household to ease the user to buy the credits. Besides that, Top Up Station is also help to upload and download settings or parameter from the Backend Server Household Meters are those Contctless Prepaid Meter has been installed at end user Block Diagram Products Category MCU Product URL KM3x: 50–75 MHz Precision Metrology MCUs with Segment LCDs based on Arm® Cortex®-M0+  Product Description The KM3x MCU family enables single-chip one-, two-, and three-phase electricity meters, as well as flow meters and other precision measurement applications.   Category NFC Fronted Product URL CLRC663 plus family: High-performance NFC frontends  Product Description If you need high NFC performance or the lowest power consumption, use this remarkably efficient yet highly flexible frontend family to push your design further.   Category RTC Product URL PCF8563: Real-time clock/calendar  Product Description The PCF8563 is a CMOS Real-Time Clock (RTC) and calendar optimized for low power consumption.   Category Secure Element Product URL A71CH: Plug and Trust - The fast, easy way to deploy secure IoT connections  Product Description A71CH is a ready-to-use secure element for IoT devices providing a root of trust at the IC level and delivers, chip-to-cloud security right out of the box, so you can safely connect to IoT clouds and services, including AWS, IBM Watson IoT™ Platform, and Google Cloud™ IoT Core without writing security code or exposing keys.   Category Power Management Product URL TEA1721BDB1065: TEA1721 Universal Mains White Goods Flyback SMPS Demo Board  Product Description This reference design demonstrates the TEA1721 as a -12 V and -3.3 V AC/DC SMPS converter that can provide 5 W into a load.   Category Smart Card Product URL 1 MIFARE® DESFire® EV3: High-Security IC for Contactless Smart City Services  Product Description 1 The features of the MIFARE DESFire EV3 IC reflect NXP’s continued commitment to secure, connected and convenient contactless Smart City services. Product URL 2 MIFARE Plus® EV2: Secure IC for Contactless Smart City Services  Product Description 2 As the next generation of NXP’s MIFARE Plus product family, the MIFARE Plus EV2 IC is designed to be both a gateway for new Smart City applications and a compelling upgrade, in terms of security and connectivity, for existing deployments.
View full article
Overview This NXP® reference design of a 3-phase sensorless PMSM vector control drive with a sliding mode observer (SMO) is targeted mainly for compressor control and other consumer and industrial applications. This cost-effective solution uses the NXP MC56F8013 device dedicated for motor control. Software written in C-code using some library algorithms Available for the MC56F8013 and MC56F8346 digital signal controllers Hardware-based on the NXP universal motor control h/w modules Features The system is designed to drive a three-phase PM synchronous motor. Application features are: 3-phase sensorless PMSM speed vector control (FOC) Sliding mode observer with adaptive velocity estimation Based on NXP ®  MC56F8013 (resp. 56F8346) controller Running on a 3-phase high voltage (230/115V) power stage FreeMASTER software control interface and monitor Block Diagrams Design Resources
View full article
Overview The 3-phase PMSM Vector Control using Quadrature Encoder on based on Kinetis® K40 MCUs reference design demonstrates the ability of the Kinetis K40 Arm® Cortex®-M4 MCU to drive the advanced motor control application. Targeted at the NXP® Tower® rapid prototyping system as a hardware development platform. Together with available embedded source code, you can quickly build own industrial drive application. For the successful execution of the vector control algorithm, the information on the motor shaft position is critical. The quadrature encoder position information is known in the entire motor speed range, allowing the motor start with full torque at zero speed. Features Vector control of the PMSM using the quadrature encoder as a position sensor Targeted at the Tower ®  rapid prototyping system (K40 tower board, Tower 3-phase low voltage power stage) Vector control with a speed closed loop Rotation in both directions Application speed range from 0% to 100% of nominal speed (no field weakening) Operation via the user buttons on the Kinetis ®  K40 Tower board or via FreeMASTER software Block Diagram Design Resources
View full article
This doc explain how to compile PFE driver into kernel to accelerate the network boot time, chinese version: 目录 1    需要的软件,工具与文档... 2 2    目前PFE驱动的情况... 2 3    将PFE Slave驱动编译进内核... 3 3.1  将PFE驱动代码加入内核... 3 3.2  开发Makefile文件... 6 3.3  编译与测试... 8 4    将PFE Master驱动编译进内核... 10 4.1  编译Master工程... 10 4.2  测试... 11 4.3  解决FW的加载问题... 11 Contents 1    Related Materials. 2 2    Current PFE Driver 2 3    Compiled PFE Slave into Kernel 3 3.1  Put the PFE driver source into kernel source. 3 3.2  Develop the Makefile. 6 3.3  Compilation and Testing. 8 4    Compiled PFE Master Driver into Kernel 10 4.1  Compiling the Master driver 10 4.2  Testing. 11 4.3  Solve the FW loading fail issue. 11    
View full article
This post entry provides a detailed description of how to port the NFC Reader Library to Kinetis K64F MCU. It is used a real porting example exercise to show the steps required to adapt the NFC Reader Library to a sample target MCU. The goal of this post is to serve as a guide for software developers requiring to port the NFC Reader Library to their MCU of choice for their designs. NFC Reader Library overview The NFC Reader Library is a software stack for creating and developing contactless applications for NXP’s NFC frontends and NFC controllers with customizable firmware. This library provides an API facilitates the most common operations required in NFC applications such as: reading or writing data into contactless cards, exchanging data with other NFC-enabled devices or emulating cards. The NFC Reader Library: It is based on a modular approach It has been designed with a flexible and multilayered architecture It is written in ANSI-C programming language It is supported in multiple design environments and platforms and it has been developed with a strong focus on portability. It is available for free download. The NFC Reader Library v5.02.00 currently supports: All our NFC frontends (CLRC663 plus PN5180) and PN7462 NFC controller. Their corresponding development boards, used as NXP reference HW (CLEV6630B, PNEV5180B, PNEV7662B) And built-in MCU support for LPC1769, LPC11U68, FRDM-K82F and Raspberry Pi. In addition, the release includes several examples to get familiar with the library and which can be used as reference for your developments and, it is also included an HTLM-based API documentation for all the components, which is generated from source-code annotations. NFC Reader Library architecture The NFC Reader Library is encapsulated into layers, differentiated by colors, and components, differentiated in boxes. From top to bottom, we have: The Application Layer (AL), which implements the command sets to interact with MIFARE cards and NFC tags. The NFC activity, which implements a configurable Discovery loop for the detection of contactless cards, NFC tags or other NFC devices. Next to it, the HCE and P2P components, for the emulation of Type 4 tags and P2P data exchange respectively. The protocol abstraction layer (PAL), which contains the RF protocol implementation of the ISO14443, Felica, vicinity and NFC standards. One level down, the hardware abstraction layer (HAL), which implements the drivers for controlling the NFC frontends RF interface and capabilities. Below, the Driver Abstraction Layer (DAL), newly introduced in the latest release, which implements the GPIO pinning, the timer configuration and the physical interface (BAL) between the host MCU and the reader IC. Finally, the OSAL module, in charge of abstracting the OS or RTOS specifics (handles tasks such as timers, events, semaphores and threads) This layered architecture is helpful for several reasons: The eleven software examples, the Application Layer (AL) and the Protocol Abstraction Layer (PAL) are HW-independent, so that can be used on top of any NFC frontend. The the Application Layer (AL), the Protocol Abstraction Layer (PAL) and the Hardware Abstraction Layer (HAL) are platform-independent, so that can run in any MCU without any additional change. In case the reader MCU is part of the built-in support, the examples can be directly imported and executed straight forward. On the other hand, in case the reader MCU is not supported by default, the major advantage is that only adaptations in the DAL and OSAL layers are required, while the rest of the layers can be used without any modification. The NFC Reader Library structure can be seen more clearly when imported in the MCUXpresso development environment. After completing the import wizard, all projects are listed in the “Project Explorer” window. As can be seen in the screenshot, it contains different folders: API documentation folder Driver Abstraction Layer FreeRTOS support The platform support (in the screenshot, corresponding to the LPC support) The software examples (11) The Reader Library implementation And the OS abstraction layer NFC Reader Library porting to FRDM-K64F steps In the existing NFC Reader Library v5.02.00 release there is no native support for Kinetis K64F. However, it is included a pre-compiled package for Kinetis K82F MCU. We use the K82F NFC Reader Library package as a reference project to start the porting to K64F MCU. This package can be downloaded from www.nxp.com/pages/:NFC-READER-LIBRARY. The steps required to port the library to Kinetis K64F are: Prearing the HW (i.e the pining between the Kinetis and the NFC reader board). Setting up the development environment (i.e workspace). Perfoming some changes in project configuration settings Performing some code modifications in the DAL and application code for adding Kinetis K64F support. NFC Reader Library porting to FRDM-K64F - Preparing the hardware The hardware used for this porting exercise is: A CLEV6630B board (CLRC663 plus) as an NFC transceiver  A FRDM-K64F board (Kinetis K64F) as host MCU, used to load and run the application logic. The CLRC663 plus evaluation board is connected by default to an LPC1769 µC via SPI. However, the board is made in such a way that the LPC1769 MCU can be bypassed to connect an external MCU easily. For doing so: Six resistors from the board need to be removed. These are highlighted in red. Use the SPI pin connectors available on the left hand side, on the board edge. Next, to connect the two boards together, the pining routing was done as follows: We use the Kinetis K64F jumper 2 pin line for the MOSI, MISO, chip select and clock lines of the SPI communication. The IRQ, interface selection and reset pins of CLRC663 plus are connected in jumper 1 pin line. And, one ground pin used for reference. Therefore no complex HW manipulation was required since all interfaces are easily accessible via dedicated headers or test points. NFC Reader Library porting to FRDM-K64F - Setting up the development environment Once the HW connection is prepared, we can move to setting up the development environment and workspace. Get the latest NFC Reader Library release From the software perspective, first we need to download the latest NFC Reader Library package. To do so: Go to NXP dot com slash pages slash NFC Reader Library (www.nxp.com/pages/:NFC-READER-LIBRARY) Go to the Downloads tab and click on the download button Click download on the NFC Reader Library for Kinetis K82Fpackage. Generate a downloadable SDK package for FRDM-K64F board As part of the NXP support, an SDK with drivers, middleware, RTOS demos and more is available for any of its Kinetis and LPC micros.We need to build the corresponding one to K64F SDK. For that: Navigate to www.mcuxpresso.nxp.com and select SDK builder option. Then, use the drop-down menus to customize your SDK configuration, middleware and optional software components be included in the package. Select Request build. In a few minutes, you will receive an email with a link to download the SDK package, very similar to the one showed in the figure below. Import the NFC Reader Library into MCUXpresso workspace Next step to configure the development environment is to import the library package in the workspace. The easiest way is to use the Quick Start Panel on the left hand side. Click on Import project from file system Then, browse the library package in your file system. Click Finish to import it all to your workspace. Install and link FRDM-K64F SDK into MCUXpresso workspace The last step is to import the K64F customized SDK we configured from the MCUXpresso tools. To do so: Just drag and drop the SDK into the installed SDKs tab of the MCUXpresso IDE. (It will appear in the bottom part, in the center) Import the SDK into the workspace and link it with the software examples. It will appear as another folder in the project explorer window. If the K64F SDK has been properly imported in the workspace, we should see a new drop-down menu for K64F. From there, we should select K64F and click Apply so that the memory details for K64F are set to the project example NFC Reader Library porting to FRDM-K64F - Project configuration changes At this point we have the hardware and the workspace for software development ready. In this step, we will start porting the NfcrdlibEx1_BasicDiscoveryLoop  software example provided as part of the NFC Reader Library release. Select FRDM-K64F SDK in the project MCU settings One of the first configurations to be changed is the project MCU settings. These settings indicate which target host device is running the application code. These settings can be found if: You right click on the project example > Properties In the left-hand list of the Properties window, open “C++ build” and select “MCU settings” In the right-hand panel, we can observe the corresponding settings for K82F micro. The left figure indicates the project configuration settings used by the default SW example prepared for K82F while the right figure indicates the final project configuration settings used by the SW example ported to K64F. Define FRDM-K64F SDK preprocessor symbols in the project After that, we need to change the compiler preprocessor settings, which can be found in C++Build > Settings. In the project examples of the NFC Reader Library, the conditional directives like #ifdef and #ifndef are used to include or exclude portions of the code from the actual compilation. The conditional codes are included in the program compilation only if the MACROs are defined in the project compiler preprocessor settings. In the left side we can see the defined macros for the original project. Among them, includes one which defines that the HW used is PN518 and K82F board. Therefore, in the ported project, we need to replace the macros corresponding to K82F with the new ones corresponding to K64F.  For instance, the PHDRIVER_K64_CLRC663 macro includes in the compilation the files related to the new HW used in the ported project (for the board pin and GPIO config, SPI settings or timers). Precisely, these files are included inside BoardSelection.h file in the Driver Abstraction Layer (DAL). Add include paths for FRDM-K64F SDK files When including header files into our project, the compiler must be told which directories must be searched to find those files. To do this: Open the project properties. In the left-hand list, open “C++ Build” and Select “Settings”. In the right-hand pane, choose the “Includes” section. Click the “Add icon”. In the left figure, we see the compiler include paths for the K82F SDK of the original example. In the ported example, the K64F SDK sources will not yet compile since we did not tell the compiler about all the new include paths. Therefore, we need to add the new include paths pointing to the K64F SDK and put them into the MCUXpresso IDE project. In the right figure, you can see the paths we included for this purpose. Mainly, these paths reference to the board system init, board drivers, CMSIS files and debug utils. Add include path for FRDM-K64F MCU assembler The last MCUXpresso settings to be changed is in the MCU Assembler. This can be found in the right-hand panel, choose the “MCU Assembler” and select “General”. In the original source code, a path is used to the K82F SDK. In the ported example, we just need to remove the previous include path and replace it with the corresponding one pointing to the K64F SDK in our workspace. NFC Reader Library porting to FRDM-K64F - Code changes So far, we have the HW, the development environment prepared and the project configuration settings changed. At this point, there are only a few code changes to be done before the porting is completed and the software example can be run in K64F. DAL driver adaptation for FRDM-K64F The layered architecture of the NFC Reader Library makes porting easier since only the lower drivers need to be adapted. This driver includes functions for: The physical link connection establishment between the CLRC663 plus and K64F The init functions for timers and interrupts so they are correctly used by the application layer. Going to the NfcrdlibEx1-BasicDiscovery loop project structure, it contains several folders. If we open the DAL > board folder, we can observe one source file per each supported platform (LPC with PN5180 and CLRC663, and the same for Raspberry Pi and Kinetis K82F). Our task for the porting would be to create an equivalent source file for the new supported board, the K64F together with the CLRC663 (e.g. Board_FRDM_K64FRc663.h). This file includes The related board pin and GPIO configurations The SPI configuration The timer configuration In addition, we need to include the board, pin_mux and clock config files. Use SDK examples to get FRDM-K64F board specific configuration Implementing these board specific files, in some cases, could be time consuming and may require experience. However, you do not need to do so but rather use the existing source files. For that, you can use any of the existing SDK software examples. You can easily import one SDK example by: Clicking the “Import SDK” example in the quick start menu > select the FRDM-K64F board. Selecting the demo example. Each example application has its own unique copy of the board, pin mux, and clock config files that you can reuse for the porting (Note: this process could be different depending on the MCU used). Add FRDM-K64F macro definitions in the source code Next, along the project tree, we need to add the #ifdef directives, indicating that K64F board files that need to be compiled. This is the case for: The BoardSelection.h file The ph_NxpBuild_App.h, which links the board with the reader IC by enabling the CLRC663 plus module in the HAL layer. The ph_AppInit.h so that the board is initialized when the reader device boots. Add FRDM-K64F CPU initialization code The ph_AppInit.h  file takes care of the code initialization and code specific to the HW used to run the example. As part of this ph_AppInit.h file, there is a function in charge of initialization the host MCU. Here, we need to implement the corresponding function for the K64F init, based on the SDK example source code selected earlier. If we look within this routine, we actually find functions for: Configuring the MCU clocks. Configuring the MCU pins. Configuring the interrupts (PIT). NFC Reader Library porting to FRDM-K64F: NfcrdlibEx1_BasicDiscoveryLoop execution After following the previous steps, the source code is succesfully ported to K64F. The following video demonstrates the correct execution of the NfcrdlibEx1_BasicDiscoveryLoop example in FRDM-K64F host MCU connected to CLRC663 plus NFC frontend (CLEV6630B). The video includes a webcam, which records the HW, including all the witing wiring between the K64F and the CLRC663 plus antenna. After the code is built and compiled, the video shows how some tags are tapped to validate that the example is working as expected (tag's UIDs are displayed in the MCUXpresso console). . General considerations to port the NFC Reader Library to your target MCU Overall, the general steps required to port the NFC Reader Library to your target MCU are: Adapt the MCU drivers to the DAL layer in the NFC Reader Library. This typically includes: timers, interrupts, pining and host interface configuration between the NFC reader and host MCU sides. Adapt the OS layer (i.e. you might need to port the FreeRTOS or to your target OS platform). Adapt the source code examples: project settings (macros, include paths, MCU configuration) and perform the required code modifications (Code for HW initialization, board files, etc). Available resources NFC Reader Library:  www.nxp.com/pages/:NFC-READER-LIBRARY CLRC663 plus: www.nxp.com/products/:CLRC66303HN CLRC663 plus development kit: www.nxp.com/demoboard/OM26630 FRDM-K64F board: www.nxp.com/demoboard/FRDM-K64F Video recorded session
View full article
Linux kernel is not real time OS, while some applications is time sensitive tasks running in Linux environment, this request to extend the real time feature in common Linux kernel, and RT_PREEMPT is one of the methods to enable Linux kernel with real time processing requirement. But RT_PREEMPT is not accepted by kernel, so it needs extra effort to porting this patch-set to i.MX8M family products. This patch-set is based on L4.14.78 for i.MX8M products, customer need to apply patches based on this release.
View full article
This post entry provides a detailed description of how NFC can be used for authentication and identification of consumables and accessories. This document has been structured as follows: NFC for product authentication and identification NFC is a useful addition to verify product authenticity and identification. There are plenty of examples where NFC fits nicely, for instance: For anti-counterfeit protection and safe brand reputation. For identifying users and provide personalized interactions For sending notifications when accessories need to be replaced And to automatically adjust settings of the main unit based on the accessory attached. These are just a few examples so you grasp the potential of NFC in such scenarios. How NFC works in product authentication and identification Into the scope of a consumable or accessories authentication via NFC, there are always two components involved.  On the one hand, there is one main unit. This is the device where you can plug the part or the accessory. Typically, this main unit would include an active NFC reader. On the other hand, the consumable or replacement would include and NFC tag. The NFC reader in the main unit can detect when the removable part is connected. As soon as the replacement is connected, it reads the information stored in the tag and uses it to verify the accessory originality. Precisely, the information and security features implemented in the tag is what allows the main unit to: First, authenticate that is a genuine accessory And optionally, configure related settings depending on the accessory. Success stories The NFC authentication is not a proof-of-concept but rather a consolidated solution. There are already some success stories in the market. For example: A high-end blender that uses NFC to verifies the authenticity of the containers and cups used. In addition, the blender adjusts the speed parameters automatically per each different container. As mentioned, the NFC reader is part of the base unit while the tag is part of each container. Another example, a face brush that make sure that the brush head is genuine. As before, the reader in on the base while the tag is on each head brush. When a new head brush is connected it check its validity and adjust the settings. The third example is a fridge that discards non-original water filters and check if the fridge and filter models are compatible. How to implement the use case From a simplified block diagram perspective, the base unit embed an NFC reader, this NFC reader is made of an NFC frontend, generating the RF field and a Host MCU, loaded with the application firmware. On the other hand, the accessory, beds an NFC tag. The MFRC630 or our SLRC610 are recommended options from the reader side, while the NTAG and ICODE families are recommended from the tag side. The final product selection depends on your specific application requirements There are a few questions that you can ask yourself to know which product fits you best. First, what is your application about? Are you looking for brand protection? Or counterfeit detection? Or settings customization? Second, what kind of security you need? You need device identification, or you also would like encrypted data exchange? Third, what reading distance is required in your system? Are we talking about a centimeters or tenths of centimiters? And, in relation implementation details, are there any specific size constrains? Is there metal in the surrounding? Etc. NFC portfolio for authentication and identification applications I organized the security features for consumable authentication in three groups: There is a basic level security level where the tag UID is used for proof-of-origin. In this case, there is no crypto protocols applied and the verification consists on checking whether the UID is in our database or not. There is a second level, where the authentication is proven using an originality signature. Depending on the solution, this can be an NXP- signature or a customer-specific signature. There is a third level, that uses a cryptographic three pass mutual authentication as a verification mechanism. NXP originality signature The originality signature implemented in NTAG and ICODE families is based on standard Elliptic Curve Cryptography. NXP generates a ECC key pair (a public and a private key) that are stored in a secure server. In asymmetric crypto, a signature is generated by a signing algorithm given a message and a private key. During production, NXP takes care of provisioning a die-individual signature in each IC. This signature is generated using the tag’s UID and the NXP private key. Since each tag has a different UID, a unique signature is stored in each tag. Therefore, the tags leave the NXP factory already with this unique signature pre-programmed in the IC memory. These pre-provisioned tags are integrated by OEM into their final devices & accessories. On the field, the originality signature verification process is as follows: First, the reader unit reads the tag UID. Second, the reader retrieves the tag signature with the READ_SIGNATURE command. Third, the reader can verify this tag originality signature using the corresponding ECC public key and the tag’s UID. With this feature, it is possible to verify with confidence that the tag is using an IC manufactured by NXP and not a cloned IC. In case that the public key is stored in the reader, the entire process can be performed offline. The products supporting this functionality are: NTAG21x, NTAG413 DNA, NTAG I2C plus, NTAG21x F and ICODE SLIX2. OEM customizable orignality signature The NFC tags come pre-programmed with an NXP originality signature. However, some NTAG and ICODE family members also offer the possibility to customize the originality signature per OEM. The process is similar to the one described above, but in this case, the OEM provisions each tag with a die-individual signature, and lock it to avoid unauthorized overwriting. On the field, the tag originality signature verification is done in the same way: The reader retrieves the tag UID and tag signature The reader uses the corresponding OEM public key and tag UID to verify the signature. The main benefit of customizing the originality signature is that, in addition, it allows to verify that the product belongs to the OEM and not from another manufacturer. The products supporting customer originality signature are NTAG210u, NTAG 213 TT and ICODE DNA. Secure unique NFC message (SUN) One security level up, we find solutions like our NTAG 413 DNA which enable a new Secure Unique NFC message (SUN) feature. This SUN feature generates a unique, secure authentication code each time the tag is tapped. This tap-unique data consists of an NDEF formatted packet that includes: A URL The tag UID The tap counter And a AES-based CMAC calculated over the UID, the counter and the URL. This CMAC is dynamic and changes over each tap since the counter is increased every time. The cloud service verifies the authenticity of the message with the appropriate symmetric keys. With this tag, any NFC enabled device (including Android and the recent iOS 11 devices) can automatically connect to a web based service and based on the information contained in URL, the device can check the tags authenticity and verify the information validity. AES three-pass mutual authentication The last tag security feature is the AES mutual authentication, which is supported by our NTAG 413 DNA as well as the ICODE DNA. The mutual authentication: It is based on a shared secret key known by both endpoints It allows us to verify both ends of the communication (not just the accessory). . The AES 3 pass mutual authentication consist of probing to the other end the knowledge of a secret, in this case, the knowledge of a secret AES key. As we do not want to share in plain this secret over an unsecure channel, the mechanism is based on the encryption of random challenges using this secret key. If both ends are capable of verifying this random-challenge scheme, they demonstrate that the other end knows the secret, and therefore, they prove their authenticity. NFC tag security feature comparison The following table consolidates the different NFC tag security options:  The NTAG21x support NXP originality signature The NTAG210u is a cost optimized version with customizable originality signature The NTAG413 DNA offers the SUN feature as well as AES authentication and encryption Finally, the ICODE DNA comes with customizable originality signature and AES authentication. Therefore, the NTAG413 DNA and ICODE DNA are the strongest authentication options that we have right now in the tag portfolio. The reading distance will influence on the decision between NTAG or ICODE: NTAG is an ISO14443 compliant tag with a operating distance of a few centimiters. ICODE is an ISO15693 compliant tag with an operating distance of tens of centimers. NFC frontends comparison Regarding the NFC readers for the base unit side, we most ideal solutions are: The SLRC610 plus if your application needs a reading distance of tens of centimiters. The SLRC610 supports ISO15693 and is fully operational with our ICODE family. The MFRC630 if your applications needs a reading distance of a few centimiters. The MFRC630 supports ISO14443-A and is fully operational with our NTAG family. NFC Nutshell kit This section leverages on the NFC Nutshell kit to explain how to develop your own NFC authentication solution. This kit was developeb by GMMC an approved engineering consultant of NXP. The NFC Nutshell kit is a set of hardware modules that can be used for: NFC integration into new designs or retrofitting into existing products thanks to its small size. It can be used to build NFC demonstrators Or, it can be used for evaluation, development and testing of NFC applications The main benefits offered by the NFC Nutshell kit are that: It is made to provide designers with Nano sized hardware modules which can be configured and combined in a variety of ways. It was developed with flexibility in mind so that designers can easily combined different MCUs with different NFC frontends and multiple development environment easily. And, it is constructed and prepared to be compatible with NXP software tools. NFC Nutshell kit components The kit includes a good bunch of modules that be divided in 4 different groups: Host interface modules A USB plug that bridges the USB communication to the Host MCU A USB converter that is used to communicate over UART, I2C or SPI with the host MCU A host interface signal debug extender MCU modules: LPC1769 LPC11U68. NFC reader modules: CLRC663 plus PN5180 And soon, PN7462 and PN7150 Antenna PCBs of different sizes to test the performance over different antenna sizes (20x10mm, 20x20mm, 40x40mm, 72x48mm). All the modules are connected with flexible flat cables, and the hardware components are designed for minimal PCB area to demonstrate integration into space constrained products. Modes of operation for the USB protocol converter module In our case, out of the different host interface modules, we select the USB to I²C, UART and SPI converter. This single module itself has several configuration options. As part of the kit, a USB Protocol Converter Configure Tool is provided to easily configure the different operation modes of this component. The user can open this tool and check the different options: The first one is used when the converter is connected to an MCU. It configures the module for an in-system-programming, which means we can use NXP Flash Magic Tool to program the MCU flash memory.  The second option, the development PC communicates directly to the connected NFC frontend via UART.  Last, we have 3 bridge modes for single protocol conversion. The Host system can send the any command over the USB interface and it will be converted to the chosen protocol, either I²C, SPI or UART.  NXP development tools supported Another nice feature of this NFC Nutshell kit is its native support of NXP development tools. Using this kit, you can seamlessly run: The NFC Cockpit, an intuitive graphic user interface that lets you configure and adapt IC settings without writing a single line of software code. The RFIDDiscover PC tool, a user-friendly GUI for evaluation of NTAGs, ICODEs or MIFARE Cards. It is the software that is commonly used with NXP Pegoda reader. The NFC reader library, a complete SW support library for RF frontend ICs. The faster and more straightforward way to develop NFC applications. Consumable authentication using the NFC Nutshell kit This last section is meant to give insight on how to develop your own NFC authentication solution. For that, we will make use of the NFC Nutshell kit and existing software examples as a way to illustrate a possible development process.  The five steps that we followed to run a tag signature verification software example in the NFC Nutshell kit are: First, we select and connect the right modules together Second, we configure the host system interface according to our SW development environment. After that, we develop the application logic of our use case. When the code is ready, we build the project, and create the binary file. And last, we use the Flash Magic tool to install the binary file. Hardware preparation About the hardware preparation… the modules selected are: The USB protocol converter module, as an interface converter between the development PC and the reader host MCU. The LPC1769 as the reader host MCU The CLRC663 as NFC frontend And, the 40x400 mm PCB antenna. USB converter module configuration Before going to the software development itself, we need to configure the USB protocol converter. The USB protocol converter mode of operation configuration is a straight forward process. We just need to execute the Configure Tool provided in the kit, and select the mode compatible for Flash Magic.  In this case, this setting corresponds to the first choice as shown in the screenshot. Software development with the NFC Reader Library For the application software development, we leverage on our well know NFC Reader Library. The NFC Reader Libary is a complete API for developing NFC and MIFARE-based applications, it is free of charge and the latest release can be downloaded from www.nxp.com/pages/:NFC-READER-LIBRARY. Great news is that the NFC Reader Library has: Native support for the modules we selected out the NFC Nutshell kit (the CLRC663 plus and LPC1769) Supports the proximity and vicinity RF protocols. And also, the commandset of Type 2, Type 4 and Type 5 tags. Therefore, we can focus on developing the application logic rather than spending time on implementing drivers or the RF protocols. For that, we do not even need to start from scratch, because we can take as reference any of the eleven software examples. Each of these examples do not make use of the entire library, but just use the NFC Reader library components required for the use case demonstrate, allowing to reduce the overall memory footprint. NXP Originality signature verification We take the Basic Discovery loop example as a starting point for developing an piece of code for tag originality signature verification. If we have a look at the source code, this example: Initialize the library, this is initializing the SW components that will be used It configures the discovery loop for tag detection Keeps iterating until a tag is detected Once the tag is detected, we mentioned that the signature verification process consisted of: Retrieving the UID Retrieving the signature Use a signing verification algorithm to check the signature There are several libraries implementing ECC signature validation. As an example, we added an open source C library called nano-ECC into our project. The function call ecdsa_verify() can process the originality signature read from the tags. It is just as simple as passing as arguments, the UID the signature and the public key. In addition, the NTAG Originality signature validation application note provides code snipets and instructions for this process as well. Three-pass mutual authentication Another example for the implementation of a AES three-pass mutual authentication. Once again, we can take as a starting point the Basic Discovery loop example, which: Initializes the library, configures the discovery and iterates until a tag is detected. In addition, we need to add the crypto component in the NFC Reader Library handling the crypto calculation and key storage (in orange) Once the tag is detected, we can make a direct API function call of the corresponding tag type, whether it is a Type 5 (ICODE) or a Type 4 tag (NTAG 413 DNA) there is the right function call in the lib for that. All the crypto complexity of the three pass mutual authentication is just hidden behing a single function call. Build project with MCUXpresso The MCUXpresso tools is used to build and compile the solution by clicking in the hammer button down in the quick start panel. Create .hex file with MCUXpresso After that, we can also generate the .hex file. For that, we just need to right click on the binary file, go to binary utilities and click on create hex file option. Flash the MCU image with Flash Magic tool With the .hex file generated., the last step is to flash our MCU with this .hex file. In the Flash Magic tool menu, select: The MCU used, in this case LPc1769 The COM port, which can be found in the Windows device manager, in our case COM72 Select the path to the .hex file Click start Once the flashing is completed, the USB converter setting should be changed to I2C or SPI configuration. At this moment, the solution is running and the application will try to authenticate any tag presented in front of the reader. Debugging mode Optionally, the NFC Nutshell kit also incorporates a code debugging mode. For that, there is an extra HW module compatible with LC1769 and LPC11U68 that can be used to interface with an LPC-Link2 debug probe. Video recorded session On 22 February 2018, a live session explaining the NFC for consumable and accessories solution was recorded. You can watch the recording here: Available resources The available resources referred to this post explanation are:  Tags: NTAG 413 DNA NTAG 210μ NTAG 213 TT ICODE DNA Readers: MFRC630 plus SLRC610 plus Application notes: AN11350 NTAG Originality Signature Validation NFC Nutshell kit: GMMC
View full article
Description    NXP’s Personal Network Attached Storage (NAS) solution enables portable personal storage to be shared through an internal protocol (IP) or Wireless network allowing users to share photos, data, stream music or videos, backup and recovery of data over the local area network in a completely secure environment. In addition, the solution can support gateway features such as packet forwarding, cloud connectivity via Ethernet, Wi-Fi or LTE. This NAS solution offers significant advantages to consumer and SMB environments, including: Hardware-accelerated Raid for data parity and recovery, a reduced bill of materials (BOM) and ease-of-use associated with an IP network that most business and consumers already find familiar. Based on the QorIQ Layerscape LS1012A processor and the Network Attached Storage Application Solution Kit (ASK), the personal/consumer NAS solution offered by NXP allows developers to easily build storage applications leveraging the highly-optimized and feature rich ASK software stack along with the small form factor, low-power consumption and packet processing capabilities enabled by LS1012A processor. NXP provides an integrated platform solution (SW and HW) helping the customer to reduce his time to market, increase security and increase performance by leveraging the packet accelerators within the QorIQ® Layerscape LS1012A processor while delivering high NAS performance and IP forwarding applications with reduced load on the Arm® core. In addition, NXP LS1012ARDB supports a full set of popular interfaces such as SATA, USB 3.0, PCIe and 2.5/1Gigabit Ethernet for LAN and WAN, allowing customers and operators to securely connect storage devices with the cloud. Features Integrated Platform Solution Commercial Market Proven Software Solution Hardware Offloading Popular Connectivity Flexible and Optimized Software Architecture Use Cases Personal Storage Consumer Network Attached Storage (NAS) Consumer Direct Attached Storage (DAS) Battery Powered Portable NAS Wireless Personal Storage Media Gateway Chip on Drive Wi-Fi SSD and Small/Portable Drive Ethernet Drives Block Diagram Products Category Name MPU Product URL Layerscape LS1012A Communication Processor for the IoT | NXP  Product Description The QorIQ® LS1012A processor, optimized for battery-backed or USB-powered, space-constrained networking and IoT applications Category Name DC Regulator Product URL MC34VR500 | Multi-Output DC/DC Regulator | NXP  Product Description The NXP® MC34VR500 power management solution for network processor systems is a high-efficiency, quad buck regulator with up to 4.5 A output and five user-programmable LDOs. Tools Product URL QorIQ® LS1012A Development Board QorIQ® LS1012A Development Board | NXP  Layerscape FRWY-LS1012A board FRWY-LS1012A Development Platform | NXP 
View full article