Kinetis Bootloader 总结 Bootloader是一种面向用户应用程序的引导代码，可以在没有烧写器的情况下烧录用户程序，也可以用于在线更新程序。飞思卡尔提供了三种实现bootloader的方式，分别为： 1.预烧写在ROM中的bootloader     这种方式是MCU中内置了专用的ROM来存放bootloader，目前支持ROM型bootloader的Kinetis系列MCU包括KL03，KL17，KL27和KL43等。其中KL03和KL17的ROM bootloader包含SPI/UART/IIC三种接收方式，KL27和KL43还增加了USB的方式。 2.预烧写在FLASH中一次性bootloader     这种类型的bootloader在芯片出厂前预写在FLASH中，因此可以像ROM型bootloader一样直接使用。但与ROM型不同的是，上电后bootloader会从FLASH搬移到RAM 中运行，再将FLASH整片擦除并烧写用户程序，因此这种bootloader是一次性的。其优点是不需要片内ROM且方便量产烧写，缺点是无法支持以后的程序更新。目前支持预烧写在FLASH中一次性bootloader的Kinetis系列MCU包括K22、K24和KV3x等。 3.开放源码的bootloader     这种方式将FLASH空间分为两个部分，一部分用于存储bootloader代码；另一部分用于存储用户应用程序代码。这种方式的bootloader方便客户定制自己的代码。     目前飞思卡尔提供开放源代码的Kboot，支持UART/SPI/IIC/USB HID 几种接口方式，其网址链接为：     www.freescale.com/kboot     除了Kboot，还有以下独立版本的bootloader，包括：     1）AN2295（开发人员的串行引导加载程序）         文档下载地址为：http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN2295.pdf         代码下载地址为：http://cache.freescale.com/files/microcontrollers/doc/app_note/AN2295SW.zip        另外FAE Yang Liang 对其进行了移植，目前已经支持FRDM-KE02,KE06,KL25,KL26,KL43,KL46, TWR-K60, KV4x, KV10.下载地址为：Kinetis/AN2295_Bootloader · GitHub     2）AN4767 （Kinetis E 系列上的UART Boot Loader 设计）         文档下载地址为：http://cache.freescale.com/zh-Hans/files/32bit/doc/app_note/AN4767.pdf         基于AN2295，没有提供代码。     3）AN4775 （Kinetis E 系列上的IIC Boot Loader设计）         文档下载地址为：http://cache.freescale.com/zh-Hans/files/32bit/doc/app_note/AN4775.pdf         代码下载地址为：http://cache.freescale.com/files/32bit/doc/app_note/AN4775SW.zip     4）AN4368 （USB 大容量存储设备主机引导加载程序）          文档下载地址为：http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN4368.pdf          代码下载地址为：GitHub - Wangwenxue/USB_MSD_Host_Bootloader_K60: This is usb msd Bootloader for K60 （For K60）                                        GitHub - Wangwenxue/USB_MSD_Host_Bootloader_K64: This USB MSD bootloader for K64 （For K64）     5）AN4379  （Freescale USB大容量存储设备引导加载程序）          文档下载地址为：http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN4379.pdf          代码下载地址为：http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4379SW.zip     6）AN4764   （USB Human Interface Device Boot Loader for ColdFire Plus, Kinetis K, and Kinetis L MCUs）          文档下载地址为：http://cache.freescale.com/files/32bit/doc/app_note/AN4764.pdf          代码下载见附件     7）AN4370   （用于 MCU 的 USB DFU 引导加载程序）         文档下载地址为：http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN4370.pdf         代码下载地址为：http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4370SW.zip       8）AN4367   （用于 MCU 的 以太网引导加载程序）         文档下载地址为：http://cache.freescale.com/zh-Hans/files/microcontrollers/doc/app_note/AN4367.pdf?fromsite=zh-Hans         代码下载地址为：http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4367SW.zip         最新的代码请到FNET官网下载：http://fnet.sourceforge.net/    9）Kinetis Bootloader to Update Multiple Devices in a Network - for Cortex-M0+         代码及文档下载地址为：https://community.freescale.com/docs/DOC-328168             回复：Kinetis Bootloader 总结 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 嗨文学 对 Kinetics 系列引导加载程序的总结做得很好。 我正在研究基于 K20d72m 的定制板，寻找从 PC 接收命令来校准板上的蓝牙芯片的解决方案。 您是否知道是否有一个演示引导加载程序同时支持 USB（虚拟 COM 连接到 PC）和 SPI 端口到外围芯片？我需要这样的裸机应用程序来进行电路板校准。 谢谢！ 回族 Re: Kinetis Bootloader 总结 谢谢，我一直在更新AN2295，目前支持FRDM-KE02，KE06，KL25，KL26，KL43，KL46. TWR-K60, KV4x, KV10，可以从下面这个地址获取： Kinetis/AN2295_Bootloader · GitHub Re: Kinetis Bootloader 总结 点赞,总结的非常好! Re: Kinetis Bootloader 总结 谢谢分享，非常感谢！ 希望能将KBoot如何通过命令行更新介绍的更详细些。 回复：Kinetis Bootloader 总结 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> HI，Liang Yang， 如何将 KE02/KE06 uart 引导加载程序移植到 FRDM-KE04Z 演示板？ 谢谢你？ 回复：Kinetis Bootloader 总结 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> Hi hui， 我们没有可以满足您的要求的引导加载程序。您需要自己动手。 顺祝商祺！ Wenxue 发自我的 iPhone 在 2015年4月11日，0:20，"Hui Shao" > 写道： <> <> Kinetis 引导加载程序总结 Hui Shao 的新评论<>查看本文档的所有评论<>

S32G_LLCE_to_PFE_Demo Building(Chinese Version) 本文说明在S32G2 RDB2板上实现LLCE to PFE Demo的搭建过程。本Demo目前包括：  CANtoEth：CAN0发送，用硬件回环到 CAN1接收，然后通过PFE_EMAC1， 再通过RGMII接口发出。  CANtoEth：CAN0发送，用硬件回环到 CAN1接收，然后通过PFE_EMAC1， 再通过SGMII接口发出。  EthtoCAN：PC通过PFE_EMAC1的 RGMII发出，接收到CAN1，再硬件 回环到CAN0  CANtoCAN Logging to Eth: CAN0发 送，用硬件回环到CAN1接收，然后 通过PFE_EMAC1，再通过SGMII接 口发出,同时LLCE内部硬件把CAN1 再发送到CAN15_TX，再用硬件回环 到CAN14_RX 软件版本为 RTD3.0.0+LLCE1.0.3+PFE0.9.6/0.9.5。 Automotive

MPC5746Cは周囲温度115℃でハングアップする（起動せず、UARTも動作しない）。 パート: MPC5746C(Power Architecture Z4、SDK:NXP MPC57xxプラットフォームSDK) 周囲温度115℃での恒温槽試験中、当社のMPC5746Cベースのボードは起動時に完全に反応しなくなり、UARTコンソール出力が全くなくなります。この現象は、その温度での起動試行のたびに発生します。冷却後、部品は完全に回復するようです。室温で再フラッシュ/再起動すると、永続的な損傷なく正常な動作に戻ります。 興味深いことに、基板が115°Cの状態でもPEMicro JTAGデバッグプローブを使ってフラッシュを再プログラム することは可能です 。これは、温度でバージョンストリングをフラッシングし、冷却後に新しいバージョンを読み返すことで確認済みです。したがって、デバッグプローブのフラッシュ経路は115°Cで動作します。アプリケーションのブートパスだけがハング/悪い状態になります。 マニュアルにはMCUが最大125°Cまで持続できると書かれています。 問題の根本原因と解決方法を教えていただけませんか。 Re: MPC5746C hangs (no boot, no UART) at 115°C ambient こんにちは、 マニュアルにはMCUが最大125°Cまで持続できると書かれています。 はい、それは問題ありません。 問題の根本原因と解決方法を教えていただけませんか。 これはカスタムボードであり、冷却後に問題が解消されることから、私は次のことを疑っています。 1. 時計の起動に関する問題（最も可能性が高い） 115℃の場合： 外部水晶発振器（FXOSC）の起動時間が長くなります。 発振器のゲインマージンが減少する。 負荷コンデンサの値は温度によって変化する。 プリント基板からの漏洩電流が増加します。 デバッグロジックは独自のインフラストラクチャを利用し、アプリケーションがmain(に到達する)に依存しないため、デバッガーは部品にアクセスできます。 FXOSCステータスビット CMUクロックモニタの障害 FIRCのみのブート実験 FIRCから完全に実行し、外部水晶発振器を一時的に無効にする JTAGのプログラミングが115°Cで動作し続けていることは、コアインフラストラクチャがまだ生きており、故障がフラッシュアレイ自体ではなくアプリケーションのブートパスの非常に早い段階で起きていることを示す最も強い手がかりです よろしくお願いいたします。 ピーター Re: MPC5746C hangs (no boot, no UART) at 115°C ambient @petervlna さん、貴重なご意見ありがとうございます。 これを受けて、同僚の@mnargundと私はさらに調査を進め、MPC5746Cを115℃で正常に起動させることに成功しました。以下に、調査結果の概要を示します。 根本原因: 事前初期化時にシステムをFIRC、FXOSC、PLLを起動するように設定し、その後システムクロックをFIRCからPLLに切り替えました。続いて、DRUN モードへのモード遷移をトリガーしました（システムはデフォルトで既に DRUN モードでしたが、マニュアルに記載されているように、新しい設定を有効にするには同じモードへの遷移が必要です）。そして、MC_ME_GS.MTRANS をポーリングして遷移が完了するのを待ちました。 しかし、MC_ME_GS.MTRANSがクリアされた後でも、コードはIVOR1例外でエラーを起こしました。これは、実行が続行された時点で遷移が完全に安定していなかったことを示している可能性があります。高温（115℃）では、室温よりも遷移に時間がかかるようで、次の命令が実行されたときにシステムが不安定な状態になる。 回避策の適用例: MC_ME_GSの後に明示的なソフトウェア遅延を挿入しました。MTRANSのポーリングを行い、その後の初期化を進めます。500ミリ秒の遅延を設けると、115℃の環境下でも起動は安定して成功する。100ミリ秒の遅延もテストしましたが、私たちの環境では問題なく動作しました。 初期化のこの段階で安全に挿入できる最大推奨ソフトウェア遅延はありますか? 125℃までの全動作温度範囲において、動作前にクロックの安定性を確実に確保するための推奨手順はありますか？

T1024 RESET_REQ 无故注册 您好，我们最近几个月在使用T1024 CPU时遇到了一些问题。 先感谢您。 问题描述： 我们的工业PLC内部使用了T1024NSE7KQA CPU。 直到去年我们还在使用 MQX OS（单核实现），然后我们用 SDKLINUX 将其移植到双核 Linux 实现（该操作系统大部分是由第三方实现的）。 硬件在物理上与之前的MQX操作系统版本相同。 所有单元在 Linux 启动期间都出现问题：MCU 卡住（MCU 本身发出 RESET_REQ_B 信号）。 该事件并非确定性的：只有 10% 的启动周期会受到影响，但它总是发生在操作系统启动的同一阶段。 我们通过周期性的启动/关机序列重现了该问题。 如果事件发生在开机后，则总是在硬件启动/初始化后约 40 秒，操作系统启动完成后 5-8 秒发生（由于操作系统进程调度略有变化，从启动到事件发生的时间略有变化）。 否则，该事件将不会再次出现，我们需要等待几次断电重启才能再次发生。 RCW 正确，PBL 阶段正确完成。 事件发生前，我们用示波器检查了 O1VDD、OVDD、G1VDD、VDD、VDDC 电源轨电压，结果显示电压稳定，且在 CPU 容差范围内。 事件期间，我们测量到 RESET_REQ_B:H->L 转换。 我们中断了 RESET_REQ_B 与板载电路之间的任何板载连接（这样 RESET_REQ_B 就不会强制 HRESET_B 或 PORESET_B 发生转换），以便在同一启动周期或下一个启动周期中读取 DCFG_CCSR_RSTRQSR1 寄存器，但结果始终为0x0值。我们确信CPU内部正在请求RESET，但我们找不到原因。 我们已将操作系统日志的详细程度设置为最高，但在问题启动事件发生之前，我们并未发现任何异常（与正常启动相比）：没有内核消息，没有进程消息，没有异常，…… 我们正在通过 UART 定期记录 DCFG_CCSR_RSTRQSR1 寄存器：事件发生后，CPU 无法再写入任何内容。 我们尝试屏蔽所有RESET原因（将 DCFG_CCSR_RSTRQMR1 的所有非保留位设置为 1），但问题仍然存在。 问题： • 是否存在未映射到 DCFG_CCSR_RSTRQSR1 的 RESET_REQ_B 原因？我提醒一下，我们已经屏蔽了 DCFG_CCSR_RSTRQMR1 中的所有非保留位，但没有成功； • 我们如何才能深入了解是哪个 CPU 机制请求了 RESET_REQ_B？ • CPU 是否可能进入低功耗电源管理单元状态，从而发出 RESET_REQ_B 信号？ 谢谢你的解释。 贾科莫·加斯帕里尼。 Re: T1024 RESET_REQ without any cause registered 顺便问一下，我无法访问我的官方账号：请问你们处理这类问题的参考邮箱地址是什么？谢谢 Re: T1024 RESET_REQ without any cause registered 你好， 关于你提出的三个问题： 1) 是否 存在 未 映射 到 DCFG_CCSR_RSTRQSR1 的 RESET_REQ_B 原因 ？ 是的： CPU/核心 看门狗 定时器 复位请求 原因 未 映射 到 RSTRQSR1 ； 当 配置 为 看门狗 复位 请求 模式 时 ， 它们 会 在 DCFG_CCSR_RSTRQWDTSR 中 捕获 。T1024 RM 明确 指出 RSTRQSR1 不包括 核心 看门狗 定时器 源， 而 RSTRQSR1 是 专用 RSTRQWDTSR 看门狗 状态 寄存器 。 对于记录在案的非看门狗原因， RSTRQSR1 至少包括： IFC_RR 、 WDT_RR （摘要，指示RSTRQWDTSR中至少设置了一个看门狗位 ）、 SW_RR 、 CCM_RR 、 PBL_RR 、 SFP_RR 、 SEC_RR 、 SDC_RR 、 MBEE_RR 、 RPTOE_RR 和SRDS_RST_RR SRDS_RST_RR 2 ） 如何 才能 进一步 挖掘 ？ 下一步 最 有用的 方法 是 在 同 一个 失败 的 启动 周期 中 捕获 更 广泛的 RESET 快照 ， 而 不仅仅是 RSTRQSR1 。在 之前的 T1024 支持 案例 中 ， 推荐 的 寄存器 集 为： DCFG_CCSR_RSTCR 、 DCFG_CCSR_RSTRQPBLSR 、 DCFG_CCSR_RSTRQMR1 、 DCFG_CCSR_RSTRQSR1 、 DCFG_CCSR_RSTRQWDTMR 和 DCFG_CCSR_RSTRQWDTSR 。 根据 您的 症状 出现 时间——Linux 系统 完全 启动 后 ， 大约 5-8 秒 后 出现 故障 —— 可能 需要 注意 的 字段 是 ： RSTRQWDTSR 用于线程监视程序过期详情 如果 软件 直接 或 通过 某种 复位 路径 写入 DCFG_CCSR_RSTCR[RESET_REQ] （位 30） ， 则 RSTRQSR1[SW_RR] 值会 发生变化 。 RSTRQSR1[RPTOE_RR] 表示 与 核心 停止/复位 请求 处理 相关 的 RCPM 超时 复位 请求 事件 RSTRQSR1[MBEE_RR] 用于平台内部存储器多位ECC RSTRQSR1[SRDS_RST_RR] 表示已启用SerDes PLL未锁定 一些基于源代码的调试观察： RESET_REQ_B 可以 在 任何 时候 被钳位 ， 并且 一旦 被钳位， 它将 一直保持 钳位状态， 直到 PORESET_B 被 钳位为止。 设计 清单 建议 保留 一个 选项 ，可以 将 RESET_REQ_B 与 PORESET_B 或 HRESET_B 断开 ， 专门 用于 调试/RCW 覆盖 场景， 因为 否则 反复的 复位 循环 会妨碍 诊断。 NXP 在 类似 情况 下 提供的支持 指南 指出， 在 发生 灾难性的 内部 事件 后， CPLD 通常 不是 RSTRQSR1 的 实用 记录 器 ； 使用调试器 读取 复位 寄存器 ， 同时 尽量 减少 SoC 的 参与， 则被 认为 更 实用 。 根据 我 找到 的 文档 ， 最 直接的 调试 方法 是 ： 在调试期间 ， 防止 RESET_REQ_B 导致 立即 触发 POR 路径 。 捕获 RSTRQSR1 和 RSTRQWDTSR ， 以及 RSTCR 、 RSTRQPBLSR 和 掩码 寄存器 。 RSTRQSR1 如果 可能， 在 RESET_REQ_B 置位 后 但 在 任何 外部 复位 传播 之前 ， 立即 使用 JTAG 停止 。 3) CPU 是否可能 进入 低 功耗 状态 ， 从而 发出 RESET_REQ_B 信号 ？ 对于 标准 的 T1024 电源管理单元 状态 ——PH10/doze、 RESET_REQ_B /nap、 LPM20/sleep—— 检索到的 T1024 文档 并未 将 进入 这些 状态 描述 为 RESET_REQ_B 的 原因 。这些 模式 通过 RCPM 控制 进入 ，并 通过 唤醒 事件、 中断、 硬 RESET 或 其他 已记录的 唤醒 机制 退出 。 深度 睡眠 有所 不同： 在 深度 睡眠 唤醒 时 ， EPU 有限状态 机 在 退出期间 明确 请求 热 设备 RESET （ Exit.2 : XTRIG[ 9 Exit.2: XTRIG[9]: Request warm device reset ）。 此外， 白皮书 中的 Linux 挂起/深度睡眠 流程 指出， EPU 在 启动 代码 恢复 之前 ， 会 在 深度睡眠 唤醒 过程 中 发出 设备 热 复位 指令 。 然而， 这 是 一种 深度睡眠 恢复 机制 ， 而不是 在 正常 运行时进入 PH10 /PH15/LPM20 的 正常 结果 。   此致问候 Re: T1024 RESET_REQ without any cause registered 首先，非常感谢您的详细且迅速的回复！ 1）根据您的回复，我们也尝试使用 DCFG_CCSR_RSTRQWDTSR 寄存器值 0x3 来掩盖看门狗复位的原因，但问题仍然存在。 2) 我们使用 CodeWarrior TAP 通过 JTAG 读取了寄存器。事件发生后，我们立即发出“暂停”命令，并读取了以下寄存器值： RegistersOnReset_Req.png 原因似乎是软件RESET（DCFG_CCSR_RSTRQSR1[SW_RR]=1）。 这与 RESET_REQ_B 的这种原因无法通过 DCFG_CCSR_RSTRQMR1 寄存器屏蔽这一事实相符；这就是问题反复出现的原因…… 我们正在调查此次 RESET 的原因。 3) 在我最初的问题中，因果关系颠倒了：CPU 是否可能进入低功耗状态，然后导致 RESET_REQ_B 断言？ 如果您能帮忙，我最后还要补充一个相关问题，是关于今天我们进行的 CPU 寄存器读取试验中 CPU 到 JTAG TAP 的连接问题： 将 CodeWarrior TAP 连接到 CPU 后，向 CodeWarrior 发出 Suspend 命令，但只有 1 次我们能够读取 CPU 寄存器；其他每次尝试都会出现此错误（见图），并且与 CPU 失去连接。 CSS_ConnectionError.png 这是 CodeWarrior 的配置问题吗？我们该如何解决这个问题？ 再次感谢。 贾科莫。 Re: T1024 RESET_REQ without any cause registered 关于 uC RESET 问题的最新进展：我们发现 ETH phyter 驱动程序存在问题（它在 Linux 内核上调用了“machine_restart”函数，但由于在刷新控制台消息之前中断被禁用，我们在日志中看不到任何内容）。 我们可以暂时关闭这个话题了。 谢谢！

外部供給クロック信号の電圧仕様（MCX A185 VLH） 最大値が見つかりません。データシート上のMCXA185VLH MCUのEXTAL48Mピンで許容される電圧。 LPCxxxファミリのマイクロコントローラでは、発振器入力がこの振幅(0.85Vppなど)に非常に厳格であることを知っています。 外部から生成された3.3Vの発振クロック信号を直接EXTAL48Mピンに送ることはできますか? クロック|タイマー MCXA Re: Voltage specification for externally provided clock signal (MCX A185 VLH) 投稿ありがとうございます。 はい、データシートには最大 Vec (外部から提供される入力クロック振幅) が指定されています。電圧はVIHとして表されます。しかし、VIHは0.7xVDDなので、VDD=3.3Vの場合、最大ベクトル。電圧は2.31Vのみになります。 つまり、このデータシートの仕様が間違っているか、VDD=3.3Vの場合、Vecの最大値は実際には2.31Vなのでしょうか? Re: Voltage specification for externally provided clock signal (MCX A185 VLH) こんにちは、 @wyss-11 投稿ありがとうございます！ MCXA18にはEXTAL48M入力電圧の定義がありますが、それは独立した固定のEXTAL48M電圧値としてではなく、VDDに対する標準入力しきい値VIH/VILを介して間接的に指定されます。 データシートには、発振のピークツーピーク振幅が標準値として0.6Vと記載されているだけです。 VDDが3.3 Vの場合EXTAL48M、クロックがVIH/VILの閾値を満たし、かつVDD + 0.3 Vの入力制限を超えない限り、3.3 Vの外部発振器で駆動可能です。 Re: Voltage specification for externally provided clock signal (MCX A185 VLH) こんにちは、 @wyss-11 VEC仕様とは、外部発振器入力が有効な低状態および高状態を認識するために必要な最小電圧レベルを指します。 VDD = 3.3 Vの場合、2.31 Vは有効なハイレベルとして検出される最小電圧です。

MCX N947 TFLM モデルランナーによるNeutron変換モデルの推論 TFLM modelrunnerのHTTPを使って、FRDM MCXN947(CPUとNPU)で多数のtfliteモデル(<500KBサイズ)をベンチマークしたいと思っています。 問題は、CPU推論がすべてのモデルで機能せず、NPU推論も全く機能しないことです。 ハードウェア: - FRDM-MCXN947開発ボード(USBとイーサネットでWindowsマシンにコネクテッド) ソフトウェアとツールのセットアップ: - ホスト:Windows 11マシン - eIQ Neutron SDK: eiq-neutron-sdk-windows-3.0.1 - MCUXpresso SDKs:SDK_26_03_00_FRDM-MCXN947 - SDKsからのプロジェクト:frdmmcxn947_tflm_modelrunner_cm33_core0 CPU推論のためのMLモデル: - ad01_int8.tflite - kws_ref_model.tflite - pretrainedResnet_quant.tflite - vww_96_int8.tflite Neutronコンバータ（eIQ Neutron SDKの一部）で変換されたNeutronのMLモデル（NPU推論用）: eiq-neutron-sdk-windows-3.0.1\bin neutron-converter --target mcxn94x --input ad01_int8.tflite --output ad01_int8_converted_3_0_1.tflite - ad01_int8_converted_3_0_1.tflite - kws_ref_model_converted_3_0_1.tflite - pretrainedResnet_quant_converted_3_0_1.tflite - vww_96_int8_converted_3_0_1.tflite 実施されたステップ 1. 最新のeIQ Neutron SDKライブラリでeIQプロジェクトを更新する コピー先: eiq-neutron-sdk-windows-3.0.1\target\mcxn94x\common\include\NeutronErrors.h eiq-neutron-sdk-windows-3.0.1\target\mcxn94x\driver\include\NeutronDriver.h eiq-neutron-sdk-windows-3.0.1\target\mcxn94x\mcxn\libNeutronDriver.a eiq-neutron-sdk-windows-3.0.1\target\mcxn94x\mcxn\libNeutronFirmware.a に： frdmmcxn947_tflm_modelrunner_cm33_core0\include\NeutronErrors.h frdmmcxn947_tflm_modelrunner_cm33_core0\driver_include\NeutronDriver.h frdmmcxn947_tflm_modelrunner_cm33_core0\mcxn\libNeutronDriver.a frdmmcxn947_tflm_modelrunner_cm33_core0\mcxn\libNeutronFirmware.a 2. vscodeを使用してプロジェクト「frdmmcxn947_tflm_modelrunner_cm33_core0」をビルドしてフラッシュします。 3. フラッシュ済みのTFLM Modelrunnerを使用してHTTP経由で推論を実行します。 指示： curl -X PUT http://192.168.178.75:10818/v1-F "block_content=@C:\ \ad01_int8.tflite" シリアルモニター経由の出力： .... 実行時間: 6.167000ms 指示： curl -X PUT http://192.168.178.75:10818/v1-F "block_content=@C:\ \vww_96_int8.tflite" シリアルモニター経由の出力： .... 実行時間: 182.042000ms 他のモデルでは動作しません 出力: a) フラッシュ後の推論なし: FLASH 0x104000 消去、プログラム at 104000: 16384 bytes == フラッシュ0x108000消去済み、プログラム108000:16384バイト == フラッシュ0x10c000 消去、プログラム10c000:16384バイト == FLASH 0x110000 消去、プログラム 110000 で:16384バイト == フラッシュ0x114000消去済み、プログラム114000:16384バイト == FLASH 0x118000 消去、プログラム118000:16384バイト == フラッシュ0x11c000消去、プログラム11c000:16384バイト == FLASH 0x120000 消去、プログラム at 120000: 16384バイト == FLASH 0x124000 消去済み、プログラム124000:16384バイト == FLASH 0x128000 消去、プログラム at 128000: 16384 bytes == フラッシュ0x12c000消去、プログラム12c000:16384バイト == FLASH 0x130000 消去、プログラム at 130000: 16384 bytes == フラッシュ0x134000消去済み、プログラム134000:16384バイト == FLASH 0x138000 消去、プログラム 138000:544バイト == b) フラッシュ処理が全くありません c) 誤HardFault_Handler 343行目: ldr r0,=HardFault_Handler で SDK_26_03_00_FRDM-MCXN947\mcuxsdk\devices\MCX\MCXN\MCXN947\gcc\startup_MCXN947_cm33_core0.S デバッガーによって停止されました どんなヒントでも大歓迎です！ MCX N Re: MCX N947 TFLM Modelrunner Inference of Neutron Converted Models こんにちは、 @Laurens26さん 問題は純粋な「モデルサイズ」の問題というよりも、バージョンの整合性が混ざっている可能性が高いと思います。 このリンクを参照してもいいと思います。 最新のeIQ Neutron SDKライブラリでeIQプロジェクトを更新する方法 BR ハリー

Why model size is limited at 1 MB? I run model from sample tflm_cifar10 on MIMRT700 (NPU model). When building the program, I could see the model's size and correspond region size.  In many cases, the region size is 1 MB. As my understanding, the model's size is limited at 1 MB. Is that right? nnxxpp_0-1781495142659.png I did not understand this point. Here is information of MIMRT700 EVK. nnxxpp_2-1781495429888.png I don't know where model is saved on MIMRT700 EVK. And where is the 1 MB for region size? Is it actual limit of model size? Or we can increase model size by some methods. Do you have any comment for this problem? Because I try to deploy a larger model > 1 MB. I do wait for your response. Thank you. Re: Why model size is limited at 1 MB? @mayliu1  Thank you so much. Now I understood that we can increase the size of the model by setting region size. nnxxpp_0-1781514247437.png Or If I want to run larger model on external memory, I can follow this document https://docs.nxp.com/bundle/AN14700/page/topics/external_memory.html  Re: Why model size is limited at 1 MB? Hi @nnxxpp , Thank you so much for your interest in our products and for using our community. Q: I don't know where model is saved on MIMRT700 EVK. And where is the 1 MB for region size? Is it actual limit of model size? Or we can increase model size by some methods. Do you have any comment for this problem? Because I try to deploy a larger model > 1 MB. A: The 1 MB shown for modeldata is not a hardware limit of the RT700. It is only the default linker allocation used in the sample project. For larger models, this allocation can be adjusted in the project settings, and external XSPI flash can also be used if more storage is needed. For more detail information, you can refer to this AN14700. https://docs.nxp.com/bundle/AN14700/page/topics/introduction.html mayliu1_0-1781507645284.png So, the RT700 is not inherently limited to a 1 MB model. Larger NPU models are supported either by increasing the modeldata memory allocation or by placing the model in external XSPI flash with the appropriate conversion option.  Wish it helps you Best Regards May Liu Re: Why model size is limited at 1 MB? @mayliu1  I want to reopen this topic. Now i am trying to deploy larger model on RT700. The below image is captured when building the program with the small model. I see that there are 4 memory regions: - QSPI_flash: external memory - SRAM: I ask chatgpt and it is for data when running the program (like .data, .bss, stack, heap). Is that correct? - NCACHE_REGION: it is same ktensorArena (for inputs, intermediate outputs and output) -  modeldata: to save model weights I see in the memory configuration when I import SDK example. It means that SRAM, NCACHE_REGION and modeldata from SRAM (7.5 MB). NCACHE_REGION and modeldata should be located in  0x2000_0000 to 0x2058_0000 (5.5 MB) to get best perforemce (SRAM area that can be accessed by the NPU) But location of SRAM (named SRAM) is 0x20080000 (in the second image) ==> It is also in the range 0x2000_0000 to 0x2058_0000. And by default, it is set about 2.5 MB. It means that NCACHE_REGION + modeldata should be less than (5.5 - 2.5) = 3 MB. My model size is about 3.5 MB. Beside that I can locate my model on external memory (it results in larger inference time), how I can config memory to still locate my model (3.5 MB) on memory area that NPU can access? I am curious about whether we can shrink "SRAM" region (in the images 1, 2) or can I move it to another area of RAM (7.5 - 5.5 = 2 MB - the last region in the image 3)? And how I can estimate the size of "SRAM" region? In the below image, it is 15560 B. Sorry for my long questions. nnxxpp_0-1782205318606.png nnxxpp_1-1782205742121.png nnxxpp_2-1782206037185.png Re: Why model size is limited at 1 MB? @mayliu1  Good morning. Maybe you missed my new above questions.  Re: Why model size is limited at 1 MB? Hi @nnxxpp , Apologies for the delayed response. If you don’t mind, could you please create a new case for your new issue?  Thank you for your understanding and cooperation. Best Regards, May Re: Why model size is limited at 1 MB? @mayliu1  Yes, ok. Let me create new issue. Thank you. Re: Why model size is limited at 1 MB? @mayliu1  I have resolved my problem. We can locate SRAM outof 5.5 MB area for NPU. I locate modeldata and kTensorArena in area 5.5 MB and it worked. The inference time is good. But If you did not miss my questions, so I can finish soon my tasks. Thank you. Re: Why model size is limited at 1 MB? Yes. Have a nice day. Re: Why model size is limited at 1 MB? Glad to hear that your issue has been resolved. Apologies for the delayed response,   thank you for your understanding.

i.MX RT700 开发套件对 VIT 语音到意图（S2I）功能的支持 您好，NXP团队， 我正在评估 VIT 的语音到意图（S2I）解决方案，用于在 i.MX RT700 开发套件上实现自然语言语音控制。 在查看 VIT S2I 文档和支持的设备信息时，我注意到 i.MX RT700 没有明确列在 S2I 自然语言模型支持的设备/示例中。不过，RT700 搭载了 HiFi4 DSP 和 NPU，这两者似乎非常适合语音 AI 应用。 请问能否就以下问题进行说明？ i.MX RT700 EVK 是否正式支持 VIT 语音转意图 (S2I) 引擎？ 如果是，是否有适用于 RT700 的参考示例、SDK 包或移植指南？ 如果 RT700 目前不支持 S2I，未来是否有计划添加该功能？ 对于 i.MX RT700 平台，您会推荐哪些由 NXP 支持的自然语言理解（NLU）或语音转意图解决方案？ 目前，我可以看到VIT Wake Word和Voice Command技术支持多台i.MX RT设备，但我特别感兴趣的是基于自然语言/意图的语音控制，而不是固定命令识别。 感谢您的指导。 Re: VIT Speech-to-Intent (S2I) Support on i.MX RT700 EVK 你好@suhas1503， 对于语音转意图解决方案，推荐的软件包是 VIT。 有关支持的设备的更多信息以及有关VIT语音转意图的一般问题，请联系当地的恩智浦代表或发送电子邮件至 [email protected]。 顺祝商祺！ 巴勃罗

iMX8 Mini 上的 SEC_CONFIG 熔丝 您好， 我正在尝试在基于 iMx8 Mini 的自定义硬件平台上启用安全启动。 通过遵循可用的文档，我能够创建具有正确签名的启动映像，我确信这是因为 hab_status 命令没有显示任何 hab 事件，而且图像验证器工具也没有显示任何错误。 为了关闭设备，我对SRK_HASH熔丝和SEC_CONFIG熔丝进行了编程，但是在这一步之后，我的板无法启动，也不会在串行控制台上显示任何内容。 我很确定SRK_HASH已正确编程，但我对SEC_CONFIG有疑问：要启用安全启动，我应该使用以下命令： 熔丝 prog 1 3 0x02000000 这会设置第25位。 不过，在进行修改之前，我查看了 SEC_CONFIG 的内容，发现其中包含以下值： 熔丝读取 1 3 0x8000000 既然我看到第 27 位被设为 1，我就灵机一动，想到了使用下面的命令： 熔丝 prog 1 3 0x0A000000 保留第27位，并设置第25位。 问题： 是否可能是上述命令将 SEC_CONFIG 设置为无效值，导致 ROM 引导加载程序甚至无法启动 SPL？ 如果是，有什么办法可以恢复板吗？ 顺祝商祺！ Re: SEC_CONFIG fuse on iMX8 Mini 您好， 非常感谢您的解答，这与目前的情况相符。 最后一个问题： 由于我没有对任何锁定位进行编程，您认为使用硬件调试器是否有可能恢复板？ 顺祝商祺！ Re: SEC_CONFIG fuse on iMX8 Mini 如果在写入保留位后芯片损坏，则无法恢复芯片，因为熔丝操作是一次性且不可逆的过程。 Re: SEC_CONFIG fuse on iMX8 Mini 第 27 位是保留位，客户无法对其进行编程。与其说该命令（熔丝 prog 1 3 0x0A000000）会使 sec_config 失效，不如说整个芯片的行为更有可能变得不可预测。 Re: SEC_CONFIG fuse on iMX8 Mini 你好， 很遗憾，不行，清除熔丝是不行的，e熔丝是一次性可编程的。一旦 sec_config 被破坏，就无法“撤销”。

FRDM-IMX93 预制图像 大家好， 以下图片有何不同？我找不到更新日志文件。我需要将我的 FRDM-imx93 主板恢复为出厂设置。 谢谢！ Screenshot from 2026-06-10 15-52-23.png Re: FRDM-IMX93 prebuilt images 您好 ，它们之间的变化微乎其微，我建议您使用 Linux 电路板支持包 版本，因为 FRDM 版本是我们在集成之前获得的初始软件支持。 https://www.nxp.com/design/design-center/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX 此致， 阿尔多。

rte_eth_rx_burst -> 连续两次返回相同的 mbuff 指针 从我的应用程序调用 rte_eth_rx_burst 有时同一 mbuff 会出现两次。已检查代码缓冲区未释放 .在没有空闲 mbuff 的情况下，同一 mbuff 指针会收到两次。 QorIQ LS1设备 Re: rte_eth_rx_burst -> returning same mbuff pointer twice consecutively 启用 DPDK 日志级别（首先尝试） 运行应用程序： --日志级别=8 你会看到什么？ 处理 RX 描述符 缓冲区分配/再循环 PMD 行为 启用 mbuf 调试检查（非常有用） 用以下工具重建 DPDK CONFIG_RTE_LIBRTE_MBUF_DEBUG=y 这将 验证 mbuf 的一致性 接住： 损坏的元数据 错误地重复使用了 mbuf 无效 启用 mempool 调试 CONFIG_RTE_LIBRTE_MEMPOOL_DEBUG=y 有助于检测 双分配 缓存损坏 从 mempool 返回两次相同的缓冲区 毒物/自由追踪（非常有用） 您可以启用内存覆盖检查： CONFIG_RTE_MALLOC_DEBUG=y 以及 -mp-alloc=debug 这有助于检测： 覆盖之前/之后的 mbuf 隐藏的内存损坏 快速隔离技巧（非常有效） 运行 testpmd -- -i 然后： set fwd rxonly 开始 如果重复消失： 您的应用程序错误 如果仍然发生： PMD / HW / 队列配置问题 Re: rte_eth_rx_burst -> returning same mbuff pointer twice consecutively 感谢@yipingwang的快速回复和建议。我无法从代码中找出更多信息。有任何 DPDK 调试标志可以提供帮助吗？ Re: rte_eth_rx_burst -> returning same mbuff pointer twice consecutively 如果您的代码中没有明确的 mbuf 空白，最有可能的情况是 mbuf 仍在通过应用程序中的其他路径有效返回/重复使用，或者不安全地跨线程/内核共享，或者特定于驱动程序/路径的特殊缓冲区处理问题正在破坏生命周期状态。 跨核/共享 mbuf 所有权问题。 一个记录在案的案例中使用了一个 CPU 用于 RX，许多工作程序 CPU 消耗了环中的 mbuf；然后看到 mbuf 地址被重复使用/覆盖，但仍在其他地方被引用。恩智浦特别询问 RTE_MBUF_REFCNT_ATOMIC 是否为多核访问启用，客户说是，但问题仍被视为应用级所有权/寿命处理、 应用程序管道中有重复的版本或隐藏的返回路径。在这种情况下，恩智浦的指导方针是分析缓冲区分配/释放/数据包发送操作，以查看相同的地址是否被多次释放回缓冲池。 PMD/driver 在特殊路径中向池返回畸形 mbufs。 另外还有一个涉及链式 mbuf 的 DPAA2 PMD 案例，在该案例中，返回 mempool 的 mbuf 出现损坏（ 下一个 未清除），从而导致以后分配时的正确性检查失败。这与您的报告症状不同，但它确实表明特殊的缓冲区处理路径可能会导致以后的重复使用/损坏症状。 加密路径中的源和目标 mbuf 相同。 在 DPAA 网络安全/IPsec 案例中，恩智浦指出，如果  sym->m_dst  为  NULL  ，则  m_src  和  m_dst  使用相同的 mbuf。这可能会使数据包内容在负载情况下 "就地 "重写，即使指针标识没有改变。 Re: rte_eth_rx_burst -> returning same mbuff pointer twice consecutively 感谢@yipingwang的快速回复。我会尽量向您汇报情况。 每当多个 mbuf（来自同一地址）到达时，屏幕上都会显示以下内容： fslmc: dpaa2_get_qbman_swp(): 新增门户 0x17ffd61c0 (5) 关联线程 - 1953 fslmc: dpaa2_configure_stashing(): 门户= 5 CPU= 10 SDEST= 5 fslmc: DPAA 门户=0x17ffd61c0 (5) 已绑定至线程 1953 Re: rte_eth_rx_burst -> returning same mbuff pointer twice consecutively 这些 fslmc / dpaa2 portal affined thread 日志强烈表明门户（QbMan SWP）正在重新连接到不同的线程/内核，这可能会破坏所有权模型 → 导致 mbuf 重复使用/重复症状。

请问guider的table控件怎样在guider软件里调整每个单元格的宽度？ 我在使用table控件时，在guider界面没找到调整每个单元格的宽度的按钮或输入框。请问应该怎样在设计时调整单元格宽度？ Re: 请问guider的table控件怎样在guider软件里调整每个单元格的宽度？ Hi @alen-liao  您好，您可以尝试修改这个参数。 Harry_Zhang_0-1781158999778.png BR Harry

IW611：无法设置 Linux 驱动程序 您好， 我正在尝试用 Linux 内核 4.19 启动 IW611。我使用的是 mwifiex 分支 if-6.12.49_2.20。 配置文件包含以下内容： SDIW612 = { cal_data_cfg=none hw_name=IW611 fw_name=nxp/sduart_nw61x_v1.bin drv_mode=0x1 auto_ds=2 pm_keep_power=1 cntry_txpwr=0 slew_rate=0 } 芯片被 MMC 总线驱动程序识别，nwifiex 驱动程序已加载。但当我尝试启动 mlan0 接口时，却出现了写入错误。谁能告诉我是什么地方配置错误或出错了？ 下面是我的 dmesg 输出： [8.423408] wlan：正在加载 MWLAN 驱动程序 [8.427639] 未指定模块参数 cfg 文件 [8.632441] wlan：注册到总线驱动程序... [8.666463] vendor=0x0471 device=0x0205 class=0 function=1 [8.711324] Attach moal handle ops，卡接口类型：0x109 [8.764392] SDIW612：来自用户的初始化模块参数 [8.769688] cal_data_cfggs：SDIW612，配置块：0 [8.774488] cal_data_cfggg =无 [8.777622] hw_name=iw611 [8.780414] fw_name=nexp/sduart_nw61x_v1.bin [ 8.784838] drv_mode = 1 [ 8.787512] auto_ds = 2 [ 8.790109] pm_keep_power on [ 8.793152] cntry_txpwr = 0 [ 8.796102] slew_rate = 0 [ 8.798916] SDIO: sdio_blk_size=256 max_blk_count=65535 max_segs=64 max_seg_size=65536 [ 8.807287] rx_work=0 cpu_num=1 [ 8.810624] Enable moal_recv_amsdu_packet [ 9.101160] Attach mlan adapter operations.card_type is 0x109. [ 9.118472] wlan：启用 TX SG 模式 [ 9.122181] wlan: mpa_tx.buf_size=65280 [ 9.126231] wlan：启用 RX SG 模式 [ 9.129954] wlan: mpa_rx.buf_size=65280 [ 9.261877] 请求固件：nxp/sduart_nw61x_v1.bin [ 10.067400] Wlan：FW 下载结束，firmwarelen=913892 已下载 837692 [ 10.467947] WLAN FW 处于活动状态 [ 10.471106] on_time is 10463342042 [ 10.494983] VDLL 映像：len=76200 [ 10.498741] fw_cap_info=0x487cff03, dev_cap_mask=0xffffffff [ 10.504665] uuid: e139b70377da5b6fbc71c709b955b9a7 [ 10.509761] max_p2p_conn = 8, max_sta_conn = 16 [ 10.529596] IOCTL failed: 1b0efb8f id=0x200000, sub_id=0x200046 action=1, status_code=0x3 [FW_CMDRESP] [ 10.544554] Register NXP 802.11 Adapter mlan0 [ 10.549385] wlan: version = SDIW612---18.99.2.p19.10-MM6X18540.p33-GPL-(FP92) [10.567328] 设置 REG 0x90002328：0x10d57 slew_rate=0 [10.576793] usbcore：注册了新的接口驱动程序 usbxxx [10.584854] wlan：注册到总线驱动程序完成 [10.589480] wlan：驱动程序已成功加载 这里我尝试启动 mlan0 [ 76.346952] cmd53 write error=-110 [ 76.353352] host_too_card, write iomem (1) failed: -1 [ 76.359014] write CFG reg failed [ 76.362560] cmd53 write error=-110 [ 76.366184] host_too_card, write iomem (2) 失败：-1 [ 76.371495] write CFG reg 失败 [ 76.374999] cmd53 write error=-110 [ 76.402254] host_too_card, write iomem (3) 失败：-1 [ 76.407537] write CFG reg 失败 [ 76.410971] Error: host_to_card failed: 0xFFFFFFFF [ 76.416043] DNLD_CMD: Host to Card Failed [ 76.420306] IOCTL failed: ef7a4e76 id=0x90000, sub_id=0x90001 action=1, status_code=0x80000006 [CMD_DNLD_FAIL] [ 76.430903] ------------Dump info----------- [ 76.435415] Command to card failure [ 76.439111] pending command id: 0x10 ioctl_buf= (null) [ 76.444634] pending command id: 0x28 ioctl_buf=a69aa9f8 [ 76.450155]没有待执行的扫描命令 [ 76.453847] CurCmd 空 [ 76.456521] mlan_processing =1 [ 76.459753] main_lock_flag =0 [ 76.462885] main_process_cnt =75 [ 76.466292] delay_task_flag =0 [ 76.469523] mlan_rx_processing =0 [ 76.473022] rx_pkts_queued=0 [ 76.476061] more_task_flag = 0 [ 76.479292] num_cmd_timeout = 0 [ 76.482607] last_cmd_index = 2 [ 76.485830] last_cmd_id = [ 76.485834] 0x27c [ 76.488698] 0x27c [ 76.490818] 0x243 [ 76.492938] 0xe4 [ 76.495058] 0x5b [ 76.497086] 0x242 [ 76.499123] 0x4d [ 76.501243] 0xd1 [ 76.503271] 0x10 [ 76.505299] 0x28 [ 76.510935] last_cmd_act = [ 76.510937] 0x0 [ 76.513885] 0x1 [ 76.515821] 0x0 [ 76.517757] 0xff [ 76.519704] 0x1 [ 76.521732] 0x1 [ 76.523668] 0x1 [ 76.525604] 0x0 [ 76.527540] 0x1 [ 76.529486] 0x213 [ 76.535109] last_cmd_resp_index = 2 [ 76.538799] last_cmd_resp_id = [ 76.538802] 0x827c [ 76.542117] 0x827c [ 76.544329] 0x8243 [ 76.546540] 0x805b [ 76.548761] 0x805b [ 76.550973] 0x8242 [ 76.553185] 0x804d [ 76.555396] 0x80d1 [ 76.557608] 0x8010 [ 76.559828] 0x8028 [ 76.565819] last_event_index = 1 [ 76.569233] last_event = [ 76.569236] 0x0 [ 76.571999] 0x81 [ 76.573936] 0x0 [ 76.575963] 0x0 [ 76.577907] 0x0 [ 76.579844] 0x0 [ 76.581780] 0x0 [ 76.583716] 0x0 [ 76.585652] 0x0 [ 76.587587] 0x0 [ 76.593035] num_data_h2c_failure = 0 [ 76.596809] num_cmd_h2c_failure = 1 [ 76.600500] num_data_c2h_failure = 0 [ 76.604275] num_cmdevt_c2h_failure = 0 [ 76.608241] num_int_read_failure = 0 [ 76.612015] last_int_status = 64 [ 76.615422] num_alloc_buffer_failure = 0 [ 76.619572] num_pkt_dropped = 0 [ 76.622888] num_noo_cmd_node = 0 [ 76.626202] num_event_deauth = 0 [ 76.629617] num_event_disassoc = 0 [ 76.633208] num_event_link_lost = 0 [ 76.636890] num_cmd_deauth = 0 [ 76.640121] num_cmd_assoc_success = 0 [ 76.643987] num_cmd_assoc_failure = 0 [ 76.647860] num_cons_assoc_failure = 0 [ 76.651818] cmd_resp_received=0 [ 76.655133] event_received=0 [ 76.658180] max_tx_buf_size=4096 [ 76.661587] tx_buf_size=3072 [ 76.664626] curr_tx_buf_size=3072 [ 76.668134] data_sent=0 cmd_sent=0 [ 76.671725] ps_mode=1 ps_state=0 [ 76.675133] wakeup_dev_req=0 wakeup_tries=0 wakeup_timeout=0 [ 76.681121] hs_configured=0 hs_activated=0 [ 76.685448] pps_uapsd_mode=0 sleep_pd=0 [ 76.689506] tx_lock_flag = 0 [ 76.692545] scan_processing = 0 [ 76.695859] scan_state = 0x0 [ 76.698907] bypass_pkt_count=0 [ 76.702132] mp_rd_bitmap=0x0 curr_rd_port=0x0 [ 76.706734] mp_wr_bitmap=0xffffff curr_wr_port=0x0 [ 76.711987] mp_data_port_mask = 0xffffff [ 76.716314] last_recv_rd_bitmap=0x0 mp_invalid_update=0 [ 76.721843] last_recv_wr_bitmap=0xffffffff last_mp_index=0 [ 76.727641] mp_wr_bitmap：0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.734364] 0x00 [ 76.734367] 0x00 [ 76.736395] 0x00 [ 76.738432] 0x00 [ 76.740460] 0x00 [ 76.742488] 0x00 [ 76.744516] 0x00 [ 76.746543] 0x00 [ 76.748580] 0x00 [ 76.750609] 0x00 [ 76.752637] 0x00 [ 76.754665] 0x00 [ 76.756692] 0x00 [ 76.758729] 0x00 [ 76.760757] 0x00 [ 76.762785] 0x00 [ 76.768417] mp_wr_bitmap：0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.775131] 0x00 [ 76.775133] 0x00 [ 76.777162] 0x00 [ 76.779199] 0x00 [ 76.781227] 0x00 [ 76.783255] 0x00 [ 76.785283] 0x00 [ 76.787311] 0x00 [ 76.789348] 0x00 [ 76.791376] 0x00 [ 76.793404] 0x00 [ 76.795437] 0x00 [ 76.797465] 0x00 [ 76.799502] 0x00 [ 76.801531] 0x00 [ 76.803559] 0x00 [ 76.809192] mp_wr_bitmap：0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.815906] 0x00 [ 76.815908] 0x00 [ 76.817944] 0x00 [ 76.819973] 0x00 [ 76.822001] 0x00 [ 76.824029] 0x00 [ 76.826057] 0x00 [ 76.828093] 0x00 [ 76.830121] 0x00 [ 76.832149] 0x00 [ 76.834177] 0x00 [ 76.836205] 0x00 [ 76.838241] 0x00 [ 76.840269] 0x00 [ 76.842297] 0x00 [ 76.844325] 0x00 [ 76.849957] mp_wr_bitmap：0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.856671] 0x00 [ 76.856673] 0x00 [ 76.858711] 0x00 [ 76.860739] 0x00 [ 76.862774] 0x00 [ 76.864803] 0x00 [ 76.866831] 0x00 [ 76.868868] 0x00 [ 76.870897] 0x00 [ 76.872925] 0x00 [ 76.874953] 0x00 [ 76.876981] 0x00 [ 76.879018] 0x00 [ 76.881046] 0x00 [ 76.883074] 0x00 [ 76.885102] 0x00 [ 76.890734] mp_wr_bitmap：0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.897448] 0x00 [ 76.897451] 0x00 [ 76.899488] 0x00 [ 76.901516] 0x00 [ 76.903544] 0x00 [ 76.905572] 0x00 [ 76.907599] 0x00 [ 76.909636] 0x00 [ 76.911665] 0x00 [ 76.913693] 0x00 [ 76.915721] 0x00 [ 76.917749] 0x00 [ 76.919785] 0x00 [ 76.921813] 0x00 [ 76.923841] 0x00 [ 76.925869] 0x00 [ 76.931501] mp_wr_bitmap：0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.938223] 0x00 [ 76.938226] 0x00 [ 76.940254] 0x00 [ 76.942282] 0x00 [ 76.944310] 0x00 [ 76.946337] 0x00 [ 76.948374] 0x00 [ 76.950402] 0x00 [ 76.952430] 0x00 [ 76.954457] 0x00 [ 76.956485] 0x00 [ 76.958521] 0x00 [ 76.960550] 0x00 [ 76.962578] 0x00 [ 76.964605] 0x00 [ 76.966633] 0x00 [ 76.972265] mp_wr_bitmap：0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 76.978987] 0x00 [ 76.978990] 0x00 [ 76.981018] 0x00 [ 76.983046] 0x00 [ 76.985074] 0x00 [ 76.987102] 0x00 [ 76.989138] 0x00 [ 76.991167] 0x00 [ 76.993195] 0x00 [ 76.995222] 0x00 [ 76.997250] 0x00 [ 76.999286] 0x00 [ 77.001315] 0x00 [ 77.003343] 0x00 [ 77.005371] 0x00 [ 77.007399] 0x00 [ 77.013031] mp_wr_bitmap：0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 77.019753] 0x00 [ 77.019756] 0x00 [ 77.021784] 0x00 [ 77.023812] 0x00 [ 77.025840] 0x00 [ 77.027876] 0x00 [ 77.029905] 0x00 [ 77.031940] 0x00 [ 77.033969] 0x00 [ 77.035997] 0x00 [ 77.038033] 0x00 [ 77.040062] 0x00 [ 77.042090] 0x00 [ 77.044118] 0x00 [ 77.046145] 0x00 [ 77.048182] 0x00 [ 77.053806] mp_wr_bitmap：0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 77.060529] 0x00 [ 77.060531] 0x00 [ 77.062560] 0x00 [ 77.064587] 0x00 [ 77.066615] 0x00 [ 77.068652] 0x00 [ 77.0x00 [ 77.072708] 0x00 [ 77.074736] 0x00 [ 77.076764] 0x00 [ 77.078801] 0x00 [ 77.080829] 0x00 [ 77.082857] 0x00 [ 77.084884] 0x00 [ 77.086912] 0x00 [ 77.088949] 0x00 [ 77.094572] mp_wr_bitmap：0x0 mp_wr_ports=0x0 len=0 curr_wr_port=0x0 [ 77.101295] 0x00 [ 77.101297] 0x00 [ 77.103326] 0x00 [ 77.105354] 0x00 [ 77.107381] 0x00 [ 77.109418] 0x00 [ 77.111446] 0x00 [ 77.113474] 0x00 [ 77.115502] 0x00 [ 77.117529] 0x00 [ 77.119566] 0x00 [ 77.121595] 0x00 [ 77.123623] 0x00 [ 77.125650] 0x00 [ 77.127678] 0x00 [ 77.129715] 0x00 [ 77.135341] bss_index = 0, tx_pkts_queued = 0 tx_pause [ 77.140796] Host:chillair-r1234yf-00050 Timestamp:9c6953b9 [ 77.146691] Driver version = SDIW612---18.99.2.p19.10-MM6X18540.p33-GPL-(FP92) [ 77.154431] main_state = 3 [ 77.157287] ioctl_pending = 1 [ 77.160428] tx_pending = 0 [ 77.163285] wmm_tx_pending[0] = 0 [ 77.166783] wmm_tx_pending[1] = 0 [ 77.170291] wmm_tx_pending[2] = 0 [ 77.173790] wmm_tx_pending[3] = 0 [ 77.177288] rx_pending = 0 [ 77.180152] lock_count = 44 [ 77.183100] malloc_count = 49 [ 77.186231] mbufalloc_count = 0 [ 77.189554] hs_skip_count = 0 [ 77.192685] hs_force_count = 0 [ 77.195909] Media state ="Disconnected" [ 77.200059] carrier off [ 77.202641] tx queue 0: stopped [ 77.205956] tx queue 1: stopped [ 77.209279] tx queue 2: stopped [ 77.212595] tx 队列 3: stopped [ 77.215911] mlan0: num_tx_timeout = 0 [ 77.219799] -------- Dump info End--------- [ 77.237865] IPv6: ADDRCONF(NETDEV_UP): mlan0: link is not ready [ 77.270404] SDIO Func0 (0x0-0x9)：ERR [ 77.274349] SDIO Func1 (0x10-0x17)：ERR [ 77.278454] SDIO Func1: (0x8) ERR [ 77.282147] SDIO Func1 (0xe8-0xff)：ERR [ 77.387444] SDIO Func1 (0xe8-0xff)：ERR [ 77.391567] set pending clean [ 77.471612] SDIO Write ERR [ 77.474573] SDIO Write ERR [ 77.477436] ==== DEBUG MODE OUTPUT START: 77.469673 ==== [ 77.483111] SDIO Write ERR [ 77.485995] SDIO Write ERR [ 77.488871] ==== DEBUG MODE END ==== [ 77.492866] IOCTL 失败： a69aa9f8 id=0x20000, sub_id=0x20007 action=1, status_code=0x80000007 [CMD_CANCEL] (CMD_CANCEL) Re: IW611: Unable to setup Linux driver 你好@mlytvyn 您能试试 50MHz 的频率吗？ 顺祝商祺！ 肖恩 Re: IW611: Unable to setup Linux driver 我有 TI Sitara AM4376。 image.png image.png MMC 总线配置如下：   &mmc3 { status = "okay"; dmas = <&edma_xbar 30 0 1>, <&edma_xbar 31 0 2>; dma-names = "tx", "rx"; pinctrl-names = "default", "sleep"; pinctrl-0 = <&mmc3_pins_default>; pinctrl-1 = <&mmc3_pins_sleep>; vmmc-supply = <&dcdc4>; bus-width = <4>; cap-sdio-irq; ti,non-removable; max-frequency = <25000000>; /* slow down to 25MHz for bring-up */ }; MMC 总线控制器设法检测到 Wi-Fi 芯片，内核加载了正确的驱动程序，驱动程序使用提供的固件 blob 闪存了芯片，并从芯片中获得了固件版本。对我来说，这不像是 SDIO 配置问题，而像是与驱动程序（或 FW）有关的问题。 第一个错误发生在这里 [ 10.529596] IOCTL 失败： 1b0efb8f id=0x200000, sub_id=0x200046 action=1, status_code=0x3 [FW_CMDRESP] 司机在这个阶段要做什么？ 顺祝商祺！ 米哈伊洛 Re: IW611: Unable to setup Linux driver 你好@mlytvyn 您使用的是哪台主机？ 驱动程序加载和固件下载没有问题。 sdio 通信报告错误。 顺祝商祺！ 肖恩 Re: IW611: Unable to setup Linux driver 您好， 变化不大 mlytvyn_0-1780995812806.png 在这里，我启动了 mlan0，然后得到 mlytvyn_2-1780995954838.png mlytvyn_1-1780995851394.png 我遇到了同样的错误 IOCTL failed: 61e24fe7 id=0x200000, sub_id=0x200046 action=1, status_code=0x3 [FW_CMDRESP] 失败 Re: IW611: Unable to setup Linux driver 你好@mlytvyn 能否告诉我们您使用的是哪种 iw612 模块？还是您正在使用 iw612evk？我注意到你的 sd 接口是 3.3V，你匹配了 sdio 功率级吗？ 顺祝商祺！ 肖恩 Re: IW611: Unable to setup Linux driver 我使用的是 Silex SX-SDMAX 表面贴装版（https://www.silextechnology.com/connectivity-solutions/embedded-wireless/sx-sdmax）。据我所知，VIO 和 VIO_SD 上的电压决定了信号电平。 

FRDM Device Trees for Education and Rapid Prototyping To simplify development on the NXP FRDM board family, new device trees have been created for the i.MX91, i.MX93, i.MX95, and i.MX8MP platforms. These device trees are intended to provide a more ready to use out of the box experience by preconfiguring the Raspberry Pi connector with the same peripheral mapping commonly expected on Raspberry Pi compatible hardware. With this approach, developers, students, and makers can use compatible expansion boards and HAT style accessories more easily, without needing to create or significantly modify additional device tree files. Instead of spending time on low level hardware description updates, users can start evaluating peripherals and building applications directly on top of the provided configurations. For convenience, this post includes a .zip package containing: The compiled device tree binaries (.dtb) The device tree source files (.dts) The kernel patch for the NXP Linux Kernel 6.18 required to integrate these changes All files are attached to this post, allowing users to easily reuse, modify, or integrate the device trees into their own projects. To configure a new device tree, compile it, and flash it onto the target, you can refer to the following guides: How to compile Linux Kernel Image and device tree using Yocto SDK Flash customized Linux Kernel Image and device tree using UUU Tool

Polaris12 SMUファームウェアの起動中にAMDGPUが失敗する チームの皆さん、こんにちは。 弊社ではNXP T1040RBDボードを使用していますが、amdgpuドライバのロード中にPolaris12 SMUファームウェアの起動時にエラーが発生します。 以下にログファイルとカーネル設定ファイル、dtbファイルを示します。 amdgpu: メッセージ100の送信に失敗しました。戻り値は0です。 amdgpu: SMUファームウェアの起動に失敗しました！ amdgpu: SMUマイクロコードの読み込みに失敗しました。 amdgpu: ファームウェアのロードに失敗しました amdgpu: smuファームウェアの読み込みに失敗しました amdgpu 0001:01:00.0:amdgpu: amdgpu_device_ip_init が失敗しました amdgpu 0001:01:00.0:amdgpu: GPU初期化中に致命的なエラーが発生しました amdgpu 0001:01:00.0:amdgpu: amdgpu: デバイスの処理を完了します。 [drm:.gfx_v8_0_set_eop_interrupt_state[amdgpu]] 無効 me 2 [drm:.gfx_v8_0_set_eop_interrupt_state[amdgpu]] 無効 me 2 [drm:.gfx_v8_0_set_eop_interrupt_state[amdgpu]] 無効 me 2 [drm:.gfx_v8_0_set_eop_interrupt_state[amdgpu]] 無効 me 2 amdgpu: 0001:01:00.0 のプローブがエラー -22 で失敗しました Re: AMDGPU fails during Polaris12 SMU firmware startup こんにちは、 申し訳ありませんが、T1040 上の Polaris12 amdgpu 用の NXP ドライバ側の修正プログラムや既製のリポジトリは存在しません。そのため、動作させようとすると、お客様自身で SDKs カーネルを開発する必要があり、PCIe ウィンドウイングやエンディアンに関する重大なリスクを伴います。 よろしくお願いします。 Re: AMDGPU fails during Polaris12 SMU firmware startup こんにちは、 入手可能なドキュメントによると、T1040RDBはPCIeカードをホストできますが、AMD Polaris12 amdgpu 動作はサポートまたは検証されていません。この不具合は、既知のNXP PCIe起動修正ではなく、サポートされていないビッグエンディアンのPowerPCホストとの互換性の問題に起因する可能性が最も高いです。 よろしくお願いします。 Re: AMDGPU fails during Polaris12 SMU firmware startup こんにちは ドライバ側でこの問題を解決する方法はありますか？ よろしくお願いいたします。 ガネーシャ

S32K3 LPSPI 部件问题 你好，Nxp 专家： 如果使用 GPIO 引脚手动控制 LPSPI 芯片选择 (CS)，S32DS 配置工具中的 SpiCsPolarity 设置是否仍会对其产生影响？是否需要禁用工具中的 PCS（外设芯片选择）选择？另外，SpiHostRequest 参数的作用是什么？ focusdoit_0-1779058033130.png Re: S32K3 LPSPI pcs question 你好@focusdoit 如果使用 GPIO 引脚手动控制 LPSPI 芯片选择 (CS)，S32DS 配置工具中的 SpiCsPolarity 设置是否仍会对其产生影响？ 不，它不应该影响行为。 如果使用 GPIO 作为芯片选择，则需要对其进行控制。SpiCsPolarity 参数适用于由 LPSPI 外设管理的硬件控制 CS，不适用于 GPIO 控制信号。 是否需要禁用工具中的 PCS（外设芯片选择）选择？ 如果在 ConfigTools 中使用低级驱动器 (IP)，则只需将所需引脚配置为 GPIO，而无需配置任何 PCS 引脚。 对于高级驱动器（MCAL），除了将引脚配置为 GPIO 外，还有一个名为 SpiCsSelection 的参数。该参数应设置为 CS_VIA_GPIO。在这种情况下，驱动程序将使用通知（由节点 SpiJobStartNotification 和 SpiJobEndNotification 定义），通过 GPIO 控制每个 SPI 作业的 CS 引脚。 另外，SpiHostRequest 参数的作用是什么？ 在主模式下，此参数允许 LPSPI 模块仅在钳位主机请求输入时才开始新的 SPI 传输。如果 LPSPI 忙碌，主机请求输入将被忽略。 在从属模式下，当有数据可传输时，它会使 HREQ 输出引脚断言。 BR、VaneB

2026 年致命黑幕是否值得一试 我研究后对致命黑幕的诚实评论 随着越来越多的家庭在不依赖极端生存策略的情况下寻找切实可行的方法来为停电、电网故障和紧急情况做准备，致命停电在2026年越来越受到关注。该节目由退伍军人泰迪-丹尼尔斯（Teddy Daniels）制作，重点介绍切合实际的停电准备策略，采用简单的分步指导方式，专为普通家庭设计。 点击这里查看《致命黑夜》官方指南和最新详情： 致命黑夜》之所以脱颖而出，是因为它采用了适合初学者的方法。该指南没有提倡昂贵的掩体或极端的 “末日准备者” 策略，而是侧重于经济实惠的备灾方法，例如备用电力规划、储水、粮食安全、EMP保护和居家准备。许多人认为，这些信息被分解成简单的行动，可以在一段时间内切实执行。 了解 Fatal Blackout 如何运行以及系统包含哪些功能： 2026 年，对电网不稳定、网络攻击、通货膨胀和供应链中断的担忧已将备灾推向主流。Fatal Blackout 通过为那些希望在不完全改变生活方式的情况下做好更充分准备的人们提供结构化的生存路线图，从而激发了这种日益增长的兴趣。 那么，《致命黑夜》值得一试吗？对于那些正在寻找以现实为重点的实用备灾蓝图的人来说，该计划可以提供有用的见解和组织。然而，与任何生存系统一样，它的价值完全取决于用户在现实生活中是否真正坚持应用这些策略。   Re: Is Fatal Blackout Worth Trying in 2026 My Honest Fatal Blackout Review After Researching It 致命停电》在2026 年引起了广泛关注，因为越来越多的家庭正在寻找现实的方法来应对停电、电网中断和突发危机情况等紧急情况，而无需采用极端的求生方法。该计划由退伍军人泰迪·丹尼尔斯（Teddy Daniels）创建，围绕实用的停电准备策略构建，以清晰的分步形式呈现，适用于普通家庭。 访问《致命黑夜》官方网站，查看最新详情： 致命黑夜》脱颖而出的主要原因之一是其适合初学者的结构。该指南并不鼓励昂贵的掩体或紧张的 "末日准备者 "生活方式，而是强调经济实惠、可实现的准备步骤。其中包括备用电源规划、储水解决方案、粮食安全基础知识、EMP 意识和一般居家准备措施。用户通常非常重视如何将信息分解成简单、易于管理的行动，并随着时间的推移逐步实施。 fatal blackout guide tips.png 了解致命停电如何运作以及系统包括哪些内容： 2026 年，由于人们对电网可靠性、网络威胁、生活成本上升和供应链持续不确定性的担忧与日俱增，备灾已成为一个主流话题。F@@ atal Blackou t通过提供结构化框架来帮助个人和家庭在保持正常生活方式的同时，对应对潜在的干扰更有信心，从而与这种转变保持一致。 是的、 致命停电》对于那些寻求简单明了、结构合理的备灾指南的人来说是一个有用的选择的人来说，《致命黑色风暴》是一个有用的选择。它提供了明确的方向和实用的见解，其价值可以通过在日常生活中持续使用这些策略来实现，随着时间的推移，帮助用户逐步建立更强的居家准备和备灾信心。

无法订购 OM13089 我想订购 LpcXpresso54114 板零件 OM14089。该板的网页显示它仍处于活跃状态，但所有供应商都没有库存，而且似乎无法直接从恩智浦订购。 这个板怎么了？LPC54114 有不同的首选开发板吗？ LPC营销 Re: Unable to Order OM13089 你好@kk7xo、 谢谢您的帖子。 让我内部检查一下 OM13089 的状态。一旦有任何最新消息，我会尽快给您回复。 BR 西莱斯特 Re: Unable to Order OM13089 你好@kk7xo、 我确认 OM13089 没有过时，在我们的内部系统中，它仍处于激活状态。 但是由于运行率极低和成本限制，并且由于我们建议将所有新设计迁移到MCX平台，因此我们一直没有为该板补充库存。 这可能就是一些代理商在其网站上将其标记为 “过时” 的原因，尽管官方生命周期仍处于活动状态。 根据您当前的需求，我们建议迁移到 LPC54100 系列的 OM13077 板，或者使用可用的原理图文件自己构建电路板。很抱歉给您带来不便。 Celeste_Liu_0-1778665311592.png 祝您有美好的一天。 BR 西莱斯特

FIFAワールドカップ2026を視聴するための最適なIPTVサブスクリプション 2026年FIFAワールドカップに最適なIPTVサブスクリプションをお探しなら、 BekuTVは有力な選択肢の一つです。主要な試合中もバッファリングを最小限に抑え、安定したライブスポーツストリーミングを提供しているからです。 BekuTVがワールドカップのストリーミングに最適な理由： HD、FHD、4K対応のサッカーチャネル アンチバッファスポーツサーバー 低遅延で高速なチャネル切り替えが可能 国際スポーツ報道 Firestick、スマートテレビ、Android、iPhoneで動作します IPTV SmartersおよびTiviMateに対応 総合的に見て、BekuTVはFIFAワールドカップ2026を中断なくライブ視聴するための信頼できるIPTVオプションです。 Re: Best IPTV Subscription to Watch FIFA World Cup 2026 もちろん、完璧なストリーミングサービスは存在せず、パフォーマンスはインターネット速度、デバイスの構成、場所などの要因によって左右される可能性があります。しかし、私の個人的な経験に基づくと、 Nexus IPTVは、私が以前に試したいくつかの代替サービスよりも、より安定したサービスを提供してくれました。

无传感器 PMSM 现场导向控制 V2 我目前正在使用磁场定向控制与适用于 ARM Cortex M7F 的 amclib_pmsmbemfobsrvdQ 和 amclib_TrackobSRV 相结合，为 PMSM 实现无传感器控制。我有一台几千瓦的电机，轴上安装了一个机械速度传感器。我使用 2016 年 2 月 2 日的 DRM148 Rev.1 作为参考。 我希望实现这样一种情况，即在传感器闭环 FOC 的同时，观测器在后台并行运行，并提供正确的反馈信息，从而在稳态条件下，测量（传感器）速度和观测器估计速度趋于一致。回看图 23，从 DRM148 可以看出，在启动过程中，估计的观测器速度逐渐接近开环速度。 在 AMCLIB_PMSMBemfObsrvDQ 中，我使用传感器速度输出（转换为转子角速度）作为静止状态下 BEMF 观察器的输入（因此没有开环启动）。在 0 - 100 转/分钟的范围内，观测器是初始化的，而在速度为>100 转/分钟时，则使用反馈，不再使用初始函数。此外，所要求的电压 (Udq*) 和电流 (Idq*) 将用于 BEMF 观察器输入。我将 AMCLIB_TrackObsrv 输出的电子转子速度转换为每分钟的机械速度，并将其与实际的转子/传感器机械轴速度进行直观比较。这一切都以闭环方式进行（感应）。然而，AMCLIB_TrackObsrv 的输出速度在较长时间框架内仍无法收敛（例如>10 秒），同时保持转子速度恒定（例如500 RPM）。这是在空载状态下。当对电机轴施加负载时，观测器估计的机械速度会迅速降低。 在使用传感闭环控制时，造成真实传感器机械转速和估计观测器机械转速之间转速差异的可能原因是什么？ Re: Sensorless PMSM Field-Oriented Control V2 你好@ General_motor_control、 谢谢您的帖子。 请告诉我您使用的是恩智浦的哪种产品？是 i.MX RT 还是其他？ BR 西莱斯特 Re: Sensorless PMSM Field-Oriented Control V2 你好@ General_motor_control、 观测器速度与传感器速度不一致的原因可能有几个。 最常见的是观察者输入错误。DRM148 中的 BEMF 观察者预计的是实际施加的电压和测得的电流，而不是参考值（Udq*，Idq*）。该模型明确地依赖于电机电压方程（包括：±1.0V、±1.0V、±1.0V、±1.0V）。Rs·I + d²/dt)，因此命令电压和实际电压（死区时间、直流总线纹波、饱和）之间的任何不匹配都会导致稳定的误差。 有时还会出现参数不匹配（Rs、Ld/Lq、Ke）的情况。 该观测器基于模型，使用 RL 电流观测器 + BEMF 估算。 即使很小的 Rs 或电感误差也会导致估计的 BEMF 出现偏差，从而导致错误的速度。 还要注意比例/单位的不一致性。 DRM148 对所有量都使用定点分数缩放。 任何不匹配（电压、电流、速度正常化）都会导致缓慢漂移或偏移。 必须仔细检查缩放和极对转换。 希望能帮到你。 BR 西莱斯特