Alternative part for NVT4857UKAZ This is less directly software related, but we recently discovered that the NVT4857UKAZ has already reached EOL, and there are no pin-to-pin compatible replacement parts available. Since SD card support is a required feature for our i.MX95-based device, we're trying to understand what alternative solutions are available given this situation. Could you share your recommendations on possible replacement options or design approaches? Re: Alternative part for NVT4857UKAZ Hello! You can refer NVT4858 as a replacement. However, please note that NVT4858 is not a drop-in replacement. Therefore, both hardware and software modifications may be required to accommodate the new device in your application. We recommend carefully reviewing the specifications and design requirements to evaluate the impact of the migration. Hope this helps! Re: Alternative part for NVT4857UKAZ Hello! You can refer NVT4858 as a replacement. However, please note that NVT4858 is not a drop-in replacement. Therefore, both hardware and software modifications may be required to accommodate the new device in your application. We recommend carefully reviewing the specifications and design requirements to evaluate the impact of the migration. Hope this helps!

iMXRT1052 カスタムファームウェアでキーブロブを生成しても、起動時に受け入れられません。 こんにちは、   署名済みの暗号化ブートローダーがあり、HABは有効になっていますが、シールはされていません。NXPのセキュアプロビジョニングツールを使ってフラッシュすると、問題なく動作します。同様に、FCB + パディング + 署名および暗号化されたブートローダー + キーブロブ（キーブロブはターミナルで次のコマンドを実行して生成されます）を連結すると、次のようになります。   blhost -t 5000 -u 0x15A2,0x0073 -j -- generate-key-blob "dek.bin" "blob.bin"   それも効果がある。しかし、デバッグセッション（キーブロブを生成するためだけに用いられる）でカスタムファームウェアを使用してこのプロセスを実行すると、生成されたブロブファイルが受け入れられず、ブートローダーの実行に失敗します。どちらのシナリオにおいても、DEKは変化しない。   両方とも.binファイルを生成しましたファイル間の違いは、ブロブオフセットアドレスのみである。   Secure Provisioning Toolが提供するflashloader.binと公開されているソースコード(MCUブート)との間に違いはありますか?   標準のフラッシュローダーは、このバージョンを報告します。 blhost -u 0x15A2,0x0073 -- get-property 1 Response status = 0 (0x0) Success. Response word 1 = 1258424320 (0x4b020800) Current Version = K2.8.0   bl_version.h に基づくと、ソースコードは一貫しているはずであり、Secure Provisioning Tool のバージョンは 25.09 です。   カスタムファームウェアはフラッシュローダーソースからのコードスニペット(特にbl_keyblob_dcp.cにあります)を使用しています。そして、すべての依存関係は同じソースから取得されます。この実装は内部でのみ使用されるため、ファームウェアからDEKを抽出することは問題ありません。   お時間をいただきありがとうございました。 🙂

PWMキャプチャはfrdm_mcxw72ボードでは動作しません こんにちは、 frdm_mcxw72 ボードで pwm キャプチャ サンプルを試してみましたが、残念ながらシリアル ツールのプリント メッセージには「 capture cycle err -134 」としか表示されません。frdm_mcxw72ボードのPTA21ピンには、1kHz、デューティサイクル50%のPWM信号が注入されているはずです。 デモケースからプロジェクトファイル全体をインポートしましたが、オーバーレイファイルだけを追加しただけで変更はありません。以下にオーバーレイファイルの設定があります。 なぜ正しい印刷情報がないのか、その理由を調べていただけますか?前もって感謝します！

i.MX95 启动 ROM：配置 eMMC Boot0/Boot1 为主/从启动盘，FlexSPI NOR 为恢复盘 各位专家好， 我正在尝试了解 i.MX95 启动 ROM 是如何处理主启动、辅助启动和恢复启动阶段的。我已经查阅了参考手册和一些 U-Boot spl 源代码，但我仍然不清楚恢复启动机制的工作原理。 我的目标是实现以下启动架构： 主启动： eMMC Boot0 辅助启动： eMMC 启动1 Recovery 启动： FlexSPI 或非 闪存（黄金恢复镜像） 在查看arch/arm/mach-imx/image-container.c文件时，我注意到以下代码： printf("Boot stage: "); if (rom_data.boot_stage == 0x6) printf("Primary\n"); else if (rom_data.boot_stage == 0x9) printf("Secondary\n"); else if (rom_data.boot_stage == 0xa) printf("Recovery\n"); else printf("USB Serial Download\n"); 根据此，Boot ROM 似乎支持四个启动阶段：主启动、辅助启动、恢复启动和 USB 串口下载启动。但是，我找不到足够的信息来解释如何选择或配置恢复阶段。 我希望就以下问题获得一些指导： 是否可以将FlexSPI 或非 闪存配置为恢复引导设备，同时使用eMMC Boot0 和 Boot1作为主启动分区和辅助启动分区？ 如果支持这种配置，推荐的配置方法是什么？ 在选择主启动、辅助启动和恢复启动阶段时，启动 ROM 遵循的顺序是什么？ 如果主启动和辅助启动都失败，什么情况下会触发恢复启动阶段？ 在开发和验证过程中，可以有意重现哪些故障条件来模拟恢复模式？ 是否有任何文档或应用说明详细描述了启动 ROM 启动选择算法和恢复启动流程？ 引导设备熔丝配置（熔丝模式） 在选择恢复引导设备时 是否 起作用？ 恢复设备是由引导设备熔丝决定的吗？ 或者，即使启动设备熔丝到 eMMC 上，启动 ROM 能否自动切换到不同的启动设备（例如 FlexSPI NOR）？ 最终，我的目标是让系统正常从 eMMC Boot0 启动， 必要时 回退到 eMMC Boot1 ， 如果两个 eMMC 启动分区都不可用或无效， 则最终启动 存储在 FlexSPI 或非 中的 Golden Recovery Image 。 如果有人已经实现了类似的启动架构，或者可以向我提供相关的文档或应用笔记，我将非常感谢您的指导。 提前谢谢！ BR， 阿伦·库马尔

IMXRT 1180 系列 您好，NXP团队， 我们目前正在评估恩智浦半导体微控制器在空间机载计算机 (OBC) 应用中的使用情况。 最初，我们考虑的是i.MX RT1170 (MIMXRT1170) ，在评估过程中，我们注意到 NXP 的文档明确指出该器件采用28nm FD-SOI 技术制造。由于半导体工艺技术是我们应用的关键评估标准，因此我们现在也对评估i.MX RT1180系列感兴趣。 在继续进行下一步之前，我们希望了解i.MX RT1180的制造工艺： i.MX RT1180 是否也像 i.MX RT1170 一样，采用28nm FD-SOI 技术制造？ 如果没有，能否请您提供RT1180所采用的工艺技术信息？ 是否有任何官方文档或产品简介提及该设备的制造节点和工艺技术？ 我们查阅了公开的文档，但未能找到有关 RT1180 工艺技术的官方声明。 这些信息对我们的内部技术评估和认证活动非常重要，我们非常感谢您的指导。 感谢您的支持。 Re: IMXRT 1180 Family 嗨@mayliu1 ， 感谢您的快速回复，并确认i.MX RT1180采用28nm FD-SOI 技术制造。 我们希望您能再澄清一点。请问这是否适用于整个 i.MX RT1180 系列，包括以下设备？ i.MX RT1186 i.MX RT1187 i.MX RT1189 如果 RT1180 系列的所有成员都采用相同的 28nm FD-SOI 工艺制造，则此信息将有助于我们进行外围和特征分析，以确定最适合我们应用的设备。 希望您能确认一下。 感谢您的支持。 此致， 鲁斯维克·R Re: IMXRT 1180 Family 嗨@ruthvik_1 ， 非常感谢您对我们产品的关注以及对我们社区的使用。 是的。i.MX RT1180 采用 28 纳米 FD-SOI 技术。 抱歉，目前还没有任何公开的官方文件或产品简介明确提及该设备的制造节点或工艺技术。 希望对你有帮助 顺祝商祺！ 5月

NXPRDLIB_REM_GEN_INTFS の使用状況 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは。 NXP Reader Library のNXPRDLIB_REM_GEN_INTFS定義の正確な目的を知りたいです。 私の見る限り、定義されていればプロジェクトと一緒にソフトウェアAPIインターフェースが構築され、そうでなければバイナリの同等のものに置き換えられます。なぜなら、その場合は関数プロトタイプしか利用できないからです... これは正しいですか？もしそうなら、二進リベラルはどこにあるのでしょうか?バイナリを選ぶことのメリット・デメリットは何ですか? よろしくお願いします、 ペッペ NFCリーダー・ライブラリ Re: NXPRDLIB_REM_GEN_INTFS usage @stephanie_m これはDoxygen-Dokuのバグです。 /* デバッグビルドモード */ /*#define NXPBUILD__PH_DEBUG*/ /**< デバッグビルド定義 */ #define NXPRDLIB_REM_GEN_INTFS したがって、正解はまだ確定していません。 Re: NXPRDLIB_REM_GEN_INTFS usage <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、 リーダーライブラリのAPIドキュメントによると、あなたが見ている定義はビルドデバッグ目的です よろしくお願いいたします。 エステファニア Re: NXPRDLIB_REM_GEN_INTFS usage <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> エステファニアさん、こんにちは。ご関心をお寄せいただきありがとうございます。 例えばPN7462AU-FW_v05.21.00_Full file rootから、その定義は一部のNFCリーダライブラリの例で有効になっています: $ grep -r NXPRDLIB_REM_GEN_INTFS NfcrdlibEx* NfcrdlibEx4_MIFAREClassic/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx5_ISO15693/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx7_EMVCo_Polling/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx9_NTagI2C/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS また、PN7462AU PSPの例でも同様のことが言えます。 $ grep -r NXPRDLIB_REM_GEN_INTFS PN7462AU* PN7462AU_ex_phExMain/inc/APP_NxpBuild.h:#define NXPRDLIB_REM_GEN_INTFS PN7462AU_ex_phExVCom/inc/APP_NxpBuild.h:#define NXPRDLIB_REM_GEN_INTFS また、NFCリーダライブラリの多くの資料で確認されています: $ grep -r NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/ NxpNfcRdLib/comps/phacDiscLoop/src/phacDiscLoop.c:#ifndef NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phacDiscLoop/src/phacDiscLoop.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ NxpNfcRdLib/comps/phalFelica/src/phalFelica.c:#ifndefNXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phalFelica/src/phalFelica.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ NxpNfcRdLib/comps/phalI18000p3m3/src/phalI18000p3m3.c:#ifndefNXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phalI18000p3m3/src/phalI18000p3m3.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ （…） よろしくお願いいたします。 ペッペ Re: NXPRDLIB_REM_GEN_INTFS usage <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> こんにちは、 使用しているライブラリのバージョンは何ですか？その情報と、その定義が表示されているファイルを教えていただけませんか? APIのドキュメントにもライブラリでも、あなたが言及している定義を見つけることができなかったので、とても助かると思います。 よろしくお願いいたします。 エステファニア

HSEからの回答待ち HSEの回答が保留中のまま、S32K312 MCUとのOTAアップデート中に届かなかった過去の事例があるかどうかを伺いたいです。 また、どのような状況下でHSEの対応が保留となる可能性があるのかをご確認ください。 Re: Pending HSE response HSEサービスが永久に保留状態になる原因となる、既知のS32K312 OTAの問題は把握しておりません。 一般的に、すべてのHSEサービスリクエストには応答が返されるべきである。応答がない場合は、HSEファームウェアが致命的なエラーを検出し、シャットダウンモードに入ったことを示している可能性があります。この場合、診断情報についてはMU GSR登録簿を確認することをお勧めします。 原因としては、無効なサービスパラメータ、無効なメモリアドレス、XRDCアクセス違反、ECCエラー、クロックや初期化の問題、リソースの競合、その他の致命的なHSE内部エラーなどがあります。 調査にご協力いただくため、問題発生時のHSEファームウェアのバージョン、実行中の特定のHSEサービス、サービス記述子、およびMUステータスレジスタ（FSR/GSR）の情報をご提供ください。

等待 HSE 回复 我想咨询一下，之前是否有过这样的情况：在使用 S32K312 MCU 进行 OTA 更新时，HSE 响应一直处于待处理状态，没有到达。 此外，请确认在何种情况下 HSE 回复可能会处于待定状态。 Re: Pending HSE response 我们目前尚未发现任何已知的 S32K312 OTA 问题会导致 HSE 服务永久处于待处理状态。 一般来说，每个 HSE 服务请求都应该返回一个响应。如果没有收到响应，则可能表明 HSE 固件遇到了致命错误并进入了关机模式。在这种情况下，我们建议检查 MU GSR 寄存器以获取诊断信息。 可能的原因包括无效的服务参数、无效的内存地址、XRDC 访问冲突、ECC 错误、时钟或初始化问题、资源冲突或其他致命的 HSE 内部错误。 为了帮助调查，请提供 HSE 固件版本、正在执行的具体 HSE 服务、服务描述符以及出现问题时的 MU 状态寄存器（FSR/GSR）。

Pending HSE response I would like to inquire if there have been previous instances where the HSE response remained pending and did not arrive during an OTA update with the S32K312 MCU. Additionally, please confirm under what circumstances the HSE response might become pending. Re: Pending HSE response We are not aware of a known S32K312 OTA issue that causes HSE services to remain permanently pending. In general, every HSE service request should return a response. If no response is received, it may indicate that the HSE firmware encountered a fatal error and entered shutdown mode. In this case, we recommend checking the MU GSR register for diagnostic information. Possible causes include invalid service parameters, invalid memory addresses, XRDC access violations, ECC errors, clock or initialization issues, resource conflicts, or other fatal HSE internal errors. To help investigate, please provide the HSE FW version, the specific HSE service being executed, the service descriptor, and the MU status registers (FSR/GSR) when the issue occurs.

MCTPTX1AK324，FreeMASTER 连接问题 0x80000101 我正在使用MCTPTX1AK324开发板进行电机开发。目前，当我按下按钮3时，电机可以运转。我需要使用MCAT主机来调整设置，但是当我使用freeMASTER通过串口连接时，出现错误：连接超时，0x8000 0101。请问您能否帮忙查看一下示例程序是否需要修改？ 目前，演示程序的部分代码被屏蔽了。在 M3 上初始化 GD3000 和 IPCF 会导致程序冻结，因此我们根据 FAE 的建议阻止了它们。 第三季度

NXPRDLIB_REM_GEN_INTFS 用法 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好。 我想知道 恩智浦读取器库 中NXPRDLIB_REM_GEN_INTFS定义的确切用途是什么。 据我观察，如果定义了软件 API 接口，则会在项目中构建该接口；否则，它会被某种二进制等效代码所取代，因为那样的话就只有函数原型可用了…… 这样对吗？如果是这样，二进制库在哪里？选择二进制而非软件 API 的优缺点是什么？ 先感谢您， 佩佩 NFC读卡器库 Re: NXPRDLIB_REM_GEN_INTFS usage @stephanie_m 这是 Doxygen-Doku 的一个 bug： /* 调试版本模式 */ /*#define NXPBUILD__PH_DEBUG*/ /**< DEBUG 版本定义 */ #define NXPRDLIB_REM_GEN_INTFS 因此，正确答案尚未揭晓…… Re: NXPRDLIB_REM_GEN_INTFS usage <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好， 根据读取器库的 API 文档，您看到的这个定义是用于版本调试目的的。 此致， 埃斯特法尼亚 Re: NXPRDLIB_REM_GEN_INTFS usage <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 您好，Estephania，感谢您的关注。 例如，从 PN7462AU-FW_v05.21.00_Full 文件根目录开始，该定义已在某些 NFC 阅读器库示例中启用： $ grep -r NXPRDLIB_REM_GEN_INTFS NfcrdlibEx* NfcrdlibEx4_MIFAREClassic/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx5_ISO15693/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx7_EMVCo_Polling/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx9_NTagI2C/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS 在某些PN7462AU PSP示例中也是如此： $ grep -r NXPRDLIB_REM_GEN_INTFS PN7462AU* PN7462AU_ex_phExMain/inc/APP_NxpBuild.h:#define NXPRDLIB_REM_GEN_INTFS PN7462AU_ex_phExVCom/inc/APP_NxpBuild.h:#define NXPRDLIB_REM_GEN_INTFS 而且在 NFC 阅读器库的许多源代码中都有所验证： $ grep -r NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/ NxpNfcRdLib/comps/phacDiscLoop/src/phacDiscLoop.c:#ifndef NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phacDiscLoop/src/phacDiscLoop.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ NxpNfcRdLib/comps/phalFelica/src/phalFelica.c:#ifndefNXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phalFelica/src/phalFelica.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ NxpNfcRdLib/comps/phalI18000p3m3/src/phalI18000p3m3.c:#ifndefNXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phalI18000p3m3/src/phalI18000p3m3.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ （……） 顺祝商祺！ 佩佩 Re: NXPRDLIB_REM_GEN_INTFS usage <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 你好， 你使用的是哪个版本的库？请问您能否提供相关信息以及您看到此定义的文件？ 我在 API 文档和库中都找不到您提到的定义，所以如果您能提供给我，将对我帮助很大。 问候， 埃斯特法尼亚

IMXRT 1180 Family Hello NXP Team, We are currently evaluating NXP microcontrollers for use in a Space On-Board Computer (OBC) application. Initially, we were considering the i.MX RT1170 (MIMXRT1170), and during our assessment we noted that NXP documentation specifies that the device is manufactured using 28nm FD-SOI technology. Since semiconductor process technology is a key evaluation criterion for our application, we are now also interested in evaluating the i.MX RT1180 family. Before proceeding further, we would appreciate clarification regarding the manufacturing process used for the i.MX RT1180: Is the i.MX RT1180 also fabricated using 28nm FD-SOI technology, similar to the i.MX RT1170? If not, could you please provide information on the process technology used for the RT1180? Is there any official documentation or product brief that references the manufacturing node and process technology for this device? We have reviewed the publicly available documentation but were unable to locate an official statement regarding the RT1180 process technology. This information is important for our internal technology assessment and qualification activities, and we would greatly appreciate your guidance. Thank you for your support. Re: IMXRT 1180 Family Hi @mayliu1, Thank you for the quick reply and for confirming that the i.MX RT1180 is manufactured using 28nm FD-SOI technology. We would appreciate one additional clarification. Could you please confirm whether this applies to the entire i.MX RT1180 family, including the following devices? i.MX RT1186 i.MX RT1187 i.MX RT1189 If all members of the RT1180 family are fabricated using the same 28nm FD-SOI process, this information will help us proceed with our peripheral and feature analysis to determine the most suitable device for our application. We would appreciate your confirmation. Thank you for your support. Best regards, Ruthvik R Re: IMXRT 1180 Family Hi @ruthvik_1 ， Thank you so much for your interest in our products and for using our community. Yes. The i.MX RT1180 uses 28 nm FD-SOI technology . Sorry, but there is currently no public official documentation or product brief that explicitly references the manufacturing node or process technology for this device. Wish it helps you Best Regards, May

NVT4857UKAZ 的替代零件 这与软件的直接关系不大，但我们最近发现NVT4857UKAZ已经停产，并且没有引脚兼容的替代零件可用。由于 SD 卡支持是我们基于 i.MX95 的设备所必需的功能，因此我们正在努力了解在这种情况下有哪些替代方案。您能否就可能的替代方案或设计方案提出一些建议？ Re: Alternative part for NVT4857UKAZ 您好！ 您可以参考NVT4858作为替代品。 但是请注意，NVT4858 不是直接替代产品。因此，为了在您的应用中适应新设备，可能需要对硬件和软件进行修改。 我们建议仔细审查规范和设计要求，以评估迁移的影响。 希望这能帮到你！ Re: Alternative part for NVT4857UKAZ 您好！ 您可以参考NVT4858作为替代品。 但是请注意，NVT4858 不是直接替代产品。因此，为了在您的应用中适应新设备，可能需要对硬件和软件进行修改。 我们建议仔细审查规范和设计要求，以评估迁移的影响。 希望这能帮到你！

PWM Capture can't work in frdm_mcxw72 board Hi， I tried to practice the pwm capture sample in  frdm_mcxw72 board, but unfortunately, the print message in serial tool only show " capture cycle err -134" . I'm sure there is the 1Khz, 50% duty cycle pwm signal inject into the PTA21 pins in frdm_mcxw72 board. i imported the whole project files from the demo case,  there is no change that i only added the overlay file,   below is the overlay files setting. can you help check the reason why there is no correct print information. thanks in advance!

i.MX95 ブートROM：eMMC Boot0/Boot1をプライマリ/セカンダリ、FlexSPI NORをリカバリとして設定する こんにちは、専門家の皆様。 i.MX95のブートROMがプライマリ、セカンダリ、リカバリーの各ブート段階をどのように処理するのかを理解しようとしています。リファレンスマニュアルやU-Bootのsplソースコードの一部は確認しましたが、リカバリーブートの仕組みがどう機能するのかはまだよく分かっていません。 私の目標は、以下のブートアーキテクチャを実装することです。 プライマリブート: eMMC Boot0 セカンダリブート: eMMC Boot1 リカバリブート： FlexSPI NORフラッシュ（ゴールデンリカバリイメージ） arch/arm/mach-imx/image-container.cを調べていると、以下のコードに気付きました: printf("Boot stage: "); if (rom_data.boot_stage == 0x6) printf("Primary\n"); else if (rom_data.boot_stage == 0x9) printf("Secondary\n"); else if (rom_data.boot_stage == 0xa) printf("Recovery\n"); else printf("USB Serial Download\n"); これに基づき、ブートROMはプライマリ、セカンダリ、リカバリー、USBシリアルダウンロードの4つのブート段階をサポートしているようです。しかし、リカバリーステージがどのように選択・設定されるのかについて十分な情報が見つかりませんでした。 以下の質問について、ご助言いただければ幸いです。 eMMC Boot0とBoot1を プライマリおよびセカンダリブートパーティションとして 使用しながら、 FlexSPI NORフラッシュをリカバリブートデバイスとして 構成することは可能ですか ？ この構成がサポートされている場合、推奨される構成方法は何ですか？ ブートROMがプライマリ、セカンダリ、リカバリーの各ブートステージを選択する際に従う順序は何ですか？ プライマリブートとセカンダリブートの両方が失敗した場合、どのような条件でリカバリブート段階が開始されますか？ 開発や検証中にリカバリーモードをシミュレートするために、意図的に再現できる故障条件はどのようなものでしょうか?  Boot ROMのブート選択アルゴリズムやリカバリーブートフローについて詳細に説明したドキュメントやアプリケーションノートはありますか? ブートデバイスのヒューズ構成（ヒューズモード） は、 リカバリブートデバイスの選択に何らかの役割を果たしますか？ リカバリデバイスは、ブートデバイスのヒューズによって決定されますか？ それとも、ブートROMがeMMCにフュージョンされていても、自動的に別のブートデバイス(例えばFlexSPI NORなど)に切り替わることは可能でしょうか? 最終的な目標は、システムを通常はeMMC Boot0から起動し、必要に応じてeMMC Boot1にフォールバックし、両方のeMMCブートパーティションが利用できないか無効な場合は、 FlexSPI NORに保存されているゴールデンリカバリイメージから起動することです。 もし似たようなブートアーキテクチャを実装したことがある方や、関連するドキュメントやアプリケーションノートを教えていただける方がいれば、ぜひご指導いただけるとありがたいです。 お手数ですが、よろしくお願いいたします。 BR、 アルン・クマール

PWM捕获功能在frdm_mcxw72板上无法工作 你好， 我尝试在frdm_mcxw72板上练习pwm捕获示例，但不幸的是，串口工具中的打印消息只显示“捕获周期错误-134 ”。我确信有 1Khz、50% 占空比的 PWM 信号注入到 frdm_mcxw72 板的 PTA21 引脚中。 我从演示案例中导入了整个项目文件，没有任何改动，只是添加了覆盖文件，以下是覆盖文件设置。 请帮忙查一下为什么打印信息不正确。提前致谢！

MCTPTX1AK324, FreeMASTER connecttion problem 0x80000101 I'm using the MCTPTX1AK324 development board for motor development,，Right now，when I press button 3, the motor can run，I need to use the MCAT host computer to adjust the settings，But when using freeMASTER with the serial connection, it shows an error: connection timeout, 0x8000 0101，Can you take a look and see if the demo program needs any changes? Currently, the demo program has some code blocked. Initializing GD3000 and IPCF on the M3 causes the program to freeze, so we blocked them based on the FAE's suggestion. 3Q

NXPRDLIB_REM_GEN_INTFS usage Hi. I'd like to know what is the exact purpose of the NXPRDLIB_REM_GEN_INTFS define in NXP Reader Library. From what I can see, if it's defined a software API interface is built with the project, otherwise it's replaced by some binary equivalent, since then only the function prototypes are available... Is this correct? If so, where are the binary libs? What are pros/cons in selecting binary over software API? Thank you in advance, Peppe NFC Reader Library Re: NXPRDLIB_REM_GEN_INTFS usage @stephanie_m  Thats a bug in the Doxygen-Doku: /* DEBUG build mode */ /*#define NXPBUILD__PH_DEBUG*/ /**< DEBUG build definition */ #define NXPRDLIB_REM_GEN_INTFS Thus, the correct answer is still pending... Re: NXPRDLIB_REM_GEN_INTFS usage Hello, According to the API documentation of the reader library the definition you are seeing it's for build debug purposes Regards, Estephania Re: NXPRDLIB_REM_GEN_INTFS usage Hi Estephania, thank you for your interest. Starting e.g. at PN7462AU-FW_v05.21.00_Full file root that definition is enabled in some NFC Reader Library examples: $ grep -r NXPRDLIB_REM_GEN_INTFS NfcrdlibEx* NfcrdlibEx4_MIFAREClassic/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx5_ISO15693/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx7_EMVCo_Polling/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS NfcrdlibEx9_NTagI2C/intfs/ph_NxpBuild_App.h:#define NXPRDLIB_REM_GEN_INTFS and in some PN7462AU PSP examples too: $ grep -r NXPRDLIB_REM_GEN_INTFS PN7462AU* PN7462AU_ex_phExMain/inc/APP_NxpBuild.h:#define NXPRDLIB_REM_GEN_INTFS PN7462AU_ex_phExVCom/inc/APP_NxpBuild.h:#define NXPRDLIB_REM_GEN_INTFS and it is checked in many places in NFC Reader Library sources: $ grep -r NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/ NxpNfcRdLib/comps/phacDiscLoop/src/phacDiscLoop.c:#ifndef NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phacDiscLoop/src/phacDiscLoop.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ NxpNfcRdLib/comps/phalFelica/src/phalFelica.c:#ifndef NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phalFelica/src/phalFelica.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ NxpNfcRdLib/comps/phalI18000p3m3/src/phalI18000p3m3.c:#ifndef NXPRDLIB_REM_GEN_INTFS NxpNfcRdLib/comps/phalI18000p3m3/src/phalI18000p3m3.c:#endif /* NXPRDLIB_REM_GEN_INTFS */ (...) Best regards, Peppe Re: NXPRDLIB_REM_GEN_INTFS usage Hello, Which version of the library are you using ? Could you please help me with that information and the file where you are seeing this definition ? I was not able to locate the definition you are referring to neither in the  API documentation nor in the library, so it would help me a lot. Regards, Estephania

i.MX95 Boot ROM: Configuring eMMC Boot0/Boot1 as Primary/Secondary and FlexSPI NOR as Recovery Hello Experts, I am trying to understand how the i.MX95 Boot ROM handles the Primary, Secondary, and Recovery boot stages. I have gone through the Reference Manual and some of the U-Boot spl source code, but I am still not clear on how the Recovery boot mechanism is intended to work. My goal is to implement the following boot architecture: Primary boot: eMMC Boot0 Secondary boot: eMMC Boot1 Recovery boot: FlexSPI NOR flash (Golden Recovery Image) While looking through arch/arm/mach-imx/image-container.c, I noticed the following code: printf("Boot stage: "); if (rom_data.boot_stage == 0x6) printf("Primary\n"); else if (rom_data.boot_stage == 0x9) printf("Secondary\n"); else if (rom_data.boot_stage == 0xa) printf("Recovery\n"); else printf("USB Serial Download\n"); Based on this, it appears that the Boot ROM supports four boot stages: Primary, Secondary, Recovery, and USB Serial Download. However, I could not find sufficient information explaining how the Recovery stage is selected or configured. I would appreciate some guidance on the following questions: Is it possible to configure FlexSPI NOR flash as the Recovery boot device while using eMMC Boot0 and Boot1 as the Primary and Secondary boot partitions? If this configuration is supported, what is the recommended way to configure it? What is the sequence followed by the Boot ROM when selecting between the Primary, Secondary, and Recovery boot stages? If both Primary and Secondary boot attempts fail, what conditions trigger the Recovery boot stage? What failure conditions can be intentionally reproduced to simulate Recovery mode during development and validation?  Is there any documentation or application note that describes the Boot ROM boot selection algorithm and Recovery boot flow in detail? Does the boot device fuse configuration (Fuse Mode) play any role in selecting the Recovery boot device? Is the Recovery device determined by the boot device fuses? Or can the Boot ROM automatically switch to a different boot device (such as FlexSPI NOR) even when the boot device is fused to eMMC? Ultimately, my objective is to have the system normally boot from eMMC Boot0, fall back to eMMC Boot1 if necessary, and finally boot a Golden Recovery Image stored in FlexSPI NOR if both eMMC boot partitions are unavailable or invalid. If anyone has implemented a similar boot architecture or can point me to the relevant documentation or application notes, I would really appreciate your guidance. Thank you in Advance ! BR, Arun Kumar

IMXRT 1180ファミリ NXPチームの皆様、こんにちは。 現在、宇宙搭載コンピュータ(OBC)アプリケーションでのNXPマイクロコントローラの評価を進めています。 当初、 i.MX RT1170(MIMXRT1170)を検討しており、評価の際にNXPのドキュメントに 28nm FD-SOIテクノロジで製造されていることが記されていることに気づきました。半導体プロセス技術が当社の応用における重要な評価基準であるため、現在は i.MX RT1180 ファミリーの評価にも関心を持っています。 先に進む前に、 i.MX RT1180の製造工程についてご説明いただければ幸いです。 i.MX RT1180も i.MX RT1170と同様に 28nm FD-SOI技術で製造されているのでしょうか? もしなければ、RT1180に使われたプロセス**テクノロジ**について教えていただけますか? この装置の製造ノードやプロセス**テクノロジ**について言及した公式の**ドキュメント**や**製品**概要はありますか? 公開されているドキュメントを調査しましたが、RT1180プロセス技術に関する公式な声明は見つかりませんでした。 この情報は当社の内部テクノロジ評価および資格確認活動にとって重要であり、皆様からのご指導を大変ありがたいです。 再開まで今しばらくお待ちください。 Re: IMXRT 1180 Family こんにちは、@mayliu1 さん。 迅速な返信と、 i.MX RT1180 が 28nm FD-SOIテクノロジで製造されていることを確認してくださりありがとうございます。 もう一つ、ご説明をいただければ幸いです。これが以下の機器を含む すべての i.MX RT1180ファミリに適用されるのか確認していただけますか? i.MX RT1186 i.MX RT1187 i.MX RT1189 RT1180ファミリの全ての製品が同じ28nm FD-SOIプロセスで製造されている場合、この情報はペリフェラルおよび機能解析を進め、アプリケーションに最適なデバイスを決定するのに役立ちます。 ご確認いただければ幸いです。 再開まで今しばらくお待ちください。 よろしくお願いします、 ルースヴィク・R Re: IMXRT 1180 Family こんにちは、 @ruthvik_1 さん、 私たちの製品にご関心を寄せ、コミュニティをご利用いただき、本当にありがとうございます。 はい。i.MX RT1180は28nmのFD-SOIテクノロジを採用しています。 申し訳ありませんが、現時点ではこの装置の製造ノードやプロセス技術を明示的に言及した公的な公式ドキュメントや製品概要はありません。 お役に立てれば幸いです。 よろしくお願いいたします。 5月