Multi Source Translation Content

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Multi Source Translation Content

ディスカッション

ソート順:
IMXRT EDMA error IRQ handler is not implemented in the SDK Hi, The IMXRT EDMA API in the SDK seems to handle "happy case" interrupts correctly.  However, there doesn't seem to be any provision for handling error interrupts.  Not only that, but it appears there is one global DMA_ERROR_IRQHandler for all DMA.  So if you're using both DMA0 and DMA1, when things are "happy" the DMA0/DMA1 IRQHandler would be called and the SDK can distinguish which DMA got the happy interrupt.  However, if there's a DMA error, since there's one global error interrupt handler, there's no easy way to know which DMA (0 or 1 or whatever) the error happened on. As in my previous question about LPUART error IRQ handling.  Why isn't this baked into the SDK to handle DMA errors and call appropriate callbacks?  Now I have to figure out how to determine which DMA the error is on by hand and call special handling outside the SDK instead of just having it call a callback for me. For an SDK that is supposed to be usable in production code, there seem to be a lot of missing robustness features, and I'm betting most people are just assuming these errors are handled under the hood by the SDK, and they don't think about the fact that they really aren't. -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK Dear @nxp16 , Which i.MX RT device are you using? When you mention DMA0 and DMA1, are you referring to two DMA channels rather than two DMA controller peripherals? Not all i.MX RT devices have two eDMA controllers. For example: i.MX RT1180 contains two eDMA controllers. In the startup file (for example, startup_mimxrt1189_cm33.c), you can find two DMA error handlers: DMA_ERROR_IRQHandler and DMA4_ERROR_IRQHandler. i.MX RT1050 contains only one eDMA controller. In the startup file (for example, startup_mimxrt1052.c), there is only one DMA error handler: DMA_ERROR_IRQHandler. In general, DMA errors are relatively infrequent events. From the hardware architecture perspective, channel error status is aggregated into a module-level error request, which triggers the DMA error interrupt. Therefore, the software must examine each channel's error status register (for example, CHn_ES) to determine which specific channel caused the error. Best Regards, Shelly Zhang Re: IMXRT EDMA error IRQ handler is not implemented in the SDK Sorry, I meant channel.  I'm using IMXRT1172. Wouldn't DMA errors occur if there was a problem with whatever peripheral it was being used with?  I.e. if it was LPSPI with DMA wouldn't any SPI errors cause a DMA error?  If not, then do SPI errors when using DMA trigger a SPI error interrupt? Thanks, -m
記事全体を表示
新建项目向导失败:未自动添加 FreeRTOS 端口 大家好, 我正在尝试使用 MCUXpresso IDE V24.12 为 LPC5536 创建一个基于 freeRTOS 的项目。 “创建新的 C/C++ 项目”向导(可从快速入门面板获取)似乎提供了一种简单的方法,可以将 freeRTOS 支持添加到项目中(请参见下方屏幕截图中的标记): 如您所见,“新建项目向导”提供了一个复选框,用于添加 freeRTOS 作为“操作系统”。选中此复选框后,向导会自动添加 freeRTOS 的另一个关键部分——内存管理器(请参见下方标记的复选框): 然而,该向导未能添加freeRTOS 中最重要的部分,即 MCU 特定的代码(请参见下方屏幕截图中的标记): 如果您不自行选择此元器件,则生成的项目会抛出编译错误。我认为“新建项目向导”应该始终生成一个可编译的项目。此外,MCUXpresso IDE 手册明确指出:“同时,选择一个元器件会自动选择其所有依赖项。”(第 5.1.1 节)SDK 新建项目向导)。 我认为这至少是一个用户体验方面的缺陷。 我希望这个问题能在下一个 SDK / MCUXpresso 版本中得到修复。 谢谢。 丹尼尔 Re: New Project Wizard fAiL: no freeRTOS port added automatically 我使用 MCUXpresso IDE v25.6(撰写本文时的最新版本)和 LPC5536 SDK(版本 25.06,清单 3.15)进行了尝试,但 FreeRTOS 内核和 cm33 端口之间的依赖关系仍然缺失,需要手动选择。 Re: New Project Wizard fAiL: no freeRTOS port added automatically 你好@EdwinHz , 感谢您的及时支持。 谢谢。 丹尼尔 Re: New Project Wizard fAiL: no freeRTOS port added automatically 嗨@danielholala , 我重现了这个问题,这绝对是一个 bug,因为项目向导应该会自动选择所有依赖项。我会将此问题报告给 IDE 团队,以便他们可以在 MCUXpresso 项目向导的未来版本中进行修正。 感谢您报告此问题。 BR, 埃德温。
記事全体を表示
i.MX8M PLUS) 交換部品互換性 LPDDR4 NXP様、 I.MX8PLUS EVBで使用されたLPDDR4部品である*Z2BMは生産終了です。 部品供給業者は、交換部品として**Z2BMと***Z42BMを推奨しています。 *Z2BM: MT53E1536M32D4DT-046 WT:A (EVB部品) **Z4BM: MT53E1536M32D4DE-046 WT:C (交換部品 1) ***Z42M: MT53E1G32D2FW-046 WT:BP (交換部品 2) これら2種類の交換部品を使用しても問題ないかどうかお伺いしたいのですが。 よろしくお願いします。 よろしくお願いいたします。 チョン・インホ Ace テクノロジ Re: i.MX8M PLUS) Replacement part compatibility LPDDR4 こんにちは、 @Inho さん。 上記の2種類のDRAMは問題なく使えます。 BR
記事全体を表示
运行外部闪存 大家好, 我正在使用 MCXN547-EVK 开发板,并尝试 使用 四通道SPI (FlexSPI) 接口连接外部 W25Q64JWTBJQ 闪存 。我正在使用 IAR Embedded Workbench 构建项目 。 在使用 MCUXpresso SDK 构建spi_flash示例时,我遇到了以下错误: CMake Error: Cannot find source file: .../examples/_boards/mcxn5xxevk/demo_apps/spi/spi_flash/cm33_core0/pin_mux.c 之前有人遇到过这个问题吗?请问您能否帮我分析一下造成这种情况的原因以及如何解决? 任何建议都将不胜感激。谢谢你! MCX N Re: Run External Flash 你好@Ashish-625 请您确认一下 pin_mux.c 文件是否正确。文件是否存在于以下路径? examples/_boards/mcxn5xxevk/demo_apps/spi/spi_flash/cm33_core0/pin_mux.c   此外,请确认您使用的是哪个 MCUXpresso SDK 版本,以及 spi_flash 演示是否基于 IAR Embedded Workbench 下载。   谢谢!   BR 爱丽丝
記事全体を表示
Offering Contribution: Complete PFE Plugin for S32DS, LWIP Integration & tcpip/LLCE Fixes Hello NXP Team and S32G Community, I have developed a complete PFE plugin for S32 Design Studio (S32DS) / S32 Configuration Tools. Previously, PFE configuration support was available only through EB Tresos. The new plugin includes: Full native integration within the S32DS environment Seamless integration with NXP’s official tcpip plugin for LWIP stack support Complete TSN traffic shaper configuration (TAS and CBS) Thorough testing with LWIP and LLCE, including offload scenarios In the process, I also identified and resolved several bugs in the official tcpip and LLCE plugins. This enhancement enables smoother development of advanced Ethernet and TSN applications on S32G platforms. I would like to contribute the full plugin, integration components, bug fixes, documentation, and test results to NXP. This could be integrated into future RTD or S32 Configuration Tools releases, or shared as an official reference for the community. Questions for the NXP Team: What is the recommended process to formally submit this contribution (e.g., via a technical support case or other channel)? Are there any particular requirements regarding documentation, packaging, or agreements (such as NDA)? I have prepared a comprehensive package including the plugin files, installation/integration guide, detailed changelog, and verification results. I am happy to share it privately and support any technical review or discussion. Thank you in advance for your guidance. I look forward to your feedback. Best regards, Arsal Imam SDV Architect @ GK Automobiltechnologie (Disrupt) GoldVIP Re: Offering Contribution: Complete PFE Plugin for S32DS, LWIP Integration & tcpip/LLCE Fixes Hi,arsalimam First of all, thank you for sharing this impressive work and for your willingness to contribute it to the NXP. The functionality you described—including native S32 Design Studio integration, LWIP/tcpip integration, TSN traffic shaping support (TAS/CBS), LLCE validation, and the related bug fixes—appears very valuable for S32G Ethernet and TSN development. At this stage, contributions of software components, plugins, and modifications to existing NXP tooling require review by the relevant product and software teams. As the acceptance process may involve technical evaluation as well as intellectual property and legal considerations. You can share your materials through our customer support system: https://support.nxp.com We appreciate your effort and your interest in improving the S32G software ecosystem. BR Joey
記事全体を表示
i.MX8M PLUS)替换部件兼容性 LPDDR4 尊敬的恩智浦: *Z2BM 是 I.MX8PLUS EVB 中使用的 LPDDR4 元器件,现已停产。 零件供应商推荐使用 **Z2BM 和 ***Z42BM 作为替换零件。 *Z2BM:MT53E1536M32D4DT-046 WT:A(EVB部件) **Z4BM:MT53E1536M32D4DE-046 WT:C(替换零件 1) ***Z42M:MT53E1G32D2FW-046 WT:BP(替换零件 2) 我想咨询一下,使用这两种类型的替换零件是否可以。 谢谢! 顺祝商祺! 全仁浩 艾斯科技 Re: i.MX8M PLUS) Replacement part compatibility LPDDR4 嗨@Inho 您可以毫无问题地使用上述两种类型的动态随机存取存储器(DRAM)。 BR
記事全体を表示
HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job Hello Nxp team, I have use case to use HMAC verify job. After triggering the job crypto driver throw DET and the response from HSE is "HSE_SRV_RSP_INVALID_PARAM". I am not able to understand what wrong with my current configuration. could you please check attached config zip file?  Need support to resolve issue. Thanks, Aditya Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job Hi @lukaszadrapa , Details: Device: S32K311 HSE FW: HSE_FW_S32K311_0_2_55_0 RTD: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 Thanks, Aditya Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job Hi @WagdeoA  Could you confirm which device, which RTD and which HSE firmware version you have? Regards, Lukas Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job Hi @WagdeoA  There’s no problem in your configuration. It works on my side. But one possible issue could be the length of tag (secondaryInputLength). This can be found in function Crypto_Ipw_HmacVerify: If redirection is disabled, it’s necessary to provide the length of tag in bits, not in bytes. Isn’t this the problem? Regards, Lukas
記事全体を表示
如何为我们使用的 i.mx RT1062 路由器获取唯一的以太网 MAC 地址? 你好, 我们使用MIMXRT1062DVL6B,并通过以太网实现我们的产品。 首先,我们使用 `fsl_silicon_id.c` 中的 ` SILICONID_ConvertToMacAddr`为我们的产品实现 MAC 地址,以便使用 NXP 的 OUI 和硅 ID 为每个设备获取唯一的 MAC 地址。 但是,我们通过` SILICONID_ConvertToMacAddr`获取的 MAC 地址并不唯一,它们都相同。 我有个问题。 在调用 `SILICONID_ConvertToMacAddr` 之前,我们需要做哪些设置? 或者,`SILICONID_ConvertToMacAddr` 无法通过 NXP 设备获取唯一的 MAC 地址? 我们在 IMXRT1060RM.pdf 的 Rev. 4, 01/2026 中找不到答案。 您能给我们答案吗? 谢谢。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? 嗨,阿布纳 感谢您的支持! 我们了解到,我们可以使用通过SILICONID_ConvertToMacAddr 函数获取的 MAC 地址作为我们产品的 MAC 地址。但我明白 SILICONID_ConvertToMacAddr 只是一个示例,我们不能将其用于我们的大规模产品。我们必须使用我们 OUI 下的 MAC 地址。 顺祝商祺! 茂 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? 嗨@shigeru-tsujita 感谢您发现这种情况。我们使用 SILICONID_ConvertToMacAddr 函数来减少 NXP MCUX SDK 示例中的 MAC 地址冲突,以用于我们的测试环境。我们在同一交换机上连接不同 SoC 的以太网接口。对于同一系列 SoC 的情况,我们可能无法涵盖。 但我不太明白的是,为什么你们要用这种方式生成产品 MAC 地址。首先,您的 OUI 应该使用您公司的 OUI。那么,我认为贵公司应该对唯一标识符有一个内部特殊定义。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? 你好,梅。 我理解 SILICONID_ConvertToMacAddr 使用固定的 NXP OUI 和三个字节的硅 ID(它是 OCOTP->CFG0/1 的一部分)来生成 MAC 地址。 我观察了我们目标产品的 OCOTP->CFG0/1。 这些数值如下: - 一个 MIMXRT1062 - OCOTP->CFG0: (uint32_t)0x615c'faa4 - OCOTP->CFG1: (uint32_t)0x2a1e'61d7 - 其他 MIMXRT1062 - OCOTP->CFG0: (uint32_t)0x615c'faa4 - OCOTP->CFG1: (uint32_t)0x4922'61d7 因为 OCOTP->CFG0 的低三个字节在 SILICONID_ConvertToMacAddr 中用作 MAC 地址,所以它们的 MAC 地址相似。 因此,我们很多产品的 MAC 地址都很相似。(现在我们有几十个原型机,虽然我们不会检查所有的 MAC 地址,但我们还没有找到与 54:27:8D:A4:FA:5C 不同的 MAC 地址。) 谢谢。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? 嗨@shigeru-tsujita , 非常感谢您对我们产品的关注以及对我们社区的使用。 假设 SDK 的 silicon_id 元器件已正确集成,则在调用 MIMXRT1062 的 SILICONID_ConvertToMacAddr() 之前无需进行其他设置。 请注意,SILICONID_ConvertToMacAddr() 不使用完整的 64 位硅 ID 来生成 MAC 地址。它使用固定的 NXP OUI 作为前 3 个字节,而最后 3 个字节仅使用来自硅 ID 的 3 个字节。 根据SDK代码: 请您读取几个设备的 64 位硅唯一 ID,并检查 ID 值是否读取正确?另外,请比较 siliconId[0]、siliconId[1] 和 siliconId[2],因为这些是用于生成 MAC 地址的字节。 如果这三个字节在各个设备上都相同,则生成的 MAC 地址也将相同。 顺祝商祺! 5月
記事全体を表示
外部フラッシュを実行する こんにちは、みんな、 私は MCXN547-EVK 開発ボードを使っており、 Quad SPI(FlexSPI) を使って外部 W25Q64JWTBJQ フラッシュメモリ とインターフェースしようとしています 。 私は IAR Embedded Workbench でプロジェクトを構築しています 。 MCUXpresso SDKからspi_flash例を構築していると、以下のエラーに遭遇しました: CMake Error: Cannot find source file: .../examples/_boards/mcxn5xxevk/demo_apps/spi/spi_flash/cm33_core0/pin_mux.c 以前にこの問題に遭遇した方はいますか?原因と解決方法を教えていただけませんか? 何かご提案があれば大変ありがたいです。ありがとう! MCX N Re: Run External Flash こんにちは、 @Ashish-625さん pin_mux.c.がファイルは以下のパスに存在しますか? examples/_boards/mcxn5xxevk/demo_apps/spi/spi_flash/cm33_core0/pin_mux.c   さらに、どのMCUXpresso SDKバージョンを使用しているか、またspi_flashデモがIAR Embedded Workbenchベースのダウンロード版かどうかも確認してください。   よろしくお願いします。   BR アリス
記事全体を表示
i.MX8M PLUS) Replacement part compatibility LPDDR4 Dear NXP,  The *Z2BM, an LPDDR4 component used in the I.MX8PLUS EVB, has been discontinued. The parts supplier has recommended the **Z2BM and ***Z42BM as replacement parts. *Z2BM: MT53E1536M32D4DT-046 WT:A (EVB Part) **Z4BM: MT53E1536M32D4DE-046 WT:C (Replacement Part 1) ***Z42M: MT53E1G32D2FW-046 WT:B P (Replacement Part 2) I would like to inquire if it is acceptable to use these two types of replacement parts. Thank you. Best Regards, Inho Jeon Ace Technologies Re: i.MX8M PLUS) Replacement part compatibility LPDDR4 Hi @Inho  You can use  two types of DRAM mentioned above without any problems. B.R
記事全体を表示
IMXRT EDMAエラーIRQハンドラはSDKには実装されていません こんにちは、 SDK内のIMXRT EDMA APIは「ハッピーケース」割り込みを正しく処理しているようです。しかし、エラー割り込みを処理するための仕組みは見当たらないようだ。それだけでなく、すべてのDMAに対して1つのグローバルなDMA_ERROR_IRQHandlerが存在するようです。例えばDMA0とDMA1の両方を使っている場合、状況が「良好」な状態にあるときにDMA0/DMA1のIRQHandlerが呼び出され、SDKがどのDMAがハッピーインタラプトを受け取ったかを識別できます。しかし、DMAエラーが発生した場合、グローバルなエラー割り込みハンドラが1つしかないため、どのDMA(0、1、またはその他)でエラーが発生したかを簡単に知る方法はありません。 以前の質問で、LPUARTエラーIRQ処理について質問したのと同様です。なぜこれがSDKに組み込まれていて、DMAエラーを処理したり適切なコールバックを呼び出したりしないのでしょうか?今は、エラーがどのDMAにあるかを手作業で特定し、SDK外の特別な処理を呼ぶ方法を考えなければなりません。単にコールバックを呼んでもらうのではなく。 本番コードで使えるはずのSDKにしては、堅牢性の機能が欠けているように思えますし、多くの人はこれらのエラーがSDKによって処理されていると思い込んでいて、実際にはそうではないという事実を考えていないのだと思います。 -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK @nxp16様、 どのi.MX RTデバイスをお使いですか?DMA0とDMA1の話ですが、2つのDMAコントローラペリフェラルではなく、2つのDMAチャネルのことを指していますか? すべての i.MX RTデバイスに2つのeDMAコントローラーがあるわけではありません。例えば: i.MX RT1180には2つのeDMAコントローラが含まれています。スタートアップファイル(例:startup_mimxrt1189_cm33.c)には、DMA_ERROR_IRQHandlerとDMA4_ERROR_IRQHandlerの2つのDMAエラーハンドラがあります。 i.MX RT1050にはeDMAコントローラが1つしかありません。起動ファイル(例えば、startup_mimxrt1052.c)では、DMAエラーハンドラはDMA_ERROR_IRQHandlerという1つだけです。 一般的に、DMAエラーは比較的まれなイベントです。ハードウェアアーキテクチャの観点からは、チャネルエラーの状態はモジュールレベルのエラー要求に集約され、DMAエラー割り込みを引き起こします。したがって、ソフトウェアは各チャネルのエラーステータスレジスタ(例えばCHn_ES)を調べ、どの特定のチャネルがエラーを引き起こしたかを特定しなければなりません。 よろしくお願いいたします。 シェリー・チャン Re: IMXRT EDMA error IRQ handler is not implemented in the SDK すみません、チャネルのことを言いました。私はIMXRT1172を使用しています。 もし使っていた周辺機器に問題があった場合、DMAエラーは起こるのではないでしょうか?つまり、LPSPIとDMAを組み合わせた場合、SPIエラーが発生するとDMAエラーも発生するのではないでしょうか?そうでない場合、DMA使用時のSPIエラーはSPIエラー割り込みをトリガーしますか? ありがとうございます -m
記事全体を表示
Battery Management System - Overview 1 Table of Contents • Introduction • Overview • Target Audience • Context • References • Conclusion 2 Introduction A Battery Management System (BMS) is a system that monitors and manages a battery pack to ensure it operates safely, efficiently, and reliably, making it a critical component in electric vehicles. Its main functions include measuring voltages, currents, and temperatures and balancing the cells to maintain consistent performance. This overview introduces a series on the architecture, development and integration of a battery management system developed using NXP hardware and software. To accelerate this process, MathWorks ecosystem is used to streamline the development, maintain traceability from model to implementation and to validate complex embedded applications.   3 Overview Articles roadmap Developing a battery management system is a complex undertaking, and explaining it thoroughly requires a structured series of articles. Each article focuses on a key stage of the development process, offering detailed insight into how such a system is designed, implemented, tested, and validated from concept to deployment. The series includes the following articles: Software and Hardware Environment - An overview of the required software environment, including NXP software development kits (SDKs), real-time drivers (RTDs), and MathWorks toolboxes, together with the hardware platform used in the application. Architecture and Model Description - A detailed description of the system architecture, including the model structure, input and output signals, and the core algorithms used in the battery management system. Validate the BMS Algorithms (Model-in-the-Loop) - An explanation of how validated MathWorks battery management assets - such as state-of-charge (SoC) and state-of-health (SoH) estimation algorithms - can be adapted, integrated, and verified within the application model. Preparing BMS Algorithms for Code Generation (Software-in-the-Loop) - Guidance on generating production-oriented code from validated models and running software-in-the-loop (SiL) simulations to compare code behavior against the model-in-the-loop (MiL) baseline. Bringing the BMS Closer to Hardware (Processor-in-the-Loop) - Steps to prepare the model for execution on target hardware by deploying the generated software to an NXP evaluation board while emulating battery measurements on a host PC. Deployment and Validation on the High-Voltage BMS Reference Design Kit - Configuration of external devices to supply real data to the BMS algorithms, followed by system-level validation. Extending the Controller with CAN Communication - Integration of controller area network (CAN) communication by defining the CAN database, configuring the communication stack, and validating message exchange on the NXP hardware. Final Results - A summary and discussion of results, along with final validation of the complete battery management system. What is the Battery Management System? A Battery Management System (BMS) is a combined hardware and software system responsible for monitoring, controlling, and protecting an electric vehicle's battery pack. Technically, it acts as the central authority that has full visibility into the battery's operating conditions, such as cell voltages, pack current, and temperatures. Based on this information, the BMS makes real-time decisions to keep the battery within safe operating limits. It also enforces critical protections - such as preventing overcharge, over-discharge, over-temperature, or short-circuit conditions - which are essential for safety, reliability, and regulatory compliance. From a functional perspective, the BMS performs several key jobs that directly impact vehicle performance and longevity. These include estimating battery states such as State of Charge (SoC), State of Health (SoH), and available power, which higher-level vehicle systems rely on for range prediction and energy management. The BMS also manages cell balancing, ensuring that individual cells within the pack age uniformly and maintain similar voltage levels. This combination of accurate state estimation and active control helps maximize usable energy, protect the battery from accelerated degradation, and maintain consistent performance throughout the vehicle's life. On the hardware side, a BMS typically consists of sensing components (voltage, current, and temperature sensors), cell monitoring and balancing ICs, a microcontroller, isolation components, and communication interfaces. These elements work together to acquire high-precision measurement data from the battery pack and execute control actions such as enabling contactors or activating balancing circuits. In many architectures, the system is distributed, with multiple cell monitoring units communicating with a central BMS controller. The software layer ties everything together and is often the most complex part of the system. BMS software includes low-level drivers for sensors and communication, real-time control logic, diagnostic and fault-handling mechanisms, and advanced algorithms for state of charge estimation. It must integrate seamlessly with the rest of the vehicle through networks such as CAN, allowing the BMS to exchange data with vehicle control units, chargers, thermal management systems, and the powertrain. Through this tight hardware-software integration, the BMS becomes a core enabler of safe operation, efficient energy use, and coordinated vehicle behavior. 4 Target Audience This article series is intended for engineers, technical specialists, and decision-makers involved in the development, integration, or evaluation of high-voltage battery management systems for electric vehicle applications. It is especially relevant for readers who want to understand how BMS algorithms, embedded software, hardware platforms, and validation workflows come together in a complete development process. The content is suitable for both engineers looking for practical implementation guidance and technical stakeholders interested in the benefits of using a Model-Based Design approach with MathWorks and NXP solutions. The main target audience includes: Embedded software engineers Control and algorithm engineers Battery system engineers Electric vehicle system architects Model-Based Design engineers Hardware and integration engineers Test and validation engineers Technical managers and project leads 5 Context In the electric vehicle architecture presented in this series, the Battery Management System is located in the rear zone of the vehicle. It is a safety-critical controller responsible for battery supervision, but it operates within a highly interconnected ecosystem. It bridges: Battery pack (physical layer) Vehicle Control Network (communication layer) Powertrain and Vehicle Behavior (functional layer) The HVBMS is implemented on the reference design bundle for 800 V high-voltage battery management systems. It provides a complete hardware solution including: RD-K358BMU - battery management Unit (BMU) RD33774CNT3EVB - cell monitoring unit (CMU) RD772BJBTPL8EV - battery junction box (BJB) 18 Cell Battery Pack Emulator 6 References Speed-Up BMS Application Development with NXP's HVBMS RD and Model-Based Design Toolbox (MBDT) Model-Based Design Toolbox NXP Community 800 V Battery Management System (BMS) Reference Designs Using ETPL Model-Based Design Toolbox (MBDT) 7 Conclusion This article introduced the Battery Management System within the context of an electric vehicle architecture and established the technical foundation for the rest of the series. It described the role of the Battery Management System and illustrated how a Model-Based Design workflow can be implemented by combining the MathWorks and NXP ecosystems. The next article will focus on the software and hardware environment needed to develop, simulate, and deploy a Battery Management System using MathWorks and NXP solutions.
記事全体を表示
Developing a Steering System with Model-Based Design Toolbox 1 Table of Contents • Introduction • Overview • Context • References • Conclusion 2 Introduction The steering system is an essential and safety-critical component of any vehicle, responsible for controlling the direction of wheel movement and guiding the vehicle along the intended path. In our Hello World with MBDT project, the Steering subsystem delivers this capability by driving a steering motor to a desired angle and direction, transmitting the resulting torque to the road wheels through the steering column and rack-and-pinion assembly. Figure 1. Hello World with MBDT Demo – Steering system This article series presents the Electric Power Steering (EPS) system in Electric Vehicle (EV) architecture and covers the hardware, software, code generation, and vehicle network integration needed to implement the system using a Model-Based Design (MBD) workflow with MathWorks tools and NXP hardware. 3 Overview 2.1. What will this series of articles cover? The articles in this series will present the Steering System within an EV architecture and cover the following topics: Software and Hardware Environment Overview of the MathWorks and NXP tools used to develop, test, and validate the EPS control system. Logic Control Description of the model architecture, signal interfaces, and core control algorithms implemented in the Steering System. Deployment on Real Hardware Integration with physical hardware, the stepper motor, 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. System Validation Presentation of the final implementation results and validation of the complete system behavior. 2.2. What is the Electric Power Steering System? Electric Power Steering (EPS) eliminates the hydraulic pump found in conventional steering systems, instead relying on an electric motor driven by an Electronic Control Unit (ECU). Torque and position sensors mounted on the steering column feed real-time measurements to the ECU, which computes the required assist level and commands the motor accordingly. This on-demand assist approach improves energy efficiency, enables precise tuning of steering feel, and provides a programmable interface for Advanced Driver Assistance Systems (ADAS). Figure 2. Electric Steering Rack and Pinion EPS systems are classified based on where the electric motor is mounted on the steering mechanism. Column Assist Type (C-EPS) - The electric motor and control unit are mounted directly on the steering column inside the cabin. Pinion Assist Type (P-EPS) - The electric motor is attached to the pinion shaft within the steering gear box. Dual-Pinion Assist Type (DP-EPS) - This system separates the assist function from the steering mechanism. One pinion gear connects the steering wheel, while the electric motor applies assistance to a second, separate pinion gear directly on the steering rack. Rack Assist Type (R-EPS) - The electric motor is mounted directly onto the main steering rack, either via a concentric motor around the rack or a belt drive. Steer-by-Wire (SbW) - The mechanical connection (steering column and intermediate shaft) between the steering wheel and the wheels is entirely removed. Key Characteristics of Steer-by-Wire EPS: The wheel's movement is handled completely by electronic sensors, algorithms, and actuators It allows for completely customizable steering ratios Frees up interior cabin space Relies heavily on redundant electronics and fail-safes 2.3. Target Audience This series is intended for engineers and technical stakeholders involved in the development, integration, and evaluation of electric power steering systems, including the following audiences: Mechanical and Embedded Software Engineers Motor Control & Power Electronics Engineers System Architects & Vehicle Architecture Engineers Model-Based Design and Simulink Developers Academic and Research Communities 4 Context In the example vehicle architecture used throughout this series, the Steering System is located in the front zone of the vehicle. The Steering ECU is built around the NXP S32K312 microcontroller, which provides both CAN and LIN connectivity. Note: The NXP S32K312 microcontroller provides the processing performance, peripheral set, and communication interfaces (CAN, LIN) required for automotive steering control applications. The ECU drives the stepper motor to the commanded position and communicates desired angle and direction requests over CAN to the Zonal Controller, which coordinates these signals with the central vehicle control node. 5 References Steering column - Wikipedia Power steering - Wikipedia Electric Power Steering (EPS) System Parts Solutions | NXP Semiconductors Electric power steering system (EPS) Clemson Vehicular Electronics Laboratory: Electric Power-Assisted Steering Electric Steering Rack and Pinion 6 Conclusion This article introduced the Electric Power Steering system architecture, its core components, and its position within a modern EV platform. It outlined the Model-Based Design approach using MATLAB/Simulink and NXP hardware as the development foundation, from algorithm modeling through automatic code generation and hardware deployment. The next article will focus on the software and hardware environment required to develop, simulate, and deploy the EPS control system using MathWorks and NXP solutions.
記事全体を表示
DOC_S32K3x1_S32K3x2_S32K3x4_eMCEM_DCM_Mapping_v1_0_SPD1.0.5_Unofficial Mapping between SPD eMCEM and DCM for S32K311, S32K312, S32K314, S32K322, S32K324, S32K341, S32K342, S32K344.
記事全体を表示
Monitor the CPU loading using ebpf to reduce system call overhead A lightweight CPU utilization monitor built with eBPF + libbpf.   It hooks into the kernel scheduler (sched_switch tracepoint) to measure per-CPU active time with nanosecond precision — more accurate than polling-based tools like top, and with lower overhead at high process counts. How it works   Kernel (eBPF) User space (C + libbpf) ----------------------- ------------------------- sched_switch tracepoint poll BPF maps every 1 s -> record on-CPU time per core -> compute active % and idle % -> accumulate in BPF Array map print per-core + average   The sched_switch tracepoint context structure is defined manually in cpu_monitor_bpf.c. Output The monitor displays per-core active/idle percentages, with the idle column matching top's id field for easy comparison:   CPU Core   | Active %   | Idle % (=top id) ------------------------------------------- CPU 0      |     0.34%  |         99.66% CPU 1      |    21.89%  |         78.11% CPU 2      |     0.15%  |         99.85% CPU 3      |     0.03%  |         99.97% ------------------------------------------- TOTAL AVG  |     5.60%  |         94.40%   To compare with top, press 1 in top to show per-core stats, then compare the id column with the Idle % column above. Prerequisites Host (build machine) Package Purpose clang + llvm version 21 Compile BPF C source to BPF ELF bpftool Generate BFP skeleton headers aarch64 Poky Toolchain Corss-compile the user-space binary   Install on Ubuntu/Debian: wget https://apt.llvm.org/llvm.sh chmod +x llvm.sh ./llvm.sh 21 apt update apt install -y llvm-21 clang-21 lld-21 lldb-21 update-alternatives --install /usr/bin/llvm-link llvm-link /usr/bin/llvm-link-21 100 update-alternatives --install /usr/bin/clang clang /usr/bin/clang-21 100 update-alternatives --install /usr/bin/llc llc /usr/bin/llc-21 100 llvm-link --version clang --version # install bpftool apt install linux-tools-$(uname -r) Target board Tested Linux kernel == 6.18.20-2.0.0 Tested image == imx-image-full Most BPF configurations are enabled by default. In addition, you need CONFIG_FTRACE=y to enable tracepoint support (required for the sched_switch hook). Build Build the project on your host machine: TOOLCHAIN_PATH=/opt/fsl-imx-internal-wayland/6.18-whinlatter/environment-setup-armv8a-poky-linux ./build_and_deploy.sh   The script will: Source the Poky toolchain environment Run make clean && make all (compiles BPF object, generates skeleton, cross-compiles user-space binary) Install the binary to ./board_deploy/cpu_monitor Deploy and run   # Copy binary to the board scp board_deploy/cpu_monitor root@<board-ip>:/usr/bin/ # Run on the board (root required for eBPF) ssh root@<board-ip> ./cpu_monitor   Press Ctrl+C to exit.   Benchmarking: eBPF vs top A scheduler stress test script is included to compare monitoring overhead between cpu_monitor and top under high scheduling pressure. Run the stress test On the target board, open three terminals:   # Terminal 1: start scheduler pressure (200 threads, 30 seconds) ./stress_sched.sh -t 200 -d 30 # Terminal 2: measure eBPF monitoring overhead perf stat -e cpu-clock,task-clock,context-switches,cpu-migrations,instructions timeout -s KILL 10 ./cpu_monitor # Terminal 3: measure top monitoring overhead perf stat -e cpu-clock,task-clock,context-switches,cpu-migrations,instructions top -b -d 1 -n 10 Compare task-clock, instructions, and context-switches from perf stat output. Try different thread counts to observe scaling behavior:   ./stress_sched.sh -t 50 -d 30     # low pressure ./stress_sched.sh -t 200 -d 30    # medium pressure ./stress_sched.sh -t 500 -d 30    # high pressure Result Test environment: i.MX943 (4x Cortex-A55), Linux 6.18.20, 10-second measurement window. Comparison results in free system load: Indicator eBPF cpu_monitor top delta task-clock (CPU timing) 12.0 ms 263.9 ms 22x CPU usage 0.1% 2.8% 28x instructions 3.38M 197M 58x context-switches 12 17   sys time (kernel time) 5.0ms 199.5ms 40x user time 0 62.1ms     Comparison results in high scheduling pressure (200 threads): Indicator eBPF cpu_monitor top delta task-clock (CPU timing) 12.6ms 690ms 54x CPU usage 0.1% 6.1% 61x instructions 4.8M 538M 112x context-switches 122 9019 75x sys time (kernel time) 4ms 461ms 115x user time 0 206ms     Project structure ebpf_cpu_usage/ ├── cpu_monitor_bpf.c      # Kernel-side eBPF program (C, compiled to BPF) ├── cpu_monitor.c          # User-space program (C, cross-compiled to aarch64) ├── Makefile               # Build rules ├── build_and_deploy.sh    # One-shot build + package script ├── stress_sched.sh        # Scheduler stress test for benchmarking └── README.md   A lightweight CPU utilization monitor built with eBPF + libbpf.   It hooks into the kernel scheduler (sched_switch tracepoint) to measure per-CPU active time with nanosecond precision — more accurate than polling-based tools like top, and with lower overhead at high process counts. i.MX Processors
記事全体を表示
lowlight opensource ai-isp test on imx95       There are many open-source low-light AI-ISP models. The table below is a comparison table provided by Copilot.  Algorithm GitHub Type i.MX95 NPU Suitability FPGA Suitability MSR (Retinex) jsrsinchana/.../MSR-algorithm Non-AI (ISP) Medium Very High Zero-DCE++ arnabroy734/low_light_enhancement Lightweight CNN + Curve Very High Very High RetinexNet weichen582/RetinexNet CNN (Retinex) Medium High EnlightenGAN VITA-Group/EnlightenGAN GAN (CNN) Very High (lite) Low FLOL cidautai/FLOL Lightweight CNN High Low SNR-aware JIA-Lab-research/SNR-Aware Transformer + CNN Low Low KinD zhangyhuaee/KinD Retinex + CNN Medium Medium RetinexNet-lite Derived Light CNN Medium High EnlightenGAN-lite Derived Small CNN Very High Low Fast LLIE CNN Various Small CNN High Medium We selected some open-source models and used UVC to perform performance tests on the exip-os08a20 module with no HDR mode. We found that SCI(GitHub - vis-opt-group/SCI: [CVPR 2022] This is the official code for the paper "Toward Fast, Flexible, and Robust Low-Light Image Enhancement". · GitHub) computation is relatively small, low-light performance is good in subjective evaluations, and it can basically run on the IMX95. The testing method involves copying the tflite file and test script to the /root/ directory of the IMX95 and running the following command: `python3 test_sci_cvpr_illu_imx95_int8.py --model sci_tpami_illu_imx95_int8.tflite`. The comparison interface shown below is displayed.
記事全体を表示
Boot uses C40 to erase and rewrite flash. Hello, I'm having trouble writing to flash memory using the C40 chip in the bootloader. I'm writing a 300KB binary program, and it frequently fails at the 9th data packet (the second block), with only a 1/10 chance of succeeding completely. Could you please check if there's a problem with my C40 chip? The main program I'm writing... Flash_UnlockSectorIfProtected ( cur_sector ) ; DisableAllInterrupts () ; DisEnableIrq1 () ; if ( Flash_Write ( flash_write_addr + offset , & payload [ 2 ] , FIXED_PACKET_DATA_LEN ) != 0 ) { EnableIrq1 () ; EnableAllInterrupts () ; } EnableIrq1 () ; EnableAllInterrupts () ; Is there a problem with my use of Power_Ip_MC_ME_SocTriggerResetEvent(POWER_IP_DEST_RESET_MODE) for resetting? How can I prevent consecutive resets after 8 attempts, and what function should I use for jumps? func = * ( uint32_t volatile * )( ADDR_APP + 0xC ) ; func = * ( uint32_t volatile * )((( uint32_t ) func ) + 0x4 ) ; func = (((( uint32_t ) func ) & 0xFFFFFFFF U )) ; // Reset_Handler+1 --> required to avoid hard fault After resetting and jumping , will there be any residual data from the previous program? Is it necessary to clean up the RAM? If so , how? Thank you . 回复: boot使用C40擦写flash Hi@ LJH1 Please provide me with a simple demo that can reproduce the problem so I can reproduce your issue. I don't need your complete product project or scattered driver files. 回复: boot使用C40擦写flash RTD Company uses version 4.0.0 as standard. 回复: boot使用C40擦写flash Subsequent testing revealed that C40 writes were intermittently successful. The `status = C40_Ip_MainInterfaceWriteStatus(); ` command returned a value of 2. ErrorFlags = C40_Ip_pFlashBaseAddress -> MCRS & ( FLASH_MCRS_PEG_MASK | FLASH_MCRS_PEP_MASK | FLASH_MCRS_PES_MASK ) ; ErrorFlags eventually equals 0; returns an error. 回复: boot使用C40擦写flash Offline burning of two programs allows for faster reproduction: the first boot directly jumps to the app, the app flashes for 30 seconds to enter boot, the erase/write cycle flashes for 1 second, a total of 300 times. If there are no problems, it resets; if there are problems, it stays on or off.
記事全体を表示
How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? I am using the eIQ Toolkit to train an image classification model with a dataset of approximately 6,000 images. My target is to generate a TensorFlow Lite (TFLite) model that is smaller than 800 KB so that it can run on the MCXN947. My current training configuration is: Model: MobileNetV2 Alpha: 0.35 Pruning: Enabled Output format: TFLite The issue is that the training process takes nearly 24 hours to complete. I would like to know if there are any recommended settings or optimizations that can reduce the training time to around 1–2 hours while still keeping the final model size below 800 KB. Has anyone faced a similar situation? Are there any best practices in the eIQ Toolkit for reducing training time without significantly affecting model accuracy or increasing the model size? Any suggestions would be greatly appreciated. Thank you! FRDM-Training MCXN Re: How to Reduce eIQ Toolkit Training Time for a 6,000-Image Dataset? Hi @sivamankomb  A 24-hour run for ~6,000 images is not expected for a small MobileNetV2-alpha-0.35 transfer-learning job unless training is running on CPU, using a large input size, too many epochs, heavy dynamic augmentation, or doing pruning/QAT throughout the full training run. I think you can refer to the following. Verify CUDA + cuDNN are installed and being used. Use the smallest input resolution that still gives acceptable accuracy; if you are at 224×224, try 128×128 first. Start with a low epoch limit plus early stopping, not a fixed long training run. Disable pruning for the initial training run; Use INT8 TFLite quantization for deployment; Avoid QAT in the first speed-optimized run; Start with “No Augments,”  You can refer to eIQ Toolkit User Guide for specific content BR Harry
記事全体を表示
Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage Hello NXP Team, I am bringing up a custom board based on the i.MX9596 processor with LPDDR5 memory using the i.MX OEI bootloader. I generated the DDR configuration for my custom board using MCUXpresso Config Tools version 26.3. The generated files are: lpddr5_timing.c lpddr5_config.ds peripherals.c peripherals.h pin_mux.c pin_mux.h In the OEI source under boards/mx95lp5/ddr, I found these files: MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_ECC_enabled_timing.c XIMX95LPD5EVK19_6400mbps_train_timing_a1.c I would like to confirm the correct integration procedure for a custom LPDDR5 board. Should the generated lpddr5_timing.c be used in place of MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c, with OEI_DDR_CONFIG updated to reference the new timing file? Is XIMX95LPD5EVK19_6400mbps_train_timing_a1.c a silicon-specific training file provided by NXP that should remain unchanged for a custom board? OEI uses the following DDR PHY firmware binaries: lpddr5_imem_v202409.bin lpddr5_dmem_v202409.bin lpddr5_imem_qb_v202409.bin lpddr5_dmem_qb_v202409.bin Can these same firmware binaries be reused on a custom LPDDR5 board as long as the firmware version matches the generated DDR timing configuration? Is the ECC-enabled timing file required only when LPDDR5 ECC is enabled? If ECC is not used on the custom board, is the normal timing file sufficient? Please let me know if any additional files need to be regenerated or modified when migrating from the EVK DDR configuration to a custom LPDDR5 board. Thank you. Re: Clarification on Integrating Custom LPDDR5 Timing into i.MX95 OEI and DDR PHY Firmware Usage Hello, 1. Yes, you need to replace the MIMX95_LPDDR5_EVK_19X19_6400MTS_FW2024.09_timing.c with your custom configuration. 2. That is a different configuration for that specific silicon revision, it can be used as a reference if is your case. If you are not using this configuration, you can leave it untouched. 3. Yes, those binaries can be reused for similar configurations and normal timing file sufficient if you are not using ECC. Best regards.
記事全体を表示
How to Integrate a C++ TFLite Model into a C-Based MCUXpresso Project? Hello NXP Team, I am integrating a TensorFlow Lite Micro model into my MCUXpresso project for the MCXN947. My application is written in C, while the TensorFlow Lite Micro inference code and generated model are in C++. I am encountering compilation and linking issues when combining the C and C++ source files. I have already tried using "extern C", but the issue remains. Could you please advise on the following? Is it recommended to mix C and C++ source files in an MCUXpresso project? What is the recommended approach for integrating a C++ TensorFlow Lite Micro model into a C-based application? Are there any required compiler/linker settings or reference examples for this integration? Any guidance would be greatly appreciated. Thank you. Development Board MCXN Re: How to Integrate a C++ TFLite Model into a C-Based MCUXpresso Project? Hello @sivamankomb , Thanks for your post. Of course you can mix C and C++ source files in an MCUXpresso project. In fact, this is also the approach used in our SDK demos. For reference, you can review several eIQ-related example projects included in the SDK. The SDK is available for download from Select Board | MCUXpresso SDK Builder. The key points are as follows: - .c files are compiled as C code. - .cpp files are compiled as C++ code. - The final linking stage must use a toolchain that supports the C++ runtime and C++ symbol resolution. - C code should only call functions exposed through extern "C" wrappers and should not directly include or use TFLM C++ classes, templates, or namespaces. Therefore, the recommended approach is to encapsulate the TFLM inference implementation in a .cpp file and expose only a C ABI-compatible wrapper interface to the C application. For example, in the SDK's tflm_label_image demo, the core TFLM inference logic is implemented in common/tflm/model.cpp. This file uses the TFLM C++ APIs, such as #include "tensorflow/lite/micro/micro_interpreter.h" #include "tensorflow/lite/micro/micro_op_resolver.h" static const tflite::Model* s_model = nullptr; static tflite::MicroInterpreter* s_interpreter = nullptr; extern tflite::MicroOpResolver &MODEL_GetOpsResolver(); Then creating a tflite::MicroInterpreter instance and calling AllocateTensors() within MODEL_Init() to perform initialization. The externally exposed model.h,  provides a C-friendly interface. #if defined(__cplusplus) extern "C" { #endif status_t MODEL_Init(void); uint8_t* MODEL_GetInputTensorData(tensor_dims_t* dims, tensor_type_t* type); uint8_t* MODEL_GetOutputTensorData(tensor_dims_t* dims, tensor_type_t* type); void MODEL_ConvertInput(uint8_t* data, tensor_dims_t* dims, tensor_type_t type); status_t MODEL_RunInference(void); const char* MODEL_GetModelName(void); #if defined(__cplusplus) } #endif The function declarations are exported through extern "C", allowing C source files to simply #include "model.h" and call functions such as MODEL_Init() and MODEL_RunInference() without needing any knowledge of C++ types like tflite::MicroInterpreter or MicroMutableOpResolver. This architecture is also the approach adopted by our SDK examples and is generally recommended when integrating TFLM into a C-based application, as it cleanly isolates the C++ implementation details while preserving a pure C interface for the application layer. If you want to integrate customer ML model to SDK demo, you can refer to AN14241 . Hope it helps. BR Celeste
記事全体を表示