恩智浦设计知识库

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 

NXP Designs Knowledge Base

讨论

排序依据:
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 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
查看全文
This doc expain how to use eMMC from user space, contents as follows: 目录 1 eMMC的分区情况 ...................................................... 2 2 S32G+BSP29上默认的eMMC启动 ............................ 3 2.1 eMMC硬件设计 .................................................. 3 2.2 eMMC的镜像烧写办法与启动 ............................. 6 2.3 增加MMC内核测试工具 .................................... 10 3 eMMC GP功能的测试 .............................................. 10 3.1 eMMC GP功能的说明 ....................................... 10 3.2 eMMC GP功能的测试 ....................................... 11 4 eMMC RPMB功能的测试 ......................................... 13 4.1 eMMC RPMB功能的说明 ................................. 13 4.2 eMMC RPMB功能的测试 ................................. 15
查看全文
Overview The Sensorless High-Speed SR Motor Control Reference Design based on the NXP® low-cost MC56F8013 digital signal controller (DSC) deals with a 2-phase switch reluctance (SR) motor sensorless drive for vacuum cleaners and other air movement applications. The application is a speed-open loop SR drive without any position or speed sensor needs Uses a sensorless control method based on current peak detection and a patented start-up algorithm (Patent No. US6448736 B1) The control technique allows the SR motor more than 100 000 RPM The application is primarily for vacuum cleaners, although it can be used for any application with a high-speed drive (50 000 RPM) Features High-speed 2-phase SR motor sensorless control based on a current peak detection Designed for vacuum cleaner applications Capable of running SR motors at more than 100.000 RPM (tested with SR motor designed for 60 000 RPM) Single direction rotation enabled by asymmetric of 2-phase SR motor Speed open loop Start-up from any position using alignment and patented algorithm (Patent No. US6448736 B1) Start-up time and maximum speed depends on SR motor parameters Manual interface and FreeMASTER control page for monitoring, control and tuning Block Diagram Design Resources
查看全文
Overview This reference design shows the simplicity of a soft modem design, how few resources of the processor it takes, and how well it performs on USA average lines. This design omits the standard telecommunications Codec, instead of using PWM for output and ADC for input. Since both peripherals are readily available on one 56F8300/100 series device, along with more processing power than required from the single core, the design is a true one-chip, one-core system that includes telecommunications ability with room for even more system functionality. Ideal for advanced motion control, home appliances, medical monitoring, fire and security systems, power management, smart relays, and POS terminals. Features Hybrid architecture facilitates implementation of V.21 and V.22bis modem, control, and signal processing functions in one chip Consumes only 7.5 MIPS for the modem function - Only 15K words of Flash for the complete modem application and test harness High-performance, secured Flash memory eliminates the need for external storage devices Extended temperature range allows for operation of non-volatile memory in harsh environments Flash memory emulation of EEPROM eliminates the need for external non-volatile memory 32-bit performance with 16-bit code density On-chip voltage regulator and power management reduces overall system cost Off-chip memory expansion capabilities allow for glueless interfacing with the additional memory of external devices, without sacrificing performance Boots directly from Flash, providing additional application flexibility High-performance PWM with programmable fault capability simplifies design and promotes compliance with safety regulations PWM and ADC modules are tightly coupled to reduce processing overhead; only one of each is used by the modem General purpose input/output (GPIO) pins support application-specific needs Simple in-application Flash memory programming via Enhanced OnCE or serial communication Block Diagram Board Design Resources
查看全文
Overview This reference design demonstrates speed control of the 3-Phase Switched Reluctance (SR) motor with Hall position sensor using the NXP® 56F80x or 56F83XX Digital Signal Controllers (DSCs). It helps start development of the SR drive dedicated to the targeted application The DSC runs main control algorithm; when the start command is accepted, the state of the Hall sensors position signals is sensed and the individual motor phases are powered in order to start the motor in the requested direction of rotation without rotor alignment According to the determined switching pattern and the calculated duty cycle, the on-chip PWM module generates the PWM signals for the SR motor power stage Features Speed Control of an SR motor with position Hall sensors Targeted 56F80X, 56F83XX, and 56F81XX Digital Signal Controllers Running on a 3-Phase SR HV Motor Control Development Platform (115/230VAC) Running on a 3-phase SR LV Motor Control Development Platform (12V DC) The control technique: voltage control with a speed closed loop Hall sensors position reference for commutation Start from any motor position without rotor alignment Manual interface FreeMASTER software control interface and monitor Fault protection Block Diagram Board Design Resources
查看全文
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 doc explain how to configure a new LPDDR4 and test it on S32G, contents as follows: 目录 1    硬件资源,文档及工具下载... 2 1.1    硬件资源... 2 1.2    内存配置测试相关的文档... 2 1.3    内存配置与压力测试工具. 3 2    内存设计要求... 3 3    LPDDR4基础... 3 3.1    基本知识... 3 3.2    Inline ECC.. 4 4    硬件连接... 6 5    S32G+LPDDR4内存配置与测试步骤... 8 5.1    配置LPDDR4初始化寄存器设置... 9 5.2    使用内存测试工具初始化PHY及生成DDRC配置Uboot源代码    11 5.3    生成DDRC配置ATF源代码(从BSP32开始) 14 5.4    测试内存... 18 5.5    其它尺寸的LPDDR4配置... 19 6    测试失败的DEBUG.. 24 7    内存参数应用到Uboot中... 25 8    内存参数应用到ATF中... 25 9    附录... 25 9.1    一个重要的DDR TOOL bug Fix. 25 9.2    Uboot DDR测试工具... 26 9.3    Kernel DDR测试工具... 27 9.4    附DDR tool测试项截图... 28   Contents 1    Hardware Materials, Docs and Tools Needed. 2 1.1    Hardware resource. 2 1.2    Related docs of memory configuration and test 2 1.3    Memory configuration and test tools. 3 2    Memory Hardware Design Requirement 3 3    LPDDR4 Basics. 3 3.1    Basic Knowledge. 3 3.2    Inline ECC.. 5 4    Hardware Design. 7 5    S32G+LPDDR4 Memory Configuration and Test Steps. 8 5.1    Configure LPDDR4 DDRC Register Settings. 9 5.2    Use the Memory Test Tool to Initialize the PHY and Generate the DDRC Configuration Uboot Source Code  12 5.3    Generate ddrc configuration ATF source code (starting from bsp32) 15 5.4    Memory Test 19 5.5    Other size LPDDR4 configurations. 20 6    Debug of the Fails of Test 25 7    Modify the DDRC register settings in Uboot 26 8    Modify the DDRC register settings in ATF. 26 9    Appendix. 26 9.1    A importance DDR TOOL bug Fix. 26 9.2    Uboot DDR Test Tools. 27 9.3    Kernel DDR Test Tool 28 9.4    Attached Screenshot of DDR Tool Test Items. 29
查看全文
Overview NXP ®  offers solutions for the growing unmanned vehicle market in both civil and defense designs, supporting functions such as control, motion, vision, navigation, and communication. Target applications include: Unmanned Aerial Vehicle Unmanned Ground Vehicle Unmanned Underwater Vehicle Construction, demolition, inspection, or mining robot Firefighting or rescue robot Reference Designs NXP Product Link PX4 Robotic Drone FMU https://www.nxp.com/design/designs/px4-robotic-drone-fmu-rddrone-fmuk66:RDDRONE-FMUK66  KV Series Quad Motor Control https://www.nxp.com/design/designs/kv-series-quad-motor-control:KINETIS-DRONE-REFERENCE-DESIGN Block Diagram Recommended Products NXP Product Link MCU Kinetis® V Series: Real-time Motor Control & Power Conversion MCUs based on Arm® Cortex®-M0+/M4/M7 | NXP  LPC54000|Power Efficient 32-bit Microcontrollers (MCUs)|Cortex®-M4 Core | NXP  i.MX RT1060 MCU/Applications Crossover MCU | Arm® Cortex®-M7, 1MB SRAM | NXP  i.MX 6Solo Applications Processors | Single Arm® Cortex®-A9 @ 1GHz | NXP  i.MX 6Dual Applications Processors | Dual Arm® Cortex®-A9 @1.2GHz | NXP  i.MX 6Quad Applications Processors | Quad Arm® Cortex®-A9 | NXP  Wireless Connectivity Bluetooth®Smart/Bluetooth Low Energy | NXP  Interfaces In-Vehicle Network | NXP  I²C, SPI, Serial Interface Devices | NXP  USB Interfaces | NXP  NFC Reader NFC Readers | NXP  Wireless Power Wireless Power | NXP  Motor Driver GD3000 |3-phase Brushless Motor Pre-Driver | NXP  Voltage Regulator Linear Voltage Regulators | NXP  Switch Detector Signal Conditioners | NXP  Sensors Sensors | NXP  Tools and Software NXP Product Link i.MX RT1060 Evaluation Kit i.MX RT1060 Evaluation Kit | NXP  i.MX RT1020 Evaluation Kit i.MX RT1020 Evaluation Kit | NXP  SABRE Board for Smart Devices Based on the i.MX 6Quad Applications Processors i.MX 6Quad SABRE Development Board | NXP  i.MX RT1064 Evaluation Kit i.MX RT1064 Evaluation Kit | NXP  Kinetis® KV3x TWR-KV31F120M|Tower System Board|Kinetis® MCUs | NXP  i.MX RT1015 i.MX RT1015 Evaluation Kit | NXP  3-Phase Motor Control Low-Voltage, 3-Phase Motor Control Tower System Module | NXP  i.MX RT1050 Evaluation Kit i.MX RT1050 Evaluation Kit | NXP  NXP HoverGames drone kit including RDDRONE-FMUK66 and peripherals KIT-HGDRONEK66: NXP drone kit | NXP  Kinetis KV4x TWR-KV46F150M|Tower System Board|Kinetis MCUs | NXP  BSP, Drivers, and Middleware NXP Product Link Android OS for i.MX Applications Processors Android OS for i.MX Applications Processors | NXP  Embedded Linux for i.MX Applications Processors Embedded Linux for i.MX Applications Processors | NXP  MCUXpresso Software Development Kit (SDK) MCUXpresso SDK | Software Development for Kinetis, LPC, and i.MX MCUs | NXP  MCUXpresso Config Tools - Pins, Clocks, Peripherals MCUXpresso Config Tools|Software Development for NXP Microcontrollers (MCUs) | NXP 
查看全文
Overview This drive application allows vector control of an AC Induction Motor (ACIM) running in a closed-speed loop without a speed/position sensor at a low cost and serves as an example of AC induction vector control drive design using an NXP ®  56F8013 with Processor Expert ®  software support. ACIM is ideal for appliance and industrial applications This design uses sensorless FOC to control an ACIM using the 56F8013 device, which can accommodate the sensorless FOC algorithm The motor control system is flexible enough to implement complex motion protocols while it drives a variable load. The system illustrates the features of the 56F8013 in motor control Features General: The motor control algorithm employs Stator-Flux-Oriented Control (SFOC) Power stage switches are controlled by Space Vector Pulse Width Modulation (SVPWM) No position information devices or stator flux measurement are used, a sensorless speed method is employed The motor is capable of forward and reverse rotation and has a speed range from 50rpm to 3000rpm The user controls motion profiles, rotation direction, and speed. The RS-232 communication supports further R&D by enabling the easy tuning of control parameters The motor drive system is designed to create minimal acoustic noise Active power factor correction which reduces the negative effects of the load on the power grid in conducted noise and imaginary power Design is low cost General Benefits: Improved End System Performance Energy savings Quieter operation Improved EMI performance System Cost savings Enhanced Reliability Performance: Input voltage: 85 ~265VAC Input frequency: 45 ~65HZ Rating bus voltage: 350V Rating output power: 500W Switch frequency of PFC switch: 100KHZ Switch frequency of inverter: 10KHZ Power factor: >95% Efficiency: >90% Communications: RS232 port for communication with optoisolation Visual Interface: Multi-segment LED indicators Block Diagram Board Design Resources
查看全文
Overview This reference design of a 3-phase Permanent Magnet Synchronous Motor (PMSM) sensorless vector control drive and a Brushless DC (BLDC) Motor drive without position encoder coupled to the motor shaft uses the NXP® 56F8013 with Processor Expert® software support. PMSM/BLDC motor are excellent choices for many appliances and industrial applications that require low cost and high-performance variable speed operation This design will employ sensorless FOC to control a PMSM and a sensorless algorithm to control BLDC The hardware design supports both motor types with the algorithms fully implemented digitally via software running on the 56F8013 DSC Features General: For PMSM the motor control algorithm employs Field-Oriented Control (FOC). The power stage switches are controlled by means of Space Vector Pulse Width Modulation (SVPWM) The feedback hardware elements are limited to the motor stator phase currents and the bus voltage. No position information devices or stator flux measurement are used; sensorless speed methods are employed The Motor is capable of forward and reverse rotation and has a speed range of 500rpm to 6000rpm The user controls motion profiles, rotation direction, and speed. The RS-232 communication supports further R&D by enabling the easy tuning of control parameters The motor drive system is designed to create minimal acoustic noise Active power factor correction which reduces the negative effects of the load on the power grid in conducted noise and imaginary power Design is low cost General Benefits: Improved End System Performance Energy savings Quieter operation Improved EMI performance System Cost savings Enhanced Reliability Performance: Input voltage: 85 ~265VAC Input frequency: 45 ~65HZ Rating bus voltage: 350V Rating output power: 500W Switch frequency of PFC switch: 100KHZ Switch frequency of inverter: 10KHZ Power factor: >95% Efficiency: >90% Communications: RS232 port for communication with optoisolation Visual Interface: Multi-segment LED indicators Block Diagram Board Design Resources
查看全文
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
查看全文
本文说明S32G在Linux中如何使用内存读写工具来发起一个HSE Server服务请求,以确认HSE是否正常工作。本说明的目的旨在在极端缺少Debug手段的情况下,确认HSE的状态。 目录 1    背景说明与参考资料... 2 1.1  背景说明... 2 1.2  参考资料... 2 2    启动包含HSE的Linux镜像... 3 3    HSE服务代码逻辑与寄存器状态... 3 3.1  HSE Demo示例... 3 3.2  IDEL情况下MU寄存器状态... 6 4    使用Linux memtool命令来访问HSE. 10 4.1  检查HSE状态... 10 4.2  准备hseSrvDescriptor_t数据结构... 10 4.3  申请HSE服务... 11 5    其它建议... 12
查看全文
         LittleVgl作为一款开源免费的嵌入式GUI得到越来越多工程师的厚爱,我们可以看到很多小型HMI项目或者一些开源社区都在使用它作为GUI的框架,同时也受益于用户群的不断扩大以及一些半导体原厂的青睐(通俗点就是说有赞助有钱儿了),LittleVgl本身也在快速的不断更新迭代,易用的组件和相关的辅助开发工具在不断的增加,而RT1050/1060/1170系列作为一款带有LCD控制器的平台,自然成为了LittleVgl最佳的载体之一了。         LittleVgl本身的组件已经很丰富了,但是遗憾的是一直没有加入对中文输入法Keyboard的支持(看了下它在Github上的Contributor List没有华人),这让它在我们国内的应用有了一些限制(注意在某组件上显示中文和真正的中文输入法是不同的概念),所以本项目旨在解决该问题,即把一个简单轻量的中文输入法框架嵌入到LittleVgl并跑在RT1050平台上,并把它开源开放出来,所以不要小看了我的“公益心”,哈哈。下图是该示例设计的UI界面 calvinji_0-1636016289849.png        下面进入正题,首先把测试环境给出来,方便有兴趣有能力的朋友可以自行搭建(当然应一部分偷懒的强烈需求,我随本文档也附赠了完整的移植好的工程),然后我再一步一步地给出如何移植这套框架到用户自己的工程里,当然我已经把代码本身做了很多优化,尽量减小环境依赖,力求最少步骤的移植过程,理论上来讲不太会出现移植后编译出一堆Error的问题,咳咳。。。下面我们赶紧开整吧: 测试环境: SDK版本:SDK_v2.9.1 SDK参考例程:boards\evkbimxrt1050\littlevgl_examples\littlevgl_demo_widgets LittleVgl版本:v7.4.0 IDE工具:Keil_v5.31 开发板:MIMXRT1050-EVK + 480*272 RGB LCD屏 软件说明: 我们先看下这套中文输入法所需的几个文件,如下图所示,.c和.h文件加起来一共7个,其中nxp_logo.c只是我额外加的一个NXP的官方logo图标转成的C数组文件供littleVgl调用显示,属于锦上添花的东西,可有可无,真正跟输入法相关的是剩下的6个文件,下面我们逐一介绍下这几个文件的作用: calvinji_1-1636016390952.png1. qwerty_py.c/.h:        实际上这两个文件才是这套全键盘拼音中文输入法的核心框架,实现了对输入的拼音字母进行索引匹配对应的汉字候选列表,这部分我是移植了如下链接中网友分享的代码,所以这两个文件我的角色只是一个大自然搬运工,不过说实话我是很感激该网友的无私分享的(这也是我一直推崇开源分享精神的源动力),之前对平时使用的各种输入法里面的算法原理一直充满好奇,直到看了这篇文章后才豁然开朗,“So that is what it is!”,让我获益匪浅(可能人的学习曲线和知识体系就是这样一点一滴的积累吧),而且更关键的是,如果让我继续往下开发诸如拼音联想和多汉字输入等功能的话,我更多关心的可能只是逻辑搭建的工作量问题,而不是纠结于Yes or No的问题了,因为咱已经了解了其最底层的工作原理了,所以很多复杂的事情,我们如果能抽丝剥茧的找到其最底层的本质(虽然这真的很难),那很多让人抓耳挠腮的问题很快就可以理清思路。说到这里我思维又发散了,呵呵,我想起让Linus Torvalds等一波老大神们一直头疼的Linux内核维护后继无人的问题,其实我的个人理解有很大一部分原因是如今的Linux太庞大了以至于几乎没有后辈的人对Linux的理解能赶上这些老辈大神,而这些老辈大神的最大优势是他们创建了Linux最早期的底层框架而且难能可贵的是一直在follow Linux每个版本的历史。总之,推荐大家看看如下这篇文章吧(实际上主要内容也都是代码),希望能各有所获; https://www.amobbs.com/thread-5668320-1-1.html?_dsign=0939dcbd 2. lv_chs_keyboard.c/.c文件:        这部分就是我的工作了(咱也不能啥都搬运…,这是体现咱的value的东西不是),我把它当作littleVgl的一个补充组件来写的,里面的大多数API参考官方littlevgl的lv_keyboard.c,所谓的文章开头的嵌入中文输入法到LittleVgl GUI环境中实际上就是这两个文件干的活,即将上面提到qwerty.c/.h实现的拼音输入法与LittleVgl框架结合到一块,起到一个桥梁的作用,所以如果你想把这套中文输入法嵌入到其他GUI环境中的话(比如emWin,GUIX,TouchGFX等),那主要的工作就是参考这两个文件的内容了; 3. lv_font_NotoSansCJKsc_Regular.c字体文件:        虽然littleVgl官方源码包里自带了一个中文字体文件(\lvgl\src\lv_font\lv_font_simsun_16_cjk.c),但是它只包含了1000个左右最常用的字,我实际体验了下很多我们想用的字都找不到,所以这个时候就需要自己去做一个更全一点的字体库了。这里面涉及到两个问题需要考虑,第一是很多我们常见的中文字体是收费的(咱PC机的Microsoft Office套件里的中文字体都是微软付费买的,所以咱也理解下早年正版Windows为啥辣么贵了,那你问为啥现在便宜了?因为人家现在不靠这个赚钱了呗),第二个是字体转换工具的问题,我们网上找到的字体都是TTF或者OTF格式的,但littleVgl是不认的,需要转换成它支持的字体格式。        对于第一个问题,我网上搜了好久最终选择了目前用的比较多的Google开源免费的字体,Google真乃金主也,它维护的网站里面字体各种各样啥都有且是开源免费的,如下链接,我选择的是NotoSansCJKsc字体(最后面的sc表示simplified Chinese,简体中文),然后它里面又包含了各种字形(regular, bold, light等),可以根据需要自行选择,整个包很大(100多MB),拆分成不同字形的就小了(每个14~16MB左右); https://www.google.com/get/noto/ calvinji_2-1636016483936.png        对于第二个字体转换工具的问题,LittleVgl官方自带了一个字体转换工具(online font converter),我个人觉着不太好用(对OTF字体支持的不行),这里推荐阿里大神自己做的一个LittleVgl字体转换工具(LvglFontTool),非常方便好用,且支持加入Awesome图标; http://www.lfly.xyz/forum.php?mod=viewthread&tid=24&extra=page%3D1 calvinji_3-1636016512024.png        关于字体这部分我需要再补充个问题,就是它占用的memory大小,毕竟我们是在嵌入式MCU平台Flash和RAM的资源是受限的,如下图所示,该字体文件占用大概1Mbytes的rodata空间(即可寻址的Flash空间,当然该大小可以通过在上图转换工具中增减一些文字来调 整),所以在移植本套输入法之前需要预留足够的Flash空间,当然对RT平台来说这部分还好,毕竟其本身就外扩至少几MB空间的QSPI Flash作为存储空间的。 4. lv_demo_chineseinput.c/.h文件:        这两个文件属于应用层实现了,主要关注该文件中下图的ta_event_cb函数(即textarea事件的callback,点击文本框的输入时回调),在里面我们需要按照1,2,3去调用即可(这三步的API均在lv_chs_keyboard.c/h文件里实现);        至此,这套全键盘拼音中文输入法框架所需的几个文件就介绍完了,用户只需要把这几个文件放到自己的工程设置好文件搜索路径,并参考随本文档附带的代码工程示例,再结合自己产品的GUI样式,把这套中文输入法嵌入到自己应用当中。
查看全文
  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
查看全文
  本文说明S32G  RDB2板Linux板级开发包BSP32 的ATF细节,以帮助客户了解S32G的ATF是如何运行的,以及如何修改到客户的新板上。   从BSP32开始,默认启动需要ATF支持,所以部分定制需要移动到ATF中,Uboot会简单很多。 请注意本文为培训和辅助文档,本文不是官方文档的替代,请一切以官方文档为准。   目录如下: 目录 1    S32G Linux文档说明... 2 2    创建S32G RDB2 Linux板级开发包编译环境... 3 2.1  创建yocto编译环境: 3 2.2  独立编译... 8 3    NXP ATF 原理... 13 3.1  AArch64 Exception Leve: 13 3.2  ATF原理... 14 3.3  ATF目录 结构... 16 3.4  ATF初始化流程... 25 3.5  NXP ATF的SCMI支持... 28 3.6  NXP ATF的PSCI支持... 32 3.7  NXP ATF OPTEE接口(未来增加)... 36 4    ATF 定制... 36 4.1  修改 DDR配置... 36 4.2  修改调试串口与IOMUX定制说明... 39 4.3  启动eMMC定制说明... 48 4.4  I2C与PMIC定制说明... 58
查看全文
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
查看全文
目录 1 S32G Linux文档说明 .................................................. 3 2 创建S32G RDB2 Linux板级开发包编译环境 .............. 4 2.1 创建yocto编译环境: ................................................. 4 2.2 独立编译 ................................................................. 9 3 FSL Uboot 定制 ........................................................ 14 3.1 FDT支持 ............................................................... 14 3.2 DM(driver model)支持 ........................................... 20 3.3 Uboot目录结构 ...................................................... 31 3.4 Uboot编译 ............................................................. 34 3.5 Uboot初始化流程 .................................................. 35 3.6 使能了ATF后对Uboot初始化流程的影响 ............... 40 4 Uboot 定制 ............................................................... 41 4.1 修改 DDR大小 ....................................................... 41 4.2 修改调试串口与IOMUX说明 .................................. 44 4.3 DM I2C与PMIC初始化 .......................................... 53 4.4 通用GPIO ............................................................. 59 4.5 启动eMMC定制 ..................................................... 69 4.6 Ethernet定制 ......................................................... 78 5 Uboot debug信息 ..................................................... 89 5.1 Print env ............................................................... 89 5.2 dm - Driver model low level access ...................... 92 5.3 fdt .......................................................................... 95 5.4 I2C测试 ................................................................. 95 5.5 芯片寄存器访问 ..................................................... 98 updated to V5
查看全文
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
查看全文