S32K344 OTAアクティブ領域 1. S32K3_HSE_DemoExamples_1_0_0\S32K3_HSE_DemoExamples\テンプレート\S32K344_DemoAppTemplate\ドライバ\dcm_register\hse_dcm_register.c xionggang_0-1787021979735.pngxionggang_0-1787021979735.png 2. AN13465_S32K3xx セキュアブート.pdf xionggang_1-1787021998225.pngxionggang_1-1787021998225.png 「アクティブ領域」の説明はドキュメントとコードで一貫していません。どちらが正しいのか？ Re: S32K344 OTA Active Region ハイ Dcm_ActiveAddressOTARegion () は、 DCMOTAR =0/1 から低値/高値へのマッピングを反転させたようです。 DCMSTAT [ DCMOTAR ] については以前にも議論しました。https: //community.nxp.com/t5/S32K/s32k312/td-p/1697583 よろしくお願いいたします ロビン

温度センサー ADT7420 KW47-LOCボードでは動作しません こんにちは KW47-LOCボードでadt7420サンプルデモを実行しようとしましたが、 「sensor_addr_set failed ret -134」というメッセージが表示されました。 ターゲットにイメージをフラッシュした後。 チップに互換性があるため、frdm-mcxw72のサンプルを使用し、オーバーレイファイルを修正してKW47-LOCボードのピンに適合させました。 参考までに、以下の写真の印刷メッセージをご覧いただけます anliu114036_0-1787031664257.pnganliu114036_0-1787031664257.pnganliu114036_0-1787031664257.pnganliu114036_0-1787031664257.png こちらがオーバーレイです。そしてprj。ファイル情報： anliu114036_1-1787032612716.pnganliu114036_1-1787032612716.pnganliu114036_1-1787032612716.pnganliu114036_1-1787032612716.png anliu114036_2-1787032650507.pnganliu114036_2-1787032650507.pnganliu114036_2-1787032650507.pnganliu114036_2-1787032650507.png 適切な温度を測るのを手伝ってもらえますか?正直、どう解決すればいいのか全く分かりません。前もって感謝します よろしくお願いいたします！ Re: ADT7420 temperature sensor can't work with KW47-LOC board こんにちは、db16122さん。 私はこのパートではジュニアなので、あなたの下のガイドの説明が理解できません。問題を確認するためにウェブミーティングを開くことは可能でしょうか? Re: ADT7420 temperature sensor can't work with KW47-LOC board sensor_addr_setが失敗し、戻り値-134が返されました。これは、 adt7420モジュールのアドレス設定が間違っていることが原因である可能性があります。 ADT7420_cn.pdf 温度測定のクイックガイド 以下は、温度を測定するための簡単なガイドです。 連続変換モード（デフォルトの電源投入モード）。実行する 各ステップを順番に実行してください。 1.ADT7420の電源を入れた後、以下の手順でセットアップを確認します。 デバイスID（レジスタアドレス0x0B）を読み取っています。それはすべきです 0xCBを読み込む。 2. 連続した測定値が得られた後に ステップ 1、構成レジスタ (0x03) を読み取ります。 TCRIT (0x08、0x09)、THIGH (0x04、0x05)、TLOW (0x06、 0x07) レジスタ。表6に指定されているデフォルト値と比較してください。 すべての読み取り値が一致すれば、インターフェースは動作しています。 3. 設定レジスタに書き込み、ADT7420 を次のように設定します。 希望する構成。 4. 温度値の最上位ビットレジスタを読み取り、続いて 温度値の最下位ビット（LSB）レジスタ。両方のレジスタは 有効な温度測定値を生成する。 Re: ADT7420 temperature sensor can't work with KW47-LOC board 公式EVK anliu114036_0-1787042775204.jpeganliu114036_0-1787042775204.jpeganliu114036_0-1787042775204.jpeganliu114036_0-1787042775204.jpeg Re: ADT7420 temperature sensor can't work with KW47-LOC board カスタムボードを使用していますか、それとも公式のEVKを使用していますか？ Re: ADT7420 temperature sensor can't work with KW47-LOC board それでは、さらにサポートが必要な場合は、内部メッセージを送ってください。 Re: ADT7420 temperature sensor can't work with KW47-LOC board はい、あなたの助けが必要です。どのウェブ会議ツールがご都合よろしいですか？また、ご都合の良い時間帯を教えてください。本当にありがとうございます！

About S32K3XX APPLICATION sunshine88_0-1787046454804.pngsunshine88_0-1787046454804.png 想咨询一下，为什么在S32K358 RTD库函数中，没有Cache_Ip_init()函数，如果没有初始化函数，系统又是怎样初始的哪？系统自启动Cache初始化过程吗？ Re: About S32K3XX APPLICATION 你好， 我想请问为什么 S32K358 RTD 库中没有 `Cache_Ip_init()` 函数。如果没有初始化函数，系统如何初始化缓存？系统是否会自动启动缓存初始化过程？ 在最近的 RTD 版本中，S32K358 RTD 没有提供专用的 Cache_Ip_Init() API。缓存启用是在设备启动期间通过平台/系统初始化代码处理的。启用缓存后，Cortex-M7 硬件会自动管理缓存分配、失效和行替换。因此，不需要显式的应用层缓存初始化函数。 顺祝商祺！ Peter

ADT7420 temperature sensor can't work with KW47-LOC board Hi  i tried to run the adt7420 sample demo with KW47-LOC board, but the print message is "sensor_addr_set failed ret -134.“ after i flashed the image into the target . Since the chips are compatible , I used the frdm-mcxw72 examples and modify the overlay file to adapt it to the KW47-LOC board pins. you can find the print message like below picture for reference  anliu114036_0-1787031664257.pnganliu114036_0-1787031664257.pnganliu114036_0-1787031664257.pnganliu114036_0-1787031664257.png here is the overlay. and prj. file information : anliu114036_1-1787032612716.pnganliu114036_1-1787032612716.pnganliu114036_1-1787032612716.pnganliu114036_1-1787032612716.png anliu114036_2-1787032650507.pnganliu114036_2-1787032650507.pnganliu114036_2-1787032650507.pnganliu114036_2-1787032650507.png can you help check how to get the right temperature very. i really have no idea to solve the issue.  thanks in advance Best regards! Re: ADT7420 temperature sensor can't work with KW47-LOC board Hi db16122, i‘m junior for this part, and i can't understand your below guiding. is it possible we can have web meeting to check the issue? Re: ADT7420 temperature sensor can't work with KW47-LOC board sensor_addr_set failed ret -134 may caused by address setting incorrect about the adt7420 module ADT7420_cn.pdf QUICK GUIDE TO MEASURING TEMPERATURE The following is a quick guide for measuring temperature in continuous conversion mode (default power-up mode). Execute each step sequentially. 1. After powering up the ADT7420, verify the setup by reading the device ID (Register Address 0x0B). It should read 0xCB. 2. After consistent consecutive readings are obtained from Step 1, proceed to read the configuration register (0x03), TCRIT (0x08, 0x09), THIGH (0x04, 0x05), and TLOW (0x06, 0x07) registers. Compare to the specified defaults in Table 6. If all the readings match, the interface is operational. 3. Write to the configuration register to set the ADT7420 to the desired configuration. 4. Read the temperature value MSB register, followed by the temperature value LSB register. Both registers should produce a valid temperature measurement. Re: ADT7420 temperature sensor can't work with KW47-LOC board official EVK anliu114036_0-1787042775204.jpeganliu114036_0-1787042775204.jpeganliu114036_0-1787042775204.jpeganliu114036_0-1787042775204.jpeg Re: ADT7420 temperature sensor can't work with KW47-LOC board do you use custom board or officail EVK？ Re: ADT7420 temperature sensor can't work with KW47-LOC board Yes, i need your help. which web meeting tool is ok for you and when you are available? many thanks! Re: ADT7420 temperature sensor can't work with KW47-LOC board Ok then, drop me a internal message if you need further help

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 嗨，雪莉， 非常感谢您的详细解答！ 顺祝商祺！ 马可