PowerPC support for Wrynose SDK Hi, We are looking to migrate our T4240rdb based board from Dunfell to Wrynose Yocto SDK. Are PowerPC boards supported in Wrynose SDK ? If not what are our options to get support for PowerPC boards. Thanks, Subbarao Nalajala Senior Engineer at Thales Group Re: PowerPC support for Wrynose SDK Hello, PowerPC/T4240RDB boards are NOT supported in the NXP Wrynose Yocto SDK. This is a well-established limitation that applies to all newer NXP Yocto releases beyond Dunfell. Why PowerPC is Not Supported in Wrynose NXP's Wrynose SDK (Yocto 6.0) is exclusively targeted at ARM-based i.MX and Layerscape processors. The QorIQ T-Series (including T4240) uses the Power Architecture (e6500 core), which has not been carried forward into the newer Yocto SDK releases. This is consistent with NXP's broader strategy: "QorIQ SDK is a fully featured and mature Yocto-based software kit for QorIQ PowerPC-based P-series and T-series family of processors... Layerscape SDK is the hybrid Ubuntu-based software kit for the Layerscape family of processors, and going forward will be the primary delivery mechanism for the most up-to-date software on Layerscape platforms." The last officially NXP-supported Yocto release for T4240RDB is Dunfell (Yocto 3.1). Newer Yocto releases (Scarthgap, Wrynose, etc.) do not include T4240RDB or other PowerPC T-Series boards. A known build error also confirms this at the glibc level — attempting to build for the e6500 PowerPC64 architecture in post-Dunfell Yocto results in: configure: error: The e6500 subspecies of powerpc64 is not supported. Your Options Option 1: Stay on Dunfell (Recommended for T4240RDB) The Dunfell branch of the QorIQ Yocto SDK remains the latest officially supported Yocto release for the T4240RDB. You can access it at:  https://github.com/nxp-qoriq/yocto-sdk/tree/dunfell This is the path NXP recommends for PowerPC T-Series customers who need a stable, supported Yocto environment. Option 2: Use Community/Upstream Sources NXP's official guidance for Power Architecture P-Series and T-Series customers is to leverage upstream community sources for newer kernel and U-Boot versions: "Going forward, we encourage customers using Power Architecture-based P-series and T-series platforms to get the enablement software directly from the community sources like kernel.org and denx.de (uboot)." This means you can build a newer kernel (e.g., 5.x or 6.x) for T4240RDB using mainline sources, but this requires manual integration work and is not a turnkey NXP-supported SDK. Option 3: Migrate to an ARM-Based Layerscape Platform If a newer Yocto SDK (including Wrynose) is a hard requirement, the only path is to migrate the hardware platform to an ARM-based Layerscape processor (e.g., LX2160A, LS1046A, LS1088A), which are fully supported in Wrynose and future NXP Yocto releases. This is a significant hardware redesign effort but aligns with NXP's long-term roadmap. Option 4: NXP Professional/Premium Support If you need custom BSP work or a porting effort for T4240RDB on a newer Yocto baseline, NXP offers Professional Support for Processors and Microcontrollers, which includes Linux/Yocto recipe assistance and direct access to NXP engineers.   regards

i.MX RT1064 - PEmicro 连接助手错误和启动配置意外更改 您好， 我正在使用i.MX RT1064控制器，并通过 MCUXpresso IDE 中的PEmicro Multilink接口进行调试/烧录。 有时，我在尝试连接目标设备时会遇到附件中的“PEmicro 连接助手”错误。这个问题似乎是随机发生的；我还没有发现任何特定的软件活动、代码更改或硬件事件会持续触发信号它。 我观察到，当出现此错误时，控制器的启动配置似乎发生了意外变化。在这种状态下，我无法对设备进行刷机或调试。我目前唯一能恢复的方法是将启动配置恢复到其原始设置——内部闪存模式，之后刷写和调试功能就能再次正常工作了。 一些补充细节： MCU：i.MX RT1064 调试探针：PEmicro 多链路通用 Rev E IDE：MCUXpresso IDE 有人遇到过类似的问题吗？ 我希望您能就以下方面提供指导： 什么原因会导致启动配置意外更改？ 是否存在调试器或应用程序代码可能影响启动配置的已知场景。 防止这种情况发生的建议方法。 能否在不手动更改的情况下通过软件更改启动配置 我附上了错误信息的截图供您参考。 谢谢！ i.MX RT106x Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 你好， 您能帮我解答以下问题吗？ 你用的是定制主板还是EVK主板？ 您使用的是哪个版本的SDK和IDE？ 你烧断过熔丝吗？ 您提到需要将启动配置恢复到内部闪存模式——您目前使用的是哪种启动配置？ 此致， 巴勃罗 Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 我使用的是定制电路板，但这个问题在 EVK 上也出现过。 SDK 版本：26.03.00 IDE 版本：25.6.136 我们没有烧断熔丝。 我们通常使用内部启动模式来烧录代码并进行正常操作，但它会随机导致一些意想不到的问题，所以我们将其更改为串行下载模式，擦除闪存，然后再将其改回内部启动模式，之后再次烧录代码。 请查看附件图片以获取启动配置信息。 Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 你好@Subhasri_S ， 通过在 POR_B 的上升沿对 BOOT_MODE0 和 BOOT_MODE1 输入进行采样来初始化 BOOT_MODE 寄存器。对这些输入进行采样后，它们的后续状态不会影响内部 BOOT_MODE 寄存器的内容。 如果 BT_FUSE_SEL = 0，则可以使用 GPIO 引脚而不是 eFuse 来设置特定的启动配置参数。 能否请您在问题出现时，在 RESET 过程中测量一下 BOOT_MODE 和 BT_CFG 引脚的值？ 关于此问题的另一种可能结论，请参阅以下知识库文章： 知识库： RT板恢复调试器连接问题 “当闪存中包含异常应用程序（访问内存不存在、内存损坏、时钟配置错误等）时，会导致板处于未知状态，此时调试器无法控制内核。但是，当将核心置于串行下载器模式时，它将使核心处于已知状态，这样，调试器就可以控制核心。 因此，当RT板出现调试器问题时，尝试在串行下载模式下批量擦除外部闪存，这样就能使板载调试器恢复正常状态。 此致， 巴勃罗 Re: i.MX RT1064 - PEmicro Connection Assistant Error and Boot Configuration Changing Unexpectedly 您好，请提供问题发生时记录的 BOOT_MODE 和 BOOT_CFG 引脚值。

Wrynose SDK 对 PowerPC 的支持 您好， 我们正在考虑将基于 T4240rdb 的开发板从 Dunfell 迁移到 Wrynose Yocto SDK。Wrynose SDK 是否支持 PowerPC 板？ 如果以上方法都不行，我们还有哪些途径可以获得对PowerPC主板的支持？ 谢谢！ 苏巴拉奥·纳拉贾拉 泰雷兹集团高级工程师 Re: PowerPC support for Wrynose SDK 你好， NXP Wrynose Yocto SDK 不支持 PowerPC/T4240RDB 板。这是所有较新的 NXP Yocto 版本（Dunfell 之后）都存在的既定限制。 为什么 Wrynose 不支持 PowerPC？ NXP 的 Wrynose SDK（Yocto 6.0）专门针对基于 ARM 的 i.MX 和 Layerscape 处理器。QorIQ T 系列（包括 T4240）采用Power 架构（e6500 内核） ，但该架构并未延续到较新的 Yocto SDK 版本中。这与恩智浦的整体战略是一致的： “QorIQ SDK 是一款功能齐全、成熟的基于 Yocto 的软件工具包，适用于 QorIQ 基于 PowerPC 的 P 系列和 T 系列处理器……Layerscape SDK 是一款基于 Ubuntu 的混合型软件工具包，适用于 Layerscape 系列处理器，未来将成为 Layerscape 平台上最新软件的主要交付机制。” NXP 官方支持的最后一个适用于 T4240RDB 的 Yocto 版本是 Dunfell（Yocto 3.1） 。较新的 Yocto 版本（Scarthgap、Wrynose 等）不包含 T4240RDB 或其他 PowerPC T 系列板。 一个已知的版本错误也证实了这一点，该错误发生在 glibc 层——尝试在 Dunfell 事件后的 Yocto 中为 e6500 PowerPC64 架构进行版本会导致以下结果： configure: error: The e6500 subspecies of powerpc64 is not supported. 您的选择 方案一：留在邓费尔（推荐给 T4240RDB 用户） QorIQ Yocto SDK 的 Dunfell 分支仍然是 T4240RDB 最新官方支持的 Yocto 版本。您可以通过以下方式访问： https://github.com/nxp-qoriq/yocto-sdk/tree/dunfell 这是 NXP 推荐给需要稳定、受支持的 Yocto 环境的 PowerPC T 系列客户的路径。 方案二：使用社区/上游资源 NXP 针对 Power Architecture P 系列和 T 系列客户的官方建议是，利用上游社区资源获取更新的内核和 U-Boot 版本： “今后，我们鼓励使用基于 Power Architecture 的 P 系列和 T 系列平台的客户直接从 kernel.org 和 denx.de (uboot) 等社区资源获取启用软件。” 这意味着您可以使用主线源代码为 T4240RDB 构建更新的内核（例如 5.x 或 6.x），但这需要手动集成工作，并且不是 NXP 支持的交钥匙 SDK。 方案三：迁移到基于 ARM 的 Layerscape 平台 如果必须使用较新的 Yocto SDK（包括 Wrynose），则唯一的途径是将硬件平台迁移到基于 ARM 的 Layerscape 处理器（例如 LX2160A、LS1046A、LS1088A），这些处理器在 Wrynose 和未来的 NXP Yocto 版本中都得到完全支持。这是一项意义重大的硬件重新设计工作，但符合恩智浦的长期发展路线图。 选项 4：NXP 专业/高级支持 如果您需要定制 BSP 工作或将 T4240RDB 移植到更新的 Yocto 基线，NXP 可提供处理器和微控制器的专业支持，包括 Linux/Yocto 配方协助和直接联系 NXP 工程师。   此致问候

i.MX95 Neutron：四分之一的相同 INT4 LLM 测试结果存在 NPU/CPU 差异 摘要 我们在 i.MX95 上运行一个量化的 ONNX，一次在 CPUExecutionProvider 下，一次在 CPUExecutionProvider 下。 NeutronExecutionProvider。两条臂给出的答案并不一致：在 2,466 对配对样本中 多项选择题中，25.7% 的答案与实际答案不同（MMLU 中为 43.6%）。免费 同样的情况也会发生——在 MMLU 提示符下，19 代中有 13 代产生了 不同的答复信。 这不是措辞上的区别。这是模型给出的答案不同的问题。与此同时，综合基准准确率仅下降了 1.8 个百分点。 我们想了解 Neutron 运行时在数值上做了哪些工作，从而产生这些结果。 这一点，以及这种程度的规模是否在预期之内。 设置 请确认您那边可以复现：模型来自 UG10166 表 2，量化方式为： 你自己的配方，未经修改。 - 主板：i.MX95 19x19 EVK (IMX95LPD5EVK-19)，LPDDR5 - BSP：LF6.18.2_1.0.0，设备树 imx95-19x19-evk-neutron.dtb - 运行时：来自 BSP 的 ONNX Runtime 1.22.0 + NeutronExecutionProvider - 中子变流器：3.1.3 - 型号：meta-llama/Llama-3.2-1B-Instruct - 量化：NXP/eiq-olive rev aae820e， examples/Llama3/llama3_2-1B_Spinquant_RTN_ONNX_4bits.json - 转换：convert_ort_models_to_neutron.py，应用于 CPU arm 的 model.onnx - 环境：NEUTRON_CMA_512SLOTS=6 两条臂均源自同一个量化模型。The NPU Arm is that model passed through convert_ort_models_to_neutron.py。我们记录源图的 安全散列算法 (SHA)-256 值， 外部砝码——在转换时使用，并在每次测量前重新验证，因此 没有第二次量化运行，也没有第二次导出。 我们观察到的 1.每四件物品中就有一件会得到不同的答案。 来自 MMLU、ARC-Challenge 和 PIQA 的 2,466 个配对项目，零次测试，采用对数似然法评分 候选延续 - 每个候选者向前推进一次，不进行生成，不进行抽样。 对于每个基准，首先计算答案发生变化的项目的比例，然后计算答案发生变化的项目的比例。 正确性已改变： - MMLU（4 个选项）：43.6% 的答案发生了改变，27.1% 的正确性发生了改变。 - ARC挑战（4个选项）：21.3%的答案被修改，13.3%的正确性被修改。 - PIQA（2个选项）：9.4%的答案被更改，9.4%的正确性被更改。 总计：答案更改率为 25.7%，正确率更改率为 17.3%。 这两个数字之所以不同，是因为三分之一的变化（634 处变化中的 208 处）是从一个错误值转移到另一个错误值。 对另一个错误答案的回应——一种真正能带来准确性的行为改变 未受影响。由于PIQA是二进制的，因此不存在这种盲点，它的两个数值完全一致。 确切地。 2. 自由生成中也会发生同样的情况——答案本身会发生变化。 50 个提示，贪婪解码，64 个令牌。对于 MMLU 提示符，预期输出开始 连同答题信一起，就可以直接从生成过程中读取答案。 （n = 19）： - 两臂答案字母不同：19 封信中有 13 封不同 - CPU 正确率：7/19 - 正确答案：19题中的6题 - 双方都犯错且错误答案不同的分歧：13 例中有 6 例 三分之二的答案发生了变化，但得分基本相同（7 分对 6 分）。 样本量很小——我们仅将其作为示例进行报告；以上2466项测量结果。 是定量分析。 举个例子，原话如此。提示列出了四个选项，并要求写一封信。 预期答案是 😧 CPU：“A\n解释：表达式 9(9m + 3t) 等价于 81m + 27t。 最佳答案是A。 NPU：“C\n最佳答案是C。” 两者都错了，错的点不同，而且没有基准分数会记录这一点。 3. 这种分歧在第一个正向传播中就存在，而不是逐渐积累的。 在这种信件格式中，第一个生成的令牌就是答案，并且有 60% 的生成结果都是如此。 两者之间已经存在差异——这是仅由预填充过程生成的令牌，尚未经过任何解码。 步。在所有 50 个提示中，分歧曲线先急剧上升，然后趋于平缓：84% 令牌 4，98% 到令牌 64。这就是初始差异传播的样子 在贪婪解码模式下，不会通过 KV 缓存累积错误。 4. 总体准确率掩盖了所有这些问题。 CPU 使用率为 50.28%，而 Neutron 使用率为 48.50%，相差 1.78 个百分点，且没有其他问题。 三个基准指标各自都具有重要意义。仅限于以下 634 项： 双方意见不一致，CPU 的正确率是 37.1%，而 Neutron 的正确率是 30.1%——235 对 在已决定的项目中，有 191 个，即 55/45，而对称噪声会给出 50/50。 我们排除了哪些选项 - 静默 CPU 回退：ORT 分析报告显示 80/80 个 MatMulNBits 处于开启状态 NeutronExecutionProvider，CPU 占用率为 0。不进行局部植入。 - 两种不同的模型：相同的源文件，图的 安全散列算法 (SHA)-256 值和外部权重 转换时记录，并在得分前重新核实。 - 采样：全程贪婪解码；无温度、无 top-k、无 top-p。 - 不同的输入：两个 Arm 都从同一个物品文件中按相同的顺序读取数据。 相同的固定种子。 - 评分指标：板 仅 捕获 每个标记的对数概率；所有决策 逻辑在主机上离线运行，两个 Arm 的逻辑完全相同。 - NPU 上的运行间噪声：在同一 Neutron 会话中重复播放相同的项目 产生比特相同的对数概率。NPU Arm是可重复的；差异 这是针对CPU的，而不是针对CPU本身的。 我们的问题是 这是 Neutron-S 上 INT4 路径的预期行为吗？如果是，我们应该怎么做？ 验证在 NPU 上部署 LLM 的可行性，前提是总体基准测试准确率明显高于预期。 没有显示出来吗？ 我们并未假定存在缺陷。浮点CPU内核和 整数 NPU 路径是正常的，我们想知道您认为的量级是多少。 正常情况下，你们接受 LLM 端口到 Neutron 的标准是什么？如果 四分之一的答案发生变化在预期之内，这对我们来说是件好事。 了解并围绕其进行设计。 Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM 谢谢你的快速回复！ DS Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM 嗨@DamienSCHNEBELEN IMX95 NPU 只能运行矩阵乘法运算，其 LLM 性能在 NPU 上实际上只是中等水平。因此，您观察到的现象在可预测的范围内，我们不建议在 NPU 上运行 LLM 模型。 B.R

Audifortレビュー：本当に一晩で耳鳴りを止めることができるのか？ Audifortレビュー：本当に一晩で耳鳴りを止めることができるのか？ 毎日耳鳴り、ブンブン、カチカチという音に悩まされているなら、救いを求める過程がどれほど必死になるかをご存知でしょう。オンラインで解決策を探していると、次のような液体栄養剤の積極的な広告を目にするかもしれません。 オーディフォート それは、即効性がある、あるいは一晩で耳鳴りが解消されるといったことを示唆するものです。 簡潔に言うと、答えはノーです。Audifortは耳鳴りを一夜にして止めるものではありません。 経口サプリメントや天然の点滴薬では、慢性的な耳鳴りを即座に治したり、損傷した聴神経を24時間以内に再生したりすることはできません。 しかし、だからといってその公式が無意味だというわけではない。奇跡の治療薬ではなく、天然の栄養補助食品として現実的に評価すると、オーディフォートは内耳の血管を栄養し、過剰に活動している神経信号を時間をかけて鎮めるのに役立つ栄養素を提供します。 この Audifortのレビューでは、販売促進のためのマーケティングにとらわれず、このドロップが実際にどのように作用するのか、その主要成分、現実的な効果発現までの期間、潜在的な副作用、そして偽のオンライン広告を回避する方法などを分析します。

88W8887 射频合规性测试 亲爱的， 我们使用的是基于 88W8887 芯片组的 wifi/蓝牙模块。为了确保产品符合规范，我们需要进行多项射频测试（tx 连续数据包、rx 模式等）。对于另一个模块 88W8997，我们遵循了以下应用节点：AN14114。然而，该应用笔记并未提及支持88W8887。 该应用笔记使用了mwifiex驱动程序。查看代码可知，驱动程序应该支持 88W8887。遗憾的是，该驱动程序需要固件文件sd8887_wlan_a2.bin，但我们未能找到该文件。 在 88W8887 上运行 RF 测试（类似于 AN 中描述的方法）的推荐方法是什么？NXP 是否仍然支持这种使用场景？ 此致敬礼， 吉 Re: 88W8887 RF compliance testing 嗨@shaun_wu 我无法访问提供的链接。我这边需要做些什么才能获得访问权限？ 此致敬礼， 吉 Re: 88W8887 RF compliance testing 你好@YoshiDev 8887 不支持 rf_test_mode。你可以使用 mfg_mode。您可以参考以下链接： https://www.nxp.com/webapp/Download? colCode=88W8887-LABTOOL-USER-GUIDER0_1&appType=license 顺祝商祺！ 肖恩 Re: 88W8887 RF compliance testing 你好@YoshiDev 该文件属于机密文件。您可以向NDA团队提交工单以获取访问权限。 顺祝商祺！ 肖恩

88W8887 RF compliance testing Dear,  We are using a wifi/bluetooth module based on the 88W8887 chipset. For product compliance, we need to do a number of RF testing (tx continious packets, rx mode etc.). For another module 88W8997, we have followed the following application node: AN14114. However, the application note does not mention the 88W8887 as supported.  The application notes uses mwifiex driver. Looking at the code, the 88W8887 should be supported by the driver. Unfortunately, the driver requires a firmware file sd8887_wlan_a2.bin which we were not able to find.  What is the recommended way to run RF tests (similar as described in the AN) on the 88W8887? Does NXP still support this usecase? Kind regards, Yoshi  Re: 88W8887 RF compliance testing Hi @shaun_wu  I do not have access to the provided link. Anything I need to do on my side to get access? Kind regards, Yoshi Re: 88W8887 RF compliance testing Hello @YoshiDev  8887 do not support rf_test_mode. you could use mfg_mode. You could refer to following link: https://www.nxp.com/webapp/Download?colCode=88W8887-LABTOOL-USER-GUIDER0_1&appType=license Best Regards Shaun Re: 88W8887 RF compliance testing Hello @YoshiDev  The document is confidential. You could submit a ticket to NDA team get access. Best Regards Shaun

S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 Hello,  I tried running the example PIL S32CT with MBDT S32K3xx (v1.4.0) on MATLAB 2023a. My setup consists of an S32K3x4EVB-T172 connected via the onboard OpenSDA port. Attempt 1 (OpenSDA COM): I can flash the generated target model successfully, but PIL execution fails immediately with the following error: "The communication channel could not be opened" (see attached screen shot of the error message) Attempt 2 (External USB2Serial Convertor) I kept the OpenSDA port connected for flashing, but connected an external USB2Sireal  connector to J44(1 to TX and 2 to RX) for PIL communication and updated the COM port in the hardware settings. The model flashes successfully, but execution times out with this error: Error: The timeout of 10 seconds for receiving data from the rtiostream interface has been exceeded. There might be multiple reasons for this communications failure. You should: (a) Check that the target hardware configuration is correct, for example, check that the byte ordering is correct. (b) Confirm that the target application is running on the target hardware. (c) Consider the possibility of application run-time failures (e.g. divide by zero exceptions, incorrect custom code integration, etc.). Note (c): To identify possible reasons for the run-time failure, consider using SIL, which supports signal handlers and debugging. If you cannot find a solution, consider using the method setTimeoutRecvSecs of rtw.connectivity.RtIOStreamHostCommunicator to increase the timeout value.   Questions:   1. Does the S32K3x4EVB-T172 board require an external USB2Serial convertor for PIL or can it run PIL over the onboard OpenSDA port ?  2. If an external USB2Serial convertor required , what is the exact hardware UART configuration expected?  3. Am i missing any configuration ? Any guidance i highly appreciated!  Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 Hi, @PruthviB, Before investigating further, could you clarify why you are using MBDT S32K3xx v1.4.0? The latest available release is v1.8.0, which includes several fixes and improvements. We recommend upgrading to v1.8.0 first and checking whether the issue still reproduces. Regarding your setup, an external USB-to-Serial converter is not required for PIL communication on the S32K3X4EVB-T172. The onboard OpenSDA interface already provides access to the target UART used for host-target communication, so the same USB connection can be used for both programming and PIL communication. Since OpenSDA has direct access to the UART pins, connecting an additional USB-to-Serial adapter is generally unnecessary and may even introduce configuration conflicts if multiple serial interfaces are active. Could you please try the example with: MBDT S32K3xx v1.8.0 Only the onboard OpenSDA USB connection The COM port exposed by OpenSDA selected in the hardware settings Best regards, Dragos Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 Hi, @dragostoma Thank you for the guidance regarding OpenSDA onboard interface. Regarding the version, MBDT v1.4.0 was the recommended version for MBDT for BMS. Could you please provide guidance on running PIL simulations in v1.4.0 ?  Best Regards, Pruthvi Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 Hi, @PruthviB, Indeed, you are correct. The BMS Toolbox requires S32K3 Toolbox version 1.4.0. Since the initial discussion did not mention the BMS Toolbox, I assumed the issue was related to the use of an outdated S32K3 Toolbox version. Regarding the PIL simulation in version 1.4.0, the workflow remains unchanged. The example model provided with the toolbox is configured to use the LPUART instance whose RX and TX signals are routed through the OpenSDA interface. If you intend to use a dedicated USB-to-Serial converter, you will need to configure a different LPUART instance and assign the corresponding RX and TX pins to which the converter will be connected. To summarize: Using the OpenSDA interface: the example model included with the toolbox should work without any additional modifications. The required LPUART instance and associated RX/TX pins are already configured. Using a dedicated USB-to-Serial converter: the converter must be connected to specific RX and TX pins on the target device. Consequently, those pins must be configured and mapped to an available LPUART instance, which requires corresponding updates to the project configuration. Please make sure that the correct COM Port is used, and the RX and TX pins from J44 are configured when using the USB2Serial converter. Let us know how it works, Dragos

i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM SUMMARY We run one quantized ONNX on i.MX95, once under CPUExecutionProvider and once under NeutronExecutionProvider. The two arms do not give the same answers: on 2,466 paired multiple-choice items, 25.7 % receive a different answer (43.6 % on MMLU). In free generation the same thing happens - on MMLU prompts, 13 of 19 generations produce a different answer letter. This is not a difference in wording. It is a difference in what the model answers. Meanwhile aggregate benchmark accuracy moves by only -1.8 points. We would like to understand what the Neutron runtime does numerically that produces this, and whether this magnitude is expected. SETUP Reproducible on your side: the model is from UG10166 Table 2 and the quantization is your own recipe, unmodified. - Board: i.MX95 19x19 EVK (IMX95LPD5EVK-19), LPDDR5 - BSP: LF6.18.2_1.0.0, device tree imx95-19x19-evk-neutron.dtb - Runtime: ONNX Runtime 1.22.0 from the BSP + NeutronExecutionProvider - Neutron Converter: 3.1.3 - Model: meta-llama/Llama-3.2-1B-Instruct - Quantization: NXP/eiq-olive rev aae820e, examples/Llama3/llama3_2-1B_Spinquant_RTN_ONNX_4bits.json - Conversion: convert_ort_models_to_neutron.py, applied to the CPU arm's model.onnx - Environment: NEUTRON_CMA_512SLOTS=6 Both arms come from one quantized model. The NPU arm is that model passed through convert_ort_models_to_neutron.py. We record a SHA-256 of the source - graph and external weights - at conversion time and re-verify it before every measurement, so there is no second quantization run and no second export. WHAT WE OBSERVE 1. One item in four gets a different answer. 2,466 paired items from MMLU, ARC-Challenge and PIQA, 0-shot, scored by log-likelihood of the candidate continuations - one forward per candidate, no generation, no sampling. For each benchmark, the share of items whose ANSWER changed, then the share whose CORRECTNESS changed: - MMLU (4 choices): 43.6 % answer changed, 27.1 % correctness changed - ARC-Challenge (4 choices): 21.3 % answer changed, 13.3 % correctness changed - PIQA (2 choices): 9.4 % answer changed, 9.4 % correctness changed - Aggregate: 25.7 % answer changed, 17.3 % correctness changed The two figures differ because a third of the changes (208 of 634) move from one wrong answer to another wrong answer - a real behavioural change that leaves accuracy untouched. PIQA, being binary, has no such blind spot, and its two figures coincide exactly. 2. The same happens in free generation - the answer itself changes. 50 prompts, greedy decoding, 64 tokens. For the MMLU prompts the expected output starts with the answer letter, so the answer can be read directly from the generation (n = 19): - Different answer letter between the two arms: 13 of 19 - Correct on CPU: 7 of 19 - Correct on Neutron: 6 of 19 - Disagreements where both arms are wrong, with different wrong answers: 6 of 13 Two thirds of the answers change, and the score is essentially the same (7 versus 6). The sample is small - we report it as an illustration; the 2,466-item measurement above is the quantitative one. An example, verbatim. The prompt lists four options and asks for a letter, and the expected answer is 😧 CPU: " A\nExplanation: The expression 9(9m + 3t) is equivalent to 81m + 27t. The best answer is A." NPU: " C\nThe best answer is C." Both are wrong, they are wrong differently, and no benchmark score records it. 3. The divergence is present in the very first forward, not accumulated. In this letter format the first generated token IS the answer, and 60 % of generations already differ there - a token produced by the prefill pass alone, before any decoding step. Across all 50 prompts the divergence curve rises steeply then flattens: 84 % by token 4, 98 % by token 64. That is what propagation of an initial difference looks like under greedy decoding, not error accumulating through the KV cache. 4. Aggregate accuracy hides all of it. 50.28 % on CPU against 48.50 % on Neutron, a -1.78 point difference, and none of the three benchmarks is individually significant. Restricting to the 634 items where the arms disagree, CPU is correct 37.1 % of the time against Neutron's 30.1 % - 235 versus 191 among decided items, i.e. 55/45 where symmetric noise would give 50/50. WHAT WE RULED OUT - Silent CPU fallback: ORT profiling reports 80 of 80 MatMulNBits on NeutronExecutionProvider, 0 on CPU. No partial placement. - Two different models: same source file, SHA-256 of graph and external weights recorded at conversion and re-verified before scoring. - Sampling: greedy decoding throughout; no temperature, no top-k, no top-p. - Different inputs: both arms consume the same items file, in the same order, from the same fixed seed. - Scoring artefacts: the board only captures per-token log-probabilities; all decision logic runs offline on the host, identically for both arms. - Run-to-run noise on the NPU: replaying the same items in the same Neutron session yields bit-identical log-probabilities. The NPU arm is reproducible; the discrepancy is against CPU, not against itself. OUR QUESTION Is this expected behaviour for the INT4 path on Neutron-S - and if it is, how should we validate an LLM deployment on the NPU, given that aggregate benchmark accuracy clearly does not surface it? We are not assuming a defect. Some difference between a floating-point CPU kernel and an integer NPU path is normal, and we would like to know what magnitude you consider normal, and what criterion you use yourselves to accept an LLM port to Neutron. If a quarter of answers changing is within expectations, that is a useful thing for us to know and to design around.  Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM Thanks for your quick answer ! D.S Re: i.MX95 Neutron: NPU/CPU discrepancy on one answer in four with the same INT4 LLM Hi @DamienSCHNEBELEN  IMX95 NPU can only run matmul, and LLM performance on NPU is actually only average. Therefore, the phenomenon you observed is within the predictable range, and we do not recommend running LLM models on an NPU. B.R

S32K3x4EVB-T172 PIL 通信错误/超时，MBDT S32K3xx 1.4.0 你好， 我尝试在 MATLAB 2023a 上运行 PIL S32CT 示例和 MBDT S32K3xx (v1.4.0)。我的配置包括通过板载 OpenSDA 端口连接的 S32K3x4EVB-T172。 尝试 1（OpenSDA COM）： 我可以成功刷写生成的目标模型，但是 PIL 执行立即失败，并出现以下错误： “无法打开通信通道”（请参见附件中的错误信息截图） 尝试 2（外置 USB 转串口转换器） 我保持 OpenSDA 端口连接以进行刷写，但将外部 USB2Sireal 连接器连接到 J44（1 到 TX，2 到 RX）以进行 PIL 通信，并在硬件设置中更新了 COM 端口。模型刷写成功，但执行超时并出现以下错误： 错误：从 rtiostream 接口接收数据的超时时间已超过 10 秒。通信失败可能由多种原因造成。 你应该： （a）检查目标硬件配置是否正确，例如，检查字节顺序是否正确。 （b）确认目标应用程序正在目标硬件上运行。 （c）考虑应用程序运行时故障的可能性（例如除以零异常、不正确的自定义代码集成等）。 注（c）：要确定运行时失败的可能原因，请考虑使用 SIL，它支持信号处理程序和调试。 如果找不到解决方案，请考虑使用 rtw.connectivity.RtIOStreamHostCommunicator 的 setTimeoutRecvSecs 方法来增加超时值。 问题： 1.S32K3x4EVB-T172开发板运行PIL时是否需要外接USB转串口转换器，还是可以通过板载OpenSDA端口运行PIL？ 2. 如果需要外部 USB 转串口转换器，所需的硬件 UART 配置具体是什么？ 3. 我是否遗漏了什么配置？ 非常感谢您的指导！ Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 你好， @PruthviB ， 在进一步调查之前，能否请您说明一下您使用MBDT S32K3xx v1.4.0 的原因？最新版本为v1.8.0 ，其中包含多项修复和改进。我们建议您先升级到 v1.8.0 版本，然后检查问题是否仍然存在。 关于您的设置， S32K3X4EVB-T172上的PIL 通信不需要外部 USB 转串口转换器。板载OpenSDA 接口已经提供了对用于主机-目标通信的目标 UART 的访问，因此同一个 USB 连接可以用于编程和 PIL 通信。 由于 OpenSDA 可以直接访问 UART 引脚，因此通常不需要连接额外的 USB 转串口适配器，如果多个串口处于活动状态，甚至可能会引入配置冲突。 请您尝试一下以下示例： MBDT S32K3xx v1.8.0 仅板载OpenSDA USB 连接 在硬件设置中选择的 OpenSDA 公开的 COM 端口 此致， 德拉戈斯 Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 你好， @dragostoma 感谢您对OpenSDA板载接口的指导。 关于版本，MBDT v1.4.0 是推荐用于电池管理系统的 MBDT 版本。请问能否提供在v1.4.0版本中运行PIL仿真的指导？ 顺祝商祺！ 普鲁特维 Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 你好， @PruthviB ， 没错，你说得对。The 电池管理系统 Toolbox requires S32K3 Toolbox version 1.4.0. 由于最初的讨论没有提到电池管理系统 工具箱，我假设这个问题与使用过时的 S32K3 工具箱版本有关。 关于 1.4.0 版本中的PIL 模拟，工作流程保持不变。工具箱提供的示例模型配置为使用LPUART 实例，其 RX 和 TX 信号通过 OpenSDA 接口路由。如果您打算使用专用的USB 转串口转换器，则需要配置不同的 LPUART 实例，并将转换器连接的相应 RX 和 TX 引脚分配给该实例。 总结起来： 使用 OpenSDA 接口：工具箱中包含的示例模型无需任何额外修改即可工作。所需的 LPUART 实例和相关的 RX/TX 引脚已配置完毕。 使用专用 USB 转串口转换器：转换器必须连接到目标设备上的特定 RX 和 TX 引脚。因此，必须配置这些引脚并将其映射到可用的 LPUART 实例，这需要对项目配置进行相应的更新。 使用 USB2Serial 变流器时，请确保使用正确的 COM 端口，并配置 J44 的 RX 和 TX 引脚。 与我们联系， 德拉戈斯

[SPSDK][i.MX95] nxpele read-common-fuse fails Hi, I'm working on enabling secure boot on an IMX95 19x19 EVK board. I've successfully signed my images using the SPSDK. Now, before writing the fuses, i wanted to read them using `nxpele` but i'm getting the error below. ``` $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 read-common-fuse --index 136 SPSDKParsingError: SPSDK: Message SIZE in response is invalid: 0x4 See debug log file: /home/user/.local/state/spsdk/3.11.0/log/debug.log for more info ``` and in the logs it says the following: ``` $ tail -60 /home/user/.local/state/spsdk/3.11.0/log/debug.log raise SPSDKParsingError(f"Message SIZE in response is invalid: {hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: Message SIZE in response is invalid: 0x4 DEBUG:spsdk:*************************************************** (206ms since start, spsdk_logger.py:212) DEBUG:spsdk:* SPSDK DEBUG LOGGING STARTED 2026-09-03 15:58:44 * (207ms since start, spsdk_logger.py:213) DEBUG:spsdk:* SPSDK version: 3.11.0 * (207ms since start, spsdk_logger.py:215) DEBUG:spsdk:* Python version: 3.14.4 * (207ms since start, spsdk_logger.py:216) DEBUG:spsdk:* OS version: Linux-6.12.95+deb13-amd64-x86_64-with-glibc2.43 * (208ms since start, spsdk_logger.py:217) DEBUG:spsdk:* Last command: ['/usr/bin/../lib/spsdk/bin/nxpele', '-f', 'mimx9596', '-d', 'uboot_serial', '-p', '/dev/ttyUSB2', 'read-common-fuse', '--index', '136'] * (208ms since start, spsdk_logger.py:218) DEBUG:spsdk:*************************************************** (208ms since start, spsdk_logger.py:219) TRACE:spsdk.uboot.uboot:Uboot WRITE -> invalid (210ms since start, __init__.py:50) DEBUG:spsdk.uboot.uboot:Uboot READ UNTIL <- => (210ms since start, uboot.py:271) DEBUG:spsdk.uboot.uboot:Checking if the serial console is open by sending invalid command: "invalid\r\nUnknown command 'invalid' - try 'help'\r\nu-boot=> " (224ms since start, uboot.py:209) DEBUG:spsdk.utils.database:Current database finger print hash: f0f0598d4e6ae6c755d693693f232e30537cfb3b (226ms since start, database.py:1967) DEBUG:spsdk.utils.database:Loaded database from cache: /tmp/spsdk-cache-1001/spsdk/3.11.0/db_data_25a661a55aac_3.11.0.cache (226ms since start, database.py:1976) DEBUG:spsdk.utils.misc:Loading text file from /usr/lib/spsdk/lib/python3.14/site-packages/spsdk/data/devices/mimx9596/database.yaml (226ms since start, misc.py:312) INFO:spsdk.ele.ele_comm:ELE communicator is using 196608 B size buffer at 92800000 address in mimx9596, Revision: latest target. DEBUG:spsdk.ele.ele_comm:ELE msg 0x92800000 0x30000 0602971788000000 (245ms since start, ele_comm.py:502) TRACE:spsdk.uboot.uboot:Uboot WRITE -> ele_message 0x92800000 0x30000 0602971788000000 (246ms since start, __init__.py:50) DEBUG:spsdk.uboot.uboot:Uboot READ UNTIL <- => (246ms since start, uboot.py:271) DEBUG:spsdk.ele.ele_comm:Raw ELE message output: ele_message 0x92800000 0x30000 0602971788000000 060497e1d60000000000000000000200u-boot=> (256ms since start, ele_comm.py:422) DEBUG:spsdk.ele.ele_comm:Stripped output: 060497e1d600000000000000 (256ms since start, ele_comm.py:460) DEBUG:spsdk.apps.utils.utils:SPSDK: Message SIZE in response is invalid: 0x4 (257ms since start, utils.py:182) Traceback (most recent call last): File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/utils/utils.py", line 172, in wrapper retval = function(*args, **kwargs) File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py", line 2189, in safe_main sys.exit(main()) # pylint: disable=no-value-for-parameter ~~~~^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 1631, in __call__ return self.main(*args, **kwargs) ~~~~~~~~~^^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 1552, in main rv = self.invoke(ctx) File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 2032, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 1415, in invoke return ctx.invoke(self.callback, **ctx.params) ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/click/core.py", line 910, in invoke return callback(*args, **kwargs) File "/usr/lib/spsdk/lib/python3.14/site-packages/click/decorators.py", line 46, in new_func return f(get_current_context().obj, *args, **kwargs) File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py", line 575, in cmd_read_common_fuse ele_read_common_fuse(handler, index) ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/apps/nxpele.py", line 588, in ele_read_common_fuse ele_handler.send_message(read_common_fuse_msg) ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_comm.py", line 519, in send_message msg.decode_response(response) ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py", line 1235, in decode_response super().decode_response(response) ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^ File "/usr/lib/spsdk/lib/python3.14/site-packages/spsdk/ele/ele_message.py", line 346, in decode_response raise SPSDKParsingError(f"Message SIZE in response is invalid: {hex(size)}") spsdk.exceptions.SPSDKParsingError: SPSDK: Message SIZE in response is invalid: 0x4 ``` Note: i'm using `SPSDK 3.11.0` I've created an issue also on SPSDK's github page https://github.com/nxp-mcuxpresso/spsdk/issues/116#issue-5346231614  Any help is very much appreciated.  Thank you, BR, Re: [SPSDK][i.MX95] nxpele read-common-fuse fails Hi joanxie I'm using linux BSP version LF6.18.20_2.0.0 (yocto wrynose) And here is the output of nxpele get-info $ nxpele -f mimx9596 -d uboot_serial -p /dev/ttyUSB2 get-info ELE get info ends successfully: Command: 0xda Version: 4 Length: 256 SoC ID: SocId:Unknown_0x9590 - 0x9590 SoC version: B000 Life Cycle: OEM_OPEN - 0x0010 SSSM state: 4 Attest API version: 0 UUID: bc193865d65e45f193b55cc234303a0f SHA256 ROM PATCH: d5d2cdc98cb54b64bffb00687edcd994ebfdd762275a66a858d928ae2fcff494 SHA256 FW: 525f972dbb772acd9f461bfc148d29beb5dc2f2e9693ff1b9ace182a8ffd8131 Advanced information: OEM SRKH: 0000000000000000000000000000000000000000000000000000000000000000 CSAL state: EdgeLock secure enclave random context initialization succeed - 0x02 TRNG state: TRNG entropy is valid and ready to be read - 0x03 OEM PQC SRKH: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Re: [SPSDK][i.MX95] nxpele read-common-fuse fails could you tell me what ele fw version do you use for this command? let me double check it Re: [SPSDK][i.MX95] nxpele read-common-fuse fails I reproduced this issue, and I checked internal data base, this is existed issue and will fixe on spsdk 3.12.0 

HSE FW 2.40.0および2.55.0におけるGCM IV長サポートに関する質問 こんにちは、 S32K358のHSEにおけるGCMの動作について質問があります。 HSEサービスAPIリファレンスマニュアルのAEADサービス説明において、HSE FW 2.40.0および2.55.0の両方でGCMについて以下の事項が明記されています。 GCM: 1 <= ivLength <= 2^32-1。推奨サイズは12バイト以上です。 しかし、HSE FW 2.40.0のマニュアルには、HSE FW 2.55.0のマニュアルには記載されていない以下の注記が追加されています。 GCM操作においては、IV値として正確に12バイトを使用することを推奨します。12バイトを超える任意のIVサイズに対して、GCM暗号化操作によって生成される認証タグが正しくない場合があります。GCM復号操作では、認証チェックが失敗することがあります。 この点に関して、以下の点を明確にしたいと思います。 1. IV長が12バイトでない場合、HSE FW 2.40.0でGCM操作を通常使用できますか? 2. 12バイト以外のIV長を使用した場合、HSE FW 2.40.0と2.55.0の間でGCM操作に挙動的な違いはありますか? 3. IV長が12バイト以外の場合、HSE FW 2.40.0と2.55.0の間でGCM動作の信頼性に違いはありますか？ 私たちのテストでは、IV長が12バイトでなくてもGCM暗号化と復号が成功し、認証結果も正確でした。 したがって、HSE FW 2.40.0で12バイト以外のIV長の使用が完全にサポートされているかどうか、またこの場合のHSE FW 2.55.0使用と機能的に違いがあるのかを確認したいと思います。 ご説明いただきありがとうございます。 Re: Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 こんにちは、 @wodudwo さん。 技術的には、ivLengthは異なる長さで設定可能ですが、しかし、その動作が信頼性を保証するわけではないため推奨されません。ご指摘の通り、ドキュメントにはGCM復号操作では、12バイト以外のIV長を使うと認証チェックが失敗する可能性があると記載されています。 異なる長さの点滴チューブを使用したテストに合格したとしても、手術が必ず成功するとは限りません。言い換えれば、特定のテストケースで成功した結果が、その構成が完全にサポートされている、あるいはすべてのシナリオで一貫して動作するという指標と解釈すべきではありません。 さらに、両方のファームウェアバージョンのリリースノートを確認すると、制限事項のリストに同じ推奨事項が記載されていることがわかります。それは、IV値を正確に12バイトにすることです。 この注記はHSE FW 2.55.0からHSEサービスAPIリファレンスマニュアルから削除されましたが、制限自体は変更されていません。 BR、VaneB

i.MX8M PlusおよびTIM-VX/VSINPU上のGC7000UL汎用演算推論パスはNPU専用であるように見える 理事会/BSP: i.MX8M Plus、aarch64 Galcore バージョン 6.4.11.p2.745085 VSINPUExecutionProviderを用いたONNXランタイム(libtim-vx.so に対して静的リンク) Vivante OpenCL ICDの存在と機能(Vivante.icd → libVivanteOpenCL.so) 目標: GC7000UL 3D GPUコア上でResNet50推論ベンチマーク(MLPerfロードゲンハーネス)を実行し、既存のNPU(VIP8000Nano)やCPUベンチマークの結果と比較します。 動作確認済みの項目： Vivante OpenCL ICDを経由したclGetPlatformIDs/clGetDeviceIDsは、1つのプラットフォーム上で2つの独立したデバイスをきれいに列挙します。 デバイス0：GC7000UL.6204.0000 デバイス1：VIP8000Nano-S+I.8002.0000 両者とも、CL_DEVICE_TYPE_ACCELERATORを報告し、エラーはなく、libOpenCL.so → libGAL.so と連携した最小限のCテストプログラムで確認されました。 ORT経由でGPUディスパッチを妨げている原因: ort.get_available_providers()は['VSINPUExecutionProvider', 'CPUExecutionProvider']のみを返します — OpenCLベースのEPはありません。 VSINPUExecutionProviderは静的にリンク libtim-vx.so(OVXLIB/vsi_nn_* API)です。libtim-vx.so と libGAL.so の両方のシンボル/文字列ダンプでは、DEVICE_INDEX/DEVICE_IDスタイルのenv varやconfig surfaceは表示されず、動作の切り替え(VIV_VX_ENABLE_SHADER、VSI_NN_ENABLE_*など)のみが表示されます。 libGAL.so 生のHALレイヤーでgcoHAL_SetDeviceIndex/gcoHAL_GetCurrentDeviceIndexをエクスポートしますが、OVXLIB/TIM-VXからその呼び出しまでの配管は見当たりません。これは、VSINPUが使うグラフコンパイラがデバイスインデックスに関係なくNPUコアのみをターゲットにしている可能性を示唆しています。 具体的な質問： このBSP(galcore 6.4.11.p2)上のTIM-VX / OVXLIBは、グラフをコンパイルして一般的な計算対象としてGC7000ULにディスパッチするのをサポートしているのでしょうか?それともこのビルドではグラフコンパイラは設計上NPUのみ対応されているのでしょうか?また、その方法で実行可能かどうかはどうやって確認すればよいのでしょうか? もしTIM-VXの上流でGPUターゲットグラフコンパイルがサポートされているのに、このNXP搭載ビルドでは有効になっていない場合、それを公開するビルドフラグやSDKコンポーネントはありますか? TIM-VX/ORTを通るサポート済みの経路がない場合、NXPが推奨する汎用推論をGC7000UL上で直接実行する方法(例えばOpenCL/OpenVXレイヤー経由、その部分は機能が確認されているため)やサンプルアプリ、SDKコンポーネント、または参照実装などを基準に構築する方法はありますか? 現在学生で、この実装に取り組みながらGPUの上にORTを動かそうとしているのですが、GPUを使って推論できる方法、あるいは他に何か方法はありますか? どうもありがとうございます。 IMX8MPLUS #GC7000UL Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only こんにちは、 @WaleedO さん。 NXPサポートまでご連絡いただきありがとうございます。 GPU上で推論を実行するにはGPUデリゲートを使うべきで、これを使うとサポートされた操作をCPUだけで動作するのではなくGPUで加速できます。 利用可能な実行バックエンド、設定の委任、サポートフレームワーク、例のアプリケーションをよりよく理解するために、 Machine Learning ユーザーガイド の確認をお勧めします。ガイドには、GPUデリゲートが正しく読み込まれているか、モデルが期待通りに動作しているかを確認するためのステップバイステップの例も含まれています。 セットアップや実行中に問題が発生した場合は、モデル、BSPバージョン、使用しているコマンドを共有していただければ、喜んでサポートいたします。 よろしくお願いします、 アレハンドロ・ガルシア Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only こんにちは、 @Chavira はじめまして。 ドキュメントを確認すると、GPUデリゲートとOpenCLパスは95/952 GPU(Arm Mali G310)内で i.MX 使われています。現在、『The IMX8MPLUS』に取り組んでいます。 IMX8M Plusは以下のスタックを持っています:VX delegate ==> TIM-VX ==> GPU/NPU(統一ドライバー)==> I.MX 8シリーズNPU、 GPU(GC7000,GC7000L、GC7000UL)。ドキュメントによると。 現在、私はONNXとORTを扱っています。実行時には、デフォルトでNPU上で実行されます。OpenCLを使って IMX8MPLUS GPUで作業する方法はありますか?あるいは、コンパイルをNPUかGPUに手動で設定できる手動オーバーライドや技術があれば教えてください。 ご返信いただき、誠にありがとうございます。 敬具、 IMX8MPLUS #TIM-VX #VX-delegate Re: GC7000UL general-compute inference path on i.MX8M Plus and TIM-VX/VSINPU appears NPU-only こんにちは、 はい、まだ可能な経路はありますが、VSINPU Execution プロバイダにGC7000ULを強制するのは避けたほうがいいです。 あなたの結果は、現在のNXP TIM-VX/OVXLIBのビルドが主にVIP8000 NPU向けに設計されていることを強く示唆しています。gcoHAL_SetDeviceIndex libGAL.so だけではTIM-VXがNNグラフをGPUにリダイレクトできるわけではありません。 まずは、ONNXランタイムの外で、小さなモデルでTIM-VX/OpenVXを直接テストします。 お使いのOVXLIBがGC7000UL/GPUのNNターゲットを公開しているか確認してください。 NXP TIM-VXのビルドとアップストリームのTIM-VXを比較してみてください。特にマルチデバイス/プラットフォームのサポートです。 もしTIM-VXがGC7000ULでコンパイルできない場合は、GPUベンチマークとしてVivante OpenCL/OpenVXスタックを直接使用してください。 MLPerfプロジェクトでは、GPUパスに必ずしもORTは必要ありません。別のGC7000ULバックエンドを作成し、CPU/NPU用の同じLoadGenハーネスに接続することができます。 ですので、次のように構成します。 MLPerf LoadGen → ResNet50 GPU バックエンド → OpenCL/OpenVX → GC7000UL それよりも： MLPerf→ORT→VSINPU→GPUを強制的に使います ベストリグラッド、 フェサジ

参考文档请求：在 S32DS 中将 AI 工具与 Cody Chat 集成 尊敬的NXP社区团队： 我目前正在使用 S32 Design Studio，并使用 IDE 中提供的 Cody Chat 功能。 我想知道是否可以将OpenAI ChatGPT 和 Anthropic Claude等外部 AI 模型集成到 S32 Design Studio 的 Cody Chat 部分中。 我的需求是在 S32DS 内部直接使用 AI 助手来执行以下操作： C/C++ 代码生成及说明 嵌入式 C 开发 调试编译器和链接器错误 CAN、SPI、I2C、UART 和 ADC 开发 S32K3/S32K344 开发 了解并参与当前的S32DS项目项目。 我发现 Sourcegraph Cody 的官方文档描述了对 OpenAI 和 Anthropic 模型的支持，包括模型配置和自带密钥 (BYOK) 选项。 请问您能否澄清一下： S32 Design Studio 中使用的 Cody 集成是否能够连接到 ChatGPT/OpenAI 和 Claude 等外部 AI 提供商？ 我们能否在 Cody Chat 部分为这些 AI 提供商配置我们自己的 API 密钥？ 是否有任何 NXP 官方文档、S32DS 文档、Cody 文档或示例项目说明如何在 S32DS 中配置或将外部 AI 模型与 Cody 集成？ 如果当前 S32DS 版本不直接支持此功能，是否有官方方法可以扩展 Cody/Eclipse 插件以支持外部 AI 提供商？ 与标准的 Sourcegraph Cody 实现相比，S32DS 实现的 Cody 是否存在任何限制？ 作为参考，我找到了以下关于支持的LLM和模型配置的Sourcegraph文档： 支持的LLM 科迪模型配置 Cody 模型配置示例 请问能否提供NXP的相关参考文档或推荐的S32DS实施流程？ 感谢您的支持。 此致， 阿拉文德·托加拉利 Re: Request for Reference Documentation: Integrating Ai tools with Cody Chat in S32DS 你好， 人工智能工具及其外部使用文档计划于9月26日发布。

Request for Reference Documentation: Integrating Ai tools with Cody Chat in S32DS Dear NXP Community Team, I am currently working with S32 Design Studio and using the Cody Chat feature available in the IDE. I would like to know whether it is possible to integrate external AI models such as OpenAI ChatGPT and Anthropic Claude into the Cody Chat section of S32 Design Studio. My requirement is to use an AI assistant directly inside S32DS for activities such as: C/C++ code generation and explanation Embedded C development Debugging compiler and linker errors CAN, SPI, I2C, UART and ADC development S32K3/S32K344 development Understanding and working with the current S32DS project context I found that the official Sourcegraph Cody documentation describes support for both OpenAI and Anthropic models, including model configuration and Bring Your Own Key (BYOK) options. Could you please clarify: Is the Cody integration used in S32 Design Studio capable of connecting to external AI providers such as ChatGPT/OpenAI and Claude? Can we configure our own API key for these AI providers in the Cody Chat section? Is there any official NXP documentation, S32DS documentation, Cody documentation, or example project explaining how to configure or integrate external AI models with Cody in S32DS? If this functionality is not directly supported in the current S32DS version, is there an official method to extend the Cody/Eclipse plugin to support external AI providers? Are there any restrictions in the S32DS implementation of Cody compared with the standard Sourcegraph Cody implementation? For reference, I found the following Sourcegraph documentation regarding supported LLMs and model configuration: Supported LLMs Cody Model Configuration Cody Model Configuration Examples Could you please provide the appropriate NXP reference documentation or recommended procedure for implementing this in S32DS? Thank you for your support. Best regards, Aravind Togaralli Re: Request for Reference Documentation: Integrating Ai tools with Cody Chat in S32DS Hi,  the release of AI tools with documentation for external usage is planed on September 26. 

PFE EMAC0 ECUウェイクアップ後の無効なバッファアクセス こんにちは、 EMAC0を2500 Mbpsで設定し、必要なSERDESチャネル設定も行っています。ECUの稼働状態中は、イーサネット通信が正常に動作しています。 Eth通信にアクセスするアプリケーションをシャットダウンした後、ECUMからECUスリープリクエストをトリガーし、MCUモードをSOCスタンバイに設定し、HSE_CM7をメインコアとして選択します。 ウェイクアップ後、ECUは通常の動作に戻り、COM、SOAD、TCPIP、ETHIFのレイヤーは期待通りに動作します。EthのIFレイヤーでは、API呼び出し中の「Provide TX buffer」が「Provide TX buffer」が空いていないというエラーを返し、その後Ethフレームの送信が停止します 問題解決のために試された修正方法のリスト: 1. 「Eth_43_Pfe_Deinit」を使ってPFEドライバをシャットダウンし、「Eth_43_Pfe_Init」を呼んでPFEドライバを起動しようとしましたが、実行後にCPUがロックされてしまいました。 2. EthコントローラをEth_43_Pfe_SetControllerモードで下げてアクティブに戻そうとしたところ、バス障害が発生しました この問題の解決策を教えてください。 追伸> 使用コンフィギュレーター:EB tresos Eth PFE RTDバージョン:1.3.0 SDK:GOLDVIP Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、Avinash_7373さん ご返信よろしくお願いします。 1.SOCがスタンバイモードに入ると、パーティション2のPFEクロックが無効になります。ウェイクアップ後にパーティション2が再度有効になっているか確認してください。PFE開始前のPCSの状態PRTN2_STATを確認してみてください。PFE開始前のPCS状態。 2. SERDESが正常に機能しているかどうかを確認します。 BR ジョーイ Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、 @Joey_z 1.PFEはMコアでのみ使用されています 2. 開発ボードを使っています:S32G-VNP-RDB3 よろしくお願いいたします。 アビナシュ・V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、Avinash_7373さん お問い合わせいただきありがとうございます。 1. PFEはMコアでのみ使用されますか？Aコアを一緒に使ったことはありますか？ 2. お客様のボードを使っていますか、それとも私たちの開発ボードを使っていますか? BR ジョーイ Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、@Joey_z。 ステータスレジスタのビットフィールドはスリー プ前Partition_2 1のままですが、スリープ中は 0 に更新され、MCUモードが通常に設定された後、ウェイクアップ後には再び 1 に更新されます。 Serdesは正常に動作しています。さらに、ET Phyコネクタ(RJ45)とコントローラー(NXPS32G399A)の間にSERDESが関与しないRGMIIモードでEMAC2を試しましたが、それでも問題は同じままでした。 Partition_2の起動後に再起動シーケンスが必要な場合は、お知らせください。 よろしくお願いいたします。 アビナシュ・V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、Avinash_7373さん 問題は、おそらくウェイクアップ後のPFE初期化に関するものと思われます。クロックと関連するPFE構成を確認し、理想的な状態に初期化されていることを確認してください。 1. PFEの初期化がブートローダーに入力され、起動後にアプリケーション内で正しく再初期化されているか確認してください。 2. スタンバイプロセスに従って該当する構成を確認する。RM 32.5.5「実行モードからスタンバイモードへ」を参照してください。 BR ジョーイ Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、Avinash_7373さん ご返信よろしくお願いします。 スタンバイとウェイクアップシーケンスの操作について教えていただけますか? 1. コアとパーティションはどのように設定しますか？ 2.Do アプリケーションでブートローダーとAコアを使っていますか? BR ジョーイ Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、 @Joey_z さん。 以下に睡眠・覚醒の順序を示します。 1. API 「EcuM_SelectShutdownTarget()」 を使ってECUスリープモードをリクエストしています。これにより、ECUMの実装通りにMCUモードがスタンバイに設定されます。 2. ECUMがスリープモードに入ると、ウェイクアップイベントをポーリングし、CANトランシーバーがバスの活動を検出してEcuM_SetWakeupEvent() APIを使ってウェイクアップイベントを設定し、その後ECUは通常の動作を再開します。 ブートローダーについては、NXPのブートローダー(0x0にフラッシュされる)のフラッシュ位置と、Mコアアプリケーションが0x400000にフラッシュされます。Aコアはどこにも使用されていません。 よろしくお願いいたします。 アビナシュ・V Re: PFE EMAC0 Invalid Buffer Access Post ECU wakeup こんにちは、 Avinash_7373 あなたの問題について何か進展はありましたか？もし継続的なサポートが必要な場合は、以下のリンクからコードをアップロードしていただければ問題をより詳しく分析できます。 https://support.nxp.com BR ジョーイ

can not get all details with command: v4l2-ctl --device /dev/video0 --all Hi All, I'm working with camera sensor os02g10. I can get the RAW10 file from sensor but the picture is not correct. There is misalignment  and picture has 2 parts shifted to each other. You can see it here: https://community.nxp.com/t5/i-MX-Processors/Camera-sensor-os02g10-MIPI-CSI-for-IMX8MM-Image-issue/m-p/1512386#M194329 I tested many DeviceTree setting for camera sensor and mipi-csi but no changes in the picture. There is also issue with v4l2, below you can see it. Why it can not get Driver Info: Driver name : mx6s-csi Card type : i.MX6S_CSI Bus info : platform:32e20000.csi_bridge Driver version : 5.10.72 Capabilities : 0x84200001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04200001 Video Capture Streaming Extended Pix Format Priority: 0 Video input : 0 (Camera: ok) Format Video Capture: Width/Height : 1920/1080 Pixel Format : '' Field : None Bytes per Line : 0 Size Image : 4147200 Colorspace : Default Transfer Function : Default (maps to Rec. 709) YCbCr/HSV Encoding: Default (maps to ITU-R 601) Quantization : Default (maps to Full Range) Flags : Crop Capability Video Capture: Bounds : Left 0, Top 0, Width 0, Height 0 Default : Left 0, Top 0, Width 0, Height 0 Pixel Aspect: 1/1 Selection Video Capture: crop, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: crop_default, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: crop_bounds, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_default, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_bounds, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: compose_padded, Left 0, Top 0, Width 0, Height 0, Flags: Selection Video Capture: native_size, Left 0, Top 0, Width 0, Height 0, Flags: But when I get picture there is more details. I try to identify if v4l2 is the source of incorrect picture or something else. What can be wrong ? v4l2-ctl -d /dev/video0 --verbose --set-fmt-video=width=1920,height=1080,pixelformat=BG10 --stream-mmap --stream-count=1 --stream-to=bb001.raw VIDIOC_QUERYCAP: ok VIDIOC_G_FMT: ok VIDIOC_S_FMT: ok Format Video Capture: Width/Height : 1920/1080 Pixel Format : 'BG10' (10-bit Bayer BGBG/GRGR) Field : None Bytes per Line : 3840 Size Image : 4147200 Colorspace : sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: ITU-R 601 Quantization : Full Range Flags : VIDIOC_REQBUFS returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QUERYBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_QBUF returned 0 (Success) VIDIOC_STREAMON returned 0 (Success) cap dqbuf: 0 seq: 0 bytesused: 4147200 ts: 46.903731 delta: 46903.731 ms (ts-monotonic, ts-src-eof) i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all Hi, you can use our linux upstreamed driver,  we have tested this on i.mx8mp based debix platform.  Here is our driver  https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=263d0fa1d46ac1ae2eebc5a5490fec58233c69ad Here is our DT https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a4d0f0c88ae8185315afbc1eb68c978ed710f759 -- Rutvij  SiliconSignals Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all Looks like mx6s_vidioc_g_fmt_vid_cap is incomplete.  mx6s_vidioc_s_fmt_vid_cap has all details btarnowski_0-1672393812102.png Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all regarding RAW10 there is solution https://community.nxp.com/t5/i-MX-Graphics/gst-launch-1-0-returns-Internal-data-stream-error/m-p/1536966 and regarding: v4l2-ctl --device /dev/video0 --all hard to say what is wrong, maybe camera driver uses ctrl API instead ctrlio for V4L2 But now it's not problem, for me next thing is to set parameter like exposure or gain Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all hi @btarnowski  for the display thing with v4l2-ctl --all, you just need to edit mx6s_capture.c In function 'mx6s_vidioc_s_fmt_vid_cap' : just copy the whole pix struct instead of just width/height/sizeimage/field csi_dev->pix = f->fmt.pix; this way, internal struct csi_dev->pix has all the information needed when you do a get_format (see function mx6s_vidioc_g_fmt_vid_cap) i feel mx6s_capture.c is full of little mistakes and needs a lot of improvements to have a better compliance with v4l2 tools. regards Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all Hi, Regarding v4l2-ctl --device /dev/video0 --all  and  gstream no progress. Looks like it is camera sensor driver issue. dev/media0 - is not necessary There is different approaches for handling camera sensor. Below you can see differences for low level API handling. ov5640 (camera sensor) works on other device. btarnowski_0-1663928001102.png And the other comparison: btarnowski_1-1663928150167.png Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all did you get any solution for that? because i have got the same error if you got pls share your solution Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all And also I see not correct assignments. The csi_bridge should be assigned to media0. btarnowski_0-1662374734790.png How to do that, any help? Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all in the meantime: root@qrnd:~# gst-inspect-1.0 -a > gst-inspect.txt and the result below in the attachement Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all next issue: I can see video devices, but there is no /dev/media devices root@qrnd:~# v4l2-ctl --list-devices i.MX6S_CSI (platform:32e20000.csi_bridge): /dev/video0 vsi_v4l2dec (platform:vsi_v4l2dec): /dev/video2 vsi_v4l2enc (platform:vsi_v4l2enc): /dev/video1 Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all I had to update the list of packages for yocto build: # Camera support tools IMAGE_INSTALL_append = " i2c-tools" IMAGE_INSTALL_append = " v4l-utils" IMAGE_INSTALL_append = " gstreamer1.0" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good" IMAGE_INSTALL_append = " gstreamer1.0-plugins-imx" IMAGE_INSTALL_append = " gstreamer1.0-plugins-base" IMAGE_INSTALL_append = " gst-player" IMAGE_INSTALL_append = " gstreamer1.0-meta-base" IMAGE_INSTALL_append = " gst-examples" IMAGE_INSTALL_append = " gstreamer1.0-rtsp-server" IMAGE_INSTALL_append = " gst1.0-fsl-plugin" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-video4linux2" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-png" IMAGE_INSTALL_append = " gstreamer1.0-plugins-good-jpeg" but now I have issue with the command gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=1 ! video/x-raw,width=1920,height=1080 ! pngenc ! filesink location=/tmp/test_1920x1080.png I got: Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline: pipeline0/GstV4l2Src:v4l2src0: Internal data stream error. Additional debug info: ../git/libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: streaming stopped, reason not-negotiated (-4) Execution ended after 0:00:00.057218529 Setting pipeline to NULL ... Freeing pipeline ... Re: can not get all details with command: v4l2-ctl --device /dev/video0 --all Looks that Yocto makes this issue. There is no all needed components in the kernel image. Lack of v4lsrc from gstreamer-plugins-good. I added additional packages to Yocto build but no effect. Need to investigate the deploy stage of Yocto build process.

摩托罗拉 MCQ1C3L69J 和摩托罗拉 MC908Q4CP 数据手册 我正在寻找以上两种元器件的数据手册，谢谢。 Re: Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets 你好， 由此给您带来的不便，我深表歉意。这是老产品，信息有限； MC908Q4CP：您是不是想说的是“908QC4”，而您正在寻找的是MC68HC908QC4？如果是这样，这是数据手册[ MC68HC908QC16、MC68HC908QC8、MC68HC908QC4 - 数据手册] 有关 C08Q 系列的更多数据手册，请参阅HC08Q|8 位 EEPROM 仿真 Q MCU | NXP 半导体 MCQ1C3L69J：根据勘误信息，“3L69J”指的是掩码； 您能否帮我们确认一下，您是否还有其他名称可以用来识别该设备？ 顺祝商祺！ Re: Motorola MCQ1C3L69J and Motorola MC908Q4CP Datasheets Hello 谢谢！ 请看附图

S9KEAZN16AM WDOG 时序说明：128 个总线时钟与观察到的 80 微秒和 2.5 毫秒延迟对比 你好， 我正在与S9KEAZN16AM合作，想了解一下 WDOG 初始化时间的相关问题。 配置 MCU：S9KEAZN16AM 总线时钟：16.777216 MHz WDOG 时钟源：1 kHz LPOCLK 重置类型：软件重置（SYSRESETREQ） 根据KEA64参考手册，在看门狗解锁序列之后： “解锁序列完成后，用户必须在 128 个总线时钟周期内重新配置看门狗；否则，看门狗将强制 RESET MCU。” ppande19_1-1784788705383.pngppande19_1-1784788705383.png 总线时钟频率为 16.777216 MHz： 128 个总线时钟周期 ≈ 7.63 微秒 说明 为了确保可靠运行，我们目前的实施方案需要以下延迟： 软件重置();   SysTick_DelayUs(2500);   禁用中断();   WDOG_Init(&Wdog_cfg);   SysTick_DelayUs(80);   启用中断(); 我们发现两个问题： 如果移除或减少Software_Reset() 之后的 2.5 毫秒延迟，看门狗计数器并不总是能正确启动/运行。 如果移除WDOG_Init() 之后的 80 µs 延迟，看门狗配置将无法始终正确应用。 问题 128 总线时钟要求是否仅限于解锁后的配置窗口，还是之后还会进行额外的内部同步？ 使用1 kHz LPO 时钟是否会引入额外的同步延迟？ RESET后是否存在已知的启动时间要求，可以解释为何需要约 2.5 毫秒？ 是否有推荐的状态位或轮询机制可以替代固定延迟？ 主要令人困惑的是，观察到的延迟（ 80 µs 和 2.5 ms ）明显大于记录在案的128 总线时钟（~7.6 µs）要求所隐含的时序。 任何指导都将不胜感激。 谢谢！ Re: S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays 如果在 ICS 完全锁定之前尝试初始化看门狗或运行严格的定时循环，则在该时间段内，实际总线时钟频率会较低或不稳定。较低的实际总线时钟意味着 128 个总线周期将比 7.6 µs 长得多，或者您的初始化序列在硬件外设完全脱离其RESET状态之前执行。约2.5毫秒的延迟使ICS有足够的时间完全锁定并稳定16.777216 MHz总线频率。 Re: S9KEAZN16AM WDOG timing clarification: 128 bus clocks vs observed 80 µs and 2.5 ms delays 你好， 等待约 2.5 毫秒，以便内部时钟源 (ICS) 完全锁定并稳定总线时钟 (16.777216 MHz)。过早初始化看门狗或运行紧密循环会导致时钟不稳定/降低，从而造成时序偏差或在外部设备RESET之前执行。

高级线粒体配方评测：完整购买指南 最后更新日期：2026年9月5日 高级线粒体配方是一种膳食补充剂，旨在支持线粒体健康和细胞能量产生。与许多主要侧重于兴奋剂的普通能量补充剂不同，该配方旨在为线粒体提供营养支持，线粒体通常被称为细胞的“动力工厂”。这正是高级线粒体配方与其他市面上的线粒体支持补充剂区别开来的原因之一。 高级线粒体配方 的核心理念 很简单：为身体提供有助于维持线粒体健康功能和高效细胞能量产生的营养物质。当线粒体正常运作时，细胞就能更有效地产生能量。这有助于维持日常精力、耐力、精神集中力和整体细胞机能。 Re: Advanced Mitochondrial Formula Reviews: A Complete Buyer’s Guide 高级线粒体配方是一种膳食补充剂，由美国、加拿大、英国、澳大利亚和新西兰配制而成，旨在支持线粒体功能和健康的细胞能量产生。与许多传统能量补充剂主要依赖兴奋剂不同，它专注于提供关键营养素，帮助滋养和支持线粒体——通常被描述为我们细胞的“动力工厂”的结构。这种营养方法是ORIGINAL 高级线粒体配方与其他许多线粒体支持产品区别开来的特点之一。 高级线粒体配方的理念很简单：为身体提供营养，以帮助维持健康的线粒体活性，并支持细胞层面的有效能量产生。功能正常的线粒体在细胞产生能量的过程中发挥着重要作用。通过支持正常的线粒体功能，该配方可能有助于提高日常精力、耐力、精神警觉性和整体细胞性能。