APF-DES-T2297 - LPC MCUを使用した次世代組み込みアプリケーションに有線接続およびグラフィックス機能を追加 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> LPCXpressoエコシステムを使用してアプリケーションを開発するための詳細なセッション(USBおよびイーサネットスタック、組み込みエンジニアがUSBアプリケーション開発を成功させるために必要な無料のemWinライブラリなど)。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> LPCXpressoエコシステムを使用してアプリケーションを開発するための詳細なセッション(USBおよびイーサネットスタック、組み込みエンジニアがUSBアプリケーション開発を成功させるために必要な無料のemWinライブラリなど)。

NXP ARMマイクロコントローラのソフトウェア暗号化 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> はじめに さまざまなLPC ARMマイクロコントローラで実行されるソフトウェア暗号化には、いくつかのオプションがあります。これらのオプションの中には、NXPから無料で提供されているものもあれば、無料のオープンソースソリューションであるものもあれば、第三者からのロイヤリティベースの暗号化製品もあります。これらの異なるソリューションには、コスト、メモリフットプリント、パフォーマンス、サポートレベルのトレードオフがあるため、プロジェクトのニーズに最も適したライブラリを選択してください。 リンク アプリケーションノート:LPC MCU上のAES暗号化および復号化ソフトウェア(zipファイル) Cypherbridge システム: uSSL および CDK リアルタイムロジック:SharkSSLライブラリ リアルタイム ロジック: ARM Cortex-M0 ベンチマーク セキュリティ・イノベーション:LPC2000 ARM7用の暗号化ライブラリ MetratecのLPC1200ブートローダー Polar SSLオープンソース暗号化ライブラリ Cya SSL オープンソース暗号化ライブラリ 「これらのページで使用されているその他すべての商標、製品名、商号、およびロゴは、それぞれの所有者に帰属します。」

NAND坏块标记 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 即使是新的，NAND 设备也可能有坏块。坏块可能是某个位发生故障或无法正确擦除的块。供应商通常会为每个部件提供已知现有坏块的预建地图。工厂坏块在每个块的第一页上的工厂坏块标记偏移量中用非 0xFF 值进行标记。 对于小页设备，此工厂偏移量通常为页面中的字节 516 和 517。对于大页面设备，此工厂偏移量通常为 2048。您可以通过扫描 NAND 设备上每个块的第一页并检查数据中的工厂坏块标记偏移量中的值是否为非 0xFF 值来获取坏块列表。 SLC NAND 控制器和所有 NXP 为 SLC NAND 控制器开发的软件（Linux、WinCE 或独立软件）使用与工厂标记相同的位置进行坏块标记和检测。因此，NAND 设备不需要对坏块进行特殊处理或重新定位。 MLC NAND 控制器只能以 528 字节的块读取和写入带有 ECC 的数据。因此，数据和 ECC 值在 NAND 页面中交错。此方案的工厂坏块标记无法使用。如果必须将 MLC NAND 控制器用于芯片启动以外的任何用途，则需要在将数据写入设备之前记录并移动工厂坏块标记。对于使用 MLC 控制器在 LPC32x0 上进行 NAND 启动的块 0，任何 NXP 软件均不使用坏块检测或标记。这是因为 NAND 设备制造商通常只保证有限次数（即 1000 次）写入周期内块 0 的数据可靠性。

S12 系列设备 COP 识别注意事项 - Calculator.xlsx <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> S12 FAMILY DEVICES COP RECOGNITION CONSIDERATIONS_v2.0.pdf中描述的理论 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> S12 FAMILY DEVICES COP RECOGNITION CONSIDERATIONS_v2.0.pdf中描述的理论 概述

通过删除项目中不需要的前端 IC 文件夹，使 NFC 读取器库更易于读取 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> NFC 阅读器库支持多个前端。对于客户来说，如果只需要其中一个前端芯片的部件，这可能会变得更加难以使用。 为了增强可读性和可用性，您可以通过删除 NxpRdLib/comps/phhalHw/src 下的文件夹来删除对未使用的读取器 IC 的支持。例如：如果您只想使用 RC663，您可以简单地删除文件夹 Pn5180、Rc523。结果将是一个仅支持 RC663 的库。 这个简短的屏幕录像显示了减少支持的前端数量的步骤。 （在 “我的视频” 中查看） NFC 前端解决方案 NFC读卡器库

DES-N1957 Kinetis Enablement 业界最全面的软件工具组合 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 使用业界最广泛的工具和支持产品开始利用 Kinetis MCU 进行开发。了解 Kinetis 软件开发套件 (SDK)、Kinetis Design Studio、Kinetis Bootloader、FreeRTOS 和其他实时操作系统。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 使用业界最广泛的工具和支持产品开始利用 Kinetis MCU 进行开发。了解 Kinetis 软件开发套件 (SDK)、Kinetis Design Studio、Kinetis Bootloader、FreeRTOS 和其他实时操作系统。 设计 | 软件与服务

ftf-ins-f1222.pdf Accelerometers, Magnetometers, Gyroscopes, Pressure Sensors. Gathering sensor data at 400 samples per second, on 9 axes, results in 700 MB of data per day. This hands-on class will show what information is contained in sensor data and how to reduce the amount of recorded data dramatically without any major loss of targeted information. They will then compare data between dumb and intelligent data loggers, and understand the techniques used to compress the information. Accelerometers, Magnetometers, Gyroscopes, Pressure Sensors. Gathering sensor data at 400 samples per second, on 9 axes, results in 700 MB of data per day. This hands-on class will show what information is contained in sensor data and how to reduce the amount of recorded data dramatically without any major loss of targeted information. They will then compare data between dumb and intelligent data loggers, and understand the techniques used to compress the information.

FTF-INS-F1277 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 汽车集成电路需要高温、高压的应用环境。高温、高电压对IC互连设计以及组装封装工艺所用的材料提出了严格的限制。细规格铜线键合在消费、便携式和工业电子产品中的应用增长非常迅速。飞思卡尔在高可靠性汽车领域引入和加速采用细规格铜线方面取得了重大进展。对成型化合物进行了研究并重新配制，以适应高达 65V 的高电压。本次演讲将讨论铜线键合工艺和成型化合物配方开发中的关键知识，并介绍飞思卡尔关于金线到铜线转换战略的激动人心的最新进展。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 汽车集成电路需要高温、高压的应用环境。高温、高电压对IC互连设计以及组装封装工艺所用的材料提出了严格的限制。细规格铜线键合在消费、便携式和工业电子产品中的应用增长非常迅速。飞思卡尔在高可靠性汽车领域引入和加速采用细规格铜线方面取得了重大进展。对成型化合物进行了研究并重新配制，以适应高达 65V 的高电压。本次演讲将讨论铜线键合工艺和成型化合物配方开发中的关键知识，并介绍飞思卡尔关于金线到铜线转换战略的激动人心的最新进展。

KSDK GPIOドライバーとProcessor Expertの <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> このビデオでは、Processor Expertを使用して、Kinetis Design Studioのコンポーネント fsl_gpio でKSDK GPIOペリフェラル・ドライバを構成する方法を示します。 この手順は、FRDM-K2FのSW64ボタン入力を読み取っているときに、赤と青のLEDを点滅させる方法を示しています。この手順は、KSDK がサポートする任意のボードで、また PE Driver Suite でも再現できます。楽しむ！ (マイビデオで視聴) 全般 日時:プロセッサエキスパートとKSDK GPIOドライバ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 初心者プログラマーのための優れたビデオ、あなたはこのようなものをもっと作成できますか?、お願いします。 また、ビデオでは、各ピンをgsl_gpioで設定しているため、pin_init:Pinsettingsを設定していませんが、init:Pinsettingsでgpioを設定するとどうなりますか?また、fsl_gpioとfsl_gpio_halとの(プログラムの)違いは何でしょうか? 感謝 カルロスE.

规则 - 2015 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 注册要求 最低技能 需要具有 C 或 Java 的使用经验。 需要具有 Linux 系统使用经验。 具有嵌入式编程经验者优先，但不是必须的。 团队 来自布加勒斯特理工大学或军事技术学院的一至三名成员。 2015年Linux嵌入式挑战赛

フリースケールi.MX6によるデジタルサイネージ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> デジタルサイネージは、i.MX6プロセッサが最適であるアプリケーションです。ハードウェアのエンコードとデコード、ビデオの出力と入力、処理能力により、デジタルサイネージにi.MX6を使用することは非常に人気があります。 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> デジタルサイネージは、i.MX6プロセッサが最適であるアプリケーションです。ハードウェアのエンコードとデコード、ビデオの出力と入力、処理能力により、デジタルサイネージにi.MX6を使用することは非常に人気があります。 全般

Kinetis Design Studio: Migrating KDS V2.0.0 Projects to GNU Tools for ARM Embedded (Launchpad, KDS V3.0.0) Introduction Up and including to version 2.0.0, the Kinetis Design Studio (KDS) is using a custom GNU toolchain built by SOMNIUM Technologies, referred here as 'legacy'. That toolchain is built from the Free Software Foundation (FSF) source base, with a few minor modifications. Starting with v3.0.0, KDS will use the unmodified GNU Tools for ARM Embedded (launchpad, GCC ARM Embedded in Launchpad) toolchain (4.8-2014-q3-update : Series 4.8 : GCC ARM Embedded release), referred here as 'launchpad'. Projects created with KDS v3.0.0 will use the 'launchpad' tools by default. The reasons for 4.8-2014-q3 instead of using the later 4.9 release is because of stability and smaller footprint of 4.8 applications.   Outline This document outlines what are the differences between the 'legacy' and 'launchpad' toolchain, and what is needed to port existing 'legacy' projects to the 'launchpad' ones. It is already possible to use the 'launchpad' tools with KDS v2.0.0 today (see Switching ARM GNU Tool Chain and Libraries in Kinetis Design Studio | MCU on Eclipse), therefore the information in this document can be applied to KDS v2.0.0 to with using the 'launchpad' toolchain.   KDS Upgrade Assistant Kinetis Design Studio V3.0.0 comes with a migration assistant to migrate projects to the GCC ARM Embedded (launchpad) tools. The migration assistant is accessible from the menu Project > KDS Upgrade Assistant: This opens a dialog with the currently open projects in the workspace:   NOTE: if the Upgrade Assistant does not list your project, then you still can do the manual steps as listed below (changing the linker flags).   Select the project(s) you want to migrate and press Next. In the next dialog you can configure the details of the conversion, then press Finish: A report will be generated in each project directory:   Migration of KDS Projects To migrate an existing 'legacy' project to a 'launchpad' project, usually only the linker settings need to be changed. For this go into the project properties, and check the 'Other linker flags' settings of the Linker. The table below shows the difference between the two: Legacy 'Other linker flags' Launchpad 'Other linker flags' -specs=nosys.specs -nanolibc -specs=nano.specs -specs=nosys.specs   For example this project is a legacy project using the newlib-nano library: To use it with the 'launchpad' toolchain, use -specs=nano.specs -specs=nosys.specs as shown below: With this, normally projects are converted from the 'legacy' to the 'launchpad' toolchain.   NOTE: after switching toolchains, delete all intermediate or object files (e.g. delete the Debug/Output folder inside the project. Mixing object files or libraries from different toolchains and compilers will likely cause problems.   Now your project should compile fine. However, if you face a problem about wrong Thumb mode, see the following subsection.   Wrong or missing Thumb mode If getting errors like      Error: selected processor does not support Thumb mode      error: interrupt Service Routines cannot be coded in Thumb mode This means that the project settings do not properly pass the processor to the compiler. That problem mainly occurs with Kinetis SDK projects, and with Cortex-M0+ (Kinetis-L) projects. As explained in the next section, the launchpad tools by default use the ARM, not the thumb mode. The solution is to add      -mcpu=cortex-m0plus for these Kinetis-L projects to the compiler 'Other target flags'.   The following sections provide more detailed information about the differences.     Differences Both the 'launchpad' and the 'legacy' toolchains are GNU toolchains, and largely compatible. However there are notable differences between the two toolchains:   legacy launchpad GNU Binaries Microsoft 32bit binaries, Linux 64bit binaries Microsoft 32bit binaries, Linux 32bit binaries(1) GNU binutils 2.32.2 2.23.2.20140731(*) GCC 4.8.0(*) 4.8.4 (ARM/embedded-4_8-branch) NewLib 1.19.0(*) 2.1.0(*) Newlib-nano 1.0(*) 2.1 GDB 7.6(2) 7.6.0.20140731-cvs(2) ARM Mode Thumb ARM (non-Thumb) (*) Modified. (1) See next section about running 32bit GNU tools on 64bit Linux. (2) The legacy GDB has Python support, while this is not present in the launchpad 4.8-2014-q3 build. Python support has been added by ARM in 4.9-Q4-2014 release.   Launchpad 32bit Binaries to run on 64bit Linux Because the 'launchpad' tools are 32bit binaries on Linux only, this can cause issues on 64bit Linux systems (e.g. Ubuntu 14.04 64bit) if the needed 32bit support libraries are not installed. A usual error message is that arm-none-eabi-gcc could not be found, even if that file is present, because the system does not know how to run it. This is because the 'launchpad' tools are built as 32bit binaries, an the compatibility package needs to be installed. See http://gnuarmeclipse.livius.net/blog/toolchain-install/ how to install the necessary compatibility libraries for Linux.   ARM Default Mode The default options for the 'legacy' toolchain produce code for the ARM Cortex-M0+ (Thumb mode), while the 'launchpad' tools default to the 'ARM' mode (non-Thumb). Therefore it is important that the command line options -mthumb with the appropriate -mcpu= or -march= options are used if using the tools in command line only mode. If using the GNU ARM Eclipse plugins, then no changes are needed as these options are set in the project already:     Default Libraries and Options The GNU compiler driver and linker is using default pre-built libraries in certain sub directories. These directories contain a default set of libraries, based on the compiler and architecture options specified during the build and link phase. Using linker options like -L to include a specific library or using options like -nostdlib or similar have an effect which libraries in which subdirectory are used. The library folder location is in \toolchain\arm-none-eabi\lib   The following table lists the specific options used for both the legacy tools and launchpad tools to link for a specific architecture and floating point ABI used: Target Legacy Options Legacy Subdir Launchpad Options Launchpad Subdir ARM Cortex-M0+ -mthumb -march=armv6s-m armv6-m ARM Cortex-M4 -mcpu=cortex-m4 m4 -mthumb -march=armv7e-m armv7e-m ARM Cortex-M4F -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 m4/fp/v4-sp-d16 -mthumb -march=armv7e-m -mfloat-abi=hard -mfpu=fpv4-sp-d16 armv7e-m/fpu ARM Cortex-M4F with softfp ABI -mcpu=cortex-m4 m4 -mthumb -march=armv7e-m -mfloat-abi=softfp -mfpu=fpv4-sp-d16 arm7e-m/softfp   Newlib-nano Both the legacy and the launchpad toolchain include the newlib-nano library, a standard library more optimized for embedded devices than the normal newlib one. The option to select the newlib-nano library is different: Newlib-nano for Legacy Newlib-nano for Launchpad -nanolibc --specs=nano.specs   Application _start() The startup code needs to call the _start() function of the library which then calls the main() function. The _start() function in the library is responsible to initialize the library and prepare it to be used by the application. In order to do this, the library needs to have the __stack symbol defined in the linker file which points to the top of stack. For this, the __stack symbol needs to be defined in the linker file as in the example below: /* Highest address of the user mode stack */ _estack = 0x20000000;    /* end of m_data */ __SP_INIT = _estack; __stack = _estack;   Semihosting The legacy library has semihosting included in the libraries, and users can use _isatty() and _write() to overwrite the existing semihosting hooks. With the launchpad tools semihosting is enabled with the -specs=rdimon.specs linker option, and users can implement their own hooks with _sbrk(), _write(), _close(), _fstat(), _isatty(), _lseek() and _read(). To completely disable semihosting, the options -specs=nosys.specs can be passed to the linker.   Application Exit Function The legacy library includes a default implementation of _exit(), while the launchpad tools do not include this. Using the -specs=nosys.specs linker option will ensure that the linker does not complain about the missing _exit() function.   Summary A typical legacy Kinetis Design Studio (KDS) V2.0.0 project can be easily migrated to the launchpad toolchain with adding -specs=nosys.specs linker option and replacing the -nanolibc legacy option with -specs=nano.specs linker option.   Links Kinetis Design Studio: Kinetis Design Studio Integrated Development |Freescale GNU Tools for ARM Embedded: GCC ARM Embedded in Launchpad Q3 2014 GNU Tools for ARM Embedded Release: 4.8-2014-q3-update : Series 4.8 : GCC ARM Embedded Blog article about how to switch KDS toolchain: Switching ARM GNU Tool Chain and Libraries in Kinetis Design Studio | MCU on Eclipse GNU ARM Eclipse plugin website and blog by Liviu: Welcome to the GNU ARM Eclipse plug-ins! | GNU ARM Eclipse Article by Liviu how to install toolchain: http://gnuarmeclipse.livius.net/blog/toolchain-install/ General Re: Kinetis Design Studio: Migrating KDS V2.0.0 Projects to GNU Tools for ARM Embedded (Launchpad, KDS V3.0.0) It seems that your project already has a file exit.c with _exit() in it, so you do not need to do this last step. Erich Re: Kinetis Design Studio: Migrating KDS V2.0.0 Projects to GNU Tools for ARM Embedded (Launchpad, KDS V3.0.0) Hi Erich, I have tried to use the "KDS upgrade assistant" tool to migrate KDS2.0 projects with KSDK1.1 to KDS3.0 version. I am trying to convert the KSDK libs, MQX libs, USBH libs and usb host demo projects. All succeeded except the usb host demo. I got a failure message as follows.   Project name: host_msd_fatfs_frdmk64f_mqx_frdmk64f   Project location: C:/Freescale/KSDK_1.1.0/usb/example/host/msd/msd_fatfs/sdk/kds/host_msd_fatfs_frdmk64f_mqx   Conversion status: failure.   Add exit() file failure: A resource exists with a different case: '/host_msd_fatfs_frdmk64f_mqx_frdmk64f/sources'. So do I need to apply the last step in upgrade option? Hao Re: Kinetis Design Studio: Migrating KDS V2.0.0 Projects to GNU Tools for ARM Embedded (Launchpad, KDS V3.0.0) I found this guide very useful, thoughI think it is worth mentioning that launchpad toolchain in KDS3.0.0 has no support for C++ exceptions. Any throw will cause the execution to end up in the unhandled exception handler regardless a suitable catch is available in the call chain. (See: Question #230716 : Questions : GCC ARM Embedded ) Best Re: Kinetis Design Studio: Migrating KDS V2.0.0 Projects to GNU Tools for ARM Embedded (Launchpad, KDS V3.0.0) Hi BlackNight​, thanks for sharing this document.  I have a question regarding the project conversion process.  For those project previously written using KSDK 1.1, KDS 3.0 is going to ask us to install the KSDK 1.1.0-GA update: When I first loaded the project, I clicked "Skip loading", and then proceeded with the project conversion.  It completed successfully.  My thought was that after closing and re-opening the upgraded project, I would no longer get this message.  However, that's not the case. At this point, I'm not sure what to do because I don't know how the 1.1.0-GA update will interact in KDS 3 when the 1.2.0-GA update is already installed.  I do know that clicking Continue loading results in a project that doesn't work.

启动 LS1046A 当闪存为空或镜像损坏时，如何启动板卡？当根据需求修改 RCW 后，如何从各种启动模式启动板卡？本文档将以全新的 LS1046ARDB 板卡为例介绍相关功能（文档中所有目标板均为 LS1046ARDB）。 内容 通过 CodeWarrior TAP 启动 LS1046A 从 SD 卡启动 从 RCW 源文件编译 PBL 二进制文件 将 PBL 二进制文件编译为固件 将固件编程到目标板（LS1046ARDB） 从QSPI启动 从 RCW 源文件编译固件 将固件编程到目标板（LS1046ARDB） 从eMMC启动 启用板载 eMMC 从 RCW 源文件编译固件 将固件编程到目标板（LS1046ARDB） QorIQ LS1设备

S32K344 - FOC with dual shunt current measurement S32K344 - FOC with dual shunt current measurement These examples demonstrate a 3-phase Permanent Magnet Synchronous Motor (PMSM) vector control (Field Oriented Control - FOC) drive with 2- shunt current sensing with and without position sensor. This design serves as an example of motor control design using NXP S32K3 automotive family. Examples were designed on S32K344 Brushless Direct Current and Permanent Magnet Synchronous Motor Control Development Kit.  C-project based examples are part of MCSPTE1AK344 Development Kit Application Software. An innovative drivers set, Real-Time Drivers (RTD),are used to configure and control the MCU. It complies with Automotive-SPICE, ISO 26262, ISO 9001 and IATF 16949. Production-ready Automotive Math and Motor Control Library set provides essential building blocks for algorithm. FreeMASTER is used as useful run-time debugging tool. Application software contains:  MCSPTE1AK344_PMSM_FOC_2Sh_ll - Low-level drivers of RTD and S32 Design Studio Configuration Tools (S32CT) are used to demonstrate non-AUTOSAR approach. Detailed description of the example can be found in application note AN13767. MCSPTE1AK344_PMSM_FOC_2Sh_as_tr - RTD, EB (Elektrobit) tresos Studio and S32 Design Studio are used to demonstrate AUTOSAR (AUTomotive Open System ARchitecture) approach. Detailed description of the example can be found in application note AN13884. MATLAB Simulink based project (Motor Control PMSM Example - s32k344_mc_pmsm_ebt) is build using Model-Based Design Toolbox (MBDT) and can be downloaded from NXP Model-Based Design Toolbox for S32K3xx - version 1.4.0 or newer releases. Example is described in article  3-Phase Sensorless PMSM Motor Control Kit with S32K344 using MBDT blocks. 

NXP's wireless router Solution: Connecting the Future of Smart Networking Experience In the era of digitization, concepts like smart homes and the Internet of Things (IoT) are continuously evolving. To realize these visions, a robust and efficient network infrastructure becomes crucial. OpenWRT, with its open-source nature, high customizability, and excellent stability, has become a key player in leading the future development of networks. NXP, as a global leader in semiconductor technology innovation, leverages its expertise in embedded systems and communication to introduce an intelligent network solution based on OpenWRT, empowering the flourishing smart home and IoT ecosystems. This article will explore the current status and ways to access NXP's chip support for the wireless router solution, enabling readers to build a solid foundation for the next generation of networks. 1. Unique Features of OpenWRT 1.1. Noble Value of Open Source Freedom OpenWRT stands out with its open-source nature, granting users unlimited freedom to access, modify, and share the source code, unlocking significant innovation potential. This openness not only drives continuous technological advancements but also allows users to take active control of the network direction, saving costs. 1.2. Stable and Reliable Network Foundation Built on a mature Linux kernel, OpenWRT undergoes extensive evolution and fine-tuning, ensuring outstanding system stability. This results in fewer network failures, longer device lifespans, and solid support for various network needs. OpenWRT becomes an ideal choice for building reliable home networks, alleviating concerns about network instability or crashes. 1.3. Powerful Software Package Management OpenWRT's proud software package management system provides users with great flexibility. Users can freely install, update, and uninstall various applications and services based on their needs, achieving a highly personalized network environment for a smarter networking experience. OpenWRT allows users to install various network services and applications such as VPNs and proxy servers to meet specific network requirements, providing greater freedom to create a network environment that suits individual or family needs. 1.4. Strong Community Support The vast OpenWRT community is the source of its powerful driving force. Users can exchange experiences, solve problems, and even participate in project development within the community. This collaborative spirit propels continuous innovation and progress in OpenWRT. 2. Applications of NXP wireless router Solution 2.1. Construction of Smart Home Ecosystem The seamless integration of NXP's wireless router solution with the NXP Matter solution provides an ideal platform for users to build smart home ecosystems. With its powerful customization capabilities, users can easily connect, manage, and control various smart devices, creating a highly intelligent home environment. The solution integrates NXP's Bluetooth and Wi-Fi chip drivers, such as IW612, 88W9098, 88W8997, allowing users to effortlessly build an OpenThread Border Router (OTBR) or Zigbee Bridge based on OpenWRT. 2.2. Customized Network Services The NXP wireless router solution supports the customized installation of various network services and applications. Users can create personalized network services, such as VPNs, proxy servers, home routers, or gateways, based on their individual needs, achieving a more flexible networking experience. 2.3. Transmission of High-Definition Video Streams The transmission of high-definition video streams in smart homes imposes higher demands on network performance. NXP's wireless router solution, with its excellent network performance, combined with NXP's industrial-grade IP Camera solution, ensures users can smoothly enjoy high-definition video streams, providing a superior home entertainment experience. 2.4. Construction of Smart Security Systems Security systems are an essential part of smart homes. NXP's wireless router solution, with its advanced network security features, builds a more reliable and intelligent security system for users, enhancing home security. 3. NXP's Support for OpenWRT Given the numerous advantages and wide-ranging application scenarios of wireless router, NXP early on adapted to support OpenWRT. Full support has been provided for the entire Layerscape series processors, and mainstream IMX processors are also supported. The specific supported IMX platforms and details are as follows: Processor and Board Support         ARMv8                                             ARMv7       I.MX93EVK                                •      I.MX6ULL       I.MX8MPlus       I.MX8MMini       I.MX8MNano       I.MX8MQuad OpenWrt Version  Based on OpenWrt v23.05 from mainline (tag: v23.05.0-rc1) Toolchain: ARMV8: gcc-11.3, binutils-2.37 ARMV7: gcc-12.3, binutils-2.40 U-Boot Boot Loader IMX LF release, tag: lf-5.15.71-2.2.1 v2022.04 Linux Kernel       OpenWrt kernel 5.15.114 based on IMX SDK release kernel v5.15.71_2.2.1 Firmware       firmware-imx-8.18       firmware-sentinel-0.5.1 Main Features       Squashfs rootfs support on SD card.       Supported CLI and web configuation. - U-Boot: lf-5.15.71-2.2.1. - Arm Trusted firmware (TF-A) integration. - Boot from SDHC       Linux Kernel Core - Linux kernel 5.15.114 - Cortex-A53 (AARCH64), little endian for imx8m platform - Cortex-A55 (AARCH64), little endian for imx93 platform - Cortex-A7, little endian for imx6ull platform - 64-bit effective kernel addressing [Cortex-A53/A55]       Linux Kernel Drivers - SDIO 3.0 / eMMC5.1 - USB 3.0/2.0 Dual-Role with PHY type C - 32-bit LPDDR4 - 2x Gigabit Ethernet with AVB, IEEE 1588, EEE   and 1x w/ TSN - PCIe Gen 3 + WIFI - CAN FD - Dual-ch. QuadSPI (XIP) or 1x OctalSPI(XIP) - RTC Licensing The majority of the software included in the OpenWrt release is licensed under a form of open source license (e.g. GPL, BSD). Some software is licensed under the NXP EULA license. 4. How to Start Deploying and Using wireless router? To experience the powerful features of the Layerscape series chips with wireless router, download the source code from the official OpenWRT repository: https://git.openwrt.org/openwrt/openwrt.git. The OpenWRT support code for Layerscape is already integrated into the official OpenWRT codebase. Taking IMX8MMini-EVK as an example, here are the deployment steps for wireless router on the IMX platform using Ubuntu 22.04: 4.1. Get the source code from GitHub: https://github.com/nxp-imx/imx_openwrt (Tag: imx_v23.05_v5.15.114) 4.2. Compile, Install, and Configure wireless router: $ ./scripts/feeds update -a; ./scripts/feeds install -a; cp config.default .config; make -j $ sudo dd if=/mnt/tftpboot/imx8/matter_20230908/openwrt-imx-imx8-imx8mmini-squashfs-sdcard.img of=/dev/sdX bs=1M && sync This way, an wireless router bootable disk for SD card has been generated. You can directly use an SD card to boot and experience wireless router. For more compilation assistance, please refer to the README file in the source code: target/linux/imx/README. 4.3. Configuration and Personalization Users can access the wireless router device through the web interface or SSH to begin configuring and personalizing the network environment. This includes setting network rules, installing software packages, and ensuring that the device operates according to individual needs. The following image shows the interface for installing and removing software. Isn't it simple and convenient! 4.4. What to Do If You Encounter Issues? Firstly, you can seek support in the vibrant OpenWRT community. You can not only get assistance but also share your development or usage experiences and even participate in project development. This open community provides users with more opportunities for learning and growth, collectively driving continuous progress in OpenWRT. You can also participate in the official NXP community at https://community.nxp.com/t5/i-MX-Processors/bd-p/imx-processors to ask questions and share technical insights. Professional engineers are available to help you troubleshoot and overcome challenges. NXP OpenWRT looks forward to your participation! Disclaimer This wireless router release is an NXP's Systems Engineering Initiative and is not part of NXP's Linux base enablement strategy for its MPU platforms. NXP does not vouch for the quality of this release and any follow up releases including adding support to new platforms is at the sole discretion of the Systems Engineering team. For specific requirements or needs please reach out to NXP's systems engineering team on the following email address "[email protected]." Re: NXP's wireless router Solution: Connecting the Future of Smart Networking Experience Upgrade to v2410_v6.6.52: https://github.com/nxp-imx/imx_openwrt.git

Developing a Dual-Motor EV Control System with Model-Based Design Toolbox 1 Introduction This article series presents the Motor Control System (MCS) within an electric vehicle (EV) architecture. It introduces the end-to-end development flow, from controller and plant modeling to simulation, code generation, hardware deployment, and integration with the rest of the vehicle network. This opening article establishes the technical foundation for a series focused on the architecture, implementation, and integration of a dual-motor control system for EV traction applications. The series also shows how MathWorks tools can be used together with NXP software and hardware to support a Model-Based Design workflow. This approach helps engineers develop, verify, and deploy motor control applications more efficiently while maintaining traceability across the development cycle. Figure 1-1. Role of the Motor Control System within the EV traction domain 2 Table of Contents • Introduction • Overview • Context • References • Conclusion 3 Overview 3.1. What will this series of articles cover? The articles in this series define the development roadmap for the Motor Control System within a broader EV architecture. The series covers the following topics: Software and Hardware Environment - Overview of the MathWorks and NXP tools used to develop, test, and validate a dual-motor control system. Architecture and Model Description - Description of the model architecture, signal interfaces, and core control algorithms implemented in the Motor Control System. Model-in-the-Loop Development - Simulation of the controller and plant in Simulink to validate algorithms before code generation. Software-in-the-Loop Validation - Code generation for the validated controller and comparison of the generated software against the Model-in-the-Loop baseline. Processor-in-the-Loop Validation - Execution of the controller on NXP hardware while the plant remains simulated on the host system. Deployment and Validation on Real Hardware - Integration with physical hardware, scaling from single-motor to dual-motor operation, and configuration of the NXP MCU peripherals required for motor control. CAN Integration - Definition of the CAN communication interface, including database design and integration on the target NXP platform. Results and System Validation - Presentation of the final implementation results and validation of the complete system behavior. 3.2. What is the Motor Control System? Electric vehicles depend on traction systems that deliver efficient propulsion, accurate torque control, and safe operation. At the center of this functionality is the Motor Control System (MCS), which combines real-time control software, power electronics, sensing, actuation, and communication interfaces into a tightly coordinated embedded system. Figure 3-1. PMSM motor and controller as core elements of the traction system In modern EVs, the traction system delivers the torque and power needed to propel the vehicle. It is typically composed of the following elements: Electric motor - converts electrical energy from the battery into mechanical power at the wheels. Inverter system - converts DC energy from the battery into the controlled AC waveforms required by the motor. Transmission system - transfers the generated torque from the motor to the wheels. At its core, the Motor Control System regulates motor torque, speed, and position by controlling the voltage and current applied to the motor phases. A typical MCS includes the following functional layers: Control Algorithm - implements torque and current control strategies such as Field-Oriented Control (FOC). Sensing and Feedback - measures motor currents, voltages, rotor position, and temperature. Power Electronics - inverter circuitry that switches DC power into AC waveforms for motor drive. Embedded Processor - microcontroller executing real-time control loops. Communication Interfaces - CAN, LIN, or Ethernet for integration with other system modules. Together, these layers form a closed-loop control system that operates at high switching frequencies and under strict real-time constraints. Figure 3-2. Field-Oriented Control (FOC) architecture EV traction systems can be implemented using different architectures depending on the required balance of efficiency, performance, cost, and system complexity. A single-motor architecture uses one traction motor to drive either the front or rear axle. This approach reduces hardware complexity and cost, and it often improves vehicle range because of lower mass and lower overall energy consumption. A dual-motor architecture uses two independent traction machines that can be arranged in several drivetrain topologies. This configuration enables higher total power, better traction, improved vehicle dynamics, and stronger acceleration. The tradeoff is increased electrical and mechanical complexity, together with higher system cost. Figure 3-3. Example dual-motor traction architecture Advantages & Disadvantages of Dual Motor: Acceleration faster due to torque from both motors Superior traction and handling, especially in snow, rain or off-road conditions Slightly lower range due to increased weight and power consumption More expensive but can include AWD and performance benefits Advantages & Disadvantages of Single Motor: Slightly better range due to less energy consumption More affordable Moderate traction, suitable for most road conditions Slower acceleration Note: The example used throughout this series is based on a dual-motor rear-axle architecture, where each rear wheel is driven by its own motor. 3.3. Target Audience This series is intended for engineers and technical stakeholders involved in the development, integration, and evaluation of electric drive systems, including the following audiences: Embedded Software Engineers Motor Control & Power Electronics Engineers System Architects & Vehicle Architecture Engineers Hardware Engineers Model-Based Design and Simulink Developers Academic and Research Communities 4 Context In the electric vehicle architecture presented in this series, the Motor Control System is located in the rear zone of the vehicle. Each rear wheel is driven by an independent Permanent Magnet Synchronous Motor (PMSM). The Motor Control System ECU coordinates both motors and exchanges real-time data with the rest of the vehicle over the CAN network. Figure 4-1. Motor Control System highlighted within the EV architecture The traction ECU is built around NXP's S32K396 microcontroller, which supports both single 6-phase motor control and dual 3-phase motor configurations. The inverter stage is driven by the MC33937 pre-driver, which provides three high-side and three low-side FET pre-drivers for automotive motor control applications. Note: The inverter receives DC power from the vehicle battery, while battery operation and safety are supervised by the Battery Management System. The Motor Control System communicates over CAN with the Zone Node controller, which in turn exchanges commands and status information with the main vehicle control node responsible for speed and torque requests. 5 References PMSM Control Workshop BLDC Control Workshop A Model-Based Design (MBDT) Environment for Motor Control Algorithm Development Deploy Motor Control Algorithms on NXP S32K3 from Simulink Motor Control Rapid Prototyping on NXP S32M2 with MathWorks and Model-Based Design Toolbox Next Generation of NXP EV Traction Inverter with S32K39 MCU and FS26 SBC AN14326: 3-phase Motor Control Kit with S32K396 Application Note AN13884: 3-phase Sensorless PMSM Motor Control Kit with S32K344 using RTD AUTOSAR API Application Note Advancing Motor Control Performance with Digital Twins Extended Range Dual-Motor Electric Vehicle Model 6 Conclusion This article introduced the Motor Control System within an EV architecture and established the technical context for the rest of the series. It explained the role of the Motor Control System, compared single-motor and dual-motor traction topologies, and outlined how a Model-Based Design workflow can be applied using MathWorks tools together with NXP software and hardware. The next article will focus on the software and hardware environment required to develop, simulate, and deploy the Motor Control System using MathWorks and NXP solutions.

Importing a Wrapped Key Blob into ELS Using NXP_DIE_KEK_SK on RW612 Introduction When provisioning secrets into an RW612 device, one common requirement is to securely load cryptographic keys without ever exposing the plaintext key material to application software. The EdgeLock Secure Subsystem (ELS) provides a secure mechanism for accomplishing this by allowing a wrapped key blob to be imported directly into an ELS key slot. The wrapping key is derived from device-unique root material inside the secure enclave. This article demonstrates how to: Derive the die-specific NXP_DIE_KEK_SK Import and unwrap the blob using ELS Store the resulting key in an ELS keyslot Remove temporary key material after provisioning The imported key never exists in plaintext in application memory, significantly reducing the attack surface compared to software-based key management. Understanding the Key Hierarchy Before looking at the implementation, it is useful to understand the different keys involved. NXP_DIE_MK_SK(NXP_DIE_INT_MK_SK) This is the 256-bit die master key derived from UDF and PUF using the KEYPROV operation. Characteristics: Die unique Not exportable Used as a root-of-trust Occupies key slot 0 on RW612 The key is loaded via dedicated secret key bus from PUF into ELS and XOR with a UDF derived key using KEYPROV, where it is used as a main key for further derivation of all remaining keys used by ROM. Applications never directly access the key material. NXP_DIE_KEK_SK This 256-bit key is derived from the master key using CKDF. It used for the wrapping of RFC3394 blobs stored in the OTP fuse region. Purpose: Acts as a Key Encryption Key (KEK) Used only for wrapping or unwrapping other keys Can be generated dynamically when needed In this example the KEK is stored temporarily in key slot 5. Imported Key The final key imported from the wrapped blob depends on how the blob was originally generated using the HSM provisioning flow (for example, via HSM_STORE_KEY and later loaded with loadkeyblob ). The imported key may represent a customer-defined security asset such as: Customer master key ( CUST_CKDFK_FLAG ) HKDF master key ( CUST_HKDFK_FLAG ) HMAC key ( CUST_HMACK_FLAG ) CMAC key ( CUST_CMACK_FLAG ) AES key ( CUST_AESK_FLAG ) Key unwrap-only key ( CUST_KUOK_FLAG ) Regardless of the key type, the import process remains the same. The key material is never exposed to application software during this process. Once imported, the key can be used directly by ELS for the cryptographic operations associated with its intended purpose, while remaining protected within the secure subsystem. Prerequisites FRDM-RW612 Key blob wrapped using RFC3394 format using HSM_STORE_KEY Key blob programmed to OTP fuses using LoadKeyBlob command. Required Headers: #include "mcux_els.h" #include "mcuxClEls.h" #include "mcux_pkc.h" #include "fsl_romapi_otp.h" Step 1 – Derive NXP_DIE_KEK_SK The wrapped blob is protected using a Key Encryption Key (KEK). On RW612, the KEK can be derived from the device master key ( NXP_DIE_MK_SK ) using the official recipe constants. The derivation operation uses  masterKeyIdx = 0;  which corresponds to NXP_DIE_MK_SK  and produces a new key in the target slot. Example: static const uint8_t derivation_data[12] = { 0x94, 0xbe, 0x03, 0xac, 0x8b, 0x59, 0x32, 0x45, 0x11, 0x7f, 0xf8, 0x3f }; mcuxClEls_Ckdf_Sp800108_Async( masterKeyIdx, target_slot, targetKeyProperties, derivation_data);   Wait for completion: mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR);   Verify that the derived key slot becomes active before proceeding. Step 2 – Retrieve the Wrapped Blob The example reads the blob directly from OTP memory. otp_fuse_read(starting_fuse_index + i, &fuse_word); Each fuse word contains four bytes.   These words are assembled into a contiguous buffer: blob_data[i * 4 + 0] = (fuse_word >> 0) & 0xFF; blob_data[i * 4 + 1] = (fuse_word >> 8) & 0xFF; blob_data[i * 4 + 2] = (fuse_word >> 16) & 0xFF; blob_data[i * 4 + 3] = (fuse_word >> 24) & 0xFF; The resulting buffer contains the RFC3394 wrapped key. Step 3 – Import and Unwrap the Blob Once the KEK exists and the blob has been retrieved, the import operation can begin. Configure ELS for RFC3394 import: mcuxClEls_KeyImportOption_t options; options.word.value = 0; options.bits.kfmt = MCUXCLELS_KEYIMPORT_KFMT_RFC3394; Perform the import: mcuxClEls_KeyImport_Async( options, blob_data, blob_length, kek_slot, target_slot); Parameters: Parameter Purpose blob_data Wrapped key blob blob_length Blob size kek_slot Slot containing NXP_DIE_KEK_SK target_slot Destination keyslot Wait for completion: mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR); If successful, ELS unwraps the blob internally and places the resulting key into the destination key slot. No plaintext key material is exposed to software. Step 4 – Clean Up Temporary KEK After the blob has been imported, delete the temporary KEK: mcuxClEls_KeyDelete_Async(kek_slot); mcuxClEls_WaitForOperation(MCUXCLELS_ERROR_FLAGS_CLEAR); This leaves only the imported key resident inside ELS. Next Steps At this point, the wrapped key blob has been successfully imported into the target ELS key slot, and the temporary NXP_DIE_KEK_SK has been removed. The imported key is now available for use by ELS-protected cryptographic operations without exposing the underlying key material to application software. The next step is to validate the imported key by performing the operation it was provisioned for. Depending on the key type, this may include: AES encryption or decryption operations HMAC generation or verification CMAC generation or verification HKDF-based key derivation Importing or unwrapping additional key material Secure firmware or data encryption workflows A successful cryptographic operation confirms that: The blob was read correctly from storage. The NXP_DIE_KEK_SK derivation completed successfully. The RFC3394 unwrap operation succeeded. The key was installed into the intended ELS keyslot with the expected properties. For production deployments, this import mechanism provides a secure method for provisioning customer keys generated with the HSM tooling while ensuring that plaintext key material never leaves the ELS security boundary.

S32K3 上的 LDREX/STREX/CLREX——似乎在 SRAM 中也能正常工作？ 我之前问过一个问题——https://community.nxp.com/t5/S32K/Understanding-Atomics-i-e-STREX-LDREX-on-S32K3/m-p/2356118 ——而回答似乎暗示，即使我仅在单核上使用 LDREX/STREX/CLREX，也无法依赖其行为来防止中断服务程序（ISRs）或中断请求（IRQs）与主线程发生冲突，尤其是当被检查的内存位于 SRAM 中时。 不过经过一些测试，结果似乎与我的预期一致——能否请设计团队确认，LDREX/STREX/CLREX 并不负责解决来自单个内核的访问冲突？我知道这无法阻止DMA与Cortex-M7内核之间的独占访问，但内核自身之间的访问又如何呢？ Re: LDREX/STREX/CLREX on S32K3 - seems to work in SRAM? 你好 @kscz， 我也进行了测试，根据测试结果，我重新开启了这项讨论。 一旦有最新消息，我会尽快回复您。 此致， 丹尼尔 Re: LDREX/STREX/CLREX on S32K3 - seems to work in SRAM? 你好@kscz ， 我已经确认，SRAM 中的行为与 TCM 中的行为相同。我已经据此更新了之前的回答。谢谢你指出这一点。 BR，丹尼尔

s32k322 EMAC RMII 问题 您好， 我们 我们 使用 的 恩智浦 S32K322 微控制器 并 经历 以太网 以太网 接收 问题： TX 传输 正常工作 正常、 但 RX 接收 不 不 功能.关于 硬件 硬件方面 硬件方面、 硬件方面 RMII 接口 是 直接 与 直接连接到 以太网 以太网 交换机、 并且 我们 我们 验证了 开关 电路板 PCB 迹线 长度 匹配 和 阻抗 控制 满足 设计 设计 符合设计要求。用于 功率 排序、 我们 目前 确保 手动 确保 开关 开关 完成 其 开机 之前 在 S32K322。 测试期间 测试期间、 我们 我们 开关 开关 发送 ARP 数据包 并 已 测量到 测量了 与 RX 信号 波形 用 示波器 示波器、 所有 所有 所有 看起来 正确。然而 然而 S32K322 EMAC 不 不 进入 接收 接收 中断 （与 相同 波形 成功 成功 接收到 在 另一个 ECU 平台）。我们 我们还 还 检查了 我们还检查了 EMAC 接收 和 错误 计数器 中的 寄存器中的 和错误计数器、 和 都 读取 为 零.所有 时钟 频率 配置 已 已 时钟频率配置 频率配置 正确。 正确。请 帮助 提供 额外的 故障排除 意见 或 建议。   顺祝商祺！ 李永祥 Re: s32k322 EMAC RMII issue 你好@PavelL、 感谢您的答复。我们已经检查了所提供的一些要点。 只有在交换机完全启动并运行（确认与其他端口通信）后，才会接通 MCU 的电源。我们增加了图中所示的延迟，但无济于事。 我们检查了时钟并重新配置了它，但 RX 计数器仍然没有显示新的计数。 在外设配置中选择 RMII 模式。 交换机可以从 TX 方向正确接收和转发 RMII 帧到其他端口，因此交换机配置似乎是正确的。我们还扫描了交换机和 MCU RX0/RX1 信号提供的 TXCLK，波形看起来很好，交换机的帧没有明显问题。 我们正在对照参考示例进行交叉检查。 我们使用的是 RTD 6.0.0。测试项目附后，以供验证（代码混乱，敬请原谅，这是测试固件）。   顺祝商祺！ 李永祥 Re: s32k322 EMAC RMII issue 你好@YongxiangLi、 有几个方面看起来值得首先检查。 由于发送工作正常，但 RX 数据包计数器和 RX 错误计数器都保持为 0，我目前怀疑 EMAC 根本无法识别有效的 RMII 接收活动，而不是接收帧后再丢弃它们。   最重要的检查是   1) 初始化期间的 RMII 参考时钟计时 在执行 emac/引脚/时钟初始化之前，请验证来自交换机的外部 50 MHz RMII 参考时钟是否已经存在并稳定在 S32K322 引脚上。很可能需要增加较小的延迟，正如 S32K3-T-BOX 所建议的那样。另请注意下面代码片段的第一行： 2) MCU 内部的 RMII 时钟配置 对于 S32K3 RMII，MAC 在 EMAC_MII_RMII_TX_CLK 上使用 50 MHz 的 RMII 参考时钟，而外部 RX_CLK 引脚不在 RMII 模式下使用。但是，仍需要正确配置内部 EMAC RX/TX 时钟（100 Mbps 通常为 25 MHz，源自 50 MHz RMII 参考时钟）。请仔细检查 EMAC 时钟多路复用器/分频器设置。 用于 S32K3 的 RMII 时钟 3) RMII 模式选择 请确认 gmac 驱动程序（用于 EMAC 外设）确实配置为 RMII 模式（而非 MII），并且在初始化过程中尽早进行了选择。   4) 开关侧 RMII 模式 由于您的 MAC 直接连接到交换机端口，而不是分立的 PHY，因此还请验证交换机端口是否真正配置为 RMII/rev-RMII 运行，并且正在向 MCU 驱动正确的 50 MHz 参考时钟。   5) 或者，您可以将您的项目与我的 S32K344 EMAC lwIP 项目进行比较 S32K 示例   为了缩小范围，请与我们分享一下： - 您使用的是哪个版本的 S32K3 RTD 驱动程序？ - 能否至少分享您项目的简约版本或 mex 文件？   顺祝商祺！ 帕维尔 Re: s32k322 EMAC RMII issue 你好@YongxiangLi、 我仔细审查了您的项目，对每个细节都格外关注。我实在想不出Rx为什么对你不起作用。虽然有些细节可以调整，但这些调整微乎其微。 您使用的是哪种 VDD_HV_B？ 作为诊断步骤，您还可以尝试在 GMAC 驱动程序中启用混杂模式。 这样，MAC 就能接受所有传入帧，而不受目标 MAC 地址过滤的限制，这有助于判断问题是与帧过滤相关，还是接收路径在更底层出现了故障。 如果启用混杂模式后行为未发生改变，且接收计数器仍保持为零，那么问题很可能出在数据包过滤层之下（例如 RMII 时钟、接收路径初始化或 DMA/描述符处理）。 作为另一个有用的调试步骤，我建议您退一步，从标准的 InternalLoopback 示例开始，并根据您的硬件平台进行调整。 首先，请验证 InternalloopBack 示例在您的主板上是否能正常运行。这有助于确认 GMAC 的基本初始化、描述符处理、缓冲区配置以及软件流程在 S32K322 上均按预期运行。 之后，您可以取消勾选“内部环回模式”，并将该项目作为与外部交换机通信的最小基线。换句话说，使示例尽可能接近有效的参考设计，并再次测试帧的传输和接收。 这种方法有助于确定问题是源于与交换机的硬件接口（例如 RMII 时序/时钟），还是由当前项目中更高层级的软件集成差异所导致。 顺祝商祺！ 帕维尔 Re: s32k322 EMAC RMII issue 你好@PavelL  感谢您的耐心支持。我们将按照您的建议在周末继续进行调查，并将于下周一或周二给您回复。 顺祝商祺！ 李永祥 Re: s32k322 EMAC RMII issue 你好@PavelL、 很抱歉回复晚了。我们根据最近的研究结果进行了进一步的测试。我们测试了混杂模式，但结果没有变化。 我们还有一点观察结果：在重新设计 PCB 并实现外部环回后，MCU 能够接收自己发送的帧。然而，同一台交换机使用相同的配置，通过同一端口，经由 RMII 与另一产品板上的不同 MCU 成功通信。这让我们非常困惑，究竟是什么原因导致了这个问题。 我们将继续进行分析。我们目前的计划是通过让MCU TX和交换机输出相同的包来比较波形。然而，这在实施上具有挑战性，我们仍在努力——交换机转发的帧并不干净，因为它们包含许多其他数据包，会干扰波形捕获。 我们非常感谢您能提供任何其他建议。   顺祝商祺！ 李永祥 Re: s32k322 EMAC RMII issue 你好@YongxiangLi、 谢谢你的更新。 根据您最新的观察，下一步的一个有用方法可能是通过交换机本身创建一个更可控的交换机到 MCU 接收测试。   由于 MCU 端的外部环回功能正常，这表明基本的 GMAC TX/RX 路径和软件流程是功能正常的。因此，隔离从开关输出到 MCU RMII 接收接口的特定路径可能很有帮助。   如果你的交换机支持，你可以尝试以下方法之一： 1. 配置一个非常简单的静态 L2 转发路径，以便将已知的测试帧仅转发到 MCU RMII 端口。 2. 或者，如果支持，可以使用端口镜像生成向 MCU 端口的受控出口帧。 如果交换机支持，我还建议暂时禁用所有端口的 MAC 地址学习功能。   无论哪种情况，我都建议禁用或过滤所有其他不必要的流量，如果可能的话，禁用转发到所有其他端口。目标是只让一个已知的帧模式到达 MCU，以便更清晰地捕获 RMII 接收波形（REF_CLK、CRS_DV、RXD0、RXD1）。 顺祝商祺！ 帕维尔

我能否从 nxp 中取出胶带 我能否将我的芯片设计从 nxp 中剥离出来？ Re: can i tape out from nxp 亲爱的拉吉-里特维克   感谢您联系恩智浦并对我们的产品感兴趣。 我们想澄清的是，恩智浦并不为外部芯片设计提供开放式代工或带出服务。通常情况下，需要定制硅带输出的客户会直接与台积电和 GlobalFoundries 等商业代工厂联系、 您能否告诉我们您的询问是否与任何特定的恩智浦产品或设备有关？如果需要，我们很乐意为您提供进一步的帮助。 如果需要，请随时提供更多详细信息，我们很乐意提供力所能及的帮助。 祝您愉快