关于禁用 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） Re: Clarification on LC Advancement and Debug Authentication with HSE FW Feature Flag Disabled 你好@KPAKHIL 您似乎已经在私人工单中提交了相同的问题。 我已在私信中回复了您。   谢谢！   BR 爱丽丝

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 行为。 感谢您的支持。 核心与内存 开发板 Re: Clarification regarding Life Cycle change and Debug authentication 你好@KPAKHIL 您似乎已经在私人工单中提交了相同的问题。 我会通过私信逐一回复他们。   谢谢！   BR 爱丽丝

imx8mp Android システムファストブートソリューション 你好！ 我参考Android システム高速ブート ソリューション - Hibernate_v1.pdf の調査と概要 imx8mp android14 で  源码是source imx-android-14.0.0_1.0.0/imx_android_setup.sh GPU の不具合が発生する可能性があるため、アクセサリの修正が完了しました。これには解決が必要です Re: imx8mp Android System Fast Boot Solution こんにちは@jieh朱 デフォルトのBSP GPUドライバコードは、GPUの休止状態および電源投入時の実行をサポートしていません。NXPはこの点についてテストを行っていません。`echo mem`の電源投入/電源オフ時の処理については参考になりますが、`echo disk`では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. Re: Cmake Build Long Paths Issue Hi @alexander_safonov , Thank you for your patience and for reporting this issue. I have confirmed with our internal team that the issue has been acknowledged and is planned to be addressed in a future update.  Thank you again for your valuable feedback and understanding.   Wish you a nice day.   Best Regards May Liu

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 扩展的未来版本中修复此问题。 Re: Cmake Build Long Paths Issue 嗨@alexander_safonov ， 感谢您的耐心等待并报告此问题。 我已经与内部团队确认，他们已经意识到这个问题，并计划在未来的更新中解决。 再次感谢您宝贵的反馈和理解。   祝你今天过得愉快。   顺祝商祺！ 刘梅

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 Re: i.MX 95 with PF0900 + third-party VDD_SOC/VDD_ARM regulators 你好， 很遗憾，我们没有这些调节器的替代品。 1. 为了保证处理器电源转换的顺利进行，需要遵循以下使能/排序规则，请按照设计指南进行操作。 2. 只要在规格范围内，就是可以接受的。 3. 这样可以。 4. 请记住，系统管理器中存在多个初始化、电源转换、中断等。从 PF53 控制器移植到第三方控制器需要考虑。很遗憾，我们没有针对此特定零件编号的移植指南。 5.您可以参考PF53 数据手册中的“典型性能曲线”部分来获取这些数值。 顺祝商祺！

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 Re: i.MX 95 with PF0900 + third-party VDD_SOC/VDD_ARM regulators Hello, Unfortunately, we do not have replacements for these regulators. 1. Following enable/sequencing is needed to warranty power transitions in the processor, please follow them according to the design guidelines. 2. It is acceptable while you are into the specification range. 3. This is ok. 4. Keep in mind that there are several initializations, power transitions, interrupts, etc. in system manager. Porting from PF53 regulators to third party regulators that needs to be considered. Unfortunately, we do not have a porting guide for this specific part number. 5. You can use PF53 datasheet in section "Typical performance curves" as reference to get these values. Best regards.

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) Re: Clarification on LC Advancement and Debug Authentication with HSE FW Feature Flag Disabled Hello @KPAKHIL  It seems you submitted the same questions in the private ticket. I have replied you in the private ticket.   Thank you.   BR Alice

imx8mp 安卓系统快速启动解决方案 你好！ 我参考Android系统快速启动解决方案-Hibernate_v1的学习与总结.pdf 在imx8mp android14  是源码imx-android-14.0.0_1.0.0/imx_android_setup.sh 修改完成会出现GPU的报错，详情见附件，这个需要怎么解决 Re: imx8mp Android System Fast Boot Solution Hi @jieh朱  默认BSP的GPU驱动代码不支持GPU休眠重新上电执行，NXP没有测试过。可以参考 echo mem 的上下电处理，但 echo disk 必须单独验证 GPU 驱动和缓冲区的恢复。 Best Regards, Zhiming

CMakeビルドにおける長いパスの問題 バグ: MCUXpresso VS Code拡張機能が、 compile_commands.jsonに出力フィールドが欠落しているため、有効なCMakeプロジェクトをビルドできない。 製品: MCUXpresso for VS Code コンポーネント: MCUXpresso拡張 — ビルドプロジェクト / Windowsロングパス検証 ホストOS: 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 エラーは、CMakeの設定やビルドプロセスではなく、MCUXpresso拡張機能のJavaScriptコード内で発生します。 同じプロジェクトは、どちらの方法でも正常にビルドできます。 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 ）に、出力プロパティを持たないエントリが含まれていることを確認してください。 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コンパイルデータベース形式では、outputプロパティはオプションです。有効なエントリには、 directory 、 command 、 fileのみを含めることができます。 しかし、この拡張機能は、プロパティが存在するかどうかを検証することなく、 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 Toolsとコマンドラインの両方でビルドが正常に動作しました。 回避策が検証されました。mcuxpresso.long.path.warn を false に設定することで、 MCUXpresso GUI を介したビルドが正常に復元されました。 報告された根本原因は、拡張機能にバンドルされているJavaScriptの静的解析とデバッガーによる観測に基づいています。例外を引き起こした特定のコンパイルデータベースレコードは、個別に取得されませんでした。 FUTUREのMCUXpresso for VS Code拡張機能のリリースでこの問題の修正を検討してください。 Re: Cmake Build Long Paths Issue こんにちは、 @alexander_safonov さん。 ご辛抱いただき、またこの問題をご報告いただき、ありがとうございました。 社内チームに確認したところ、この問題は認識されており、FUTUREアップデートで対処する予定です。 貴重なご意見とご理解をいただき、改めて感謝申し上げます。   良い一日をお過ごしください。   よろしくお願いいたします。 メイ・リウ

KITPF0100EPEVBE KITPF0100EPEVBE評価ボード用の回路図ファイルをお願いします。おそらくCadence OrCad形式で。DSN形式で。 よろしくお願いします。 Re: KITPF0100EPEVBE こんにちは、ミエルコ 直接あなたのメールアドレスに送ります。

imx7ulp A7 配置 IOMUXC0 上的焊盘（LPUART0–3 和 I2C） 你好， 我们是学生，正在开发一块定制的imx7ulp (MCIMX7U3)板。我们希望使用Linux (A7) 系统来控制全部8个LPUART接口以及一些I2C线路。 LPUART4–7 使用 IOMUXC1（A7 功能域），在我们的 DTS 中工作正常。但是，LPUART0–3 和我们的 I2C 线使用IOMUXC0（M4 功能域）中的焊盘。 查看 Linux pinctrl 驱动程序和 U-Boot 源代码，似乎 A7 默认使用 IOMUXC1，而 U-Boot 使用特定的IOMUX_CONFIG_MPORTS标志来访问 IOMUXC0。参考手册也提到 IOMUXC 是“所有权受限”的。 我们卡在了 IOMUXC0 的引脚配置步骤。 我们的疑问： A7 是否有支持的方法（通过 DTS 节点或驱动程序标志）直接从 Linux 配置 IOMUXC0 焊盘？ 如果不是，M4 固件的标准预期流程是否是在启动期间复用这些引脚，然后 A7 接管 UART/I2C 控制器？ 由于障碍在于焊盘控制器（而不是外设协议），我们可以假设 I2C 线路面临与 UART 完全相同的限制吗？ 非常感谢您能就此方面的标准做法提供一些指导。 补充信息：我们的 Linux 系统基于 Wrynrose Yocto 版本，并使用 NXP 电路板支持包。

EB代码激活失败，许可证激活码无法使用。 你好， 我正在尝试激活 EB Tresos Studio 27.1.0。使用我的 NXP 软件帐户中提供的激活码，有效期至 2026 年 12 月 31 日。 但是，激活失败，并出现以下错误： 错误：flxActAppActivationSend (50040, 41147, 10248) 指定的数量超过了允许的最大数量（0）。 请您检查一下许可证是否已用完，并提供更新后的激活码？ 谢谢你！ Re: EB code failed activate code for license 嗨@Cip 给您带来的不便，我们深表歉意！ 我已经将此问题报告给相关团队；请等待他们更新网页上的激活码。 顺便一提，NXP 为 EB Tresos 提供免费评估许可证。生产许可证需要向Elektrobit公司订购。 此致敬礼， Robin Re: EB code failed activate code for license 激活码已更新。 谢谢你！

请求提供 MR-CANHUBK344 的已归档 S32K3 FreeRTOS 2.0.0 软件包 你好， 我正在使用 NXP MR-CANHUBK344 评估板，我需要 NXP 原始示例项目所需的已归档的 FreeRTOS 软件包。 所需文件： SW32K3_FreeRTOS_10_4_6_UOS_2_0_0_DS_updatesite_D2204.zip 我的环境： 电路板：MR-CANHUBK344 MCU：S32K344 S32 设计工作室：3.4 S32K3 开发包：3.4.3 S32K3 RTD AUTOSAR 4.4：2.0.0 我已经下载了所需的 S32DS、S32K3 开发包和 RTD 版本，但是 FreeRTOS 2.0.0 在下载门户中已不再提供。 请问您能否提供对已存档的 FreeRTOS 2.0.0 软件包的访问权限，或者为我的 NXP 帐户启用该软件包？ 谢谢！ Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 嗨@lxndrkurus 您无法查看该产品，因为它已被存档。这意味着其中可能存在无法修复的漏洞。我们通常建议客户使用新版本。 但是，如果您坚持要测试旧版本，请稍等片刻，我会联系内部团队，让他们将软件添加到您的帐户中。 此致， 罗宾 Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 @lxndrkurus前往： 汽车软件 - S32K3 标准软件->汽车软件 - S32K3 - FreeRTOS ->上一版本：SW32K3_FreeRTOS_10.4.6_2.0.0_D2204 Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 嗨@lxndrkurus 现在应该已经添加到您的账户中了。请注意，您所请求的产品——SW32K3_FreeRTOS_10.4.6_2.0.0_D2204——已被归档，这意味着任何现有的错误都可能无法修复。 请点击“S32K3 参考软件-> 汽车软件 - S32K3 - FreeRTOS -> 上一版本 -> 2.0.0 SW32K3_FreeRTOS_10.4.6_2.0.0_D2204”进行下载。 此致敬礼， Robin

MR-CANHUBK344用のアーカイブされたS32K3 FreeRTOS 2.0.0パッケージのリクエスト こんにちは、 私はNXP MR-CANHUBK344評価ボードを使っており、元のNXPサンプルプロジェクトに必要なアーカイブ済みFreeRTOSパッケージが必要です。 必須ファイル: SW32K3_FreeRTOS_10_4_6_UOS_2_0_0_DS_updatesite_D2204.zip 私の環境： 基板: MR-CANHUBK344 MCU:S32K344 S32 Design Studio:3.4 S32K3開発パッケージ:3.4.3 S32K3 RTD AUTOSAR 4.4: 2.0.0 必要なS32DS、S32K3開発パッケージ、RTD版はすでにダウンロード済みですが、FreeRTOS 2.0.0はダウンロードポータルからは利用できません。 このアーカイブ済みFreeRTOS 2.0.0パッケージへのアクセス権を提供できるか、私のNXPアカウントで有効にしていただけますか? よろしくお願いします。 Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 こんにちは、 @lxndrkurus さん 製品はアーカイブされているため、見ることができません。つまり、修正されないバグが存在する可能性があるということです。通常、お客様に新しいバージョンの使用を推奨しています。 ただし、どうしても古いバージョンのテストを希望する場合は、内部チームに連絡してソフトウェアをアカウントに追加してもらうまでお待ちください。 よろしくお願いします、 ロビン Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 @lxndrkurusアクセス先: 自動車ソフトウェア - S32K3標準ソフトウェア - > 自動車ソフトウェアソフトウェア - S32K3 - FreeRTOS ->  前回:SW32K3_FreeRTOS_10.4.6_2.0.0_D2204 Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 こんにちは、 @lxndrkurus さん もうあなたのアカウントに追加されているはずです。ご要望の製品であるSW32K3_FreeRTOS_10.4.6_2.0.0_D2204はアーカイブされており、既存のバグは修正されない場合がありますのでご注意ください。 ダウンロードは S32K3 参考ソフトウェア - > オートモーティブ SW - S32K3 - FreeRTOS - > 前回 - > 2.0.0 SW32K3_FreeRTOS_10.4.6_2.0.0_D2204 よろしくお願いいたします ロビン

Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 Hello, I am using the NXP MR-CANHUBK344 evaluation board and I need the archived FreeRTOS package required by the original NXP example project. Required file: SW32K3_FreeRTOS_10_4_6_UOS_2_0_0_DS_updatesite_D2204.zip My environment: Board: MR-CANHUBK344 MCU: S32K344 S32 Design Studio: 3.4 S32K3 Development Package: 3.4.3 S32K3 RTD AUTOSAR 4.4: 2.0.0 I have already downloaded the required S32DS, S32K3 Development Package and RTD versions, but FreeRTOS 2.0.0 is no longer available in the download portal. Could you please provide access to this archived FreeRTOS 2.0.0 package or enable it for my NXP account? Thank you. Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 Hi @lxndrkurus  You cannot see the product because it is archived. It means there can be bugs in it, that will not be fixed. We usually recommend that customers use the newer version. However, if you insist on testing the older version, then please wait while I contact the internal team to have them add the software to your account. Best Regards, Robin Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 @lxndrkurus  Go to: Automotive SW - S32K3 Standard Software -> Automotive SW - S32K3 - FreeRTOS ->  Previous: SW32K3_FreeRTOS_10.4.6_2.0.0_D2204 Re: Request for archived S32K3 FreeRTOS 2.0.0 package for MR-CANHUBK344 Hi @lxndrkurus  It should have been added to your account by now. Please note that the product you are requesting—SW32K3_FreeRTOS_10.4.6_2.0.0_D2204—has been archived, which means that any existing bugs may not be fixed. Please download it by click S32K3 Reference Software -> Automotive SW - S32K3 - FreeRTOS -> Previous -> 2.0.0 SW32K3_FreeRTOS_10.4.6_2.0.0_D2204 Best Regards, Robin