MCXW727CMFTBT — 出厂空白设备上的 SWD 连接失败（2 台设备，故障相同） 我们无法与任何MCXW727CMFTBT 样品（2 个单元，定制板）建立 SWD 调试连接，而完全相同的探针/电缆/设置却能立即连接到其他方面完全相同的板（相同的原理图，相同的物料清单，只有 MCU 不同）上的 MCXW716C。 元件： MCXW727CMFTBT，HVQFN-48封装，日期代码9D2604，批号PF2R73.00；板：定制PCB（10引脚Cortex调试SWD，无ISP按钮），出厂空白/从未编程； SDK： MCUXpresso SDK 26.06.00 — 应用程序构建/链接正常，故障仅在调试连接阶段出现。 症状 使用 NXP LinkServer 25.12.83 和正版 SEGGER J-Link Plus 均出现完全相同的故障：   LinkServer: Error: Wire Ack Fault - target connected? Ed:02: Failed on connect: Ee(42). No connection to chip's debug port J-Link: device MCXW727C_M33_0 / connect (VTref correctly read at 3.025V) ERROR: Wrong DM-AP IDCODE detected: 0xFFFFFFFF LinkServer 自身的 MCXW7XX 预连接脚本 (LS_preconnect_MCXW7XX.scp) 会自动发出调试会话请求 — 但仍然失败。nxpdebugmbox (SPSDK) 手动启动调试会话也失败，出现相同的 WIRE ACK FAULT 错误。 已经排除 探头/电缆/适配器：已确认工作正常（同样的配置连接到MCXW716C也没问题） MCU 端的 VDD_IO / P3V3：~3.3V，正确 SWDIO/SWDCLK 连续性：良好 VDD_CORE（内部 低压差线性稳压器(LDO)）：1.065V，在范围内 RESET_b 处于静止状态，电缆拔出：读取0V而不是预期的内部上拉 ~3.3V（参考）。手册第22.3.1节）— 两个单元 连接尝试期间，强制外部将 RESET_b 设置为 3.3V（VTref 读取正确为 3.025V）：无变化，仍然失败，并出现相同的错误：DM-AP IDCODE 错误 0xFFFFFFFF 在两台独立的物理设备/两块独立的电路板上均可复现。 相关帖子 这里报告了完全相同的错误（DM-AP IDCODE 0xFFFFFFFF），设备名称相同，但情况不同（板卡工作正常，但在擦除/重新编程周期后损坏）： FRDM-MCXW72 不再连接。我们的设备从未进行过任何刷机，因此如果像该帖子所暗示的那样与 NBU/核心状态有关联，那么它显然也会影响客户从未触碰过的设备。 问题 对于早期生产的 MCXW727CMFTBT（批号 PF2R73.00），是否存在任何已知的勘误/启动配置要求/默认生命周期状态，导致在标准调试邮箱程序之外的空白设备上阻止 SWD 操作？ 两个单元的 RESET_b 在静止状态下读数均为 0V（与文档中记录的内部上拉电阻相反）——是该批次产品的制造问题，还是上电时会有其他因素驱动该引脚？ 针对这种情况，有没有不需要基于UART的ISP（我们的板子没有板载USB-UART桥接器）的推荐恢复方法？ 乐意根据要求提供完整日志、示波器捕获或其他任何有用的信息。 协议：BLE -> 连接性 协议：Thread Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 感谢您的快速跟进！ 为了澄清，我们使用两种探针分别进行了测试，每种探针都使用各自合适的工具——没有将 LinkServer 与 J-Link 探针混用： NXP MCU-Link Pro ，通过LinkServer 25.12.83访问，通过 MCUXpresso for VS Code 调试/闪存集成（它会在底层启动 LinkServer 的 gdbserver/flash-programmer）。这是我们日常的正常工作安排。 结果：线路确认故障 - 目标已连接？/ Ed:02: 连接失败: Ee(42)。无法连接到芯片的调试端口，即使 LinkServer 自动运行其 MCXW7XX 特定的预连接脚本（LS_preconnect_MCXW7XX.scp，该脚本会发出调试会话请求）时也是如此。 一个独立的、正品的SEGGER J-Link Plus （固件 V11.00）+ J-Link Adapter CortexM（20 针 → 10 针 0.05 英寸），通过J-Link Commander V9.74直接访问（而不是通过 LinkServer）。 结果：错误：检测到错误的 DM-AP IDCODE：连接时为 0xFFFFFFFF，VTref 已正确读取为 3.025 V。 我们专门进行了第二次测试，以排除任何 LinkServer/MCU-Link 特有的问题。使用完全相同的 J-Link Plus + 适配器 + 电缆 + 实验室电源设置，仅将目标板更换为我们的 MCXW716C 型号（PCB 相同，只有 MCU 不同）， J-Link Commander 连接成功并识别出 Cortex-M33 内核——因此确认探针、电缆、适配器和工具工作正常；故障似乎是 MCXW727C 部件/板特有的。 我们还没有专门尝试过 J-Flash 或 LinkFlash，只尝试过 J-Link Commander（连接）和 LinkServer 的内置“调试”和“恢复”闪存编程器模式——如果这有助于进一步缩小问题范围，我们很乐意尝试其中任何一个。 与我们联系，如果需要提供任何其他信息或日志。 顺祝商祺！ Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好@Rwaka ，希望你一切都好。 为了更好地了解您观察到的现象，请您确认一下，在每种情况下，您是否都使用了外部 J-Link 调试器？或者您是否也尝试过使用 MCU-Link Pro？ 此外，请提供您用于通过 SWD 访问的工具（LinkFlash、J-Flash、J-Link Commander），因为 Linkserver 是用于启动和管理 NXP 调试探针的 GDB 服务器的实用程序（例如，因此，MCU-Link Pro），预计 Linkserver 不会检测到 J-Link 探针。J-Link Plus 探针只能与 J-Link Commander/J-Flash 工具一起被检测到和使用。 Re: MCXW727CMFTBT — SWD connection fails on factory-blank devices (2 units, identical failure) 你好@Rwaka ，感谢你提供补充信息。 我注意到您提到 Reset_b 信号读数为 0V，这意味着设备处于持续 RESET 状态。鉴于此，我将提出一些问题，以帮助进一步分析观察到的行为： 请问MCU的PTD0/RESET_b引脚是否连接了任何硬件/电路？它浮空吗？ VDD_IO_D 轨电压测量结果是否正常？因为该电源域驱动复位系统上的电压。有关电源管理硬件建议，您可以参考AN14742 。 您能否测量 RESET_b 引脚的电阻？如果可以，请提供测量值。 当您从外部执行强制复位时，是否将外部电压直接连接到复位引脚？ 请告知我所需信息。

IMXRT1024でヒューズを焼損させずにHABをテストする 署名のないledのblinkyコードを使ってHAB監査API(報告状況と報告イベント情報)を実装しました。EVKボードは開いており、ヒューズも焼けていません 署名なしイメージ(CSF=0) - HABが4イベント情報で失敗 署名画像 - HAB パス0イベント情報 なので、ボードでもオープンHAB認証が実行されているのでイベント情報が見られると仮定しました。 しかし今回は同じIVT(CSF=0)でプロジェクトファームウェアを使い、同じHAB監査を実施しました 署名なし画像 - 0 イベント情報 のHABパス リードされた点滅ログ(署名なし): RVTヘッダー 0x 2002c0: tag=0xdd len=0x 038 par=0x43 HAB:RVTバージョン=0x 40305 居住区:report_status() = 0x33(HAB_FAILURE) HAB: config = 0xf0(HAB_CFG_OPEN) HAB: state = 0x66(HAB_STATE_NONSECURE) HAB: event[0], 8バイト HAB: hdr: tag=0xdb len=0x 0 8 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x22(HAB_INV_ADDRESS) context=0x a(HAB_CTX_AUTHENTICATE) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 8 43 33 22 a 0 HAB: event[1], 20バイト HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) コンテキスト=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 0 60 0 10 0 0 0 0 20 HAB: event[2], 20バイト HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) context=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 60 0 10 20 0 0 0 1 HAB: event[3], 20バイト HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) コンテキスト=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 0 60 0 20 0 0 0 4 HAB: VERDICT = 4 イベント情報 記録済み -- 上記のデコード済みフィールドを参照 私のプロジェクトファームウェア(署名なし) HAB: RVTヘッダー 0x002002c0 HAB: tag=0xdd len=0x0038 par=0x43 HAB:RVTが確認され有効 居住区:RVTバージョン=0x00040305 居住区:report_status() = 0xf0 HAB: config = 0xf0 HAB: state = 0x66 HAB: 監査イベント情報やクエリなし... HAB: report_event(idx=0) 0x33返されました(イベント情報やクエリなし) HAB: VERDICT = PASS(監査イベント情報なし) なぜ違いがあるのか Re: Test HAB on IMXRT1024 without burning fuses こんにちは、 @Abhay2080 さん。 ご連絡ありがとうございます！LED点滅コードが入っているSDK版と、画像作成に使われているSPT版の両方をいただけますか? ご辛抱いただきありがとうございます！ すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: Test HAB on IMXRT1024 without burning fuses これはSDKバージョンです - SDK_25_06_00_MIMXRT1024xxxxx SPTバージョン - 26.06 MCU xpresso - v25.6.136 MCU Xpressoでコンパイルした場合、LED Blinky用の署名なし画像はSPTとCST 4.0の両方で作成されます Re: Test HAB on IMXRT1024 without burning fuses こんにちは、 @Abhay2080 さん。 情報と詳細なログをありがとうございます。これは素晴らしい観察結果で、違いはIVT内のCSFポインタがゼロかゼロでないかという一点に集約されます。 HABv4が認証を決定する方法 i.MX RT10xxでは、ブートROMは認証を試みるかどうかを判断する前にIVTのCSFフィールドを確認します。 CSF = 0x00000000 (null)の場合、HABは認証を完全にスキップし、イベント情報は記録されず report_status() 0xf0 (HAB_SUCCESS)を返します。これはセキュリティ上の「合格」ではありません。認証は一度も試みられていません。 CSF = non-zero (CSF領域を指す場合):HABは認証を試みます。署名が欠落または無効の場合、失敗イベント情報が記録され、 report_status() は 0x33 (HAB_FAILURE)を返します。オープンボードの場合、これはブートを停止させません。 なぜLED点滅(署名なし)が4つの故障イベント情報を示したのか あなたのLED点滅バイナリはMCUXpresso IDEによって構築され、その後SPT(Secure Provisioning Tool)で処理されてブート可能なイメージが作成されました。「署名なし」ビルドタイプの場合でも、SPTのブートイメージパイプラインは、ゼロ以外のCSFポインタをIVTに書き込み、イメージ内にCSF領域を予約します。Boot ROMは非ゼロポインタを発見し、認証を試みましたが有効な署名データは見つからず、4つのイベントを記録しました。 イベント情報0( HAB_INV_ADDRESS / HAB_CTX_AUTHENTICATE 😞 HABは認証のために画像を探しましたが、無効なアドレスに遭遇しました。これは空のCSF領域と一致します。 イベント情報1–3( HAB_INV_ASSERTION / HAB_CTX_ASSERT 😞 HABによる画像領域に対する内部検証は、実際の脳脊髄液データが存在しないため失敗しました。 なぜプロジェクトのファームウェア(署名なし)にイベント情報が0と表示されたのか あなたのプロジェクトファームウェアは、SPTの起動可能なイメージ生成ステップ を経ずに 、MCUXpresso IDEを通じて直接コンパイルされました。結果として得られるバイナリには、IVT内に真のヌルCSFポインタが含まれています。Boot ROMは CSF = 0 を認識し、認証を完全にスキップし、HABはクリーンな報告をします。ログの report_event(idx=0) からの 0x33 リターンは「このインデックスにイベント情報なし」(つまり、クエリ自体が何も保存されていないため返HAB_FAILURE)を意味しており、HABが故障を検出したわけではありません。 確認の簡単な方法 バイトオフセット +0x18 （CSFフィールド）で、両方のバイナリのIVTを調べます。 SPT製LED点滅：ゼロ以外の値（例： 0x60006xxx または類似のフラッシュアドレス） プロジェクトファームウェア: 0x00000000 プロジェクトのファームウェアで HAB 監査を適切にテストするには 起動可能なイメージはSPT(またはelftosb/nxpimage)でビルドし、CSF領域をイメージに埋め込む必要があります。署名なしビルドでも同様です。これにより、Boot ROMが認証を試み、HABイベント情報が生成されます。そうして初めて、HAB監査コードはテスト目的のための有意義なデータを収集できるようになります。 まとめると、HAB認証はオープンボード上で動作するというあなたの最初の仮定は正しいですが、それはIVTに非ゼロのCSFポインタが存在する場合に限られます。プロジェクトのファームウェアで観察された動作は想定どおりであり、正しいものです。 これで少しでも分かりやすくなれば幸いです！他に質問があればお知らせください。   すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 ------------------------------------------------------------------------------- Re: Test HAB on IMXRT1024 without burning fuses はい、Kan_Liあなたが言った説明は正しいですが、正しいシナリオは私たちにとってです。 LED点滅(署名なし)-> このバイナリiはMCU Xpresso IDEのみで生成(SPT経由は処理していません)。サイズ - 30KB そして、LED点滅（符号なし）と私のプロジェクト（符号なし）の両方のIVTを比較しても、両方ともまったく同じIVT（CSF=0）でした。サイズ 64KB 16進数比較を参照 左側はLED点滅、右側は私のプロジェクトのファームウェアです また、ヒューズを焼損させずにHABを正しくテストする方法についても教えてください。 Abhay2080_0-1788931301704.pngAbhay2080_0-1788931301704.png

i.MX8QXP C0：崩溃证据捕获 ramoops 跨越 SCwatchdogresetCortex-M4 监督 A35 集群 NXP团队您好， 平台详情： SoC：i.MX8QXP C0，基于 MEK 参考芯片的定制板 BSP：NXP Linux 6.6.3 [状态精确标签，例如：lf-6.6.3-1.0.0],约克托·斯卡斯盖普 SCFW 版本：[运行 scu_rm / 检查启动日志 — 粘贴版本] SECO/AHAB：[已启用/未启用，版本] U-Boot：[2024.04/tag] Cortex-M4 (CM4_0)：当前未使用，未加载固件 应用案例：量产汽车仪表盘；A35 运行 Linux/Weston HMI 问题陈述： 在生产环境中，我们偶尔会看到 A35 复合体崩溃或死机（内核崩溃/锁定）。目前我们没有持久的崩溃证据，也没有自主恢复功能——集群会一直处于崩溃状态，直到手动重启电源，并且无法调试现场/DV 事件。我们希望实现 (a) 使用 pstore/ramoops 在看门狗重置时保持 panic 日志的持久性，以及 (b) 由 CM4_0 监督 A35，并能够仅重置 A35 分区。 在 i.MX8QXP C0 上，当系统看门狗（imx-sc-wdt，由 SCFW 处理）触发时，执行的是哪种类型的 RESET——完整的 SoC/板 RESET 还是 A 集群分区 RESET？这可以通过SCFW板级文件或sc_pm API进行配置吗？

针对 Android Automotive 16.0.0_1.3.0 的安全更新预编译版本，不会破坏内核/U-Boot 构建 您好， 我们使用的是NXP Android Automotive 16.0.0_1.3.0，内核版本为 6.12 ，并采用 NXP 官方文档中记录的预编译版本： platform/prebuilts/clang/host/linux-x86 66acdd82ee62e4aaa4248f03191c59dfed9db193 kernel/prebuilts/build-tools 3c5e4f14b451ec85167c38b917d2459687abd7f4 platform/prebuilts/rust 5156e7f81ae254c79ee736e44c960e75ad685c67 platform/prebuilts/clang-tools 17329f6590e2872dcf04a0c96a176be089470cd9 以下是 NXP Android Automotive 用户指南中针对此版本列出的修订内容。 使用这些修订版本可以构建，但我们的容器漏洞扫描报告称，提供的 Android 预构建版本中存在几个高危和严重漏洞。 例如，Clang 预编译版本包含嵌入式 Go 标准库。对于 clang-r536225/bin/clang，扫描结果显示： 总计：22 高危：21 严重：1 Go 标准库版本：v1.23.2 示例：CVE-2025-68121 crypto/tls - 证书验证错误 同样的发现模式也出现在 clang++ 和 clang-tidy 中，以及嵌入的 Go 版本为 v1.23.4 的较新的 clang-r547379 二进制文件中。 NXP 锁定的内核/预编译/构建工具也包含受影响的 soong_zip 二进制文件，其 Go-stdlib 查找模式相同。 Rust 预编译版本中还包含对已发布的 Cargo 锁定文件的发现，例如： thin-vec 0.2.13 版本已修复 常见漏洞与后门-2026-6654 漏洞（已在 0.2.16 版本中修复）；hashbrown 0.15.0 版本已修复 GHSA-wwq9-3cpr-mm53 漏洞（已在 0.15.1 版本中修复）。 我们不希望用任意更新的 AOSP 提交替换已记录的修订版本，因为这些预构建版本是 NXP 内核/U-Boot 构建环境的一部分，我们希望保持与Android Automotive 16.0.0_1.3.0 / 内核 6.12 的兼容性。 对于这些预构建版本，是否有 NXP 推荐的更新版本或已知兼容的提交 ID？ 我们尤其需要以下方面的更新修订： platform/prebuilts/clang/host/linux-x86 kernel/prebuilts/build-tools platform/prebuilts/rust platform/prebuilts/clang-tools   NXP 或社区中的其他人是否已经更新了这些版本并验证了以下内容仍然有效？ 理想情况下，我们也希望确认完整的 Android Automotive 版本仍然能够与更新后的预构建版本兼容。 我们更倾向于更新受影响的预构建版本，而不是永久压制网络安全漏洞。 我已附上失败的漏洞扫描日志供您参考。它包含了受影响的 Clang、内核构建工具和 Rust 预编译版本的完整调查结果，包括检测到的嵌入式版本和可用的修复版本。 谢谢。 Android

DTM APIに関する質問 こんにちは、 MCUXpresso SDK v26.03.00の SDK_26_03_00_KW47-EVK\mcuxsdk\middleware\wireless\bluetooth\host\interface\hci_interface.h で宣言されたHci_LeEnhancedReceiverTestとHci_LeEnhancedTransmitterTest関数を KW47 MCU で使いたいです。これらのコマンドはサポートされていますか？ 追加情報： これら 2 つの関数の宣言は、#if defined(gHciCompleteHciCmdSupport_d) && (gHciCompleteHciCmdSupport_d == TRUE) によって保護されています。このマクロを有効にすると、プロジェクトはエラーでビルドに失敗しました。 SDKでHci_LeEnhancedReceiverTestとHci_LeEnhancedTransmitterTestを探しましたが、宣言はhci_interface.hでしか見つかりませんでした。実装や他の参考文献は見つかりませんでした。 どなたか、これらのDTMコマンドがこのSDKリリースでKW47に対応しているか、また必要な実装の有効化や入手方法(または必要なファームウェア・ライブラリ・設定の場所)を教えていただけませんか?何かご助言いただければ大変ありがたいです。 よろしくお願いします。 Re: Question regarding the DTM API こんにちは、お元気でお過ごしでしょうか。 SDKではHci_LeEnhancedReceiverTestとHci_LeEnhancedTransmitterTestの両方がサポートされています。これらの関数はgHciCompleteHciCmdSupport_dガードによって制御されており、app_preinclude.hで有効にする必要があります。プロジェクトからのファイル: #define gHciCompleteHciCmdSupport_d  TRUE テストにはhci_bb_bm_cm33_core0プロジェクトを使用することをお勧めします。このサンプルはメインのCM33コア上で動作し、透過的なHCIブリッジとして機能します。 現在、SDKのサンプルを使ってテストしていますか?以前は、gHciCompleteHciCmdSupport_d マクロをどのように有効にしていましたか？ hci_bb例をマクロを有効にしてフラッシュした後、 NXP Test Tool 12 を使ってHCIコマンドをデバイスに送信できます。HCI DTMコマンドの全セットにアクセスするには、最新のBLE HCIコマンドセットファイル(BLE HCI 5.0 x.x.x.xml)を読み込みます。 また、これらの投稿はNXPテストツールやDTMコマンドの使い方にも役立つかもしれません: トランスミッタ/レシーバテストコマンドを設定するBLE HCIアプリケーション この記事では、ユーザーがデバイスにシリアルコマンドを送信する方法を示す手順を紹介します。 Bluetooth LE HCI ブラックボックスクイックスタートガイド この記事では、ユーザーがシリアルコマンドを通じて無線機を制御できるようにする簡単なプロセスを説明しています。 よろしくお願いします、 ソフィア。

Question about GCM IV Length Support in HSE FW 2.40.0 and 2.55.0 Hello, I have a question regarding the GCM operation of the HSE on the S32K358. In the AEAD service description of the HSE Service API Reference Manual, both HSE FW 2.40.0 and 2.55.0 specify the following for GCM: GCM: 1 <= ivLength <= 2^32-1. Recommended 12 bytes or greater. However, the HSE FW 2.40.0 manual contains the following additional note, which is not present in the HSE FW 2.55.0 manual: In GCM operations, it is recommended to use IV values of exactly 12 bytes. For any IV size different from 12 bytes, the authentication tag generated by the GCM encryption operation might not be correct. In GCM decryption operations, the authentication check might fail. In this regard, I would like to clarify the following: 1. Can GCM operations be used normally in HSE FW 2.40.0 when the IV length is not 12 bytes? 2. Is there any behavioral difference in GCM operations between HSE FW 2.40.0 and 2.55.0 when using an IV length other than 12 bytes? 3. Is there any difference in the reliability of GCM operations between HSE FW 2.40.0 and 2.55.0 when using an IV length other than 12 bytes? In our tests, GCM encryption and decryption were performed successfully even when the IV length was not 12 bytes, and the authentication results were also correct. Therefore, I would like to confirm whether using an IV length other than 12 bytes is fully supported in HSE FW 2.40.0, and whether there is any functional difference compared to using HSE FW 2.55.0 in this case. Thank you for your clarification.

Security-updated prebuilts for Android Automotive 16.0.0_1.3.0 without breaking kernel/U-Boot builds Hi, we are using NXP Android Automotive 16.0.0_1.3.0 with kernel 6.12 and the prebuilt revisions documented by NXP: platform/prebuilts/clang/host/linux-x86 66acdd82ee62e4aaa4248f03191c59dfed9db193 kernel/prebuilts/build-tools 3c5e4f14b451ec85167c38b917d2459687abd7f4 platform/prebuilts/rust 5156e7f81ae254c79ee736e44c960e75ad685c67 platform/prebuilts/clang-tools 17329f6590e2872dcf04a0c96a176be089470cd9 These are the revisions listed in the NXP Android Automotive User's Guide for this release. The build works with these revisions, but our container vulnerability scan reports several HIGH and CRITICAL findings inside the supplied Android prebuilts. For example, the Clang prebuilts contain embedded Go standard libraries. For clang-r536225/bin/clang, the scan reports: Total: 22 HIGH: 21 CRITICAL: 1 Go stdlib version: v1.23.2 Example: CVE-2025-68121 crypto/tls - incorrect certificate validation The same finding pattern also appears in clang++ and clang-tidy, and in the newer clang-r547379 binaries where the embedded Go version is v1.23.4. The NXP-pinned kernel/prebuilts/build-tools also contains affected soong_zip binaries with the same Go-stdlib finding pattern. The Rust prebuilts also contain findings in shipped Cargo lock files, for example: thin-vec 0.2.13 CVE-2026-6654 fixed in 0.2.16 hashbrown 0.15.0 GHSA-wwq9-3cpr-mm53 fixed in 0.15.1 We do not want to replace the documented revisions with arbitrary newer AOSP commits, because these prebuilts are part of the NXP kernel/U-Boot build environment and we want to preserve compatibility with Android Automotive 16.0.0_1.3.0 / kernel 6.12. Are there newer NXP-recommended or known-compatible commit IDs for these prebuilts? In particular, we are looking for updated revisions for: platform/prebuilts/clang/host/linux-x86 kernel/prebuilts/build-tools platform/prebuilts/rust platform/prebuilts/clang-tools   Has NXP, or anyone in the community, already updated these revisions and verified that the following still work? Ideally, we would also like confirmation that a complete Android Automotive build still works with the updated prebuilts. We would prefer to update the affected prebuilts instead of permanently suppressing the security findings. I have attached the failed vulnerability scan log for reference. It contains the complete findings for the affected Clang, kernel build-tools and Rust prebuilts, including detected embedded versions and available fixed versions. Thanks. Android

在不烧断熔丝的情况下测试 IMXRT1024 上的 HAB 功能 我使用了未签名的 LED 闪烁代码，并实现了 HAB 审计 API（报告状态和报告事件）。EVK板开路，熔丝未烧断。 无符号镜像（CSF=0）- HAB 失败，共发生 4 个事件 签名图像 - HAB 通过 0 事件 所以我假设即使板处于打开状态，HAB 认证也会运行，因此我可以看到事件。 但是现在我使用了相同的 IVT (CSF=0) 项目固件，并实施了相同的 HAB 审计，但这次是 未签名图像 - HAB 通过，事件数为 0 LED闪烁日志（未签名） ： RVT 标头位于 0x2002c0：标签=0xdd 长度=0x038 参数=0x43 HAB：RVT 版本 = 0x 40305 HAB：report_status() = 0x33(HAB_FAILURE) HAB：配置 = 0xf0(HAB_CFG_OPEN) HAB：状态 = 0x66(HAB_STATE_NONSECURE) HAB：事件[0]，8 字节 HAB：hdr：标签=0xdb 长度=0x08 参数=0x43 HAB：状态=0x33(HAB_FAILURE) 原因=0x22(HAB_INV_ADDRESS) 上下文=0xa(HAB_CTX_AUTHENTICATE) 引擎=0x0(HAB_ENG_ANY) HAB：原始数据：db 0 8 43 33 22 a 0 HAB：事件[1]，20 字节 HAB：hdr：标签=0xdb 长度=0x014 参数=0x43 HAB：状态=0x33(HAB_FAILURE) 原因=0xc(HAB_INV_ASSERTION) 上下文=0xa0(HAB_CTX_ASSERT) 引擎=0x0(HAB_ENG_ANY) HAB：原始数据：db 0 14 43 33 c a0 0 0 0 0 0 60 0 10 0 0 0 0 20 HAB：事件[2]，20 字节 HAB：hdr：标签=0xdb 长度=0x014 参数=0x43 HAB：状态=0x33(HAB_FAILURE) 原因=0xc(HAB_INV_ASSERTION) 上下文=0xa0(HAB_CTX_ASSERT) 引擎=0x0(HAB_ENG_ANY) HAB：原始数据：db 0 14 43 33 c a0 0 0 0 0 0 60 0 10 20 0 0 0 1 HAB：事件[3]，20 字节 HAB：hdr：标签=0xdb 长度=0x014 参数=0x43 HAB：状态=0x33(HAB_FAILURE) 原因=0xc(HAB_INV_ASSERTION) 上下文=0xa0(HAB_CTX_ASSERT) 引擎=0x0(HAB_ENG_ANY) HAB：原始数据：db 0 14 43 33 c a0 0 0 0 0 0 60 0 20 0 0 0 0 4 HAB：结果 = 4 个事件已记录 -- 请参阅上面的解码字段，但 我的项目固件（未签名） HAB：RVT 标头位于 0x002002c0 HAB：标签=0xdd 长度=0x0038 参数=0x43 HAB：RVT已找到且有效 HAB：RVT 版本 = 0x00040305 HAB：report_status() = 0xf0 HAB：配置 = 0xf0 HAB：状态 = 0x66 HAB：正在查询审计事件... HAB：report_event(idx=0) 返回 0x33（无事件或查询） HAB：结果 = 通过（未记录任何审计事件） 为什么会有差异 Re: Test HAB on IMXRT1024 without burning fuses 你好@Abhay2080 ， 感谢您的联系！请问能否提供包含LED 闪烁代码的 SDK 版本以及用于构建镜像的 SPT 版本？ 感谢您的耐心等待！ 祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 ------------------------------------------------------------------------------- Re: Test HAB on IMXRT1024 without burning fuses 这是 SDK 版本 - SDK_25_06_00_MIMXRT1024xxxxx SPT 版本 - 26.06 MCU xpresso - v25.6.136 如果使用 MCU Xpresso 编译，则 LED 闪烁灯的未签名镜像；如果使用 SPT 和 CST 4.0 编译，则生成的是已签名镜像。 Re: Test HAB on IMXRT1024 without burning fuses 你好@Abhay2080 ， 感谢您提供的信息和详细日志——这是一个很棒的观察，区别归根结底在于一件事： IVT 中的 CSF 指针是零还是非零。 HABv4 如何决定进行身份验证 在 i.MX RT10xx 上，启动 ROM 会检查 IVT 的 CSF 字段，然后再决定是否尝试进行身份验证： 如果 CSF = 0x00000000 （null）：HAB完全跳过身份验证——不记录任何事件，并且 report_status() 返回 0xf0 （HAB_SUCCESS）。从网络安全意义上讲，这并非“通行证”；从未尝试进行身份验证。 如果 CSF = non-zero （指向 CSF 区域）：HAB尝试进行身份验证——如果签名缺失或无效，则会记录失败事件，并且 report_status() 返回 0x33 （HAB_FAILURE）。在开放式电路板上，这不会阻止启动。 为什么您的 LED 指示灯（未签名）显示 4 个故障事件 您的 LED 闪烁二进制文件由 MCUXpresso IDE 构建，然后通过 SPT（安全配置工具）处理以创建可启动映像。即使对于“无符号”版本类型，SPT 的可引导映像管道也会将非零 CSF 指针写入IVT，并在映像中保留一个 CSF 区域。启动 ROM 检测到非零指针，尝试进行身份验证，但未找到有效的签名数据，并记录了以下 4 个事件： 事件 0 ( HAB_INV_ADDRESS / HAB_CTX_AUTHENTICATE 😞 HAB 尝试查找用于身份验证的图像，但遇到了无效地址——这与空/短截线 CSF 区域一致。 事件 1–3 ( HAB_INV_ASSERTION / HAB_CTX_ASSERT 😞 由于没有真正的脑脊液数据，HAB 对图像区域的内部断言检查失败了。 为什么您的项目固件（未签名）显示 0 个事件 您的项目固件直接通过 MCUXpresso IDE 编译，而没有经过 SPT 的可启动映像生成步骤。生成的二进制文件中，IVT 的CSF 指针确实为空。启动 ROM 检测到 CSF = 0 ，完全跳过身份验证，HAB 报告干净。日志中 report_event(idx=0) 返回的 0x33 表示“此索引处没有事件”（即，查询本身返回 HAB_FAILURE，因为没有存储任何内容），而不是 HAB 检测到了故障。 快速验证方法 检查两个二进制文件在字节偏移量 +0x18 处的 IVT（CSF 字段）： SPT内置LED闪烁：非零值（例如， 0x60006xxx 或类似的闪存地址） 您的项目固件： 0x00000000 要使用您的项目固件正确测试 HAB 审计 您需要通过 SPT（或 elftosb/nxpimage）构建可引导映像，以便将 CSF 区域嵌入映像中——即使对于未签名的构建也是如此。这样可以确保启动 ROM 尝试进行身份验证并生成 HAB 事件。只有这样，您的 HAB 审计代码才能捕获用于测试目的的有意义的数据。 总而言之，你最初的假设是正确的，即 HAB 认证是在开放的板上运行的——但仅当 IVT 中存在非零的 CSF 指针时才如此。您观察到的项目固件的行为是预期的，也是正确的。 希望这能有所帮助！如果您还有其他问题，请与我们联系。   祝你有美好的一天， 坎 ------------------------------------------------------------------------------- 笔记： - 如果此回复解答了您的问题，请点击“标记为正确答案”按钮。谢谢你！ - 我们会持续关注帖子，从最后一条回复发出后持续7周，之后的回复将被忽略。 如果您之后有相关问题，请另开新帖并引用已关闭的帖子。 ------------------------------------------------------------------------------- Re: Test HAB on IMXRT1024 without burning fuses 是的，Kan_Li，你提到的解释是正确的，但正确的场景是—— LED 闪烁（无符号）-> 此二进制文件仅通过 MCU xpresso IDE 生成（未通过 SPT 处理）。大小 - 30KB 即使我比较了 LED 闪烁（无符号）和我的项目（无符号）的 IVT，它们的 IVT 也完全相同（CSF=0）。大小 64KB 参见十六进制比较 左侧是 LED 闪烁灯，右侧是我的项目固件。 另外，请问在不烧断熔丝的情况下测试HAB的正确方法是什么？ Abhay2080_0-1788931301704.pngAbhay2080_0-1788931301704.png

question regarding electrical motor control job Okay so i got interviewed for a job which seems veeery interesting, in the field of control of electrical motors. Now the problem is that he basically described 2 main job functions very different: one is actually develope of control system for motors: simulations in matlab, implementation in microcontrollers and testing. The second part however is related to PLC: he told me that they write some function that are somehow integrated into the system they build. Now my question is: how do i know if i end up working in the first branch o the second one? And if both, with which percentage? Do some of u work in a similar company and can tell me how the 2 aspects are balanced? Should i just ask it to the interviewer? Note that they are not 2 different positions Re: question regarding electrical motor control job Hi taotomi urushi,   Thanks for reaching out.   I’m not sure I fully understand your question. Could you please clarify what specific information about NXP products or technologies you are looking for? Please provide more details about your inquiry so that we can better assist you.   Here is our NXP website: https://www.nxp.com/   If your intention is to apply for a position at NXP, please visit our careers page and submit your application through the following link:   https://nxp.wd3.myworkdayjobs.com/careers   Hope all the information could help you.   BR Lina 

The CSEC and Flash driver in an S32K144 project created with S32DS3.5 cannot coexist. I need to modify an existing S32DS3.5 project to meet the requirements of a new client. Since a Flash driver already exists, I need to add a CSEC driver. When configuring peripherals in the MEX file, I found that adding CSEC results in an error, while deleting CSEC or the Flash driver resolves the issue. How can I resolve this problem? IDE: S32DS3.5 SDK: S32 SDK RTM 4.0.1 err.jpgerr.jpg     Re: S32DS3.5创建的S32K144工程CSEC和Flash驱动不能同时存在 Hello @ZDDL, According to the SDK release notes, it is compatible with S32 Design Studio (S32DS) 3.4. Compatibility with S32DS 3.5 has not been validated, so we cannot guarantee correct functionality. I also strongly recommend installing only one SDK or RTD version within a single IDE installation. If multiple SDK/RTD versions are required, use separate IDE installations for each version. danielmartynek_0-1788953256888.pngdanielmartynek_0-1788953256888.png BR, Daniel 

S32 デザインスタジオのライセンスが切れました こんにちは、 私のS32デザインスタジオライセンスはもうすぐ期限切れになります。 免許の更新は可能ですか? ライセンスコードは085B-C474-AA78-FC99です。 ご回答をお待ちしています。

S32DS3.6.6にSW32K1_S32M24x_RTD_R21-11_3.0.0_QLP07をインストールした後、K144プロジェクトを作成できません。 S32DS3.6.6をインストールした後、インストール...新規ソフトウェア方式を使用して、SW32K1_S32DS_Development_Pack_3.6.6_RFP_D2602.zip と SW32K1_S32M24x_RTD_R21-11_3.0.0_QLP07_D2606_DesignStudio_updatesite.zip をインストールしました。拡張機能リストには、両方のパッケージが正常にインストールされたと表示されています。しかし、サンプルや新規プロジェクトの作成時に K144 が見つからず、K3 しか利用できません。この問題を解決するにはどうすればよいでしょうか？ Ex.jpgEx.jpg exam.jpgexam.jpg     Re: S32DS3.6.6安装SW32K1_S32M24x_RTD_R21-11_3.0.0_QLP07后无法创建K144工程 こんにちは、 @ZDDL さん。 QLP07アップデートサイトは、S32K1/S32M24x RTD 3.0.0用のパッチ/拡張機能のみであり、完全なRTDインストールではありません。 まずベース SW32K1_S32M24x_RTD_R21-11_3.0.0_D2503_DesignStudio_updatesite.zipパッケージをインストールし、その上にQLP07をインストールしてください。S32 Design Studioを再起動すると、S32K144デバイスと対応する例が利用可能になるはずです。 QLP07で導入された追加機能、特にS32K142Nデバイスのサポートが必要ない場合は、QLP07パッケージをインストールする必要はありません。   よろしくお願いいたします。 パベル

Test HAB on IMXRT1024 without burning fuses I have taken unsigned led blinky code and implemented HAB audit API (report status and report event). EVK board is open and fuses not burnt Unsigned image(CSF=0) - HAB fail with 4 events Signed image - HAB pass 0 events  So i assumed that even board is open HAB authentication runs and hence i can see events. But now i taken project firmware with same IVT (CSF=0) and i implemented same HAB audit but this time Unsigned image - HAB pass with 0 events Led blinky logs (unsigned): RVT header at 0x 2002c0: tag=0xdd len=0x 038 par=0x43 HAB: RVT version = 0x 40305 HAB: report_status() = 0x33(HAB_FAILURE) HAB: config = 0xf0(HAB_CFG_OPEN) HAB: state = 0x66(HAB_STATE_NONSECURE) HAB: event[0], 8 bytes HAB: hdr: tag=0xdb len=0x 0 8 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x22(HAB_INV_ADDRESS) context=0x a(HAB_CTX_AUTHENTICATE) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 8 43 33 22 a 0 HAB: event[1], 20 bytes HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) context=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 60 0 10 0 0 0 0 20 HAB: event[2], 20 bytes HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) context=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 60 0 10 20 0 0 0 1 HAB: event[3], 20 bytes HAB: hdr: tag=0xdb len=0x 014 par=0x43 HAB: status=0x33(HAB_FAILURE) reason=0x c(HAB_INV_ASSERTION) context=0xa0(HAB_CTX_ASSERT) engine=0x 0(HAB_ENG_ANY) HAB: raw: db 0 14 43 33 c a0 0 0 0 0 0 60 0 20 0 0 0 0 4 HAB: VERDICT = 4 EVENT(S) LOGGED -- see decoded fields above but  my  project firmware(unsigned) HAB: RVT header at 0x002002c0 HAB: tag=0xdd len=0x0038 par=0x43 HAB: RVT found and valid HAB: RVT version = 0x00040305 HAB: report_status() = 0xf0 HAB: config = 0xf0 HAB: state = 0x66 HAB: querying audit events... HAB: report_event(idx=0) returned 0x33 (no events or query HAB: VERDICT = PASS (no audit events logged) Why there is a difference  Re: Test HAB on IMXRT1024 without burning fuses Hi @Abhay2080 , Thanks for the reaching out! May I have the sdk version that has the led blinky code and the SPT version used for building the image?  Thank for your patience! Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: Test HAB on IMXRT1024 without burning fuses This is SDK version - SDK_25_06_00_MIMXRT1024xxxxx SPT version - 26.06 MCU xpresso - v25.6.136 unsigned image for led blinky if compiled through mcu xpresso and then signed image is created through both SPT and CST 4.0 Re: Test HAB on IMXRT1024 without burning fuses Hi @Abhay2080 , Thanks for the info and detailed logs — this is a great observation and the difference comes down to one thing: whether the CSF pointer in the IVT is zero or non-zero. How HABv4 decides to authenticate On i.MX RT10xx, the Boot ROM checks the CSF field of the IVT before deciding whether to attempt authentication: If CSF = 0x00000000 (null): HAB skips authentication entirely — no events are logged and report_status() returns 0xf0 (HAB_SUCCESS). This is not a "pass" in the security sense; authentication was never attempted. If CSF = non-zero (points to a CSF region): HAB attempts authentication — if the signature is missing or invalid, failure events are logged and report_status() returns 0x33 (HAB_FAILURE). On an open board this does not halt boot. Why your LED blinky (unsigned) showed 4 failure events Your LED blinky binary was built by MCUXpresso IDE and then processed through SPT (Secure Provisioning Tool) to create a bootable image. Even for an "unsigned" build type, SPT's bootable image pipeline writes a non-zero CSF pointer into the IVT and reserves a CSF region in the image. The Boot ROM found that non-zero pointer, attempted authentication, found no valid signature data, and logged the 4 events: Event 0 ( HAB_INV_ADDRESS / HAB_CTX_AUTHENTICATE 😞 HAB tried to locate the image for authentication but encountered an invalid address — consistent with an empty/stub CSF region. Events 1–3 ( HAB_INV_ASSERTION / HAB_CTX_ASSERT 😞 HAB's internal assertion checks on the image regions failed because there is no real CSF data present. Why your project firmware (unsigned) showed 0 events Your project firmware was compiled directly through MCUXpresso IDE without going through SPT's bootable image generation step. The resulting binary has a genuinely null CSF pointer in the IVT. The Boot ROM sees CSF = 0 , skips authentication entirely, and HAB reports clean. The 0x33 return from report_event(idx=0) in your log means "no event at this index" (i.e., the query itself returns HAB_FAILURE because there is nothing stored), not that HAB detected a failure. Quick way to verify Inspect the IVT of both binaries at byte offset +0x18 (the CSF field): SPT-built LED blinky: non-zero value (e.g., 0x60006xxx or similar flash address) Your project firmware: 0x00000000 To properly test HAB audit with your project firmware You need to build the bootable image through SPT (or elftosb/nxpimage) so that a CSF region is embedded in the image — even for an unsigned build. This ensures the Boot ROM attempts authentication and HAB events are generated. Only then will your HAB audit code capture meaningful data for testing purposes. In summary, your original assumption is correct that HAB authentication runs on an open board — but only when a non-zero CSF pointer is present in the IVT. The behavior you observed with your project firmware is expected and correct. Hope this helps clarify! Let us know if you have further questions.   Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. ------------------------------------------------------------------------------- Re: Test HAB on IMXRT1024 without burning fuses Yes Kan_Li the explaination you mentioned is correct but the correct scenario us - LED blinky (unsigned) -> This binary i generated through MCU xpresso IDE only (not processed through SPT). size - 30KB And even i compare the IVT for both led blinky unsigned and my project unsigned both have exactly same IVT (CSF=0) .- size 64KB See hex compare left side is Led blinky and right side is my project firmware Also please mention what is the right way to test HAB without burning fuses Abhay2080_0-1788931301704.pngAbhay2080_0-1788931301704.png

关于电机控制工作的问题 我面试了一份工作，看起来非常有趣，是关于电机控制领域的。现在的问题是，他基本上描述了两个截然不同的主要工作职能：一个是电机控制系统的开发：在 matlab 中进行仿真，在微控制器中实现和测试。但第二部分与 PLC 有关：他告诉我，他们编写了一些函数，这些函数以某种方式集成到他们构建的系统中。现在我的问题是：我如何知道我最终会在第一个分支还是第二个分支工作？如果两者都有，比例是多少？你们当中有人在类似的公司工作吗？能否告诉我这两方面是如何平衡的？我应该直接问面试官吗？请注意，它们并非两种不同的立场。 Re: question regarding electrical motor control job 您好，桃金娘漆，   感谢您的联系。   我不太确定我是否完全理解你的问题。请问您想了解恩智浦半导体产品或技术的哪些具体信息？请提供更多关于您咨询的内容，以便我们更好地为您提供帮助。   这是我们的恩智浦网站： https://www.nxp.com/   如果您有意申请恩智浦的职位，请访问我们的招聘页面，并通过以下链接提交您的申请： https://nxp.wd3.myworkdayjobs.com/careers   希望这些信息对您有所帮助。   BR 莉娜

88W8887 RF準拠試験 親愛なる、 私たちは88W8887チップセットをベースにしたWi-Fi/Bluetoothモジュールを使用しています。製品準拠のために、連続パケットの送信や受信モードなどのRFテストを行う必要があります。別のモジュール88W8997については、以下のアプリケーションノードAN14114をたどっています。しかし、アプリケーションノートには88W8887がサポートされているとは記載されていません。 アプリケーションノートにはmwifiexドライバを使用しています。コードを見る限り、88W8887はドライバーがサポートしているはずです。残念ながら、ドライバにはファームウェアファイルsd8887_wlan_a2.binが必要ですが、私たちは見つけることができませんでした。 88W8887でRFテストを行う推奨方法(ANに記載されているものと似ています)は何ですか?NXPはまだこのユースケースをサポートしていますか? 敬具 ヨシ Re: 88W8887 RF compliance testing こんにちは@shaun_wu 提供されたリンクにアクセスできません。アクセスを得るために自分の側で何かやるべきことはありますか? 敬具 ヨシ Re: 88W8887 RF compliance testing こんにちは、 @YoshiDev さん。 8887はrf_test_modeをサポートしていません。mfg_modeを使えばいい。以下のリンクを参照できる https://www.nxp.com/webapp/Download?colCode=88W8887-LABTOOL-USER-GUIDER0_1&appType=license よろしくお願いいたします。 ショーン

Android オートモーティブ 16.0.0_1.3.0向けのセキュリティアップデート済みプリビルドで、カーネルやU-Bootビルドを壊さずに提供されました こんにちは、 NXPの Android オートモーティブ 16.0.0_1.3.0をカーネル6.12 と、NXPが文書化したプリビルドのリビジョンを使用しています。 プラットフォーム/Prebuilts/Clang/Host/Linux-x86 66acdd82ee62e4AAAA4248F03191C59DFED9DB193 カーネル/prebuilts/build-tools 3c5e4f14b451ec85167c38b917d2459687abd7f4 プラットフォーム/prebuilts/rust 5156e7f81ae254c79ee736e44C960e75AD685C67 プラットフォーム/prebuilts/clang-tools 17329f6590e2872dcf04a0c96a176be089470cd9 これらは本リリースのNXP Android Automotiveユーザーガイドに記載された改訂版です。 ビルドはこれらのリビジョンで動作しますが、当社のコンテナ脆弱性スキャンでは、 提供されたAndroidプリビルト内でいくつかのHIGHかつCRITICALな発見が報告されています。 例えば、Clangのプリビルド版にはGoの標準ライブラリが組み込まれています。clang-r536225/bin/clang のスキャン結果は以下のとおりです。 合計: 22 高: 21 重大: 1 Go stdlib バージョン: v1.23.2 例: CVE-2025-68121 crypto/tls - 証明書の検証が正しく行われていない 同様の検出パターンは、clang++ および clang-tidy、そして組み込みの Go バージョンが v1.23.4 である新しい clang-r547379 バイナリでも見られます。 NXPが固定しているkernel/prebuilts/build-toolsにも、同じGo-stdlib検出パターンを持つ、影響を受けるsoong_zipバイナリが含まれています。 Rustのプリビルド版には、出荷されるCargoロックファイルに含まれる発見事項も含まれています。例えば、以下のとおりです。 thin-vec 0.2.13 CVE-2026-6654 は 0.2.16 で修正されました。 hashbrown 0.15.0 GHSA-wwq9-3cpr-mm53 は 0.15.1 で修正されました。 これらのプリビルドはNXPカーネル/U-Bootビルド環境の一部であり、 Android Automotive 16.0.0_1.3.0 / カーネル6.12との互換性を維持したいため、ドキュメント化されたリビジョンを任意の新しいAOSPコミットで置き換えるつもりはありません。 これらのプリビルド製品に対応する、NXPが推奨する、または互換性が確認されている新しいコミットIDはありますか？ 特に、以下の項目に関する最新の改訂版を求めています。 platform/prebuilts/clang/host/linux-x86 カーネル/prebuilts/build-tools platform/prebuilts/rust platform/prebuilts/clang-tools   NXP社、あるいはコミュニティの誰かが、これらの改訂版を既に更新し、以下の内容が引き続き正常に動作することを確認しましたか？ 理想的には、更新されたプリビルト車と完全なAndroid Automotiveビルドがまだ動作するかどうかの確認も望んでいます。 セキュリティ調査結果を恒久的に抑制するよりも、影響を受けたプリビルトを更新したいと考えています。 参考までに、失敗した脆弱性スキャンログを添付しました。これには、影響を受けるClang、カーネルビルドツール、およびRustのプリビルド版に関する完全な調査結果が含まれており、検出された組み込みバージョンと利用可能な修正バージョンも含まれています。 ありがとうございます。 Android

S32DS3.6.6安装SW32K1_S32M24x_RTD_R21-11_3.0.0_QLP07后无法创建K144工程 新安装S32DS3.6.6后，通过install New Software的方式分别安装了SW32K1_S32DS_Development_Pack_3.6.6_RFP_D2602.zip和SW32K1_S32M24x_RTD_R21-11_3.0.0_QLP07_D2606_DesignStudio_updatesite.zip。在Extensions里面也可以看到这2个包安装成功，但是无论是通过example还是新建工程都找不到K144只有K3的。怎么处理？ Ex.jpgEx.jpg exam.jpgexam.jpg     Re: S32DS3.6.6安装SW32K1_S32M24x_RTD_R21-11_3.0.0_QLP07后无法创建K144工程 你好@ZDDL ， QLP07 更新站点只是 S32K1/S32M24x RTD 3.0.0 的一个补丁/扩展程序；它不是一个完整的 RTD 安装。 请先安装基础的SW32K1_S32M24x_RTD_R21-11_3.0.0_D2503_DesignStudio_updatesite.zip软件包，然后再在其上安装 QLP07。重启 S32 Design Studio 后，S32K144 设备和相应的示例应该就可以使用了。 如果您不需要 QLP07 中引入的附加功能，特别是对 S32K142N 设备的支持，则无需安装 QLP07 软件包。   顺祝商祺！ 帕维尔

i.MX8QXP C0: クラッシュ証拠キャプチャ SCwatchdogresetCortex-M4監視A35クラスタ全体にラムーブ こんにちは、NXPチームの皆さん、 プラットフォームの詳細: SoC: i.MX8QXP C0、MEKリファレンスに基づくカスタムボード BSP: NXP Linux 6.6.3 [状態完全タグ、例:lf-6.6.3-1.0.0]、ヨクト・スカースギャップ SCFWバージョン：[scu_rmを実行し、ブートログを確認してバージョンを貼り付けてください] SECO/AHAB: [有効/無効、バージョン] U-Boot: [2024.04/tag] Cortex-M4(CM4_0):現在使用されておらず、ファームウェアはインストールされていません ユースケース:生産オートモーティブ向けインストゥルメントクラスター;A35はLinux/Weston HMIを動作させています 問題提起： 実稼働環境では、A35 複合システムがクラッシュしたり、ハードハングアップ（カーネルパニック／ロックアップ）を起こしたりするケースが時折発生します。現在では持続的なクラッシュの証拠もなく、自律的な復旧もありません。クラスターは手動で電源を入れ直すまで停止状態のままで、フィールドやDVの発生はデバッグできません。我々は、(a) pstore/ramoops を使用したウォッチドッグリセット後のパニックログの永続化、および (b) A35 パーティションのみをリセットできる機能を備えた CM4_0 による A35 の監視を実装したいと考えています。 i.MX8QXP C0において、システムウォッチドッグ（imx-sc-wdt、SCFWによって処理される）が作動した場合、どのようなタイプのリセットが実行されますか？（SoC/ボード全体のリセット、またはAクラスタパーティションのリセット）これはSCFWボードファイルまたはsc_pm API経由で設定可能ですか？

S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 Hello,  I tried running the example PIL S32CT with MBDT S32K3xx (v1.4.0) on MATLAB 2023a. My setup consists of an S32K3x4EVB-T172 connected via the onboard OpenSDA port. Attempt 1 (OpenSDA COM): I can flash the generated target model successfully, but PIL execution fails immediately with the following error: "The communication channel could not be opened" (see attached screen shot of the error message) Attempt 2 (External USB2Serial Convertor) I kept the OpenSDA port connected for flashing, but connected an external USB2Sireal  connector to J44(1 to TX and 2 to RX) for PIL communication and updated the COM port in the hardware settings. The model flashes successfully, but execution times out with this error: Error: The timeout of 10 seconds for receiving data from the rtiostream interface has been exceeded. There might be multiple reasons for this communications failure. You should: (a) Check that the target hardware configuration is correct, for example, check that the byte ordering is correct. (b) Confirm that the target application is running on the target hardware. (c) Consider the possibility of application run-time failures (e.g. divide by zero exceptions, incorrect custom code integration, etc.). Note (c): To identify possible reasons for the run-time failure, consider using SIL, which supports signal handlers and debugging. If you cannot find a solution, consider using the method setTimeoutRecvSecs of rtw.connectivity.RtIOStreamHostCommunicator to increase the timeout value.   Questions:   1. Does the S32K3x4EVB-T172 board require an external USB2Serial convertor for PIL or can it run PIL over the onboard OpenSDA port ?  2. If an external USB2Serial convertor required , what is the exact hardware UART configuration expected?  3. Am i missing any configuration ? Any guidance i highly appreciated!  Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 Hi, @PruthviB, Before investigating further, could you clarify why you are using MBDT S32K3xx v1.4.0? The latest available release is v1.8.0, which includes several fixes and improvements. We recommend upgrading to v1.8.0 first and checking whether the issue still reproduces. Regarding your setup, an external USB-to-Serial converter is not required for PIL communication on the S32K3X4EVB-T172. The onboard OpenSDA interface already provides access to the target UART used for host-target communication, so the same USB connection can be used for both programming and PIL communication. Since OpenSDA has direct access to the UART pins, connecting an additional USB-to-Serial adapter is generally unnecessary and may even introduce configuration conflicts if multiple serial interfaces are active. Could you please try the example with: MBDT S32K3xx v1.8.0 Only the onboard OpenSDA USB connection The COM port exposed by OpenSDA selected in the hardware settings Best regards, Dragos Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 Hi, @dragostoma Thank you for the guidance regarding OpenSDA onboard interface. Regarding the version, MBDT v1.4.0 was the recommended version for MBDT for BMS. Could you please provide guidance on running PIL simulations in v1.4.0 ?  Best Regards, Pruthvi

S32K3x4EVB-T172 PIL 通信错误/超时，MBDT S32K3xx 1.4.0 你好， 我尝试在 MATLAB 2023a 上运行 PIL S32CT 示例和 MBDT S32K3xx (v1.4.0)。我的配置包括通过板载 OpenSDA 端口连接的 S32K3x4EVB-T172。 尝试 1（OpenSDA COM）： 我可以成功刷写生成的目标模型，但是 PIL 执行立即失败，并出现以下错误： “无法打开通信通道”（请参见附件中的错误信息截图） 尝试 2（外置 USB 转串口转换器） 我保持 OpenSDA 端口连接以进行刷写，但将外部 USB2Sireal 连接器连接到 J44（1 到 TX，2 到 RX）以进行 PIL 通信，并在硬件设置中更新了 COM 端口。模型刷写成功，但执行超时并出现以下错误： 错误：从 rtiostream 接口接收数据的超时时间已超过 10 秒。通信失败可能由多种原因造成。 你应该： （a）检查目标硬件配置是否正确，例如，检查字节顺序是否正确。 （b）确认目标应用程序正在目标硬件上运行。 （c）考虑应用程序运行时故障的可能性（例如除以零异常、不正确的自定义代码集成等）。 注（c）：要确定运行时失败的可能原因，请考虑使用 SIL，它支持信号处理程序和调试。 如果找不到解决方案，请考虑使用 rtw.connectivity.RtIOStreamHostCommunicator 的 setTimeoutRecvSecs 方法来增加超时值。 问题： 1.S32K3x4EVB-T172开发板运行PIL时是否需要外接USB转串口转换器，还是可以通过板载OpenSDA端口运行PIL？ 2. 如果需要外部 USB 转串口转换器，所需的硬件 UART 配置具体是什么？ 3. 我是否遗漏了什么配置？ 非常感谢您的指导！ Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 你好， @PruthviB ， 在进一步调查之前，能否请您说明一下您使用MBDT S32K3xx v1.4.0 的原因？最新版本为v1.8.0 ，其中包含多项修复和改进。我们建议您先升级到 v1.8.0 版本，然后检查问题是否仍然存在。 关于您的设置， S32K3X4EVB-T172上的PIL 通信不需要外部 USB 转串口转换器。板载OpenSDA 接口已经提供了对用于主机-目标通信的目标 UART 的访问，因此同一个 USB 连接可以用于编程和 PIL 通信。 由于 OpenSDA 可以直接访问 UART 引脚，因此通常不需要连接额外的 USB 转串口适配器，如果多个串口处于活动状态，甚至可能会引入配置冲突。 请您尝试一下以下示例： MBDT S32K3xx v1.8.0 仅板载OpenSDA USB 连接 在硬件设置中选择的 OpenSDA 公开的 COM 端口 此致， 德拉戈斯 Re: S32K3x4EVB-T172 PIL Communication Error/ Timeout with MBDT S32K3xx 1.4.0 你好， @dragostoma 感谢您对OpenSDA板载接口的指导。 关于版本，MBDT v1.4.0 是推荐用于电池管理系统的 MBDT 版本。请问能否提供在v1.4.0版本中运行PIL仿真的指导？ 顺祝商祺！ 普鲁特维