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

This doc explain bootloader secure boot feature and how to re-develop it to support: .FW update .OTP attribute access .IVT protect: 目录 1 参考资料 .................................................................... 2 2 S32G Secure Boot说明 ............................................. 2 2.1 IVT头格式与Secure Boot相关 ................................ 3 2.2 Secure Boot流程 .................................................... 3 2.3 Secure Boot配置 .................................................... 4 2.4 Secure Boot涉及到的HSE内容 ............................... 6 3 环境搭建 .................................................................... 7 3.1 搭建编译环境 .......................................................... 7 3.2 IVT镜像制造 ........................................................... 7 3.3 镜像烧写 ................................................................. 8 3.4 Bootloader Secure Boot测试 .................................. 8 4 Bootloader Secure Boot代码与功能说明 ................... 9 4.1 EB配置说明： ........................................................ 9 4.2 EB生成代码说明： ............................................... 15 5 定制1：HSE FW update .......................................... 22 5.1 代码开发 ............................................................... 22 5.2 测试 ...................................................................... 25 6 定制2：HSE OTP Attribute设置 ............................... 26 6.1 代码开发 ............................................................... 26 6.2 模拟测试 ............................................................... 33 7 定制3：IVT签名 ....................................................... 35 7.1 代码开发 ............................................................... 35 7.2 模拟测试 ............................................................... 40 Contents 1 Reference Materials .................................................. 2 2 S32G Secure Boot ..................................................... 3 2.1 IVT header format for the Secure Boot part .......... 3 2.2 Secure Boot Flow ................................................... 3 2.3 Secure Boot Configuration ..................................... 4 2.4 HSE background of Secure Boot ........................... 6 3 Build the Project ........................................................ 7 3.1 Build the Compiling Environment ........................... 7 3.2 Create IVT Image ................................................... 7 3.3 Burning Image ........................................................ 8 3.4 Bootloader Secure Boot Testing ............................ 9 4 Bootloader Secure Boot Codes and Function Description 9 4.1 EB Configuration .................................................... 9 4.2 EB output codes ................................................... 15 5 Customization 1：HSE FW update ......................... 22 5.1 Codes development ............................................. 23 5.2 Testing ................................................................. 26 6 Customization 2：HSE OTP Attribute Setting ......... 26 6.1 Code Development .............................................. 27 6.2 Simulation test ...................................................... 34 7 Customization 3：IVT Signature ............................. 36 7.1 Codes Development ............................................. 36 7.2 Simulation Testing ................................................ 40  

This doc explain  where is the design resource and what they are of S32G in Chinese,  Contents as follows: 目录 1 www.nxp.com 官网资源 ............................................. 2 1.1 www.nxp.com Documentation ................................ 4 1.2 www.nxp.com Tools&Software ............................. 10 2 Flexera资源 ............................................................. 18 2.1 Automotive HW-S32G Evaluation Board .............. 21 2.2 Automotive HW-S32G GoldBox ........................... 22 2.3 Automotive HW-S32G RDB2(RDB不再说明) ....... 22 2.4 Automotive SW-S32G2 Standard Software.......... 23 2.5 Automotive SW-S32G2 reference Software ......... 28 2.6 Automotive SW-S32G2 Tools .............................. 30 3 Docstore资源 ........................................................... 31

This doc explain how to optimize the Linux boot time, Contents as follows: 目录 1 默认BSP28 Linux内核的启动时间分析和优化方向 ..... 2 2 UBoot的优化 .............................................................. 3 2.1 缩小Uboot的DTS尺寸 ............................................ 3 2.2 缩小Uboot的尺寸 .................................................... 4 2.3 去掉等待3S输入时间 .............................................. 4 2.4 配合内核修改的Uboot参数 ..................................... 4 2.5 关闭串口调试信息 .................................................. 5 2.6 MMC read的方法来读取内核和DTB ....................... 5 3 Kernal的优化 ............................................................. 5 3.1 DTB中去掉不用的驱动和代码 ................................. 5 3.2 内核中去掉不用的平台与驱动及相关代码 ............... 6 3.3 内核中去掉不用功能，缩小内核大小 ...................... 7 3.4 去掉initramfs支持 ................................................... 7 3.5 关闭调试信息 .......................................................... 7 3.6 提前eMMC驱动加载时间 ........................................ 7 3.7 将Kernel与DTB打包在一起..................................... 8 4 Rootfs+应用程序的优化 ............................................. 8 5 最终全部启动时间比较 ............................................. 12

  i.MXRT系列具有内部ROM，并且ROM中暴露出了一些功能接口可供用户直接使用。 本文介绍了Flexspi Nor ROM APIs, 并且列举了API相关的参数及示例程序。 通过这些API可以很方便的操作外部Flexspi Nor Flash。用户无需关系细节。   Products Product Category NXP Part Number URL MCU MIMXRT1060 https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i-mx-rt-crossover-... MCU MIMXRT600 https://www.nxp.com/products/processors-and-microcontrollers/arm-microcontrollers/i-mx-rt-crossover-...   Tools NXP Development Board URL i.MX RT1060 Evaluation Kit https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/mimxrt1060-evk-... i.MX RT600 Evaluation Kit https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/i-mx-rt600-eval...   SDK SDK Version URL MCUXpresso SDK Builder https://mcuxpresso.nxp.com/en/welcome

  Overview   Vehicle-to-Everything (V2X) technology enables cars to communicate with their surroundings and makes driving safer and more efficient for everyone. By making the invisible visible, V2X warns the driver of road hazards, helping reduce traffic injuries and fatalities. In addition to improving safety, V2X helps to optimize traffic flow, reduce traffic congestion and lessen the environmental impact of transportation. V2X is a key component for full autonomous driving. V2X need message package signing & verification which need high CPU loading if used CPU. Qualcomm recommend their customers to use NXP i.MX8X/XL which have HSM as their modem’s companion chip. Two major components in the system: RSU (Road Side Unit) and OBU (On Board Unit). Both have similar system design, with minor differences. Block Diagram   Product Category MCU/MPU Product URL 1 i.MX 8X Family – Arm® Cortex®-A35, 3D Graphics, 4K Video, DSP, Error Correcting Code on DDR  Product Description 1 Extending the scalable range of the i.MX 8 series, the i.MX 8X family is comprised of common subsystems and architecture from the higher-end i.MX 8 family, establishing a range of cost-performance scaling with pin-compatible options and a high level of software reuse. Product URL 2 https://www.nxp.com/design/development-boards/automotive-development-platforms/s32k-mcu-platforms/s32k144-evaluation-board:S32K144EVB  Product Description 2 The S32K144EVB is a low-cost evaluation and development board for general purpose automotive applications.   Category Transceivers Product URL 1 TJA1051: High-speed CAN transceiver  Product Description 1 The TJA1051 is a high-speed CAN transceiver that provides an interface between a Controller Area Network (CAN) protocol controller and the physical two-wire CAN bus. Product URL 2 TJA1101: 2nd generation Ethernet PHY Transceivers - IEEE 100BASE-T1 compliant  Product Description 2 TJA1101 is a high-performance single port, IEEE 100BASE-T1 compliant Ethernet PHY Transceiver.   Category Power Management Product URL PF8100-PF8200: 12-channel Power Management Integrated Circuit (PMIC) for High-Performance Processing Applications  Product Description The PF8100/PF8200 PMIC family is designed for high-performance processing applications such as infotainment, telematics, clusters, vehicle networking, ADAS, vision and sensor fusion.   Category Secure Element Product URL SXF1800: Secure Element IC for V2X Communication  Product Description SXF1800 is based on highly secure microcontroller used also to protect mobile payments, providing highest proven assets protection.   Category I2C interface Product URL 1 PCA9538: 8-bit I²C-bus and SMBus low power I/O port with interrupt and reset  Product Description 1 The PCA9538 is a 16-pin CMOS device that provides 8 bits of General Purpose parallel Input/Output (GPIO) expansion with interrupt and reset for I2C-bus/SMBus applications and was developed to enhance the NXP Semiconductors family of II2CC-bus I/O expanders. Product URL 2 PCT2075: I2C-Bus Fm+, 1 Degree C Accuracy, Digital Temperature Sensor And Thermal Watchdog  Product Description 2 The PCT2075 is a temperature-to-digital converter featuring ±1 °C accuracy over ‑25 °C to +100 °C range. Product URL 3 PCA85073A: Automotive tiny Real-Time Clock/Calendar with alarm function and I2C-bus  Product Description 3 The PCA85073A is a CMOS1 Real-Time Clock (RTC) and calendar optimized for low power consumption.   Category Wi-Fi Product URL 88W8964: 2.4/5 GHz Dual-Band 4x4 Wi-Fi® 5 (802.11ac) Access Solution  Product Description The 88W8964 features 160MHz bandwidth and Multi-User Multi-Input Multi-Output (MU-MIMO) while achieving 2.6 Gbit/s peak data rate for high speed, secure, and reliable access points and smart gateways.   Category V2X Modem Product URL RoadLINK® SAF5400 Single Chip Modem for V2X  Product Description The RoadLINK SAF5400 is an automotive-qualified single chip DSRC modem for V2X applications. The SAF5400 modem is able to receive and verify up to 2000 messages per second.

  Overview With the expansion of IoT technologies, it is required to implement devices that allow a trusted environment for such technologies. This device allows to have a secure environment thanks to the use of the A71CL Secure Element, which provides a root of trust at the IC level and chip-to-cloud security while working with IoT technologies. Besides the A71CL, the implementation uses a i.MX 8M Mini in order to work with high performance and low power consumption. Block Diagram Products Category MPU Product URL i.MX 8M Family - Arm® Cortex®-A53, Cortex-M4, Audio, Voice, Video  Product Description The i.MX 8M family of applications processors based on Arm® Cortex®-A53 and Cortex-M4 cores provide industry-leading audio, voice and video processing for applications that scale from consumer home audio to industrial building automation and mobile computers.   Category Power Management Product URL PF1510: Power Management Integrated Circuit (PMIC) for low power application processors  Product Description The PF1510 is a Power Management Integrated Circuit (PMIC) designed specifically for use with i.MX processors on low-power portable, smart wearable and Internet-of-Things (IoT) applications.   Category Transceiver Product URL TJA1101: 2nd generation Ethernet PHY Transceivers - IEEE 100BASE-T1 compliant  Product Description TJA1101 is a high-performance single port, IEEE 100BASE-T1 compliant Ethernet PHY Transceiver.   Category Secure Element Product URL EdgeLock™ SE050: Plug & Trust Secure Element Family – Enhanced IoT security with maximum flexibility  Product Description The EdgeLock SE050 product family of Plug & Trust devices offers enhanced Common Criteria EAL 6+ based security, for unprecedented protection against the latest attack scenarios.

  Overview NXP’s Motion Control and Robotics solution provides the computing performance, embedded connectivity, low latency and a real-time open source operating system to address the requirements for multi-axis motion control and robotics applications.  This solution is based on an i.MX RT1050, which controls four steppers motors that activates the different kind of movement of the robotic arm for the 3D printer to function. This solution also counts with the FreeMASTER GUI for easy debugging and a better presentation and control of the system. Use Cases Our robust product portfolio makes motor and robotics control more precise, secure and effective for the creation of end-products with applications like: 3D printers Industrial applications: Welding machines Material handling Painting and drilling Assembly machines Surgical assistants Block Diagram Products Category MCU Product URL i.MX RT1050 Crossover MCU with Arm® Cortex®-M7 core  Product Description The i.MX RT1050 is the industry's first crossover MCU and combines the high-performance and high level of integration on an applications processors with the ease of use and real-time functionality of a microcontroller.   Category Motor Driver Product URL GD3000: 3-Phase Brushless Motor Pre-Driver  Product Description The GD3000 is a gate driver IC for three-phase motor drive applications providing three half-bridge drivers, each capable of driving two N-channel MOSFETs.   Category Power Management Product URL PCA9412: 3.0 MHz, 300 mA, DC-to-DC boost converter  Product Description The PCA9412 and PCA9412A are highly efficient 3.0 MHz, 300 mA, step-up DC-to-DC converters.

    Description: Teensy 3.1 and Teensy-LC are a complete USB-based development tools featuring respectively the Kinetis 32-bit Cortex-M4 K20 and Cortex-M0+ KL26 devices running @ 72 and 48 MHz. Teensy 3.1 is equipped with 256KB flash and 64KB RAM. Teensy-LC board is equipped with 62KB flash and 8KB RAM.   Value Propositions * Very small footprint development tools * Very Low Cost dev tool * They are able to implement many different projects * Open source SDKs   Teensy board with very high extended-Arduino compatible performance levels and libraries taking advantage of Kinetis features like low power modes and internal DMA. Libraries for LED (WS2811) and 16bit 44.1kHz audio quality is where Makers go when they need quality, performance and small size. FEATURES Hardware Specifications Specification Teensy LC Teensy 3.0 Teensy 3.1 & 3.2 Units Processor MKL26Z64VFT4 32 bit ARM Cortex-M0+ 48 MHz MK20DX128 32 bit ARM Cortex-M4 48 MHz MK20DX256 32 bit ARM Cortex-M4 72 MHz Flash Memory 62 128 256 kbytes RAM Memory 8 16 64 kbytes EEPROM 1/8 (emu) 2 2 kbytes I/O 46, 5 Volt 34, 3.3 Volt 34, 3.3V, 5V tol Analog In 8 14 21 PWM 9 10 12 UART,I2C,SPI 1,1,1 3,1,1 3,2,1 Price $24.00 $19.00 $19.80 USD   Software Enablement Teensy 3.2 & 3.1: New Features https://www.pjrc.com/store/teensylc.html     RECOMMENDED PRODUCTS Product Description Kinetis K Microcontroller Kinetis L Microcontroller RESOURCES Title Type PJRC (Teensy Official Website) Web Page

About this demo This demo is based on the Wireless UART example from the SDK available on Welcome | MCUXpresso SDK Builder selecting the QN908X board.  The main idea of this demo is to be able to send commands from one device to another, it could be from a QN9080DK, a phone using our NXP application: IoT Toolbox or even an FRDM-KW41Z, this is possible because of the BLE protocol used in all our devices. The end-device used is a QN9080DK, this board receives the message, does parsing and triggers a PWM function using the values sent from another device. This signal can be used in different applications, typically controlling smart lighting brightness and color, speed of motor controls and audio or video amplifiers. The goal of this demo is to implement a task for our FreeRTOS scheduler in order to be able to control a PWM while the BLE connection is still running and receive new incoming messages.   Video Limitations We only interpret ON, OFF and a string of values for our 3 signal outputs. The string of values has to be in the following syntax: rXXX,gXXX,bXXX. An example of this could be r255,g130,b200. The max value should be 255 in order to achieve 100% of the duty cycle, for this example, we are using is at 100 Hz. The connection is not using pairing or bonding modes, so no device information is saved on the non-volatile memory due to this if the connection is lost we need to follow the initial connection procedure. The amount of bytes that can be sent is limited by the macro: #define gAttMaxMtu_c in the ble_constants.h file from the project, we recommend to leave it as it is.   Useful Links Useful documentation is available in the SDK previously downloaded: <SDK Installation folder>...\SDK_2.2.1_QN908XCDK\docs   Link Description https://www.nxp.com/webapp/Download?colCode=QN908x-DK  QN908xDK User’s Guide Welcome | MCUXpresso SDK Builder  SDK Builder site Wireless Connectivity  NXP Wireless Community Connectivity Software: Implement tickless mode in FreeRTOS  Document for implementing a new task using OSA Abstraction layer of FreeRTOS https://www.nxp.com/docs/en/nxp/data-sheets/QN908x.pdf QN908x Datasheet for pins functions   Required Items Link Description QN908x: Ultra-Low-Power Bluetooth Low Energy System on Chip (SoC) Solution | NXP  It is required at least one as an end-point. Oscilloscope  An Oscilloscope to visualize the PWM. Hardware Diagram Step-by-Step Guide Download de QN908x SDK Download the attached .zip file. Import it into MCUXpresso, for the end node you should only use the qn908xcdk_wireless_uart_peripheral project. If you want to use a second QN board to send the commands it is required to also import the qn908xcdk_wireless_uart_central project. Once the projects are imported, we need to flash each board with a project and connect the PA9, PA10, and PA18 pins to our oscilloscope in order to visualize the signal. Connect the USB cables to the computer and open Teraterm with the following values: 115200, 8 bits, none,1 bit, none. Press the RESET Button (SW3) of the Peripheral board Press the Button1 (SW1) after the message: "Wireless UART starting as GAP Peripheral, press the role switch to change it.", an "Advertising" should appear. If a second QN board is used (central), we need to open a second Teraterm session and set it to the same Serial configurations from point 5. If an Android phone is used we need to have the IoT Toolbox application installed and select the Wireless UART example and connect to the Peripheral board using the interface. To pair the Central board to the Peripheral it is required to press the RESET Button (SW3) of the Central board while the Peripheral board is advertising and then Push the Button1 (SW1). Once the boards are connected, we need to paste the message to our terminal in order to be sent as one message. The message should be seen in the other board terminal. Send "ON" to activate the PWM functionality. Send "r255,g128,b64" to set the PWM pins to 100%, 50%, 25%. This signal must be displayed at 100Hz on the oscilloscope. Send "OFF" to deactivate the PWM functionality.   Further Information The Demo is based on the Wireless UART example, The BleApp_ReceivedUartStream function is modified to compare de received strings. The getValuesRGB converts the string into integer values to be assigned to the global variables red, green, blue. Inside getValuesRGB we use the OSA abstraction layer for FreeRTOS to create the task using: OSA_TaskCreate and creating the task named: vfnTaskPWM. vfnTaskPWM configures the timer and initializes the PWM values using the CTimer driver functions and starts the CTimers.     Results 1. After the QN9080 is flashed and in Advertising mode, we have to connect our Central device, Which in this case is an Android phone. In or Teraterm we should be able to see this message: 2. Then, we get the Connected status from our devices and we should be able to send the ON command and the RGB values, Teraterm indicates the integer values and the string received.         3. When we send the OFF command the PWM signals should be 0 V.   4. Here is another example:    

This doc explain how to support a new QSPI nor for boot, SDK and Linux, Contents as follows: 目录 1 硬件设计 .................................................................... 2 2 所需工具和相关资料 .................................................. 5 3 ROM Code的启动流程 ............................................... 5 4 S32G QSPI NOR flash配置表头定制 ......................... 7 4.1 S32G QSPI NOR启动配置表信息 .......................... 7 4.2 目前支持的配置表头分析说明 ............................... 10 4.3 LUT构成与Flash write Data说明 ........................... 16 4.4 具体分析已有的配置表头的LUT与Flash write Data的 配置方法 ...................................................................... 22 4.5 支持一款新的QSPI NOR Flash示例1:Micron........ 28 4.6 支持一款新的QSPI NOR Flash示例2:Winbond .... 31 5 使用IVT打包配置头 .................................................. 33 6 使用IVT工具中的flash image工具烧写镜像到QSPI NOR 中 34 7 软件定制M7 ............................................................. 35 8 软件定制uboot ......................................................... 37 9 软件定制Linux Kernel .............................................. 40 9.1 支持美光8bit DDR 模式(未验证) .......................... 44 9.2 支持1bit SDR fast read 模式 ............................... 46 10 Debug过程中需要注意的几点 .................................. 49 10.1 启动时ROM Code读取QSPI NOR时钟仅有12Mhz左 右 49 10.2 比较大的镜像如果不加参数头，无法从QSPI-NOR上启 动 55   add a new doc for lauterbach driver: S32G How to Develop the QSPI-Nor Lauterbach Script 目录 1    背景和参考资料... 2 1.1  背景说明... 2 1.2  参考资料... 2 2    高速读开发流程... 3 2.1  时钟相关修改... 5 2.2  Lut配置说明... 6 2.3  QSPI NOR控制器配置... 12 2.4  QuadSPI_Write32BytesDOPI读函数分析... 15 2.5  增加AHB read寄存器配置... 17 2.6  测试结果... 18 3    高速写开发流程... 19 3.1  Erase lut分析及调用... 19 3.2  Write lut分析及调用... 21 3.3  测试结果... 22 3.4  Lauterbach烧写镜像脚本说明... 22

  Overview   Since 1996 in EU and since 2000 in Europe, the OBD (On-Board Diagnostics) is mandatory for all the cars manufactured. This protocol is used to verify the smoke emissions and check if any car is between the parameters stablished in every country. Also detect engine failures without need to check the engine manually, identifying accurately the problems reducing the repairing time and cost. OBD-II is a sort of computer which monitors emissions, mileage, speed, and other useful data. OBD-II is connected to the check engine light, which illuminates when the system detects a problem. Scan tools can be used to make sense of the diagnostic trouble codes and collect data on other aspects of vehicle’s performance.   Use Cases Hotspot in the CAR Geofences and speed limits Driving habits tracking Insurance and Rental Entertainment   Block Diagram   Products Category Name MCU Product URL 1 MIMXRT1050-EVK: i.MX RT1050 Evaluation Kit Product Description 1 The i.MX RT1050 EVK is a 4-layer through-hole USB-powered PCB. At its heart lies the i.MX RT1050 crossover MCU, featuring NXP’s advanced implementation of the Arm® Cortex®-M7 core.   Category Name Serial Link Bus Product URL 1 KIT33660EFEVBE: Evaluation Kit - MC33660, ISO K Line Serial Link Product Description 1 The KIT33660 evaluation board supports the MC33660, a serial link bus interface device designed to provide bi-directional half-duplex communication interfacing in automotive diagnostic applications.   Category Name Transceiver Product URL 1 TJA1100HN: Evaluation Board, TJA1100HN 100BASE-T1 PHY Transceiver Product Description 1 The TJA1100HN customer evaluation board is a low-cost hardware development tool which supports the functional evaluation of the TJA1100HN 100BASE-T1 PHY transceiver.  

Overview This application creates a vector control PMSM drive with optional speed closed-loop using a quadrature encoder, and serves as an example of a PMSM vector control system design based on the cost-effective 32-MIPS NXP® digital signal controller MC56F80XX. Dedicated algorithms such as transformations, PI controllers and space vector modulation, are implemented using NXP’s Motor Control Library This cost-effective and highly reliable solution minimizes system cost, as the algorithm implements a single shunt current sensing, reducing 3 current sensors to one The reference manual provides a detailed description of the application, including the design of the hardware and the software Features 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 Vector control of PMSM using theQuadrature Encoder as a position sensor Control technique incorporates: Vector control with speed closed-loop with position encoder Rotation in both direction Start from any motor position with rotor alignment 4-quadrant operation Reconstruction of three-phase motor currents from DC-Bus shunt resistor Wide speed range FreeMASTER Control Interface Fault protection - overcurrent, overvoltage, undervoltage Block Diagram Board Design Resources

  Overview Hearables or smart headphones are highly integrated, truly wireless earbuds designed to improve audio experiences across a range of consumer and healthcare applications. Small form factors, ultra-light weight and wireless operation increase user comfort. The continued challenge for hearables is how to combine audio quality, user experience and better battery life in a tiny package while offering a multitude of possibilities, all of which demands digital signal processing. To simplify customer engineering efforts on prototype TWS earbud, NXP built an Application Development Kit. Customer just need plug and play to test the functionality and performance of earbud. The ADK demonstrated a stable audio streaming link from Bluetooth mobile phone to both ear. It can be used as a fundamental platform for customer to develop hearables. Features Fitness tracking (pedometer, heart rate, etc.) Local playback (mp3, wav…) Voice UI (command trigger, ON/OFF) Voice enhancement (argument hearing, be forming) Universal translator Block Diagram Products Category MCU Product URL LPC541XX: Low-Power Microcontrollers (MCUs) Based on Arm® Cortex®-M4 Cores With Optional Cortex®-M0+ Co-processor  Product Description The LPC541xx MCU family of single-core and dual-core MCUs are our next-generation of power efficient MCUs.   Category NFMI Radio Product URL NXH2266: NFMI radio for wireless audio and data streaming  Product Description The NXP® NXH2266 is a fully integrated single-chip solution that enables wireless audio streaming and data communication using Near Field Magnetic Induction (NFMI), a mature technology that has a proven track record in the hearing industry.   Category Audio Codec Product URL SGTL5000: Ultra-Low-Power Audio Codec  Product Description The SGTL5000 is a low-power stereo codec designed to provide a comprehensive audio solution for portable products that require line-in, mic-in, line-out, headphone-out and digital I/O.   Category NFC Product URL NTAG I2C plus: NFC Forum Type 2 Tag with I2C interface  Product Description The NTAG I2C plus combines a passive NFC interface with a contact I2C interface.   Category Accelerometer Product URL MMA8652FC: ±2g/±4g/±8g, Low g, 12-Bit Digital Accelerometer  Product Description The NXP® MMA8652FC 12-bit accelerometer has industry-leading performance in a small package.   Category Power Management Product URL MC34673: 1.2 A Single-Cell Li-Ion/Li-Polymer Battery Charger  Product Description The MC34673 is a cost-effective fully-integrated battery charger for Li-Ion or Li-Polymer batteries.   Category Voltage Level Translator Product URL GTL2005PW: Quad GTL/GTL+ to LVTTL/TTL bidirectional non-latched translator  Product Description The GTL2005 is a quad translating transceiver designed for 3.3 V system interface with a GTL/GTL+ bus.

Demo See NXP breakthrough automotive designs using radar that enhance safety and the driver experience with ADAS and other safety applications Products S32R27 Radar Processor • CPU: Dual Z7’s with Lock-step Z4 enabling ASIL-D applications • Embedded memory: 2 MB Flash & 1.5 MB SRAM (both ECC) • Radar signal processing toolkit: best in class performance per power MR3003 Radar Transceiver • Fully integrated SiGe radar front end for 76-81 GHz • Tx 5-bit phase rotators, and Tx BPSK modulator • 3 transmitter and 4 receiver channels • ISO 26262 compliant – ASIL level B • Optimized for fast chirp modulation • Support for 4 GHz bandwidth TEF810X Radar Transceiver • Fully integrated RFCMOS radar front end for 76-81 GHz • 3 transmitter and 4 receiver channels • LVDS, CIF and CSI-2 interface • ISO 26262 compliant – ASIL level B • Lowest power: 1.2 W • Support for 4 GHz bandwidth

  Overview The Point of Sale reference design demonstrates how the control, security, and connectivity features found on the NXP ®  MCF5329 ColdFire ®  MPU and MCS908QG8 MCU work together to create a secure Industrial Point of Sale System. Complete with an Open Source Embedded Linux® Software Solution, the Point of Sale Reference Design serves as a reference for any industrial design that requires flexible connectivity options, secure communication, or a human interface at a low cost and with a fast development cycle. Archived content is no longer updated and is made available for historical reference only.   Features The Point of Sale Reference Design was designed with the following considerations: Low system cost Easy and intuitive graphical user interface Multiple connectivity solutions to accommodate various POS system connectivity requirements Secure networking communications, transactions, and memory accesses Fast development cycle The Industrial Point of Sale Reference Design also features an Open Source Software Solution: µCLinux Operating System running on the MCF5329 Microprocessor NanoX Graphical User Interface (GUI) Configuration Tool running in the µCLinux environment Communication protocol for secure ethernet transactions MySQL Server Database used to store/access sales transactions       Code Generation Tools Model-Based Design Toolbox Printed Circuit Boards and Schematics Point of Sale Reference Design Schematics Point of Sale Gerber Files (Reference Design)

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

本文为如下G2版本的升级篇，使用G3+更新的软件 目录 1    需要的软件与工具... 2 1.1  软件工具与文档... 2 1.2  开发说明... 3 2    测试软件安装编译说明... 3 2.1  安装LLCE Logger驱动... 3 2.2  编译LLCE驱动测试程序(以CAN Logger 为例) 4 2.3  Logger Demo功能说明... 5 2.4  M7 BootLoader ATF镜像冲突检查... 7 2.5  LLCE Logger Demo去掉CLOCK INIT. 9 2.6  LLCE Logger Demo去掉MCU 相关INIT. 10 2.7  LLCE Logger Demo程序去掉PORT INIT. 10 2.8  中断冲突说明... 10 2.9  去掉其它无用初始化... 11 3    Bootloader工程说明... 11 3.1  关掉XRDC支持... 12 3.2  关掉eMMC/SD支持(可选) 13 3.3  关掉secure boot(可选) 14 3.4  增加LLCE 驱动所需要的PORT 的初始化... 15 3.5  解决Bootloader,MCAL 与Linux 的clock 冲突... 16 3.6  配置A53 Boot sources: 34 3.7  配置M7 Boot sources: 36 3.8  关闭调试软断点... 37 3.9  编译Bootloader工程... 38 3.10 制造Bootloader的带IVT的镜像... 39 3.11 烧写镜像... 41 4    Linux LLCE logger功能修改... 42 4.1 ATF的修改... 42 4.2 Linux中关于LLCE配置... 44 4.3 LLCE相关初始化冲突说明... 45 5    测试... 46 5.1  硬件连接... 46 5.2  LLCE logger 测试过程... 46 S32G Boot customization doc how to run bootloader to run mcal&linux https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Bootloader-Customzition/ta-p/1519838

  Overview With the expansion of IoT technologies, it is required to count with special devices that allow, to the users, to count with the necessary tools to develop IoT-related projects in order to acquire an edge that allows improvement and optimization in the execution of any task. Use Cases IoT Gateway / Communication HUB devices can be used to work with: Cloud Services Network commissioning Encrypted Data Storage Block Diagram Product Category MCU Product URL LPC540XX: Power-Efficient Microcontrollers (MCUs) with Advanced Peripherals Based on Arm® Cortex®-M4 Core  Product Description Offering flashless design and security integration, the LPC540xx family of MCUs combines a 180 MHz Arm® Cortex®-M4 core with a power-efficient and unique architecture, advanced HMI and flexible communication peripherals for real-time performance in the next-generation IoT.   Category NFC 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 Secure 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 Wireless Product URL JN5169: ZigBee and IEEE802.15.4 wireless microcontroller with 512 kB Flash, 32 kB RAM  Product Description The JN5169 is an ultra low power, high performance wireless microcontroller suitable for ZigBee applications.

Overview New technologies added to existing applications like Elevators, help improve user experience, quality and safety. This application summary focuses on the human machine interface of the elevator in cabin control and floor control modules. NXP ®  technologies and products enhance different features, like NFC for access control, 2-wire Ethernet provides floor to floor connectivity, and PMICs provide power supply with safety features. With NXP’s wide connectivity portfolio, Elevators can have wireless cloud connectivity as back-up communication channel that supplement cellular radio communication for data logging, monitoring & maintenance or even to handle emergencies. Block Diagram Elevator Cabin Control Module Elevator Control Module Recommended Products Category Link MPU i.MX 8M Applications Processor | Arm® Cortex®-A53, Cortex-M4 | 4K display resolution | NXP  MCU i.MX RT1050 MCU/Applications Crossover MCU| Arm® Cortex-M7, 512KB SRAM | NXP  Audio Amp Audio Amplifiers | NXP  PMIC 12-channel configurable PMIC | NXP  LED Controller LED Drivers | NXP  CAN Transceiver TJA1051 | High-speed CAN Transceiver | NXP  Ethernet PHY Automotive Ethernet PHY Transceivers | NXP  MiFARE SAM MIFARE SAM AV3 | NXP  Signal Conditioner MSDI | NXP  CD1020|Multiple Switch Detect Interface | NXP  Contact Reader Low power single card reader | NXP  NFC Controller CLRC663 plus family | High-performance NFC frontends | NXP  MiFARE DESfire MIFARE DESFire | NXP  Safety Power Management FS4500 | fail silent safety SBC compliant grade1 & grade 0 automotive qualification | NXP  Voltage Level Translator Voltage Level Translators (Level Shifters) | NXP  Motor Drivers BLDC, H-Bridge, and Stepper Motor Drivers | NXP