s32ds-lisence Our company is using the s32ds 3.5 version of the IDE. This version of the IDE requires a license. However, we couldn't find the registration link for the 3.5 version of the IDE on the official website. How can we solve this problem? 222.png222.png222.png Re: s32ds-lisence For my other account, when accessing this interface, there was no 3.5 download package or license. I have two computers. The current account has a license, but when I accessed this interface on the other computer, I couldn't find the 3.5 download package and license. Re: s32ds-lisence Hi @iiiddd  Try to use this link, it should work: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=S32DS-3-5 Regards, Lukas

S32 Design Studio for ARM v2018 ライセンスが切れました 3A82-FA1E-4469-2A32。なぜ新しいコードが生成されないのでしょうか?新しい免許を取得するにはどうすればいいですか? Re: S32 Design Studio for ARM v2018 license expired こんにちは、 お客様のS32DSライセンスの有効期限が延長されました。

S32DS license ActivationId Hello, When I opened the S32DS, I got the following information:  S32 Design Studio for ARM ActivationId: 1A99-90A8-2F06-339B Evaluation Days: 14 Feature Version: 2.2 Feature Status: Evaluation (14 days) What procedures are required to extend the license validity period? Wishing you good business wishes!  回复： S32DS license ActivationId ActivationId: 1A99-90A8-2F06-339B Please help activate and extend the usage period, thank you. Re: S32DS license ActivationId Hi,  your S32DS license has been extended. Please activate S32DS again with your old code. 

S32 Design Studio for Arm extend Hi , I would like to extend my S32 Design studio for ARM license. Expiration Date: Mar 28, 2026 Activation Code: 7D78-3595-C40B-5F1E Thanks. Re: S32 Design Studio for Arm extend Hi,  your S32DS license has been extended. Please activate S32DS again with your old code.  Re: S32 Design Studio for Arm extend Anyone help me?

PWMを使用したVboost（手動）ヒステリシスなし ファクトシート/PT2000A4FS.pdfに記載されているように、Vboost DCDCジェネレータの手動制御またはPWM制御を使用するSD6 MC33816 PT2000またはPT2001用のファームウェアコードを作成した人はいますか？唯一の指針は、インジェクターコードに似ているはずだが、低側のみであり、電圧制御と電流制御の両方が必要だということだ。 ソレノイドコントローラー Re: Vboost using PWM (manual) NOT hysteretic こんにちは、Fastさん。例を教えていただきありがとうございます。DRAM内のpwm_tonとpwm_toffの値は何ですか？あなたのコードを試しましたが、なぜ私の場合VboostがVBOOT_H(65Vと定義されている)に達しないのか不思議に思っています Re: Vboost using PWM (manual) NOT hysteretic 今のところは大丈夫です。はい、添付ファイルにはVboost生成の「マニュアル」方法が示されており、マイクロコードでLS7のオン・オフが行われます。 そろそろ閉店しましょうか？他に質問はありますか？ Re: Vboost using PWM (manual) NOT hysteretic 直接メールを [email protected] に送ってください 。この件についてはいつも彼と話し合ってきました。 Re: Vboost using PWM (manual) NOT hysteretic 上記の説明は、あなたが言及された手動PWMと何か関係がありますか？ Re: Vboost using PWM (manual) NOT hysteretic こんにちは、グオウェイスン はい、PT2001/MC33816にはハードウェアが内蔵されています。LS7のみがVFM（可変周波数モード）、ヒステリシス電流制御、または非同期位相と呼ばれる機能を備えています。私が完全に理解できない理由で、このモードには問題があります。このモードは、負荷によって消費される電流によるVboostの変動に敏感であるか、Vboostから供給される負荷の電流制御に問題があるかのどちらかです。どうやら、リザーバーコンデンサを直接接地し、Vboostの電流検出を回避すれば、感度は低下しないようだ。それはブースかもしれない。手動PWMモードのコーディングにより、その状況は回避されています。同じ機能に複数の名前を呼ぶと、これらの強力なソレノイドコントローラは不必要に複雑に感じられがちですが、続ければ必ず報われます。同期フェーズは基本的にオフです。その方がずっとシンプルに聞こえます。 Fast_0-1737539689581.pngFast_0-1737539689581.pngFast_0-1737539689581.pngFast_0-1737539689581.png Re: Vboost using PWM (manual) NOT hysteretic guoweisun_0-1737510763987.pngguoweisun_0-1737510763987.pngguoweisun_0-1737510763987.pngguoweisun_0-1737510763987.png しかし、Vboostは同期モードと非同期モードの両方を使用して実装されます。 あなたの言っていることが理解できませんでしたし、それがチップ内部の機能なのか、それとも別の方法なのかもわかりませんでした。 Re: Vboost using PWM (manual) NOT hysteretic 理由は「 PT2001でVboostが抑制される理由」を参照してください。 つまり、Vブーストが低い場合に内側のループがPWMを処理し、オン時間に制限があります。LS7を直接制御するため、ノイズの影響を受けやすい非同期ハードウェアは使用していません。通常のスイッチオフは電流に達した時です。そして、時間通りに下り坂を進む。Vboost の目標値に達すると、Vboost が低くなりすぎるまで外側のループは停止します。 Vboostの抑制は不要であるため、参照した投稿を参照してください。 コードの使用は自己責任でお願いします！ Re: Vboost using PWM (manual) NOT hysteretic ここでコードの詳細を紹介または説明していただけますか? Re: Vboost using PWM (manual) NOT hysteretic PT2001については、添付の私の解答をご覧ください。ご意見をお聞かせください。 @guoweisun @RafaR Re: Vboost using PWM (manual) NOT hysteretic HI Fast これらの部品ソフトウェアはすべてこちらに一覧です: guoweisun_0-1736732852841.pngguoweisun_0-1736732852841.pngguoweisun_0-1736732852841.pngguoweisun_0-1736732852841.png PT2000 3/4/6シリンダーエンジン評価ボード |NXPセミコンダクターズ お役に立てれば幸いです! BR Re: Vboost using PWM (manual) NOT hysteretic ご回答ありがとうございます！ 現在、PSシミュレーター上でコードのテストを行っています。インダクタは10μH 120mΩで、Tonを5μsに設定しましたが、全く動作しませんでした。次に、それを10μsに増やすと（おそらく7μsでも動作するでしょう）、DCDCは期待どおりに切り替わります。 ありがとう！ Re: Vboost using PWM (manual) NOT hysteretic こんにちは、アティカさん 私は12Vではなく48Vで動作させていました。GaN FETと15μH 25mΩインダクタを使用した場合、Ton = 7μs、Toff = 4μsとなります。これらは設置状況や負荷に大きく依存します。インジェクター切り替え後の回復時間にも注意してください。

Purchasing SAF/SCST Package for S32K3 I raised a ticket for this purchasing. Then I got a reply under this ticket says I need to contact a sales person. Then I emailed this person but he is on vacation but he mentioned two more people as the back up person to contact, then I email them and they also on vacation. Each of them referred more backup person to reach. I emailed all of them and now I have not heard anything back. Its been 3 days. 

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.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 を使用してブート可能なフラッシュ イメージを生成します。 よろしくお願いいたします。 シェリー Re: RIOP RT1189 – build and flash workflow from GitHub sources こんにちは、シェリーさん。 続報です。 RIOPリポジトリにはriop_M7FOLLOWER_DEMO/scripts/image_hash_tool.pyが含まれていませんが、元のプロジェクトでは条件付きでこのファイルが呼び出されています。RIOPマルチコアデモにおいて、ヘルパー関数が欠落しているのは意図的なものですか？もしそうなら、VS CodeのプロジェクトコンバーターはWindows上で元の「スキップ・if uncessent」の動作を保持し、失敗するcmd.exeコマンドを生成せずに済むのでしょうか?意図的でない場合、意図された image_hash_tool.py はどこで提供され、SPT で M33 画像をプロセッシングする前に必須ですか? よろしくお願いいたします。 Marco

Requires an S32DS activation key. The activation code for the S32DS installation requires a signed NDA and a company email address. If you don't have a company email address, please confirm how to apply. Re: 需要S32DS的激活码 Hi,  which S32DS version do you like to use? 

需要S32DS的激活码 s32ds 安装的激活码 需要签署NDA 需要用到公司邮箱 没有公司邮箱 请确认下 怎么申请 Re: 需要S32DS的激活码 你好， 你喜欢用哪个版本的S32DS？

imxrt1050 beeによる暗号化後、プログラムが誤動作しました。 このプログラムは、LEDを点滅させるだけのタイマープログラムです。暗号化されていないボードでは正常に動作しますが、暗号化されたボードでは暗号化後に動作しません。この問題のトラブルシューティング方法がわかりません。J-Linkも接続できないため、トラブルシューティングはさらに困難です。AXFまたはHEXイメージファイルを使用しています。FDCBで使用されるプログラムでは、DQSピンが使用されているため、QSPIは50Mに設定され、CSStepUp/Holdは2に設定されています。 Snipaste_2026-08-19_11-10-50.pngSnipaste_2026-08-19_11-10-50.pngSnipaste_2026-08-19_11-10-50.png Snipaste_2026-08-19_11-11-26.pngSnipaste_2026-08-19_11-11-26.pngSnipaste_2026-08-19_11-11-26.png Snipaste_2026-08-19_11-12-16.pngSnipaste_2026-08-19_11-12-16.pngSnipaste_2026-08-19_11-12-16.png i.MXRT 105x Re: imxrt1050 bee加密后程序运行异常 こんにちは、 @ccc_clive さん。 SNVSキーであるOTPMKをキーとして使用しているようですが、このキーはHABが閉じている場合にのみ有効で、それ以外の場合はすべてゼロになります。署名付き暗号化XIPモードを試して、結果が異なるかどうか確認してください。 さらに、当社の専門家は以前の記事で同様の状況について解説しています。詳細については、 「i.MXRT1xxxがオフラインで起動しない場合は、まずSRC_SBMRxレジスタを確認してください」を参照してください。 よろしくお願いします、 カン Re: imxrt1050 bee加密后程序运行异常 すべて消去して再ダウンロードすることはできますが、見た目には何も変わっていないように見えます。 Re: imxrt1050 bee加密后程序运行异常 こんにちは、 @ccc_clive さん、 ボードのブートモードをシリアルダウンロードに変更できますか？もし可能であれば、SPTまたはMCUBootUtilitiesを使用して一括消去を実行し、イメージを再フラッシュできるかどうか確認してください。 よろしくお願いします、 カン Re: imxrt1050 bee加密后程序运行异常 暗号化後に時計の設定や変更ができなくなるような制限はありますか？

PNEV5190Bは動作しません NFC CockpitのExtraタブにある「Load Secondary Firmware」オプションからNfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.binをロードした後、PNEV5190Bが反応せず、NFC Cockpitから操作できません。 アップデートログによると、ファームウェアのダウンロードはエラー報告もなく正常に完了しました。アップデートが完了した後、ボードが応答しなくなった。 このスレッドで似たような問題を見つけましたが、根本原因を理解したいです。 ファームウェアのアップデートが成功したにもかかわらず、なぜ基板が反応しなくなるのでしょうか? 私のボードまたはファームウェアのバージョンに対して、間違ったセカンダリファームウェアイメージを使用した可能性はありますか？ なぜセカンダリファームウェアをロードすると、NFCコックピットがボードと通信できなくなる状態になるのでしょうか? 再開まで今しばらくお待ちください。 Re: PNEV5190B does not work こんにちは、 @Miyazaki001さん あなたの調子が良いといいのですが。 あなたのセットアップについてもう少し詳しく教えていただけますか?どのような手順に従っていますか？ 私は以下の設定を試してみました。 - PNEV5190B - FW v2.0B - NFC Cockpit v9.0.0 - 「追加」タブ > 「セカンダリファームウェア」タブ > セカンダリファームウェアのロード - NxpNfcCockpit_v9.0.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin を選択してください NFC Cockpitは、COMポートを閉じてから再度開くように指示するはずです。 EduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.png COMポートを再度開いた後、「Extra」タブでセカンダリファームウェアを起動できるようになります。 よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご返信よろしくお願いします。 私のシステム構成は以下のとおりです。 - PNEV5190B（B1チップ） - PN5190 FW v02.05 - NFC Cockpit v7.4 - 追加タブ → セカンダリファームウェア → セカンダリファームウェアのロード 選択済み: -NxpNfcCockpit_v7.4.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin 二次ファームウェアアップデートは正常に完了したようです。ログによると、ファームウェアのダウンロードはエラー報告なしに完了した。 ログの該当箇所を以下に示します。 20260803.png20260803.png20260803.png20260803.png20260803.png20260803.png20260803.png20260803.png アップデート後、NFC Cockpitからボード接続を手動で閉じてから再度開くように指示されます。私はこの手順に従い、さらにCOMポートを手動で切断して再接続することも試しました。 しかし、接続を再開した後、ボードはどのコマンドにも応答しなくなった。ログには、NFC Cockpitがボードとの通信を試みた際にタイムアウトが発生したことが記録されている。 参考までに、関連するログファイルを添付しました。 何かアドバイスをいただけますか: PN5190 FW v02.05は、このセカンダリファームウェアと互換性がありますか？ NFC Cockpit v7.4とこのセカンダリファームウェアに関して、既知の問題はありますか？ このスレッドで似たような問題を見つけましたが、根本原因を理解したいです。 再開まで今しばらくお待ちください。 よろしくお願いいたします。 Re: PNEV5190B does not work こんにちは、 この特定のセットアップで予期せぬ挙動が記録された例を見つけることはできませんでした。 NFC Cockpit v7.4.0は旧バージョンです。最新バージョン（v9.0.0）にアップデートし、PN5190のファームウェアアップデートを実行してください。その後、あなたの調査結果を教えてください。 設定を更新した後もこの症状が続く場合は、ジャンパーの設定と電源接続についてお知らせください（基板の写真も添付していただけると助かります）。 よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご返信よろしくお願いします。 お客様からのご意見に基づき、NFC Cockpitのバージョンを最新バージョンであるv9.0.0に変更いたしました。また、PN5190のファームウェアをv02.05からv02.0D（NXPのウェブサイトで入手可能な最新バージョン）にアップデートし、セカンダリファームウェアのアップデートを再試行しました。 しかし、結果は同じで、問題は依然として解決されていない。 画像.png画像.png画像.png画像.png画像.png画像.png画像.png画像.png 参考までに、ボードの写真も添付しました。 画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg 以下のジャンパー設定が使用されます。 J8：閉鎖 J9：2-3（外部電源） J12：閉鎖 J22：閉鎖 J23：閉鎖 このテストでは、電流制限が1Aの外部5V DC電源を使用します。 他に確認すべき設定や項目があればお知らせください。 Re: PNEV5190B does not work こんにちは、 ジャンパー設定と電源構成は問題ないようです。 もしかして、デモ用のアプリケーション(例:)をフラッシュして実行することはできますか?PN5190の NFCリーダーライブラリ で提供されているDiscoveryLoop?詳細 PNEV5190B評価ボードクイックスタートガイド、第5.3章を参照してください。 追加のテストとして、別のPCとシステム言語(ディスプレイだけでなく)を英語に設定してみていただけますか? よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、 評価ボードのクイックスタートガイドのセクション5.1 PNEV5190B述べているように、最新のNFCコックピットを使用してファームウェアの最新バージョンにアップデートすることが推奨されています。ファームウェアプログラミングには外部デバッガが必要であり、 これはNXP NFCコックピットユーザーガイド3.3節に記載されています。 残念ながら、ブートローダーバージョンとセカンダリFWバージョン間の正式な互換性マトリックスを提供する文書は存在しません。最も近い参照は 、VCOMソースパッケージ 内の バージョン変更ログ(NxpNfcCockpit_VCOM_UcBalFW\NNC_UcBalFW\phUcBal\src\NNC_uC_VCOM_Ver.h)です。 よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご返信よろしくお願いします。 ご提案いただいた方法を別途試してみます。 その間、弊社側でも追加のテストを実施し、以下の結果を得ました。 まず、J-Linkを介してNFC Cockpit v9.0.0に付属する以下のファームウェアをプログラムしました。 BootLoader_And_Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.bin その後、NFC Cockpitを使用して以下のセカンダリファームウェアをアップデートしました。 Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin この手順により、以前発生していたエラーは発生せず、アップデートは正常に完了しました。 この結果に基づき、ブートローダーとセカンダリーファームウェアのバージョン間に互換性の依存関係が存在する可能性があると推測されます。 以下の点について説明していただけますか? 1.NFC Cockpitのバージョンを変更する場合、セカンダリファームウェアだけでなく、ブートローダーも互換性のあるバージョンにアップデートする必要がありますか？ 2. NFC Cockpitを使用してブートローダーをアップデートする方法はありますか？ それとも、ブートローダーをアップデートするには、J-Linkのような外部デバッガー／プログラマーが必要なのでしょうか？ 3. 各NFCコックピットバージョンに付属するセカンダリファームウェアとブートローダーの互換性を説明するドキュメントはありますか? 例えば、どのバージョンのセカンダリファームウェアが同じブートローダーで使えるか知りたいです。 これらの疑問の背景には、私たちが解決したいと考えている別の問題も存在します。 私たちはNFC Cockpitではなく、COMポートを通じたシリアル通信を使って自社のアプリケーションからPNEV5190Bを制御しています。 NFC Cockpit v7.4.0に付属するセカンダリファームウェアを使用すると、アプリケーションはPNEV5190Bと正常に通信し制御できました。 しかし、NFC Cockpit v9.0.0に含まれるセカンダリファームウェアにアップデートした後、同じ通信方法で同じアプリケーションが通信エラーに遭遇します。 次の点についても説明していただけますか? 4. NFC Cockpit v7.4.0とv9.0.0に付属するセカンダリファームウェアの間で、初期化シーケンス、COM通信設定、通信プロトコル、コマンド仕様、または関連する動作に関して変更点はありますか？ これらの変更を説明したリリースノートやドキュメントがあれば、ぜひ共有していただけるとありがたいです。 Re: PNEV5190B does not work こんにちは、 VCOMファームウェアは、弊社のNFCコックピットツールとの併用を想定しています。別のツール用のカスタム実装を作成しようとしている場合は、 NFC Cockpit VCOMのソースコードを参考にして、ニーズに合わせて修正することを検討してください。 よろしくお願いいたします。 エドゥアルド。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご説明いただきありがとうございます。 ブートローダーを含むファームウェアのプログラミングには、外部デバッガーが必要であることを理解しています。また、BootLoaderとセカンダリファームウェアのバージョン間には正式な互換性マトリックスがなく、VCOMソースパッケージ内のバージョン変更ログが最も近い参照であることも理解しています。 他に言及した問題については、BootLoaderとセカンダリファームウェアをNFC Cockpit v9.0.0.0に更新した後、アプリケーションが正しく通信できなくなったため、追加調査を行い、DTRの取り扱いに関する違いを発見しました。 念のため説明すると、 私たちのアプリケーションは以前、NFC Cockpit v5.3に含まれるBootLoaderとセカンダリファームウェアを使って動作しており、v7.4ではありませんでした。 NFC Cockpit v5.3にBootLoaderとセカンダリファームウェアが付属しているため、COMポートを開いた後もDTRを静的にONに保つだけで、DTRの状態移行を明示的に行わずに正常に通信できました。 しかし、NFC Cockpit v9.0.0.0 に含まれる BootLoader と Secondary Firmware では、DTR を ON にするだけでは不十分です。ボードは、DTRをLOWからHIGHに明示的に切り替えた後にのみ応答を返すことがわかりました。この移行は、通信セッションの開始時に少なくとも一度は必要となるようだ。 Wiresharkを使用してUcBalPCTestApp.exeによって生成されたUSB通信をキャプチャおよび分析することにより、このDTR操作を特定しました。 以下の点について説明していただけますか? PN5190 VCOM ファームウェアにおいて、DTRのLOWからHIGHへの遷移は、通信セッションの初期化や内部バッファプロセッシングなどの内部プロセッシングのトリガーとして使われていますか?もしそうなら、この挙動はどこかで記録されていますか? VCOMファームウェアのバージョン間で、このDTRの動作が変更された可能性はありますか？特に、NFC Cockpit v5.3とv9.0.0.0に含まれるバージョン間で、DTR処理に関して何か変更はありましたか？ ホスト側でDTRをLOWからHIGHに明示的に切り替えることなく通信を開始するための、公式に推奨されている方法はありますか？例えば、特定のIOCTL、ベンダー固有のコマンド、またはその他のメカニズムなどです。 改めてサポートありがとうございます。 よろしくお願いいたします。 Re: PNEV5190B does not work こんにちは、@EduardoZamora さん。 ご説明とサポートありがとうございます。 NFCコックピットとアプリケーションの両方で同じセカンダリファームウェアを使いたいと考えています。 したがって、NFCコックピットVCOMのソースコードを参照し、現在のVCOMファームウェア動作をサポートするようにアプリケーションを修正します。 改めてサポートありがとうございます。 よろしくお願いします、 宮崎

172ピンから257ピンパッケージへの移行に関するガイダンスS32K344請求 親愛なるNXPコミュニティチームの皆様、 現在、S32 Design Studio(S32DS)を使って172ピンパッケージのS32K344ボードを制作しています。 172ピンパッケージ用に開発された同じプロジェクトやコードが、S32K344 257ピンパッケージボード上で直接使用できる のか 、 それとも変更が必要なのか知りたいです。 同じコードが直接使えない場合は、以下の点についてご指針を教えていただけますか: S32DSプロジェクトの設定とデバイス設定の うち、 どの 設定 を変更する必要がありますか？ ピン構成／ピン多重化（MUX） 設定を 変更する必要がありますか ？ Are there any changes required in the クロック、ペリフェラル、CAN、またはその他の設定に変更が必要ですか? 既存の172ピンプロジェクトを257ピンパッケージに移行する 際の推奨手順は何ですか? このパッケージ変更に関する移行手順や関連するNXPのドキュメント・リファレンスプロジェクトを教えていただけるとありがたいです。 再開まで今しばらくお待ちください。 よろしくお願いします、 アラヴィンド・トガラリ Re: Request for Guidance on Migrating S32K344 Project from 172-Pin to 257-Pin Package @VaneB さん、ありがとうございます。 Re: Request for Guidance on Migrating S32K344 Project from 172-Pin to 257-Pin Package こんにちは、 @Aravind_Togaralli さん ソフトウェアの観点から見ると、172ピンと257ピンのS32K344パッケージは、同じMCUアーキテクチャ、メモリ、ペリフェラルモジュールを使用しているため非常に似ています。主な違いは、257ピンパッケージが追加のI/Oピンを露出し、ペリフェラル信号のルーティングオプションが増える点です。 S32 Design Studioの設定ツールでは、ピンツールの設定でMCUパッケージを選択して変更することができます。 以下の例のように、両方のMCUで257ピンパッケージを用いて、すべての設定ピンとペリフェラル信号マッピングが両パッケージで利用可能であれば、プロジェクトを設定できます。 VaneB_0-1787612000573.pngVaneB_0-1787612000573.png BR、VaneB

Help - S32DS V2.2 License Expiration Issue Activation Code: C4D8-0085-8E31-1CE3 Product: S32 Design Studio for ARM v2.2 Could you help extend the validity date,Thanks! Re: Help - S32DS V2.2 License Expiration Issue Hi,  your S32DS license has been extended. Please activate S32DS again with your old code. 

NXP BMS AFE推奨事項:250 kW BESSおよびFUTURE オートモーティブ アプリケーション NXPチームの皆様、こんにちは。 現在、既存のBMSソリューションをADIからNXPベースのプラットフォームへアップグレードしようとしており、NXPが提供するAFEオプションを探ることにワクワクしています。 私たちは以下のシステムアーキテクチャを持つ250 kWのBESSアプリケーションを開発しています。 システム構成： 5S1P モジュールあたりのセル構成： 52S BMSアーキテクチャ：マスタースレーブ 設計最終決定の一環として、NXPのBMS AFEポートフォリオを評価し、以下の機器を絞り込みました。 BMA7418 BMA7118 BMI7018 これらのデバイスを当社のアプリケーション要件に照らし、当社の設計に最適なデバイスを推奨する際の、NXPチームの技術的な指導をいただけると大変ありがたいです。 当社の主な選定基準 AFEを選定する際の主な考慮事項は以下のとおりです。 コスト効率 – BESSアプリケーションにおいて、このソリューションは商業的に競争力を持つべきです。 ソフトウェアサポート – サンプルコード、ドライバ、リファレンスファームウェア、開発リソースの入手可能性は大きな利点となります。これらのリソースがあれば、評価を加速させ、開発時間を短縮できるでしょう。 自動車再利用性 – 理想的には、FUTUREの自動車BMSアプリケーション(ASIL-B)向けに同じAFEプラットフォームを活用したいと考えています。同じハードウェアとソフトウェアプラットフォームを再利用することで、BESSの開発を基盤に構築でき、ファームウェア開発の労力と時間を大幅に削減できます。 スケーラビリティ – 選ばれたデバイスは、同じBMSアーキテクチャを異なるバッテリー構成やアプリケーションでスケーリングする実用的な道筋を提供するべきです。 私たちの目標は、AFE（承認申請書）を最終決定し、できるだけ早く詳細なハードウェアおよびファームウェア開発に移行することです。したがって、最適なデバイスに関するご提案や、関連するリファレンス・デザイン、評価ボード、アプリケーションノート、サンプルソフトウェア、推奨される開発手法などをご存知いただけると非常に価値があります。 推奨を行うにあたり、当社のシステムアーキテクチャ、セル構成、電圧範囲、通信要件、またはBMS機能に関する追加情報が必要な場合は、喜んで詳細をご提供いたします。 NXPベースのBMSプラットフォームでの展開に非常に関心があり、皆様からの貴重な技術的なご指導を楽しみにしています。 サポートにあらかじめ感謝いたします。 よろしくお願いいたします。 サントゥR #hvbms #バッテリー・セルコントローラ Re: NXP BMS AFE Recommendation for 250 kW BESS and Future Automotive Applications 産業用途がない場合は、BMI7018を主要なAFEとして使用することを推奨します。各52Sモジュールには3つのBMI7018が必要で、パック電流測定はMC33777A/BJB電流検出センシング・ソリューションを用いて別途実装されます。 自動適用の場合: guoweisun_0-1787535685716.pngguoweisun_0-1787535685716.png    

PNEV5190B does not work After loading Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin from the "Load Secondary Firmware" option on the Extra tab of NFC Cockpit, my PNEV5190B no longer responds and cannot be operated from NFC Cockpit. According to the update log, the firmware download completed successfully without any reported errors. The board became unresponsive only after the update was finished. I found a similar issue in this thread, but I would like to understand the root cause. What could cause the board to become unresponsive even though the firmware update completed successfully? Is it possible that I used an incorrect secondary firmware image for my board or firmware version? Why does loading the secondary firmware result in a state where NFC Cockpit can no longer communicate with the board? Thank you for your support. Re: PNEV5190B does not work Hello @Miyazaki001 Hope you are doing well. Could you please provide more details on your setup? What is the procedure you are following? I tried the following setup: - PNEV5190B - FW v2.0B - NFC Cockpit v9.0.0 - "Extra" tab > "Secondary FW" tab > Load Secondary Firmware - Select NxpNfcCockpit_v9.0.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin NFC Cockpit should indicate to close the COM port and open it again: EduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.pngEduardoZamora_1-1785953100786.png After reopening the COM port, you should be able to start the Secondary Firmware in "Extra" tab. Regards, Eduardo. Re: PNEV5190B does not work Hi @EduardoZamora, Thank you for your reply. My setup is as follows: - PNEV5190B (B1 chip) - PN5190 FW v02.05 - NFC Cockpit v7.4 - Extra tab → Secondary FW → Load Secondary Firmware Selected: -NxpNfcCockpit_v7.4.0.0\firmware\Secondary_PN5190\K8x\Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin The secondary firmware update appears to complete successfully. According to the log, the firmware download finishes without any reported errors. The relevant part of the log is shown below. 20260803.png20260803.png20260803.png20260803.png20260803.png20260803.png20260803.png20260803.png After the update, NFC Cockpit prompts me to manually close and reopen the Board Connection. I followed this procedure, and I also tried disconnecting and reconnecting the COM port manually. However, after reopening the connection, the board no longer responds to any commands. The log shows a timeout when NFC Cockpit attempts to communicate with the board. I have attached the relevant log for your reference. Could you please advise: - Is PN5190 FW v02.05 compatible with this secondary firmware? - Is there any known issue with NFC Cockpit v7.4 and this secondary firmware? I found a similar issue in this thread, but I would like to understand the root cause. Thank you for your support. Best regards, Re: PNEV5190B does not work Hi, I could not locate any documented instance for an unexpected behavior using this specific setup. NFC Cockpit v7.4.0 is outdated; please update to the latest version available (v9.0.0) and perform FW update on PN5190. After this, let me know your findings. If this behavior persists after updating your setup, please let me know your jumper configuration and power connections (a picture of your board would also be helpful). Regards, Eduardo. Re: PNEV5190B does not work Hi @EduardoZamora, Thank you for your reply. Based on your comment, we changed the NFC Cockpit version to the latest version, v9.0.0. We also updated the PN5190 firmware from v02.05 to v02.0D, which is the latest version available on the NXP website, and then retried the Secondary Firmware update. However, the result was the same, and the issue still persists. 画像.png画像.png画像.png画像.png画像.png画像.png画像.png画像.png We have also attached a photo of the board for reference. 画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg画像.jpg The following jumper settings are used: J8: Closed J9: 2–3 (External power supply) J12: Closed J22: Closed J23: Closed For this test, we are using an external 5 V DC power supply with a current limit of 1 A. Please let us know if there are any other settings or points we should check. Re: PNEV5190B does not work Hi, Your jumper and power configuration seems to be ok. By any chance, are you able to flash and run any of the demo applications (e.g. DiscoveryLoop) provided in the NFC Reader Library for PN5190? You can refer to PNEV5190B evaluation board quick start guide, Chapter 5.3, for more information on this. As an additional test, could you please try using a different PC and system language (not only display) set to English? Regards, Eduardo. Re: PNEV5190B does not work Hi, As mentioned in PNEV5190B evaluation board quick start guide, Section 5.1, it is recommended updating to the latest version of the firmware, using the latest version of the NFC Cockpit. An external debugger is necessary for the firmware programming, as described in NXP NFC Cockpit User Guide, Section 3.3. Unfortunately, there is no document available that provides a formal compatibility matrix between Bootloader versions and Secondary FW versions. The closest available reference is the version changelog inside the VCOM source package (NxpNfcCockpit_VCOM_UcBalFW\NNC_UcBalFW\phUcBal\src\NNC_uC_VCOM_Ver.h). Regards, Eduardo. Re: PNEV5190B does not work Hi @EduardoZamora, Thank you for your reply. We will separately try the method you suggested. In the meantime, we performed an additional test on our side and obtained the following result. First, we programmed the following firmware included with NFC Cockpit v9.0.0 via J-Link: BootLoader_And_Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.bin After that, we updated the following Secondary Firmware using NFC Cockpit: Nfcrdlib_SimplifiedAPI_EMVCo_Secondary.nnc.bin With this procedure, the error we had previously encountered did not occur, and the update completed successfully. Based on this result, we suspect that there may be a compatibility dependency between the BootLoader and Secondary Firmware versions. Could you please clarify the following points? 1. When changing the NFC Cockpit version, is it necessary to update not only the Secondary Firmware but also the BootLoader to a compatible version? 2. Is there a way to update the BootLoader using NFC Cockpit? Or is an external debugger/programmer such as J-Link required to update the BootLoader? 3. Is there any documentation describing the compatibility between the Secondary Firmware and BootLoader included with each NFC Cockpit version? For example, we would like to know which versions of the Secondary Firmware can be used with the same BootLoader. There is also another issue behind these questions that we would like to resolve. We have been controlling the PNEV5190B from our own application, rather than NFC Cockpit, using serial communication through the COM port. When using the Secondary Firmware included with NFC Cockpit v7.4.0, our application was able to communicate with and control the PNEV5190B successfully. However, after updating to the Secondary Firmware included with NFC Cockpit v9.0.0, the same application using the same communication method encounters a communication error. Could you also please clarify the following point? 4. Are there any changes between the Secondary Firmware included with NFC Cockpit v7.4.0 and v9.0.0 regarding the initialization sequence, COM communication settings, communication protocol, command specifications, or related behavior? If there are any release notes or documents describing these changes, we would appreciate it if you could share them with us. Re: PNEV5190B does not work Hi @EduardoZamora, Thank you for your clarification. We understand that an external debugger is required to program the firmware, including the BootLoader. We also understand that there is no formal compatibility matrix between BootLoader and Secondary Firmware versions, and that the version changelog in the VCOM source package is the closest available reference. Regarding the other issue we mentioned, where our application could no longer communicate properly after updating the BootLoader and Secondary Firmware to the versions included with NFC Cockpit v9.0.0.0, we performed some additional investigation and found a difference related to DTR handling. For clarification, our application had previously been working with the BootLoader and Secondary Firmware included with NFC Cockpit v5.3, not v7.4. With the BootLoader and Secondary Firmware included with NFC Cockpit v5.3, our application was able to communicate successfully by simply keeping DTR statically ON after opening the COM port, without any explicit DTR state transition. However, with the BootLoader and Secondary Firmware included with NFC Cockpit v9.0.0.0, simply keeping DTR ON is not sufficient. We found that the board returns a response only after explicitly toggling DTR from LOW to HIGH. It appears that this transition is required at least once at the beginning of the communication session. We identified this DTR operation by capturing and analyzing the USB communication generated by UcBalPCTestApp.exe using Wireshark. Could you please clarify the following points? In the PN5190 VCOM Firmware, is the LOW-to-HIGH transition of DTR used as a trigger for any internal processing, such as communication session initialization or internal buffer handling? If so, is this behavior documented anywhere? Is it possible that this DTR behavior changed between VCOM Firmware versions? In particular, were there any changes related to DTR handling between the versions included with NFC Cockpit v5.3 and v9.0.0.0? Is there any officially recommended way to initiate communication without explicitly toggling DTR from LOW to HIGH on the host side, such as a specific IOCTL, vendor-specific command, or other mechanism? Thank you again for your support. Best regards, Re: PNEV5190B does not work Hi, The VCOM FW is intended for usage with our NFC Cockpit tool. If you are trying to create a custom implementation for a different tool, please consider using the NFC Cockpit VCOM source code as reference and adapt it to your needs. Regards, Eduardo. Re: PNEV5190B does not work Hi @EduardoZamora, Thank you for your clarification and support. We would like to use the same Secondary Firmware with both NFC Cockpit and our application. Therefore, we will refer to the NFC Cockpit VCOM source code and modify our application to support the current VCOM Firmware behavior. Thank you again for your support. Best regards, Miyazaki

求助 - S32DS V2.2 许可证到期问题 激活码：C4D8-0085-8E31-1CE3 产品：S32 Design Studio for ARM v2.2 请问能否帮忙延长有效期？谢谢！ Re: Help - S32DS V2.2 License Expiration Issue 你好， 您的S32DS许可证已延期。请使用您之前的激活码重新激活S32DS。

NXP BMS AFE Recommendation for 250 kW BESS and Future Automotive Applications Hello NXP Team, We are currently looking to upgrade our existing BMS solution from ADI to an NXP-based platform and are excited to explore the AFE options available from NXP. We are developing a 250 kW BESS application with the following system architecture: System Configuration: 5S1P Cell Configuration per Module: 52S BMS Architecture: Master–Slave As part of our design finalization, we are evaluating NXP's BMS AFE portfolio and have shortlisted the following devices: BMA7418 BMA7118 BMI7018 We would greatly appreciate the NXP team's technical guidance in evaluating these devices against our application requirements and recommending the most suitable device for our design. Our Key Selection Criteria Our primary considerations for selecting the AFE are: Cost-effectiveness – The solution should be commercially competitive for BESS applications. Software support – Availability of example code, drivers, reference firmware, and development resources would be a significant advantage. Having these resources would help us accelerate evaluation and reduce development time. Automotive reusability – We would ideally like to use the same AFE platform for future automotive BMS applications targeting ASIL-B. Reusing the same hardware and software platform would allow us to build on the BESS development and significantly reduce firmware development effort and time. Scalability – The selected device should provide a practical path for scaling the same BMS architecture across different battery configurations and applications. Our objective is to finalize the AFE and move into detailed hardware and firmware development as soon as possible. Therefore, your recommendation regarding the most suitable device, along with any relevant reference designs, evaluation boards, application notes, example software, or recommended development approach, would be extremely valuable. If you need any additional information regarding our system architecture, cell configuration, voltage range, communication requirements, or BMS functionality to make the recommendation, we would be happy to provide the details. We are very interested in moving forward with an NXP-based BMS platform and look forward to your valuable technical guidance. Thank you in advance for your support. Regards, Santu R #hvbms #battery-cell-controller Re: NXP BMS AFE Recommendation for 250 kW BESS and Future Automotive Applications For No Industerial application Recommend using BMI7018 as the primary AFE; each 52S module requires three BMI7018s, with pack current measurement implemented separately using the MC33777A/BJB current sensing solution. For automatic application: guoweisun_0-1787535685716.pngguoweisun_0-1787535685716.png    

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.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 嗨，雪莉， 非常感谢您的详细解答！ 顺祝商祺！ 马可 Re: RIOP RT1189 – build and flash workflow from GitHub sources 嗨，雪莉， 以下是后续内容： RIOP 存储库不包含 riop_M7FOLLOWER_DEMO/scripts/image_hash_tool.py，而原始项目有条件地调用了它。RIOP 多核演示中是否故意缺少辅助函数？如果可以，VS Code 项目转换器能否在 Windows 上保留原有的“如果不存在则跳过”行为，而不是生成失败的 cmd.exe 命令？如果不是有意为之，那么预期的 image_hash_tool.py 文件在哪里提供？在用 SPT 处理 M33 图像之前是否需要该文件？ 顺祝商祺！ 马可

Request for Guidance on Migrating S32K344 Project from 172-Pin to 257-Pin Package Dear NXP Community Team, I am currently working on an S32K344 board with a 172-pin package using S32 Design Studio (S32DS). I would like to know whether the same project/code developed for the 172-pin package can be directly used on an S32K344 257-pin package board, or whether any changes are required. If the same code cannot be used directly, could you please provide guidance on the following: Which S32DS project configurations and device settings need to be changed? Do we need to modify the pin configuration / pin multiplexing (MUX) settings? Are there any changes required in the clock, peripheral, CAN, or other configuration settings? What are the recommended steps to migrate an existing 172-pin project to the 257-pin package? I would appreciate it if you could provide the migration procedure or any relevant NXP documentation/reference project for this package change. Thank you for your support. Best regards, Aravind Togaralli Re: Request for Guidance on Migrating S32K344 Project from 172-Pin to 257-Pin Package Thank you @VaneB  Re: Request for Guidance on Migrating S32K344 Project from 172-Pin to 257-Pin Package Hi @Aravind_Togaralli  From a software perspective, the 172-pin and 257-pin S32K344 packages are very similar because they use the same MCU architecture, memory, and peripheral modules. The main difference is that the 257-pin package exposes additional I/O pins and provides more options for routing peripheral signals.  In S32 Design Studio Config Tools, it is possible to select and change the MCU package in the Pin Tool configuration. As shown in the example below, you can configure the project using the 257-pin package for both MCUs, provided that all configured pins and peripheral signal mappings are available in both packages.  VaneB_0-1787612000573.pngVaneB_0-1787612000573.png BR, VaneB

The program malfunctioned after encryption with imxrt1050 bee. The program is simply a timer program that makes an LED blink. It runs normally on an unencrypted board, but it doesn't run on an encrypted board after encryption. I don't know how to troubleshoot this. The J-Link can't connect either, making troubleshooting even more difficult. I'm using AXF or HEX image files. In the program used by FDCB, because the DQS pin is used, QSPI is set to 50M, and CSStepUp/Hold is set to 2. Snipaste_2026-08-19_11-10-50.pngSnipaste_2026-08-19_11-10-50.pngSnipaste_2026-08-19_11-10-50.png Snipaste_2026-08-19_11-11-26.pngSnipaste_2026-08-19_11-11-26.pngSnipaste_2026-08-19_11-11-26.png Snipaste_2026-08-19_11-12-16.pngSnipaste_2026-08-19_11-12-16.pngSnipaste_2026-08-19_11-12-16.png i.MXRT 105x Re: imxrt1050 bee加密后程序运行异常 Hi @ccc_clive , I noticed you're using OTPMK, which is the SNVS key, as the key. However, this key is only valid when HAB is closed; otherwise, it's all zeros. Try the signed encrypted XIP mode to see if you get a different result. Additionally, our experts have discussed similar situations in previous articles; for details, please refer to "If i.MXRT1xxx fails to start offline, please first check the SRC_SBMRx register". Best Regards, Kan Re: imxrt1050 bee加密后程序运行异常 You can erase everything and re-download, but it won't look like anything has changed. Re: imxrt1050 bee加密后程序运行异常 Hi @ccc_clive , Can you change the board's boot mode to serial download? If so, use SPT or MCUBootUtilities to perform a mass erase and see if you can re-flash the image. Best Regards, Kan Re: imxrt1050 bee加密后程序运行异常 Is there a limitation that prevents the clock from being configured and modified after encryption?