This doc explain our Linux BSP driver and how to custom them. Contests as follows: include bsp30/32 目录 1 S32G Linux文档说明 ................................................. 2 2 创建S32G RDB2 Linux板级开发包编译环境 .............. 2 2.1 创建yocto编译环境: ................................................ 2 2.2 独立编译 ................................................................. 8 3 Device Tree ............................................................. 11 3.1 恩智浦的device Tree结构 ..................................... 11 3.2 device Tree的由来(no updates) ............................ 13 3.3 device Tree的基础与语法(no updates) ................. 15 3.4 device Tree的代码分析(no updates) .................... 37 4 恩智浦S32G BSP 包文件目录结构 .......................... 70 5 恩智浦Linux BSP的编译(no updates) ...................... 72 5.1 需要编译哪些文件 ................................................ 72 5.2 如何编译这些文件 ................................................ 73 5.3 如何链接为目标文件及链接顺序 ........................... 74 5.4 kernel Kconfig ...................................................... 76 6 恩智浦BSP的内核初始化过程(no updates) .............. 76 6.1 初始化的汇编代码 ................................................ 78 6.2 初始化的C代码 ..................................................... 82 6.3 init_machine ......................................................... 94 7 恩智浦BSP的内核定制 ............................................. 97 7.1 DDR修改 .............................................................. 98 7.2 IO管脚配置与Pinctrl驱动 .................................... 100 7.3 新板bringup ........................................................ 121 7.4 更改调试串口 ...................................................... 125 7.5 uSDHC设备定制(eMMC flash,SDcard, SDIOcard) 129 7.6 GPIO驱动 ........................................................... 137 7.7 GPIO_Key 驱动定制 .......................................... 145 7.8 GPIO_LED 驱动定制 ......................................... 150 7.9 芯片内thermal驱动 ............................................. 155 7.10 CAN接口驱动 ..................................................... 157 7.11 I2C及外设驱动 .................................................... 162 7.12 SPI与SPI Slave驱动 ........................................... 183 7.13 Watchdog test. ................................................... 190 7.14 汽车级以太网驱动定制 (未验证) (未完成) ........... 191

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

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

This doc explain how to build a PFE master project on M7 and how to integration. chinese version. 目录 1 需要的软件与工具 ...................................................... 2 2 Master Demo编译说明 ............................................... 2 2.1 安装RTD_MCAL驱动 ............................................. 2 2.2 安装PFE_MCAL驱动 .............................................. 3 2.3 编译PFE master工程 .............................................. 3 3 修改为支持RDB板的RGMII接口 ................................ 4 3.1 硬件连接 ................................................................. 4 3.2 软件修改 ................................................................. 5 4 Master Demo测试 ...................................................... 7 4.1 硬件连接 ................................................................. 7 4.2 PFE_EMAC1(RGMII)测试过程 ............................... 7 5 Master Demo代码说明 ............................................... 8 6 集成中注意点 ........................................................... 11 6.1 PFE_PreInit .......................................................... 11 6.2 S32G3中的GENCTRL1的配置 ............................. 12 6.3 RX CLOCK重新锁定 ............................................ 13 7 Demo Debug建议 .................................................... 14 7.1 PFE相关寄存器说明 ............................................. 14   Contents 1 Required software and tools ...................................... 2 2 Master Demo compiling ............................................. 2 2.1 Install RTD_MCAL driver........................................ 2 2.2 Install PFE_MCAL driver ........................................ 3 2.3 Compile PFE master project .................................. 3 3 Change the demo to support RDB3 board RGMII port4 3.1 Hardware design .................................................... 4 3.2 Software modification ............................................. 5 4 Master DemoTest ...................................................... 7 4.1 Hardware design .................................................... 7 4.2 PFE_EMAC1(RGMII) test steps ............................. 7 5 Master Demo code flow ............................................. 8 6 Notes in integration .................................................. 11 6.1 PFE_PreInit .......................................................... 11 6.2 The GENCTRL1 configruation of S32G3 ............. 12 6.3 RX CLOCK relock ................................................ 13 7 Demo Debug suggestion ......................................... 14 7.1 PFE related registers ........................................... 14

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

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

  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

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 

LPC54114 Audio and Voice Recognition Kit The LPC54114 Audio and Voice Recognition Kit provides a complete hardware and software platform for developers to evaluate and prototype with the LPC54114 processor family. It has been developed by NXP® to provide all that you need to develop an always-on low power voice triggering product. Features: LPCXpresso54114 (OM13089) development board with: LPC54114 dual-core (M4F and dual M0) MCU running at up to 100 MHz in LQFP64 package. Hi-speed USB based debug probe with CMSIS-DAP and SEGGER J-Link OB protocol options. Connectivity for external debug probes. Micro USB connector for LPC54114 USB device operation. Tri-color LED. Target Reset, ISP and interrupt/user buttons. On-board 1.8 V / 3.3 V or external power supply options. 8 Mb Macronix MX25R SPI flash. FTDI UART connector and built-in UART to USB bridge options. Built-in MCU power consumption and supply voltage measurement for LPC54114 device. UART, I²C and SPI port bridging from LPC54114 target to USB via Link2 device. FTDI UART connector. Digital Mic/Audio codec/OLED display (“MAO”) shield with: Knowles SPH0641LM4H digital microphone. Cirrus Logic (Wolfson) WM8904 audio codec with stereo line in/out sockets. Monochrome OLED display (160 x160 pixels). Demos: Include USB/I2S audio demo, as well as voice recognition demos leveraging partner technology (Malaspina and Sensory) http://cache.nxp.com/documents/application_note/AN11855.zip Videos: These videos showcase the NXP’s LPC54114 MCU in a kit designed for customers to evaluate its capabilities for audio and voice processing _______________________________________________________________________________________________________ Featured NXP Products: Product Link LPC54000 Series LPC54000|Power Efficient 32-bit Microcontrollers (MCUs)|Cortex®-M4 Core | NXP  LPC54114 Audio and Voice Recognition Kit https://www.nxp.com/design/microcontrollers-developer-resources/lpcxpresso-boards/lpc54114-audio-and-voice-recognition-kit:OM13090?&fsrch=1&sr=1&pageNum=1 _______________________________________________________________________________________________________

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:    

  本文说明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

Demo This demo shows an infotainment and ADAS system based on NXP Ethernet components and is divided in three main parts: Infotainment, Network and ADAS. In the infotainment part, a “Head Unit” ECU plays locally an MPEG movie and also streams it over Ethernet to the second “Rear Seat Unit” ECU. Both ECUs also execute in the backroad the NXP AVB SW stack. This enables the two ECUs to be perfectly synchronized with each other. Therefore the two ECUs can playback the very same video (and audio) frame at the same time on their local displays. In the network part the new Automotive Ethernet Switch (SJA1105EL) and PHYs (TJA1100HN) implement the Ethernet connectivity of the system. The switch executes the AVB “gPTP” synchronization SW that enables the infotainment application described above to operate. In the ADAS part a surround view camera captures a video stream and streams it to a “Cluster” ECU also connected via the automotive Ethernet network. The camera is based on the NXP “MPC5604E ” Salsa processor and on a competitor’s BroadR-Reach PHY. This also shows the interoperability of the TJA1100HN PHY with competitor’s products. Features: All displays are implemented with NXP i.MX6 processor, and a full implementation of the NXP Ethernet AVB Stack running on Linux. The camera is based on an NXP Salsa processor (MPC5304EKIT) . The Switch board that connects all displays and the camera uses the NXP SJA1105EL Automotive Ethernet switch and the TJA1100HN BroadR-Reach Ethernet PHY ______________________________________________________________________________________________________________ Featured NXP Products: Product Link IEEE 100BASE-T1 compliant Automotive Ethernet PHY Transceiver TJA1100HN | Automotive Ethernet PHY Transceiver | NXP  i.MX 6 Series i.MX 6 Series Applications Processors | Multicore Arm Cortex-A7/A9/M4 | NXP  Audio Video Bridging Software https://www.nxp.com/design/design-services/audio-video-bridging-software:AVB-SOFTWARE?&fsrch=1&sr=4&pageNum=1 Development Kit Enabling Video Over Ethernet with NXP® MPC5604E MCU NXP® MPC5604EKIT:Development Kit | NXP  ___________________________________________________________________________________________________________

Near Field Communication (NFC) is hot. It is available in hundreds of millions of smartphones, tablets, and other consumer electronics, and enters more and more the industrial space as well. This article shows how to implement the demos of our "Industrial NFC Demonstrator", first exhibited at embedded world 2017 in Nürnberg.           Parameterization & Diagnosis This demo shows how you can use an NFC phone to parameterize/configure a DIN rail module (or any other piece of electronics) with an NFC phone - even if the module is completely unpowered. The smart phone app lets you set the behavior of the lamps and also the language of the display. After the configuration (a simple tap) you switch on the main power, and the device comes up as configured. And NFC also lets you read out diagnostic data - no matter whether the device is powered on or off. So you can even replace your service UART by NFC. Thirdly, the demo shows how easy it is to even flash your firmware via NFC. Again, this works even when the device is switched off. This application is based on the NTAG I²C plus passive connected tag IC. See here a video from embedded world 2017 showing this demo.   Find a detailed description and all source codes here: https://community.nxp.com/docs/DOC-333834  Interested how this looks like in a commercial product? Watch this video showing how easily the Schneider Zelio NFC Timer Relay can be configured via NFC.   Device-to-device communication In this demo you see how NFC can establish a communication between 2 devices with up to 40 kbit/s. The angular position of the rotating disk is measured, communicated to the main board via NFC and displayed on an LED ring. The nice thing: The rotating disk is without battery. Energy harvesting via NFC provides supply power up to 15mW. This principle of using NFC as a cable replacement is especially interesting in cases where you want to communicate with fully sealed, isolated, moving or rotating units. The communication is bi-directional, and the data can be static (a button press, or configuration data) or dynamic (sensor measurements). The demo is based on the CLRC663 plus reader on the main unit and the NTAG I²C plus passive connected tag on the rotating disk. See here the video from embedded world 2017 demonstrating this application.   Find a detailed description and all source codes here: https://community.nxp.com/docs/DOC-333917       Access control In the Physical Access Control demo, we show a simple implementation of a basic access control solution using a Type 4 tag and a CLRC663 plus based reader, based on the public NFC Reader Library. NXP recommends for a complete real-life access control solution to use MIFARE DESFire credentials as with the MIFARE DESFire EV2 card. Supporting software library is under NDA. In this video from embedded world 2017 you see access control in action.   Download the source code here: http://nxp.com/assets/downloads/data/en/software/RC663Demo_ReadNdefT4T_v1.2.zip           1-tap Bluetooth Pairing This demo shows how easy it is to pair wireless devices to your phone with NFC - using an example of the Kinetis KW41 Freedom board (BLE MCU), with an NTAG I²C plus kit for Arduino® pinout for the NFC function. This new NTAG I²C plus kit is suitable for any board featuring an Arduino-compatible header, including LPCXpresso, Kinetis and i.MX boards. It is the ideal tool to evaluate and design-in an NTAG I²C plus tag chip in an embedded electronic system. Find a detailed description and all source codes here: https://community.nxp.com/docs/DOC-335241     Automation with Hexiwear A nice example of how to build versatile applications, is shown in the automation demo with the Hexiwear IOT development platform. Based on Kinetis MCUs and hundreds of available click-boards (plug-ins with sensors, actuators, transceivers - and of course also NFC), you can quickly build a prototype of your application. Two NFC-based click-boards are available: 1) A reader board based on PN7120 2) A board with NTAG I²C plus The automation demo uses 3 different Hexiwear base boards, connected between them via Zigbee. The NFC unit identifies a technician's badge, and also the tools he uses for his job. The second unit drives the instrument panel, and the third one the big LED screen. A video from embedded world 2017 shows how this works.   Find more information on Hexiwear at www.hexiwear.com.   Our partners in the NFC industrial demonstrator We would like to extend a special thanks to our partners who contributed to this demonstrator: Lab ID and Arti Grafiche Julia: NFC/RFID cards, tickets, labels and inlays Kronegger: Demo on logical access control, NFC reader modules and customized solutions Neosid: Small NFC/RFID transponders for tool identification and authentication   Find out more Discover NFC Everywhere: www.nxp.com/nfc All about MIFARE: https://www.mifare.net Get your technical NFC questions answered: https://community.nxp.com/community/nfc

This article explains the details and customization of the S32G M7 core Standby demo. And how to porting to Autosar Mcal demo. Contents 1    Description of reference materials. 2 2    Demo creation and running process. 2 2.1  Demo checkpoints. 2 2.2  The difference between Standby and StandbyRAMboot 4 3    S32G Standby principle and Code Description. 5 3.1  Peripheral initialization function. 5 3.2  standbyramc_cpy(optional) 5 3.3  WKPU_set 8 3.4  standby_modechange. 13 4    VR5510 PMIC Standby principle and code description. 15 4.1  PMIC_initConfig. 15 4.2  PMIC_standbyEntry. 17 5    Customization modification. 18 5.1  Do not enable RTC wakeup feaure. 18 5.2  Eable CAN1_RX wakeup feature. 19 5.3  Only support full boot 21 5.4  Open the DDR related power 21 5.5  Modify debug serial port to UART1. 24 5.6  Modify the device drive clock. 26 5.7  close other non-main core. 30 6    Build a new MCAL demo. 34 6.1  Modify the UART driver 35 6.2  Implement the clock shutdown code. 36 6.3  Configure the power mode switching driver 37 6.4  Confgure the wakeup source. 42 6.5  Add PMIC driver 51 6.6  Main function call routine. 59 6.7  Test 61 6.8  Future development plan. 62 本文说明S32G M7核Standby demo 详细情况及定制,以及如何新建一个mcal demo 录 1    参考资料说明... 2 2    Demo创建运行过程... 2 2.1  创建运行... 2 2.2  Standby和StandbyRAMboot的区别... 4 3    S32G Standby原理与代码说明... 5 3.1  外设初始化函数... 5 3.2  standbyramc_cpy(可选) 5 3.3  WKPU_set 8 3.4  standby_modechange. 13 4    VR5510 PMIC Standby原理与代码说明... 14 4.1  PMIC_initConfig. 14 4.2  PMIC_standbyEntry. 16 5    定制修改... 17 5.1  关闭RTC唤醒功能... 17 5.2  打开CAN1_RX唤醒功能... 19 5.3  只支持full boot 20 5.4  打开DDR相关电源... 21 5.5  修改调试串口为UART1. 23 5.6  修改设备驱动时钟... 25 5.7  事先关掉所有其它的非主核... 29 6    修改为MCAL Demo. 33 6.1  修改UART驱动... 34 6.2  实现时钟关闭代码... 35 6.3  配置电源模式切换驱动... 36 6.4  配置唤醒源... 41 6.5  加入PMIC驱动... 50 6.6  主函数逻辑实现... 58 6.7  运行测试... 60 6.8  未来开发计划... 61   attachment include chinese/english doc, s32ds codes with 2 zip package(remove the .7z), mcal codes.  

    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

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

NXP's secure over-the-air communication for automotive networks features embedded hardware crystallographic engine for the rapid decryption of received data.   Features   MPC5748G targets High-End Body and High-End gateway Rich communication peripheral set & HSM - embedded Security Module Encryption, decryption, message code generation, secured flash memory for secured storage Secured communication inside or outside the vehicle (wired or wireless) Encryption with different algorithms demo Decryption in both hardware (HSM) or software comparison Links High End Body Control Module Central Gateway / In-Vehicle Networking Block Diagram  

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

NFC Tandem offers best of both worlds: An NFC reader and a passive connected tag sharing one antenna. A user can interact with the device when it is powered off (through the NTAG I²C plus); when the device is powered, it can interact with cards, P2P devices or other connected tags.                                                             NFC Tandem Uses Cases and Applications: One-touch pairing WiFi with phone, or card Bluetooth with phone, headset, speaker IoT network node commissioning User identification with badge or phone Authentication and configuration of consumable and accessory Zero-power parametrization Zero-power firmware update Zero-power diagnosis and maintenance NFC Tandem Demo: NFC Tandem concept is demonstrated using NFC Tandem reference board: The demo can run on either: UDOO Neo Download UDOO Neo demo image or Raspberry Pi Download Raspberry Pi demo image Video of the demo: <script src="https://players.brightcove.net/6153537070001/default_default/index.min.js"></script>(view in My Videos) NFC Tandem References: PN7150 High performance NFC controller, supporting all NFC Forum modes, with integrated firmware and NCI interface NTAG I²C plus NFC Forum Type 2 Tag with I²C interface NFC Tandem Documents: User Manual and reference schematics are attached to this document

  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.