RT1160 带有外部同步动态随机存取存储器(SDRAM)和 SRAM，以及等待引脚 我正在使用 RT1160，搭配外部 16 位 同步动态随机存取存储器(SDRAM) 和 16 位 SRAM（用于 FPGA 通信）。SRAM 接口配置为异步模式下的 SRAM 读/写操作，并带有等待引脚。我怀疑等待信号是否会与同步动态随机存取存储器(SDRAM)刷新时序冲突，从而导致一些问题。我们测试过，让代码在同步动态随机存取存储器(SDRAM)中运行，并在 SRAM 异步写入时让等待引脚保持低电平约 10 毫秒或更长时间，但有时会在大约 1 毫秒后结束，不知道为什么。 我们可以这样使用吗？或者说同时使用同步动态随机存取存储器(SDRAM)和SRAM设备会有一些限制吗？感谢您的帮助。 Re: RT1160 with external SDRAM and SRAM with wait pin 你好 你提到的“大约1毫秒后结束”指的是什么？SRAM 写入操作是返回错误，还是进入硬故障？这种情况发生的频率如何？ 请问您能帮我测试一下以下功能吗？ 1. 从内部存储器（不是 同步动态随机存取存储器(SDRAM)）运行代码，并重复长时间异步 SRAM 写入。 2. 在仍然从内部存储器执行代码的情况下，再次运行相同的测试，但这次启用同步动态随机存取存储器(SDRAM)但使其处于空闲状态。 3. 按照你最初提到的方法运行测试，但要保持 SRAM 等待信号处于激活状态。 此外，能否在这些测试期间（包括上述提到的测试）检查以下内容？ 能否在传输过程中监控 SRAM 信号？ 能否分享一下每次测试的 SEMC INTR 寄存器值？ 请告诉我你的结果。 此致， 巴勃罗

外部供給クロック信号の電圧仕様（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 ハリー

AB SWAP question S32K312 软件停留在SRAM区域，看起来是HSE启动了Recovery mode，导致软件一直在WFI状态。 现在客户流程大体是boot_1-boot_2-app，会有两级跳入，boot_1不会进行更新。客户如果单独A区更新boot_2的时候，之后AB swap，reset调试没有问题。 但是发现A区单独更新APP时候，偶尔会AB swap 跳转不成功，reset后通讯正常。 这两天客户排查如下进展(图片截图比较多，还请查收如下邮件） 1.发现还是0X2040012e，对对应一个变量，查了DCMROD3/DCMROD4没有发现ECC错误。 2.和客户查如下进展，现在怀疑是进入recovery 模式 Re: AB SWAP question S32K312 嗨@scott071209 首先，以下是S32K3参考手册中列出的进入恢复模式的可能原因： lukaszadrapa_0-1781693464406.png 以下内容摘自 HSE FW 参考手册： lukaszadrapa_1-1781693472859.png 你们使用安全启动吗？ 两个分区中是否存在相同的 boot_1？两个分区中是否存在有效的 IVT？ RESET次数超过 8 次吗？你用示波器检查过RESET信号吗？ 请问您能否提供更多关于这句话的信息？ “但是，据观察，当在 A 区单独更新应用程序时，AB 交换转换偶尔会失败，尽管 RESET 后通信正常。” 它究竟是如何失效的？ 此致， Lukas

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

许可证到期 你好 我的 S32DS 3.4 许可证即将到期。能把这个延长吗？ Re: License Expiring 你好、 您的 S32DS 许可证已延期。

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 西莱斯特

IFC-NORブートモードを使用してLS2088ARDB上のQSPIフラッシュデバイスを有効化/アクセスする方法。 ハイ 1) LS2088ARDBはIFC-NORブートまたはQSPIブートで起動できます。 2) IFC-NORとQSPIは多重化されているため、一度に有効にできるのはどちらか一方のみです。 3) IFC/QSPIを選択するためのmux構成は、RCWデータに基づいてブートROMによって行われると私は考えています。 4)私の要件：IFC-NORブートモードで起動した後、LinuxでQSPIフラッシュにアクセスする必要があります。出来ますか ？もしそうであれば、QSPI Linuxのソースコードを提供していただけますか？ 5)LinuxレベルでQSPIを有効にするために、マルチプレクサの選択を再構成できますか（IFC-NORブートモードを考慮してください）？もしそうであれば、そのソースコードを提供していただけますか？ ありがとうございます。 Re: How to enable/access QSPI flash device on LS2088ARDB with IFC-NOR bootmode. こんにちは、 いいえ。LS2088ARDBでは、IFC-NORモードで起動した場合、後でLinuxからQSPIを有効にして使用することはできません。入手可能なLS2088A/Layerscapeのドキュメントによると、ピン多重化のためIFCとQSPIは相互に排他的であり、この多重化は実行時に動的に再構成されるのではなく、リセット時にRCWで構成されるとされています。LS2088Aに関して、NXPはピン多重化はRCWでのみ可能であり、「設計上、実行時にピン多重化を変更することは不可能である」と述べている。、 ブーツに関するあなたの理解は正しいです。 RCWソースは、リセット時にサンプリングされるリセット構成ピンによって選択されます。 プリブートローダーは、 cfg_rcw_src で指定されたソースから RCW をロードします。 LS2088クラスのボードでは、ブートソースの切り替えにはRCWの変更とボード上のスイッチ/ジャンパー設定の変更が必要になる場合があります。 LS2088/LS2044ファミリの動作に関して、NXPは明確に以下のことを確認しました。 「QSPIを使用する場合、IFC上で使用できるのはNANDコントローラのみとなります。」他のすべてのIFCマシンは、信号がQSPIインターフェースで使用するために多重化されているため、使用できません。」 LS2088Aの場合、ピン多重化はRCWで実装する必要があり、「実行時にピン多重化を変更することは不可能」です。 それでは、ご質問への直接的な回答は以下のとおりです。 LinuxはIFC-NORブートモードで起動した後でもQSPIフラッシュにアクセスできますか？ いいえ、通常のLS2088ARDB IFCブート構成ではそうではありません。IFCとQSPIは多重化されており、リセット時にRCW/ピン多重化装置によって選択が固定されます。、 Linuxは、IFC-NORブートモードを維持したまま、実行時にマルチプレクサの選択を再構成してQSPIを有効にすることができますか？ いいえ。取得した文書によると、このピン多重化はRCW専用であり、実行時に変更することはできないとのことです。 この多重化スイッチを行うためのLinuxソースコードを入手できますか？ LS2088A/Linux のソースコードや、実行時に IFC↔QSPI 多重化スイッチを行うためのドキュメント化されたメカニズムは見つかりませんでした。また、ハードウェアの動作から、そのような Linux 実装はサポートされていないことが示唆されます。、 一つ注意点があります。Layerscape Linuxのガイドによると、LS2088ARDBは異なるスイッチ/ジャンパー設定を使用してNORまたはQSPIから起動するように構成でき、起動デバイス構成を変更するとRCWまたはその他のイメージの変更が必要になる場合があると記載されています。これは、Linux の起動時スイッチではなく、起動/リセット時のハードウェア構成の選択であるという結論を裏付けています。   よろしくお願いします。 Re: How to enable/access QSPI flash device on LS2088ARDB with IFC-NOR bootmode. ありがとう。これで私の疑問は解消されました。