P3B1602 I2C/I3C PCIe CEM仕様準拠 フォーラムの皆様へ PCIe CEM仕様リビジョン6.0.1では、SMBus（I2C）を3.3V、I3Cを1.8Vと定義しています。 P3B1602はI2Cモードで3.3V(内部抵抗で3.3V)で、I3Cモードで1.8Vをサポートしていますか? 両方のモードに対応するには、P3B1602の電源電圧を変更する必要があるということですよね？ ありがとう。 敬具 モーリッツ Re: P3B1602 I2C/I3C PCIe CEM Spec Compliant こんにちは、郭さん  ご説明いただきありがとうございます。 同じSCLとSDAネットで2つのP3B1602を並列に使うことはできますか?ただし、1.8Vと3.3VのVCCB電源を使うことは可能でしょうか。 OEピンでアクティブにするために必要なものだけを抜き取ればいいのでしょうか？ 敬具 モーリッツ Re: P3B1602 I2C/I3C PCIe CEM Spec Compliant こんにちは、モーリッツさん P3B1602両方の電圧レベルをサポートしていますが、同じBサイドバスが3.3 V SMBus/I²Cと1.8V I3Cの間をスイッチする必要がある場合は、対応するVCCBをスイッチし、すべての外部プルアップ抵抗器およびコネクテッド機器のレベル要件を検証する必要があります。 よろしくお願いします！ BR

Clarification regarding Life Cycle change and Debug authentication Hello NXP Support Team, Board: FRDM-MCXE31B  I am working with the NXP FRDM-MCXE31B / MCXE31 and would like to clarify a few points regarding the HSE FW feature flag, password handling, and Secure BAF behavior during Life Cycle (LC) advancement. Could you please clarify the following: Password location when HSE FW feature flag is enabled According to Table 159, when the HSE FW feature flag is enabled, "the password is programmed by HSE firmware at different location” and is scanned by DCM during reset and retained in Standby. Could you please provide the specific address or memory region where the password is programmed by the HSE firmware? Also, which HSE firmware component/version is responsible for programming this password? Behavior of address 0x1B00_0080 When the HSE FW feature flag is enabled, is the password location at 0x1B00_0080 completely ignored by the Secure BAF/DCM, or does it have any role in the authentication process? Password continuity during LC advancement If a password was previously programmed at 0x1B00_0080 while the HSE FW feature flag was disabled, and the device is subsequently configured with the HSE FW feature flag enabled, will the same previously programmed password still be used when advancing the device from OEM_PROD to IN_FIELD? If not, could you please clarify how the password transition/handling is performed in this scenario? HSE FW feature flag enabled without HSE firmware installed Referring to Section 31.4.1 (page 790) and Section 31.4.4.1 (page 793), if the HSE FW feature flag at 0x1B00_0000 is enabled but no HSE firmware is installed, what is the expected behavior of the Secure BAF when an LC advancement is requested through the IVT LCConfig field? Specifically: Does Secure BAF wait for or expect the password at the HSE-managed password location? Can the LC advancement still be performed without HSE firmware? If the LC advancement is successful without HSE firmware, how is debug authentication/password verification handled in this case? A clarification on these points would help us understand the exact password flow and Secure BAF/DCM behavior for different HSE FW configurations. Thank you for your support. Core and Memory Development Board

RTD file Package issue using S32K324 MC Hi Team, I am using S32K324 MC using S32DS.3.6.12 IDE, i have installed all packeges, even i installed RTD( SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite i have installed  this one from NXP website and inserted in IDE then installed). Problem: while creating time the project for S32K324, SDK file is not showing i have check the all possiblities but still not getting please check the bellow image you can get easily.  Please help me to fix this issue. Looking Forward for you response. #S32K3 AUTOMOTIVE-RTD  Re: RTD file Package issue using S32K324 MC hi @danielmartynek  okay, @danielmartynek  thank you for the support. thank you and regards, sunil ladwa Re: RTD file Package issue using S32K324 MC Because the RTD (SDK) 7.0.1 supports GCC 10.2 only, not GCC 11.4. So yes, GCC 10.2 is the only GCC that can be used with RTD 7.0.1. BR, Daniel Re: RTD file Package issue using S32K324 MC Hi @danielmartynek , thank you for you guide, just i have one more question for GCC 11.4 it is not showing i want to know why? and if i select GCC 10.2 is it okay or is it suitable for latest tool and MC? thank you and regard, sunil ladwa. Re: RTD file Package issue using S32K324 MC Hello Sunil Ladwa, Yes, that is correct, select 10.2. Regards, Daniel Re: RTD file Package issue using S32K324 MC hi @danielmartynek , while creating time i got this option like GCC 11.4, GCC 10.2, GCC9.2. is this correct right? if i select the GCC 10.2 i am getting in the SDK package this is correct right? i need your conformation. thank you and regards, sunil ladwa Re: RTD file Package issue using S32K324 MC Hi @sunil0509, Please create a new thread if your follow-up questions are unrelated to the original topic. Regards, Daniel Re: RTD file Package issue using S32K324 MC Hi @sunil0509, Refer to the release notes of the RTD, it supports GCC 10.2: Regards, Daniel Re: RTD file Package issue using S32K324 MC Hi @danielmartynek , i have selected this  one GCC 11.4. it this correct? I also have a small doubt regarding AUTOSAR and RTOS. Is the SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite package applicable to both AUTOSAR and RTOS, or are separate packages required? If separate packages are required, could you please share the download links for both? thank you and regards sunil ladwa Re: RTD file Package issue using S32K324 MC Hi @sunil0509, Which compiler have you selected? The RTD supports GCC 10.2 in S32DS. Regards, Daniel

P3B1602 I2C/I3C PCIe CEM 规范符合 尊敬的论坛成员： PCIe CEM 规范 6.0.1 版定义了 SMBus (I2C) 为 3.3V 和 I3C 为 1.8V。 P3B1602在I2C模式下是否支持3.3V（内部电阻接至3.3V），在I3C模式下是否支持1.8V？ 我想，为了同时满足这两种模式，P3B1602 的供电电压需要改变，对吗？ 谢谢。 此致敬礼 莫里茨 Re: P3B1602 I2C/I3C PCIe CEM Spec Compliant 郭老师您好，  谢谢你的解释。 我可以将两个 P3B1602 并联使用在同一条 SCL 和 SDA 线上，但分别采用 1.8V 和 3.3V 的 VCCB 供电吗？ 只需要拔掉我需要激活的那个引脚，用原厂引脚连接即可？ 亲切的问候 莫里茨 Re: P3B1602 I2C/I3C PCIe CEM Spec Compliant 嗨，莫里茨 P3B1602 支持两种电压等级，但如果同一 B 侧总线需要在 3.3 V SMBus/I²C 和 1.8 V I3C 之间切换，则必须切换相应的 VCCB，并且必须验证所有外部上拉电阻和连接设备的电平要求。 谢谢您！ BR

P3B1602 I2C/I3C PCIe CEM Spec Compliant Dear Forum, PCIe CEM Spec Revision 6.0.1 defines SMBus (I2C) with 3.3V and I3C with 1.8V Does the P3B1602 support 3.3V in I2C mode (internal resistors to 3.3V) and 1.8V in I3C Mode?   I suppose to comply to both modes the supply voltage of P3B1602 needs to be changed, right?  Thank you.  Kind regards Moritz Re: P3B1602 I2C/I3C PCIe CEM Spec Compliant Hi Guo,  thank you for the clarification. Can I use 2 P3B1602 in parallel on the same SCL and SDA nets but with 1.8V and 3.3V VCCB Supply.  Just pulling only the one I need active with the OE pin? Kind regards Moritz Re: P3B1602 I2C/I3C PCIe CEM Spec Compliant HI Moritz P3B1602 supports both voltage levels, but if the same B-side bus needs to switch between 3.3 V SMBus/I²C and 1.8 V I3C, the corresponding VCCB must be switched, and all external pull-up resistors and connected devices' level requirements must be verified. Thanks! BR

使用 S32K324 MC 时出现 RTD 文件包问题 大家好， 我正在使用 S32K324 MC，版本为 S32DS.3.6.12我已经安装了所有软件包，甚至还安装了 RTD（SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite，我是从 NXP 网站安装的，然后插入到 IDE 中安装的）。 问题：在创建S32K324项目时，SDK文件没有显示。我已经检查了所有可能的原因，但仍然找不到。请查看下图，您应该能轻松找到。 请帮我解决这个问题。 期待您的回复。 #S32K3汽车-RTD Re: RTD file Package issue using S32K324 MC 嗨@danielmartynek 好的， @danielmartynek谢谢你的支持。 谢谢，此致敬礼！ 苏尼尔·拉德瓦 Re: RTD file Package issue using S32K324 MC 因为 RTD（SDK）7.0.1 仅支持 GCC 10.2，不支持 GCC 11.4。 所以，是的，GCC 10.2 是唯一可以与 RTD 7.0.1 一起使用的 GCC 版本。 BR，丹尼尔 Re: RTD file Package issue using S32K324 MC 嗨@danielmartynek ， 感谢您的指导，我还有一个关于 GCC 11.4 的问题，它没有显示出来，我想知道为什么？如果我选择 GCC 10.2，可以吗？它是否适用于最新的工具和 MC？ 谢谢，并致以问候。 苏尼尔·拉德瓦。 Re: RTD file Package issue using S32K324 MC 你好，Sunil Ladwa， 是的，没错，选择 10.2。 此致， 丹尼尔 Re: RTD file Package issue using S32K324 MC 嗨@danielmartynek ， 在创建时间时，我得到了类似 GCC 11.4 的这个选项，GCC 10.2，GCC 9.2。 这样对吗？ 如果我选择 GCC 10.2，我会在 SDK 包中获取到它。 这样对吧？我需要你的确认。 谢谢，此致敬礼！ 苏尼尔·拉德瓦 Re: RTD file Package issue using S32K324 MC 嗨@sunil0509 ， 如果您的后续问题与原主题无关，请另开新帖。 此致， 丹尼尔 Re: RTD file Package issue using S32K324 MC 嗨@sunil0509 ， 请参阅 RTD 的版本说明，它支持 GCC 10.2： 此致， 丹尼尔 Re: RTD file Package issue using S32K324 MC 嗨@danielmartynek ， 我选择了 GCC 11.4。 这样对吗？ 我对 AUTOSAR 和 RTOS 也有一些小疑问。 SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite 软件包 是否 同时适用于 AUTOSAR 和 RTOS，还是需要单独的软件包？ 如果需要单独的软件包，能否提供两者的下载链接？ 谢谢，此致敬礼。 苏尼尔·拉德瓦 Re: RTD file Package issue using S32K324 MC 嗨@sunil0509 ， 你选择了哪个编译器？ RTD 支持 S32DS 中的 GCC 10.2。 此致， 丹尼尔

imx8mp Android System Fast Boot Solution 你好！ 我参考Android System Fast Boot Solution - Study and Summary of Hibernate_v1.pdf 在imx8mp android14  源码是source imx-android-14.0.0_1.0.0/imx_android_setup.sh 修改完会出现GPU的报错，详情见附件，这个需要怎么解决

关于禁用 HSE 固件功能标志时 LC 推进和调试认证的说明 您好，NXP支持团队， 板： FRDM-MCXE31B 我正在使用NXP FRDM-MCXE31B / MCXE31 ，需要让该设备经历以下生命周期 (LC) 阶段： CUST_DEL → OEM_PROD → IN_FIELD 就我们的使用场景而言， HSE FW 功能标志将保持禁用状态。 在查阅参考手册时，我发现关于 LC 推进和调试认证方面有一些不太清楚的地方。请问您能否澄清以下问题？ 1. 当 HSE 固件功能标志禁用时，POR 后调试身份验证 根据 参考手册 第 31.9 节 ，当 HSE 固件功能标志被禁用时， 应用程序核心调试始终需要密码认证 ，并且 CUST_DB_PSWD_A 被编程到 0x1B00_0080 。 在这种情况下，一旦调试密码和 LC 配置被编程，上电复位 (POR)后的预期调试认证流程是什么？ 具体来说： DCM/Secure BAF 在 POR 后如何获取和验证调试密码？ 连接调试器时，用户是否需要将密码提供/写入特定的寄存器、内存位置或调试身份验证接口？ 设备会自动从0x1B00_0080读取密码进行比较，还是使用了其他身份验证机制？ 请问 在 HSE 固件功能标志禁用的情况下， POR 后执行调试身份验证 的预期操作顺序是什么？ 2. LC 推进和调试认证的文档 是否有任何应用笔记、用户指南、参考文档或技术说明提供完整的操作步骤： 将 MCXE31 LC 从CUST_DEL → OEM_PROD → IN_FIELD推进。 编程/配置调试密码 每次LC转换后执行调试认证 使用调试器连接到应用程序核心并进行身份验证 我在 安全配置工具指南 中 找不到有关 MCXE31 CPU 这些操作的 具体信息 。 如果 MCXE31 有具体的文档或示例，能否请您提供给我？ 3. 不同生命周期状态下的密码使用情况 设备成功推进至以下位置后： CUST_DEL → OEM_PROD → IN_FIELD 如果 HSE FW 功能标志被禁用，那么 在所有这些 LC 状态下，是否都使用 相同的 CUST_DB_PSWD_A 密码（编程地址为 0x1B00_0080） 进行调试身份验证？ 如果密码行为在LC状态之间发生变化，请您加以说明： 每个LC使用哪个密码/位置？ 每次LC转换后是否可以更改密码？ 进入IN_FIELD阶段后，相同的密码是否仍然有效？ 4. “受信任”设备状态的含义 文档中还提到， 在对密码和 LC 配置进行编程后， 设备将变为“受信任”状态 。 请问“受信任的”在这个语境下具体指的是什么？ 具体来说， “受信任”状态是否表明： 设备是否已成功接受已编程的密码和LC配置？ 设备现在可以进行调试认证了吗？ 该设备已完成特定的网络安全 BAF/DCM 网络安全状态转换？ 或者，“受信任”在 MCXE31 网络安全架构中有不同的含义？ 澄清以上几点将有助于我们了解当HSE FW 功能标志被禁用时，MCXE31 的完整LC 推进 → POR → 调试认证流程。 感谢您的支持。 启动 ROM | 启动配置 | 闪存 安全（Edgelock | 安全启动 | OTP）

RTDファイル MCを使ったパッケージの問題S32K324 チームの皆さん、こんにちは。 私はS32DS.3.6.12を使用してS32K324 MCを使用しています。IDEはすべてのパッケージをインストールしました。RTD(SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesiteもインストールしました。NXPのウェブサイトからインストールしてIDEに挿入し、インストールしました)。 問題:プロジェクトをS32K324作成中にSDKファイルが表示されず、すべての可能性を確認したが、簡単に入手できる下の画像を確認してもらえません。 この問題を解決するのを手伝ってください。 ご回答をお待ちしております。 #S32K3 オートモーティブ-RTD  Re: RTD file Package issue using S32K324 MC こんにちは、 @danielmartynek わかりました、サポート@danielmartynekありがとうございます。 ありがとうございます。 スニル・ラドワ Re: RTD file Package issue using S32K324 MC なぜならRTD(SDKs)7.0.1はGCC 10.2のみをサポートし、GCC 11.4はサポートしていないからです。 SO、GTD 7.0.1で使えるGCCはGCC 10.2だけです。 BR、ダニエル Re: RTD file Package issue using S32K324 MC こんにちは、 @danielmartynek さん、 ガイドをありがとうございます。GCC 11.4についてもう一つ質問があります。表示されないのですが、なぜでしょうか？また、GCC 10.2を選択した場合、最新のツールやMCには適しているのでしょうか？ ありがとうございます。 スニル・ラドワ。 Re: RTD file Package issue using S32K324 MC こんにちは、スニル・ラドワさん。 はい、その通りです。10.2を選択してください。 よろしくお願いいたします。 ダニエル Re: RTD file Package issue using S32K324 MC こんにちは、 @danielmartynek さん、 作成時に、GCC 11.4 のようなオプションが表示されました。GCC 10.2、GCC 9.2。 これは正しいですか？ もしGCC 10.2を選べば、SDKパッケージで入手できます これは正しいですよね？あなたの確認が必要です。 ありがとうございます。 スニル・ラドワ Re: RTD file Package issue using S32K324 MC こんにちは、@sunil0509 さん。 元のトピックと無関係な質問がある場合は、新しいThreadを作成してください。 よろしくお願いいたします。 ダニエル Re: RTD file Package issue using S32K324 MC こんにちは、@sunil0509 さん。 RTDのリリースノートを参照してください。GCC 10.2をサポートしています: よろしくお願いいたします。 ダニエル Re: RTD file Package issue using S32K324 MC こんにちは、 @danielmartynek さん、 私はGCC 11.4を選択しました。 これは正しいですか？ AUTOSARやRTOSについても少し疑問があります。 SW32K3_S32M27x_RTD_R23-11_7.0.1_D2603_DesignStudio_updatesite パッケージはAUTOSARとRTOSの両方に適用できますか?それとも別々のパッケージが必要ですか?もし別々のパッケージが必要な場合は、両方のダウンロードリンクを共有していただけませんか? ありがとうございます。 スニル・ラドワ Re: RTD file Package issue using S32K324 MC こんにちは、@sunil0509 さん。 どのコンパイラを選択しましたか？ RTDはS32DSでGCC 10.2をサポートしています。 よろしくお願いいたします。 ダニエル

关于生命周期变更和调试身份验证的说明 您好，NXP支持团队， 板： FRDM-MCXE31B 我正在使用NXP FRDM-MCXE31B / MCXE31 ，想澄清一些关于HSE FW 功能标志、密码处理以及生命周期 (LC) 升级期间安全 BAF 行为的问题。 请您澄清以下问题： 启用 HSE FW 功能标志后密码位置 根据表 159，当 HSE FW 功能标志启用时，“密码由 HSE 固件在不同位置进行编程” ，并在 RESET 期间由 DCM 扫描并保留在待机状态。 请问能否提供 HSE固件对密码进行编程的 具体 地址或内存区域 ？ 另外，是哪个HSE 固件元器件/版本负责设置此密码？ 地址 0x1B00_0080 的行为 启用 HSE FW 功能标志后， 安全 BAF/DCM 是否完全忽略 0x1B00_0080 处的密码位置，或者它在身份验证过程中是否发挥任何作用？ LC升级过程中密码保持性 如果之前在 HSE FW 功能标志禁用时，在 0x1B00_0080 处编程了一个密码 ，并且随后将设备配置为启用 HSE FW 功能标志，那么 当设备从 OEM_PROD 状态升级到 IN_FIELD 状态 时，是否仍会使用 之前编程的密码 ？ 如果不是，能否请您解释一下在这种情况下密码转换/处理是如何进行的？ 未安装 HSE 固件，但已启用 HSE 固件功能标志 参考 第 31.4.1 节（第 790 页） 和 第 31.4.4.1 节（第 793 页） ，如果 0x1B00_0000 处的 HSE FW 功能标志 已启用，但未 安装 HSE 固件 ，那么当通过 IVT LCConfig 字段 请求 LC 推进时，安全 BAF 的预期行为是什么 ？ 具体来说： Secure BAF 是否等待或期望 HSE 管理的密码位置提供密码？ 不使用 HSE 固件，LC 推进功能还能正常使用吗？ 如果 LC 推进在没有 HSE 固件的情况下成功，那么在这种情况下如何处理调试认证/密码验证？ 对这些要点的澄清将有助于我们了解不同 HSE 固件配置的确切密码流程和安全 BAF/DCM 行为。 感谢您的支持。 核心与内存 开发板

imx8mp Android システムファストブートソリューション 你好！ 我参考Android システム高速ブート ソリューション - Hibernate_v1.pdf の調査と概要 imx8mp android14 で  源码是source imx-android-14.0.0_1.0.0/imx_android_setup.sh GPU の不具合が発生する可能性があるため、アクセサリの修正が完了しました。これには解決が必要です

PCA9451Aの未使用SD機能 こんにちは、 iMX93アプリケーションでSDカードを使うつもりはないので、PCA9451A PMICのスイッチとLDO5ブロックの終端処理方法が気になっています。 1) SW_ENには内部のプルダウン機能があり、I2Cレベルのトランスレーターを使っていないので、SWINも浮かせておくことができますよね?SWOUTピンも接続せずに放置できるのですか? 2) SD_VSELとLDO5はどうすればいいですか？内部に引っ張る抵抗SD_VSEL見当たりません。LDO5は無負荷時でも出力コンデンサが必要なのでしょうか？ 私の応募はかなりスペースが限られているので、できるだけ多くの部品を省きたいと思っています。 Re: Unused SD functionality on PCA9451A はい、これは自分で解決しました。iMX93ハードウェアガイドのチェックリストには次のように記載されています。 「PCA9451AHNY PMICが電力供給に使われる場合は、使用されていなくてもすべてのレギュレーターの出力L/C部品が適切にコネクテッドされていることを確認してください。レギュレータの出力が開いたままになっていると、PMIC全体が誤動作します。 これはPMICのデータシートに記載しておくと役立つ情報だと思います。

Cmake Build Long Paths Issue Bug: MCUXpresso VS Code extension fails to build a valid CMake project due to missing output field in compile_commands.json Product: MCUXpresso for VS Code Component: MCUXpresso extension — Build Project / Windows long-path validation Host OS: Windows 11 Target MCU: NXP i.MX RT1186 (Cortex-M33) Build system: CMake + Ninja Extension version: 26.9.44 Severity: Build operation blocked; workaround available Problem description The MCUXpresso VS Code extension fails to build an otherwise valid CMake project when using the extension's Build Project command. The following error is displayed: The "path" argument must be of type string. Received undefined The error occurs inside the MCUXpresso extension's JavaScript code, rather than in the CMake configuration or build process. The same project builds successfully using both: The standard VS Code CMake Tools build task. The command-line build: cmake --build .\dbe_flexspi_nor_debug --parallel Disabling the MCUXpresso extension's Windows long-path warning completely resolves the issue. Steps to reproduce Open an MCUXpresso SDK v2 freestanding project in VS Code on Windows 11. Use a valid CMakePresets.json containing custom configure and build presets. Configure the project successfully using CMake. Ensure that the generated compilation database (compile_commands.json) contains entries without an output property. Invoke Build Project from the MCUXpresso extension GUI. Actual result: The build operation fails with: The "path" argument must be of type string. Received undefined Expected result: MCUXpresso should accept valid compilation database entries without an output property and execute the build task successfully. Root cause analysis Investigation of the extension's bundled extension.js using Chrome DevTools revealed that the failure occurs during Windows long-path validation, before execution of the actual build task. The relevant code iterates over compilation database entries: for (const entry of result.getDomainEntries()) { if (!entry.error) { if (entry.jsonData.some(item => checkPath(item))) return true; } } The path-checking function (named _S in the minified bundle) contains logic equivalent to: function checkPath(entry) { const outputPath = path.isAbsolute(entry.output) ? entry.output : path.join(entry.directory, entry.output); return isLongPath(entry.file) || isLongPath(outputPath); } The output property is optional in the JSON Compilation Database format. A valid entry may contain only directory, command, and file. However, the extension passes entry.output directly to path.isAbsolute() without verifying that the property exists. For entries without output, this effectively becomes: path.isAbsolute(undefined); Node.js throws a TypeError, which propagates through the MCUXpresso build operation and prevents the build task from running. This appears to be a bug in the extension's long-path validation logic. Confirmed workaround Add the following setting to the workspace's .vscode/settings.json: { "mcuxpresso.long.path.warn": false } Result: The MCUXpresso GUI Build command completes successfully. This confirms that the failure is associated with the extension's long-path validation. Disabling the warning does not require any changes to the CMake configuration or build toolchain. Suggested fix The extension should handle compilation database entries without an output property. Possible approaches include: Check whether entry.output is a non-empty string before calling path.isAbsolute() or path.join(). If output is missing, skip output-path validation for that entry while continuing to validate the source file path. Alternatively, determine the output path from available compilation metadata when possible. Missing optional fields in a valid compilation database should never cause the Build Project command to fail. Additional information The issue was reproduced with custom CMake presets and a successfully configured MCUXpresso SDK project. The build worked through CMake Tools and the command line throughout the investigation. The workaround was verified: setting mcuxpresso.long.path.warn to false restored successful builds through the MCUXpresso GUI. The reported root cause is based on static inspection of the extension's bundled JavaScript and debugger observations. The specific compilation database record triggering the exception was not independently captured. Please consider fixing this in a future release of the MCUXpresso for VS Code extension.

CMake 版本长路径问题 错误：MCUXpresso VS Code 扩展程序由于compile_commands.json 文件中缺少output字段，无法构建有效的 CMake 项目。 产品： MCUXpresso for VS Code 元器件： MCUXpresso 扩展 — 版本项目/Windows 长路径验证 主机操作系统： Windows 11 目标MCU： NXP i.MX RT1186（Cortex-M33） 构建系统： CMake + Ninja 扩展版本： 26.9.44 严重性：版本操作已阻止；有变通方案 问题描述 MCUXpresso VS Code 扩展程序无法对一个原本有效的 CMake 项目进行版本“版本项目”命令时。 显示以下错误信息： The "path" argument must be of type string. Received undefined 错误发生在 MCUXpresso 扩展的 JavaScript 代码中，而不是 CMake 配置或版本过程中。 同一个项目使用这两种方法都能成功构建： 标准的 VS Code CMake 工具构建任务。 命令行版本： cmake --build .\dbe_flexspi_nor_debug --parallel 禁用 MCUXpresso 扩展的 Windows 长路径警告可以彻底解决此问题。 重现步骤 在 Windows 11 上的 VS Code 中打开一个 MCUXpresso SDK v2 独立项目。 使用包含自定义配置和版本预设的有效CMakePresets.json文件。 使用 CMake 成功配置项目。 确保生成的编译数据库（ compile_commands.json ）包含没有output属性的条目。 从 MCUXpresso 扩展 GUI调用版本项目。 实际结果：版本操作失败，并显示以下错误信息： The "path" argument must be of type string. Received undefined 预期结果： MCUXpresso 应接受没有输出属性的有效编译数据库条目，并成功执行构建任务。 根本原因分析 使用 Chrome DevTools 对扩展程序捆绑的extension.js进行调查后发现，故障发生在 Windows 长路径验证期间，也就是在执行实际版本任务之前。 相关代码遍历编译数据库条目： for (const entry of result.getDomainEntries()) { if (!entry.error) { if (entry.jsonData.some(item => checkPath(item))) return true; } } 路径检查函数（在压缩包中名为_S ）包含等价于以下逻辑： function checkPath(entry) { const outputPath = path.isAbsolute(entry.output) ? entry.output : path.join(entry.directory, entry.output); return isLongPath(entry.file) || isLongPath(outputPath); } 在 JSON 编译数据库格式中，输出属性是可选的。一个有效的条目只能包含目录、命令和文件。 但是，该扩展程序直接将entry.output传递给path.isAbsolute()，而没有验证该属性是否存在。 对于没有输出的条目，这实际上就变成了： path.isAbsolute(undefined); Node.js 抛出TypeError，该错误会传播到 MCUXpresso 版本操作中，并阻止版本任务运行。 这似乎是该扩展程序的长路径验证逻辑中的一个错误。 已确认的解决方法 将以下设置添加到工作区的.vscode/settings.json文件中： { "mcuxpresso.long.path.warn": false } 结果： MCUXpresso GUI 版本命令成功完成。 这证实了故障与扩展程序的长路径验证有关。禁用此警告不需要对 CMake 配置或构建工具链进行任何更改。 建议的修复方案 该扩展程序应处理没有输出属性的编译数据库条目。 可能的方法包括： 在调用path.isAbsolute()或path.join()之前，检查entry.output是否为非空字符串。 如果缺少输出，则跳过该条目的输出路径验证，同时继续验证源文件路径。 或者，尽可能根据可用的编译元数据确定输出路径。 有效的编译数据库中缺少可选字段绝不应导致“版本项目”命令失败。 更多信息 使用自定义 CMake 预设和成功配置的 MCUXpresso SDK 项目重现了该问题。在整个调查过程中，版本通过 CMake 工具和命令行完成。 解决方法已验证：将mcuxpresso.long.path.warn设置为false可恢复通过 MCUXpresso GUI 成功构建。 报告的根本原因基于对扩展程序捆绑的 JavaScript 的静态检查和调试器观察结果。未独立捕获到触发信号异常的具体编译数据库记录。 请考虑在 MCUXpresso for VS Code 扩展的未来版本中修复此问题。

Unused SD functionality on PCA9451A Hi, I am not going to use a SD card in my iMX93 application so I am wondering how to terminate the switch and LDO5 block of the PCA9451A PMIC. 1) The SW_EN has an internal pull-down and because I am not using the I2C level translator I can also leave SWIN floating, correct? SWOUT pin can then also be left unconnected? 2) What should I do with SD_VSEL and LDO5? I can't see SD_VSEL having any internal pull resistance? And do LDO5 need to have an output capacitor even when unloaded? My application is quite space constrained so I would like to eliminate as many parts as possible. Re: Unused SD functionality on PCA9451A Ok, I figured out this by myself. The iMX93 Hardware Guide's checklist states: "If the PCA9451AHNY PMIC is used to provide power, ensure that the output L/C components of all regulators are properly connected, even if unused. Leaving any regulator output open causes a malfunction of the whole PMIC." I would think this would be useful information to put in the PMIC's datasheet..

i.MX 95 搭配 PF0900 + 第三方 VDD_SOC/VDD_ARM 稳压器 我们正在设计一款采用 MPF0900AMBA2ES 的 i.MX 95 (MIMX9596CVTXNAC, 15×15 mm, LPDDR4X) 板。MPF5302BMMAAES / MPF5301BMMABES 在我们能找到的所有代理商处都没有库存，因此作为备选方案，我们计划使用 TI TPS62873Z1 降压器作为 VDD_SOC 和 VDD_ARM。如果您能审阅以下几点，或指出我们遗漏之处，我们将不胜感激。如果恩智浦有其他推荐的替代部件，请告诉我！ 使能/排序：PF0900 GPIO3 使能 VDD_SOC 降压，GPIO4 使能 VDD_ARM 降压（A2 OTP，插槽 1 和 5，待机时为低电平），与 EVK 相同。PF0900 在 WDOG_ANY 时对其进行电源循环，符合 IMX95IEC 关于非 NXP PMIC 的说明。 启动电压：VDD_SOC 启动电压为 0.900 V，VDD_ARM 启动电压为 0.875 V（PF5302/PF5301 OTP 启动电压为 0.920 V）。两者均在 PF0900 VMON1/2 窗口（0.900 V，-5 %/+5 %）内。是 0.875–0.900V 是否适用于 ROM 启动，还是启动依赖于 0.92 V？ 暂停：与 EVK 一样，VDD_SOC 降压器关闭，PF0900 LDO3 将 VDD_SOC 保持在 0.65 V。TI 降压器的输出放电在启动时被禁用，因此不会对 LDO3 造成负载（与 PF5302 OTP“PD 电阻未放电”相匹配）。VDD_ARM 已关闭并放电。 系统管理器：我们将替换 brd_sm_voltage.c 中的 PF53 调用。使用 TPS6287x 驱动程序，并在启动时禁用 VMON1/2，就像 EVK 端口所做的那样。SM 中任何其他依赖于 PF53 的内容，例如：故障处理还是PF53信息/传感器路径？ 除了 IMX95IEC 表 30 和 32 之外，VDD_SOC/VDD_ARM 还有其他要求吗？例如负载阶跃转换速率、纹波或 PF53 使用的 AVP？ 谢谢！ PMIC

i.MX 95 with PF0900 + third-party VDD_SOC/VDD_ARM regulators We're designing an i.MX 95 (MIMX9596CVTXNAC, 15×15 mm, LPDDR4X) board with MPF0900AMBA2ES. The MPF5302BMMAAES / MPF5301BMMABES have no distributor stock anywhere we can find, so as a fallback we plan to use TI TPS62873Z1 bucks for VDD_SOC and VDD_ARM. We'd appreciate a review the points below, or anything we've missed. If there are other parts NXP recommends instead, please let me know! Enable/sequencing: PF0900 GPIO3 enables the VDD_SOC buck, GPIO4 the VDD_ARM buck (A2 OTP, slots 1 and 5, low in standby), as on the EVK. The PF0900 power-cycles them on WDOG_ANY, meeting the IMX95IEC note on non-NXP PMICs. Start-up voltage: VDD_SOC starts at 0.900 V and VDD_ARM at 0.875 V (the PF5302/PF5301 OTP boot at 0.920 V). Both are inside the PF0900 VMON1/2 window (0.900 V, −5 %/+5 %). Is 0.875–0.900 V acceptable for ROM boot, or does boot rely on 0.92 V? Suspend: as on the EVK, the VDD_SOC buck turns off and PF0900 LDO3 holds VDD_SOC at 0.65 V. The TI buck's output discharge is disabled at boot so it doesn't load LDO3 (matching the PF5302 OTP "PD resistor not discharged"). VDD_ARM is off and discharged. System Manager: we'll replace the PF53 calls in brd_sm_voltage.c with a TPS6287x driver, and disable VMON1/2 at boot as the EVK port does. Anything else in the SM that depends on the PF53, e.g. fault handling or the PF53 info/sensor paths? Are there any VDD_SOC/VDD_ARM requirements beyond IMX95IEC Tables 30 and 32: load-step slew, ripple, or the AVP the PF53 uses? Thank you! PMIC

PCA9451A 上未使用的 SD 功能 您好， 在我的 iMX93 应用中，我不会使用 SD 卡，所以我想知道如何端接 PCA9451A PMIC 的开关和 LDO5 模块。 1) SW_EN 内部有下拉电阻，而且因为我没有使用 I2C 电平转换器，所以我也可以让 SWIN 浮空，对吗？那么SWOUT引脚也可以保持未连接状态吗？ 2) 我应该如何处理 SD_VSEL 和 LDO5？我看不出 SD_VSEL 有任何内部拉电阻？即使空载，LDO5 也需要输出电容吗？ 我的应用程序空间非常有限，所以我希望尽可能地精简组件。 Re: Unused SD functionality on PCA9451A 好吧，我自己想明白了。iMX93硬件指南的检查清单中指出： “如果使用PCA9451AHNY PMIC供电，请确保所有稳压器的输出L/C元器件连接正确，即使未使用。任何一个稳压器输出端开路都会导致整个电源管理集成电路（PMIC）故障。 我认为这些信息应该添加到电源管理集成电路（PMIC）的数据手册中。

Clarification on LC Advancement and Debug Authentication with HSE FW Feature Flag Disabled Hello NXP Support Team, Board: FRDM-MCXE31B  I am working with the NXP FRDM-MCXE31B / MCXE31 and need to advance the device through the following Life Cycle (LC) states: CUST_DEL → OEM_PROD → IN_FIELD For our use case, the HSE FW feature flag will remain disabled. While referring to the Reference Manual, I found a few points regarding LC advancement and debug authentication that are not completely clear. Could you please clarify the following? 1. Debug authentication after POR when HSE FW feature flag is disabled According to Section 31.9 of the Reference Manual, when the HSE firmware feature flag is disabled, application-core debug always requires password authentication, and CUST_DB_PSWD_A is programmed at 0x1B00_0080. In this scenario, once the debug password and LC configuration have been programmed, what is the expected debug-authentication flow after a Power-On Reset (POR)? Specifically: How does the DCM/Secure BAF obtain and verify the debug password after POR? When connecting with a debugger, does the user need to provide/write the password to a specific register, memory location, or debug-authentication interface? Is the password automatically read from 0x1B00_0080 by the device for comparison, or is there another authentication mechanism involved? Could you please provide the expected sequence of operations for performing debug authentication after POR when the HSE FW feature flag is disabled? 2. Documentation for LC advancement and debug authentication Is there any application note, user guide, reference documentation, or technical note that provides a complete procedure for: Advancing the MCXE31 LC from CUST_DEL → OEM_PROD → IN_FIELD Programming/configuring the debug password Performing debug authentication after each LC transition Connecting to and authenticating the application core using a debugger I could not find specific information for the MCXE31 CPU regarding these operations in the Secure Provisioning Tool Guide. If there is a specific document or example available for MCXE31, could you please point me to it? 3. Password usage across different Life Cycle states After successfully advancing the device through: CUST_DEL → OEM_PROD → IN_FIELD with the HSE FW feature flag disabled, is the same CUST_DB_PSWD_A password programmed at 0x1B00_0080 used for debug authentication in all of these LC states? If the password behavior changes between LC states, could you please clarify: Which password/location is used in each LC? Whether the password can be changed after each LC transition? Whether the same password remains valid after advancing to IN_FIELD? 4. Meaning of "Trusted" device status The documentation also refers to the device becoming "Trusted" after programming the password and LC configuration. Could you please clarify what "Trusted" means in this context? Specifically, does the Trusted status indicate that: The device has successfully accepted the programmed password and LC configuration? The device is now ready for debug authentication? The device has completed a specific Secure BAF/DCM security state transition? Or does "Trusted" have a different meaning in the MCXE31 security architecture? A clarification of the above points would help us understand the complete LC advancement → POR → debug authentication flow for MCXE31 when the HSE FW feature flag is disabled. Thank you for your support. Boot ROM|Booting | Flash Security(Edgelock | secure boot | OTP)

imx8mp 安卓系统快速启动解决方案 你好！ 我参考Android系统快速启动解决方案-Hibernate_v1的学习与总结.pdf 在imx8mp android14  是源码imx-android-14.0.0_1.0.0/imx_android_setup.sh 修改完成会出现GPU的报错，详情见附件，这个需要怎么解决