PN7160A 和 linux_libnfc-nci 在 Raspberry Pi 5 2026 64 位 Trixie 系统上运行 你好， 我正在尝试为工作项目启动 PN7160A，但始终无法让 linux_libnfc-nci 正常工作。该补丁已过时，lgpiod 在版本 2 中进行了全面改进。 还需要使用标志 sudo make install CFLAGS="-Wno-error=implicit-function-declaration" " 否则我就会 "demoapp/main.c:在函数“onMessageReceived”中： demoapp/main.c:451:5:错误：隐式声明函数“PrintNDEFContent” [-Wimplicit-function-declaration] 451 | PrintNDEFContent(NULL, NULL, message, length); 我找到了 2025 年关于 PN7150 的一篇旧帖子，但是当我尝试编译时，我遇到了奇怪的错误，例如“uint8_t”未在作用域中声明，请使用 。我的树莓派操作系统是最新的Trixie Debian 13.6。 需要一些帮助，谢谢。 Re: PN7160A and linux_libnfc-nci on Raspberry Pi 5 2026 64-bit Trixie 你好@paulwitulski 请将补丁作为附件应用。

需要帮助查找适用于 i.MX95 内核版本 (v6.6.52-2.2.0) 的 Neutron 变流器 SDK。 您好，NXP团队， 我目前正在使用 LF_v6.6.52-2.2.2_images_IMX95 ，并且我正在尝试确定 Neutron Converter SDK 的正确版本，以便将 TensorFlow Lite INT8 量化 模型 转换 为 NPU 格式。 我尝试过多个版本的 Neutron 变流器 SDK，但每次尝试都出现以下错误： 信息：NeutronDelegate 委托：27 个节点中有 1 个节点被委托，共 1 个分区。 信息：已为 CPU 创建 TensorFlow Lite XNNPACK 委托。 警告：微代码版本不匹配！0x359f358d（预期为 0xa186aaf2） 警告：微代码版本不匹配！0x359f358d（预期为 0xa186aaf2） 推理轮询超时 错误：元器件='Neutron Driver'，类别='超时'，代码=754 回溯（最近一次调用）： 文件“/home/object_detc/main.py”，第 80 行，在 中 解释器.调用() 文件“/usr/lib/python3.12/site-packages/tflite_runtime/interpreter.py”，第 941 行，在 invoke 中 self._interpreter.Invoke() RuntimeError: /usr/src/debug/tensorflow-lite-neutron-delegate/2.16.2/neutron_delegate.cc:355 neutronRC != ENONE (193099 != 0)节点编号 27 (NeutronD. 能否解释一下为什么移除了对LF_v6.6.52-2.2.2_images_IMX95的支持？是因为该电路板支持包仍被视为 alpha 版本吗？ 请问您能否也就以下问题提供一些建议： 是否可以将 Neutron 变流器 SDK 与此内核/电路板支持包 版本一起使用？ 如果是这样，那么哪个版本的 Neutron 变流器 SDK 与 LF_v6.6.52-2.2.2_images_IMX95 兼容 ？ 如果没有，是否有其他版本的 eIQ 工具或不同的工作流程可以与此 BSP 一起使用？ 感谢您的帮助。期待您的指导。 疑似软件缺陷 Re: Need help to find Neutron Converter sdk for i.MX95 kernel version (v6.6.52-2.2.0) 你好@boopathi123 ， 感谢您联系恩智浦技术支持！ 看来您使用的是非常早期的芯片版本。在这种情况下，我建议使用 eIQ 工具包中包含的 Neutron 变流器。但是请注意，此 BSP 版本并未得到 i.MX95 的官方支持。 i.MX95 正式发布，采用 B0 硅版本和 BSP 6.12.34。早期的硅片版本旨在用于评估和预生产目的，因此可能无法提供与当前支持的设备相同的功能、稳定性、兼容性或性能。 因此，我强烈建议迁移到以下受支持的组合： i.MX95 B0 硅 BSP 6.12.34 或更高版本 使用受支持的软件和硬件配置将确保您能够享受到 i.MX95 平台的最新修复、优化和 NPU 软件支持。 你观察到的现象可能与早期硅片版本中的局限性或已知问题有关，而不是与模型本身有关。 此致， 查维拉

NXP iMX8MP: U-Boot内のWFIベースのCPUアイドル状態が復帰しない 親愛なるNXPサポートチームへ、 私たちはi.MX8M Plusベースの製品向けにU-Bootの低消費電力待機メカニズムを調査しており、NXPからの指導を歓迎する段階に達しています。 ソフトウェアのバージョン SoC: NXP i.MX8M Plus BSP: ATF: lf_v2.10_android-15.0.0_1.2.0 U-Boot: lf_v2024.04_android-15.0.0_1.2.0 公開されているNXP BSPに基づいています（Varisciteフォークには、ATF/GICコードパスに関する重要な変更は含まれていません）。 ゴール アプリはAndroidを起動する前に、バッテリーが完全に放電された状態で数分間U-Bootに留まっている必要があります。 mdelay()に基づくビジーループは不必要な電力を消費し、追加の熱を発生させるため、ARMジェネリックタイマー(CNTP, PPI 30)を使って定期的に低消費電力のアイドル状態とウェイクに入ろうとしています。 初期実装 CNTPタイマーの設定 PPI 30を有効にする EL2から生のwfi()を実行する プロセッサはwfi()から決して起動しません。UARTの出力は、例外やクラッシュもなく、単に停止するだけです。 PSCIの実装 PSCI_VERSIONは1.1を返します。 PSCI_FEATURES(CPU_SUSPEND) は 0 を返します (サポートされています) CPU_SUSPENDを呼び出してスタンバイ電源状態を要求します これにより、ATFスタンバイ実装であるimx_cpu_standby()に到達しますが、システムは全く同じようにハングアップします。例外も発生せず、UART出力もなく、実行は再開されません。 したがって、両方とも： EL2で実行されたraw wfi() wfi() は ATF を介して PSCI で実行されます 全く同じ動作を生み出す。 既に検証済みのもの CPUとタイマー U-BootはEL2上で実行されます。 CNTPタイマーは正しくプログラムされています。 CNTP_TVAL_EL0 は正しくカウントダウンします。 CNTP_CTL_EL0 には以下が表示されます。 有効 = 1 IMASK = 0 武装直後のISTATUSは0です。 CPUインターフェース ICC_PMR_EL1は正しく設定されています。 ICC_IGRPEN1_EL1が有効になっています。 仮想化 HCR_EL2には以下が含まれます： IMO = 0 FMO = 0 したがって、EL2仮想化による割り込みルーティングは関与しません。 割り込みセキュリティ分類 ATFの情報筋から以下のことを確認しました。 すべてのPPIは、汎用GICv3ヘルパーコードによって最初にグループ1非セキュアとして設定されます。 SGI8 (およびオプションで SDEI SGI) のみがセキュアとして再構成されます。 PPI 30 はセキュア割り込みプロパティテーブルに存在しません。 したがって、Generic Timer 割り込みは予想通りグループ1非安全のままのままです。 SCR_EL3.TWE 当初、非セキュアな wfi() が SCR_EL3.TWE を介して EL3 にトラップされるのではないかと疑っていましたが、wfi() が PSCI を介して ATF 自体の中で実行された場合にも同じ動作が発生するため、これは可能性が低いと思われます。 追加調査 ATFのGIC初期化を追跡していると、gicv3_distif_init()がDistributor EnableGrpビットをクリアし、セキュア割り込みプロパティテーブルで要求されたビットのみを再有効化していることに気付きました。 ヘルパーは Group0 と Group1 の Secure プロパティのみを生成するため、EnableGrp1NS が明示的に再度有効になることはないようです。 これを検証するために、我々は以下のことを行いました。 GICD_CTLR を読み込む EnableGrp1NS = 0 を観測しました EL2からEnableGrp1NSを独自に設定しようと試みました。 意外なことに： 書き込みは問題なく完了します。 RWPは正常に動作します。 しかし、読み戻し後もEnableGrp1NSは0のままです。 また、以下の点も確認しました。 GICD_CTLR.DS == 0 GICメモリ領域に対するRDC保護は無効になっています（ENA = 0）。 RDC違反記録はゼロのままです。 したがって、RDCは書き込みを妨げていないようです。 残りの疑問 現時点で、以下の項目を除外しました。 タイマープログラミング、 CPUインターフェース構成、 割り込み優先度マスキング、 割り込みグループ分類、 SCR_EL3.TWE トラッピング、 PSCIと生のWFI実行の比較、 RDC保護。 残された説明のつかない挙動は、アーキテクチャ的に非安全な書き込み可能なディストリビュータ制御ビット(EnableGrp1NS)がこのプラットフォーム上で書き込みを受け入れていないようで、その結果、生のwfi()もPSCIもGeneric Timer割り込みで起動CPU_SUSPENDしないことです。 この動作はi.MX8M Plus Android 15 BSPで予想されるのでしょうか? 汎用タイマーPPIがwfi()からCPUを起動させるために、公開ATFソース以外でプラットフォーム固有の初期化が欠けているのでしょうか? EnableGrp1NSは、このプラットフォーム上で安全でないソフトウェアによる変更を意図的に防いでいるのでしょうか? U-Bootから定期的にウェイクアップする機能を、以下のいずれかの方法で実装することに成功した人はいますか？ 生のwfi()、または PSCI CPU_SUSPEND ARMのジェネリックタイマーで動かされているのか? 初期化シーケンスやプラットフォーム固有の動作についてのご意見をいただけると大変ありがたいです。 よろしくお願いします。 よろしくお願いいたします。 桟橋

MCUX 25.6.136、newlib-nano、& swprintf 未定義 MCUX 25.6.136でswprintfへの未定義参照が発生しています。& newlib-nano。newlibも試してみましたが、結果は同じでした。 いろいろ調べてみたところ、newlib-nano/newlib に上流の問題が見つかりました。https: //sourceware.org/pipermail/newlib/2024/021012.html NXPが私の推測を裏付けてくれるか気になっています。Newlib-nanoのバンドル版にもこの問題があるのではないかと。もしそうなら、newlib-nano/newlibの新しいバージョンを取り入れて修正する案は考えられていますか? - コナー

MD8LC925NR1アンプのバイアス調整方法を教えてください。 こんにちは、 現在、 MD8LC925NR1パワーアンプを使用したシステムを設計中です。適切な バイアス回路や専用の電源管理部品 をおすすめしていただけるとありがたいです。 この目的のために推奨されるリファレンス・デザイン、アプリケーションノート、または具体的な部品番号を教えていただけますか? ご協力ありがとうございました。 Re: How to bias the amp MD8LC925NR1? こんにちは、 NXPセミコンダクターズの製品にご関心をお寄せいただき、またサポートの機会をいただきありがとうございます。 記載されている部品番号に誤植があるようです。MDL8LC925NR1は、NXPの有効な注文可能部品番号ではありません。最も近い類似デバイスはMD8IC925Nです。このデバイスは現在、販売終了（EOL）となっており、サポートが終了しているため、新規購入はできませんのでご注意ください。 以下のNXP文書は、回路回路図、部品リスト、特性評価データを含む詳細な設計情報を提供しています。 MD8IC925N データシート AN1977 – RF集積回路ファミリにおける静止電流熱追尾回路 AN1987 – RF集積回路デバイスファミリ向けクイセント電流制御(両方のバイアス回路トポロジーと完全な部品リストを含む) AN1955 – RFパワーアンプの熱測定手法 残念ながら、MD8IC925Nの直接的な代替品は存在しません。さらに、 100MHzから1000MHz 帯をカバーする多くのRF製品はEOLに近づいており、現時点では新しい代替機器の発表はありません。 お客様の周波数、電力、供給電圧に関する具体的な要件に基づき、代替ソリューションの特定についてサポートが必要な場合は、お知らせください。 よろしくお願いいたします。

.mexファイル内の警告ファイル （自動生成された）.mexファイル内プロジェクト用のファイルでは、各ペリフェラルは次のような内容です: 1.0.0 「説明」属性の文言に注目してください。他のペリフェラルについては状況が異なりますが、ほとんどの場合、警告やエラーメッセージのようなものです。プロジェクトは正常にコンパイルされ、実行されます。 関連して、『ペリフェラルビュー』から新しいソフトウェアコンポーネントを追加しようとすると、現在選択されていないペリフェラルが黄色い感嘆符でマークされています。添付のスクリーンショットをご覧ください。マウスカーソルをそれらの上に重ねると、「description」属性に表示されているのと同じメッセージが表示されます。しかし、私は問題なくそれらを追加できます。 これらの警告は何に関するものですか？

Need help to find Neutron Converter sdk for i.MX95 kernel version (v6.6.52-2.2.0) Hello NXP Team, I am currently using LF_v6.6.52-2.2.2_images_IMX95 and I'm trying to identify the correct version of the Neutron Converter SDK to convert a TensorFlow Lite INT8 quantized model for the NPU. I have tried multiple versions of the Neutron Converter SDK, but every attempt results in the following error: INFO: NeutronDelegate delegate: 1 nodes delegated out of 27 nodes with 1 partitions. INFO: Created TensorFlow Lite XNNPACK delegate for CPU. Warning: microcode version mismatch! 0x359f358d (expected 0xa186aaf2) Warning: microcode version mismatch! 0x359f358d (expected 0xa186aaf2) Inference poll timeout Error: component='Neutron Driver', category='timeout', code=754 Traceback (most recent call last): File "/home/object_detc/main.py", line 80, in interpreter.invoke() File "/usr/lib/python3.12/site-packages/tflite_runtime/interpreter.py", line 941, in invoke self._interpreter.Invoke() RuntimeError: /usr/src/debug/tensorflow-lite-neutron-delegate/2.16.2/neutron_delegate.cc:355 neutronRC != ENONE (193099 != 0)Node number 27 (NeutronD. Could you clarify why support for LF_v6.6.52-2.2.2_images_IMX95 was removed? Is this because the BSP is still considered an alpha release? Could you also please advise on the following: Is it possible to use the Neutron Converter SDK with this kernel/BSP version? If so, which version of the Neutron Converter SDK is compatible with LF_v6.6.52-2.2.2_images_IMX95? If not, is there another version of the eIQ tools or a different workflow that should be used with this BSP? Thank you for your help. I look forward to your guidance. Suspected Software Defect Re: Need help to find Neutron Converter sdk for i.MX95 kernel version (v6.6.52-2.2.0) Hi @boopathi123, Thank you for contacting NXP Support! It appears that you are using a very early silicon revision. In that case, I recommend using the Neutron Converter included with the eIQ Toolkit. However, please note that this BSP version is not officially supported for the i.MX95. The i.MX95 was officially released with the B0 silicon revision and BSP 6.12.34. Earlier silicon revisions were intended for evaluation and pre production purposes, and therefore may not provide the same level of functionality, stability, compatibility, or performance as the currently supported devices. For this reason, I strongly recommend migrating to a supported combination of: i.MX95 B0 silicon BSP 6.12.34 or later Using a supported software and hardware configuration will ensure that you benefit from the latest fixes, optimizations, and NPU software support available for the i.MX95 platform. The behavior you are observing may be related to limitations or known issues present in the early silicon revisions rather than the model itself. Best regards, Chavira

NXP iMX8MP: WFI-based CPU idle in U-Boot never wakes Dear NXP Support Team, We are investigating a low-power waiting mechanism in U-Boot for a i.MX8M Plus based product and have reached a point where we would appreciate guidance from NXP. Software versions SoC: NXP i.MX8M Plus BSP: ATF: lf_v2.10_android-15.0.0_1.2.0 U-Boot: lf_v2024.04_android-15.0.0_1.2.0 Based on the public NXP BSP (Variscite fork contains no relevant modifications in the ATF/GIC code paths) Goal The application needs to remain in U-Boot for several minutes while a deeply discharged battery charges before Android is started. A busy-loop based on mdelay() consumes unnecessary power and generates additional heat, so we are trying to periodically enter a low-power idle state and wake using the ARM Generic Timer (CNTP, PPI 30). Initial implementation configure CNTP timer enable PPI 30 execute a raw wfi() from EL2 The processor never wakes from wfi(). UART output simply stops with no exception or crash. PSCI implementation PSCI_VERSION returns 1.1 PSCI_FEATURES(CPU_SUSPEND) returns 0 (supported) invoke CPU_SUSPEND requesting the Standby power state This reaches the ATF standby implementation imx_cpu_standby(), but the system hangs in exactly the same way: no exception, no UART output, and execution never resumes. Therefore, both: raw wfi() executed at EL2 wfi() executed through ATF via PSCI produce identical behavior. What have been already verified CPU and timer U-Boot executes at EL2. CNTP timer is correctly programmed. CNTP_TVAL_EL0 counts down correctly. CNTP_CTL_EL0 shows: ENABLE = 1 IMASK = 0 ISTATUS = 0 immediately after arming. CPU interface ICC_PMR_EL1 is configured correctly. ICC_IGRPEN1_EL1 is enabled. Virtualization HCR_EL2 has: IMO = 0 FMO = 0 so interrupt routing through EL2 virtualization is not involved. Interrupt security classification From the ATF sources we verified that: all PPIs are initially configured as Group 1 Non-secure by the generic GICv3 helper code, only SGI8 (and optionally SDEI SGIs) are reconfigured as Secure, PPI 30 is **not** present in the secure interrupt property table. Therefore the Generic Timer interrupt appears to remain Group 1 Non-secure as expected. SCR_EL3.TWE We originally suspected that non-secure wfi() might be trapped to EL3 via SCR_EL3.TWE, but this now seems unlikely because the same behavior occurs when wfi() is executed inside ATF itself through PSCI. Additional investigation While tracing the ATF GIC initialization we noticed that gicv3_distif_init() clears the Distributor EnableGrp bits and only re-enables those requested by the secure interrupt property table. Since the helper only produces Group0 and Group1 Secure properties, it appears that EnableGrp1NS is never explicitly re-enabled. To verify this we: read GICD_CTLR observed EnableGrp1NS = 0 attempted to set EnableGrp1NS ourselves from EL2. Unexpectedly: the write completes without fault, RWP behaves normally, but EnableGrp1NS remains 0 after readback. We also verified: GICD_CTLR.DS == 0 RDC protection for the GIC memory regions is disabled (ENA = 0) RDC violation registers remain zero. Therefore RDC does not appear to be preventing the write. Remaining question At this point we have eliminated: timer programming, CPU interface configuration, interrupt priority masking, interrupt group classification, SCR_EL3.TWE trapping, PSCI vs raw WFI execution, RDC protection. The remaining unexplained behavior is that an architecturally Non-secure writable Distributor control bit (EnableGrp1NS) does not appear to accept writes on this platform, and consequently neither raw wfi() nor PSCI CPU_SUSPEND ever wake using the Generic Timer interrupt. Is this behavior expected on the i.MX8M Plus Android 15 BSP? Is there any platform-specific initialization missing outside the public ATF sources that is required before the Generic Timer PPI can wake a CPU from wfi()? Is EnableGrp1NS intentionally prevented from being modified by non-secure software on this platform? Has anyone successfully implemented periodic wake-up from U-Boot using either: raw wfi(), or PSCI CPU_SUSPEND  driven by the ARM Generic Timer? Any insight into the expected initialization sequence or platform-specific behavior would be greatly appreciated. Thanks Best Regards Pier

i.MX95カーネルバージョン(v6.6.52-2.2.0)用のNeutron Converter SDKを探すのに助けが必要です NXPチームの皆様、こんにちは。 現在 は LF_v6.6.52-2.2.2_images_IMX95 を使っており、 TensorFlow LiteのINT8量子化 モデルをNPU用 に 変換するための 正しい Neutron コンバータ SDK のバージョンを特定しようとしています 。 Neutron Converter SDKsの複数のバージョンを試しましたが、毎回以下のエラーが発生します。 INFO: NeutronDelegate デリゲート: 27 ノードのうち 1 ノードが委任され、1 つのパーティションがあります。 情報: CPU 用の TensorFlow Lite XNNPACK デリゲートを作成しました。 警告：マイクロコードのバージョンが一致しません！0x359f358d（期待値：0xa186aaf2） 警告：マイクロコードのバージョンが一致しません！0x359f358d(予想された0xa186aaf2) 推論調査のタイムアウト エラー:コンポーネント='Neutron Driver'、カテゴリ='タイムアウト'、コード=754 トレースバック(直近の通話): ファイル「/home/object_detc/main.py」、 interstructer.invoke() ファイル "/usr/lib/python3.12/site-packages/tflite_runtime/interpreter.py",インヴォークの941行 self._interpreter。Invoke() RuntimeError: /usr/src/debug/tensorflow-lite-neutron-delegate/2.16.2/neutron_delegate.cc:355 neutronRC != ENONE (193099 != 0) ノード番号27 (NeutronD. なぜ LF_v6.6.52-2.2.2_images_IMX95 のサポートが削除されたのか 、詳しく教えていただけます か?これはBSPがまだアルファ版とみなされているからでしょうか? 以下の点についてもアドバイスいただけますか: このカーネル/BSPバージョンでNeutron Converter SDKを使うことは可能でしょうか? もしそうなら、どのバージョンのNeutron Converter SDKがLF_v6.6.52-2.2.2_images_IMX95に対応しているのでしょうか? そうでない場合、このBSPで使用するべきeIQツールの別のバージョン、または別のワークフローはありますか？ 助けてくれてありがとう。ご指導を心よりお待ちしております。 ソフトウェア不具合の疑い Re: Need help to find Neutron Converter sdk for i.MX95 kernel version (v6.6.52-2.2.0) こんにちは、@boopathi123。 NXPサポートにご連絡いただきありがとうございます! お使いのチップは非常に初期のシリコンリビジョンのようです。その場合は、eIQ Toolkitに付属しているNeutronコンバーターの使用をおすすめします。ただし、このBSPバージョンはi.MX95では公式にはサポートされていないことにご注意ください。 i.MX95は、B0シリコンリビジョンとBSP 6.12.34で正式にリリースされました。以前のシリコン改訂版は評価および量産前の目的で作成されたため、現在サポートされているデバイスと同等の機能性、安定性、互換性、または性能を提供しない可能性があります。 そのため、以下のサポート対象の組み合わせへの移行を強くお勧めします。 i.MX95 B0シリコン BSP 6.12.34以降 対応するソフトウェアとハードウェア構成を使用することで、i.MX95プラットフォーム向けの最新の修正、最適化、NPUソフトウェアのサポートを享受できます。 あなたが観察している挙動は、モデル自体ではなく、初期シリコン改良版に存在した制限や既知の問題に関連している可能性があります。 よろしくお願いします、 チャビラ

如何调整功放MD8LC925NR1的偏置电压？ 你好， 我们目前正在设计一个使用MD8LC925NR1功率放大器的系统。我们恳请您推荐合适的偏置电路或专用电源管理元器件，以便为该功率放大器提供正确的偏置。 请问您能否提供一些推荐的参考设计、应用笔记或具体零件编号？ 谢谢你的帮助。 Re: How to bias the amp MD8LC925NR1? 你好， 感谢您对恩智浦半导体产品的关注，也感谢您给我们提供支持的机会。 提供的零件编号似乎有误。MDL8LC925NR1不是 NXP 可订购的有效零件编号。最接近的匹配设备是MD8IC925N。请注意，该设备目前已停产，这意味着它不再受支持，也不再接受新的购买。 以下NXP文档提供了详细的设计信息，包括电路原理图、元器件清单和特性数据： MD8IC925N 数据手册 AN1977 –射频集成电路系列中的静态电流热跟踪电路 AN1987 – 射频集成电路设备系列的静态电流控制（包括两种偏置电路拓扑结构及完整的元器件清单） AN1955 – 射频功率放大器的热测量方法 遗憾的是，MD8IC925N 没有直接的替代品。此外，许多涵盖100 MHz 至 1000 MHz频率范围的射频产品即将停产，目前还没有宣布推出新的替代设备。 如果您需要我们根据您的具体频率、功率和供电电压要求，协助您寻找替代解决方案，请与我们联系。 顺祝商祺！

MCUX 25.6.136, newlib-nano, & swprintf undefined I'm experiencing an undefined reference to swprintf with  MCUX 25.6.136 & newlib-nano. I've tried newlib as well and same result.  After some digging I've found an upstream issue with newlib-nano/newlib: https://sourceware.org/pipermail/newlib/2024/021012.html  I'm wondering if NXP can corroborate my guess that the bundled version of newlib-nano contains this issue. If that's the case Is a fix via incorporating a newer version of newlib-nano/newlib on the agenda? - Connor

NXP iMX8MP：基于WFI的CPU在U-Boot中处于空闲状态时不会唤醒 尊敬的恩智浦技术支持团队： 我们正在研究基于 i.MX8M Plus 的产品的 U-Boot 中的低功耗等待机制，现在我们希望得到 NXP 的指导。 软件版本 SoC：NXP i.MX8M Plus BSP： ATF：lf_v2.10_android-15.0.0_1.2.0 U-Boot：lf_v2024.04_android-15.0.0_1.2.0 基于公开的 NXP 电路板支持包（Variscite 分支对 ATF/GIC 代码路径没有相关的修改） 目标 在 Android 系统启动之前，应用程序需要在 U-Boot 模式下停留几分钟，以便为深度放电的电池充电。 基于 mdelay() 的忙循环会消耗不必要的功率并产生额外的热量，因此我们正在尝试定期进入低功耗空闲状态，并使用 ARM 通用定时器 (CNTP, PPI 30) 唤醒。 初始实施 配置 CNTP 定时器 启用 PPI 30 从 EL2 执行原始 wfi() 处理器永远不会从 wfi() 中唤醒。UART 输出突然停止，没有任何异常或崩溃。 PSCI 实现 PSCI_VERSION 返回 1.1 PSCI_FEATURES(CPU_SUSPEND) 返回 0（支持） 调用 CPU_SUSPEND 请求进入待机电源状态 程序会执行 ATF 备用程序实现 imx_cpu_standby()，但系统会以完全相同的方式挂起：没有异常，没有 UART 输出，执行永远不会恢复。 因此，两者： 在 EL2 级别执行原始 wfi() 函数 wfi() 通过 ATF 经由 PSCI 执行 产生相同的行为。 已经核实的内容 CPU 和定时器 U-Boot 在 EL2 层执行。 CNTP定时器已正确编程。 CNTP_TVAL_EL0 倒计时正常。 CNTP_CTL_EL0 显示： 启用 = 1 IMASK = 0 布防后，ISTATUS = 0。 CPU接口 ICC_PMR_EL1 配置正确。 ICC_IGRPEN1_EL1 已启用。 虚拟化 HCR_EL2 具有： IMO = 0 FMO = 0 因此，中断路由不会通过 EL2 虚拟化进行。 中断网络安全分类 我们从美国烟酒枪炮及爆炸物管理局（ATF）的消息来源证实： 所有PPI最初都由通用GICv3辅助代码配置为第1组非安全设备。 只有 SGI8（以及可选的 SDEI SGI）被重新配置为安全模式。 PPI 30 不在安全中断属性表中。 因此，通用定时器中断似乎仍如预期那样保持为第 1 组非安全状态。 SCR_EL3.TWE 我们最初怀疑不安全的 wfi() 可能会通过 SCR_EL3.TWE 被困到 EL3，但现在看来不太可能，因为当 wfi() 通过 PSCI 在 ATF 内部执行时，也会发生同样的行为。 进一步调查 在跟踪 ATF GIC 初始化时，我们注意到 gicv3_distif_init() 会清除 Distributor EnableGrp 位，并且只会重新启用安全中断属性表请求的那些位。 由于该辅助程序只生成 Group0 和 Group1 Secure 属性，因此 EnableGrp1NS 似乎永远不会被显式地重新启用。 为了验证这一点，我们： 读取 GICD_CTLR 观察到 EnableGrp1NS = 0 尝试从 EL2 自行设置 EnableGrp1NS。 不料： 写入操作顺利完成，没有出现任何错误。 RWP运行正常 但读取后 EnableGrp1NS 仍然为 0。 我们还核实了： GICD_CTLR.DS == 0 GIC 内存区域的 RDC 保护已禁用（ENA = 0） RDC违规登记数量仍为零。 因此，RDC 似乎并没有阻止写入操作。 剩余问题 至此，我们已经排除了： 定时器编程 CPU接口配置， 中断优先级掩码 中断组分类， SCR_EL3.TWE 捕获， PSCI 与原始 WFI 执行方式对比， RDC保护。 剩下的未解释的行为是，架构上不安全的可写分发器控制位（EnableGrp1NS）似乎不接受此平台上的写入，因此原始 wfi() 和 PSCI CPU_SUSPEND 都无法使用通用定时器中断唤醒。 i.MX8M Plus Android 15 电路板支持包。 出现这种现象是否正常？ 在公共 ATF 源代码之外，是否存在任何平台特定的初始化缺失，导致通用定时器 PPI 无法通过 wfi() 唤醒 CPU？ EnableGrp1NS 是否被有意阻止在此平台上被不安全的软件修改？ 有没有人成功地使用以下两种方法之一实现了从 U-Boot 定期唤醒： 原始 wfi()，或 PSCI CPU_SUSPEND 由 ARM 通用定时器驱动？ 非常感谢您能提供任何关于预期初始化顺序或平台特定行为的见解。 谢谢！ 顺祝商祺！ 码头

.mex 文件中的警告文件 在（自动生成的）.mex 文件中项目文件中，每个外设的内容大致如下： 1.0.0 请注意“描述”属性中的措辞。对于其他外围设备，情况各不相同，但几乎总是会显示警告或错误消息之类的信息。项目编译和运行都没问题。 另外，如果我尝试从“外围设备视图”添加新的软件组件，所有当前未选择的外围设备都会被标记为黄色感叹号，请参见附件屏幕截图。如果我将鼠标悬停在它们上面，就会得到与“描述”属性中显示的相同的消息。但我添加它们没有任何问题。 这些警告是关于什么的？

How to bias the amp MD8LC925NR1? Hello, We are currently designing a system using the MD8LC925NR1 Power Amplifier. We would appreciate your recommendation for a suitable bias circuit or a dedicated power management component to properly bias this PA. Could you please provide any reference designs, application notes, or specific part numbers that you recommend for this purpose? Thank you for your assistance. Re: How to bias the amp MD8LC925NR1? Hello, Thank you for your interest in NXP Semiconductors products and for the opportunity to support you. There appears to be a typo in the part number provided. MDL8LC925NR1 is not a valid NXP orderable part number. The closest matching device is MD8IC925N. Please note that this device is currently End of Life, meaning it is no longer supported and is no longer available for new purchases. The following NXP documents provide detailed design information, including circuit schematics, component lists, and characterization data: MD8IC925N Datasheet AN1977 – Quiescent Current Thermal Tracking Circuit in the RF Integrated Circuit Family AN1987 – Quiescent Current Control for the RF Integrated Circuit Device Family (includes both bias circuit topologies with complete component lists) AN1955 – Thermal Measurement Methodology of RF Power Amplifiers Unfortunately, there is no direct replacement available for the MD8IC925N. In addition, many RF products covering the 100 MHz to 1000 MHz frequency range are approaching EOL status, and no new replacement devices have been announced at this time. Please let us know if you would like assistance identifying alternative solutions based on your specific frequency, power, and supply voltage requirements. Best regards

MCUX 25.6.136，newlib-nano，& swprintf 未定义 我在使用 MCUX 25.6.136 时遇到了对 swprintf 的未定义引用问题。& newlib-nano。我也试过newlib，结果一样。 经过一番调查，我发现 newlib-nano/newlib 存在一个上游问题： https://sourceware.org/pipermail/newlib/2024/021012.html 我想知道 NXP 能否证实我的猜测，即捆绑的 newlib-nano 版本存在这个问题。如果情况确实如此，那么通过引入更新版本的 newlib-nano/newlib 来修复这个问题是否已提上日程？ 康纳

XIP FLASHリマップを有効にした状態でイメージスワップ後にMCUBootイメージをデバッグ/フラッシュする 皆さん、 なぜ特定の状況でフラッシュドライバーが故障するのか、何か理由があるのか教えてほしいです。 私たちはカスタムボードをIMXRT1176に使っています。このMCUのボードはEmbedded Artistsのキャリアボードをベースにしています。私たちのプロジェクトでは、フラッシュメモリに0x30100000と0x30200000の2つのパーティションがあります。私たちはMCU-LinkとLinkserverを使ってバイナリをフラッシュしています。バイナリは-この場合確認された署名です。FLASHのリマップ機能を有効にしているので、スワップは行われません。 我々は2つの状況を観察する。 1.フラッシュメモリにブートローダーがあり、パーティション1にイメージファイルがあれば、すべて正常に動作します。 2. OTAアップグレードを完了し、MCUbootが2つ目のパーティションから新しいイメージを起動すると、linkserverからエラーが出るため、FLASHパート1への書き込みができません。 ================================================= NC:フラッシュドライバーの起動 MIMXRT1170_SFDP_QSPI.cfx(すでに常駐中) NC:フラッシュドライバーを実行するためにVECTRESETを送信中 Nc: フラッシュバリアント「iMXRT1170_SFDP_FlexSPI1_A_QSPI 2026年5月15日 18:32:39」検出(16MB = 256*64K 0x30000000) Pb: 1/1(0) 0x30100000でセクター16-31を1048576バイトで書き込み 追伸:(0) 30100000 で:0バイト - 0/1048576 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) ステータス 0x1 - ドライバーがドライバーエラーを報告 - EXTSPIJドライバー rc 1 - 操作失敗 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) ステータス 0x1 - ドライバーがドライバーエラーを報告 - EXTSPIJドライバー rc 1 - 操作失敗 最初のパーティションは erase-range コマンドで消去済みであることに注意してください。また、私たちのファームウェアがフラッシュドライバーで処理すると期待通りに動作することも確認できます。リンクサーバーを手動で操作しようとした場合にのみ失敗します。 =================================================== Q1。何か明確な理由はありますか?パーティション2を消すべきなのか、それとも両方の区画を消すべきなのでしょうか? Q2。もしスロット1のためにバイナリをビルドした場合、パーティション2のイメージで動作するコアに接続したとき、このバイナリは動作しますか?Flashのリマップは動作しますか? ご協力ありがとうございます。 よろしくお願いします！ ヤクブ Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled ギャビンさん、こんにちは。ご返信ありがとうございます！あなたはこれらの概念を理解する上で本当に役立ちました。 もし可能なら、もう一つだけ一緒に考えていただけませんか? これはOTAアップデート後に取得したパーティション情報です。 =========== 画像 0; 名前 APP; 状態 永続的: スロット 0 APP_PRIMARY; オフセット 0x100000; サイズ 0x100000 (1048576): <画像: サイズ 821444; バージョン 1.1.1+0> 画像ペイロードのSHA256: C825709456C098E38090... log_addr 0x30100000 は 0x30200000 にリマップされます スロット 1 APP_SECONDARY; オフセット 0x200000; サイズ 0x100000 (1048576): <画像: サイズ 821444; バージョン 2.1.1+0> 画像ペイロードのSHA256: EBFCCC0D3E970230E404... log_addr 0x30200000 は 0x30200000 に再マッピングされます *アクティブ* =============== 次に、このスクリプトを実行してスロット0をクリアします。 LinkServer.exe flash MIMXRT1176xxxxx:MIMXRT1170-EVKB erase-range 0x30100000 0x100000 あなたの説明によると、リマップオーバーレイが有効になっているため、スロット1が消去されると予想していました。しかし、そうではありません。電源リセット後に得られた結果は以下のとおりです。 ========= フラッシュREMAP_OVERLAYが有効です。 画像 0; 名前 APP; 状態 なし: スロット 0 APP_PRIMARY; オフセット 0x100000; サイズ 0x100000 (1048576): 画像が見つかりませんでした スロット 1 APP_SECONDARY; オフセット 0x200000; サイズ 0x100000 (1048576): <画像: サイズ 821444; バージョン 2.1.1+0> 画像ペイロードのSHA256:EBFCCC0D3E970230E404... log_addr 0x30200000 0x30200000への再マップ *アクティブ*========= まだslot0に何も書き込めないのは予想外です。eraseコマンドはremapコマンドの論理マッピングをバイパスするが、loadコマンドはバイパスしないということはあり得るのでしょうか？ Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled こんにちは、 @jslota13245 さん。 NXP MIMXRTシリーズにご関心をお寄せいただきありがとうございます！ ご提供いただいた情報に基づき、以下の理由を考慮すべきだと考えます。故障の原因は FlexSPIリマップは引き続き有効です OTAアップデート後。MCUbootがリマップでslot1(partition2)を起動すると、アプリケーションにremapを残します。LinkServerのフラッシュ  .cfx  ドライバはAHB論理アドレスを通じて処理されるため、リマップは書き込みTo  0x30100000  (partition1)を物理  0x30200000  (partition2)に静かにリダイレクトします。物理はすでに確認済み画像を保持しており、空白ではありません。NORフラッシュは上書きできません。 以前の  erase-range 0x30100000  実際、同じ理由でパーティション2も消去しました。独自のファームウェアは、プログラムによって動作します。 FlexSPI IPコマンドモードでは、明示的な物理オフセットを使用することで、リマップをバイパスします。注: VECTRESET / デバッガーアタッチ 再マッピングは明確ではない。PORまたは明示的なレジスタ書き込みのみがそれを可能にする。 Q1: どのパーティションを消去すべきですか? 重要なのは、パーティションを消去するだけでなく、まずリマップを無効にすることです。推奨： LinkServerでプログラミングを行う前に、リマップレジスタをクリアしてください。 次に、両方のパーティション（slot0とslot1）を消去します。direct-XIPは最高バージョンを選択するため、slot1に古くなった画像が残るとMCUbootが再度選び、再マッピングを有効化するため、問題が再発します。 Q2: Partition2イメージを実行するコアに接続した場合、slot1バイナリは動作しますか? 画像にはリンクが必要です プライマリスロット ( 0x30100000 ) 用に一度だけ実行します。同じバイナリはリマップによりどちらのスロットからでも実行されます。スロット1 用に別途ビルドする必要はありません。デバッグ用にアタッチすると、リマップは論理アドレスの整合性を保つため、コードの読み取りやブレークポイントは問題なく動作します。しかし、同じリマップはフラッシュを書く際に物理ターゲットを変えるため、LinkServerでslot0をプログラムする前にリマップを無効にする必要があります 。 よろしくお願いします、 ギャビン

Warning in the .mex file In the (autogenerated) .mex file for a project, each peripheral reads something like this: 1.0.0 Notice the verbiage in the "description" attribute. For other peripheral this varies, but it is almost always something like a warning or an error message. The project compiles and runs fine. Also related, if I try to add a new software component from the 'Peripherals view', all the currently unselected peripherals are marked with yellow exclamations, please see the attached screen shot. If I hover the mouse over them, I get the same message shown in the "description" attribute. Yet I am able to add them without any issues. What are those warnings about?

PN5190B1最初のRFフィールドONで反応しなくなります 皆さんこんにちは、もうアイデアが尽きてしまったので助けていただけると嬉しいです... PN5190B1HN/C121E(ホスト:CC1352 MCU over SPI)を搭載したカスタムボードを持っています。新生産ロット(約100台)では、約75%の故障率が示されています。RFフィールドが初めてオンになった瞬間にSPIで応答しなくなり、VENリセット後にのみ回復します。前のロットのユニット(プロトタイプ5個)は同じデザインとBOMで正常に動作します。測定結果から、アンテナ/マッチング、送信機のショート、静的電源、SYS3Vの電圧低下、チップのファームウェア、シリコンロットの問題は除外しました。我々は、確認済みの根本原因、考えられるシリコンの不具合、または見落としている可能性のあるEEPROM/電源構成を探しています。 ハードウェア NFCフロントエンド：PN5190B1HN/C121E — GetVersionレポートによると、HW=0x52、ROM=0x02、FW=0x0201です。 TX電源＝内部TX_LDO。VUP_TX（ピン6）= 3.3V（LDO入力）。VDDPA（ピン9）＝TX_LDO出力（GNDのみにデカップリング）。VBAT / VBATPWR = 3.3 V。内部DC-DCコンバータは使用されていません（BOOST_LXインダクタは取り付けられていません）。 メインレールSYS3V = TPS62840降圧コンバータ（最大0.7A）からの3.3V。 27.12 MHz水晶発振子（村田製作所製 XRCGB27M120F3M00R0）。 DPCは無効になっています。ULPCD（超低消費電力カード検出）を使用。VDDPAを最小値に設定（TX_LDO_VDDPA_HIGH/LOW、EE 0x06/0x07 = 0x00）。 差動アンテナTX1/TX2、EMCフィルタ（L = 160 nH）+整合回路。測定された共振周波数は約12.56MHz（最終的な金属環境なし）（良品と不良品で同一）。 症状（詳細な特徴） フィールドONの前にフルSPIが動作します：SWITCH_MODE_NORMAL、GetVersion、GetDieId、EEPROMの読み書きはすべてSUCCESS（ステータス0x0000）を返します。 最初のFieldOn(RF_ON)では、ホストがフィールドオンイベントを待つためにタイムアウトします。その直後、すべてのSPIレジスタの読み取りがタイムアウトします（CLIF_STATUS、SYSTEM_CONFIG、GetDieIdの読み取りはすべてHAL IOタイムアウトを返します）。VENリセットを行うまで、このチップはSPIに対して全く反応しません。 VENリセット後、チップは再び正常になります（GetVersion OK）。その後、FieldOnが再びチップを破損させ、無限リトライループが発生します。 RFフィールドは放射されません(NFCテストLEDは点灯しません)。基板は約20mAの電流を消費し、低電力状態に戻ることはありません。 良品と不良品は、ファームウェア（0x0201）、DIEIDロット、EEPROM構成、アンテナ（VNA）、およびDC抵抗において同一である。唯一の違いは、FieldOnでは不良ユニットが破損してしまう点です。 ホストMCUはハング中も生き続けます(I²Cキーパッドエキスパンダーが応答し続けます)。つまり、故障するのは基板全体ではなくPN5190側です。 正常ユニットと不良ユニットの電流消費量は約2.7秒までは同一ですが、約2.7秒で正常ユニットは処理を完了して低電力に低下し、不良ユニットは約20mAのままになります。 除外された項目（それぞれ直感ではなく、測定に基づいて） 仮説 除外された経緯 アンテナ／マッチング／チューニング miniVNAを4つの良品ユニットと4つの不良品ユニットで測定したところ、両者は区別がつかなかった。共振周波数は良品12.565MHz、不良品12.593MHz、RL ≈ −9dB、|Z| ≈ 24.7Ω、SWR ≈ 2.08（いずれも同じ値）。 TX短絡/過電流 直流抵抗 TX1–TX2 ≈ 1.2 kΩ、TX1–GND ≈ TX2–GND ≈ 1.15 kΩ、良品と不良品で同一 静電気による電源漏れ／デカップリング 電流消費量は、約2.7秒までは正常と異常で同じである。 SYS3V電圧低下 3.3Vで安定して測定。3.3Vレールすべてに47μFのバルクコンデンサを追加→変化なし、依然として故障。 チップFW ユニットを最新のPN5190ファームウェアにアップデートしましたが、依然として失敗し、同じ動作を示します。（未処理の良品と不良品の両方で、ファームウェアコード0x0201が報告される。） シリコンロット DIEID 正常 00000000 0DD0945E 5B38BDDC 892C0810 対 不良 00000000 0DD095A6 6938BDDC 892C0E64 — 同じプレフィックス/ロット構造 TXドライバ振幅 FieldOn前のCLIF_SS_TX1/2_RMCFG CW振幅の減少 → 変更なし TX_LDO過電流保護 TX_LDO_CONFIGビット11（0xAE → 0xA6）で無効化しましたが、変化はありませんでした。 TX_LDO出力コンデンサ VDDPA出力コンデンサ（4.7 µF + 100 pF）を取り外した → 変化なし EEPROM構成（良品と不良品で同一） DCDC_PWR_CONFIG (0x00) = 0x21 (DC-DCオフ、VUP = VBATPWR、ULPCD有効) TX_LDO_CONFIG (0x02 / 0x03) = 0xA7 / 0xAE (デフォルト) TX_LDO_VDDPA_HIGH / LOW (0x06 / 0x07) = 0x00 (最小値、約 1.5 V) DPCが無効になっています 質問 これは報告された「最初の起動時/最初のRFフィールドオン時にPN5190チップ破損」と一致します。根本原因と最終的な解決策を確認できますか?(注:最新のPN5190ファームウェアをフラッシュしても解決しませんでした — 同じ失敗です。) このロット／日付コードに対応するシリコンに関する訂正情報はありますか？完全なDIEIDとチップの刻印の写真も提供できます。 当社のトポロジー（内部TX_LDO、VUP_TX = 3.3 V、VDDPA = LDO出力、DC-DCオフ、DPCオフ、ULPCD、VDDPA最小1.5 V）において、この構成は有効でしょうか？VDDPAを最低限の電圧で動作させることは問題でしょうか？また、比較対象となる正しいEEPROM電源構成（PNEV5190Bとの比較）は何でしょうか？ 電源投入順序に関する要件（VENとサプライランプのどちらを優先するかなど）があり、それが満たされない場合にこのような問題が発生するのでしょうか？注:前の(動作中の)ロットと比べて、VENはI²Cエクスパンダ出力から直接MCU GPIOに移し、VENプルアップはDNPなので、ホスト起動時にVENは浮動します。 ブラウンアウト、過電流、FW、シリコン、アンテナがすべて測定で除外されている中で、VENリセットまでチップがSPIに応答しなくなるRF_ON経路の他に何があるのでしょうか? よろしくお願いいたします。   イグナシオ

启用 XIP FLASH 重映射后，在镜像交换后对 MCUBoot 镜像进行调试/刷写。 各位亲爱的朋友们， 我想请教一下，为什么我们的U盘会在某种特定情况下出现故障？ 我们使用定制的电路板，搭载 IMXRT1176，我们的电路板基于 Embedded Artists 的该 MCU 载板。我们的项目中，闪存中有两个分区，分别为 0x30100000 和 0x30200000。我们使用 MCU-Link 和 Linkserver 来烧录二进制文件。在这种情况下，二进制文件会使用 --confirmed 进行签名。我们启用了 FLASH 重映射功能，因此不会执行交换操作。 我们观察到两种情况： 1.如果闪存中有引导加载程序，并且分区 1 中有镜像，则一切都按预期工作。 2. OTA 升级完成后，MCUboot 从第二个分区启动新镜像，此时我们将无法再写入 FLASH 分区 1，因为链路服务器会报错： ================================================= Nc：正在打开闪存驱动程序 MIMXRT1170_SFDP_QSPI.cfx（已驻留） Nc：发送 VECTRESET 以运行闪存驱动程序 Nc：检测到 Flash 变体“iMXRT1170_SFDP_FlexSPI1_A_QSPI 2026 年 5 月 15 日 18:32:39”（16MB = 256*64K，地址为 0x30000000） Pb：1/1 (0) 正在写入地址 0x30100000 的扇区 16-31，共 1048576 字节 PS：（0）位于 30100000：0 字节 - 0/1048576 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) 状态 0x1 - 驱动程序报告驱动程序错误 - EXTSPIJ 驱动程序返回码 1 - 操作失败 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) 状态 0x1 - 驱动程序报告驱动程序错误 - EXTSPIJ 驱动程序返回码 1 - 操作失败 请注意，我已经使用 erase-range 命令擦除了第一个分区。我还可以确认，当我们的固件通过闪存驱动程序执行此操作时，它能按预期工作。只有当我尝试手动使用链接服务器时才会失败。 =================================================== 问题一：这样做有什么明显的原因吗？我们应该总是擦除分区 2 还是两个分区都擦除？ Q2. 如果我们为 slot1 构建了一个二进制文件，那么当我们将其连接到运行在分区 2 中的镜像的核心时，该二进制文件是否能正常工作？Flash 重映射能否使其正常工作？ 提前感谢您的帮助！ 此致！ 雅库布 Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled 你好 Gavin，非常感谢你的回复！你真的帮我理解了这些概念。 如果可以的话，能否请您再帮我解决一件事？ 这是我通过OTA更新获取到的分区信息： =========== 图片 0；名称 APP；状态 永久： 插槽 0 APP_PRIMARY；偏移量 0x100000；大小 0x100000 (1048576)： < size="" 821444=""> 图像有效载荷的 SHA256 值：C825709456C098E38090... log_addr 0x30100000 重映射为 0x30200000 插槽 1 APP_SECONDARY；偏移量 0x200000；大小 0x100000 (1048576)： < size="" 821444=""> 图像有效载荷的 SHA256 值：EBFCCC0D3E970230E404... log_addr 0x30200000 重映射为 0x30200000 *积极的* =============== 然后我运行这个脚本来清除 slot0。 LinkServer.exe flash MIMXRT1176xxxxx:MIMXRT1170-EVKB erase-range 0x30100000 0x100000 根据你所说，我原本以为会删除 slot1，因为重新映射叠加层已启用。然而，事实并非如此。断电重启后出现的情况是： ========= Flash REMAP_OVERLAY 已激活。 图片 0；名称 APP；状态 无： 插槽 0 APP_PRIMARY；偏移量 0x100000；大小 0x100000 (1048576)： 插槽 1 APP_SECONDARY；偏移量 0x200000；大小 0x100000 (1048576)： < size="" 821444=""> 图像有效载荷的 SHA256 值：EBFCCC0D3E970230E404... log_addr 0x30200000 重映射为 0x30200000 *活跃*========= 我仍然无法向 slot0 写入任何内容，这出乎我的意料。是否有可能擦除操作绕过了重映射的逻辑映射，而加载操作则没有？ Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled 你好@jslota13245 ， 感谢您对 NXP MIMXRT 系列产品的关注！ 根据您提供的信息，我认为应该考虑以下原因。故障是由以下原因造成的： FlexSPI 重映射仍然启用 OTA 之后。当 MCUboot 通过重映射启动 slot1（分区 2）时，它会将重映射保留到应用程序中。LinkServer 的  .cfx  闪存驱动程序通过 AHB 逻辑地址进行编程，因此重映射会静默地将您的写入操作重定向到  0x30100000  （分区1）到物理  0x30200000  （分区 2）——其中已包含已确认的图像，并且不为空。NOR闪存无法覆盖它。 你之前的  erase-range 0x30100000  实际上，出于同样的原因，我也删除了分区2。你自己的固件之所以能工作，是因为它通过以下方式进行编程： FlexSPI IP 命令模式，具有明确的物理偏移量，绕过重映射。注意：VECTRESET / 调试器附加 重映射并不明确——只有 POR 或显式寄存器写入才能实现。 问题1：要删除哪个分区？ 关键在于先禁用分区重映射，而不仅仅是删除分区。受到推崇的： 使用 LinkServer 进行编程之前，请清除重映射寄存器； 然后擦除两个分区（slot0 和 slot1）。由于 direct-XIP 会选择最高版本，因此插槽 1 中遗留的过时映像会导致 MCUboot 再次选择它并重新启用重映射，从而导致问题再次出现； Q2：当把 slot1 二进制文件附加到运行 partition2 镜像的核心上时，它能正常工作吗？ 图片应该链接 一次用于主槽（ 0x30100000 ）；同一个二进制文件通过重映射从任一槽运行——无需单独构建槽1的**版本**。当您附加到调试位置时，重映射会保持逻辑地址一致，因此代码读取/断点可以正常工作。然而，同样的重映射操作在写入闪存时会改变物理目标，所以你 在用 LinkServer 对 slot0 进行编程之前，必须先禁用重映射。 此致， 加文

Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled Dear Everyone, I would like to ask for any possible reason why does our flash driver fail in one specific situation. We use custom board with IMXRT1176, our board is based on Embedded Artists carrier board for that MCU. In our project there are two partitions in flash, 0x30100000 and 0x30200000. We use MCU-Link and Linkserver to flash binaries. Binaries are signed with --confirmed in this case. We have a FLASH remap functionality enabled so no swap is performed. We observe two situations: 1. If there is a bootloader in flash and an image in partition 1, everything works as expected. 2. Once we complete the OTA upgrade and MCUboot boots new image from a second partition, we can no longer write to FLASH partiton 1 as we get an error from linkserver: ================================================= Nc: Opening flash driver MIMXRT1170_SFDP_QSPI.cfx (already resident) Nc: Sending VECTRESET to run flash driver Nc: Flash variant 'iMXRT1170_SFDP_FlexSPI1_A_QSPI May 15 2026 18:32:39' detected (16MB = 256*64K at 0x30000000) Pb: 1 of 1 ( 0) Writing sectors 16-31 at 0x30100000 with 1048576 bytes Ps: ( 0) at 30100000: 0 bytes - 0/1048576 Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) status 0x1 - driver reported driver error - EXTSPIJ driver rc 1 - Operation failed Ec: op ProgramPage (0x30100000, 0x20002830, 0x4000) status 0x1 - driver reported driver error - EXTSPIJ driver rc 1 - Operation failed Note that I have erased the first partition with erase-range. I also can confirm that when our firmware does it with flash driver it works as expected. It fails only when i try to do it with the linkserver manually =================================================== Q1. Is there any obvious reason for it? Should we always erase partition 2 or both paritions? Q2. If we have binary built for slot1, does this binary work when we attach to the core which runs with image in partition 2? Does Flash remap make it work? Thanks in advance for any help, Best Regards! Jakub Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled Hello Gavin, thank you very much for your response! You really helped me to understand these concepts. If it's possible, could you please help me figure out one more thing? This is partition info i get after OTA: =========== Image 0; name APP; state Permanent: Slot 0 APP_PRIMARY; offset 0x100000; size 0x100000 (1048576): < size="" 821444=""> SHA256 of image payload: C825709456C098E38090... log_addr 0x30100000 remaps to 0x30200000 Slot 1 APP_SECONDARY; offset 0x200000; size 0x100000 (1048576): < size="" 821444=""> SHA256 of image payload: EBFCCC0D3E970230E404... log_addr 0x30200000 remaps to 0x30200000 *ACTIVE* =============== Then I run this script to clear slot0 LinkServer.exe flash MIMXRT1176xxxxx:MIMXRT1170-EVKB erase-range 0x30100000 0x100000 According to what you said, i expected to erase slot1 because remap overlay is active. However that's not the case. What i got after power reset is: ========= Flash REMAP_OVERLAY active. Image 0; name APP; state None: Slot 0 APP_PRIMARY; offset 0x100000; size 0x100000 (1048576): Slot 1 APP_SECONDARY; offset 0x200000; size 0x100000 (1048576): < size="" 821444=""> SHA256 of image payload: EBFCCC0D3E970230E404... log_addr 0x30200000 remaps to 0x30200000 *ACTIVE*========= I still can't write anything to slot0 which is unexpected. Is it possible that erase bypasses the logical mapping of remap but load doesn't? Re: Debug/Flash MCUBoot image after after image swap with XIP FLASH remap enabled Hi @jslota13245 , Thanks for your interest in NXP MIMXRT series! Based on the information you provided, I believe the following reasons should be considered. The failure is caused by the FlexSPI remap still being enabled after OTA. When MCUboot boots slot1 (partition2) via remap, it leaves remap on into the application. LinkServer's  .cfx  flash driver programs through the AHB logical address, so the remap silently redirects your write to  0x30100000  (partition1) to physical  0x30200000  (partition2) — which already holds the confirmed image and is not blank. NOR flash cannot overwrite it. Your earlier  erase-range 0x30100000  actually erased partition2 for the same reason. Your own firmware works because it programs via FlexSPI IP command mode with explicit physical offsets, bypassing the remap. Note: VECTRESET / debugger attach do not clear the remap — only a POR or an explicit register write does. Q1: Which partition to erase? The key is to disable remap first, not just erasing partitions. Recommended: Before programming with LinkServer, clear the remap registers; Then erase both partitions (slot0 and slot1). Because direct-XIP selects the highest version, a stale image left in slot1 will make MCUboot pick it again and re-enable remap, so the problem returns; Q2: Will a slot1 binary work when attached to a core running the partition2 image? The image should be linked once for the primary slot ( 0x30100000 ); the same binary runs from either slot via remap — no separate slot1 build is needed. When you attach for debug, remap keeps logical addresses consistent, so code reads/breakpoints work fine. However, the same remap changes the physical target when writing flash, so you must disable remap before programming slot0 with LinkServer. Best regards, Gavin