S32K376NHT1MJBST: applicable power estimator and per-supply current data Hello, Could you please identify the applicable power-estimation tool and supply-current data for S32K376NHT1MJBST? Does S32K-PET support this exact derivative? Which tool and device-dataset revisions should be used? If it is not supported, what is the recommended current NXP method? For externally supplied V15 with the external NMOS V11 regulator arrangement, how should reported demand be attributed to V15, V11, VDD_HV_A/B and other analog/bias supplies? Please identify what is included or excluded, especially regulator losses, shared core/lockstep demand, I/O loading and peripheral currents, so these are not counted twice. Which applicable public documents, data or characterization method cover worst-case supply current versus voltage/temperature, and peaks during reset, startup, wake and clock/mode changes? Please distinguish typical/average estimates from guaranteed limits and identify their conditions. The public PET page and setup guide have been reviewed. Their family-level support listing and initial average-power scope do not identify the exact derivative or all physical-supply contributions. We are seeking the applicable sources and method, not an application-specific current result without a defined operating profile. Please point to the appropriate public material or support route if these details are not public. Thank you. Re: S32K376NHT1MJBST: applicable power estimator and per-supply current data Hello @JonasGranlund, 1. As of now, the S32K PET tool does not support S32K39/37/36 devices. The recommended method is to refer to S32K396's Data Sheet (Rev. 5) for supply current data, specifically: 6.7 Supply currents (Standby and RUN mode tables) 6.9 Cyclic wake-up average current calculation 2. The datasheet supply current tables report current at the following rails independently: VDD_HV_A is catalogued as the main I/O and analog supply, and it covers both I/O pads in the VDD_HV_A bank and all analog blocks.  VDD_HV_B is the secondary I/O supply and covers I/O pads in the VDD_HV_B bank only. You can refer to "S32K39_and_S32K37_IOMUX.xlsx" attachment inside the Reference Manual in order to identify which pin belongs to which power domain. V11 is generated by V15 using external NMOS. The external V1.5 power supply should be turned off before entering LPM mode. IO load current is not included in measurements. The actual current requirements for IOs will depend on the I/O configuration in the application. Refer to the DC characteristics tables in the S32K39 Data sheet. Lockstep/dual-core demand is included in the core supply figures in the data sheet; the power consumption is specified to be the same because there are no separate specifications depending on the load of the cores. 3. Data Sheet values include ambient temperature, typical and maximum values.  As far as I know, there are no specific S32K39 documents detailing worst-case scenario currents, peaks during reset, etc. However, S32K3 Low Power Management AN and demos document provide power mode transitions, clock operation in low-power modes, hardware considerations and quiescent current. It is focused on a more family-level, referencing S32K3xx in general, rather than S32K39-37-36 specifics. I've also sent you a private message in community sharing S32K3 Low Power Lab presentation, which explains S32K3 low power behavior and considerations. Best regards, Julián

S32K376NHT1MJBST：适用的功率估算器和单电源电流数据 你好， 请问您能否提供适用于 S32K376NHT1MJBST 的功率估算工具和供电电流数据？ S32K-PET 是否支持这种特定衍生物？应该使用哪些工具和设备数据集版本？如果不支持，NXP 目前推荐的方法是什么？ 对于采用外部 NMOS V11 稳压器配置的外部供电 V15，应如何将报告的需求分配给 V15、V11、VDD_HV_A/B 和其他模拟/偏置电源？请明确哪些项目包含在内，哪些项目不包含在内，特别是调节器损耗、共享核心/锁定步进需求、I/O 负载和外围电流，以免重复计算。 哪些适用的公共文件、数据或表征方法涵盖了最坏情况下的供电电流与电压/温度的关系，以及RESET、启动、唤醒和时钟/模式变化期间的峰值？请区分典型/平均估价和保证限额，并说明其适用条件。 已审核公开的PET页面和设置指南。他们的家族级支持清单和初始平均功率范围并未明确指出具体的衍生品或所有实物供应贡献。我们寻求的是适用的资源和方法，而不是没有明确操作规范的特定应用的当前结果。 如果这些信息不公开，请指出相应的公开资料或支持途径。 谢谢！ Re: S32K376NHT1MJBST: applicable power estimator and per-supply current data 你好@JonasGranlund ， 1.目前，S32K PET 工具不支持 S32K39/37/36 设备。推荐的方法是参考 S32K396 的数据手册（修订版）。5）关于供应电流数据，具体而言： 6.7 电源电流（待机和运行模式表） 6.9 循环唤醒平均电流计算 2. 数据手册中的电流表分别报告以下各轨的电流： VDD_HV_A被列为主 I/O 和模拟电源，它覆盖 VDD_HV_A 组中的两个 I/O 焊盘和所有模拟模块。 VDD_HV_B是辅助 I/O 电源，仅覆盖 VDD_HV_B 组中的 I/O 焊盘。您可以参考参考手册中的“S32K39_and_S32K37_IOMUX.xlsx”附件，以确定哪个引脚属于哪个电源域。 V11由 V15 利用外部 NMOS 产生。进入LPM模式前，应关闭外部V1.5电源。 测量中不包括 I/O 负载电流。实际的 I/O 电流需求将取决于应用程序中的 I/O 配置。请参阅 S32K39 数据表中的直流特性表。 数据表中核心供电量中包含了锁步/双核需求；由于没有根据核心负载单独制定的规格，因此功耗规定为相同。 3. 数据表中的数值包括环境温度、典型值和最大值。 据我所知，没有专门针对 S32K39 的文件详细说明最坏情况下的电流、RESET 期间的峰值等。然而， S32K3 低功耗电源管理单元 AN 和演示文档提供了电源模式转换、低功耗电源模式下的时钟操作、硬件注意事项和静态电流。它更侧重于家族层面，一般参考 S32K3xx，而不是 S32K39-37-36 的具体细节。 我还通过社区分享 S32K3 低功耗实验室演示文稿向您发送了一条私信，其中解释了 S32K3 的低功耗特性和注意事项。 此致， 朱利安

SodaPeakは買う価値があるのか？2026年に向けた正直なレビュー ソーダピーク： 従来のサプリメントがカプセルを飲み込んだり粉末を用意したりするのに対し、SodaPeakは忙しいライフスタイルに合うシンプルなアプローチを提供します。この製品は、男性の健康において重要な3つの分野、すなわち日常のエネルギー、身体的持久力、そして全体的な活力に焦点を当てています。 公式サイト： https://finance.yahoo.com/healthcare/articles/sodapeak-launch-2026-advanced-soda-174000686.html

S32N55 A/B スワップ OTA — パッシブバンク資産(PaCo/Codef/SMR)インストールタイミングおよびランタイムフラッシュアクセス 環境: S32N55、FSS FW 1.19.0 (D2604)、GrayVIP 1.0.25、HSE2、セキュアブート有効。 目標：OTA（Over-The-Air）によるA/Bスワップを実装する。アクティブバンクAはAHB 0x10000000、パッシブバンクBは0x14000000（フラッシュオフセット0x04000000）にあります。実行中のFSS（アクティブバンクA）にパッシブバンクのPaCo/Codef/SMRをインストールさせ、その後IVTを交換してバンクBに再起動させようとしています。 私が発見したこと： 実行中のFSSは0x14000000のパッシブバンクを読み取ることができません。T32(XSPIは4バイト読み取り、cmd 0x13設定)では0x14000000のデータが正しく読み込まれますが、実行時にはFSS/QSPIはOPI読み取りを3バイトアドレス指定(約16MBの範囲)で使用するため、0x14xxxxxxバスへのアクセスは困難です。バンクAが機能するのは、使用されているデータがすべて16MB未満に収まっているためです。 ランタイムアセットの再インストールを強制すると、ボードがハードフォルト/リセットされます。FSSアセットインストール機能（InstallPaCo / InstallSMRs / InstallCodefs / AuthenProcess）の「SYS-IMAGEは既にロードされています」ゲートをバイパスして実行時にインストールを再実行すると、アクティブな（読み取り可能な）バンクをターゲットにした場合でも、ボードがリセットされます。これは、アセットのインストールは、コホート（CRS/RTU）が既に実行されている間は実行されるべきではないことを示唆しています。 質問: FSSアセットのインストール（HSE経由のPaCo/Codef/SMR）は、ブート/プロビジョニングフェーズ（コホートがリリースされる前）のみサポートされ、CRS/RTUが実行されている実行時にはサポートされないのでしょうか？ A/BスワップOTAの場合、想定されるアクティベーション手順は何ですか？パッシブバンクの書き込みとIVTの交換後、パッシブバンクのCodef（イメージソースアドレスはバンクによって異なる）、SMR、およびPaCoはいつ、どのようにインストール/検証されますか？ 実行中のFSSは実行時にパッシブバンク(0x14000000)にアクセスすることが期待されるのでしょうか(つまり、ランタイムの読み取りパスは4バイトアドレス指定を使うべきか)、それともパッシブバンクは次のブート時にブートROMのみがアクセスするのでしょうか? A/Bスワップにおいて、銀行間でPaCoに違いはありますか？PaCoにはフラッシュレンジアドレス(0x10xxxxxx / 0x11xxxxxx)が含まれていますが、パッシブバンクのPaCoはCodefのように移動が必要なのでしょうか、それとも銀行に依存しないのでしょうか? S32N5 Re: S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash acc Chenyinさん、早速のお返事ありがとうございます。 私の質問を明確にするために申し上げますが、私は組み込みのSCMIサービスに依存しているわけではありません。私は既に、A/Bバンク切り替えOTAの一環として、独自のランタイムPaCo/CoDefインストールを実装しました。このデザインは銀行に依存しません。実行中の(アクティブ)FSSは実行時にパッシブ銀行の資産をインストールし、IVTのプライマリポインタ(0x10000000 ↔ 0x14000000)を交換してもう一方の銀行に再起動します。この目的のために、既存のFSSインストール状態マシンをそのまま再利用します。 SO、私の本当の疑問は、この方法が現行のFSSで実現可能かどうかです。なぜなら、テストでは特定のポイントで失敗するからです。 うまくいく方法:アクティブなバンクをターゲットにインストールすると、全パスが完了します(PaCo/Owner/Keys、SMRのインストールはOK、FSS FW SMR0/AuthenProcess OK;codef-installとValidateBootConfigは公開されたSYS-IMGの下でNOT_ALLOWED返すので、それらは次のブートのBootCfgVerifyに任せています)。BTMはその後、PublishSysImageとEnableGlobalSecureBootを実行します。 何が失敗するか: インストールがパッシブバンクをターゲットにする場合、FSS が AHB 0x14013000 にあるパッシブバンク PaCo を最初に参照解除したときに、IndexSourcesStep でバスフォルトが発生します。アクティブなバンクアドレス（0x10xxxxxx）は正常に読み取れます。 原因を突き止めたところ、AHBウィンドウやアドレス指定の問題ではないことがわかりました。MemAcc_Init()(Mem_43_EXFLSを初期化するMemPerformDeviceConfiguration=TRUE)はFss_Firmware_InstallPacoCodefs()より先に動作するため、インストール時点でSFA1Dはすでに0x18000000(128MB)済みで、AHB読み込みが有効で、読み込みLUTは4バイトのOPI-DDRです。T32経由でSFA1D = 0x18000000を手動で確認した後でも、0x14013000は依然としてハードバスエラーを返します（SFPエラーペイロードではありません）。これはXSPIセキュアフラッシュ保護(SFP)に関係しています。パッシブ領域をカバーするFRADはアクセスするマスターのドメインRWを付与していません。FRADカバレッジをフルフラッシュに拡張し、Md4Acp = RWに設定したところ、アクセスの動作が変わりました。 私の質問： 現在のFSS（セキュアブート有効）では、上記のようにインストール関数を再利用することで、パッシブバンクへのPaCo/CoDefのランタイムインストールがアーキテクチャ的にサポートされていますか？それとも、リファレンスOTAが利用可能になる前に注意すべき重大な障害がありますか？ この暫定的なアプローチ（例えば、対象バンクにFSS FW SMR0（AuthenProcess）をインストールし、CoDef/boot-configのチェックを次回のブート時のBootCfgVerifyに延期するなど）に関して、何か注意点はありますか？ ありがとう、 エディ Re: S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash acc こんにちは、 @EddiePark 投稿ありがとうございます。またサポートできて嬉しいです。 現在のFSSは、実行時にPaCoとCoDefをインストールするためのSCMIサービスを提供していません。 現在、S32NのリファレンスOTA実装はまだ開発中です。可能であれば、利用可能になった時点でそれを直接参照して独自のOTAプロセスを実装することをお勧めします。 BR チェイン   Re: S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash acc こんにちは。体系的なデバッグを行った結果、より詳細な情報をお伝えします。 セットアップ: S32N55、FSS FW 1.19.0、セキュアブート。A/B銀行スワップOTA。実行中のFSS（M7）は、実行時にパッシブバンクのPaCo/CoDefをインストールします（FSSインストールステートマシンを再利用した独自の実装）。パッシブバンクベース = 0x14000000。 障害: Fss_Firmware_IndexSourcesStep で、FSS-M7 はパッシブバンク PaCo の 0x14013000 を直接 AHB メモリマップド リード (CPU デリファレンス) し、正確な BusFault が発生します。 CFSR = 0x00008200 → BFSR: PRECISERR=1、BFARVALID=1、MMFSR=0 BFAR = 0x14013000 我々が（証拠に基づいて）除外した事項： MPU：原因ではない。MMFSR=0。MPU領域2 = 外部フラッシュ0x10000000–0x1FFFFFFF、通常のキャッシュ可能なWB、読み取り専用 → 0x14013000をカバー、読み取り許可。 SFP：原因ではない。MemXspiSfpEnable = FALSE に設定して再構築しても、同じエラーが発生します。（FRADは、いずれにせよ該当ドメインにその領域を付与する。） AHB ウィンドウ: SFA1D = 0x18000000 (128 MB) → バンク B はウィンドウ内にあります。 重要な観察結果：これは銀行固有の問題ではなく、「新規データかキャッシュデータか」の問題です。 読み取り/フォルト境界は正確に0x13780000です（読み取り回数0x1377FFFF、フォルト回数0x13780000）。これはファームウェアイメージ領域（FSS/CRS/HSE/RTU/Sys_Img）の終わりであり、データ領域（IDS…）の開始です。ベースから56MBであり、2のべき乗ではなくハードウェアサイズの境界ではありません。これはFSSがブート時に読み取ってキャッシュする範囲(外部フラッシュ領域はキャッシュ可能)に正確に相当します。 → ブート中にFSSが読み取ったもの（現在はDキャッシュに格納されている）はすべて正常に読み戻されます。FRESH (キャッシュされていない) の直接 AHB 読み取りフォルトを必要とするアドレス (0x14000000 未満のアドレスを含む) (例:0x13780000はアクティブな64MBにあり、障害も発生しています。SO、本当の問題は、外部フラッシュの新規でキャッシュされていない直接のAHBメモリマップ読み取りが実行時に失敗することです。 MemPerformDeviceConfiguration テスト: MemPerformDeviceConfiguration = TRUE (デバイス初期化実行 → 8 進 DDR): フラッシュ書き込みは機能し (MemAcc INDIRECT_STATIC を介した間接 / IP コマンド)、キャッシュ読み取りは機能し、新しい AHB 読み取りは FAULT です。 MemPerformDeviceConfiguration = FALSE (デバイス初期化をスキップ): 読み取り結果はすべて 0x00 を返します (デバイスが 8 進 DDR モードのままではありません)。 SO、デバイスを正しく8進制DDRに設定した場合、書き込みは成功しますが、新しいメモリマップのREADS障害が発生します。8進数DDRの外部DQS読み出しはデバイスのDQSストローブを使用してサンプリングされますが、書き込みはサンプリングされないため、これは読み出しパス（DQS/DLL/ダミー/タイミング）の問題を示しています。 設定コンテキスト: XSPIコントローラの設定はFSSのみです(Xspi_Ip_paXspiUnitCfg、MemPerformDeviceConfiguration = TRUE、octal-DDR、外部DQS、DLLバイパス)。CRSとRTUはコントローラ設定(XspiUnit = NULL、DeviceConfiguration = FALSE)をスキップし、ブート設定を引き継ぎます。 qspi パラメータ (xspi_S28H_octal_ddr_200Mhz_dll_bypass_ext_dqs.bin) は、生成された VIP/IVT ブロブに含まれています。 質問: 現在のFSSにおいて、FSS-M7は、実行時（MemAcc_Init後）に、任意のアドレス／キャッシュされていないアドレスで、外部XSPIフラッシュのAHBメモリマップド読み出しを直接実行できると予想されますか？それとも、実行時のフラッシュ読み取りは間接的な（IPコマンドによる）Mem/MemAccパスを経由する必要があるのでしょうか？ SFA1D=128MB、SFP無効、MPU ROが領域をカバーしている場合、キャッシュされていないアドレスに対して直接AHB読み取りを行うと正確なBusFaultが返されるのに、書き込み（間接）とキャッシュされた読み取りは成功するのはなぜでしょうか？ FSSのMemAcc_Initコントローラの再構成が、起動時のqspi-paramのXSPI読み取り設定と衝突し、メモリマップされた読み取りが途切れてしまうのでしょうか?FSSはコントローラの再構成(CRS/RTUのように)を省略し、起動時のqspi-param設定を継承すべきでしょうか?もしそうなら、フラッシュ書き込みのサポートをどのように維持すればよいのでしょうか? S28HS01GTの200MHzにおけるオクタルDDR/外部DQS/DLLバイパスの場合、信頼性の高いメモリマップド読み出しを行うには、どのようなDLL/DQS/ダミーサイクル設定が必要ですか？（FSS読み取り設定が、正常に動作するブート時のqspi-param設定と異なっている可能性があると考えています。） ありがとう、 エディ Re: S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash acc こんにちは、 @EddiePark 休暇のため返信が遅くなり申し訳ありません。 以下の設定を変更されたかどうか教えていただけますか？TG0のアクセス制御ポリシー→すべてのインスタンスをXSPI_IP_SFP_ACP_RWに変更し、FSS経由でフラッシュアドレスにアクセスしても問題が続くかテストします。 BR チェイン

S32G399 ベアメタル DDR 初期化 こんにちは！ 私たちは、起動プロセスにおいてこのコアシーケンスを再現しようとしています。 しかし、M7コアによるDDR初期化中にいくつかの問題が発生しました。 1. Design Studioの例から新しいプロジェクトを作成しました;(Linflexd_Uart_Ip_Example_S32G399A_M7: Debug_RAM); 2. DDRの設定と検証を行い、ddr_*.cに関連するソースファイルを生成しました。 3. GoldVIP例およびarm-trusted-firmwareからDDR初期化に関するコードをコピー・調整; 4. main.c には次のようなコードシーケンスがあります。   Clock_Ip_Init(&Mcu_aClockConfigPB[0]); IntCtrl_Ip_Init(&IntCtrlConfig_0); Siul2_Port_Ip_Init(NUM_OF_CONFIGURED_PINS0, g_pin_mux_InitConfigArr0); Mpu_M7_Ip_Init(&MPU_M7_ModuleConfig_0); EnableRdInterconnect(2); // RD2 EnableRdInterconnect(3); // RD3 /* 2. NoC QoS */ FlexNOC_InitNoc(4); // 4 - CORE_ID_M7_0 enable_partition(); ddr_status = ddr_init();   DDRが初期化された後はスリープモードになることに気づいたので、私たちはそれを起動します:   *(volatile uint32_t*)0x403C0000 = 0x83080023; *(volatile uint32_t*)0x403C0020 &= ~0x1; *(volatile uint32_t*)0x403C0030 = 0x0; *(volatile uint32_t*)0x403C0320 = 0x0; *(volatile uint32_t*)0x403C0320 = 0x1;   DDRメモリはアドレス0x60000000から始まるため、Debug Probeでのデバッグ中にアセンブリでメモリが割り当てられていることが確認できます。エラーもハードフォルトもありませんが、GDBで呼び出すと:   set {uint32_t}0x60000000 = 0xDEADBEEF または x/1xw 0x60000000   「アドレス0x60000000のメモリにアクセスできません」と返されます   ddr_status は0を返します。   私たちが何を間違っているのか教えていただけますか?そして、その図はNXPが推奨するS32G399ボードの起動方法として実際に適用できるものなのでしょうか？   ご回答をお待ちしています。 Re: S32G399 Bare Metal DDR initialization こんにちは、 @Interrogator 投稿ありがとうございます。 実は、あなたが言及したフローはS32Gプラットフォームを使う際の典型的なブートフローではありません。 典型的なブートフローは、AN13750やGoldVIPで説明されている通りで、ブートローダーがM7_0(イニットクロックやピンなど)上で動作し、異なるパーティション(M7_1/2、A53_0など)のイメージを読み込みます。一方、Linux BSPはA53_0に読み込まれ、DDRはA53_0上で動作するTFAによって初期化されます。 現在、デザインに取り組んでいるか教えていただけますか?もしそうなら、上記のブートフローを使うことが比較的推奨されます。 BR チェイン Re: S32G399 Bare Metal DDR initialization @chenyin_hこんにちは！ 1.当社では、SW3、SW6.1-2、SW10.1-2、SW12.1-2のピンのみを備えたカスタム基板を使用しています。 2. マシン上でbitbakeを実行し、ソースコード（カーネル、ブートローダー、ルートファイルシステム）からイメージを構築します。 Re: S32G399 Bare Metal DDR initialization @chenyin_h返信ありがとうございます！本当に感謝しています。もう一つ教えてもらえますか?現在ボードは手元にあり、M7にはブートローダーがない可能性があります。Yocto BSP 46で構築されたLinuxイメージをSDカード(.sdcardファイル)に書き込み、ボードにカードを差し込み、ボードのピンをSDカードから読み込むように切り替えましたが、S32G274と同じ動作を期待していましたが、UARTの出力は完全に空でした。COMセッション（MobaXterm）中にボタンを押すと、ボード上のRxインジケーターが点滅します。Linux出力を見るにはM7ブートローダーが必要ですよね?私たちの状況で最善の方法を教えていただけませんか? ありがとう！ Re: S32G399 Bare Metal DDR initialization こんにちは、 @Interrogator 確認ありがとうございます 1. 通常、デフォルトのBSPコード/設定では、構築されるイメージはRDB3/EVB3のようなS32G3リファレンスボードの起動をターゲットとしています。 2. カスタムボードを扱っている場合、正しく起動できなかったイメージが作られ、これはカスタムボードの表示問題である可能性があります。 オリジナルのBSP46 BSPに何らかの変更を加えたかどうか、また問題箇所を特定するためのデバッグログがあるかどうかは分かりません。 BR チェイン Re: S32G399 Bare Metal DDR initialization こんにちは、 @Interrogator ご返信ありがとうございます。 M7側を使用する必要がない場合は、BSPのみを使用してボードを起動すれば十分です。(M7ブートローダーはこのような設定では必須ではありません。 あなたが遭遇した問題に関して 1. どのような種類のボードが使用されていますか？カスタムのものか、NXPのリファレンスデザインか? 2. SDカードに書き込まれるBSP46イメージはどのように生成されるのですか？既製のイメージとカスタムイメージのどちらが使用されますか？ BR チェイン 

S32K376NHT1MJBST：適用可能な電力推定器および電源ごとの電流データ こんにちは、 S32K376NHT1MJBSTに適用される電力推定ツールと供給電流データを教えていただけますか? S32K-PETはこの派生モデルをサポートしていますか?どのツールとデバイスデータセットの改訂版を使用すべきですか？もしサポートされていない場合、現在の推奨されているNXP方法は何ですか? 外部供給のV15に外部NMOSのV11レギュレータ配置がある場合、報告された需要はV15、V11、VDD_HV_A/Bおよびその他のアナログ/バイアス供給にどのように帰属すべきでしょうか?特にレギュレーター損失、共有コア/ロックステップ需要、I/O負荷、ペリフェラル電流などを含め、何が含まれているか、何が除外されているかを特定してください。これらが二重にカウントされないようにするためです。 どの適用可能な公文書、データ、特性評価方法が、最悪のケースの電源電流と電圧/温度、リセット、起動、ウェイク、クロック/モード変更時のピークをカバーしていますか?標準値／平均値と保証限度額を区別し、それぞれの条件を明記してください。 公開されているPETページとセットアップガイドを確認しました。ファミリレベルの支援リストと初期の平均出力範囲では、正確な微分やすべての物理的供給貢献は特定されていません。私たちは、定義された運用プロファイルのない応用特有の現行結果ではなく、適用される情報源と方法を求めています。 これらの詳細が公開されていない場合は、適切な公開資料やサポートルートをご紹介ください。 よろしくお願いします。 Re: S32K376NHT1MJBST: applicable power estimator and per-supply current data こんにちは、@JonasGranlund さん。 1.現時点で、S32K PETツールはS32K39/37/36デバイスをサポートしていません。推奨される方法は、S32K396のデータシート(Rev.5) 供給電流データについては、具体的には： 6.7 供給電流（スタンバイモードおよび動作モードの表） 6.9 周期的なウェイクアップ平均電流の計算 2. データシートの供給電流表には、以下のレールにおける電流が個別に記載されています。 VDD_HV_A メインのI/Oおよびアナログ電源としてカタログ化されており、VDD_HV_AバンクのI/Oパッドとすべてのアナログブロックをカバーしています。 VDD_HV_Bは二次I/O電源であり、VDD_HV_Bバンク内のI/Oパッドのみを対象としています。どのピンがどのパワードメインに属しているかを特定するために、リファレンスマニュアル内の「S32K39_and_S32K37_IOMUX.xlsx」アタッチメントを参照できます。 V11は、外部NMOSを用いてV15によって生成される。LPMモードに入る前に、外部V1.5電源をオフにしてください。 IO負荷電流は測定値に含まれていません。IOの現在の要件は、アプリケーションのI/O構成によって異なります。S32K39データシートのDC特性表を参照してください。 データシートのコア供給量には、ロックステップ/デュアルコア動作時の需要が含まれています。コアの負荷に応じて個別の仕様が定められていないため、消費電力は同じ値として規定されています。 3．データシートの値には、周囲温度、標準値、最大値が含まれます。 私の知る限り、最悪のシナリオの電流やリセット時のピークなどを詳述したS32K39の文書は存在しません。しかし、S32K3の低電力パワーマネージメントANおよびデモでは、電源モードの遷移、低消費電力モードのクロック動作、ハードウェアの考慮事項、静止電流が記載されています。よりファミリレベルに焦点を当てており、S32K39-37-36の詳細ではなく、S32K3xx全体を指しています。 S32K3の低消費電力動作と留意事項について説明したS32K3低消費電力ラボのプレゼンテーションを、コミュニティ共有のプライベートメッセージでお送りしました。 よろしくお願いします、 ジュリアン

88W8987 使用 FreeRTOS 时，AP 模式下 WPA2 认证间歇性失败 您好， 我们使用基于 88W8987 的 Murata LBEE5QD1ZM 模块，通过 SDIO 连接到运行 FreeRTOS 和 NXP Wi-Fi 驱动程序的 i.MX RT1176。 某些设备，特别是 Multilaser M10 安卓平板电脑，经常无法使用 PSK/CCMP 连接到我们的 WPA2-Personal AP。有时，同一台平板电脑在多次尝试后才能成功连接。其他设备，例如三星 S9 FE，连接正常。 虽然安卓系统显示“正在获取 IP 地址”，但日志显示 WPA2 四次握手过程中出现故障： - AP 报告了站点关联，但没有 RSN_CONNECTED 事件。 - Android 日志显示接收到 EAPOL 消息 3 并发送消息 4，随后 AP 再次转发消息 3。 - 关联后约 18 秒，AP 报告取消认证，原因为 1。 - 当出现 RSN_CONNECTED 时，DHCP 正常完成。 受影响的平板电脑可以正常工作，开放式和 WEP 连接均可正常使用。固件版本 16.91.21.p82 和 16.92.21.p156.4 仍然存在此问题。 一个重要的对比是另一款在 Linux 下使用相同模块模型的产品：M10 使用 WPA2-PSK/CCMP 成功连接，验证芯片通过 hostapd 在主机上运行。在我们的 FreeRTOS 实现中，握手由 88W8987 固件管理。 这些观察结果表明固件管理的验证芯片存在互操作性问题。但是，如果没有空中捕获，我们无法确认消息 4 是否到达模块，也无法确认为什么它不被接受。 这是已知问题吗？是否有固件修复程序或诊断选项来跟踪验证芯片状态并确定握手无法完成的原因？ 此致， JV Melo。 Re: 88W8987 Intermittent WPA2 Authentication Failure in AP Mode with FreeRTOS 你好@joseviniciusmelo 能否帮忙分享一下iMX1176的SDK版本？ 顺祝商祺！ 肖恩 Re: 88W8987 Intermittent WPA2 Authentication Failure in AP Mode with FreeRTOS 嗨，肖恩， 我测试了以下88W8987固件版本和SDK： 16.91.21.p82，MCUXpresso SDK 2.13.1； 16.92.21.p156.4，带 MCUXpresso SDK 26.09.00； 在我们的 FreeRTOS 平台上，两个版本都出现了同样的间歇性 WPA2 身份验证失败问题。 同一台平板电脑可以成功连接到另一台在 Linux 系统下使用相同模块型号的产品，其中 hostapd 在主机上处理 WPA2 握手。由于模块固件在我们的 FreeRTOS 平台上处理握手，我们怀疑与固件的 WPA2 验证芯片存在互操作性问题。 此致， JV Melo。

88W8987 Intermittent WPA2 Authentication Failure in AP Mode with FreeRTOS Hi, We are using the Murata LBEE5QD1ZM module, based on the 88W8987, connected through SDIO to an i.MX RT1176 running FreeRTOS and the NXP Wi-Fi driver. Some devices, especially a Multilaser M10 Android tablet, frequently fail to connect to our WPA2-Personal AP using PSK/CCMP. Occasionally, the same tablet connects successfully after several attempts. Other devices, such as a Samsung S9 FE, connect normally. Although Android displays “Obtaining IP address,” the logs indicate a failure during the WPA2 four-way handshake: - The AP reports station association, but no RSN_CONNECTED event. - Android logs indicate reception of EAPOL message 3 and transmission of message 4, followed by further retransmissions of message 3 from the AP. - Approximately 18 seconds after association, the AP reports deauthentication with reason 1. - When RSN_CONNECTED does occur, DHCP completes normally. Open and WEP connections work with the affected tablet. The problem persists with firmware versions 16.91.21.p82 and 16.92.21.p156.4. An important comparison is another product using the same module model under Linux: the M10 connects successfully using WPA2-PSK/CCMP, with the authenticator running on the host through hostapd. In our FreeRTOS implementation, the handshake is managed by the 88W8987 firmware. These observations suggest an interoperability issue in the firmware-managed authenticator. However, without an over-the-air capture, we cannot confirm whether message 4 reaches the module or why it is not accepted. Is this a known issue? Is there a firmware fix or diagnostic option to trace the authenticator state and determine why the handshake does not complete? Best regards, J. V. Melo. Re: 88W8987 Intermittent WPA2 Authentication Failure in AP Mode with FreeRTOS Hello @joseviniciusmelo  Could you help share sdk version of iMX1176? Best Regards Shaun Re: 88W8987 Intermittent WPA2 Authentication Failure in AP Mode with FreeRTOS Hi Shaun, I tested the following 88W8987 firmware versions and SDKs: 16.91.21.p82 with MCUXpresso SDK 2.13.1; 16.92.21.p156.4 with MCUXpresso SDK 26.09.00; The same intermittent WPA2 authentication failure occurred with both versions on our FreeRTOS platform. The same tablet connects successfully to another product that uses the same module model under Linux, where hostapd handles the WPA2 handshake on the host. Since the module firmware handles the handshake on our FreeRTOS platform, we suspect an interoperability issue with the firmware’s WPA2 authenticator. Best regards, J. V. Melo.

S32K344 QuadSPI 至外部 NVM 存储器 我正在使用 QuadSPI 模块与外部 FRAM NVM 设备 CY15B102QSN 进行通信。为了简单起见，我目前使用单 SPI 模式来使用该设备和模块。 我创建了用于读写内存的例程和 LUT 序列来支持读写操作。我的问题是，这些函数和查找表序列的流程应该是什么。 s32k344 参考。手册在这方面写得不太清楚。 要对NVM进行读写访问，我需要写入S32K344上的哪些寄存器？如果能提供一个很好的NXP驱动程序示例，那就太好了。 阅读并编写以下示例函数。 // 读取序列 =============================================== 我使用 BFGENCR 寄存器来指定 READ命令中的 LUT 序列。 然后使用 C 语句将内存地址读取到一个变量中。 // 示例 sudo 代码 /* AHB 读取四路操作*/ for(unit32 i=0; i < buf_size; ++i)         { /* 将 AHB 读取的 LUT 序列 ID 值写入 BFGENCR[SEQID]。*/ quad_base_addr->BFGENCR = (quad_base_addr->BFGENCR & ~QuadSPI_BFGENCR_SEQID_MASK) | QuadSPI_BFGENCR_SEQID(qspi_lut_seq_read_memory); /* 获取下一个数据元素 */ buffer[i] = *(volatile U8_T *)(mem_addr[i]);         } // 写入序列 ============================================== 我不清楚是否可以使用 BFGENCR 寄存器来指定写入命令中的 LUT 序列。 或者说，因为我像在寄存器写入时一样使用 SFAR 和 IPCR。 // 使用 SFAR 和 IPCR 的示例 sudo 代码 for(unint32 i=0; i < buf_size; ++i)         {             /* 写入 WREN 命令以启用对 FRAM 的写入 */ cy15_write_opcode_wren(quad_base_addr, qspi_lut_seq_wren_opcode);             if(G_FALSE == qspi_is_tx_full(quad_base_addr)){     /** 将串行闪存地址寄存器 (SFAR) 加载内存地址 */ quad_base_addr->SFAR = mem_addr;         /* 在触发序列之前，将数据写入 TX FIFO。*/ quad_base_addr->TBDR = buffer[i];         /** 设置 IPCR，序列 ID = (1) 用于写入，IDATASZ = 8 字节 * 序列由此开始。*/ quad_base_addr->IPCR  = QuadSPI_IPCR_SEQID(1) | QuadSPI_IPCR_IDATSZ(8);         /* 等待操作完成再返回。*/                 if( G_FALSE == qspi_wait_for_idle(quad_base_addr)){ ret_val = QSPI_TIMEOUT_BUSY; }         }     } // 或者使用与读取操作更相似的操作 ======================= /* AHB 写入四元组操作 */ for(i=0; i < buf_size; ++i)         {             /* 将 AHB 写入的 LUT 序列 ID 值写入 BFGENCR[SEQID]。*/ quad_base_addr->BFGENCR = (quad_base_addr->BFGENCR & ~QuadSPI_BFGENCR_SEQID_MASK) | QuadSPI_BFGENCR_SEQID(qspi_lut_seq_write_memory); /* 获取下一个数据元素 */ *(volatile U8_T *)(mem_addr[i]) = buffer[i];     } Re: S32K344 QuadSPI to external NVM Memory 您的 AHB 读取流程原则上是正确的，但需要在读取循环之前配置一次 BFGENCR[SEQID]，而不是每个字节都配置一次。例如，从 QSPI AHB 窗口读取 QSPI 基地址加上 FRAM 偏移量。如果 mem_addr 是基地址，则使用基地址加上当前偏移量，而不是 mem_addr[i]。 S32K344 不支持 AHB 写入访问。因此，不要使用 BFGENCR 后跟指针写入。通过 IP 命令写入 FRAM： 按照 CY15B102QSN 数据表的要求发送 WREN。 将外部 FRAM 偏移量（而不是内存映射的 CPU 地址）写入 SFAR。 通过 TBDR 将完整的写入数据加载到 TX FIFO 中。 使用写入 LUT 序列 ID 和 IDATASZ 写入 IPCR。 等待 QuadSPI 模块空闲且 IP 事务完成。 在所示示例中，IDATASZ 为 8，但只有一个缓冲区元素加载到 TBDR 中。要么加载全部 8 个字节并执行一个 8 字节的事务，要么使用 IDATASZ 等于 1 来执行一个字节的事务。第一个方案更可取。SFAR 也必须针对每个模块进行升级。WREN 应按照 FRAM 数据手册的要求，在每个完整的写入事务中处理，而不是在加载单个字节时无意中重复处理。 对于 IP 读取，将 FRAM 偏移量写入 SFAR，通过 IPCR 开始读取序列，并从 RX 缓冲区读取结果。对于普通读取，AHB 方法更简单、更高效。 LUT 必须与 CY15B102QSN 协议匹配：单焊盘命令、地址和数据阶段，以及正确的地址宽度。除非适用于此 FRAM，否则请勿添加 或非-Flash 擦除或 WIP 处理。Qspi_Ip_Example_S32K344 和 FRDM-A-S32K344 的 QSPI Flash Memory Read/Write demo 可以作为起点，但它们的 或非-Flash LUT 命令和状态处理必须针对 FRAM 进行调整。 Re: S32K344 QuadSPI to external NVM Memory 谢谢你的回复。 相关但又新的问题，一般是关于 IP 写入和读取的。当我向 FRAM 发送 RDID 操作码（读取 8 字节设备 ID）时，我得到的响应与预期的字节顺序相反。尝试调整 S32K344 QuadSPI MCR 寄存器设置。看来保留位会影响字节顺序。参考文献中没有相关记录。手册中特别提到，MCR[位 3,2]会影响 RX 字节顺序。还有其他保留位会影响发送字节顺序吗？您能解释一下其他保留部分的作用吗？

S32N55 A/B 交换 OTA — 被动库资产 (PaCo/Codef/SMR) 安装时序和运行时闪存访问 环境：S32N55，FSS 固件 1.19.0 (D2604)，GrayVIP 1.0.25，HSE2，已启用安全启动。 目标：实现 A/B 交换 OTA。活动存储体 A 位于 AHB 0x10000000，被动存储体 B 位于 0x14000000（闪存偏移 0x04000000）。我正在尝试让正在运行的 FSS（活动库 A）安装被动库的 PaCo/Codef/SMR，然后交换 IVT 并重新启动到库 B。 我的发现： 正在运行的 FSS 无法读取 0x14000000 处的被动存储体。使用 T32（XSPI 配置为 4 字节读取，命令 0x13）时，0x14000000 处的数据可以正确读取，但在运行时，FSS/QSPI 使用 OPI 读取，这似乎是 3 字节寻址（~16MB 范围），因此任何对 0x14xxxxxx 总线的访问都会导致故障。银行 A 之所以能正常运行，是因为它使用的所有数据都在 16MB 以内。 强制重新安装运行时资源会导致电路板硬故障/RESET。当我在 FSS 资产安装函数（InstallPaCo / InstallSMRs / InstallCodefs / AuthenProcess）中绕过“SYS-IMAGE 已加载”门，在运行时重新运行安装时，即使我选择的是活动（可读）存储体，板也会重置。这表明资产安装不应该在队列（CRS/RTU）已经执行时运行。 问题： FSS 资产安装（通过 HSE 安装 PaCo/Codef/SMR）是否仅在启动/配置阶段（在队列发布之前）受支持，而不在 CRS/RTU 运行时受支持？ 对于 A/B 交换 OTA，预期的激活顺序是什么？在写入被动存储体并交换 IVT 之后，被动存储体的 Codef（其映像源地址取决于存储体）、SMR 和 PaCo 何时以及如何安装/验证？ 运行中的 FSS 是否需要在运行时访问被动存储体 (0x14000000)（即，运行时读取路径是否应该使用 4 字节寻址），还是被动存储体仅在下次启动时由启动 ROM 访问？ 在 A/B 互换交易中，各银行的 PaCo 值是否不同？PaCo 包含闪存范围地址（0x10xxxxxx / 0x11xxxxxx），那么被动存储体的 PaCo 是否像 Codef 一样需要重新定位，还是与存储体无关？ S32N5 Re: S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash acc 陈音，谢谢你的快速回复。 为了澄清我的问题：我并没有依赖内置的 SCMI 服务。我已经实现了我自己的运行时 PaCo/CoDef 安装，作为 A/B 银行交换 OTA 的一部分。该设计与银行无关：运行中的（活动的）FSS 在运行时安装被动银行的资产，然后交换 IVT 主指针 (0x10000000 ↔ 0x14000000) 并重新启动到另一个银行。我直接重复使用现有的 FSS 安装状态机来实现这一点。 所以我的真正问题是，这种方法在当前的FSS上是否可行，因为在测试中它在某个特定点失败了。 有效方法：当安装目标指向活动银行时，完整路径完成（PaCo/Owner/Keys，SMR 安装返回 OK，FSS FW SMR0/AuthenProcess OK；Codef-install 和 ValidateBootConfig 在已发布的 SYS-IMG 下返回 NOT_ALLOWED，因此我将它们推迟到下一次启动的 BootCfgVerify）。然后 BTM 继续执行 PublishSysImage + EnableGlobalSecureBoot。 失败的原因：当安装程序以被动存储体为目标时，在 FSS 首次在 AHB 0x14013000 处取消引用被动存储体 PaCo 时，IndexSourcesStep 中会发生总线故障。活动银行地址（0x10xxxxxx）读取正常。 我追溯到的根本原因：问题不在于 AHB 窗口或地址。MemAcc_Init()（初始化 Mem_43_EXFLS，MemPerformDeviceConfiguration=TRUE）在 Fss_Firmware_InstallPacoCodefs() 之前运行，因此在安装时 SFA1D 已经是 0x18000000（128 MB），AHB 读取已启用，读取 LUT 为 4 字节 OPI-DDR。即使我通过 T32 手动确认 SFA1D = 0x18000000，0x14013000 仍然返回硬总线错误（不是 SFP 错误有效载荷）。这表明 XSPI 安全闪存保护 (SFP)：覆盖被动区域的 FRAD 没有授予访问主功能域 RW 权限。当我将 FRAD 覆盖范围扩展到整个闪存并将 Md4Acp 设置为 RW 时，访问行为发生了变化。 我的问题： 在当前的 FSS（启用安全启动）架构上，是否支持通过重复使用上述安装函数将 PaCo/CoDef 运行时安装到被动存储体中？或者在参考 OTA 可用之前，是否存在我应该注意的重大障碍？ 这种临时方法有什么注意事项吗？例如，为目标存储体安装 FSS FW SMR0（AuthenProcess），并将 CoDef/启动-config 检查推迟到下次启动的 BootCfgVerify 中？ 谢谢， 埃迪 Re: S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash acc 你好， @EddiePark 感谢您的帖子，很高兴再次支持您。 当前 FSS 不提供 SCMI 服务以在运行时安装 PaCo 和 CoDef。 目前，S32N 的 OTA 参考实现仍在开发中，如果可能的话，我建议在它可用时直接参考它来实现您自己的 OTA 流程。 BR 陈银   Re: S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash acc 您好，经过系统调试后，我将提供更多详细信息。 配置：S32N55，FSS固件1.19.0，安全启动。A/B 银行间互换 OTA。运行中的 FSS (M7) 在运行时安装被动银行的 PaCo/CoDef（我们自己的实现，重复使用 FSS 安装状态机）。被动银行基址 = 0x14000000。 故障：在 Fss_Firmware_IndexSourcesStep 中，FSS-M7 对 0x14013000 处的被动存储体 PaCo 执行直接 AHB 内存映射读取（CPU 解引用），并出现精确的 BusFault： CFSR = 0x00008200 → BFSR: PRECISERR=1, BFARVALID=1, MMFSR=0 BFAR = 0x14013000 我们已排除以下可能性（并附有证据）： MPU：并非病因。MMFSR=0。MPU 区域 2 = 外部闪存 0x10000000–0x1FFFFFFF，普通可缓存 WB，只读 → 覆盖 0x14013000，允许读取。 SFP：并非原因。设置 MemXspiSfpEnable = FALSE 并重新构建 → 出现同样的错误。（无论如何，FRAD 都会将该区域授予相关功能域。） AHB 窗口：SFA1D = 0x18000000 (128 MB) → 银行 B 位于窗口内。 关键观察结果——这并非特定于某家银行，而是“新鲜数据与缓存数据”的问题： 读取/故障边界正好是 0x13780000（0x1377FFFF 读取，0x13780000 故障）。这是固件映像区域（FSS/CRS/HSE/RTU/Sys_Img）的结束/数据区域（IDS…）的开始。从基本容量算起是 56 MB——不是 2 的幂，所以它不是硬件大小的边界；它恰好是 FSS 在启动期间读取和缓存的范围（外部闪存区域是可缓存的）。 → FSS 在启动期间读取的所有内容（现在位于数据缓存中）都可以正常读取。任何需要 FRESH（未缓存）直接 AHB 读取故障的地址——包括低于 0x14000000 的地址（例如，0x13780000 位于活动的 64 MB 内存中，并且也存在故障）。所以真正的问题是：对外部闪存进行新鲜的、未缓存的、直接的 AHB 内存映射读取在运行时失败。 MemPerformDeviceConfiguration 测试： MemPerformDeviceConfiguration = TRUE（设备初始化运行 → 八进制 DDR）：闪存写入工作（通过 MemAcc INDIRECT_STATIC 的间接/IP 命令），缓存读取工作，新的 AHB 读取失败。 MemPerformDeviceConfiguration = FALSE（跳过设备初始化）：读取操作全部返回 0x00（设备未保持在八进制 DDR 模式）。 因此，当设备正确设置为八进制 DDR 时，写入操作成功，但新内存映射的读取操作失败。由于八进制 DDR 外部 DQS 读取使用设备 DQS 选通进行采样，而写入则不使用，这表明存在读取路径（DQS/DLL/虚拟/时序）问题。 配置上下文： 只有 FSS 配置 XSPI 控制器（Xspi_Ip_paXspiUnitCfg，MemPerformDeviceConfiguration = TRUE，八进制 DDR，外部 DQS，DLL 已绕过）。CRS 和 RTU 跳过控制器配置（XspiUnit = NULL，DeviceConfiguration = FALSE），并继承启动配置。 qspi 参数（xspi_S28H_octal_ddr_200Mhz_dll_bypass_ext_dqs.bin）包含在生成的 VIP/IVT blob 中。 问题： 在当前的 FSS 中，FSS-M7 是否能够对任意/未绑定的地址在运行时（MemAcc_Init 之后）执行直接的 AHB 内存映射读取外部 XSPI 闪存？或者运行时闪存读取必须通过间接（IP 命令）Mem/MemAcc 路径？ 为什么在 SFA1D=128 MB、SFP 已禁用且 MPU RO 覆盖该区域的情况下，直接 AHB 读取未缓存地址会返回精确的 BusFault，而写入（间接）和缓存读取却会成功？ FSS 的 MemAcc_Init 控制器重新配置是否与启动 qspi-param XSPI 读取设置冲突，以致于内存映射读取中断？FSS 是否应该跳过控制器重新配置（如 CRS/RTU）并继承启动 qspi-param 配置？如果是这样，我们如何保留闪存写入支持？ 对于 S28HS01GT 上的 200 MHz 八进制 DDR / 外部 DQS / DLL 旁路，可靠的内存映射读取需要哪些 DLL / DQS / 虚拟周期设置？（我们怀疑我们的 FSS 读取配置与正常工作的启动 qspi-param 配置不同。） 谢谢， 埃迪 Re: S32N55 A/B swap OTA — passive-bank asset (PaCo/Codef/SMR) install timing & runtime flash acc 你好， @EddiePark 抱歉回复晚了，因为我休假了。 请问您是否修改过以下设置？TG0 的访问控制策略 → 将所有实例更改为 XSPI_IP_SFP_ACP_RW，然后测试通过 FSS 访问闪存地址时问题是否仍然存在。 BR 陈银

Is SodaPeak Worth Buying? An Honest Review for 2026 SodaPeak:- Unlike traditional supplements that require swallowing capsules or preparing powders, SodaPeak offers a simple approach that can fit into a busy lifestyleThe product focuses on three important areas of men's wellness: everyday energy, physical endurance, and general vitality. Official Website:- https://finance.yahoo.com/healthcare/articles/sodapeak-launch-2026-advanced-soda-174000686.html

Does i.MX 95 support simultaneous 4K60 decode/encode? Hi, Does i.MX 95 support simultaneous 4K60 decode/encode? If not, does NXP have other processor that can support it? Thanks, Fan Evaluation Board Re: Does i.MX 95 support simultaneous 4K60 decode/encode? Hi @fan99  Simultaneous 4K60 decoding and 4K60 encoding is not supported. The iMX95 VPU supports up to 4K60 shared between encode and decoder.  Best Regards, Zhiming

MPC8308CVMAFD 与 MPC8308CVMAFDA 您好， 我们希望就以下零件编号寻求您的技术意见： MPC8308CVMAFD MPC8308CVMAFDA 请问这两个零件编号之间有什么区别吗？ 根据产品规格书，附加字母“A”表示版本号。然而，我们未能找到任何进一步的信息来解释具体的版本号及其对设备的影响。 请您确认这两个零件编号在电气性能和功能上是否相同，是否可以互换。 非常感谢您的帮助。 Re: MPC8308CVMAFD Vs MPC8308CVMAFDA ### 1. 两个零件编号的区别 **MPC8308CVMAFD** 和 **MPC8308CVMAFDA** 之间的唯一区别在于 **内部硅步进/版本**： * **`MPC8308CVMAFD`**：代表**硅版本 1.0**。 * **系统版本寄存器 (SVR)：** `0x8101_0110` * **`MPC8308CVMAFDA`**：代表**硅修订版 1.1**（末尾字母**“A”**表示飞思卡尔/恩智浦部件编号方案中的修订版 1.1）。 * **系统版本寄存器 (SVR)：** `0x8101_0111` 两台设备的标称参数完全相同： * **封装：** 473引脚MAPBGA（19毫米×19毫米，0.8毫米引脚间距） * **温度等级：**扩展/工业级（`C` = -40°C 至 105°C $T_j$） * **核心频率：** 333 MHz (`AF`) * **DDR 数据速率：** 266–333 MHz (`D`) * **无铅/符合RoHS标准：**无铅MAPBGA（`VM`） --- ### 2. 硬件等效性（外形、尺寸、功能） * **电气和机械方面：** **引脚完全匹配，即插即用。** * 无需对PCB布局、原理图、布线、电源或去耦进行任何更改。 * 焊球分配、电压轨（$V_{DD} = 1.0\text{V}$、$G_{VDD} = 1.8\text{V}$、$N_{VDD} = 3.3\text{V}$）、I/O 驱动强度和 AC/DC 时序规格相同。 --- ### 3. 硅芯片差异及软件影响 Silicon Revision 1.1 (`MPC8308CVMAFDA`) 版本，其中包含了对 Revision 1.0 的一些内部错误/勘误的修复。 对于 99% 的应用，**Rev 1.1 完全向下兼容 Rev 1.0**。但是，请记住以下两点软件方面的注意事项： 1. 系统版本寄存器 (SVR) 检查： * 如果您的引导加载程序（U-Boot）、内核或专有固件明确读取并匹配精确的 32 位 SVR 值： * Rev 1.0 返回 `0x8101_0110` * 版本 1.1 返回 `0x8101_0111` * 确保代码中的任何硬件版本检查屏蔽或接受低 4 位（例如，与 `0x8101_011x` 匹配或检查 $\ge \text{Rev } 1.0$），以免启动序列停止。 2. **硅谷勘误解决方法：** * Rev 1.0 中存在的几个已知错误在 Rev 1.1 中得到解决或改进（记录在 *MPC8308 芯片错误* 文档 `MPC8308CE` 中）。 * 固件中针对 Rev 1.0 实现的软件变通方案在 Rev 1.1 上将继续安全运行。 --- ### 总结建议 **MPC8308CVMAFDA 是 MPC8308CVMAFD 的直接推荐替代品。**它们在外形、尺寸和功能上都是即插即用的替代品。只要你的固件没有对 SVR 寄存器进行硬编码的精确匹配检查，你就可以安全地替换 `MPC8308CVMAFDA`，而无需重新设计板。

KW45B41Z-LOC：应用程序运行后SWD失效；只能通过ISP/SW4刷写；应用程序无法运行或显示任何提示信息。 硬件和软件 电路板：KW45B41Z-LOC，电路板/PCB版本[填写]，手册KW45B41Z-LOCUM Rev. 2 主机：Windows，MCUXpresso IDE 25.6.136链接服务器 26.9.130SPSDK 3.12.0（blhost） SDK：kw45b41z-loc SDK 软件包（文件夹名称中的版本为 25.12.0） MCU-Link：板载，CMSIS-DAP 固件版本 V3.160，后续版本为 V3.174 仅通过 USB (J3) 供电，未连接 CAN 12V 电源。 跳线：默认值见表 3，JP12 开路，JP16 仅对 ISP 短接。[请确认 JP1、JP2、JP3、JP10、JP13、JP14、JP21、JP22、JP25 的实际位置。] 问题 当应用程序位于闪存中时，SWD 调试和对 KW45 的闪存访问都会失败。只有当芯片首先通过 SW4 保持在 ISP 模式时，刷写程序才能正常工作。 我们观察到 初始失败（库存 kw45b41zloc_wireless_uart_freertos）：探针连接（DAP ID 6BA02477，Cortex-M33，“处理器处于安全模式”），然后出现 Nn(05) DAP 访问中的 Wire ACK 故障和连接失败。擦除和编程都会出现同样的失败情况。 ISP 工作正常：在 RESET 期间短接 JP16 并按住 SW4，blhost -p COMxx,115200 -- get-property 1 返回 Success (K3.1.0)，flash-erase-all 返回成功。如果没有SW4，ping命令就不会响应。 擦除后，烧录过程可以进行，但最终出现错误：闪存写入完成（“闪存程序摘要”、“闪存写入成功”）。最后一步失败，并出现以下错误： 使用系统 RESET 和停止目标启动执行，并指定一个停止地址... DAP 访问中的线路 ACK 故障... 警告 - 处理器未停止... 闪存 - 系统 RESET 失败 - Ep(04)。无法停止处理器。 无论是标准的 LOC wireless_uart_freertos 还是我们基于 EVK wireless_uart_bm 开发的 CAN_BLE 项目，都会出现这种情况。 应用程序运行后，SWD 再次丢失：典型错误为 Ee(42) 无法连接到核心，Em(17) 访问位置 0x20008838 后调试端口无法访问，以及 Em(12) 目标拒绝访问位置 0x20008848 的调试端口。在此期间，LED1/LED2 曾出现闪烁现象。 J-Link 固件测试：我们短暂地将 MCU-Link 切换到了 J-Link 固件。即使在空白芯片上，SWD 也失败了（DM-AP IDCODE 错误 0x00000000/0xFFFFFFFF，VTref 3.300 V）。通过 J-Link VCOM 端口的 ISP 仍然有效。我们已恢复到 CMSIS-DAP V3.174 版本。 NBU：擦除后，我们发送了 kw45b41_nbu_ble_hosted.sb3，使用 blhost ... receive-sb-file（成功）。我们不确定这是否是 LOC 板上 wireless_uart 的正确图像。 当前状态：刷机并重新插拔后（JP16 已移除，SW4 未按住，SW1 已按下）： LED1/LED2 不闪烁，VCOM 端口 (115200 8N1) 没有输出。 该板不支持通过蓝牙低功耗 (BLE) 进行广播。 D3 亮度降低，D7 逐渐变暗（MCU-Link 正常模式） Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or 你好@priyanshua1 ， 为了更好地为您提供支持，请您提供以下信息？ - 在发生错误之前，您是否按照任何应用笔记或步骤配置了设备上的任何安全功能？ -发生错误之前，你刷入的是哪个镜像文件？ -之前是否对该设备上的任何熔丝进行过编程？ -我了解到该设备没有运行您刷入的镜像。我的理解正确吗？ -请您执行一次批量擦除操作，在不做任何修改的情况下刷入 led_blinky 示例程序，然后告诉我结果好吗？ 我还建议迁移到最新的 SDK 版本，因为它包含了最新的错误修复、增强功能和整体改进。Visual Studio Code 的 MCUXpresso 扩展程序完全支持最新的 SDK 版本，我也强烈建议您考虑使用该扩展程序。除了支持最新的 SDK 版本外，该扩展还提供了一个现代化且优化的开发环境，支持 Zephyr 和 Matter 等开放标准，以及其他几个优点。如果您感兴趣，可以在他们的情况说明书中找到其益处的概要。 BR 哈比卜 Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or 你好@priyanshua1 ， 为了帮助确定问题是否与调试连接有关，请您使用安全配置工具执行以下测试？SPT 是一个基于 GUI 的应用程序，它简化了 NXP MCU 设备的启动映像的生成和配置。 请按照以下步骤，使用 SPT 中的“连接目标处理器”功能测试调试器连接？ 按照您当前使用的步骤，在 KW45B41Z-LOC 板上进入 ISP 模式。 在 SPT 中打开与目标处理器的连接窗口。 选择合适的COM端口。 点击“测试”按钮，然后告诉我结果。 如果测试结果标记为“OK”，请按照“使用 .elf 文件启动纯镜像或 CRC 镜像”部分中提到的步骤进行操作。一个已建成的LED灯项目的文件。你可以找到 .elf 文件。VS Code 中 debug 文件夹下的文件。   如果您不熟悉安全配置工具 (SPT)，SPT 用户指南中包含一个关于创建新工作区的章节，这可能对您的入门有所帮助。 BR 哈比卜 Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or 你好， 以下是我对您问题的回答： 在发生错误之前，板上已经刷入了无线 UART 和 FlexCAN 应用程序。但是，设备的网络安全配置没有做任何更改。 该设备上未对任何熔丝进行编程。 是的，目前镜像刷新失败。 按照建议，我为 VS Code 安装了 MCUXpresso，并下载了最新的 KW45-LOC SDK（版本 26.09.00）。但是，我仍然遇到同样的错误。 [ 2026-10-27T13:03:36.504 ] [proc] [info]命令：C ":\Program Files\SEGGER\JLink_V980\JLinkGDBServerCL.exe" -listprobes USB [ 2026-10-27T13:03:36.511 ] [ proc] [ info]命令：C: \ NXP\LinkServer_26.9.130 \LinkServer.exe probes --json [ 2026-10-27T13:03:38.049 ] [proc] [info] Cmd: C:\Users\Hondaconceptbench\.mcuxpressotools\arm- gnu-toolchain-14.2.rel1-mingw-w64-x86_64-arm-none -eabi\bin\arm- none-eabi-gcc.exe --version [ 2026-10-27T13:03:38.061 ] [proc] [ info]命令：C:\NXP\MCUXpressoIDE_25.6.136 \ide \ tools\bin\arm- none -eabi-gcc.exe --version [ 2026-10-27T13:03:38.328 ] [proc] [info]命令：C:\Users\Hondaconceptbench\.mcuxpressotools\arm- gnu-toolchain-14.2.rel1-mingw-w64-x86_64-arm-none -eabi\bin\arm- none-eabi-gcc.exe --version [ 2026-10-27T13:03:38.337 ] [proc] [ info]命令：C:\NXP\MCUXpressoIDE_25.6.136 \ide \ tools\bin\arm- none -eabi-gcc.exe --version [ 2026-10-27T13:03:40.870 ] [proc] [info]命令：taskkill /PID 28160 /F /T [ 2026-10-27T13:03:41.291 ] [proc] [info]命令：pkill -P 28160 [ 2026-10-27T13:03:41.296 ] [proc] [error] pkill 退出，错误代码为Error : spawn pkill ENOENT [ 2026-10-27T13:03:41.296 ] [proc] [error] [ 2026-10-27T13:03:41.296 ] [错误] [ 2026-10-27T13:03:41.296 ] [proc] [info]命令：kill - 9 28160 [ 2026-10-27T13:03:41.299 ] [proc] [error] kill 函数退出，错误代码为Error : spawn kill ENOENT [ 2026-10-27T13:03:41.299 ] [proc] [error] [ 2026-10-27T13:03:41.300 ] [proc] [error] kill 函数退出，返回代码-4058 [ 2026-10-27T13:03:41.300 ] [proc] [error] [ 2026-10-27T13:03:41.300 ] [proc] [error] pkill 退出，返回代码-4058 [ 2026-10-27T13:03:41.300 ] [proc] [error] [ 2026-10-27T13:04:19.506 ] [proc] [info]命令：C ":\Program Files\SEGGER\JLink_V980\JLinkGDBServerCL.exe" -listprobes USB [ 2026-10-27T13:04:19.513 ] [proc] [ info ]命令：C : \NXP\LinkServer_26.9.130 \LinkServer.exe probes --json [ 2026-10-27T13:04:20.830 ] [proc] [ info ]命令：C: \ NXP\LinkServer_26.9.130 \LinkServer.exe probes --json [ 2026-10-27T13:04:20.840 ] [proc] [info]命令：C ":\Program Files\SEGGER\JLink_V980\JLinkGDBServerCL.exe" -listprobes USB [2026-10-27T13:04:21.776] [proc] [info] 命令：C:\NXP\LinkServer_26.9.130\LinkServer.exe flash --probe WXZBCIEABA3EA --no-启动 KW45B41Z83xxxA:KW45B41Z-LOC erase --sector [ 2026-10-27T13:04:30.403 ] [proc] [ error] C:\NXP\LinkServer_26.9.130 \ LinkServer.exe退出，返回代码4294967295 [ 2026-10-27T13:04:30.403 ] [proc] [error]固件更新“检查”：不需要 - 可以使用以下命令强制更新：`LinkServer probe # 1 update forced` Ns: LinkServer RedlinkMulti 驱动程序v26.9 ( 2026 年9 月18 日19:34:33 - crt_emu_cm_redlink.exe版本1382 ) PC：（ 0 ）读取远程配置 Wc( 03 )。不支持缓存。 Nc：在 C:\Users\HONDAC~ 1 \AppData\Local\Temp\tmpa5n5cx_7\crt_directory.xml中找到通用目录 XML 文件 PC：（ 5 ）远程配置完成 Nc：已重新连接到现有 LinkServer 进程。 Nc：连接到探测器1核心0 （使用外部启动的服务器）报告：     “Ee(42)。无法连接到核心网。” Nc：正在重试…… Nc：已重新连接到现有 LinkServer 进程。 Nc：服务器正常，但无法连接到探测1核心0 （尝试3次后）- Ee( 42 )。无法连接到核心。 Wc: ============= 脚本: KW45B41_connect.scp ============= Wc：KW45B41 连接脚本 Wc：正在连接到探针索引 = 1 Wc：DpID = 6BA02477 WC：错误：AP 未就绪 Wc: ============= 脚本结束 ================================ Nc：探针固件：板载 MCU-LINK (r0E3) CMSIS-DAP V3.174 (NXP 半导体) Nc：序列号：WXZBCIEABA3EA Nc: VID:PID: 1FC9:0143 Nc：USB路径： 0001:0014:00 Nc：连接失败 - Em( 01 )。找不到核心索引选择的 MEM-AP（请检查目标功率）。正在重试。 Ed:02 ：连接失败：Em( 01 )。找不到核心索引选择的MEM-AP（请检查目标功率）。 Et：探针（ 0）😞 已连接&重置。之前状态：未连接。DpID：6BA02477。CPU ID： 00000000 。 信息 ： Nc:   最后一个短截线错误 0: 正常 Nc：上次粘滞错误： 0x0 AIndex： 0 Nc：未选择调试总线（MemAp）。 Nc：DAP速度测试未执行或失败 Nc：调试协议：SWD。RTCK：已禁用。向量捕获：已禁用。 PC：（ 100 ）目标操作失败 -------------------- 闪存擦除概要： 错误：Flash： 0x00000000 - 0x00100000 （ 0x00100000字节）[ KW45B41.cfx ] 信息：找到与 KW45B41Z83xxxA:KW45B41Z-LOC 完全匹配的项 信息：已选择设备 KW45B41Z83xxxA:KW45B41Z-LOC 信息：已选择探针 # 1 WXZBCIEABA3EA（板载 MCU-LINK (r0E3) CMSIS-DAP V3.174 ） 信息：MCU-Link 固件更新“检查”：探针 ([WXZBCIEABA3EA] [MCU-LINK 板上 (r0E3) CMSIS-DAP V3.174]) 已运行与包含的固件版本 [3.174]相同的固件版本 错误： Flash ： 0x00000000 - 0x00100000 （ 0x00100000字节）[ KW45B41.cfx ] 错误信息：异常：闪存操作退出，返回代码1 严重错误：出现严重错误 错误信息：异常：擦除一个或多个闪存失败 补充说明： 当尝试使用 SPSDK 元器件擦除内存或扫描 NXP 设备时，我需要短接 JP16 跳线并按住 SW4，才能检测到电路板或继续进行擦除操作。 请问造成这种现象的可能原因是什么？能否提出解决此问题的后续步骤？ PS C:\Users\Hondaconceptbench> blhost -p COM19,115200 --get-property 1 SpsdkNoDeviceFoundError：接口“uart”，参数为“port=COM19，baudrate=115200，timeout=5000”：在端口 COM19 上找到设备，但未响应 115200 波特率的 PING 请求。确保设备处于引导加载程序模式。 请查看调试日志文件：C:\Users\Hondaconceptbench\AppData\Local\nxp\spsdk\3.12.0\Logs\debug.log，了解更多信息。 PS C:\Users\Hondaconceptbench> blhost -p COM19,115200 --get-property 1 响应状态 = 0 (0x0) 成功。 响应词 1 = 1258488064 (0x4b030100) 当前版本 = K3.1.0 PS C:\Users\Hondaconceptbench> blhost -p COM19,115200 -- flash-erase-all SpsdkNoDeviceFoundError：接口“uart”，参数为“port=COM19，baudrate=115200，timeout=5000”：在端口 COM19 上找到设备，但未响应 115200 波特率的 PING 请求。确保设备处于引导加载程序模式。 请查看调试日志文件：C:\Users\Hondaconceptbench\AppData\Local\nxp\spsdk\3.12.0\Logs\debug.log，了解更多信息。 PS C:\Users\Hondaconceptbench> blhost -p COM19,115200 -- flash-erase-all 响应状态 = 0 (0x0) 成功。 PS C:\Users\Hondaconceptbench> Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or 第一 张 图片 中 ， 我 开始 测试 时 手持 SW4 ， 测试 成功 完成 。 第二 张 图片 中 ， 我 没有 手持 SW4 ， 导致 测试 失败 。 以下是这两项测试的结果。 1. SPT连接测试 ISP 模式（JP16 短接，RESET 期间按住 SW4），COM19，115200：结果OK 。模式：ROM引导加载程序，生命周期：OEM开放，KW45Z41083匹配。已附截图。 2. 启动一个纯镜像 我从 kw45b41zloc_led_blinky 项目（ELF 转换为 BIN，创建了可引导镜像）构建了一个 Plain unsigned 镜像，并使用 SPT “写入镜像” 将其写入。结果为成功（get-property、pre-erase 和 write-memory 都成功了）。日志已附上。 写入完成后，我松开了 SW4，移除了 JP16，重启了板，然后按下了 SW1。LED灯不闪烁，因此电路板上没有明显显示应用程序正在运行。 blhost -p COM19,115200 -- get-property 1 without SW4 held: responds 问题概述 ISP连接和编程工作。当应用程序在闪存中时，使用 MCUXpresso/LinkServer 的 SWD 会出现故障（“DAP 访问中的线路 ACK 故障”、“无法停止处理器”、“调试端口无法访问”）。闪存被擦除后，SWD 连接并闪烁，但最后的 RESET 和停止步骤失败。 Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or 你好@priyanshua1 ， 我注意到您目前在工作区中使用的是 KW45Z41083 处理器。使用此设备是否有具体原因？例如，您是否遵循 AN14003？ KW47-LOC 使用 KW45B41Z 处理器，如KW45B41Z-LOC 板用户手册第 1.2 章“设备特性”中所述。请您使用 KW45B41Z 处理器创建一个新的工作区，并重复之前提到的步骤。这次，请在用闪存编程器工具对映像进行编程之前，也擦除整个片上闪存。 之后，请您提供以下信息： 写入镜像时生成的日志。 使用 Flash Programmer 工具再次读取写入映像的内存区域的结果。 另外，能否请您提供一下使用OTP/IFR 配置时，处理器输出的 OTP 值？ BR 哈比卜 Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or 你好@priyanshua1 ， 谢谢你提供的信息。 根据日志来看，图像似乎已正确写入。您能使用Flash Programmer 工具看到图像吗？您可以在“工具”窗口中找到此工具： 另外，能否请您帮我澄清以下几点？ 最后几个步骤是否导致了相同的结果？如果可以，请您重复上述步骤，但这次使用 hello_world 示例，并使用 .elf 文件。这是 VS Code 生成的文件吗？您能在终端看到“Hello World”吗？ 在进行测试之前，请您确认跳线是否完全按照KW45B41Z-LOC 板用户手册图 3“KW45B41Z-LOC 跳线”所示进行配置？ 请问这个板是否曾经被重新设计过？如果是这样，能否请您提供更多关于返工的细节？ BR 哈比卜 Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or 你好@Habib_MS ， 很抱歉输入错误。 我已经使用正确的处理器进行了测试。请注意，当我选择KW45B41Z5 作为处理器时，连接测试失败。但使用 KW45B41Z8 时，连接测试通过。请查看附件中的日志和图片。 写入镜像日志： ELF 图像已转换为 BIN 格式：source_images\kw45b41zloc_led_blinky.bin ELF 图像已转换为 BIN 格式：source_images\kw45b41zloc_led_blinky.bin 操作状态：成功：已创建新工作区：C:\Users\Hondaconceptbench\secure_provisioning00 ELF 图像已转换为 BIN 格式：source_images\kw45b41zloc_led_blinky.bin ######################################################################################################################### ## Build image - operation started at 2026-11-06 16:54:25 ## ## Build script is generated: build_image_lnx.sh Build script is generated: build_image_win.bat Build script is generated: build_image_mac.sh Executing script C:\Users\Hondaconceptbench\secure_provisioning00\build_image_win.bat ## ... # ## Create Master Boot Image using nxpimage tool ## # 警告：spsdk.image.mbi.mbi：MBI-kw45b41z8-MbiImageTypeEnum.PLAIN_IMAGE-xip（警告） ======================================== TrustZone 配置（警告） ========================================= 验证 TrustZone 设置和配置类型 ==================================================================================================================== 功能“tz”验证（警告） 实现（警告）：未实现 （自启动以来耗时 1808 毫秒，mbi.py:689） 成功。（主启动映像：C:/Users/Hondaconceptbench/secure_provisioning00/bootable_images/kw45b41zloc_led_blinky.bin 已创建。） # ## RESULT of the script `Building image`: Success (return code = [0]SUCCESS) Status of the operation: Success: Building image Built image: "C:\Users\Hondaconceptbench\secure_provisioning00\bootable_images\kw45b41zloc_led_blinky.bin" ## ############################################################################################################### ## Write image - operation started at 2026-11-06 16:54:46 ## ##################################################################################################################### ## The following fuses status was detected: OTP request: LIFECYCLE |= 0x7 (mask: 0xff); current value=0x7; status=MATCHES SUMMARY: Detected status of fuses for write operation: all fuse(s) match with the requested value(s) Write script generated: write_image_lnx.sh Write script generated: write_image_win.bat Write script generated: write_image_mac.sh Executing script C:\Users\Hondaconceptbench\secure_provisioning00\write_image_win.bat pre_erase ## # 脚本：正在写入映像：C:\Users\Hondaconceptbench\secure_provisioning00\write_image_win.bat # ## SCRIPT arguments: pre_erase ## # 解析输入参数 # ## ## # 检查连接 # ## blhost -t 2000 -p COM19,115200 -j -- get-property 1 0 { "command": "get-property", "response": [ 1258488064 ], "status": { "description": "0 (0x0) Success.", "value": 0 } } blhost succeeded ## # 擦除闪存 # ## ## # 预擦除闪存以防止 RESET 后应用程序启动 # ## blhost -t 50081 -p COM19,115200 -j -- flash-erase-region 0x00000000 8192 0 { "command": "flash-erase-region", "response": [], "status": { "description": "0 (0x0) Success.", "value": 0 } } blhost succeeded blhost -t 50163 -p COM19,115200 -j -- flash-erase-region 0x00000000 16384 0 { "command": "flash-erase-region", "response": [], "status": { "description": "0 (0x0) Success.", "value": 0 } } blhost succeeded ## # 写入镜像 # ## blhost -t 5000 -p COM19,115200 -j -- write-memory 0x00000000 "C:\Users\Hondaconceptbench\secure_provisioning00\bootable_images\kw45b41zloc_led_blinky.bin" { "command": "write-memory", "response": [ 9732 ], "status": { "description": "0 (0x0) Success.", "value": 0 } } blhost succeeded ## # 脚本“写入镜像”的结果：成功（返回码 = [0]SUCCESS） 操作状态：成功：正在写入图像 Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or 你好， 以下是使用 KW45B41Z83 工作区的结果（全部在 ISP 模式下：JP16 短接，RESET 期间按住 SW4）。 Flash Programmer：我擦除了所有内容，写入了纯文本未签名映像，然后读取了 0x00000000-0x000027DF（状态：成功）。向量表存在（SP 0x2001C000，回读时 RESET 向量为 0x00000195）。已附上屏幕截图。 启动结果：释放 SW4、移除 JP16 并重启电源后，LED1 (PTC0) 不闪烁。该项目的 pin_mux 将 PTC0 配置为 LED1 的 GPIO 输出。 hello_world：使用 .elf 文件重复相同的步骤，MCU-Link VCOM 端口 (115200 8N1) 上没有“Hello World”。 此外，从 VS Code 中，GDB 报告 0x14816fdc in ?? () 和错误 103：用上市，不用发布 GDB 失败：完成 flash 操作时出错。终端输出已附上。 启动 GDB: "C:\\NXP\\MCUXpressoIDE_25.6.136\\ide\\tools\\bin\\arm-none-eabi-gdb.exe"-q --interpreter=mi2 重要提示：在“launch.json”文件中将“showDevDebugOutput”设置为“raw”。查看所有 GDB 事务。 启动 GDB 服务器："C:\\NXP\\LinkServer_26.9.130\\LinkServer.exe"-l3 gdbserver "KW45B41Z83xxxA:KW45B41Z-LOC" --probe WXZBCIEABA3EA --gdb-port 2336 --no-启动 --core primary 请检查终端选项卡（GDB 服务器控制台）以获取“C:\NXP\LinkServer_26.9.130\LinkServer.exe”的输出。 输出基数现在设置为十进制 10、十六进制 a、八进制 12。 输入基数现在设置为十进制 10、十六进制 a、八进制 12。 NMI_Handler() 位于 C:/Users/Hondaconceptbench/Documents/MCUXpresso_VSC/SDK_26_09_00_KW45B41Z-LOC/mcuxsdk/devices/Wireless/KW/KW45B41Z83/gcc\startup_KW45B41Z83.S:446 446 ldr r0,=HardFault_Handler 程序停止运行，可能是由于调试器发出的 RESET 和/或停止指令所致。 错误 103：启动 GDB 失败：完成 flash 操作时出错（来自 target-download） 跳跃者：与图 3 相符。 MCU-Link 固件：板载 MCU-LINK (r0E3) CMSIS-DAP V3.174 使用 VS Code 中的 Linkserver Flash Programmer 将 helloworld.elf 烧录到闪存时产生的日志。 [ 2026-11-09T15:04:18.756 ] [ proc] [ info]命令：C : \NXP\LinkServer_26.9.130 \LinkServer.exe probes --json [ 2026-11-09T15:04:18.767 ] [proc] [info]命令：C ":\Program Files\SEGGER\JLink_V980\JLinkGDBServerCL.exe" -listprobes USB [ 2026-11-09T15:04:20.075 ] [proc] [info]命令：C ":\Program Files\SEGGER\JLink_V980\JLinkGDBServerCL.exe" -listprobes USB [ 2026-11-09T15:04:20.083 ] [proc] [ info ]命令：C : \NXP\LinkServer_26.9.130 \LinkServer.exe probes --json [ 2026-11-09T15:04:21.857 ] [proc] [info]命令：C:\NXP\LinkServer_26.9.130 \LinkServer.exe flash --probe WXZBCIEABA3EA --no-启动 KW45B41Z83xxxA:KW45B41Z-LOC load C:\Users\Hondaconceptbench \ Documents\MCUXpresso_VSC\SDK_26_09_00_KW45B41Z-LOC\mcuxsdk\examples\demo_apps\hello_world\debug\hello_world.elf --erase-all [ 2026-11-09T15:04:25.241 ] [proc] [info] INFO : 找到与 KW45B41Z83xxxA:KW45B41Z-LOC 完全匹配的项 信息：已选择设备 KW45B41Z83xxxA:KW45B41Z-LOC 信息：已选择探针 # 1 WXZBCIEABA3EA（板载 MCU-LINK (r0E3) CMSIS-DAP V3.174 ） 信息：MCU-Link 固件更新“检查”：探针 ([WXZBCIEABA3EA] [MCU-LINK 板上 (r0E3) CMSIS-DAP V3.174]) 已运行与包含的固件版本 [3.174]相同的固件版本 [ 2026-11-09T15:04:25.241 ] [LinkServer] [信息] LinkServer 闪存操作成功完成： 固件更新检查：无需检查 - 可以使用以下命令强制更新：`LinkServer probe # 1 update forced` Ns: LinkServer RedlinkMulti 驱动程序v26.9 ( 2026 年9 月18 日19:34:33 - crt_emu_cm_redlink.exe版本1382 ) PC：（ 0 ）读取远程配置 Wc( 03 )。不支持缓存。 Nc：在 C:\Users\HONDAC~ 1 \AppData\Local\Temp\tmp62t_evtb\crt_directory.xml中找到通用目录 XML 文件 PC：（ 5 ）远程配置完成 Nc：已重新连接到现有 LinkServer 进程。 Wc: ============= 脚本: KW45B41_connect.scp ============= Wc：KW45B41 连接脚本 Wc：正在连接到探针索引 = 1 Wc：DpID = 6BA02477 Wc：APID = 0x84770001 Wc: ============= 脚本结束 ================================ Nc：探针固件：板载 MCU-LINK (r0E3) CMSIS-DAP V3.174 (NXP 半导体) Nc：序列号：WXZBCIEABA3EA Nc: VID:PID: 1FC9:0143 Nc：USB路径： 0001:0016:00 Nc：在搜索到可用核心后，使用核心0的内存 电脑：（ 30 ）模拟器已连接 Nc：处理器处于安全模式 PC：（ 40 ）调试停止 PC：（ 50 ）CPU ID Nc：调试接口类型 = CoreSight DP（DAP DP ID 6BA02477）通过 SWD TAP 0 Nc：处理器类型 = Cortex-M33（CPU ID 00000D21），位于 DAP AP 0上 Nc：硬件断点数 = 8 Nc：闪光灯片数量 = 0 Nc：硬件监视点数量 = 4 Nc：探针（ 0）😞 已连接&重置。DpID：6BA02477。CPU ID：00000D21。信息 ： Nc：调试协议：SWD。RTCK：已禁用。向量捕获：已禁用。 Ns：CoreSight调试ROM的内容： Nc: RBASE E00FF000: CID B105100D PID 04000BB4C9 ROM (类型0x1 ) Nc: ROM 1 E000E000: CID B105900D PID 04000BBD21 CSt ARM ARMv8-M 类型0x0其他 - 未定义 Nc：ROM 1 E0001000：CID B105900D PID 04000BBD21 CSt ARM DWTv2 类型0x0其他 - 未定义 Nc：ROM 1 E0002000：CID B105900D PID 04000BBD21 CSt ARM FPBv2 类型0x0其他 - 未定义 Nc：ROM 1 E0000000：CID B105900D PID 04000BBD21 CSt ARM ITMv2 类型0x43跟踪源 - 总线 Nc：ROM1E0042000：CID B105900D PID04000BBD21CSt Arm CTIv2 类型0x14 调试控制 - 触发信号，例如ECT Nc：NXP：KW45B41Z83xxxA Nc：DAP 步长为1024字节（ 256字） Nc：已检查v.2片上闪存KW45B41.cfx Nc：图片“FMU 2026 年 9 月 18 日 19:14:27” Nc：打开闪存驱动程序KW45B41.cfx Nc：请求 VECTRESET，但 ARMv8-M CPU 不支持此功能。改用 SOFTRESET 方式。 Nc：使用软复位运行闪存驱动程序 Nc：检测到闪存变体“FMU 1MB” （1MB = 128 * 8K，地址为0x0 ） Nc：正在关闭闪存驱动程序KW45B41.cfx Nc：已检查v.2片上闪存KW45B41_S.cfx Nc：图像“FMU（安全）2026年9月18日 19:14:02” Nc：打开闪存驱动程序KW45B41_S.cfx Nc：请求 VECTRESET，但 ARMv8-M CPU 不支持此功能。改用 SOFTRESET 方式。 Nc：使用软复位运行闪存驱动程序 Nc：检测到闪存变体“FMU 1MB（安全）” （1MB = 128 * 8K，地址为0x10000000 ） Nc：正在关闭闪存驱动程序KW45B41_S.cfx PC：（ 65 ）芯片设置完成 PC：（ 70 ）许可证检查完成 Nt：正在加载“hello_world.elf” ELF 0x00000000长度0x37F4 Nc：打开闪存驱动程序KW45B41.cfx Nc：请求 VECTRESET，但 ARMv8-M CPU 不支持此功能。改用 SOFTRESET 方式。 Nc：使用软复位运行闪存驱动程序 Nc：检测到闪存变体“FMU 1MB” （1MB = 128 * 8K，地址为0x0 ） 铅：（ 0 ）大规模擦除闪光 Pb： 1/1 ( 0 )正在写入地址0x00000000的扇区0-1 ，共14324字节 PS： ( 0 )位于00000000 ： 0字节-0/14324 PS：（ 100 ）位于00000000 ： 16384字节 - 16384 / 14324 Nc: 00004000完成100 % ( 14324中已完成16384 ) Nc：已写入扇区： 2 ，未更改扇区： 0 ，总计： 2 Nc：正在关闭闪存驱动程序KW45B41.cfx Pb: ( 100 ) Flash 编写成功。 Nt：已加载0x37F4字节，耗时 380 毫秒（约 37kB/秒） Nt：RESET目标（系统） Nc：使用系统RESET和停滞地址启动执行 Nc：将读取监视点1 （地址0xE000ED08）重新分配给启动 ROM 停滞。 Nc：状态 - 正在运行或正在执行 RESET 请求 - 状态重读失败 - rc Nn(05)。DAP 访问中的线路 ACK 故障 Nc：关闭调试会话时出错 - Nn( 05 )。DAP 访问中的线路 ACK 故障 结论与请求： 我们投入了大量时间来排查 KW45B41Z-LOC 板的问题，但不幸的是，由于硬件问题尚未解决，我们的项目活动现在被延误了。 此外，我们的项目需求涉及到达角 (AoA) 和航道测深 (CS)，而 KW45 LOC 并不完全支持这两项功能。尽管存在这些限制，我们仍在继续评估该板。然而，我们目前仍停留在非常基础的阶段，无法达到预期效果。 考虑到已耗费的时间以及对项目进度的影响，我们希望恩智浦半导体能够提供一块搭载最新硬件版本的BLE开发板作为替代品。这将使我们能够尽快恢复开发工作，避免进一步延误。 我们愿意将现有的KW45B41Z-LOC板寄回恩智浦进行进一步的检查和故障分析。 我们恳请您尽快回复并支持我们解决此事，以便我们能够使项目活动重回正轨。 顺祝商祺！ Re: KW45B41Z-LOC: SWD fails once application runs; can flash only via ISP/SW4; app no longer runs or @priyanshua1 ，你好！ KW45-LOC 被用作实验和原型设计的参考设计，因为 KW45 不包含支持完整蓝牙通道探测规范所需的所有功能。此外，正如 NXP产品页面上所指出的，KW45-LOC 已不再生产。 作为替代方案，您可以考虑KW47-LOC ，它旨在演示汽车和物联网应用中的蓝牙通道探测功能。该设计包含两个板载单极子PCB天线和一个射频开关，以支持天线分集。 这是因为KW47处理器支持通道探测。与 KW45 相比，它还提供了多项增强功能，包括更大的内存容量、运行频率高达 64 MHz 的专用的 Arm Cortex-M33 无线电内核以及对蓝牙 LE 6.x 的支持。 如果您有兴趣，还可以参考AN14796 ，了解有关 KW45 和 KW47 之间的功能差异和迁移考虑的更多信息。 BR 哈比卜

ROM API経由で.SBファイルをストリーミング再生する 私はUSBブートローダーを作成しています。目標は、SB21ファイルをUSB経由で512バイトずつのチャンクに分割してストリーミングし、それをブートローダーAPIに送信することです。しかし、SBファイルをストリーミングすると、ERASEセクションしか機能せず、loadセクションのデータは実際にはフラッシュにロードされません。SBファイルが良いのは、同じSBファイルをblhost経由でブートローダーに直接送って動作するからです。このフォーラム投稿には、ブートROMにデータをストリーミングするC言語のソースコードが添付されています。この問題を解決するのに役立つような、何か誤った情報はありませんか？ 私のブートローダーコードは、NXPのkb_init、kb_deinit、kb_execute APIを使用してSBファイルをストリーミングします。 私のsb21設定yamlファイル： # 説明: Secure Binary v2.1 セクションブロック セクション：   # --------------------------------------===== SB2.1 コマンド [オプション] =====---------------------------------------   # 説明: Secure Binary v2.1 コマンドブロック、すべての可能なオプションのリスト - 必要に応じて変更してください   # 応用 -コマンド:       # アプリケーションスペースを消去。永続的なデータ用に下部の部分を予約してください -消去:           アドレス: 0x10000           長さ： 0x6BC00           mem_opt : 0           フラグ: 0       # 署名付きアプリケーションのMBIをフラッシュに読み込む -負荷：           アドレス: 0x10000           load_opt : 0           # ファイルパスは、生成されたデバイス固有の MBI に置き換えられます。           ファイル: C:\code\Application_SECURE_MBI.bin メモ： 1.blhostを使用して全く同じSB21ファイルをブートROMに送信することができ、すべて正常に動作します。SO SBIが良いと知っています 2. ブートローダーを使用して SB21 ファイルをストリーミングすると、セクション消去コマンドは実行されますが、MBI ファイルのセクションのロードが失敗するようです。しかし、kb_execute や init/deinit 呼び出しからはエラーコードがまったく返されません。皆、成功を口にする。 3. 最終的なSB21ファイルは合計155,568バイトです。ブートローダーにすべてのバイトをストリーミングすることができ、結果としてすべてのステータス_tが0x00になります。 4. CMPAはSECURE_BOOT無効化、SWDアクセスは有効、CMPAは封印されていません。CFPAもすべての機能を有効化し、公開している。ISPが有効になっています LPC55xx 回复： Streaming .SB file via ROM API こんにちは、 @guitardenver 同じSB2.1ファイルがblhostで正しく動作することから、SBファイル自体は有効であるはずです。 アプリケーションの以下のポイントをご確認いただけますか? LPC55xxユーザーマニュアルによると、ROM認証機能は以下のRAM領域を使用します。 0x30000000–0x30003FFF 0x14005000–0x140059FF リンカーマップを確認し、ワークスペース、USBバッファ、スタック、その他のアプリケーションデータがこれらの領域と重複していないか確認してください。 kb_init/kb_process/kb_deinitが間接的にskboot_authenticate()を呼び出す場合、アプリケーションのHASH割り込みベクトルはHASH_IRQHandler()を呼び出さなければなりません。また、この割り込み転送が正しく設定されていることを確認してください。 ROM APIの要件に基づくと、まず最初に確認すべき2つの領域はこれらです。   BR ハリー

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 Re: P3B1602 I2C/I3C PCIe CEM Spec Compliant こんにちは、モリッツさん よりよく理解するために接続図を教えていただけますか?BR Re: P3B1602 I2C/I3C PCIe CEM Spec Compliant こんにちは、モリッツさん よりよく理解するために接続図を教えていただけますか?BR Re: P3B1602 I2C/I3C PCIe CEM Spec Compliant こんにちは、郭さん  私の計画はこうです。 敬具 モーリッツ Re: P3B1602 I2C/I3C PCIe CEM Spec Compliant こんにちは、モーリッツさん 1.8Vまたは3.3VのチャネルはOEを通じて選択可能です。しかし、OEは単なるソフトウェア信号選択ではありません。相互排他性、デフォルトオフ状態、スイッチングデッドゾーンを確保しなければなりません。 Re: P3B1602 I2C/I3C PCIe CEM Spec Compliant こんにちは、郭さん。 FPGAで対応できると思います。 要約すると、相互排他性が確保され、有効化の間に遅延が設けられていれば、問題はないということですね？ 分かりやすくするために、プルダウン抵抗は省略しました。 敬具 モーリッツ Re: P3B1602 I2C/I3C PCIe CEM Spec Compliant こんにちは、モーリッツさん これらのB側ピンに外部プルアップ抵抗がない場合は、問題ないはずです。

i.MX 95は同時4K60のデコード/エンコードをサポートしていますか? こんにちは、 i.MX 95は同時4K60のデコード/エンコードをサポートしていますか?もしなければ、NXPにはサポートできる他のプロセッサはありますか? ありがとうございます ファン 評価ボード Re: Does i.MX 95 support simultaneous 4K60 decode/encode? こんにちは、 @fan99さん 4K60のデコードとエンコードの同時実行はサポートされていません。iMX95 VPUはサポート エンコード側とデコーダー側で最大4K60fpsを共有可能。 よろしくお願いします、 志明

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

Streaming .SB file via ROM API I am making a USB bootloader. The goal is to stream a SB21 file via USB in 512Byte chunks and stream them to the Bootloader API. But when I stream the SB file, only the ERASE section works, no data in the load section actually gets loaded into flash. I know the SB file is good because I can send the same SB file via blhost directly to the bootloader and it works. Attached to this forum post is my C source code that streams the data to the boot ROM. Is there anything incorrect that might help solve this issue? My bootloader code uses the NXP kb_init, kb_deinit and kb_execute API to stream a SB file.  My sb21 config yaml: # Description: Secure Binary v2.1 section blocks sections:   # --------------------------------------===== SB2.1 Commands [Optional] =====---------------------------------------   # Description: Secure Binary v2.1 commands block, list of all possible options - Modify it according to your   # application   - commands:       # Erase Application space. Keep bottom reserved area for persistent data       - erase:           address: 0x10000           length: 0x6BC00           mem_opt: 0           flags: 0       # Load the signed application MBI to flash       - load:           address: 0x10000           load_opt: 0           # File path is replaced with the generated device-specific MBI.           file: C:\code\Application_SECURE_MBI.bin Notes: 1. I am able to use blhost to send the same exact SB21 file to the Boot ROM and everything works. So I know the SBI is good 2. When I use my bootloader to stream the SB21 file, it does the erase section command, but the load section of the MBI file seems to fail, but I get no error code at all from kb_execute or the init/deinit calls. They all say success.  3. the final SB21 file is 155,568 Bytes total. I am able to stream every byte to the bootloader, all with status_t = 0x00 as a result.  4. My CMPA has SECURE_BOOT disabled, SWD access is enabled, CMPA is not sealed. CFPA also have everything enabled and open.  ISP is enabled LPC55xx 回复： Streaming .SB file via ROM API Hi @guitardenver  Since the same SB2.1 file works correctly with blhost, the SB file itself should be valid. Could you please check the following points in your application? According to the LPC55xx User Manual, the ROM authentication functions use the following RAM regions: 0x30000000–0x30003FFF 0x14005000–0x140059FF Please check your linker map and make sure your workspace, USB buffer, stack, or other application data does not overlap these regions. When kb_init/kb_process/kb_deinit indirectly invoke skboot_authenticate(), the application HASH interrupt vector must call HASH_IRQHandler(). Please also confirm that this interrupt forwarding is correctly configured. These would be the first two areas I recommend checking based on the ROM API requirements.   BR Harry

MPC8308CVMAFD Vs MPC8308CVMAFDA Hi, We would like to seek your technical expertise regarding the following part numbers: MPC8308CVMAFD MPC8308CVMAFDA Could you please clarify whether there are any differences between these two part numbers? According to the datasheet, the additional letter “A” indicates a revision level. However, we could not find any further information explaining the specific revision or its impact on the device. We would appreciate your confirmation on whether these two part numbers are electrically and functionally equivalent and interchangeable. Thank you very much for your assistance. Re: MPC8308CVMAFD Vs MPC8308CVMAFDA ### 1. Difference Between the Two Part Numbers The only difference between **MPC8308CVMAFD** and **MPC8308CVMAFDA** is the **internal silicon stepping / revision**: * **`MPC8308CVMAFD`**: Represents **Silicon Revision 1.0**. * **System Version Register (SVR):** `0x8101_0110` * **`MPC8308CVMAFDA`**: Represents **Silicon Revision 1.1** (the trailing letter **“A”** designates Rev 1.1 in Freescale/NXP’s part numbering scheme). * **System Version Register (SVR):** `0x8101_0111` Both devices share identical nominal parameters: * **Package:** 473-pin MAPBGA (19 mm × 19 mm, 0.8 mm pitch) * **Temperature Grade:** Extended / Industrial (`C` = -40°C to 105°C $T_j$) * **Core Frequency:** 333 MHz (`AF`) * **DDR Data Rate:** 266–333 MHz (`D`) * **Lead-free / RoHS:** Pb-free MAPBGA (`VM`) --- ### 2. Hardware Equivalence (Form, Fit, Function) * **Electrically & Mechanically:** **100% Pin-to-Pin and Drop-in Equivalent.** * No PCB layout, schematic, routing, power supply, or decoupling changes are required. * Ball assignments, voltage rails ($V_{DD} = 1.0\text{V}$, $G_{VDD} = 1.8\text{V}$, $N_{VDD} = 3.3\text{V}$), I/O drive strengths, and AC/DC timing specifications are identical. --- ### 3. Silicon Differences & Software Impact Silicon Revision 1.1 (`MPC8308CVMAFDA`) was released to incorporate minor internal bug/errata fixes over Revision 1.0. For 99% of applications, **Rev 1.1 is fully backward-compatible with Rev 1.0**. However, keep the following two software considerations in mind: 1. **System Version Register (SVR) Checks:** * If your bootloader (U-Boot), kernel, or proprietary firmware explicitly reads and matches the exact 32-bit SVR value: * Rev 1.0 returns `0x8101_0110` * Rev 1.1 returns `0x8101_0111` * Ensure any hardware revision checks in your code mask out or accept the lower 4 bits (e.g., matching against `0x8101_011x` or checking $\ge \text{Rev } 1.0$) so the boot sequence does not halt. 2. **Silicon Errata Workarounds:** * Several known errata present in Rev 1.0 were resolved or improved in Rev 1.1 (documented in the *MPC8308 Chip Errata*, document `MPC8308CE`). * Software workarounds implemented in firmware for Rev 1.0 will continue to operate harmlessly on Rev 1.1. --- ### Summary Recommendation **MPC8308CVMAFDA is the direct, recommended replacement for MPC8308CVMAFD.** They are form, fit, and functional drop-in replacements. You can safely substitute `MPC8308CVMAFDA` without board redesign, provided your firmware does not hardcode an exact match check on the SVR register.