Multi Source Translation Content

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

Multi Source Translation Content

ディスカッション

ソート順:
SJA1110 的连接问题 尊敬的恩智浦半导体成员们: 此工单可能与以下主题相关: SJA-1110-Qbv配置 SJA1110-Qbv-AdminBaseTime-Configuration 在配置 S32G-VNP-RDB3 板上的 SJA1110 交换机的 Qbv 时,我一直使用 NXP 的 S32G SJA1110 SDK 来设置 gPTP/Qbv 参数,编译新的sja1110_uc.bin文件,并将其部署到 A-core Linux 电路板支持包 的固件文件夹中。 最初,我使用 PFE0 接口(SJA1110 交换机端口 4)作为 gPTP 主服务器,并将 ADMINBASETIME 设置为 0。我进行了一些测试和验证,一切迹象都表明它的行为符合预期。 然而,在项目进行过程中,我不得不重新分配角色,以便现在 gPTP 主控节点将来自连接到端口 3 的外部设备。 从我连接这个外部设备的那一刻起,Qbv 的性能就会变得非常不稳定。 我进行了一些测试,例如从较大的循环值开始: Cycle = 1 sec -> 125000000 CycleExt (12.5%) = 15625000 segment 1 = 0.25 sec TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 0.25 sec TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 0.25 sec TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 0.25 sec TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 1250000 (2x625000) port 4: TRIGGER_TIME = 3125000 (4x781250) ports 5...: TRIGGER_TIME = 125000 为了进行测试,我从客户端(S32G PFE0 接口)向连接在同一网络上的另一个 Linux 设备(作为服务器)发送 UDP 数据包。 我在服务器端使用 tcpdump 工具捕获数据包,并分析结果。 在这种情况下,传输会在几秒钟后开始,但一旦开始,它就会正常工作(1 秒周期,给定流量优先级的 25%): 然后,我将 GATESTATUS 分成四个段,但将周期时间缩短至 200 毫秒: Cycle = 200ms -> 25000000 CycleExt = 3125000 segment 1 = 50 ms TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 50 ms TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 50 ms TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 50 ms TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 250000 port 4: TRIGGER_TIME = 625000 ports 5...: TRIGGER_TIME = 25000 这样做是可行的,但我需要等待 30 秒到 2 分钟才能开始传输数据包。   在随后的测试中,我观察到了同样的模式: 当循环时间缩短至 100 毫秒时,我需要等待 2 到 4 分钟才能开始传输; 当循环时间缩短到 50 毫秒时,我需要等待 5 到 6 分钟才能开始传输。 等等。因此,周期长度越短,Qbv 实际开始前的等待时间就越长。在此之前,交通一直处于阻塞状态。 但是,当我进行以下配置时,观察到了另一种奇怪的现象: Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 2 = 300 μsec TC 6: GATESTATUS 4 segment 3 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 在这种情况下,除了TC6之外,所有交通流量都将通过。 当我反转配置时: Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TC 6: GATESTATUS 4 segment 2 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 3 = 300 μsec TC 6: GATESTATUS 4 在这种情况下,只有 TC6 的流量会被传输,而其他 TC 的流量将被阻止。 我认为,这指向了时间同步问题。 以下是我在S32DS上配置gPTP的方法:     值得一提的是,这个外部 gPTP 主服务器提供的同步时间戳基于当前的 Unix 纪元:   当 PFE0 用作主控时,它会提供从 0 开始的同步时间戳:   这种行为该如何解释? 感谢您的支持! 顺祝商祺! 吉列尔梅 Re: Connectivity issue in SJA1110 你好@GuilhermeS32G , 是的,请稍候,您将获得访问权限。除了保密协议外,汽车以太网还属于出口管制政策的范畴。 我认为,ECT 工具是交换机动态重配置相关代码的绝佳来源。 是的,将 Unix epoch gPTP时间戳拆分为 ADMINBASETIME[0:31] 和 ADMINBASETIME[32:63] 是正确的方法。 顺祝商祺! 帕维尔 Re: Connectivity issue in SJA1110 嗨@PavelL , 感谢您的反馈, 确实,这种ECT工具似乎是正确的选择。 但是,我仍然无法下载它。上面写着:“SJA11XX 标准软件 - 您的申请表已收到”。我可能需要等待一段时间才能获得访问权限。 同时,为了更清楚地说明,我们假设当前的 Unix 时间戳(精确到纳秒)是: 1784013205012345678 这在世界协调时 (UTC) 代表: 2026年7月14日星期二上午7:13:25 如何正确地将此时间戳拆分为 ADMINBASETIME[0:31] 和 ADMINBASETIME[32:63]? 顺祝商祺! 吉列尔梅 Re: Connectivity issue in SJA1110 你好@GuilhermeS32G , 感谢您创建后续讨论帖——这有助于我们了解案件的最新进展。 感谢您一次性分享所有细节和测试结果。 我已检查所提供的数据,您的 gPTP 配置似乎是正确的。   根据您的观察,该行为强烈表明问题与 Qbv 调度激活时间有关,而非门控列表条目本身。如果外部 gPTP 主时钟提供基于纪元的 PTP 时间值,而 ADMINBASETIME 配置为 0,则 ADMINBASETIME = 0 相对于当前同步的 gPTP 时域而言非常遥远,交换机需要基于该值解析 Qbv 更改/启动时间。与 PTP 时间接近零的设置相比,这可能会导致意外的调度激活行为。因此,将 ADMINBASETIME 设置为当前同步的 PTP 时域中的未来值更为安全。   因此,对于此用例,我建议根据当前同步的 PTP/gPTP 时间动态配置 ADMINBASETIME(并在静态配置中仍然使用固定值 0)。 典型的序列如下: 1. 启动 gPTP 并等待交换机与外部主控交换机同步。 2. 从交换机读取当前的 PTP 时钟。 3. 将 ADMINBASETIME 设置为未来的时间值,例如当前 PTP 时间 + 足够的安全裕度。 4. 编写 TAS/Qbv 管理参数。 5. 触发 TAS/Qbv 配置更改。 您可以参考 ECT 服务器的实现。特别是请查看udp_traffic.c文件中的 udpReceiveCallback() 函数。无论您使用的是 ECT 服务器的 SDK 版本还是 RTD 版本,都无关紧要。 在 TAS 配置处理中,ECT 服务器(SDK 版本)使用 SWITCH_DRV_GetPtpClk() 读取当前 PTP 时间,将此值赋给 TAS 基准时间,加上 2 秒的裕量,然后调用 SWITCH_DRV_WriteTasAdminParameters(),再调用 SWITCH_DRV_ChangeTasConfig()。   这种方法避免使用 ADMINBASETIME = 0,并将 Qbv 调度激活与实际同步的 PTP 时间域对齐。 顺祝商祺! 帕维尔
記事全体を表示
Zephyr 中对 i.MX95 FRDM EVK 的 HDMI 配置支持 您好,NXP团队: 我目前正在使用 Zephyr RTOS 在i.MX95 FRDM EVK板上进行开发。 Linux 系统方面,HDMI 输出已经得到支持,并且运行正常。但是,我想知道如何在 Zephyr 中启用和配置 HDMI。 请问您能否指导我完成以下事项? Zephyr 是否支持 i.MX95 FRDM EVK 的 HDMI 输出? 如果需要,需要哪些驱动程序和设备树配置? Zephyr 上是否有 HDMI 的参考实现或示例应用程序? 任何指导或文件都将不胜感激。 谢谢!
記事全体を表示
How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi,  We use MIMXRT1062DVL6B and realize our product with ethernet. First, we implement the MAC address for our product using `SILICONID_ConvertToMacAddr` on `fsl_silicon_id.c` to get unique MAC address per device with NXP's OUI and silicon ID. But the MAC address we got via `SILICONID_ConvertToMacAddr` was not unique, and they were all identical. So, I have a question. Do we have any setting before calling `SILICONID_ConvertToMacAddr`? Or, `SILICONID_ConvertToMacAddr` does not work to get unique MAC address over the NXP device? We couldn't find answer in IMXRT1060RM.pdf of Rev. 4, 01/2026. Could you give us the answer? thank you. Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi, Abner Thank you for your supporting,  We understood that we can use MAC address got via SILICONID_ConvertToMacAddr for our product. But I understand SILICONID_ConvertToMacAddr is just an example and we can't use it for our mass product. And we have to use the MAC address under our OUI. Best regards. Shigeru Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi @shigeru-tsujita  Thanks to find this situation. SILICONID_ConvertToMacAddr is used for NXP MCUX SDK example to reduce MAC address conflict in our test environment. We connect to different Socs' eth in same switch. For this same series Soc situation, we may not cover. But what I'm confused is why you use this way to generate your product MAC address. First of all, your OUI should use your company's one. Then the unique ID I think your company should have a internal special definition. Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi, May. I understand SILICONID_ConvertToMacAddr make MAC address using fixed NXP OUI and three bytes of silicon ID(it's part of OCOTP->CFG0/1). I observed the OCOTP->CFG0/1 of our target product. Those values are following: - one MIMXRT1062   - OCOTP->CFG0: (uint32_t)0x615c'faa4   - OCOTP->CFG1: (uint32_t)0x2a1e'61d7 - other MIMXRT1062   - OCOTP->CFG0: (uint32_t)0x615c'faa4   - OCOTP->CFG1: (uint32_t)0x4922'61d7 Because lower three bytes of OCOTP->CFG0 is used for MAC address in SILICONID_ConvertToMacAddr, they have similar MAC address. So, many of our product have similar MAC address. (Now we have handreds of prototype and we don't check all MAC address, but we couldn't find differnt MAC address with 54:27:8D:A4:FA:5C yet.) thank you. Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi @shigeru-tsujita, Thank you so much for your interest in our products and for using our community. Assuming the SDK silicon_id component is correctly integrated, no additional setting is required before calling SILICONID_ConvertToMacAddr() for MIMXRT1062. Please note that SILICONID_ConvertToMacAddr() does not use the full 64-bit silicon ID to generate the MAC address. It uses a fixed NXP OUI for the first 3 bytes and only 3 bytes from the silicon ID for the last 3 bytes. According to the SDK code: Could you please read the 64-bit silicon unique ID from several devices and check whether the ID values are read correctly? Please also compare siliconId[0] , siliconId[1] , and siliconId[2] , as these are the bytes used to generate the MAC address. If these three bytes are identical across devices, the generated MAC addresses will also be identical. Best Regards May
記事全体を表示
Yoctoのリリーノーズビルド失敗 imx-car-navigation こんにちは、 最新の6.18.20-2.0.0 BSP上でFRDM-IMX93用の「imx-image-full」をビルドしようとすると、次のように失敗します。 ERROR: imx-car-navigation-1.0-r0 do_compile: Execution of '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/temp/run.do_compile.1753043' failed with exit code 1 ERROR: Logfile of failure stored in: /media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/temp/log.do_compile.1753043 Log data follows: | DEBUG: Executing shell function do_compile | Cloning into '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode'... | fatal: unable to access 'https://github.com/CANopenNode/CANopenNode.git/': Could not resolve host: github.com | fatal: clone of 'https://github.com/CANopenNode/CANopenNode.git' into submodule path '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode' failed | Failed to clone 'CANopenNode'. Retry scheduled | Cloning into '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode'... | fatal: unable to access 'https://github.com/CANopenNode/CANopenNode.git/': Could not resolve host: github.com | fatal: clone of 'https://github.com/CANopenNode/CANopenNode.git' into submodule path '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode' failed | Failed to clone 'CANopenNode' a second time, aborting | WARNING: exit code 1 from a shell command. ERROR: Task (/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb:do_compile) failed with exit code '1' これは100%再現可能であり、必ずここで失敗します。また、bitbakeが「コンパイル」ステップを実行しているにもかかわらず、リポジトリのダウンロードが失敗する点にもご注意ください。現状では、コンパイルの段階でダウンロードを行うべきではないことと、Bitbakeがネットワーク機能をダウンロード段階に限定していることが関係しているのではないかと考えています。最近このレシピを試した人はいますか? Re: Yocto wrynose build failure for 'imx-car-navigation' 私の直感は正しかったようだ。以下のパッチを適用することで、私の場合は問題が解決しました。 --- sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb.ORIG 2026-07-13 16:02:28.733344421 +0200 +++ sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb 2026-07-13 16:02:11.178539144 +0200 @@ -14,6 +14,7 @@ do_configure[noexec] = "1" +do_compile[network] = "1" do_compile() { cd ${S} ただし、これはあくまで一時的な回避策であることに注意してください。これがデフォルトで許可されていない理由があります。コンパイルステップはネットワークアクセスを行わないはずです。
記事全体を表示
当请求 HMAC 验证作业时,HSE 返回“HSE_SRV_RSP_INVALID_PARAM” 您好,NXP团队, 我有一个使用 HMAC 验证作业的用例。触发作业加密驱动程序后抛出 DET,HSE 的响应为“HSE_SRV_RSP_INVALID_PARAM”。 我无法理解我当前的配置出了什么问题。请查收附件中的配置文件压缩包。 需要技术支持来解决问题。 谢谢! 阿迪亚 Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job 嗨@lukaszadrapa , 细节: 设备:S32K311 HSE固件:HSE_FW_S32K311_0_2_55_0 RTD:SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 谢谢! 阿迪亚 Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job 嗨@WagdeoA 请问您能否确认一下您使用的是哪款设备、哪款RTD以及哪款HSE固件版本? 此致, Lukas
記事全体を表示
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
記事全体を表示
新建项目向导失败:未自动添加 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
記事全体を表示
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
記事全体を表示
如何为我们使用的 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
記事全体を表示
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)を調べ、どの特定のチャネルがエラーを引き起こしたかを特定しなければなりません。 よろしくお願いいたします。 シェリー・チャン
記事全体を表示
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
記事全体を表示