S32K344 OTA 活动区 1. S32K3_HSE_DemoExamples_1_0_0\S32K3_HSE_DemoExamples\Template\S32K344_DemoAppTemplate\drivers\dcm_register\hse_dcm_register.c xionggang_0-1787021979735.png雄钢_0-1787021979735.png 2. AN13465_S32K3xx 安全启动.pdf xionggang_1-1787021998225.pngxionggang_1-1787021998225.png 文档和代码中对“活动区域”的描述不一致。谁的说法正确？ Re: S32K344 OTA Active Region HI Dcm_ActiveAddressOTAREgion () 似乎已经将DCMOTAR =0/1 到低/高值的映射反转了。 我们之前讨论过DCMSTAT [ DCMOTAR ]： https://community.nxp.com/t5/S32K/s32k312/td-p/1697583 此致敬礼， Robin

S32K3 MBDT SENTの実装について？ S32K3上のSENTプロトコルのモデルベースの実装作成は進展していますか? この投稿(解決済み:S32K3 MBDTにおけるSENTプロトコルサポートに関するもの - NXPコミュニティ)を見ましたが、数年前のものです。それ以降、何か進展はありましたか？

S32K3 MBDT SENT implementation? Has there been any progress on creating a model based implementation for the SENT protocol on the S32K3? I saw this post (Solved: Re: SENT Protocol Support in S32K3 MBDT - NXP Community) but it is a few years old. Has anything been developed since then?

S32K3 MBDT SENT 实现？ 在 S32K3 上为 SENT 协议创建基于模型的实现方面，是否有任何进展？ 我看到了这篇帖子（已解决：回复：S32K3 MBDT 中的 SENT 协议支持 - NXP 社区），但它已经是几年前的帖子了。此后是否有任何进展？

RIOP RT1189 – GitHubソースからのビルドおよびフラッシュワークフロー こんにちは、 現在はNXP RIOP評価ボードと連携しており、Getting Startedガイドを無事に完了し、事前プログラムされたFreeMASTERデモもテストしました。 次のステップは、デモをソースコードから再構築し、ボードに書き込んで、ビルドと書き込みのパイプライン全体が正しく動作することを確認することです。 以下のドキュメントと情報源を確認しました: はじめ:GS-REMOTE-IOプラットフォーム RIOPユーザーガイド:UG10224 GitHubリポジトリ: nxp-appcodehub/rd-riop-demo GitHubリポジトリには2つのプロジェクトが含まれています。 riop_M33LEADER_DEMO riop_M7FOLLOWER_DEMO 必要なSDKおよびツールのバージョン、MIMXRT1189 SDK 25.09.00を含むことを規定しています。 私にとってまだ完全には理解できていないのは、これら2つのプロジェクトから、基板に搭載されているものと同じ起動可能なファームウェア構成にどうやって到達するかということです。 質問: M33およびM7プロジェクトを構築する際の推奨される方法は？MCUXpressoで両方のプロジェクトを個別にインポートしてビルドすればよいのでしょうか、それともビルド順序や依存関係が必要なのでしょうか？VS Code拡張機能も使えますか? 生成されたM33およびM7の画像は、どのようにRIOPにプログラムされるのですか？Secure Provisioning Toolは、アプリケーション全体を作成・フラッシュするための意図された方法なのでしょうか? 2つのイメージがどのように結合されるか（正しいメモリレイアウトとフラッシュアドレスを含む）を示す、既存のセキュアプロビジョニングツールの構成例またはサンプルはありますか？ RIOPデモの画像認証はどのように扱われていますか?工場出荷時の設定でセキュアブート／署名検証は有効になっていますか？また、デモ版を自作してフラッシュする際に、キーのプロビジョニングは必要ですか？ rd-riop-demoを上書きする前に、現在ボードにプログラムされているrd-riop-demoのバージョンを特定する方法はありますか？ 例コードから見ると、RT1189 Boot ROMがM33アプリケーションを起動し、M33がMCMGRを使って0x303C0000でM7を起動するようです。これは工場出荷時イメージの完全なブートフローですか、それともGitHubリポジトリに含まれていない追加のブートステージがありますか？ 必要ならボードを元のすぐに使える状態に戻せるよう、元の工場出荷イメージはどこかに入手できますか? コマンドライン／ヘッドレスビルドのワークフローも利用可能ですか？長期的には、ビルドを再現可能にし、CI（継続的インテグレーション）に適したものにしたいと考えています。 Getting Startedガイドはすぐに使えるのデモをよく説明しており、GitHubリポジトリにもソースがありますが、今のところ両者のつながりが分かりません。 GitHubソース → M33/M7をビルド → ブート可能なイメージを作成 → フラッシュ → 同じデモを実行 UG10224か他の文書の該当箇所を見落としたのかもしれません。 ご回答をお待ちしています。 Re: RIOP RT1189 – build and flash workflow from GitHub sources こんにちは、シェリーさん。 詳細なご回答をありがとうございました！ よろしくお願いいたします。 Marco Re: RIOP RT1189 – build and flash workflow from GitHub sources @Embernard様、 ご質問への回答は以下のとおりです。 1.RIOPデモはMCUXpresso IDEとVS Code + MCUXpresso for VS Codeの両方をサポートしています。VS Codeのご利用をお勧めします。riop_M7FOLLOWER_DEMOとriop_M33LEADER_DEMOプロジェクトをインポートした後、まずM7フォロワープロジェクトをビルドし、次にM33リーダープロジェクトをビルドすることをお勧めします。これは、M33プロジェクトがriop_M7FOLLOWER_DEMO.axf.oを参照しているためです。M7プロジェクトによってマルチコアスレーブイメージとして生成されたファイル。 2. Secure Provisioning Tool (SPT) を使用してフラッシュメモリに書き込む必要があるのは、riop_M33LEADER_DEMO.axf ファイルのみです。UG10224のセクション4.1.5を参照してください。「デモアプリケーションの実行中」。最新版のSPT v26.06をダウンロードして使用することをお勧めします。一部の設定設定はユーザーガイドに示されているものとは若干異なることに注意してください。 ShellyZhang_0-1787196235459.pngShellyZhang_0-1787196235459.png 3. 独自のRIOP SPTワークスペースを作成するには、UG10224を参照してください。SPT側では、主な役割はブート可能なRT1189アプリケーションイメージを生成し、デバイスにプログラムすることです。 4. 開発中は、機能検証のために署名なし/オープン構成を使用することを推奨し、eFuseやキーのプログラミングは推奨しません。 プログラミングヒューズは不可逆的な操作であり、シャドウレジスタなど適切な検証後の本番セキュリティプロセスの一部としてのみ実施されるべきです。セキュアブート、イメージ署名、暗号化を有効にするかどうかは、最終的には本番環境のセキュリティ要件とSPT設定によって決定されるべきです。 5. 現在のファームウェアがFreeMASTER変数、UART出力、またはバージョン文字列を通じてバージョン情報を公開しない場合、ボード上で現在実行されているrd-riop-demoのバージョンを確実に判別することはできません。フラッシュメモリの内容を上書きする前にバックアップを取るか、カスタムファームウェアにバージョン情報を追加することをお勧めします。 6.現在のプロジェクトで実装されている起動モデルは、RT1189がまずCM33(M33リーダー)を起動し、その後M33がマルチコア/MCMGRフレームワークを通じてM7フォロワーを起動するというものです。追加の起動段階は不要です。 7. 復元が必要な場合、最も信頼できる方法は、既存のフラッシュイメージを読み返して保存し、再プログラムすることです。バックアップが利用できない場合は、rd-riop-demoを再構築して再プログラムするしか選択肢はありません。これにより、システムは機能的に同等の状態に復元されます。 8. コマンドラインワークフローがサポートされています。SPTは内部的にOpenSSLやSPSDKなどのコマンドラインツールを呼び出し、鍵の生成やイメージのビルド/書き込みを行います。詳細については、以下のドキュメントをご参照ください。 セキュアプロビジョニングツール - コマンドライン操作 2つの画像がどのように関連付けられているかについては、主要な流れは以下のとおりです。 1.デモは、リンクされた2つのマルチコアプロジェクトとして構成されています。 RIOPデモリポジトリには、2つのプロジェクトディレクトリが含まれています。 riop_M33LEADER_DEMO/ riop_M7FOLLOWER_DEMO/ 。 MCUXpressoのマルチコアプロジェクトモデルでは、プライマリ/リーダープロジェクトがセカンダリー/フォロワープロジェクトにリンクします。プライマリプロジェクトが構築されると、まずセカンダリプロジェクトが構築され、セカンダリ出力イメージがプライマリイメージに組み込まれる／埋め込まれる。 2. M33プロジェクトはマルチコアマスターとして構成され、M7プロジェクトはスレーブとして構成されます。 riop_M33LEADER_DEMO/.cproject では、プロジェクトは __MULTICORE_MASTER と __MULTICORE_MASTER_SLAVE_M7SLAVE を定義しています。そのマルチコアマスター構成は以下を指し示しています。 ${workspace_loc:/riop_M7FOLLOWER_DEMO/Debug/riop_M7FOLLOWER_DEMO.axf.o} 。 これは、まず riop_M7FOLLOWER_DEMO.axf が .axf.o に処理され、そのオブジェクトが「スレーブオブジェクト」として M33 リーダーイメージにリンクされることを意味します。 M7プロジェクトは、CM7 ITCM/DTCMメモリ領域を使用して、M7SLAVE / __MULTICORE_M7SLAVEとして構成されます。 3.実際のマージは主にリンク/ビルド後の段階で行われます。 MCUXpressoのマルチコアフローは、セカンダリコアイメージを処理し、セカンダリコアセクションをシフトしてから、それらを完全なマルチコアイメージにリンクします。 したがって、最終的なriop_M33LEADER_DEMO.axfは、M33リーダーELFにM7フォロワーの画像データ/セクションが埋め込まれたものであり、2つの独立したAXFファイルを単純にバイナリで連結したものではありません。 4.実行時に、M33はM7を開始します。 riop_M33LEADER.c 内M7ブートアドレスは次のように定義されます。 CORE1_BOOT_ADDRESS = 0x303C0000、CORE1_KICKOFF_ADDRESS = 0x0。 SystemInitHook() では、Prepare_CM7(CORE1_KICKOFF_ADDRESS) が呼び出され、その後 main() で MCMGR_StartCore(kMCMGR_Core1, CORE1_BOOT_ADDRESS, ...) が呼び出されてセカンダリ コアが起動します。 したがって、M7イメージはM33リーダーAXFに埋め込まれていますが、M7の実行は実行時にM33によって明示的に起動されます。 5. 起動可能なイメージは依然としてSPTプロセッシングが必要です RT1180については、ドキュメントによるとデバイスはCM33からのみ起動できると記載されています。Secure Provisioning Toolは、生アプリケーションイメージからブートヘッダー付きのブート可能なイメージを生成するために使用されます。MCUXpressoの出力タイプには.axfが含まれます。 通常の流れは次の通りです: riop_M7FOLLOWER_DEMO.axf→riop_M7FOLLOWER_DEMO.axf.oに処理されます→ riop_M33LEADER_DEMO.axf にリンクされます → SPT は M33 リーダー AXF を使用してブート可能なフラッシュ イメージを生成します。 よろしくお願いいたします。 シェリー

R45 MIPICSI2 BUFFOVF 错误 亲爱的， 我们使用 R45 MIPI 从其他芯片 MIPI 接收数据，但现在 R45 在接收数据一段时间后会报告缓冲区错误。MIPI 发送速率为 600M，R45 接收速率也为 600M。 R45 参考手册对 buffovf 错误描述如下：   evalin_1-1729739919559.pngevalin_1-1729739919559.png R45 CSI2 在什么情况下会报告此错误？谢谢。 Re: R45 MIPICSI2 BUFFOVF ERR 嗨，Peter @petervlna 现在我们团队使用的是 NXP S32R45 S32R45 ，我们也遇到了同样的错误。我们将 ADC 数据传输到 R45 CSI2 接口（发送方是另一个芯片）。有时，0x80000错误代码会持续存在。ADC 数据从 MIPI 传输到 SRAM，然后保存到 DDR 内存。ADC 数据捕获始终在后台运行（12ms 捕获 2MB 数据），同时 SPT 处理也在前台进行，中间数据保存到 您有什么建议吗？ 谢谢您！ Re: R45 MIPICSI2 BUFFOVF ERR 你好， 当内部缓冲已满时，需手动输入。 请务必在数据满溢之前清空/转移数据。 可能是您的DMA或核心触发信号的数据传输速度太慢。 顺祝商祺！ Peter

QorIQ T1022 DDR Validation Suite Passes with Good Margin, but Memory Corruption Seen in Application Hello, We are working with a QorIQ T1022 design and have completed DDR bring-up and validation using the NXP DDR Validation Suite. The results are encouraging: All DDR validation tests pass successfully. We have achieved good timing margins across the tested conditions. No errors are reported by the validation suite during stress testing. However, when we load and run our main application, we begin to observe what appear to be memory-related issues/corruption. These issues are not reproducible using the DDR validation tests alone. This has raised the question of whether there are additional mechanisms or test methodologies we should be using to detect issues that may only appear under real application workloads. We are interested in understanding: What types of DDR or memory subsystem issues can escape the standard DDR Validation Suite tests on the T1022? Are there known application-level scenarios that can expose problems not detected during DDR training and validation? Are there additional stress tests, performance monitors, error counters, or debugging techniques available on the T1022 that could help identify the root cause? Has anyone encountered a situation where DDR validation showed excellent margins, yet memory corruption or instability was later observed in a production application? Any guidance on additional diagnostics, hardware checks, or software debugging approaches would be greatly appreciated. Thank you. QorIQ T1 Devices Re: QorIQ T1022 DDR Validation Suite Passes with Good Margin, but Memory Corruption Seen in Applicat Hello, The QCVS DDRv tool tests DDR timing margins (write leveling, read/write centering, clock adjustment) using sequential, deterministic access patterns from a single core via JTAG. It does not exercise: Multi-master / multi-core concurrent access — The T1022 has two e5500 cores plus the DPAA (Data Path Acceleration Architecture) with frame managers, queue managers, and DMA engines all competing for the DDR bus simultaneously. Contention-induced timing violations only appear under real traffic. Cache coherency stress — Application workloads involving cache flushes, invalidations, and coherent DMA transfers create access patterns the validation suite never generates. Thermal and power-supply variation — DDR margins measured at room temperature under light load can degrade significantly when the SoC is at full utilization and the AVDD_DDR supply droops under load. DQ mapping errors — If the DQ_MAPn registers are incorrect, the controller may still pass validation (which uses known training patterns) but corrupt data under real application traffic. This is a documented T1022-specific issue. Marginal single-bit ECC errors — The validation suite may not accumulate enough transactions to trigger SBE threshold reporting, while a real application running for hours will accumulate them silently. DQ Mapping Misconfiguration The DQ_MAPn registers provide the mapping of DRAM DQ signals to the controller. If these are wrong, the controller cannot correctly interpret training patterns, and data corruption occurs under real workloads. NXP has confirmed this on T1022 designs: clearing all DQn_MAP registers (setting to 0 for 1:1 mapping) is a recommended diagnostic step. Memory Ordering / Pipeline Effects (PowerPC e5500) The e5500 core has well-documented memory ordering subtleties. Writes may not be fully committed to DDR before subsequent reads, especially without explicit msync/isync barriers. NXP's apps team has confirmed: "The write may not be fully committed to memory before the error injection is disabled. The subsequent read may hit a cache or pipeline, not triggering the ECC logic immediately."In application code, missing barriers around DMA setup or shared-memory structures can cause apparent corruption that is actually a coherency ordering issue. ECC Single-Bit Error Accumulation The T1022 DDR controller supports ECC. Single-bit errors (SBEs) are silently corrected by the hardware but counted in ERR_SBE[SBEC]. If the SBE counter crosses the threshold ERR_SBE[SBET], a critical interrupt is generated. Under light validation traffic, this threshold is never reached. Under a real application, accumulated SBEs can eventually become uncorrectable multi-bit errors (MBEs), which are fatal — data cannot be recovered. Multi-Bit ECC Errors Manifesting as Application Crashes NXP has documented cases on QorIQ platforms (P2020, T1042) where application crashes (e.g., a lwz instruction faulting on a valid-looking address) were traced to MBE events in DDR. The crash is not a software bug — it is the e5500 core receiving corrupted data from the DDR controller and raising an IVOR1 Machine Check Exception. Importantly, the MCSR register shows 0xA000 (uncorrectable L1 cache/tag error) even when the memory region is cache-inhibited, because the DDR controller asserts a corrupted-data signal that the core registers as an L1 error Cross-check your board design against: AN3940 — Hardware and Layout Design Considerations for DDR3 SDRAM Memory Interfaces AN5097 — Hardware and Layout Design Considerations for DDR4 SDRAM Memory Interfaces AN4039 — PowerQUICC and QorIQ DDR3 SDRAM Controller Register Setting Considerations Pay particular attention to: AVDD_DDR power supply noise and decoupling, DDR reset signal routing (HRESET_B to DRAM RESET), and termination resistor values. Regards

S32M276XX LVR（低电压复位）功能测试 您好，NXP技术员， 我想对 S32M276 IC 的 VDD_HV_A 引脚上的 LVR（低电压复位）功能进行硬件测试。S32M276 是一款 SoC IC，所有电源均由其内部产生，那么我如何在 PCBA 层面验证此功能呢？请您提出任何建议。 Ted_Qiao_0-1787054923749.pngTed_Qiao_0-1787054923749.png Re: S32M276XX LVR(low voltage reset) function test 嗨@Ted_Qiao ， LVR 默认启用，并生成 POR。芯片上电复位事件发生后，您可以通过读取低电压模式下的PORF和LVRx标志来确定是哪个电源域导致了该事件。 状态和控制（LVSC）寄存器。 你可以从外部限制 IC 的供电电压，尝试产生 低压检测 事件或 LVR POR，并检查 LVRAF 标志。 此致， 朱利安

QorIQ T1022 DDR検証スイートは良好なマージンで通過しますが、アプリケーション中にメモリ破損が確認されています こんにちは、 私たちは QorIQ T1022 設計を用いており、NXP DDR Validation Suiteを使ったDDRの起動と検証を完了しました。 結果は有望だ。 DDRの検証テストはすべて正常に合格しました。 試験したすべての条件下で、良好な時間的余裕を達成しました。 ストレステスト中に検証スイートからエラーは報告されませんでした。 しかし、メインアプリケーションを読み込んで実行すると、 メモリ関連の問題や破損が見られます。これらの問題は、DDR検証テストだけでは再現できません。 これにより、実際のアプリケーションワークロード下でのみ発生する可能性のある問題を検出するために、追加のメカニズムやテスト手法を使えばよいのではないかという疑問が生じています。 私たちは以下の点を理解することに関心があります。 T1022の標準的なDDR検証スイートテストで回避できるDDRやメモリサブシステムの問題にはどのようなものがありますか? DDRのトレーニングや検証で検出されなかった問題を暴露できる既知のアプリケーションレベルのシナリオはありますか? T1022には、根本原因を特定するのに役立つ追加のストレステスト、パフォーマンスモニター、エラーカウンター、デバッグ技術などがありますか? DDRの検証で優れたマージンが示されたにもかかわらず、後に本番環境でメモリ破損や不安定が観察された状況に遭遇した方はいらっしゃいますか? 追加の診断、ハードウェアチェック、ソフトウェアデバッグの方法についてのアドバイスをいただけると大変ありがたいです。 よろしくお願いします。 QorIQ T1デバイス Re: QorIQ T1022 DDR Validation Suite Passes with Good Margin, but Memory Corruption Seen in Applicat こんにちは、 QCVS DDRvツールは、シングルコアからJTAG経由で逐次的かつデターミニスティックなアクセスパターンを用いてDDRのタイミングマージン(書き込みレベリング、読み書き/書き込みセンタリング、クロック調整)をテストします。運動はしない： マルチマスター/マルチコア同時アクセス — T1022は2つのe5500コアとDPAA(データパスアクセラレーションアーキテクチャ)を持ち、フレームマネージャ、キューマネージャ、DMAエンジンが同時にDDRバスを巡って競合します。競合によって引き起こされるタイミング違反は、実際のトラフィック状況下でのみ発生します。 キャッシュコヒーレンシーストレス — キャッシュフラッシュ、無効化、整合性のあるDMA転送を含むアプリケーションワークロードは、検証スイートが生成しないアクセスパターンを作り出します。 熱および電源の変動 — 室温で軽負荷時に測定されたDDRマージンは、SoCがフル稼働中でAVDD_DDR電源が負荷下で低下すると著しく劣化することがあります。 DQマッピングエラー — DQ_MAPnレジスタが誤っている場合、コントローラは既知のトレーニングパターンを用いる検証には合格しますが、実際のアプリケーション トラフィック下ではデータを破損させる可能性があります。これはT1022固有の既知の問題です。 周辺のシングルビットECCエラー — 検証スイートが十分なトランザクションを蓄積せず、SBE閾値報告をトリガーできない場合もありますが、数時間稼働する実際のアプリケーションは静かに処理します。 DQマッピングの設定ミス DQ_MAPnレジスタはDRAMのDQ信号をコントローラにマッピングします。これらが誤ると、コントローラはトレーニングパターンを正しく解釈できず、実際のワークロード下でデータ破損が発生します。NXPはT1022設計でこれを確認しており、すべてのDQn_MAPレジスタをクリア(1:1マッピングのために0に設定)が推奨される診断ステップです。 メモリの順序付け/パイプライン効果(PowerPC e5500) e5500コアには、メモリの順序付けの細かい違いがよく記録されています。書き込みは、特に明示的なmsync/isyncバリアがない場合、後続の読み取りが行われる前にDDRに完全にコミットされない可能性があります。NXPのアプリケーションチームは、 「エラー注入が無効になる前に書き込みがメモリに完全にコミットされない可能性がある。その後の読み取りでキャッシュまたはパイプラインにヒットし、ECCロジックがすぐにトリガーされない可能性がある」と確認した。アプリケーションコード、DMA設定時の欠落障壁、共有メモリ構造などは、実際には一貫性の順序の問題である明らかな破損を引き起こすことがあります。 ECCシングルビットエラー蓄積 T1022 DDRコントローラーはECCをサポートしています。シングルビットエラー（SBE）はハードウェアによって暗黙的に訂正されますが、ERR_SBE[SBEC]にカウントされます。SBEカウンタがしきい値ERR_SBE[SBET]を超えると、重大な割り込みが発生します。検証トラフィックが少ない場合、このしきい値に達することはありません。実際の応用では、蓄積されたSBEが最終的に修正不能なマルチビットエラー(MBE)となり、致命的となり、データは復元できません。 アプリケーションのクラッシュとして現れるマルチビットECCエラー NXPはQorIQプラットフォーム(P2020、T1042)で、アプリケーションクラッシュ(例:有効なアドレスでのlwz命令のフォールト)がDDRのMBEイベント情報に起因したCASEを記録しています。クラッシュはソフトウェアのバグではなく、e5500コアがDDRコントローラから破損したデータを受け取り、IVOR1マシンチェック例外を発生させたためです。重要なのは、メモリ領域がキャッシュ禁止されている場合でも、MCSRレジスタは0xA000(修正不能なL1キャッシュ/タグエラー)を表示します。これはDDRコントローラがコアがL1エラーとして登録する破損データ信号を主張するためです ボード設計を以下の基準と比較してください: AN3940 — DDR3 SDRAMメモリインターフェースのハードウェアおよびレイアウトデザインの考慮事項 AN5097 — DDR4 SDRAMメモリインターフェースのハードウェアおよびレイアウトデザインの考慮事項 AN4039 — PowerQUICCおよびQorIQ DDR3 SDRAMコントローラレジスタ設定の考慮事項 特に注意すべき点は、AVDD_DDR電源のノイズとデカップリング、DDRリセット信号のルーティング（HRESET_BからDRAM RESETへ）、および終端抵抗の値です。 よろしくお願いします。

S32M276XX LVR(low voltage reset) function test Hi NXP technician, I want to make a hardware test about the LVR(Low voltage reset) function on VDD_HV_A pin of S32M276 IC. The S32M276 is SoC IC, all power are generated internally, So How could I verify this function on PCBA level? Kindly ask you for any suggestion. Ted_Qiao_0-1787054923749.pngTed_Qiao_0-1787054923749.png Re: S32M276XX LVR(low voltage reset) function test Hi @Ted_Qiao, LVR is enabled by default, and generates a POR. After a chip POR event, you can determine which power domain caused it by reading the PORF and LVRx flags in Low Voltage Status And Control (LVSC) register. You can externally limit the IC's voltage supply to try and generate a LVD event, or LVR POR, and check the LVRAF flag. Best regards, Julián

S32M276XX LVR（低電圧リセット）機能テスト NXPの技術者さん、こんにちは。 S32M276 ICのVDD_HV_AピンにおけるLVR（低電圧リセット）機能について、ハードウェアテストを実施したいと考えています。S32M276はSoC ICで、すべての電力は内部で発生しています。では、この機能をPCBAレベルでどうやって検証すればよいのでしょうか?何かご提案がありましたら、お気軽にお尋ねください。 Ted_Qiao_0-1787054923749.pngTed_Qiao_0-1787054923749.png Re: S32M276XX LVR(low voltage reset) function test こんにちは、 @Ted_Qiao さん。 LVRはデフォルトで有効になっており、PORを生成します。チップPORイベントの後、Low Voltageの PORF と LVRx フラグを読み取ることで、どの電力領域が原因かを特定できます ステータス&コントロール(LVSC)レジスタ。 ICの電圧供給を外部から制限してLVDイベント(LVR POR)を発生させ、LVRAFフラグを確認することができます。 よろしくお願いします、 ジュリアン

R45 MIPICSI2 バッファビューエラー 親愛なる、 私たちはR45 MIPIを使用して他のチップのMIPIからデータを受信していますが、現在、R45は一定時間データを受信した後、バッファエラーを報告するようになりました。MIPIの送信速度は600Mbps、R45の受信速度も600Mbpsです。 R45リファレンスマニュアルでは、バッフォーフ誤差を次のように説明しています。   evalin_1-1729739919559.pngevalin_1-1729739919559.png R45 CSI2はどのような状況でこのエラーを報告するのでしょうか？よろしくお願いします。 Re: R45 MIPICSI2 BUFFOVF ERR こんにちは、ピーターさん@petervlna 現在、私たちのチームはNXP S32R45を使用していますが、私たちも同じエラーに遭遇しました。ADCデータをR45 CSI2インターフェース(送信元は別のチップ)に送信しています。場合によっては、0x80000エラーコードが解消されないことがあります。(MIPIからSRAMへのADCデータ、そしてDDRメモリへの保存、ADCキャプチャは常に「バックグラウンド」(12msで2MBデータ)を実行、SPTプロセッシングはフォアグラウンドに、中間データは 何かご提案はございますか？ よろしくお願いします！ Re: R45 MIPICSI2 BUFFOVF ERR こんにちは、 内部バッファが満杯の場合、手動で表現します。 データがいっぱいになってオーバーフローが発生する前に、必ずデータを空にする／転送してください。 DMAまたはコアトリガーによるデータ転送速度が遅すぎるのかもしれません。 よろしくお願いいたします。 ピーター

QorIQ T1022 DDR 验证套件以良好优势通过，但在应用程序中发现内存损坏。 你好， 我们正在使用QorIQ T1022设计，并已使用 NXP DDR 验证套件完成了 DDR 启动和验证。 结果令人鼓舞： 所有DDR验证测试均成功通过。 我们在所有测试条件下都取得了良好的时间裕度。 压力测试期间，验证套件未报告任何错误。 然而，当我们加载并运行主应用程序时，我们开始观察到一些似乎与内存相关的问题/损坏。仅使用 DDR 验证测试无法重现这些问题。 这就引出了一个问题：我们是否应该使用其他机制或测试方法来检测可能仅在真实应用程序工作负载下才会出现的问题。 我们感兴趣的是了解： T1022 上的标准 DDR 验证套件测试可以检测出哪些类型的 DDR 或内存子系统问题？ 是否存在已知的应用层面的场景，可以暴露出在 DDR 训练和验证过程中未检测到的问题？ T1022 上是否有其他压力测试、性能监视器、错误计数器或调试技术可以帮助确定根本原因？ 有没有人遇到过这样的情况：DDR验证结果显示裕量极佳，但后来在生产应用中却出现了内存损坏或不稳定的情况？ 非常感谢您能提供任何关于其他诊断方法、硬件检查或软件调试方法的指导。 谢谢！ QorIQ T1 设备 Re: QorIQ T1022 DDR Validation Suite Passes with Good Margin, but Memory Corruption Seen in Applicat 你好， QCVS DDRv 工具通过 JTAG 从单个内核使用顺序、确定性访问模式来测试 DDR 时序裕量（写入均衡、读/写居中、时钟调整）。它不进行锻炼： 多主/多核并发访问 — T1022 具有两个 e5500 内核以及 DPAA（数据路径加速架构），帧管理器、队列管理器和 DMA 引擎同时争用 DDR 总线。只有在实际流量下才会出现由竞争引起的时序违规。 缓存一致性压力 — 涉及缓存刷新、失效和一致性 DMA 传输的应用程序工作负载会创建验证套件永远不会生成的访问模式。 散热和电源变化——在室温下轻负载下测量的 DDR 裕量，在 SoC 满负荷运行时，AVDD_DDR 电源在负载下下降时，可能会显著降低。 DQ 映射错误 — 如果 DQ_MAPn 寄存器不正确，控制器可能仍然会通过验证（使用已知的训练模式），但在实际应用流量下会损坏数据。这是T1022特有的一个已记录的问题。 边缘单比特 ECC 错误 — 验证套件可能不会累积足够的交易来触发 SBE 阈值报告，而运行数小时的实际应用程序会默默地累积这些错误。 DQ映射错误配置 DQ_MAPn 寄存器提供 动态随机存取存储器(DRAM) DQ 信号到控制器的映射。如果这些是错误的，控制器就无法正确解释训练模式，并且在实际工作负载下会发生数据损坏。NXP 已在 T1022 设计中证实了这一点：清除所有 DQn_MAP 寄存器（对于 1:1 映射设置为 0）是建议的诊断步骤。 内存排序/流水线效应（PowerPC e5500） e5500 核心的内存顺序细节有据可查。写入操作可能无法在后续读取操作之前完全提交到 DDR，尤其是在没有显式 msync/isync 屏障的情况下。恩智浦的应用团队已确认： “在错误注入被禁用之前，写入操作可能尚未完全提交到内存。随后的读取操作可能会命中缓存或流水线，而不会立即触发 ECC 逻辑。”应用程序代码中缺少 DMA 设置或共享内存结构周围的屏障，可能会导致表面上的损坏，而这实际上是一致性排序问题。 ECC单比特错误累积 T1022 DDR 控制器支持 ECC。单比特错误 (SBE) 由硬件默默纠正，但计入 ERR_SBE[SBEC]。如果 SBE 计数器超过阈值 ERR_SBE[SBET]，则会产生严重中断。在验证流量较小的情况下，永远不会达到此阈值。在实际应用中，累积的 SBE 最终可能会变成无法纠正的多位错误 (MBE)，这是致命的——数据无法恢复。 多位ECC错误表现为应用程序崩溃 NXP 已记录了 QorIQ 平台（P2020、T1042）上的案例，其中应用程序崩溃（例如，lwz 指令在看似有效的地址上发生故障）可追溯到 DDR 中的 MBE 事件。崩溃不是软件错误——而是 e5500 内核从 DDR 控制器接收到损坏的数据，并引发 IVOR1 机器检查异常。重要的是，即使内存区域被缓存抑制，MCSR 寄存器仍然显示 0xA000（不可纠正的 L1 缓存/标记错误），因为 DDR 控制器会发出一个损坏数据信号，该信号被内核识别为 L1 错误。 将您的电路板设计与以下内容进行交叉核对： AN3940 — DDR3 同步动态随机存取存储器(SDRAM) 内存接口的硬件和布局设计考虑因素 AN5097 — DDR4 同步动态随机存取存储器\\(SDRAM\\) 内存接口的硬件和布局设计考虑因素 AN4039 — PowerQUICC 和 QorIQ DDR3 SDRAM 控制器寄存器设置注意事项 请特别注意：AVDD_DDR 电源噪声和去耦、DDR 复位信号路由（HRESET_B 到 动态随机存取存储器(DRAM) RESET）以及终端电阻值。 此致

R45 MIPICSI2 BUFFOVF ERR Dear, We use R45 MIPI to receive data from other chip mipi, but now R45 will report a buffove error after receiving data for a period of time. The MIPI sending rate is 600M, and the R45 receiving rate is also 600M. The R45 Reference manual describes buffovf errors as follows:   evalin_1-1729739919559.pngevalin_1-1729739919559.png Under what circumstances will R45 CSI2 report this error?Thanks. Re: R45 MIPICSI2 BUFFOVF ERR Hi, Peter @petervlna      Now our team are using NXP S32R45 S32R45 , we encountered the same error too. We transmit ADC data to R45 CSI2 interface (sender is other chip). Sometimes the 0x80000 error code will persist.  ( ADC data from MIPI to SRAM, and then save to DDR memory, the ADC capture is always running "background"(2MB data in 12ms), also SPT processing is in foreground, intermediate data saved to Any suggestions? Thanks! Re: R45 MIPICSI2 BUFFOVF ERR Hello, As manual express in the case that internal buffer is full. Make sure you empty/transfer data before it is full and overflow happen. Maybe your DMA or core triggered data transfer is too slow. Best regards, Peter

RIOP RT1189 – build and flash workflow from GitHub sources Hi, I’m currently working with the NXP RIOP evaluation board and have successfully completed the Getting Started guide and tested the pre-programmed FreeMASTER demo. My next step is to rebuild the demo from source, flash it back to the board and verify that my complete build and flash pipeline works. I checked the following documentation and sources: Getting Started: GS-REMOTE-IO-PLATFORM RIOP User Guide: UG10224 GitHub repository: nxp-appcodehub/rd-riop-demo The GitHub repository contains the two projects riop_M33LEADER_DEMO riop_M7FOLLOWER_DEMO and specifies the required SDK and tool versions, including the MIMXRT1189 SDK 25.09.00. What is still not completely clear to me is how to get from these two projects to the same bootable firmware configuration that is delivered on the board. Questions: What is the recommended way to build the M33 and M7 projects? Do I simply import and build both projects separately in MCUXpresso, or is there a required build order or dependency between them? Can I also use the VS Code Extension? How are the resulting M33 and M7 images programmed to the RIOP? Is the Secure Provisioning Tool the intended way to create and flash the complete application? Is there an existing Secure Provisioning Tool configuration or example that shows how the two images are combined, including the correct memory layout and flash addresses? How is image authentication handled for the RIOP demo? Is secure boot/signature verification enabled in the factory configuration, and is any key provisioning required when flashing a self-built version of the demo? Is there a way to determine which version of rd-riop-demo is currently programmed on the board before overwriting it? From the example code, it looks like the RT1189 Boot ROM starts the M33 application and the M33 then starts the M7 at 0x303C0000 using MCMGR. Is this the complete boot flow of the factory image, or is there an additional boot stage that is not part of the GitHub repository? Is the original factory image available somewhere so that the board can be restored to its Out-of-Box state if necessary? Is there also a command-line/headless build workflow available? In the longer term I would like to make the build reproducible and suitable for CI. The Getting Started guide explains the Out-of-Box demo well, and the GitHub repository provides the sources, but I’m currently missing the connection between the two: GitHub sources -> build M33/M7 -> create bootable image -> flash -> run the same demo Maybe I overlooked the relevant section in UG10224 or another document. Thank you! Re: RIOP RT1189 – build and flash workflow from GitHub sources Hi Shelly, thank you very much for the detailed answer! Best Regards Marco Re: RIOP RT1189 – build and flash workflow from GitHub sources Dear @Embernard , Regarding your questions, please find the responses below:   1. The RIOP demo supports both MCUXpresso IDE and VS Code + MCUXpresso for VS Code. We recommend using VS Code. After importing the riop_M7FOLLOWER_DEMO and riop_M33LEADER_DEMO projects, it is recommended to build the M7 follower project first, followed by the M33 leader project. This is because the M33 project references the riop_M7FOLLOWER_DEMO.axf.o file generated by the M7 project as the multicore slave image. 2. Only the riop_M33LEADER_DEMO.axf file needs to be programmed into Flash using the Secure Provisioning Tool (SPT). Please refer to UG10224, Section 4.1.5 "Running the Demo Application". We recommend downloading and using the latest SPT v26.06. Please note that some configuration settings differ slightly from those shown in the user guide: ShellyZhang_0-1787196235459.pngShellyZhang_0-1787196235459.png 3. Please refer to UG10224 to create your own RIOP SPT workspace. On the SPT side, its main role is to generate a bootable RT1189 application image and program it into the device. 4. During development, we recommend using an unsigned/open configuration for functional validation and do not recommend programming eFuses or keys. Programming fuses is an irreversible operation and should only be performed as part of a production security process after proper validation, such as through shadow registers. Whether to enable secure boot, image signing, or encryption should ultimately be determined by your production security requirements and SPT configuration. 5. If the current firmware does not expose version information through FreeMASTER variables, UART output, or version strings, it is not possible to reliably determine which version of the rd-riop-demo is currently running on the board. We recommend backing up the Flash content before overwriting it, or adding version information to your custom firmware. 6. The startup model implemented in the current project is that the RT1189 first boots the CM33 (M33 leader), and then the M33 starts the M7 follower through the Multicore/MCMGR framework. No additional boot stage is required. 7. If recovery is required, the most reliable method is to read back and save the existing Flash image before reprogramming. If no backup is available, the only option is to rebuild and reprogram the rd-riop-demo, which will restore the system to a functionally equivalent state. 8. Command-line workflows are supported. SPT internally invokes command-line tools such as OpenSSL and SPSDK to generate keys and build/write images. For more information, please refer to the following documentation:  Secure Provisioning Tool - Command Line Operations As for how the two images are linked together, the key flow is as follows: 1.The demo is structured as two linked multicore projects The RIOP demo repository contains two project directories: riop_M33LEADER_DEMO/ riop_M7FOLLOWER_DEMO/ . In the MCUXpresso multicore project model, the primary/leader project links to the secondary/follower project. When the primary project is built, the secondary project is built first, and the secondary output image is included/embedded into the primary image. 2.The M33 project is configured as the multicore master, and the M7 project as the slave In riop_M33LEADER_DEMO/.cproject , the project defines __MULTICORE_MASTER and __MULTICORE_MASTER_SLAVE_M7SLAVE . Its multicore master configuration points to: ${workspace_loc:/riop_M7FOLLOWER_DEMO/Debug/riop_M7FOLLOWER_DEMO.axf.o} . This means riop_M7FOLLOWER_DEMO.axf is first processed into .axf.o , and that object is then linked into the M33 leader image as a “Slave Object.” The M7 project is configured as M7SLAVE / __MULTICORE_M7SLAVE , using the CM7 ITCM/DTCM memory regions. 3.The actual merge happens mainly during the link/post-build stage The MCUXpresso multicore flow processes the secondary-core image, including shifting secondary-core sections before linking them into the complete multicore image. Therefore, the final riop_M33LEADER_DEMO.axf is essentially the M33 leader ELF plus embedded M7 follower image data/sections , not a simple binary concatenation of two standalone AXF files. 4.At runtime, M33 starts M7 In riop_M33LEADER.c , the M7 boot address is defined as: CORE1_BOOT_ADDRESS = 0x303C0000 , and CORE1_KICKOFF_ADDRESS = 0x0 . In SystemInitHook() , the code calls Prepare_CM7(CORE1_KICKOFF_ADDRESS) , and later in main() it calls MCMGR_StartCore(kMCMGR_Core1, CORE1_BOOT_ADDRESS, ...) to start the secondary core. So although the M7 image is embedded into the M33 leader AXF, M7 execution is still explicitly kicked off by M33 at runtime. 5.The bootable image still needs SPT processing For RT1180, the documentation states that the device can boot only from CM33. The Secure Provisioning Tool is used to generate a bootable image with a boot header from the raw application image, and MCUXpresso output types include .axf . So the usual flow is: riop_M7FOLLOWER_DEMO.axf → processed into riop_M7FOLLOWER_DEMO.axf.o → linked into riop_M33LEADER_DEMO.axf → SPT uses the M33 leader AXF to generate the bootable flash image. Best Regards, Shelly

RIOP RT1189 – 基于 GitHub 源代码的 版本 和烧录工作流程 您好， 我目前正在使用 NXP RIOP 评估板，已经成功完成了入门指南并测试了预编程的 FreeMASTER 演示程序。 我的下一步是从源代码重新构建演示程序，将其烧录回开发板，并验证我的完整构建和烧录流程是否正常工作。 我查阅了以下文档和资料： 入门指南：GS-REMOTE-IO-PLATFORM RIOP 用户指南：UG10224 GitHub 仓库：nxp-appcodehub/rd-riop-demo GitHub 仓库包含这两个项目。 riop_M33LEADER_DEMO riop_M7FOLLOWER_DEMO 并指定所需的 SDK 和工具版本，包括 MIMXRT1189 SDK 25.09.00。 我仍然不太清楚的是，如何从这两个项目中得到与板上提供的相同的可启动固件配置。 问题： 构建 M33 和 M7 项目的推荐方法是什么？我是否只需在 MCUXpresso 中分别导入并构建这两个项目，还是它们之间需要特定的构建顺序或依赖关系？我也可以使用 VS Code 扩展吗？ 如何将生成的 M33 和 M7 图像编程到 RIOP 中？安全配置工具是创建和刷写完整应用程序的正确方法吗？ 是否有现成的安全配置工具配置或示例，展示如何将两个映像组合在一起，包括正确的内存布局和闪存地址？ RIOP 演示中是如何处理图像认证的？出厂配置中是否启用了安全启动/签名验证？刷写自制演示版本时是否需要密钥配置？ 在覆盖之前，有没有办法确定板上当前编程的是哪个版本的 rd-riop-demo？ 从示例代码来看，RT1189 Boot ROM 启动 M33 应用程序，然后 M33 使用 MCMGR 在 0x303C0000 启动 M7。这是工厂镜像的完整启动流程吗？还是还有GitHub仓库中未包含的额外启动阶段？ 是否有原始出厂镜像文件可供获取，以便在必要时将电路板恢复到出厂状态？ 是否也提供命令行/无头版本工作流程？从长远来看，我希望构建过程能够复现，并适用于持续集成。 入门指南对开箱即用的演示程序解释得很好，GitHub 代码库也提供了源代码，但我目前还不明白这两者之间的联系： GitHub 源代码 -> 构建 M33/M7 -> 创建可启动镜像 -> 刷写 -> 运行相同的演示 或许我忽略了 UG10224 或其他文档中的相关章节。 谢谢！ Re: RIOP RT1189 – build and flash workflow from GitHub sources 亲爱的@Embernard ， 关于您的问题，请查看以下回复： 1.RIOP 演示同时支持 MCUXpresso IDE 和 VS Code + MCUXpresso for VS Code。我们推荐使用 VS Code。导入 riop_M7FOLLOWER_DEMO 和 riop_M33LEADER_DEMO 项目后，建议先构建 M7 跟随者项目，再构建 M33 领导者项目。这是因为 M33 项目引用了 riop_M7FOLLOWER_DEMO.axf.o 文件。由 M7 项目生成的多核从映像文件。 2. 只需使用安全配置工具 (SPT) 将 riop_M33LEADER_DEMO.axf 文件编程到 Flash 中即可。请参阅 UG10224，第 4.1.5 节。“运行演示应用程序”。我们建议下载并使用最新的 SPT v26.06 版本。请注意，某些配置设置与用户指南中所示的设置略有不同： ShellyZhang_0-1787196235459.pngShellyZhang_0-1787196235459.pngShellyZhang_0-1787196235459.png 3. 请参考 UG10224 创建您自己的 RIOP SPT 工作区。在 SPT 端，它的主要作用是生成可引导的 RT1189 应用程序映像并将其编程到设备中。 4. 在开发过程中，我们建议使用未签名/开放配置进行功能验证，不建议对 eFuse 或密钥进行编程。 对熔丝进行编程是不可逆的操作，只能在经过适当的验证（例如通过影子寄存器）后，作为生产网络安全流程的一部分来执行。是否启用安全启动、映像签名或加密最终应取决于您的生产安全要求和 SPT 配置。 5. 如果当前固件没有通过 FreeMASTER 变量、UART 输出或版本字符串公开版本信息，则无法可靠地确定当前在板上运行的 rd-riop-demo 版本。我们建议您在覆盖 Flash 内容或向自定义固件添加版本信息之前备份 Flash 内容。 6.当前项目中实现的启动模型是，RT1189 首先启动 CM33（M33 领导者），然后 M33 通过 Multicore/MCMGR 框架启动 M7 追随者。无需额外的启动阶段。 7. 如果需要恢复，最可靠的方法是在重新编程之前读取并保存现有的 Flash 映像。如果没有备份可用，唯一的选择是重建并重新编程 rd-riop-demo，这将使系统恢复到功能相同的状态。 8. 支持命令行工作流程。SPT 内部调用 OpenSSL 和 SPSDK 等命令行工具来生成密钥和构建/写入镜像。更多信息请参阅以下文档： 安全配置工具 - 命令行操作 至于这两幅图像是如何联系起来的，关键流程如下： 1. 该演示程序由两个相互关联的多核项目组成。 RIOP 演示仓库包含两个项目目录： riop_M33LEADER_DEMO/ riop_M7FOLLOWER_DEMO/。 在 MCUXpresso 多核项目模型中，主项目/领导项目链接到从项目/跟随项目。构建主项目时，先构建辅助项目，并将辅助输出图像包含在/嵌入到主图像中。 2. M33 项目配置为多核主设备，M7 项目配置为从设备。 在 riop_M33LEADER_DEMO/.cproject 中，该项目定义了 __MULTICORE_MASTER 和 __MULTICORE_MASTER_SLAVE_M7SLAVE。其多核主配置指向： ${workspace_loc:/riop_M7FOLLOWER_DEMO/Debug/riop_M7FOLLOWER_DEMO.axf.o} 。 这意味着首先将 riop_M7FOLLOWER_DEMO.axf 处理成 .axf.o，然后将该对象作为“从属对象”链接到 M33 领导者图像中。 M7 项目配置为 M7SLAVE / __MULTICORE_M7SLAVE，使用 CM7 ITCM/DTCM 内存区域。 3.实际合并主要发生在链接/版本后阶段 MCUXpresso 多核流程处理辅助核映像，包括将辅助核部分移位，然后再将它们链接到完整的多核映像中。 因此，最终的 riop_M33LEADER_DEMO.axf 本质上是 M33 领头星 ELF 加上嵌入的 M7 跟随星图像数据/部分，而不是两个独立 AXF 文件的简单二进制连接。 4.运行时，M33启动M7 在 riop_M33LEADER.c 中M7启动地址定义为： CORE1_BOOT_ADDRESS = 0x303C0000，CORE1_KICKOFF_ADDRESS = 0x0。 在 SystemInitHook() 中，代码调用 Prepare_CM7(CORE1_KICKOFF_ADDRESS)，然后在 main() 中调用 MCMGR_StartCore(kMCMGR_Core1, CORE1_BOOT_ADDRESS, ...) 来启动辅助核心。 因此，尽管 M7 映像嵌入到 M33 领导 AXF 中，但 M7 执行仍然由 M33 在运行时显式启动。 5. 可启动镜像仍需进行SPT处理。 对于 RT1180，文档中指出该设备只能从 CM33 启动。安全配置工具用于从原始应用程序映像生成带有启动头的可启动映像，MCUXpresso 输出类型包括 .axf。。 所以通常的流程是： riop_M7FOLLOWER_DEMO.axf → 处理成 riop_M7FOLLOWER_DEMO.axf.o→ 链接到 riop_M33LEADER_DEMO.axf → SPT 使用 M33 领导 AXF 生成可启动闪存映像。 顺祝商祺！ 雪莉 Re: RIOP RT1189 – build and flash workflow from GitHub sources 嗨，雪莉， 非常感谢您的详细解答！ 顺祝商祺！ 马可

[IMX8MQ]GPU hang and cannot be recovery We have a custom board based on the IMX8MQ which runs a web-based UI.  In our test scenario, the issue can be reproduced in roughly two to three hours. When the problem occurs, a flood of GPU‑related error logs are generated, after which the entire UI freezes. Other kernel‑level functions remain usable. We have implemented GPU recovery measures, yet they fail to restore normal GPU operation. A full device reboot is the only workaround. OS: Android 11.0.0_2.0.0 (Linux 5.10.9 kernel) Can you please help us in providing a way to either: 1. Fix this issue 2. Recover the GPU Re: [IMX8MQ]GPU hang and cannot be recovery The most practical fix path is to move off Android 11.0.0_2.0.0 / Linux 5.10.9 and test at least Android 11.0.0_2.2.0, preferably 11.0.0_2.6.0 if you must stay on Android 11. NXP’s Android release page shows 11.0.0_2.0.0 uses Linux 5.10.9, while later Android 11 drops use newer BSPs: 11.0.0_2.2.0 uses Linux 5.10.35, 11.0.0_2.4.0 uses Linux 5.10.52, and 11.0.0_2.6.0 uses Linux 5.10.72 for i.MX 8M Quad EVK images . I also found an NXP community trace stating that an RD GPU patch fixed a similar Android 11 issue in Android 11.0.0_2.2.0, and that it was a “major patch associated with GPU” later carried into Android 11/12 . For recovery: I would not rely on a software-only GPU reset once the Vivante/galcore GPU is hard-hung. The evidence I found shows galcore can attempt “GPU hang, automatic recovery” and report “recovery done,” but the same trace then continues into an AXI BUS ERROR GPU state dump . Another report notes that the reset_gpu path did nothing because there was “no registered reset control” . In practice, if galcore automatic recovery fails, the robust field workaround is a controlled system reboot, not only restarting SurfaceFlinger/WebView or the UI process. Recommended action plan: Reproduce on NXP i.MX8MQ EVK or NXP demo image if possible. If the issue appears only on the custom board, prioritize board-port differences: DDR timing/training, GPU power rail behavior, thermal, and device-tree memory carveouts. NXP guidance for similar i.MX8MQ custom-board GPU problems is to reproduce on the reference board with NXP demo images; if the failure is custom-board-only, rerun DDR tests and rebuild with updated LPDDR4 coefficients . Update BSP / GPU driver stack. Your release is Android 11.0.0_2.0.0 with Linux 5.10.9. Later NXP Android 11 releases exist for i.MX8MQ, including 11.0.0_2.2.0, 2.4.0, and 2.6.0 . Because a GPU-related Android 11 fix is specifically associated with 11.0.0_2.2.0 , first test your workload on 11.0.0_2.2.0 or newer before investing in elaborate runtime recovery. Check DDR size and GPU-addressable memory placement. Several i.MX8M-family GPU hangs/errors are tied to memory configuration. One NXP thread says the Vivante GPU driver in a GA release did not support the 4 GB memory address range and that limiting the system to 3 GB with mem=3072MiB avoided the AXI BUS ERROR failure . Another note states the GPU can only handle physical memory in the 0x10000000 to 0x80000000 area and suggests assigning CMA memory into low memory to avoid addresses above that range . As a quick experiment, boot with reduced memory, for example mem=3072MiB , and see whether the 2–3 hour failure disappears. Review CMA / contiguous GPU memory. NXP support recommends increasing CMA to about 25% of total DDR for similar i.MX8M GPU crash scenarios . The Android guidance also mentions using galcore.contiguousSize=xxx on the kernel command line to set GPU memory size . If your UI uses WebView/WebGL/video/canvas heavily, CMA exhaustion or fragmentation over a few hours is a plausible cause. Try GPU driver boot-parameter mitigations. For debug, test: galcore.powerManagement=0 to disable GPU power management galcore.baseAddress=0x40000000 galcore.physSize=0 to disable GPU flat mapping galcore.contiguousSize=xxx to tune contiguous GPU memory These should be treated as isolation tests first, not final production changes, unless they clearly eliminate the failure. Verify GPU power rail and operating mode. The i.MX8MQ datasheet lists VDD_GPU nominal-mode operation as 0.81–1.05 V, typical 0.9 V, with maximum GPU frequency 800 MHz; overdrive mode is 0.9–1.05 V, typical 1.0 V, with maximum GPU frequency 1 GHz . Absolute maximum for VDD_GPU is 1.1 V, noted for overdrive . Do not simply raise the rail to 1.1 V as a “fix”; instead, confirm the actual rail, ripple, droop during UI/GPU load, PMIC sequencing, and whether your GPU frequency/OPP matches the configured voltage. Use reboot as the production recovery fallback. You can still attempt a less disruptive recovery sequence — stop UI app/WebView, stop SurfaceFlinger, unload/reload galcore if built as a module — but the documented module operation is only normal insmod / rmmod handling , not guaranteed recovery from a wedged hardware state. If the kernel is alive but GPU logs flood and galcore recovery fails, trigger a controlled reboot from a watchdog/health monitor. Minimal triage matrix: Test Expected interpretation Run same test on NXP 11.0.0_2.2.0+ image If fixed, root cause is likely already addressed by later GPU/BSP patches. Boot with mem=3072MiB If fixed, suspect 4 GB / high physical address / GPU memory placement issue. Increase/relocate CMA into low memory If fixed, suspect GPU contiguous-memory allocation/addressing. Add galcore.powerManagement=0 If fixed, suspect GPU power-management transition/clock/rail interaction. Measure VDD_GPU during failure window If droop/ripple correlates, fix PMIC/rail/OPP configuration. Reproduce on EVK If EVK is stable, focus on custom board DDR, power, thermal, and device tree.

NXPコード署名ツール（CST）のFIPS 140-3レベル3準拠 NXPチームの皆様、こんにちは。 現在、セキュアブートの実装、およびイメージ署名に使用する鍵と証明書の生成・管理には、NXPコード署名ツール（CST）を使用しています。 製品セキュリティ要件の一環として、CSTベースのコード署名プロセスのFIPS 140-3レベル3準拠を理解する必要があります。 以下の点を明確にしていただけますか? 1.NXPコード署名ツール（CST）自体は、FIPS 140-3に準拠しているか、またはFIPS 140-3レベル3の要件について検証済みですか？ もしそうであれば、関連する認証、検証の詳細、または準拠を裏付ける公式のNXP文書を共有していただけると助かります。 ありがとう Re: FIPS 140-3 Level 3 Compliance of NXP Code Signing Tool (CST) CSTはNXPのコード署名ツールとして文書化されており、FIPS 140-3レベル3の認証を受けた暗号モジュールとしては文書化されていません。

MVR5510 OTP编程 我们目前正在测试 MVR5510AMDA0ES 的 OTP 编程。我已经进入测试模式，MAIN_TM_STATUS=0X42，FS_STATE_REG=0XA001。目前模拟正常，读取到的 OTP 值也正确。但是，当我关闭芯片电源并再次读取 OTP 值时，我发现 OTP 完全为空。当仿真正常时，如何向 OTP 写入数据并完成编程？目前，VSUP1/2=12V，VDDOTP=8.5V，POWERON1=5V，POWERON2=3.3V 请注意，我使用的是 I2C 协议来对 OTP 进行编程，而不是使用原厂工具。请问您能否帮我看看还需要执行哪些命令才能真正写入 OTP？ Re: MVR5510 OTP programming 好的，我会请我们的美国同事联系恩智浦半导体，因为他们负责与恩智浦半导体签订保密协议。如有必要，我会及时通知您。 Re: MVR5510 OTP programming 我看了下你们是烧录器公司吗？假如是的话那么第三方想做我们烧录的合作伙伴是需要认证的您可以联系NXP的local的代表去商务谈判，所以我无法把烧写的程序直接给您。 Re: MVR5510 OTP programming 已经告诉你了 OTP不支持用自己的板子去烧写，因为里面有很多rule 要追寻这些都是保密的不对外开放，你要想自己做OTP 首选我们指定的板子去烧写，正常情况下你是无法正确读取OTP寄存器的值。能理解嘛? Re: MVR5510 OTP programming 感谢您的回复，虽然对我没有任何帮助。我需要解决一个技术问题，但你却给了我一份销售方案。我会和老板讨论这件事。 Re: MVR5510 OTP programming 我们不支持客户用自己的板子做OTP，大批量的时候可以选择第三方做OTP，小批量或者自己做OTP测试的话我建议您购买下面的板子： SBC and PMIC Product OTP Programming Board | NXP Semiconductors guoweisun_0-1787018585422.pngguoweisun_0-1787018585422.png guoweisun_1-1787018601483.pngguoweisun_1-1787018601483.png 这两个组合还是比较有性价比。

LPC55S69: CPBOOT/CPUCTRL/CPUCFGシーケンスを完全に検証したにもかかわらず、コア1が起動しない LPC55S69: ブートシーケンスが完全に検証されているにもかかわらず、コア1が実行を開始しない（MCMGRと手書きレジスタ書き込みの両方で同様に失敗する）。 環境 ボード：LPC55S69-EVK（LPCXpresso55S69）、LPC55S69JBD100 IDE:MCUXpresso IDE v25.6 [ビルド136] [2025-06-27] OS:Linux(openSUSE) ツールチェーン:GNU ARM Embedded(バンドル)、GCC 14.2.1 デバッグプローブ：オンボードLPC-Link2、LinkServerバックエンド 使用されたSDKコンポーネント:driver.flexcomm、driver.mailbox、ミドルウェア.マルチコア.mcmgr_lpc55s69、freertos_kernel + cm33_non_trustzone_port (マスターのみ) 概要 コア0（マスター、cm33_core0）は正常に動作します。コア 1 (スレーブ、cm33_core1、ロール M33SLAVE) は、 2 つの別々のクリーンルーム プロジェクト ビルド ( 1つは手書きのレジスタ シーケンス、もう 1 つは NXP 独自の MCMGR ミドルウェアを使用) において、レジスタ レベルとメモリ レベルでブート シーケンスのすべての要素が独立して正しいことが検証されているにもかかわらず、自身の main () の最初の命令さえ実行しないようです。どちらの試みも、全く同じ行き詰まりに陥った。 独立機関によって正しいと検証された内容 試み１ ― 手書きのブートシーケンス SYSCON->CPBOOT は、組み込みスレーブイメージの実際のリンカ確認済みアドレスに設定されます（objdump -h section VMA で検証し、nm シンボルアドレスと照合します。0x0 に解決されるシンボルではなく、実際のゼロ以外の組み込み位置です）。 SYSCON->CPUCTRL は、書き込み解放直後に 0x08 (CPU1CLKEN ビット 3 セット、CPU1RSTEN ビット 5 クリア) として読み戻され、インバンドでキャプチャされました (書き込みを実行した関数によって共有メモリに書き込まれ、後で古い可能性のあるデバッガ セッションを介して読み取られたものではありません)。 SYSCON->CPUCFGビット2（CPU1ENABLE）がセットされていることを確認（0x04） 確認されたブートアドレスのベクターテーブルは独立して有効性を検証:初期スタックポインタが正しく計算されました(Core 1のSRAM領域の上部)、リセットベクターアドレスはnmの実際のResetISRシンボルと一致しています(ターゲットアドレスを分解して本物で妥当なCortex-M起動コードを見つけたことで確認:cpsid i →SystemInit() → data_init/bss_initループ → cpsie i → __main → _initio → アプリケーション main()) 両方のコアで独立してコンパイルされた.mapファイルにおいて、共有メモリ構造体が同一の物理アドレスに解決されることが確認されました。ファイル Core 1のプライベートSRAM/スタック領域がCore 0の領域と重複していないことを確認しました（別の物理SRAMバンクに移動済み）。 埋め込まれたスレーブイメージの.dataを確認しましたセクション (ゼロ初期化されていないグローバル変数) は、コア 0 のライブ メモリ内に配置されません (INSERT BEFORE .data を使用したカスタム リンカー スクリプト フラグメントが必要)。デフォルトのリンカースクリプトにはobjcopyで名前変更されたマルチコアセクションの配置ルールがなく、そうでなければ「孤立セクション」としてコア0のSRAMに配置されてしまうため。 上記すべてにもかかわらず、Core 1 の main() の最初の行として書き込まれた診断値 (共有され、正しくアドレス指定されていることが確認されたメモリ内) は、初期値から変化しません。 試行2 — NXPのmcmgr_lpc55s69ミドルウェアを使用した新規プロジェクト レジスタ書き込みを手書きで行う代わりに、MCMGR_Init() / MCMGR_StartCore() / MCMGR_TriggerEvent() を使用してゼロから再構築し、レジスタシーケンスに誤りがないかを確認しました。 mcmgr_internal_core_api_lpc55s69.cを直接読んでください:mcmgr_start_core_internal()が正しいSDKマクロ(SYSCON_CPUCTRL_CPU1RSTEN_MASKなど)を使ってCPBOOT→CPUCTRLシーケンス→同じCPUCFGを実行していることを確認しました。 MCMGR_Init() (main() から呼び出される) は MCMGR_EarlyInit() / mcmgr_early_init_internal() を呼び出さないことが分かりました。後者は独立した公開関数であり、ソースコードのコメントには「（SystemInitHook の起動シーケンス内で）リセットエントリのできるだけ近くで呼び出されることを意図している」と記載されているが、生成されたプロジェクトではこれを自動的に接続する仕組みは何もない。SystemInitHook() は汎用デバイス起動ファイルでは __attribute__((weak)) であり、デフォルトでは空のスタブになります。 両方のコアで独自の SystemInitHook() オーバーライドを追加し、mcmgr_early_init_internal(MCMGR_GetCurrentCore()) を呼び出しました。.mapで確認済みこのオーバーライドが、両方のプロジェクトで実際の関数（弱いスタブではない）としてリンクするファイル。 試行1のすべての修正を再適用および再確認しました（反復的な再構築全体にわたる埋め込みアドレスの安定性、.dataセクションのリダイレクトは、同じリンカーフラグメント技術を使用し、コア1のSRAMの再配置、CPUCFG/CPBOOT/CPUCTRLレジスタの値はすべて試行1の結果と同一です。 MCMGR_BUSY_POLL_COUNTデフォルトで定義されていないため、mcmgr.cではMCMGR_StartCore(..., kMCMGR_Start_Synchronous)ブロックが タイムアウトなしで 使えます内部待機ループ (while (s_mcmgrCoresContext[coreNum].state)!= kMCMGR_RunningCoreState)) は、mcmgr.h のマクロの条件付きコンパイルを直接読み取ることで確認されました。 結果：全く同じ結果。コア0がMCMGR_StartCore()内で永久にブロックされる。診断用共有メモリ値（両方のコアの.mapで同じアドレスが確認されました）ファイルは、真に共有されたSRAMバンク内にあり、.noinitCore 1のmain()の最初の実行可能行として文字通り書かれ、初代値の0を離れません。 質問 CPUCFG、CPBOOT、およびCPUCTRLはすべて、リファレンス実装(mcmgr_internal_core_api_lpc55s69.c)と全く同じように読み取られます。ブートアドレスに埋め込まれたイメージが、正しくリンクされたCortex-Mバイナリであることが独立して確認されていますが、この 部分でCore 1の命令フェッチを開始するために、これら3つのレジスタ書き込みだけではキャプチャされない追加のステップが必要でしょうか? 具体的には： LPC55S69（どのリビジョンでも可）において、CPBOOT/CPUCTRLベースのセカンダリコアブートに影響を与える既知のシリコンエラーはありますか？ Core 1の起動には、アプリケーションレベルのレジスタシーケンスに加えて、デバッグプローブレベルのアクション(例:この部分で列挙された2番目のSWDデバイスを対象としたSWDアタッチャ/リボン)も本当に必要なのでしょうか?これは、NXP自身のマルチコアSDKの例(例:)freertos_message_buffers_secondary_core)をIDEsの通常の単一プロジェクト「Debug」フローでデバッグすると、Core 1は別のLaunch グループ設定なしで正常に起動しているように見えます。これは、MCUXpressoのデバッグ起動自体がアプリケーションコードだけではトリガーできない追加ステップを行っている可能性を示唆しています。 これら3回の書き込み間に、参照mcmgr_internal_core_api_lpc55s69.cに反映されていない最小遅延、順序制約、または追加のレジスタ(例えば電力/クロック領域)があるのでしょうか?実装？ プロジェクトファイル一式（.mapファイル）を提供いたします。ファイル、またはご要望に応じた最小限の複製プロジェクトを提供いたします。 LPC55xx Re: LPC55S69: Core 1 never starts despite fully verified CPBOOT/CPUCTRL/CPUCFG sequence 解決済み — 根本原因は、Core 1 の起動失敗ではなく、私自身の診断における偽陰性でした 後で同じ症状のThreadを見つけた方のために解決策を投稿します。 実際の根本原因 このプロジェクトのどのバージョンにおいても、コア1は常に正常に起動し、動作していました。問題はCPUCFG/CPBOOT/CPUCTRL、ベクターテーブル、メモリ配置、あるいはブートシーケンス内の他のいずれにもなかった。問題は、コア1が何も実行していないように見えた、私自身の診断ツールのバグだった。 私は小さな共有メモリ構造体を使用していました（__attribute__((section(".noinit.$SRAM4"))))コア1によって書き込まれ、コア0によって読み込まれ、起動の進行状況を監視する。この手法は、プロジェクトで生成されたリンカスクリプトが実際にSRAM4という名前の領域を定義している場合にのみ、真の共有メモリに実装されます。私がゼロから作成したウィザードプロジェクトはその領域を定義していたので、その技術は構造的に機能していましたが、後にNXPの作業中のhello_world例プロジェクト(異なる名前の領域、Ram1/rpmsg_sh_memを使ったもので、SRAM4ではなく異なる名前の領域)の上にバージョンを構築した際、同じ属性が静かに各コアのprivate.noinitに移行しましたエラーを発生させる代わりにメモリに記録する。Core 0とCore 1はそれぞれ「shared」構造体の独自のコピーを読み書きしていましたが、コンパイラやリンカは何も問題がないと警告しませんでした。 最終的な結果：私の診断では、2 つの独立したブート実装 (手書きの CPUCFG/CPBOOT/CPUCTRL レジスタと NXP 独自の MCMGR ミドルウェア) と複数のプロジェクト構成にわたるすべてのテストで 0 (進行なし) が報告されました。これは、コア 1 が実際に実行されているかどうかに関係なく、2 つのコアがそもそも同じメモリ アドレスを参照していなかったためです。 実際にどのように発見されたか NXPの動作するhello_worldサンプルをそのままコピーし、既存の、変更されていない、動作確認済みのmain.cに診断書き込みのみを追加することで、(交換するのではなく)、オンボードLEDでCore 1が本当に全シーケンスを実行していることを視覚的に確認できましたが、共有メモリカウンタは依然として0と表示されていました。その矛盾(実行の物理的証拠と診断の否定)が、コア1ではなく診断自体が壊れていることを露呈させました。セクション名をプロジェクトの実際の領域（.noinit.$SRAM4 ではなく .noinit.$rpmsg_sh_mem）に一致するように修正したところ、すぐに正しい増加値が生成されました。 LPC55xxでマルチコアブートをデバッグしている他の人への教訓 コア間共有メモリに .noinit.$ セクション属性を使用する場合は、別のプロジェクトで動作した名前 (SRAM4 など) を想定するのではなく、その特定のプロジェクトで生成された _Debug_memory.ld に対して領域名を確認してください。ここで不一致が発生すると、ビルド警告もリンクエラーもランタイム障害も発生せず、完全にサイレントに失敗します。そして、実際のブート失敗と全く同じ症状が現れます（レジスタ/ベクタテーブルレベルのデバッグではすべて正常にチェックされます。なぜなら、実際の問題は完全に診断レイヤーにあるからです）。 以前の投稿を読んでくださった皆様、ありがとうございました。CPUCFG/CPBOOT/CPUCTRL/ベクターテーブルの検証作業は無駄ではありませんでした。それらがすべて正しかったことが確認できたことで、最終的に調査対象が未検証の最後の要素である診断メカニズム自体へと絞られました。 Re: LPC55S69: Core 1 never starts despite fully verified CPBOOT/CPUCTRL/CPUCFG sequence アップデート:問題はアプリケーションコードではなく、プロジェクトやリンカーの設定に特定しました 投稿後、決定的なテストを実施したところ、この可能性が大幅に絞り込まれました。 テスト：NXP独自の未修正マルチコアサンプルは、このハードウェアで正常に動作しますか？ LPCXpresso55S69 用に multicore_examples/hello_world (プライマリ + セカンダリ) を新規にインポートし、完全に変更を加えず、そのままデバッグしました。 結果：うまくいった。オンボードのRGB LEDは、500ms点灯/500ms消灯の規則的な点滅パターンで動作します。これは、同じボードに書き込んだ自分のプロジェクトと直接比較することで確認済みです（自分のプロジェクトではLEDが消灯、変更されていないサンプルではLEDが点滅、自分のプロジェクトを再書き込みすると再びLEDが消灯）。これは決定的です: まさにこのボード、プローブ、IDEのインストールでデュアルコア実行が可能です。 テスト:例のアプリケーションコードは私のプロジェクトの設定内で動作しますか? 問題が自分のアプリケーションコードにあるのか、プロジェクトのビルド/リンク設定にあるのかを区別するために、動作中の例のセカンダリコアmain.cをコピーしました。app.h、および hardware_init.cそのまま(バイト単位、未修正)で自分のスレーブプロジェクトに組み込まれ、自分のアプリケーションコードを完全に置き換えました。 結果：LEDは点滅しない。元のサンプルプロジェクトでは正常に動作する、全く同じで変更されていないNXPコードが、私のプロジェクト構成内でビルドするとCore 1の起動に失敗します。 これが証明すること 問題はアプリケーションレベルのコードではありません(すでに2回確認されています。手書きレジスタ実装とMCMGRベースの実装で、そして今回は3回目はそのサンプルのソースファイルで確認されています)。私のプロジェクトのマルチコアリンカー設定／メモリ領域構成が、動作するサンプルとどのように異なっているかという点に特有の問題があり、私はできる限り正確に一致させようと努力したにもかかわらず、それが起こってしまいました。 MCMGR_StartCore() の後、CPUCFG、CPBOOT、CPUCTRL はすべて意図どおりに読み戻されます。 埋め込みイメージのベクトルテーブルは、独立して検証され、有効であることが確認されています（正しいスタックポインタ、実際のResetISRシンボルと一致する正しいリセットハンドラアドレス）。 マスターメモリ領域はRAM領域（PROGRAM_FLASHではない）に設定されており、これはCore 1のイメージをフラッシュではなくRAMに埋め込むという動作例のアプローチと一致しています。 コア1のプライベートメモリはコア0のプライベートメモリと重複しません 構造上の違いが1つ見つかりましたが、まだ解決していません。動作例のセカンダリコアプロジェクトの.cprojectには、PROGRAM_FLASHメモリ領域のオーバーライドがまったく含まれていません。これは、動作例のセカンダリコアプロジェクトの.cprojectに、PROGRAM_FLASHメモリ領域のオーバーライドがまったく含まれていないためです。（カスタムRAM由来の領域は2つのみ）。私がゼロからウィザードで作成したスレーブプロジェクトには、再配置された PROGRAM_FLASH を含む 3 つの領域があります。その領域を完全に削除しようとすると(動作する例に正確に一致させるため)、MCUXpressoのMCU設定ページ(NullPointerException: this.mcuPage is null)がクラッシュし、IDEのツールがフラッシュ領域が定義されていないプロジェクトを快適にサポートしていないことを示唆しています。これが作業中の例の正確な設定を手作業で照合するのが難しい理由かもしれません。 質問 マスターの「M33SLAVE」役割+マルチコアリンカー設定以外に、SDKのhello_world例と同じ動作状態にするプロジェクトをゼロから作るために必要な特定のマルチコアプロジェクト構成はあるのでしょうか?それともMCUXpresso IDE v25.6.136に既知の制限やバグがあるのでしょうか?マルチコアLPC55S69プロジェクト用のプロジェクトウィザードで、サンプルプロジェクトファイルがウィザードでは再現できない方法で回避しているものはありますか？ 両プロジェクトの完全な.cprojectファイルを喜んで共有します。必要に応じて直接比較するためのファイル。