Request to extend expired license for S32 Design Studio for ARM v2.2 Hello NXP License Team, My S32 Design Studio for ARM v2.2 license will expire and I would like to continue using it. Both the License Expiration and the Entitlement Expiration dates show July 5, 2026, so the entitlement itself will expire and re-activating with the existing activation code no longer produces a valid license. Could you please extend the entitlement so that I can re-activate? Details below: Product: S32 Design Studio for ARM v2.2 Activation Code: CCB1-BEC2-FF96-4859 Thank you very much for your great help.       Re: Request to extend expired license for S32 Design Studio for ARM v2.2 Hi,  your S32DS license has been extended. Please activate S32DS again with your old code.  Re: Request to extend expired license for S32 Design Studio for ARM v2.2 Hello NXP License Team, Thansks for your help. However, My S32DS License details is still  "Evaluation" Coudl you please check it again. Thanks for your great support. S32 Design Studio for ARM ActivationId: CCB1-BEC2-FF96-4859 Evaluation Days: 20 Feature Version: 2.2 Feature Status: Evaluation (20 days) Re: Request to extend expired license for S32 Design Studio for ARM v2.2 Hi, I've been re-compiled my code code with S32DS ARM 2.2 However, my S32DS ARM 2.2 license is still not extened. Does anyone can help me? 回复： Request to extend expired license for S32 Design Studio for ARM v2.2 Hi，    Request to extend expired license for S32 Design Studio for ARM v2.2，tks Tony_lv_1-1789897641124.png

सीखो अप में शिकायत कैसे दर्ज करें Shikho shikayat Karen 9279-187863 sikho app शिकायत दर्ज करें9279-187863 सीखो अप का तुरंत समाधान, क्योंकि हर कंपनी जुड़ी है राष्ट्रीय उपभोक्ता हेल्पलाइनसेशिकायतदर्जकरनेकेलिए，कॉलकरें उपभोक्ता हेल्पलाइन पर या व्हाट्सएप नंबर पर SMS भेजें।   Re: सीखो अप में शिकायत कैसे दर्ज करें Shikho shikayat Karen 9279-187863 sikho app शिकायत दर्ज करें9279-187863 सीखो अप का तुरंत समाधान, क्योंकि हर कंपनी जुड़ी है राष्ट्रीय उपभोक्ता हेल्पलाइनसेशिकायतदर्जकरनेकेलिए，कॉलकरें उपभोक्ता हेल्पलाइन पर या व्हाट्सएप नंबर पर SMS भेजें।  

S32 Design Studio for ARM v2.2の期限切れライセンスの延長をリクエストします NXPライセンスチームの皆様、こんにちは。 私のS32 Design Studio for ARM v2.2のライセンスが期限切れになるので、引き続き使用したいと考えています。ライセンスの有効期限と使用権の有効期限の両方が2026年7月5日となっているため、使用権自体が期限切れとなり、既存のアクティベーションコードを使用して再アクティベートしても有効なライセンスは生成されなくなります。 再有効化できるように、利用期間を延長していただけませんか？詳細は以下の通りです。 製品：S32 Design Studio for ARM v2.2 アクティベーションコード：CCB1-BEC2-FF96-4859 大変お世話になりました。ありがとうございました。       Re: Request to extend expired license for S32 Design Studio for ARM v2.2 こんにちは、 お客様のS32DSライセンスが延長されました。以前使用していたコードを使って、S32DSを再度有効化してください。 Re: Request to extend expired license for S32 Design Studio for ARM v2.2 NXPライセンスチームの皆様、こんにちは。 ご協力ありがとうございました。しかし、私のS32DSライセンスの詳細は依然として「評価版」となっています。 もう一度確認していただけますか？多大なサポートをありがとうございました。 Arm向けS32 Design Studio アクティベーションID: CCB1-BEC2-FF96-4859 評価日数：20日 機能バージョン: 2.2 機能ステータス：評価中（20日間） Re: Request to extend expired license for S32 Design Studio for ARM v2.2 こんにちは、 コードコードをS32DS ARM 2.2で再コンパイルしました しかし、私のS32DS ARM 2.2ライセンスはまだ延長されていません。 どなたか助けてくれませんか? 回复： Request to extend expired license for S32 Design Studio for ARM v2.2 こんにちは、 S32 Design Studio for ARM v2.2,tksのライセンス延長申請 Tony_lv_1-1789897641124.png

P3H2840のデバッグに関する相談 現在、公式のP3H2840デモを基にデバッグを行っているのですが、デモにおける温度センサーの読み取り値がI2CモードとI3Cモードで異なることが分かりました（下図参照）。これは正常な動作でしょうか？ Re: p3h2840调试问题咨询 こんにちは、 I3Cモードレジスタの読み取り時に毎回表示される 0xff という2番目のバイトは正しくなく、ハブ構成の問題を示しています。参考までに、P3H2x4xHN-ARDの搭載温度センサーはNXP P3T1755DP デバイスで、完全にI3C対応なので、ハブが正しく設定されれば両方のモードで測定値は同じになるはずです。 以下の3項目をご確認ください。 動的アドレス割り当て— P3T1755DPはI2Cモードで起動し、I3Cプライベート転送が機能する前に動的アドレス（ENTDAA、SETAASA、またはSETDASA経由）を受信する必要があります。この段階が完了する前に i3c_xfer が呼び出されると、デバイスはI3Cフレームに正しく応答できず、2バイト目は 0xff と読み取られます。アドレス割り当てCCCが正常に実行され、0x4cが割り当てられた動的アドレスであることを確認してください。 バースト長有効化 — REG#17[6] (BL_ENABLE) — このビットが設定されている場合、I3C 書き込みフェーズにはレジスタポインタの後にバースト長バイトを含める必要があります。 i3c_xfer 呼び出しで書き込みバイト (レジスタ アドレス) が 1 つしか送信されない場合、ハブは不完全なフレームを受信し、読み取り応答のアライメントがずれるため、2 バイト目に 0xff が発生します。REG#17を読み返して、ビット6がセットされているかどうかを確認してください。もしそうであれば、書き込みペイロードにBLバイトを追加するか、必要ない場合はBL_ENABLEをクリアしてください。 ターゲットポートVCCIO — REG#22 — I3Cモードでは、ターゲットポートはREG#22のVCCIO設定を参照するプッシュプル駆動レベルを使用します。これが実際のP3T1755DP供給電圧と一致しない場合、プッシュプルモードで転送されたデータバイトが破損することがあります。REG#22がセンサーが接続されているターゲットポートの正しい動作電圧を反映しているか確認してください。 Re: p3h2840调试问题咨询 ご返信ありがとうございます。どうやらデバイスがSETAASAに対応していなかったようです。SETDASAに変更してI3Cインターフェースを入力したところ、正常に動作しました。ご協力ありがとうございました。

请求延长适用于 ARM v2.2 的 S32 Design Studio 的过期许可证 你好，恩智浦许可证团队、 我的 S32 Design Studio for ARM v2.2 许可证将过期，我想继续使用它。许可证过期日期和权利过期日期均显示为 2026 年 7 月 5 日，因此权利本身也将过期，使用现有激活代码重新激活将不再生成有效许可证。 能否请您延长权利期限，以便我重新激活？详情如下： 产品：适用于 ARM 的 S32 设计工作室 v2.2 激活码：CCB1-BEC2-FF96-4859 非常感谢你们的大力帮助。       Re: Request to extend expired license for S32 Design Studio for ARM v2.2 你好，  您的 S32DS 许可证已延长。请使用旧代码重新激活 S32DS。 Re: Request to extend expired license for S32 Design Studio for ARM v2.2 NXP 许可团队您好， 感谢您的帮助。不过，我的 S32DS 许可证详细信息仍然是："Evaluation" 请您再次核对一下。感谢您的鼎力支持。 适用于 ARM 的 S32 设计工作室 激活ID：CCB1-BEC2-FF96-4859 试用天数：20 功能版本：2.2 功能状态：试用（20天） Re: Request to extend expired license for S32 Design Studio for ARM v2.2 您好， 我已经使用 S32DS ARM 2.2重新编译了我的代码。 但是，我的 S32DS ARM 2.2许可证仍然没有延期。 请问有人能帮帮我吗？ 回复： Request to extend expired license for S32 Design Studio for ARM v2.2 你好， 请求延长 S32 Design Studio for ARM v2.2 的过期许可证，谢谢。 Tony_lv_1-1789897641124.png

P3H2840 debugging issues consultation Currently, I'm debugging based on the official P3H2840 demo and found that the temperature sensor readings on the demo differ between I2C and I3C modes (as shown in the image below). Is this normal? Re: p3h2840调试问题咨询 Hi, The 0xff second byte you are seeing on every I3C mode register read is not correct and points to a hub configuration issue. For reference, the on-board temperature sensors on the P3H2x4xHN-ARD are NXP P3T1755DP devices, which are fully I3C-capable, so the readings should be identical in both modes once the hub is correctly set up. Please check the following three items: Dynamic address assignment — The P3T1755DP powers up in I2C mode and must receive a dynamic address (via ENTDAA, SETAASA, or SETDASA) before I3C private transfers will work. If i3c_xfer is called before this step completes, the device cannot respond correctly to I3C frames, and the second byte will read as 0xff . Confirm that the address assignment CCC ran successfully and that 0x4c is the assigned dynamic address. Burst Length enable — REG#17[6] (BL_ENABLE) — If this bit is set, the I3C write phase must include a Burst Length byte after the register pointer. If your i3c_xfer call sends only 1 write byte (register address), the hub receives an incomplete frame and the read response is misaligned, causing 0xff on the second byte. Please read back REG#17 and confirm whether bit 6 is set. If it is, either add the BL byte to your write payload or clear BL_ENABLE if it is not needed. Target port VCCIO — REG#22 — In I3C mode the target port uses push-pull drive levels referenced to the VCCIO setting in REG#22. If this does not match the actual P3T1755DP supply voltage, data bytes transferred in push-pull mode can be corrupted. Please confirm that REG#22 reflects the correct operating voltage for the target port the sensor is connected to. Re: p3h2840调试问题咨询 Thank you for your reply. It seemed the device didn't support SETAASA. After changing it to SETDASA and entering the I3C interface, it worked correctly. Thank you for your support.

シコアプリメインシカヤットカイセカレン Shikho shikayat Karen 9279-187863 sikho app शिकायत दर्ज करें का तुरंत समाधान、ログイン して翻訳を追加するउपभोक्ता हेल्पलाइन से  शिकायत दर्ज करने के लिए, कॉल करें उपभोक्ता SMS メッセージの送信   Re: Sikho app mein shikayat kaise karen Shikho shikayat Karen 9279-187863 sikho app शिकायत दर्ज करें का तुरंत समाधान、ログイン して翻訳を追加するउपभोक्ता हेल्पलाइन से शिकायत दर्ज करने के लिए, कॉल करें उपभोक्ता SMS メッセージの送信  

信頼できるオンラインリソースのフリーソフトウェアに関するアドバイスが必要です こんにちは、皆さん サイバーセキュリティ、ワイヤレスネットワーキング、ウェブサイト開発ソフトウェアに関する信頼できるオンラインリソースを探しています。特に、ウェブサイト最適化、ネットワーキング、デジタルセキュリティ、オンライン生産性のためのソフトウェアソリューション thefreetech.com が選択肢の一つだと聞いたことがありますが、他の人気プラットフォームと比べてどうか気になっています。最近使った人はいますか？どれくらい正確で使いやすいですか?何かご意見、アドバイス、代替案などがあれば、ぜひ教えてください！ よろしくお願いいたします！

NXPはSonic OSをサポートするMPUを製造していますか？ こんにちは、NXPさん、 SONIC OSをサポートできるプロセッサが必要です。 NXPのウェブサイトでそのメッセージが見つかりません。 もう一度確認するのを手伝ってもらえますか? どうもありがとうございました。 i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Does NXP has MPU supporting sonic OS ? こんにちは、志明さん わかった。 ありがとうございました。 Re: Does NXP has MPU supporting sonic OS ? こんにちは@jimmyli  NXPは公式にSONIC OSをサポートしていません。 敬具 志明

I.MX6ULL ENET1 无法从物理层接收数据 I.M6ULL + 4.19.35 + KSZ 8081rnb  我们现场部署了300台这种设备。大多数情况下它们都能正常运行，业务/服务也能按预期运作。然而，我们偶尔会发现服务无法访问。经调查，我们发现 eth1 (ENET1) 停止接收数据包，即使其 LINK LED 指示灯常亮，ACT LED 指示灯有时闪烁。 此外，我们还验证了在 ENET1 上拔下并重新插入以太网电缆一次后，网络恢复正常。重启设备也能恢复它。请您帮忙分析一下可能的根本原因——是在物理层（PHY）还是媒体访问控制层（MAC）？ 从该寄存器读取的值如下： 我们读取的寄存器列表包括 MAC 寄存器和 PHY 寄存器。由于篇幅较长，全文列于下一页。 命令： phy eth1 0x1读取 PHY 寄存器 1。 内存工具 i.MX6UL Linux

सीखो अप में शिकायत कैसे दर्ज करें Shikho shikayat Karen 9279-187863 sikho app शिकायत दर्ज करें9279-187863 सीखो अप का तुरंत समाधान、क्योंकि हर कंपनी जुड़ी है राष्ट्रीय उपभोक्ताログイン して翻訳を追加するログイン して翻訳を追加するSMS メッセージ   Re: सीखो अप में शिकायत कैसे दर्ज करें Shikho shikayat Karen 9279-187863 sikho app शिकायत दर्ज करें9279-187863 सीखो अप का तुरंत समाधान、क्योंकि हर कंपनी जुड़ी है राष्ट्रीय उपभोक्ताログイン して翻訳を追加するログイン して翻訳を追加するSMS メッセージ  

S32K344 HSE_ActivatePassiveBlock 後のAB-Swap車載起動失敗;ファームウェアはJ-Link Staでのみ起動します プラットフォーム:ABスワップ方式S32K344。ファームウェアイメージは、アクティブブロックとパッシブブロックにそれぞれ別々に格納されています。観察結果：HSE_ActivatePassiveBlock()を実行してアクティブ/パッシブパーティションを交換した後、完全な電源サイクルを実行しても、ファームウェアの自動起動はトリガーされません。ファームウェアはJ-Linkが接続され、デバッガから「アプリケーションの開始」がトリガーされた場合にのみ正常に動作します。誰か根本原因を説明し、推奨される対処法を教えていただけませんか? Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link こんにちは、 @HQZ パッシブパーティションに有効なイメージが存在することを確認しましたか？電源投入後にリセットせずに実行中のターゲットにデバッガーを接続すると、どのような現象が観察されますか？デバイスはJTAGリカバリーモードに入りましたか？あるいは、デバッガでデバイスをリセットしてから、アプリケーションのエントリーポイントに到達したかを確認することもできます。 デバイスがアドレス0x2040012Cで無限ループに陥っている場合、JTAGリカバリモードに入ったことを示しています。これはIVTの設定やIVTの整合性に問題がある可能性もあります。 また、パッシブパーティション内のイメージは、アクティブパーティションのアドレス空間（つまり、0x00400000から始まるアドレス空間）から実行されるようにリンクされていますか？ 最後に、セキュアブートを使用していますか？ よろしくお願いいたします。 ルーカス Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link こんにちは@lukaszadrapa  プラットフォーム:S32K344、AB-Swapアーキテクチャ。独立したファームウェアイメージはアクティブブロックとパッシブブロックに別々に保存されます。HSEのセキュアブートは無効になっています。問題の説明:アクティブ/パッシブパーティションスイッチを完了するためにHSE_ActivatePassiveBlock()を呼んだ後、電源を入れ直してリセットした後、デバイスはターゲットファームウェアを自動で起動できません。しかし、J-Linkデバッガがチップにコネクテッドされていて、デバッガソフトウェア内で「アプリケーション開始」をクリックすると、交換したファームウェアは通常通り動作します。追加の背景:ファームウェアはパーティションAとパーティションBの両方に存在します。両画像の違いはLEDの点滅周波数だけです。パーティションAのファームウェアは0x400000からリンクされ、パーティションBのファームウェアは0x600000からリンクされています。HSE_ActivatePassiveBlock()を呼び出してリセットした後、J-Linkでフラッシュの内容をダンプしました。パーティションAとパーティションBの内容が物理的に入れ替わっており、HSE_ActivatePassiveBlock()が有効であることが確認されています。質問:1. この行動の根本原因は何でしょうか?なぜコールド電源起動はデバッガーでトリガーされる「アプリケーションの開始」と異なる挙動をするのでしょうか?2. ABパーティションスワップ後の自動起動失敗を解決できる現実的な解決策は何ですか?ご支援ありがとうございます。 [[ ## completed ##]] Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link こんにちは、 @HQZ 「パーティション B のファームウェアが 0x600000 からリンクされている」 - これが問題です。アクティブなパーティションアドレス（0x400000）を使用するには、両方のイメージがリンクされている必要があります。アプリケーションは常にアクティブパーティションから動作しており、パッシブパーティションからではありません。 解決策：両方のプロジェクトで同じリンカーファイルを使用する。 これはデバッガと連携して動作します。なぜなら、デバッガはプログラムカウンタをELFファイル内のエントリポイントアドレスに「手動で」設定するからです。 よろしくお願いいたします。 ルーカス Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link こんにちは、 @lukaszadrapa 以前の提案に従ってABパーティションのスワップを試してみましたが、問題は依然として解決していません。 使用されているHSEファームウェアのバージョンはs32k344_hse_fw_1.5.0_2.40です。 ABスワップ検証のためのテスト設定： アプリケーションベースの自己更新機能を備えた単一のリンカースクリプト。アプリケーションは新しいファームウェアイメージをパッシブパーティションにプログラムする責任を負います。 リンカースクリプト: リンカースクリプトは1つだけ使用され、ファームウェアの開始アドレスは常に0x00400000に設定されます。 ワークフロー: 1.パーティションA(論理アドレス0x00400000)で動作するアプリケーションは、CANを通じて新しいファームウェアを受け取ります。パーティションAとパーティションBのファームウェアの唯一の違いは、LEDの点滅頻度です。 2. アプリケーションは新しいファームウェアをパッシブパーティション(0x00600000)の物理アドレスに直接プログラムします。 3.プログラミングが完了すると、HSE_ActivatePassiveBlock() サービスが呼び出されます。 4．その後、チップがリセットされます。 観察： ファームウェアがリセット後に起動しない。しかし、J-Linkが接続され、デバッガから「アプリケーション開始」がトリガーされると、パーティションBのファームウェアは正しく動作します。 パーティションスワップの失敗を引き起こす他の根本原因や、対応する解決策は何でしょうか? よろしくお願いいたします Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link 返信が遅くなり申し訳ありません。 以下に、よくある問題点をいくつか挙げます。 HSE_ActivatePassiveBlock() を実行してデバイスをリセットすると、HSE が新しいサービス要求を受け入れる準備が整うまでに約 1 秒かかります。それは、HSEがHSEファームウェアのバックアップをパッシブパーティションに保存するためです。操作が完了すると、FSRレジスタのHSE_STATUS_INIT_OKフラグが設定されます。そのため、HSEが完成するまでは利用できません。時として、これがトラブルの原因となる。 これはファームウェアバージョン0.2.55.0以降で最適化されており、ファームウェアは更新された場合にのみパッシブパーティションにコピーされます。もし状況が変わらなければ、HSEはこの作業を省略し、交換作業ははるかに迅速に行われます。 それならHSEファームウェアのリファレンスマニュアルの説明を読むことをお勧めします。2.7節： 「14.6.5HSEとアプリケーションコア間のフラッシュ読み書きアクセスの同期」: https://www.nxp.com/webapp/sd/collateral/1765990353647716033651?version=2.7 表149、150、151には典型的なシナリオの詳細が記載されています。 あなたの場合、HSEがパッシブパーティションにバックアップを取ると、HSEがそのブロックに対してフラッシュ操作を行うため、フラッシュブロック3にアクセスできません。 また、ブロック1ではHSEファームウェアがこのブロックから動作しているため、フラッシュ操作はできません。 もう一つ注意すべき点は、HSEが実行されている場合、HSE_CLKを変更できないということです。リセット後約1秒でHSEが稼働している場合、これは交換後に問題になることがあります。 HSE_CLOCKを変更する際は、HSEがアイドル状態である必要があります。HSEの実行中は時計を変更できません。これが予測不能な行動につながることがあります。これはS32K3リファレンスマニュアルに明確に記載されています。 「HSE_CLKを設定する前に、HSE CPUのコアステータスレジスタ（PRTN0_CORE2_STAT）を読み取って、SBAFがWFI状態に入るまで待つ必要があります。」 これは古いバージョンのRTDドライバを使う場合に問題になる可能性があり、ドライバがステータスレジスタを確認しなかったためです。 このチェック機能は、RTDバージョン5.0.0以降で実装されました。古いバージョンの場合は、クロック初期化前にWFIをポーリングするのはユーザーが行います。ですから、これが失敗の原因かもしれません。 回复： S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link こんにちは、兄弟 私も同じ問題に遭遇しました。どうやって解決したのか教えていただけますか? 回复： S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link こんにちは、 返信が遅くなり申し訳ありません。今メッセージを確認しました。問題は解決しましたか？それともまだサポートが必要ですか？

VS Codeでmcuxpresso設定ツールをインストール中にエラーが発生しました 親愛なるみんな VS Code 用の MCUxpresso をインストールしようとしていますが、VS Code 用の MCUXpresso 設定ツールをインストールしようとすると、次のエラーが発生します。 [エラー] MCUXPRESSO-CT-WIN64-26.03 のダウンロード URL を取得できませんでした: 200: OK。ダウンロードをスキップします... [エラー] MCUXpresso設定ツールのインストール中にエラーが発生しました。 MCUXPRESSO-CT-WIN64-26.03 のダウンロード URL を取得できませんでした。 スキップ中... ***インストールエラー*** 私のVS Codeのバージョンは以下のとおりです。 バージョン: 1.118.1 (ユーザー設定) コミット: 034f571df509819cc10b0c8129f66ef77a542f0e 日付: 2026年4月29日 17:36:44 +03:00 電子: 39.8.8 ElectronBuildId: 13870025 クロム: 142.0.7444.265 Node.js: 22.22.1 V8: 14.2.231.22-electron.0 OS: Windows_NT x64 10.0.26200 これはVScodeによって自動的に開かれるフォームです _Ferrari__0-1778425696101.png あなたも同じような問題を抱えていましたか？ どうやって直したんですか？ ご協力いただき、誠にありがとうございました。 よろしくお願いいたします Re: error while installing mcuxpresso config tool in vscode こんにちは、 MCUXpressoインストーラーは、以前nxp.comからダウンロードする際に互換性の問題が発生していました。この問題は、数日前にリリースされた最新版で解決済みです。MCUXpressoインストーラーを自動更新機能を使用して更新してから、MCUXpresso設定ツールのインストールを再度お試しください。 AlexandraMaracine_0-1778479402779.png ありがとうございました。 アレクサンドラ Re: error while installing mcuxpresso config tool in vscode 20260920 こんにちは、 ご提案いただいた解決策を試してみましたが、問題は依然として解決していません。今日は2026年9月20日です。MCUXpressoインストーラーが最新バージョンにアップデートされていることを確認しました。しかし、MCUXpresso構成ツールとセキュアプロビジョニングをインストールする際に、依然としてエラーが発生します。 もう少し詳しく調べてもらえますか? ありがとう。 1.png 2.png

寻求关于值得信赖的免费软件在线资源的建议 大家好， 我正在寻找可靠的在线资源，用于网络安全、无线网络和网站开发软件。具体而言，是用于网站优化、网络、网络安全或在线生产力的软件解决方案。 我听说过thefreetech.com这个网站，但我很好奇它与其他热门平台相比如何。最近有人用过吗？它的准确性和易用性如何？任何见解、建议或替代方案都将不胜感激！ 提前感谢！

S32K344 AB-Swap 在 HSE_ActivatePassiveBlock 后自动启动失败；固件仅可通过 J-Link Sta 启动 平台：S32K344，采用 AB 互换方案。主动模块和被动模块分别存储不同的固件镜像。观察：执行 HSE_ActivatePassiveBlock() 交换活动/被动分区后，完全断电重启不会触发固件自动启动。只有连接 J-Link 并通过调试器触发启动应用程序时，固件才能成功执行。请问有人能解释一下根本原因并提供建议的解决方案吗？ Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link 嗨@HQZ 您确定被动分区中存在有效镜像吗？如果在启动目标后不RESET它，而是将调试器连接到正在运行的目标上，你会观察到什么现象？设备是否进入JTAG恢复模式？或者，您也可以直接通过调试器重置设备，然后检查它是否到达了应用程序的入口点。 如果设备在地址 0x2040012C 处陷入无限循环，则表明它已进入 JTAG 恢复模式。这也可能表明 IVT 配置或 IVT 完整性存在问题。 另外，被动分区中的映像是否链接到活动分区地址空间运行，即从 0x00400000 开始运行？ 最后，你们是否启用了安全启动？ 此致， Lukas Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link 你好@lukaszadrapa  平台：S32K344，AB-Swap架构。独立固件镜像分别存储在主动块和被动块中。HSE安全启动已禁用。问题描述：调用HSE_ActivatePassiveBlock()完成主动/被动分区切换后，设备在断电后RESET无法自动启动目标固件。但是，如果将J-Link调试器连接到芯片，并在调试器软件中点击“启动应用程序”，则切换后的固件可以正常运行。补充背景：固件同时存在于分区A和分区B中。两个镜像之间的唯一区别是LED闪烁频率。分区A固件的链接起始地址为0x400000，而分区B固件的链接起始地址为0x600000。调用HSE_ActivatePassiveBlock()并RESET后，我使用J-Link转储了闪存内容。分区A和分区B的内容已物理交换，证实HSE_ActivatePassiveBlock()已生效。问题：1. 此行为的根本原因是什么？为什么冷启动和调试器触发的“启动应用程序”的行为不同？2. AB分区交换后，有哪些可行的解决方案可以解决自动启动失败的问题？感谢您的支持。 Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link 嗨@HQZ “分区 B 固件链接起始地址为 0x600000”——这就是问题所在。两个映像必须链接才能使用活动分区地址 – 0x400000。应用程序始终在活动分区上运行，而不是在被动分区上运行。 解决方法——对两个项目使用同一个链接器文件。 它之所以能与你的调试器配合使用，是因为调试器会“手动”将程序计数器设置为入口点地址，该地址位于 elf 文件中。 此致， Lukas Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link 你好@lukaszadrapa 我已按照之前的建议尝试了 AB 分区交换，但问题仍然存在。 使用的 HSE 固件版本为 s32k344_hse_fw_1.5.0_2.40。 用于验证 AB 交换的测试设置： 具有基于应用程序的自我更新的单链接器脚本。该应用程序负责将新的固件映像编程到被动分区中。 链接器脚本：只使用一个链接器脚本，固件起始地址始终设置为 0x00400000。 工作流程： 1.在分区 A（逻辑地址 0x00400000）中运行的应用程序通过 CAN 接收新固件。A分区和B分区固件之间的唯一区别在于LED闪烁频率。 2. 该应用程序将新固件直接编程到被动分区的物理地址（0x00600000）中。 3.编程完成后，调用 HSE_ActivatePassiveBlock() 服务。 4. 然后 RESET 芯片。 观察： 固件RESET后无法运行。但是，当连接 J-Link 并从调试器触发“启动应用程序”时，分区 B 中的固件可以正确执行。 还有哪些其他根本原因会导致分区交换失败，相应的解决方法是什么？ 问候 Re: S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link 很抱歉回复晚了。 以下是一些常见问题： 运行 HSE_ActivatePassiveBlock() 并重置设备后，大约需要 1 秒 HSE 才能准备好接受新的服务请求。这是因为 HSE 会将 HSE 固件备份到被动分区。操作完成后，FSR 寄存器中的 HSE_STATUS_INIT_OK 标志将被置位。所以，在 HSE 完成之前，无法使用它。有时这就是麻烦的根源。 固件版本 0.2.55.0 及更高版本已对此进行了优化，并且仅当固件更新时才会将其复制到被动分区。如果结果仍然相同，HSE 将跳过此操作，交换速度会快得多。 然后我建议阅读 HSE 固件参考手册修订版中的描述。2.7 节： “14.6.5同步 HSE 和应用核心之间的闪存读/写访问： https://www.nxp.com/webapp/sd/collateral/1765990353647716033651?version=2.7 表 149、150 和 151 中提供了典型场景的详细信息。 就您的情况而言：当 HSE 将自身备份到被动分区时，无法访问闪存块 3，因为 HSE 在该块上执行闪存操作。 另外，您不能对块 1 执行刷写操作，因为 HSE 固件正在该块上运行。 还有一点，如果 HSE 正在运行，则无法更改 HSE_CLK。重置后，HSE 运行约 1 秒，此时可能会出现问题。 更改 HSE_CLOCK 时，HSE 必须处于IDLE状态。HSE 运行时无法更改时钟。这可能会导致不可预测的行为。S32K3 参考手册中明确提到了这一点： “在配置 HSE_CLK 之前，必须等待 SBAF 通过读取 HSE CPU 的核心状态寄存器 (PRTN0_CORE2_STAT) 进入 WFI 状态。” 使用旧版本的 RTD 驱动程序时可能会出现问题，因为这些驱动程序不会检查上述状态寄存器。 该检查已在 RTD 版本 5.0.0 及更高版本中实施。如果您使用的是旧版本，则需要在时钟初始化之前轮询 WFI。所以，这可能也是它失败的原因。 回复： S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link 你好，兄弟 我也遇到了同样的问题。请问您是如何解决这个问题的？ 回复： S32K344 AB-Swap auto-boot failure after HSE_ActivatePassiveBlock; firmware boots only via J-Link 你好， 很抱歉回复晚了——我刚看到您的消息。问题是否已解决，还是您仍然需要帮助？

I.MX6ULLのENET1は物理からデータを受信できません I.M6ULL + 4.19.35 + KSZ 8081rnb  この機器は現場に300台配備されています。ほとんどの場合、それらは正常に稼働し、事業やサービスは期待どおりに機能します。しかしながら、時折、サービスにアクセスできなくなることがあります。調査の結果、eth1（ENET1）のLINK LEDは点灯したままで、ACT LEDが時々点滅しているにもかかわらず、eth1がパケットを受信しなくなることが確認されました。 さらに、ENET1のイーサネットケーブルを一度抜き差しすると、ネットワークが正常に戻ることも確認しました。デバイスを再起動することでも復元されます。根本原因の分析を手伝ってもらえますか?それはPHYにあるのかMACなのか? そこから読み取られるレジスタ値は以下のとおりです。 読み取るレジスタのリストには、MACレジスタとPHYレジスタの両方が含まれます。かなり長いため、次のページに掲載しています。 コマンド: phy eth1 0x1は PHY レジスタ 1 を読み取ります。 memtool i.MX6UL Linux

i.MX93 M33 无法使用系统 TCM RAM 进行分配 我们正在评估 i.MX9352 在物联网设备中的应用。我为 M33 内核创建了一个应用程序，用于执行时间关键型 IO 操作，其中包括从外围设备收集大量样本。为了开发目的，我正在使用 remoteproc 从 Linux 加载和启动 M33 代码。代码是用 C 语言编写的，并使用了 MPUXpresso 26.06.00 SDK。 代码运行良好，但我现在需要一个大的样本缓冲区（约 24 kB）。我尝试过将其添加为静态数组或使用 `malloc` 分配的堆。无论哪种情况，我的内存似乎都会耗尽，即使编译输出表明内存充足。 工作版本： 以下是使用较小缓冲区版本的内存信息，**运行正常**（但缓冲区太小，无法满足我们的要求）。 Memory region Used Size Region Size %age Used m_interrupts: 1140 B 1144 B 99.65% m_text: 78300 B 129928 B 60.26% m_m33_suspend_ram: 0 B 8 KB 0.00% m_a55_suspend_ram: 0 B 4 KB 0.00% m_data: 48016 B 108 KB 43.42% m_rsc_tbl: 0 B 4 KB 0.00% build finished successfully. 以下是ELF文件中的一些信息： readelf -l imx_m33.elf Elf file type is EXEC (Executable file) Entry point 0xffe0595 There are 4 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x0ffe0000 0x0ffe0000 0x00474 0x00474 R 0x1000 LOAD 0x001478 0x0ffe0478 0x0ffe0478 0x131dc 0x131dc RWE 0x1000 LOAD 0x015000 0x20003000 0x0fff3654 0x00170 0x00170 RW 0x1000 LOAD 0x000180 0x20003180 0x0fff37e0 0x00000 0x0ba10 RW 0x1000 Section to Segment mapping: Segment Sections... 00 .interrupts 01 .resource_table .text .ARM .init_array .fini_array 02 .data 03 .bss .heap .stack 大型静态分配： 以下是使用 **24 kB 静态分配缓冲区**的编译版本的内存和 ELF 文件信息。 IE。： static uint32_t m_sample_queue[SAMPLE_QUEUE_LENGTH]; // SAMPLE_QUEUE_LENGTH = 6000 Memory region Used Size Region Size %age Used m_interrupts: 1140 B 1144 B 99.65% m_text: 78240 B 129928 B 60.22% m_m33_suspend_ram: 0 B 8 KB 0.00% m_a55_suspend_ram: 0 B 4 KB 0.00% m_data: 72016 B 108 KB 65.12% m_rsc_tbl: 0 B 4 KB 0.00% build finished successfully. ### (As expected, the `m_data` section has increased in size.) ### readelf -l imx_m33.elf Elf file type is EXEC (Executable file) Entry point 0xffe0595 There are 4 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x0ffe0000 0x0ffe0000 0x00474 0x00474 R 0x1000 LOAD 0x001478 0x0ffe0478 0x0ffe0478 0x131a0 0x131a0 RWE 0x1000 LOAD 0x015000 0x20003000 0x0fff3618 0x00170 0x00170 RW 0x1000 LOAD 0x000180 0x20003180 0x0fff37a0 0x00000 0x117d0 RW 0x1000 Section to Segment mapping: Segment Sections... 00 .interrupts 01 .resource_table .text .ARM .init_array .fini_array 02 .data 03 .bss .heap .stack 当我在 Linux 系统中尝试使用 remoteproc 启动此版本时，启动失败，dmesg 显示以下错误： [ +0.001258] imx-rproc remoteproc-cm33: Translation failed: da = 0xfff37a0 len = 0x117d0 [ +0.000021] remoteproc remoteproc0: bad phdr da 0xfff37a0 mem 0x117d0 [ +0.000006] remoteproc remoteproc0: Failed to load program segments: -22 [ +0.008868] remoteproc remoteproc0: Boot failed: -22 克劳德告诉我这是.bss .heap .stack的问题。部分，因为 PhysAddr 为 `0x0fff37a0`，大小现在为 `0x117d0`。`0x0fff37a0 + 0x117d0 = 0x10004f70` 超出了 M33 代码 TCM 地址范围0x0ffe0000 .. 0x10000000 。解释令人困惑，但我的理解是静态初始化必须放在“代码”部分，导致它溢出，即使“系统”TCM 范围内有足够的空间（另外 128 kB）。所以，这或许说得通。 动态（堆）分配： 例如。： uint32_t *p_sample_queue = malloc(SAMPLE_QUEUE_LENGTH, sizeof(uint32_t)); C 语言默认可用的堆大小只有 1 kB，因此malloc无法处理我们的大缓冲区。 我修改了项目的 CMake 文件，通过__heap_size__分配了更大的堆内存 (32 kB)，该参数会传递给链接器脚本： mcux_add_linker_symbol( SYMBOLS "__stack_size__=0x400 \ __heap_size__=0x8000 \ <---- Added __use_shmem__=1 \ __multicore__=1 \ " ) 版本输出和 ELF 文件信息： Memory region Used Size Region Size %age Used m_interrupts: 1140 B 1144 B 99.65% m_text: 78240 B 129928 B 60.22% m_m33_suspend_ram: 0 B 8 KB 0.00% m_a55_suspend_ram: 0 B 4 KB 0.00% m_data: 103760 B 108 KB 93.82% m_rsc_tbl: 0 B 4 KB 0.00% build finished successfully. #### ELF file info: #### readelf -l imx_m33.elf Elf file type is EXEC (Executable file) Entry point 0xffe0595 There are 4 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x0ffe0000 0x0ffe0000 0x00474 0x00474 R 0x1000 LOAD 0x001478 0x0ffe0478 0x0ffe0478 0x131a0 0x131a0 RWE 0x1000 LOAD 0x015000 0x20003000 0x0fff3618 0x00170 0x00170 RW 0x1000 LOAD 0x000180 0x20003180 0x0fff37a0 0x00000 0x193d0 RW 0x1000 Section to Segment mapping: Segment Sections... 00 .interrupts 01 .resource_table .text .ARM .init_array .fini_array 02 .data 03 .bss .heap .stack 这似乎让问题变得更糟，而不是更好（.bss/.heap/.stack）。位于 PhysAddr 0x0fff37a0，大小 0x193d0）。 [ +0.001320] imx-rproc remoteproc-cm33: Translation failed: da = 0xfff37a0 len = 0x193d0 [ +0.000019] remoteproc remoteproc0: bad phdr da 0xfff37a0 mem 0x193d0 [ +0.000006] remoteproc remoteproc0: Failed to load program segments: -22 [ +0.002908] remoteproc remoteproc0: Boot failed: -22 我原以为使用堆分配可以缩小代码段的大小，并从数据段分配内存。上面版本输出中显示的“m_data”部分确实更大。 我不太理解“PhysAddr”，它与参考手册中的“Code TCM”范围相匹配，即使对于应该在“System TCM”区域内的内容也是如此（我认为？）。“VirtAddr”下的地址似乎是正确的。 为什么 ELF 文件仍然尝试放置 .bss/.heap/.stack 文件？PhysAddr 0x0fff37a0 处的数据为什么在使用运行时堆分配时如此之大？有没有办法在“系统 TCM”区域中分配我的大缓冲区？ Re: i.MX93 M33 Can't Use System TCM RAM for Allocation 嗨@jcolebaker 您可以选择将数据/bss/堆/堆栈的 LMA 更改为系统 TCM。在 MCUX 链接器脚本中，将数据段的加载地址 (AT) 从代码 TCM 更改为系统 TCM，以便 PhysAddr 也位于 0x2000_0000： .data : { ... } > m_data AT> m_data /* Do not use AT> m_text */ .bss : { ... } > m_data 当 LMA == VMA 且两者都在系统 TCM 中时，PhysAddr 变为 0x2000_xxxx，这与 remoteproc 驱动程序中 {0x20000000, …, 0x00040000} (256 KB) 范围内的条目匹配，从而使 remoteproc 能够正确转换。 此致， 志明 Re: i.MX93 M33 Can't Use System TCM RAM for Allocation 谢谢，搞定了！ 注意，为了使用更大的堆，我需要移动的主要部分是“堆”部分： .heap : { ... } > m_data AT> m_data

Does NXP has MPU supporting sonic OS ? Hi NXP，       We need a processor which can support SONIC OS.        I can't find the message in NXP website.        Can you help to check again ?        Thanks very much. i.MX 8M | i.MX 8M Mini | i.MX 8M Nano Re: Does NXP has MPU supporting sonic OS ? Hi Zhiming,      Got it.      Thanks very much. Re: Does NXP has MPU supporting sonic OS ? Hi @jimmyli  NXP does not officially support SONIC OS. Best Regards, Zhiming

error while installing mcuxpresso config tool in vscode Dear all I'm installing MCUxpresso for vscode but I have the following error when i try to install MCUXpresso config tool for vs code: [error] Could not get download URL for MCUXPRESSO-CT-WIN64-26.03: 200: OK. Skipping download... [error] Error occurred while installing MCUXpresso Configuration Tools: Could not get download URL for MCUXPRESSO-CT-WIN64-26.03. Skipping... *** Installation error *** my version of VScode is: Version: 1.118.1 (user setup) Commit: 034f571df509819cc10b0c8129f66ef77a542f0e Date: 2026-04-29T17:36:44+03:00 Electron: 39.8.8 ElectronBuildId: 13870025 Chromium: 142.0.7444.265 Node.js: 22.22.1 V8: 14.2.231.22-electron.0 OS: Windows_NT x64 10.0.26200 This is the form automatically is open by VScode  _Ferrari__0-1778425696101.png Did you have similar problem ? How did you fix it ? Thank you very much for your help and cooperation best regards Re: error while installing mcuxpresso config tool in vscode Hi, The MCUXpresso Installer previously experienced a compatibility issue when downloading from nxp.com. This problem has been resolved in the latest release delivered a few days ago. Please update the MCUXpresso Installer using the auto-update feature and then retry the MCUXpresso Configuration Tools installation. AlexandraMaracine_0-1778479402779.png Thank you, Alexandra Re: error while installing mcuxpresso config tool in vscode 20260920 Hi, I have followed your suggested solution, but the issue still persists. Today is 2026-09-20. I have confirmed that my MCUXpresso Installer has been updated to the latest version. However, I still get errors when installing MCUXpresso Configuration Tools and Secure Provisioning. Could you please help check this further? Thanks. 1.png 2.png

i.MX93 M33 System TCM RAMを割り当てに使用できません 当社はIoTデバイス向けにi.MX9352を評価しています。私はM33コア用のアプリケーションを作成しました。これにはペリフェラルから大量のサンプルを収集する時間的責任のIO操作が含まれます。開発のために、Linuxからリモートプロックを使ってM33コードを読み込み、起動しています。コードはC言語で書かれ、MPUXpresso 26.06.00 SDKを使用しています。 コードはうまく動作するようになったのですが、今度はサンプル用の大きなバッファ（約24kB）が必要です。私はこれを静的配列として、または`malloc`で割り当てられたヒープとして追加しようと試みました。いずれにせよ、コンパイル出力では十分なRAMがあると示されているのに、私はすぐにRAMが切れてしまうようです。 作業版: こちらは小さなバッファのビルドのメモリ情報で、**問題なく動作します*(ただしバッファは私たちの要件には小さすぎます)。 Memory region Used Size Region Size %age Used m_interrupts: 1140 B 1144 B 99.65% m_text: 78300 B 129928 B 60.26% m_m33_suspend_ram: 0 B 8 KB 0.00% m_a55_suspend_ram: 0 B 4 KB 0.00% m_data: 48016 B 108 KB 43.42% m_rsc_tbl: 0 B 4 KB 0.00% build finished successfully. ELFファイルからの情報は以下のとおりです。 readelf -l imx_m33.elf Elf file type is EXEC (Executable file) Entry point 0xffe0595 There are 4 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x0ffe0000 0x0ffe0000 0x00474 0x00474 R 0x1000 LOAD 0x001478 0x0ffe0478 0x0ffe0478 0x131dc 0x131dc RWE 0x1000 LOAD 0x015000 0x20003000 0x0fff3654 0x00170 0x00170 RW 0x1000 LOAD 0x000180 0x20003180 0x0fff37e0 0x00000 0x0ba10 RW 0x1000 Section to Segment mapping: Segment Sections... 00 .interrupts 01 .resource_table .text .ARM .init_array .fini_array 02 .data 03 .bss .heap .stack 大規模な静的割り当て: こちらは**24 kBの静的割り当てバッファ**を持つビルドのメモリとELFファイル情報です。 つまり： static uint32_t m_sample_queue[SAMPLE_QUEUE_LENGTH]; // SAMPLE_QUEUE_LENGTH = 6000 Memory region Used Size Region Size %age Used m_interrupts: 1140 B 1144 B 99.65% m_text: 78240 B 129928 B 60.22% m_m33_suspend_ram: 0 B 8 KB 0.00% m_a55_suspend_ram: 0 B 4 KB 0.00% m_data: 72016 B 108 KB 65.12% m_rsc_tbl: 0 B 4 KB 0.00% build finished successfully. ### (As expected, the `m_data` section has increased in size.) ### readelf -l imx_m33.elf Elf file type is EXEC (Executable file) Entry point 0xffe0595 There are 4 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x0ffe0000 0x0ffe0000 0x00474 0x00474 R 0x1000 LOAD 0x001478 0x0ffe0478 0x0ffe0478 0x131a0 0x131a0 RWE 0x1000 LOAD 0x015000 0x20003000 0x0fff3618 0x00170 0x00170 RW 0x1000 LOAD 0x000180 0x20003180 0x0fff37a0 0x00000 0x117d0 RW 0x1000 Section to Segment mapping: Segment Sections... 00 .interrupts 01 .resource_table .text .ARM .init_array .fini_array 02 .data 03 .bss .heap .stack Linuxでremoteprocを使ってこのバージョンを起動しようとすると起動できず、dmesgは以下のエラーを表示します。 [ +0.001258] imx-rproc remoteproc-cm33: Translation failed: da = 0xfff37a0 len = 0x117d0 [ +0.000021] remoteproc remoteproc0: bad phdr da 0xfff37a0 mem 0x117d0 [ +0.000006] remoteproc remoteproc0: Failed to load program segments: -22 [ +0.008868] remoteproc remoteproc0: Boot failed: -22 クロードは、これは.bss .heap .stackの問題だと私に言った。PhysAddr が `0x0fff37a0` で、サイズが `0x117d0` になったため、このセクションが使用不可となります。`0x0fff37a0 + 0x117d0 = 0x10004f70` は、M33 コード TCM アドレス範囲0x0ffe0000 .. 0x10000000を超えています。説明は分かりにくかったのですが、私の解釈では、静的初期化は「code」セクションに記述する必要があり、「system」TCM領域（残りの128kB）には十分な空き容量があるにもかかわらず、オーバーフローが発生してしまうということです。だから、これで納得できるかもしれません。 動的（ヒープ）割り当て： 例えば。： uint32_t *p_sample_queue = malloc(SAMPLE_QUEUE_LENGTH, sizeof(uint32_t)); Cで利用可能なデフォルトのヒープサイズはわずか1 kBなので、 malloc は大きなバッファでは失敗します。 プロジェクトのCMakeを修正し、 __heap_size__を介してより大きなヒープ（32kB）を割り当てるようにしました。この__heap_size__はリンカースクリプトに渡されます。 mcux_add_linker_symbol( SYMBOLS "__stack_size__=0x400 \ __heap_size__=0x8000 \ <---- Added __use_shmem__=1 \ __multicore__=1 \ " ) ビルド出力とELFファイル情報: Memory region Used Size Region Size %age Used m_interrupts: 1140 B 1144 B 99.65% m_text: 78240 B 129928 B 60.22% m_m33_suspend_ram: 0 B 8 KB 0.00% m_a55_suspend_ram: 0 B 4 KB 0.00% m_data: 103760 B 108 KB 93.82% m_rsc_tbl: 0 B 4 KB 0.00% build finished successfully. #### ELF file info: #### readelf -l imx_m33.elf Elf file type is EXEC (Executable file) Entry point 0xffe0595 There are 4 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x0ffe0000 0x0ffe0000 0x00474 0x00474 R 0x1000 LOAD 0x001478 0x0ffe0478 0x0ffe0478 0x131a0 0x131a0 RWE 0x1000 LOAD 0x015000 0x20003000 0x0fff3618 0x00170 0x00170 RW 0x1000 LOAD 0x000180 0x20003180 0x0fff37a0 0x00000 0x193d0 RW 0x1000 Section to Segment mapping: Segment Sections... 00 .interrupts 01 .resource_table .text .ARM .init_array .fini_array 02 .data 03 .bss .heap .stack これは問題を改善するどころか悪化させているようだ（.bss/.heap/.stackPhysAddr 0x0fff37a0、サイズ 0x193d0)。 [ +0.001320] imx-rproc remoteproc-cm33: Translation failed: da = 0xfff37a0 len = 0x193d0 [ +0.000019] remoteproc remoteproc0: bad phdr da 0xfff37a0 mem 0x193d0 [ +0.000006] remoteproc remoteproc0: Failed to load program segments: -22 [ +0.002908] remoteproc remoteproc0: Boot failed: -22 ヒープ割り当てを使うことでコードセクションを小さくし、データセクションからメモリを割り当てられると思っていました。上記のビルド出力に示されている「m_data」セクションは確かに大きいです。 リファレンスマニュアルの「Code TCM」の範囲に一致する「PhysAddr」の意味がよく分かりません。本来「System TCM」領域にあるべきもの（だと思うのですが）についてもです。「VirtAddr」の下のアドレスは正しいようです。 ELF ファイルはなぜまだ .bss/.heap/.stack を配置しようとするのかPhysAddr 0x0fff37a0のデータについて、なぜランタイムヒープ割り当てを使うとこんなに大きいのでしょうか?また、「System TCM」領域に大きなバッファを割り当てる方法はありますか? Re: i.MX93 M33 Can't Use System TCM RAM for Allocation こんにちは、 @jcolebakerさん データ/BSS/ヒープ/スタックのLMAをSystem TCMに変更することもできます。MCUXリンカースクリプトでは、データセグメントのロードアドレス(AT)をコードTCMからSystem TCMに変更し、PhysAddrも0x2000_0000に当てはまるようにします。 .data : { ... } > m_data AT> m_data /* Do not use AT> m_text */ .bss : { ... } > m_data LMA == VMAが両方ともSystem TCMにある場合、PhysAddrは0x2000_xxxxとなり、remoteprocドライバーの{0x20000000, ..., 0x00040000}(256 KB)の範囲に一致し、remoteprocが正しく翻訳できるようにします。 よろしくお願いします、 志明 Re: i.MX93 M33 Can't Use System TCM RAM for Allocation ありがとう、うまくいったよ！ なお、より大きなヒープを使用するために移動する必要があった主なセグメントは、「heap」セグメントでした。 .heap : { ... } > m_data AT> m_data