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

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设备

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）。 顺祝商祺！ 帕维尔

什么是工业以太网协议？EtherCAT、PROFINET 和 EtherNet/IP 详解（日语博客） 目录 介绍 什么是工业以太网？ 工业网络的基本结构 1. EtherCAT（超高速、低延迟方向） 2. Profinet（灵活性/互操作性） 3. 以太网/IP（IT 亲和性/标准化） 总结 介绍   工业设备通信正迅速从传统的现场总线转向基于以太网的系统。而这一转变的核心正是工业以太网协议。   本文重点介绍三种广泛使用的协议，并清楚地解释它们在技术结构和设计理念上的差异。 以太网 PROFINET 以太网/IP （※评估和实施方法将在另一篇文章中详细说明。） 什么是工业以太网？   简而言之，工业以太网是一种通信技术，与通用以太网相比，它增强了“实时性能”、“鲁棒性”和“诊断能力” 。 标准以太网在工业应用中面临以下挑战：   这是一种尽力而为的通信方式，延迟会根据负载和切换过程而变化。 可能会出现丢帧（丢包）现象。 TCP/UDP/IP 并非为实时控制而设计。 为了应对这些挑战，工业以太网协议采用独特的方法来满足以下要求：   实时通信 同步控制 冗余配置 诊断功能   ■ 理解工业以太网的关键点：OSI 模型   理解工业以太网的关键之一在于理解“实时性能是在哪一层实现的”，而OSI参考模型有助于理解这一点。OSI模型将通信功能划分为七层，每一层都扮演着不同的角色，从物理信号的传输到应用处理。 工业以太网以 OSI 的每一层为基础，并针对每种协议扩展和优化特定层，从而实现实时性能和可靠性。 工业以太网中的 OSI 参考模型： 等级制度 姓名 工业以太网的作用 7 应用 通信数据内容（设备控制、状态、设置） 6 推介会 数据编码、压缩和加密 5 会议 建立、维护和终止通信 4 运输 通信质量控制（TCP/UDP），数据传输保证。 3 网络 通过 IP 地址路由（确定数据包目的地） 2 数据链路 通过 MAC 地址进行数据传输，创建以太网帧 1 物理 电缆（Cat5e/6 等）、连接器和物理信号传输。 工业以太网协议所使用的层： 以太网协议各特性： 协议 等级制度 特点 以太网 2 无需使用IP即可实现高速传输 PROFINET RT/IRT 是L2 NRT L3/4 RT 和 IRT 的区分使用。 以太网/IP 3/4 基于标准以太网 这些特征差异直接导致以下结果： 速度（实时性能） 实施成本 适用范围   工业网络的基本结构   工业以太网通常具有共同的基本结构，而本文讨论的三种协议（EtherCAT、PROFINET 和 EtherNet/IP）也不例外。 ■ 系统和设备结构   工业网络大致可以分为“控制器侧”和“设备侧”。   主设备（控制器）： 它在控制整个网络中起着核心作用。 启动通信并设置连接参数 发送输出数据和接收输入数据 沟通管理和终止流程 典型例子：PLC、工业PC 子设备（设备）： 响应连接请求并发送和接收必要数据。 接收输出数据并发送输入数据 网络自通知 根据需要发送警报 典型例子：传感器、伺服电机、执行器 ■ 沟通方式：周期性沟通与非周期性沟通 连接建立后，主设备和子设备之间会以极短的时间间隔持续交换I/O数据。根据应用场景的不同，这种通信可分为“周期性通信”和“非周期性通信”。 周期性沟通（周期性沟通） 应用：用于实时控制 - 对于需要实时性能的应用，例如电机控制和I/O控制，至关重要。 非循环通信 用途：配置、诊断和事件管理 - 用于读取和写入配置数据、诊断信息和意外事件通知。 ■支持实时性能的关键概念：同步（时钟） 在工业系统中，“所有设备都按照同一时间标准运行”这一点至关重要。 例如，如下图所示，如果多个设备在不同的时间 Δt₁、Δt₂ 和 Δt₃ 获取数据，则控制器 (PLC) 接收到的信息将不是来自同一时间的数据，而是时间上交错的“单独的快照”。 结果： 位置错位的发生 错误的控制判断 特别是运动控制中的关键同步误差 这可能会导致诸如此类的问题。 因此，在工业以太网中，设备间时钟同步机制是一个至关重要的要素。 三种协议的技术比较总结   以太网 PROFINET 以太网/IP 运营组织 贝乔夫 / ETG（EtherCAT 技术集团） 西门子 / PNO（PROFIBUS & PROFINET International） 洛克威尔 / OVDA（开放设备网络供应商协会） 沟通方式 摘要帧（子设备在帧中读取和写入数据） 基于第 2 层的实时通信 (RT/IRT) CIP：显式（TCP）/隐式（UDP）通信模型 主要用途 运动控制，超高速控制 通用型FA、过程控制以及广泛的工业应用 工厂自动化、PLC网络、机器人 周期 约 31.25μs 级（取决于具体实现，速度非常快） RT：几毫秒 IRT：31.25μs（取决于具体实现方式，TSN/IRT） 通常情况下，延迟级别为 10 毫秒（基于 UDP）。 同步方法 分布式时钟（DC） IRT：精确同步（PTCP） CIP 同步（IEEE1588） 设备型号 PDO/SDO（基于 EtherCAT 的 CANopen） 插槽/子插槽（GSDML） 类/实例/属性对象模型 拓扑 线型、树型、环型（低延迟） 线、星、环（MRP/MRPD） 线、星、环（DLR） 优势 简而言之，就是高速低延迟/硬件处理。 多种类别和诊断功能，高度互操作性 广泛应用于标准以太网基础设施，易于理解。 接下来，我们将解释每项技术特点。 1. EtherCAT （超高速、低延迟导向型） ■ EtherCAT 概述 由 Beckhoff Automation 开发，ETG 管理。 它运行于第 2 层，没有 IP/TCP/UDP 开销。 周期时间：约31.25微秒（取决于具体实现方式） 同步精度：±1μs 或更小 ■ 网络配置 主设备（主控设备）和  多个子设备（从设备） 该子设备配备了ESC （ EtherCAT 从控制器），并使用专用硬件进行高速处理。 虽然线路配置是基本设置，但它也支持使用环形结构的冗余配置。 图： EtherCAT网络配置图 EtherCAT 最显著的特点是“即时处理”。单个帧在经过所有设备的过程中都会被处理，每个设备都会在传输过程中读取和写入数据。由于处理工作由专用硬件（ESC）完成，无需 CPU 参与，因此延迟极低。   图： EtherCAT网络传输图像 ■ 相关协议转换：EtherCAT（IEC 61784-2-12） • CoE （CAN over EtherCAT）：通过EtherCAT帧隧道化，使CANopen通信得以使用。 • FoE （File over EtherCAT）：一种通过 EtherCAT 传输文件的协议。 EoE （以太网 over EtherCAT）：一种封装和传输常规以太网帧（例如TCP/IP ）的机制。 图：主设备（MDevice）的EoE协议转换 2. PROFINET （灵活性/互操作性） ■ PROFINET 概述 由西门子开发，PNO 管理。 基于标准以太网 根据应用场景选择RT/IRT/NRT。 生产者/消费者模式 ■ 网络配置 灵活支持各种拓扑结构，例如线型、星型和混合型拓扑结构。 它还支持通过MRP （媒体冗余协议） / MRPD（IRT）实现环冗余。 PROFINET的通信性能按“一致性等级( CC )”进行分类。 CC-A ：基本实时，所有IT服务（例如TCP/IP ）均可无限制使用。 CC-B ：为通用FA的RT添加网络诊断和其他功能。 CC-C （ IRT ）： 31.25 μs级运动应用 ■ 沟通类型 NRT（非实时）：记录读/写：非周期性地发送和接收参数和设置。报警：通知设备异常情况。 RT：周期性I/O通信，通常为1 毫秒 IRT（等时性）：时间同步的高速周期性通信，通常为 31.25 微秒。 → 实现了高度灵活性、详细的诊断和高度互操作性。 3. 以太网/IP （ IT兼容性/标准化） ■以太网/IP概述 EtherNet/IP 由 ODVA（开放设备网络供应商协会）管理。 它采用 CIP（通用工业协议），该协议运行在 TCP/UDP/IP（L3/L4）之上的一层。 面向对象模型 ■ 网络配置 支持线型、星型和环形拓扑结构。 支持使用DLR （设备级环）的高速冗余。 主设备 →扫描器：作为控制器运行，通常发起请求。 子设备 →适配器：响应该请求的设备。 ■ EtherNet/IP 的关键特性：“面向对象模型” 每个设备都被定义为由“类”、“实例”、“属性”和“服务”组成的对象的集合。 类：函数类型（例如，恒等函数、汇编函数） 实例：该类的特定实例。 属性：每个实例所具有的特定值。 服务：操作细节，例如读写。 这使得设备的功能结构非常清晰，从而实现了与不同制造商之间的高度兼容性。 ■ 沟通类型 显式消息连接 使用TCP ，读取和写入配置值，执行自我诊断，并记录日志。 分别发出一次“读”和一次“写”之类的指令。 隐式消息传递 - I/O 连接 它使用UDP 协议，可以实现实时通信，例如循环I/O ，扫描器会定期发送和接收I/O数据。   EtherNet/IP的关键特性是它能够使用隐式（ UDP ）协议实现高速I/O通信。 总结 工业以太网不仅仅是通信；它是一种能够实现实时控制的系统技术。本文介绍的三种协议分别通过不同的方法来实现这一目标。 协议 设计理念 主要用途 以太网 高速、低延迟 运动控制 PROFINET 灵活性和集成性 通用工厂自动化（FA） 以太网/IP IT集成 PLC网络   作为未来的发展趋势，产业网络将朝着以下方向发展。 TSN （时间敏感网络） 安全（包括符合《社区再投资法案》） 与OPC UA集成 换句话说，关键在于“实时性× IT集成×安全性”的融合。 下次， 为什么i.MX RT1180适用于工业以太网协议？ 实际实施和评估程序 我们将详细解释这一点。 ============================= 我们目前无法 回复 此帖子“ 评论”部分留下的评论。 对于由此造成的不便，我们深表歉意，但 在进行咨询时， 请 参考“ NXP 技术问题 - 如何联系我们 （ 日语博客 ） ” 。 （如果您已经是 恩智浦的 分销商或 与 恩智浦 有合作关系 ，您可以直接咨询您的代表。 ） 工业设备通信正迅速从传统的现场总线转向基于以太网的系统。而这一转变的核心正是工业以太网协议。 本文重点介绍三种广泛使用的协议，并清楚地解释它们在技术结构和设计理念上的差异。 以太网 PROFINET 以太网/IP （※评估和实施方法将在另一篇文章中详细说明。）   本文将介绍主导工业以太网的三大协议：EtherCAT、PROFINET 和 EtherNet/IP，并清晰地解释它们在技术结构和设计理念上的差异。   （阅读时间：15分钟） i.MX RT 处理器 介绍 日本博客

[MCXN247] 缺少 LPFLEXCOMM8/9 实例？ 你好 我们目前正在将 MCXN247VKL 微控制器集成到我们的产品中。 我正在使用 MCUXpresso 配置工具生成 pin_mux.c/.h、peripherals.c/.h 等文件。 我们有一个连接到引脚 62 和 63 的简单 UART Rx/Tx，它应能提供实例 FlexCOMM8 的 FlexCOMM 功能。但在配置工具中，MCXN247VKL 只有 8 个 FlexCOMM 实例（0-7）可用。根据数据表，该 MCU 应有 10 个 FlexCOMM 实例，引脚 62 和 63 应连接到 FlexCOMM8。 我是否遗漏了什么，或者为什么只有 8 个 FlexCOMM 实例？ 我使用的是 MCUXpresso 配置工具 26.03 版 致以最诚挚的问候， Stefan Re: [MCXN247] Missing LPFLEXCOMM8/9 instance? 你好@WaSt 谢谢你的帖子！ MCXN247 不支持 FC8 和 FC9。数据表中存在一个错误，内部团队已经在着手更新文件。 对于由此造成的不便，我们深表歉意。

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

S32k344 RTD 中的 MDIO API？ 您好， 我的定制主板将 S32K344 EMAC 的 MDIO 连接到 SJA1110 的 SMI_AP 接口。我想通过 MDIO 接口配置 SJA1110 的内部 100BASE-T1 PHY，但在实时驱动程序包中找不到任何 MDIO 读/写 API。能告诉我这些应用程序接口在哪里吗？ 谢谢！ 查尔斯 Re: MDIO APIs in S32k344 RTD? 你好@cmnxp、 MDIO 访问 API 在 S32K3 RTD 中可用，但它们是在 GMAC 驱动程序下提供的，而不是作为单独的独立 MDIO 模块提供的。在 GMAC RTD API 中，相关函数是 Gmac_Ip_MDIOWrite() 和 Gmac_Ip_MDIORead()。 对于您使用 SJA1110 SMI_AP 的特定用例，请注意内部 100BASE-T1 PHY 子系统是通过 Clause 45 寄存器映射管理的，因此您通常需要 Clause 45 API - Gmac_Ip_MDIOReadMMD()、Gmac_Ip_MDIOWriteMMD()。 顺祝商祺！ 帕维尔 Re: MDIO APIs in S32k344 RTD? 你好，帕维尔、 感谢您的快速回复。也就是说，S32K344 只有一个 MDIO 接口，同时用于 EMAC 和 GMAC，对吗？ 此致， 查尔斯 Re: MDIO APIs in S32k344 RTD? 你好@cmnxp、 是的，每个 EMAC/GMAC 通常有一个 SMI 接口。 顺祝商祺！ 帕维尔

Guidance for IVT Flash Image Creation for R52_0_0 Core on S32Z280-594EVB Without Debug Probe. Hi, Currently I am working with the NXP S32Z280-594EVB board. I created a Blink LED project for the R52_0_0 core using S32DS. I do not have the S32 Debug Probe, but I need to flash my project to the board. Please give me guidance on how to convert my project into a flashable image using the IVT method. Could you please share the procedure or any reference documents/examples for generating the flash image and booting it on the S32Z280 board without the debug probe? Thank you. Re: Guidance for IVT Flash Image Creation for R52_0_0 Core on S32Z280-594EVB Without Debug Probe. Hi,suresh308531 Thank you for contacting us. I have received your question and will help you to check it. BR Joey Re: Guidance for IVT Flash Image Creation for R52_0_0 Core on S32Z280-594EVB Without Debug Probe. Hi，suresh308531 Thank you for contacting us. You can try to refer to this links as the following contents for your question. creating a Blob Image using IVT S32Z2 How to reduce the binary size in S32Z2 Hope this information can help you. BR Joey Re: Guidance for IVT Flash Image Creation for R52_0_0 Core on S32Z280-594EVB Without Debug Probe. Hi Joey_z, Thank you for your support. I followed your steps successfully. I reduced the .bin file size and created the flash image using the IVT method. However, after flashing the image, there is no output from the board. I tested a simple UART example code. The same UART code runs successfully on the M33 core, using the same pins and configuration. Then I created a new project for the R52_0_0 core, but the UART output is not showing. For the IVT configuration, I used the RAM start pointer address and RAM entry pointer address from the .ld file and .map file. Could you please help me solve this issue? Please let me know if there are any additional boot settings, memory settings, or R52-specific configurations required for the S32Z280 R52_0_0 core.   BR, suresh Re: Guidance for IVT Flash Image Creation for R52_0_0 Core on S32Z280-594EVB Without Debug Probe. Hi,suresh308531 Could you share your R52 UART project with me? I can help you to check it. BR Joey Re: Guidance for IVT Flash Image Creation for R52_0_0 Core on S32Z280-594EVB Without Debug Probe. Hi Joey_z, Thank you for your support. I have attached my R52 UART project for your reference. Could you please check the project and help me identify why the R52_0_0 core is not booting/running after creating the IVT flash image? The IVT image is generated successfully and flashing also completes successfully, but there is no UART output from the R52 core. BR, Suresh Re: Guidance for IVT Flash Image Creation for R52_0_0 Core on S32Z280-594EVB Without Debug Probe. Hi,suresh308531 I have checked your project, please try to modify your code as the following contents. If you want to boot from R52 directly, please try to refer to the steps as the following. 1.Modify the file of startup.s to initial the RTU0 early, added for RTU0 SRAM initialization for boot target as R52 as the following picture. The startup.s patch file in the attachment.  2.Enable the partition1(use the function of Mcu_SetMode()) before use the clock initial as the following picture. 3.Set the board boot from QSPI. Hope this information can help you. BR Joey Re: Guidance for IVT Flash Image Creation for R52_0_0 Core on S32Z280-594EVB Without Debug Probe. Hi，suresh308531 Have you finished this application? I can continue support you if you still have any issue. BR Joey Re: Guidance for IVT Flash Image Creation for R52_0_0 Core on S32Z280-594EVB Without Debug Probe. Hi，Suresh Thank you for your reply and information. You can contact us at any time if you have other issue. BR Joey Re: Guidance for IVT Flash Image Creation for R52_0_0 Core on S32Z280-594EVB Without Debug Probe. Hi Joey_z, Thank you for your reply and support. I successfully ran the project with the R52 core. Your suggested binary size reduction process and the startup.s file modifications helped me achieve this successfully. Currently, the project is working even without enabling the Partition 1 clock and without using the Mcu_SetMode() function. Thank you again for your guidance. BR, Suresh

如何使用 IFC-或非 启动模式在 LS2088ARDB 上启用/访问 QSPI 闪存设备。 HI 1) LS2088ARDB 可以使用 IFC-或非 启动或 QSPI 启动启动。 2) IFC-或非 和 QSPI 是混合的，因此一次只能启用其中一个。 3) 我相信选择 IFC / QSPI 的多路复用器配置是由引导程序根据 RCW 数据完成的。 4) 我的要求：使用 IFC-或非 启动模式启动后需要在 Linux 中访问 QSPI 闪存。这可能吗？如果是，能否提供 QSPI Linux 源代码。 5) 我们能否重新配置多路复用器选择（考虑 IFC-或非 启动模式）以在 Linux 级别启用 QSPI？如果是，请提供源代码。 谢谢。 Re: How to enable/access QSPI flash device on LS2088ARDB with IFC-NOR bootmode. 你好 不是 — 在 LS2088ARDB 上，如果你以 IFC-或非 模式启动，则不应指望以后会从 Linux 启用和使用 QSPI。可用的LS2088a/LayerScape文档表明，由于引脚多路复用，IFC和QSPI是相互排斥的，并且这种多路复用是在RESET期间在RCW中配置的，而不是在运行时动态重新配置。具体到 LS2088A，恩智浦指出，只有在 RCW 中才能实现引脚多路复用，"根据设计，在运行时不可能改变引脚多路复用"。, 你对启动的理解是正确的： RCW 源由复位时采样的复位配置引脚选择。 然后，预启动加载程序从 cfg_rcw_src 指定的源加载 RCW。 在 LS2088 级主板上，开关启动源可能需要更改 RCW 和不同的主板开关/跳线设置。 对于LS2088/LS2044的家庭行为，恩智浦明确证实： “当使用 QSPI 时，只能在 IFC 上使用 与非 控制器。所有其他 IFC 机器......都不能使用，因为它们的信号都经过混搭，以便在 QSPI 接口上使用"。 对于 LS2088A，必须在 RCW 中实现引脚多路复用，而且 "不可能在运行时更改引脚多路复用"。 因此，对你们问题的直接回答是 使用 IFC-NOR 启动模式启动后 Linux 能否访问 QSPI 闪存？ 不，不在正常的 LS2088ARDB IFC 启动配置中。IFC 和 QSPI 是多路复用的，选择由 RCW/PinMux 在 RESET 时修复。, Linux 能否在运行时重新配置多路复用器选择以启用 QSPI，同时保持 IFC-或非 启动模式？ 不。检索到的文件说，这种引脚复用只限于 RCW，不能在运行时更改。 我能得到 Linux 源代码来实现这种多路复用器切换吗？ 我找不到任何 LS2088A/Linux 源代码或运行时 IFC↔QSPI 多路复用器开关的文档机制，而且硬件行为表明不支持这样的 Linux 实现。, 一个细微差别：Layerscape Linux 指南显示，可以使用不同的开关/跳线设置将 LS2088ARDB 配置为从 NOR 或 QSPI 启动，并指出更改引导设备配置可能需要更改 RCW 或其他映像。这支持了这样的结论，即这是启动/RESET 时的硬件配置选择，而不是 Linux-time 交换机   此致 Re: How to enable/access QSPI flash device on LS2088ARDB with IFC-NOR bootmode. 谢谢。这澄清了我的疑惑。

了解 i.MX 8M Plus 中的权限层次结构：SoC 与 Cortex-A53 与 Boot ROM 你好，恩智浦社区、 我目前正在为我的论文项目研究 i.MX 8M Plus SoC（用于 Toradex Verdin iMX8M Plus 模块），我有一个关于芯片架构权限等级的问题。 基于 IMX8MPRM 参考手册（Rev.3，08/2024），我了解以下等级制度： 1。启动 ROM（硬编码在芯片内部）— 根据第 6.1.1 节，首先在上电复位 (POR) 时执行 2。Cortex-A53（主核）— 根据第 1.4.3 节，在启动 ROM 后获得控制权，并负责身份验证和启用 Cortex-M7。 Cortex-M7 — 在 A53 4 明确启用之前无法运行。 DSP/NPU/GPU — 由 A53 按需调用 我的问题是 1。说 i.MX 8M Plus SoC 本身是系统中 " 最高权威 "，因为它包含启动一切的启动 ROM，这与树莓派中 BCM 芯片的功能类似，这是否正确？ 2。在 SoC 中，Cortex-A53 是否被视为 " 在操作上占主导地位的 " 内核，因为它是第一个从启动 ROM 获得控制并管理所有其他内核生命周期的内核？ 3.是否有任何恩智浦官方文档或应用笔记可以用方框图而不是流程图更好地说明SoC组件（Boot ROM → A53 → M7 → Accelerators）之间的主层次结构？ 如需任何说明，敬请垂询。这将对我的学术答辩陈述大有帮助。 顺祝商祺！ Re: Understanding the Authority Hierarchy in i.MX 8M Plus: SoC vs Cortex-A53 vs Boot ROM 你好， Q1：是的，在启动链中，更精确的术语是不可变的片上 bootroM 是初始执行权限，用安全启动的术语来说，是硬件信任根的一部分，而不是 Cortex- A53 本身。 问题 2： 在系统正常运行的情况下：是的，这种说法是公平的，也是站得住脚的。 A53 架构用作主要应用程序域，而 M7 充当辅助实时内核。 问题 3：参考手册提供了启动流程/系统启动的详细信息。 致敬， Zhiming Re: Understanding the Authority Hierarchy in i.MX 8M Plus: SoC vs Cortex-A53 vs Boot ROM 您好，Zhiming, 非常感谢您清晰准确的回答--这对我的学术答辩非常有帮助。 根据你的回答，我还有一个后续问题： 据我了解，Apalis iMX8（基于恩智浦i.MX 8QuadMax）使用专用的SCU（系统控制器单元）—一个基于Cortex-M4的内核—作为上电复位后的第一个主动元器件。在通过 SCFW → TF-A → U-Boot 将控制权移交给 Cortex-A 级 CPU 之前，SCU 管理所有其他内核的功率域、时钟和资源。 但是，Verdin iMX8M Plus（基于恩智浦i.MX 8M Plus）似乎没有专用的SCU。 因此，我的问题是： 1.在 i.MX 8M Plus 上，哪个元器件起着与 i.MX 8QuadMax 的 SCU 相同的作用？它是否纯粹是片上启动 ROM 与 GPC（通用功率控制器）、CCM（时钟控制器模块）和 SRC（系统 RESET 控制器）等硬件模块相结合？还是我们可能忽略了专用的系统控制器？ 2。除了 IMX8MPRM 参考手册中的图 1-1 之外，还有更完整的方框图专门显示了 Boot ROM、GPC、CCM、SRC、Cortex-A53 和 Cortex-M7 之间的关系和控制层次结构吗？例如，恩智浦的应用笔记 (AN) 或硬件架构文档？ 再次感谢您抽出宝贵的时间和支持。 致以最诚挚的问候 Re: Understanding the Authority Hierarchy in i.MX 8M Plus: SoC vs Cortex-A53 vs Boot ROM 你好 @Rivan 1.在 i.MX 8M Plus 上，哪个组件起着与 i.MX 8QuadMax 的 SCU 相同的作用？它是否纯粹是片上启动 ROM 与 GPC（通用功率控制器）、CCM（时钟控制器模块）和 SRC（系统复位控制器）等硬件模块相结合？还是我们可能忽略了专用的系统控制器？ --> i.MX8MP 中没有 SCU，资源由 ATF/Linux 驱动程序控制。 2。除了 IMX8MPRM 参考手册中的图 1-1 之外，还有更完整的方框图专门显示了 Boot ROM、GPC、CCM、SRC、Cortex-A53 和 Cortex-M7 之间的关系和控制层次结构吗？例如，恩智浦的应用笔记 (AN) 或硬件架构文档？ -->与其他公开文件相比，RM 中的信息已经相当详细；没有单独的 AN 来描述这一建筑设计。 致敬， Zhiming

NTAG5 LInk 中的 AES 相互验证 你好、 我正在为一个物联网应用进行基于 NTP5332 的设计（带 AES 模式的 NTAG 5 链路），需要澄清相互验证如何授予对不同内存区域的访问权限。 1.在 NTAG5 链路上，DEV_SEC_CONFIG 设置为 AES 模式，SRAM_CONF_PROT 位 NFC_SRAM_R = 1 和 NFC_SRAM_W = 1（SRAM 受 NFC 侧保护）： NFC 端相互验证成功后，是否允许 SRAM 读/写访问？ 表 25（NFC_KPx）中没有 SRAM 位，因此我不确定在 AES 模式下哪个密钥会栅极 SRAM。 2. PP_AREA_1 下面的用户 EEPROM 被 8 位 NFC_PP_AREA_0H 指针分成 AREA_0_L 和 AREA_0_H。NFC_PPC 可独立控制 AREA_0_L 和 AREA_0_H 的读/写保护（四个独立位）。 然而，表 25 只列出了 NFC_KPx 中两个"受保护用户内存区" 位（位 0 = 读取，位 1 = 写入），而没有区分 AREA_0_L 和 AREA_0_H。 当密钥通过验证且其 KPx 位 1（写入）被设置时： (a) 是否只允许写入 AREA_0_H？(b) 只给 AREA_0_L？(c) 如果 AREA_0_L 和 AREA_0_H 中的任何一个通过 NFC_PPC 进行了写保护，则同时写到 AREA_0_L 和 AREA_0_H？(d) NFC_PPC 中当前标记为写保护的是 AREA_0_L 还是 AREA_0_H？ 同样的问题也适用于第 0 位（读取）。 3.在 AES 模式的 NTP5332 上，如果 KP0 配置为同时设置多个权限位，例如第 6 位（AREA_1 读取）、第 1 位（写入受保护的用户内存）、第 0 位（从受保护的用户内存读取），再加上通过 SRAM_CONF_PROT 访问 SRAM，那么与 KEY_0 的一次成功相互验证是否会在单个会话中授予对所有这些区域的访问权限，直到字段丢弃或取消选择？ 还是主机必须为每个区域/每种访问类型分别发出验证？ 非常感谢 Re: AES mutual authentication in NTAG5 LInk 您好，感谢您对我们的产品感兴趣。 1.- 使用正确的访问密钥进行身份验证后，将授予权限，您可以对相应的 SRAM 区域进行 R/W 操作。 2.- 保护区域根据保护指针配置进行配置。第 8.1.3.11 节I2C 保护指针和条件。 3.- 每个密钥都有自己的密钥权限（KP0 = Key0 的权限，KP1 = Key1 的权限......）。使用 Key0 进行身份验证时，用户可以访问表 25 配置的内存。 Re: AES mutual authentication in NTAG5 LInk 嗨，法比安、 感谢您之前的回复。 关于第 1 点，我想再跟进一下、 在 AES 模式的 NTP5332 上，当 SRAM_CONF_PROT 位 NFC_SRAM_R = 1 和 NFC_SRAM_W = 1 时，表 25 没有列出 NFC_KPx 中的 SRAM 权限位。部分。 8.1.5提到可以通过 SRAM_CONF_PROT 限制 SRAM 访问，但我找不到描述相互验证如何解除这些限制的章节。 感谢您的时间和支持。 致以最诚挚的问候， Kavya Re: AES mutual authentication in NTAG5 LInk SRAM 的唯一访问条件是允许读取 SRAM 和写入 SRAM。但这只是为了允许读写。使用 MAM 进行身份验证不会解除这些限制。 如第 8.1.3.32 节所述，表 81 中的设备配置部分锁定字节显示了哪个位锁定了哪个部分。在这种情况下，SRAM_CONF_PROT 是第 3 节。请记住，这些锁定字节无法更新。这意味着，一旦配置，内存配置（在本例中为 SRAM 访问权限）将永久设置。 您能说明一下您尝试的是哪种用途吗？我们可能会提供更好的建议或 SRAM 的使用方法。

[不正行為] 投稿者: @RishavKaaraTech / 掲示板: TapLinx-SDK / 報告者: wvhylxyz wvhylxyz は、 @RishavKaaraTech が投稿した 「RFIDDiscover ツールを入手したが、その使い方はわからない」という 記事を以下の理由で報告しました。 理由：誤解を招く情報または虚偽の情報 詳細： dutasオンライン薬局ブログ いいえデュプロスト処方箋デュタスフェデックス なし処方箋デュタス販売 購入dutas echeck なし処方箋デュタス販売 購入義務を転がす 処方箋不要のデュプロスト（デュタス）をFedexで 割引デュタス薬局 処方箋dutasオンライン 次のデュタスを購入する場所 薬局dutas 電信送金 fedex 購入デュタス ミシガン デュタゲン 0 購入dutas 速達料金 一晩中 デュタスはどこで買えますか 購入dutas echeck can私はデュタスを最も安く買います 薬局dutas 電信送金 fedex デュタスを注文したい dutasオンライン薬局ブログ 購入オンラインのdutas uk 医薬品 デュタス・デュタステリダム錠剤割引 購入義務を転がす dutas英国で購入 カナダdutas ジェネリック オンライン 0 ジョージア州での迅速な配送の薬局dutas where次のdutasを注文するには ワシントン州でdutasを購入できますか dutasの注文方法 can私はdutasを購入します カナダdutas ジェネリック オンライン 0 購入dutas 薬局 処方箋不要 次のデュタスの購入場所 dutas イギリス最安値チェック dutas処方箋のみ サンドウェル 次のdutasの購入場所 入手dutas jcb セール最安値 dutas英国で購入 どこで次のdutasを購入する 購入dutas amex 薬局 ジョージア州への迅速な配達 投稿リンク： https://community.nxp.com/t5/TapLinx-SDK-TagWriter-and/RFIDDiscover-tool-acquired-but-how-to-use-it/mp/2164324#M205 投稿者: @RishavKaaraTech |作成者に電子メールを送信する 報告者： wvhylxyz |メールによる報告 報告された投稿には3件の返信があります。

RW61x 的 BSDL 文件 恩智浦是否发布了 RW61x 的 JTAG 边界扫描 BSDL 文件？ 我好像找不到了。 产品：WiFi RW6XX Re: BSDL files for RW61x 你好 希望你一切顺利。您使用的是 RTOS 还是 Zephyr？ 如果是 RTOS，SDK 版本是什么？ 如果是 Zephyr，哪个存储库？ 另外，能否请您说明一下您是否在使用模块？ 此致， 里卡多 Re: BSDL files for RW61x 我不知道操作系统为什么会与边界扫描文件有关。 我使用的是 Zephyr 4.4.0。 模块来自 u-blox，但上面有一个 RW610。 Re: BSDL files for RW61x 我们使用的是 BGA。 Re: BSDL files for RW61x 你好 你能澄清一下你使用的是哪种芯片封装吗？BGA/QFN 还是 CSP？ 顺祝商祺！ 里卡多 Re: BSDL files for RW61x 你好，我也在寻找 rw61x 系列芯片的 BSDL 文件。 您能为我指明下载这些文件的正确方向吗？ 谢谢！ 亚历克斯 Re: BSDL files for RW61x 恩智浦公司是否有人能回答这个问题？ 是否有RW61x的 BSDL 文件，如果有，在哪里可以下载？ 谢谢！ 亚历克斯-蒂茨沃斯

添加 USB 设备 CDC 固件支持 我正在尝试将 USB CDC VCOM 设备功能添加到在基于 LPC55S26 的设计上运行的裸机固件中。我已经更新到最新的 MCUXpresso IDE 和 SDK（包括 USB 设备中间件）。当我通过外围设备工具将 USB 设备添加到项目中并配置引脚、时钟等时，会出现两个错误（均相同）和一个警告，如下所示： 错误：" USB 设备 CDC " 驱动程序在项目中缺失。 警告：工具链/IDE 项目中的 USB 通用接头版本不支持。要求：2.8.0，实际：2.12.1：要求：2.8.0，实际：2.12.1。项目可能无法正确编译。 如果我尝试添加 SDK 元器件 " USB Device CDC " 我会收到一条消息，说在 SDK 中找不到该元器件，但是当我查看可用的 SDK 元器件时，它确实存在。如有任何建议，不胜感激。 Re: Add USB Device CDC firmware support 你好@markpotts123、 感谢您的来信。我注意到你也有一个关于同一主题的私人案例，我已经在那里给你回复了。如果您有任何新的更新，请随时回复，我将继续支持您。 祝您愉快 BR 西莱斯特 Re: Add USB Device CDC firmware support 原来是 IDE 和 SDK 版本不匹配。旋转到最新版本后，症状得到了解决。

内核恐慌：IMX-SDMA 导致原子调度 我们有一款运行恩智浦 Yocto i.MX、Linux、LF5.15.71_2.2.0 的定制 i.MX8M Plus 主板 我们遇到了间歇性内核恐慌，似乎与使用 ALSA aplay 播放音频有关。研究调用跟踪后发现，imx-sdma 驱动程序似乎是在原子上下文（见下文） soc_pcm_trigger()是在原子上下文中，sdma_prep_dma_cyclic()允许电源管理器恢复，并最终锁定了一个互斥项，导致调度。 这似乎与此处描述（和解决）的情况非常相似： [email protected] | [v6.1/standard/nxp-sdk-6.1/nxp-soc& v6.1/standard/preempt-rt/nxp-sdk-6.1/nxp-soc][PATCH] dmaengine: imx-sdma：使运行时 PM irq 安全 要重现这个问题非常困难，因为它每周只在实时系统上发生两次。 呼叫跟踪： dump_backtrace+0x0/0x19c show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 __schedule_bug+0x60/0x80 __schedule+0x658/0x710 计划+0x88/0x100 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x18c/0x56c __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_unprepare+0x24/0x44 clk_bulk_unprepare+0x3c/0x60 genpd_runtime_resume+0x26c/0x2b0 __rpm_callback+0x48/0x1a0 rpm_callback+0x6c/0x80 rpm_resume+0x378/0x614 __pm_runtime_resume+0x3c/0x8c sdma_prep_dma_cyclic+0x58/0x294 snd_dmaengine_pcm_trigger+0xec/0x1c0 dmaengine_pcm_trigger+0x18/0x24 snd_soc_pcm_component_trigger+0x164/0x230 soc_pcm_trigger+0xbc/0x1c0   Linux Yocto Project Re: kernel panic: imx-sdma causes scheduling while atomic 我知道这个主题已经很老了，但是这个问题在补丁中得到解决了吗？我在 linux-imx 5.10 上看到了同样的内核周期性恐慌现象 Re: kernel panic: imx-sdma causes scheduling while atomic 你好 我在运行 NXP Yocto i.MX、Linux、LF5.10.72_2.2.3 (hardknott) 的 iMX8MP 上遇到了同样的问题。 @Bio_TICFSL，你提到计划在 2025 年第一季度进行修复——已经发布了吗？它在哪些地方得到了应用，我又该如何加以利用？ 此致， Re: kernel panic: imx-sdma causes scheduling while atomic 你好 我在运行 NXP Yocto i.MX、Linux、LF5.10.72_2.2.3 (hardknott) 的 iMX8MP 上遇到了同样的问题。 @Bio_TICFSL，你提到计划在 2025 年第一季度进行修复——已经发布了吗？它在哪些地方得到了应用，我又该如何加以利用？ 此致， Re: kernel panic: imx-sdma causes scheduling while atomic 听到这个消息真是太好了。由于我们有一个变通办法（通过禁用 imx-sdma 的 PM），我们可以设法等待适当的解决方案。 Re: kernel panic: imx-sdma causes scheduling while atomic 你好 我们已经重现了这个问题，这个问题将在2025年第一季度发布的下一个版本中公开修复。 谢谢！ Re: kernel panic: imx-sdma causes scheduling while atomic 你好 您更新过内核吗？我无法用最新的 电路板支持包。 重现它。但是，如果修复了这个问题，这个问题就掌握在开发者手中，在下次 电路板支持包 版本之前我会一直处于修复状态。 此致 Re: kernel panic: imx-sdma causes scheduling while atomic 有什么新进展吗？ Re: kernel panic: imx-sdma causes scheduling while atomic 知道了将升级此问题，希望它现在能正常工作，谢谢。 此致 Re: kernel panic: imx-sdma causes scheduling while atomic 通过禁用 imx-sdma 驱动程序的运行时 pm，我们找到了一种解决方法，这让我们更加确信这是恩智浦 imx-sdma 驱动程序的问题。 这是解决方法： 在 > /sys/devices/platform/soc 上 回声 @0 /30c00000.bus/30e100000.dma-控制器/电源/控制 Re: kernel panic: imx-sdma causes scheduling while atomic @Bio_TICFSL我看了你的回复好几遍，但我不明白这与我的问题有什么联系？无论如何，在我的版本中，使用了来自 meta-imx 的固件-imx-8m v8.18。 我的问题似乎与 i.MX ALSA SoC 平台驱动程序在原子上下文中如何使用 sDMA 有关。 我在所附日志中还看到： tlv320aic3x 2 -0018 ： ASoC: error at snd_soc_component_update_bits on tlv320aic3x. 2-0018: -110 tlv320aic3x 是我们的 ASoC 编解码器驱动程序，不确定这是原因还是症状 Re: kernel panic: imx-sdma causes scheduling while atomic 你好 SDMA 固件由 meta-freescale 和 meta-imx 层提供，后者提供了它的更新版本。 恩智浦Yocto用户指南 IMX Yocto用户指南，建议使用恩智浦发布清单 imx清单中提及的层，其中也包括meta-imx层。 meta-imx 并不是机器支持所必需的，因为它应该只添加新的补丁，这些补丁稍后应合并到元飞思卡尔发行版层中。但是，fsl-image-machine-test镜像，这是由meta-freescale层提供的没有GUI或多媒体软件包的基本官方镜像，它还添加了固件守护程序软件包，通过udev信号从用户空间加载固件。 除此之外，我还确认，将imx-sdma驱动程序配置为模块后，固件将在模块加载后立即以直接模式加载，就我而言，相当于自启动以来大约10秒。 # dmesg | grep sdma [ 10.459118] imx-sdma 20ec000.sdma: TEST DEBUG: sdma_probe [ 10.541432] imx-sdma 20ec000.sdma: firmware found. [ 10.576034] imx-sdma 20ec000.sdma: loaded firmware 3.6 我同意这是一个更好的选择，即使没有同步加载补丁，也比依赖固件守护进程要好，因为在模块加载和固件加载之间几乎不会发生 sdma 传输。我不确定这是否适用于所有情况，但我认为恩智浦映像中的用户空间加载器可以支持所有可能驱动程序的懒固件加载，这样就不必将它们配置为模块。我希望安全的驱动程序通常会在开始传输前检查固件是否已加载，或者以其他方式安全失败，而不会惊慌失措。 此致