Connectivity issue in SJA1110 Dear NXP members, This ticket may be related to the following topics: SJA-1110-Configuration-of-Qbv  SJA1110-Qbv-AdminBaseTime-Configuration  During the configuration of Qbv on the SJA1110 switch present in the S32G-VNP-RDB3 board, I have been using the SJA1110 SDK for S32G from NXP for setting the gPTP/Qbv parameters, compiling the new sja1110_uc.bin file, and deploying it on the firmware folder of the A-core Linux BSP. Initially, I have been using the PFE0 interface (SJA1110 switch Port 4) as the gPTP grandmaster, with ADMINBASETIME set to 0. I performed some tests and validations and everything indicates that it behaves as expected. However, during the course of the project, I had to reassign the roles so that now the gPTP grandmaster would come from an external device which is connected to the Port 3. From the moment I would connect this external device, the Qbv performance would behave quite erratically. I did some tests starting with large cycle values, for instance: Cycle = 1 sec -> 125000000 CycleExt (12.5%) = 15625000 segment 1 = 0.25 sec TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 0.25 sec TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 0.25 sec TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 0.25 sec TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 1250000 (2x625000) port 4: TRIGGER_TIME = 3125000 (4x781250) ports 5...: TRIGGER_TIME = 125000 For testing, I send UDP packets from the client (S32G PFE0 interface) to another Linux device connected on the same network acting as server. I capture the packets using the tcpdump tool on the server side, and analyze the results. In this case, the transmission would start after a few seconds, but once started, it would behave correctly (1 second cycle, 25% for the given traffic priority):  Then, I used the GATESTATUS division into four segments, but reduced the cycle time to 200 ms: Cycle = 200ms -> 25000000 CycleExt = 3125000 segment 1 = 50 ms TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 50 ms TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 50 ms TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 50 ms TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 250000 port 4: TRIGGER_TIME = 625000 ports 5...: TRIGGER_TIME = 25000 It would work, but I needed to start between 30 seconds and 2 minutes for the transmission of the packets start.   In the subsequent tests, I observed the same pattern: When the cycle time was reduced to 100 ms, I would have to wait between 2 and 4 minutes before transmission started; When the cycle time was reduced to 50 ms, I would have to wait between 5 and 6 minutes before transmission started. And so on. So, the shorter the cycle length, the larger the wait time before Qbv effectively started. Until then, the traffic was blocked. But there is another weird behavior observed when I did the following configuration: Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 2 = 300 μsec TC 6: GATESTATUS 4 segment 3 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 In this case, all of the traffic would pass except TC6. When I invert the configuration: Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TC 6: GATESTATUS 4 segment 2 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 3 = 300 μsec TC 6: GATESTATUS 4 in this case, only the TC6 traffic would be transmitted while the other TCs would be blocked. From my opinion, it points in the direction of the time synchronization issue. Here is how I have configured gPTP on the S32DS:     It is also worth mentioning that this external gPTP Grandmaster provides Sync timestamps based on the current Unix epoch:   While when the PFE0 was used as the Grandmaster, it would provide Sync timestamps starting with 0:   What would explain this behavior? Thank you for your support! Best regards, Guilherme Re: Connectivity issue in SJA1110 Hello @GuilhermeS32G , Yes, please wait to get access. Besides NDA, Automotive Ethernet belongs to export control policy. In my opinion, the ECT tool is a great source of code related to switch's dynamic reconfiguration. Yes, split the Unix epoch gPTP timestamp into ADMINBASETIME[0:31] and ADMINBASETIME[32:63] is the right way. Best regards, Pavel Re: Connectivity issue in SJA1110 Hi @PavelL , Thank you for your response. Indeed, this ECT tool seems to be the right way to go. However, I still have no access for downloading it. It says: "SJA11XX Standard Software - Your Request form has been received". I may need to wait for some time to see if I can get access. In the meanwhile, just to clarify, let's say the current Unix epoch (with nanoseconds) is: 1784013205012345678 Which represents, in UTC: Tuesday, July 14, 2026 at 7:13:25 AM What is the correct way to split this timestamp into ADMINBASETIME[0:31] and ADMINBASETIME[32:63]? Best regards, Guilherme Re: Connectivity issue in SJA1110 Hello @GuilhermeS32G , Thank you for creating a follow up thread - it help us to keep clarity on cases. Thank you for sharing all the details and test results at once. I checked provided data and your gPTP configuration appears to be correct.   Based on your observations, the behavior strongly suggests that the issue is related to the Qbv schedule activation time rather than to the gate list entries themselves. If the ADMINBASETIME being configured as 0 while the external gPTP Grandmaster provides an epoch-based PTP time value, ADMINBASETIME = 0 is far in the past relative to the current synchronized gPTP time domain and the switch needs to resolve the Qbv change/start time based on that value. This may lead to unexpected schedule activation behavior compared with a setup where the PTP time starts close to zero, and it is therefore safer to program ADMINBASETIME as a future value in the currently synchronized PTP time domain.   Therefore, for this use case, I would recommend configuring ADMINBASETIME dynamically based on the current synchronized PTP/gPTP time (and still using a fixed value of 0 in the static configuration). A typical sequence would be: 1. Start gPTP and wait until the switch is synchronized to the external Grandmaster. 2. Read the current PTP clock from the switch. 3. Set ADMINBASETIME to a future time value, for example current PTP time + sufficient safety margin. 4. Write the TAS/Qbv administrative parameters. 5. Trigger the TAS/Qbv configuration change. You may use the ECT server implementation as a reference. In particular, please check file udp_traffic.c ; routine udpReceiveCallback() . It doesn't matter if you use SDK or RTD version of ECT server. In the TAS configuration handling, the ECT server (SDK version) reads the current PTP time using SWITCH_DRV_GetPtpClk(), assigns this value to the TAS baseTime, adds a margin of 2 seconds, and then calls SWITCH_DRV_WriteTasAdminParameters() followed by SWITCH_DRV_ChangeTasConfig().   This approach avoids using ADMINBASETIME = 0 and aligns the Qbv schedule activation with the actual synchronized PTP time domain. Best regards, Pavel

SJA1110のコネクティビティ問題 NXPメンバーの皆様へ このチケットは以下のトピックに関連する場合があります: SJA-1110-Qbvの構成 SJA1110-Qbv-AdminBaseTime-Configuration S32G-VNP-RDB3ボードにあるSJA1110スイッチでQbvの設定中、NXPのS32GのSJA1110 SDKを使ってgPTP/Qbvパラメータの設定、新しい sja1110_uc.bin ファイルのコンパイル、そしてAコアLinux BSPのファームウェアフォルダにデプロイしています。 最初は、PFE0インターフェース(SJA1110スイッチポート4)をgPTPグランドマスターとして使い、ADMINBASETIMEを0に設定していました。いくつかのテストや検証を行いましたが、すべて期待通りに動作しています。 しかし、プロジェクトの進行中に役割を再割り当てし、gPTPグランドマスターはポート3に接続された外部デバイスから出力されるようになりました。 この外部デバイスを接続した瞬間から、Qbvのパフォーマンスが非常に不安定になった。 例えば、大きなサイクル値から始めていくつかのテストを行いました。 Cycle = 1 sec -> 125000000 CycleExt (12.5%) = 15625000 segment 1 = 0.25 sec TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 0.25 sec TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 0.25 sec TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 0.25 sec TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 1250000 (2x625000) port 4: TRIGGER_TIME = 3125000 (4x781250) ports 5...: TRIGGER_TIME = 125000 テストのために、クライアント(S32G PFE0インターフェース)から同じネットワークにコネクテッドされた別のLinuxデバイスへUDPパケットを送信しています。 サーバー側でtcpdumpツールを使用してパケットをキャプチャし、結果を分析します。 この場合、送信は数秒後に開始されますが、一度開始すると正しく振る舞います(1秒サイクル、指定されたトラフィック優先度の25%)。 次に、GATESTATUSを4つのセグメントに分割しましたが、サイクルタイムを200msに短縮しました。 Cycle = 200ms -> 25000000 CycleExt = 3125000 segment 1 = 50 ms TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 50 ms TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 50 ms TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 50 ms TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 250000 port 4: TRIGGER_TIME = 625000 ports 5...: TRIGGER_TIME = 25000 うまくいくはずだったが、パケットの送信開始まで30秒から2分の間に開始する必要があった。   その後のテストでも、同じパターンが観察された。 サイクルタイムを100ミリ秒に短縮すると、送信が開始されるまでに2分から4分待たなければなりませんでした。 サイクルタイムが50ミリ秒に短縮された場合、送信が開始されるまでに5分から6分待たなければなりませんでした。 などなど。したがって、 サイクルの長さが短いほど、Qbvが実質的に始まるまでの待ち時間が長くなります。それまで、交通は遮断されていた。 しかし、以下の設定を行った際に、別の奇妙な動作が観察されました。 Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 2 = 300 μsec TC 6: GATESTATUS 4 segment 3 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 この場合、TC6以外のすべてのトラフィックは通過します。 設定を反転すると： Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TC 6: GATESTATUS 4 segment 2 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 3 = 300 μsec TC 6: GATESTATUS 4 この場合、TC6のトラフィックのみが送信され、他のTCはブロックされます。 私の見解では、これは時刻同期の問題を示唆している。 S32DSでgPTPを設定した方法を以下に示します。     また、この外部gPTPグランドマスターは、現在のUnixエポックに基づいた同期タイムスタンプを提供する点も特筆すべきである。   PFE0がグランドマスターとして使用された場合、同期タイムスタンプは0から始まる。   この行動を説明できるものは何だろうか？ サポートありがとうございます! よろしくお願いいたします。 ギレルメ Re: Connectivity issue in SJA1110 こんにちは、 @GuilhermeS32G さん、 はい、アクセスを待ってください。NDAに加えて、自動車用イーサネットは輸出管理政策に属しています。 私の意見では、ECTツールはスイッチの動的再構成に関連する優れたコードソースです。 はい、UnixエポックgPTPタイムスタンプをADMINBASETIME[0:31]とADMINBASETIME[32:63]に分割するのが正しい方法です。 よろしくお願いいたします。 パベル Re: Connectivity issue in SJA1110 こんにちは、 @PavelL さん。 ご返信ありがとうございます。 確かに、このECTツールは正しい方向性のように思えます。 しかし、まだダウンロードのアクセス権はありません。そこには「標準ソフトウェアSJA11XX - リクエストフォームが受領されました」と表示されます。アクセスできるかどうか、しばらく待つ必要があるかもしれません。 念のため、現在のUnixエポック（ナノ秒単位）を以下のように定義します。 1784013205012345678 これはUTCで表すと次のようになります。 2026年7月14日（火）午前7時13分25秒 このタイムスタンプをADMINBASETIME[0:31]とADMINBASETIME[32:63]に分割する正しい方法は何ですか？ よろしくお願いいたします。 ギレルメ Re: Connectivity issue in SJA1110 こんにちは、 @GuilhermeS32G さん、 フォローアップスレッドを作ってくださりありがとうございます。CASEの明確さを保つ助けになりました。 詳細情報と検査結果を一度に共有していただき、ありがとうございます。 ご提供いただいたデータを確認したところ、gPTPの設定は正しいようです。   あなたの観察から判断すると、この挙動はゲートリストのエントリ自体よりもQbvのスケジュール有効化時間に関連していることを強く示唆しています。 ADMINBASETIMEが0に設定されている一方で、外部gPTPグランドマスターがエポックベースのPTP時間値を提供する場合、ADMINBASETIME = 0は現在の同期gPTP時間領域に比べてかなり過去のことであり、スイッチはその値に基づいてQbvの変更/開始時間を解決する必要があります。これにより、PTP時間がほぼゼロから始まるセットアップと比べて予期しないスケジュール起動動作が生じる可能性があるため、現在同期されたPTP時間領域においてADMINBASETIMEを将来の価値としてプログラムする方が安全です。   したがって、このユースケースでは、現在の同期PTP/gPTP時間に基づいて動的にADMINBASETIMEを設定することをおすすめします(静的設定では固定値の0を使い続けます)。 典型的な手順は次のとおりです。 1. gPTPを起動し、スイッチが外部グランドマスターと同期するまで待ちます。 2. スイッチから現在のPTPクロックを読み取る。 3. ADMINBASETIMEを将来の時間値に設定します。例えば、現在のPTP時間+十分なセーフティマージン。 4. TAS/Qbvの管理パラメータを記述します。 5. TAS/Qbvの設定変更をトリガーします。 ECTサーバーの実装を参考にしても構いません。特に、ファイルudp_traffic.cを確認してください; routine udpReceiveCallback() .SDK版でもRTD版でも、ECTサーバーのどちらを使っても関係ありません。 TASの設定処理では、ECTサーバー(SDKバージョン)が現在のPTP時間をSWITCH_DRV_GetPtpClk()で読み取り、この値をTASのbaseTimeに割り当て、2秒の余裕を加えてからSWITCH_DRV_WriteTasAdminParameters()を呼び出し、続いてSWITCH_DRV_ChangeTasConfig()。   このアプローチでは、ADMINBASETIME = 0 の使用を回避し、Qbv スケジュールの有効化を実際の同期された PTP タイムドメインに合わせます。 よろしくお願いいたします。 パベル

Zephyrにおけるi.MX95 FRDM EVK向けHDMI構成サポート こんにちは、NXP チームの皆様、 現在、Zephyr RTOSを使って i.MX95 FRDM EVK ボードを開発中です。 Linux側ではHDMI出力がすでにサポートされていて正常に動作しています。しかし、ZephyrでHDMIを有効にする方法や設定方法を知りたいです。 以下の点について教えていただけませんか? Zephyrはi.MX95 FRDM EVKのHDMI出力に対応していますか? もしそうなら、どんなドライバーやデバイスツリーの設定が必要ですか? ZephyrのHDMI用の参考実装やサンプルアプリケーションはありますか? どんなガイダンスやドキュメントでも大変ありがたいです。 よろしくお願いします。 Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK AEチームに確認しました。 現在、IMX95 ZephyrではHDMIはサポートされていません。

SJA1110 的连接问题 尊敬的恩智浦半导体成员们： 此工单可能与以下主题相关： SJA-1110-Qbv配置 SJA1110-Qbv-AdminBaseTime-Configuration 在配置 S32G-VNP-RDB3 板上的 SJA1110 交换机的 Qbv 时，我一直使用 NXP 的 S32G SJA1110 SDK 来设置 gPTP/Qbv 参数，编译新的sja1110_uc.bin文件，并将其部署到 A-core Linux 电路板支持包 的固件文件夹中。 最初，我使用 PFE0 接口（SJA1110 交换机端口 4）作为 gPTP 主服务器，并将 ADMINBASETIME 设置为 0。我进行了一些测试和验证，一切迹象都表明它的行为符合预期。 然而，在项目进行过程中，我不得不重新分配角色，以便现在 gPTP 主控节点将来自连接到端口 3 的外部设备。 从我连接这个外部设备的那一刻起，Qbv 的性能就会变得非常不稳定。 我进行了一些测试，例如从较大的循环值开始： Cycle = 1 sec -> 125000000 CycleExt (12.5%) = 15625000 segment 1 = 0.25 sec TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 0.25 sec TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 0.25 sec TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 0.25 sec TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 1250000 (2x625000) port 4: TRIGGER_TIME = 3125000 (4x781250) ports 5...: TRIGGER_TIME = 125000 为了进行测试，我从客户端（S32G PFE0 接口）向连接在同一网络上的另一个 Linux 设备（作为服务器）发送 UDP 数据包。 我在服务器端使用 tcpdump 工具捕获数据包，并分析结果。 在这种情况下，传输会在几秒钟后开始，但一旦开始，它就会正常工作（1 秒周期，给定流量优先级的 25%）： 然后，我将 GATESTATUS 分成四个段，但将周期时间缩短至 200 毫秒： Cycle = 200ms -> 25000000 CycleExt = 3125000 segment 1 = 50 ms TCs 0 and 1 GATESTATUS 1 and 0 segment 2 = 50 ms TCs 2 and 3 GATESTATUS 6 and 7 segment 3 = 50 ms TCs 4 and 5 GATESTATUS 2 and 3 segment 4 = 50 ms TCs 6 and 7 GATESTATUS 4 and 5 port 3: TRIGGER_TIME = 250000 port 4: TRIGGER_TIME = 625000 ports 5...: TRIGGER_TIME = 25000 这样做是可行的，但我需要等待 30 秒到 2 分钟才能开始传输数据包。   在随后的测试中，我观察到了同样的模式： 当循环时间缩短至 100 毫秒时，我需要等待 2 到 4 分钟才能开始传输； 当循环时间缩短到 50 毫秒时，我需要等待 5 到 6 分钟才能开始传输。 等等。因此，周期长度越短，Qbv 实际开始前的等待时间就越长。在此之前，交通一直处于阻塞状态。 但是，当我进行以下配置时，观察到了另一种奇怪的现象： Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 2 = 300 μsec TC 6: GATESTATUS 4 segment 3 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 在这种情况下，除了TC6之外，所有交通流量都将通过。 当我反转配置时： Cycle = 0.5 ms -> 62500 CycleExt = 7812 segment 1 = 30 μsec TC 6: GATESTATUS 4 segment 2 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7 segment 3 = 300 μsec TC 6: GATESTATUS 4 在这种情况下，只有 TC6 的流量会被传输，而其他 TC 的流量将被阻止。 我认为，这指向了时间同步问题。 以下是我在S32DS上配置gPTP的方法：     值得一提的是，这个外部 gPTP 主服务器提供的同步时间戳基于当前的 Unix 纪元：   当 PFE0 用作主控时，它会提供从 0 开始的同步时间戳：   这种行为该如何解释？ 感谢您的支持！ 顺祝商祺！ 吉列尔梅 Re: Connectivity issue in SJA1110 你好@GuilhermeS32G ， 是的，请稍候，您将获得访问权限。除了保密协议外，汽车以太网还属于出口管制政策的范畴。 我认为，ECT 工具是交换机动态重配置相关代码的绝佳来源。 是的，将 Unix epoch gPTP时间戳拆分为 ADMINBASETIME[0:31] 和 ADMINBASETIME[32:63] 是正确的方法。 顺祝商祺！ 帕维尔 Re: Connectivity issue in SJA1110 嗨@PavelL ， 感谢您的反馈， 确实，这种ECT工具似乎是正确的选择。 但是，我仍然无法下载它。上面写着：“SJA11XX 标准软件 - 您的申请表已收到”。我可能需要等待一段时间才能获得访问权限。 同时，为了更清楚地说明，我们假设当前的 Unix 时间戳（精确到纳秒）是： 1784013205012345678 这在世界协调时 (UTC) 代表： 2026年7月14日星期二上午7:13:25 如何正确地将此时间戳拆分为 ADMINBASETIME[0:31] 和 ADMINBASETIME[32:63]？ 顺祝商祺！ 吉列尔梅 Re: Connectivity issue in SJA1110 你好@GuilhermeS32G ， 感谢您创建后续讨论帖——这有助于我们了解案件的最新进展。 感谢您一次性分享所有细节和测试结果。 我已检查所提供的数据，您的 gPTP 配置似乎是正确的。   根据您的观察，该行为强烈表明问题与 Qbv 调度激活时间有关，而非门控列表条目本身。如果外部 gPTP 主时钟提供基于纪元的 PTP 时间值，而 ADMINBASETIME 配置为 0，则 ADMINBASETIME = 0 相对于当前同步的 gPTP 时域而言非常遥远，交换机需要基于该值解析 Qbv 更改/启动时间。与 PTP 时间接近零的设置相比，这可能会导致意外的调度激活行为。因此，将 ADMINBASETIME 设置为当前同步的 PTP 时域中的未来值更为安全。   因此，对于此用例，我建议根据当前同步的 PTP/gPTP 时间动态配置 ADMINBASETIME（并在静态配置中仍然使用固定值 0）。 典型的序列如下： 1. 启动 gPTP 并等待交换机与外部主控交换机同步。 2. 从交换机读取当前的 PTP 时钟。 3. 将 ADMINBASETIME 设置为未来的时间值，例如当前 PTP 时间 + 足够的安全裕度。 4. 编写 TAS/Qbv 管理参数。 5. 触发 TAS/Qbv 配置更改。 您可以参考 ECT 服务器的实现。特别是请查看udp_traffic.c文件中的 udpReceiveCallback() 函数。无论您使用的是 ECT 服务器的 SDK 版本还是 RTD 版本，都无关紧要。 在 TAS 配置处理中，ECT 服务器（SDK 版本）使用 SWITCH_DRV_GetPtpClk() 读取当前 PTP 时间，将此值赋给 TAS 基准时间，加上 2 秒的裕量，然后调用 SWITCH_DRV_WriteTasAdminParameters()，再调用 SWITCH_DRV_ChangeTasConfig()。   这种方法避免使用 ADMINBASETIME = 0，并将 Qbv 调度激活与实际同步的 PTP 时间域对齐。 顺祝商祺！ 帕维尔

Zephyr 中对 i.MX95 FRDM EVK 的 HDMI 配置支持 您好，NXP团队： 我目前正在使用 Zephyr RTOS 在i.MX95 FRDM EVK板上进行开发。 Linux 系统方面，HDMI 输出已经得到支持，并且运行正常。但是，我想知道如何在 Zephyr 中启用和配置 HDMI。 请问您能否指导我完成以下事项？ Zephyr 是否支持 i.MX95 FRDM EVK 的 HDMI 输出？ 如果需要，需要哪些驱动程序和设备树配置？ Zephyr 上是否有 HDMI 的参考实现或示例应用程序？ 任何指导或文件都将不胜感激。 谢谢！ Re: HDMI Configuration Support in Zephyr for i.MX95 FRDM EVK 我已向AE团队确认过。 IMX95 Zephyr 目前不支持 HDMI。

How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi,  We use MIMXRT1062DVL6B and realize our product with ethernet. First, we implement the MAC address for our product using `SILICONID_ConvertToMacAddr` on `fsl_silicon_id.c` to get unique MAC address per device with NXP's OUI and silicon ID. But the MAC address we got via `SILICONID_ConvertToMacAddr` was not unique, and they were all identical. So, I have a question. Do we have any setting before calling `SILICONID_ConvertToMacAddr`? Or, `SILICONID_ConvertToMacAddr` does not work to get unique MAC address over the NXP device? We couldn't find answer in IMXRT1060RM.pdf of Rev. 4, 01/2026. Could you give us the answer? thank you. Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi, Abner Thank you for your supporting,  We understood that we can use MAC address got via SILICONID_ConvertToMacAddr for our product. But I understand SILICONID_ConvertToMacAddr is just an example and we can't use it for our mass product. And we have to use the MAC address under our OUI. Best regards. Shigeru Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi @shigeru-tsujita  Thanks to find this situation. SILICONID_ConvertToMacAddr is used for NXP MCUX SDK example to reduce MAC address conflict in our test environment. We connect to different Socs' eth in same switch. For this same series Soc situation, we may not cover. But what I'm confused is why you use this way to generate your product MAC address. First of all, your OUI should use your company's one. Then the unique ID I think your company should have a internal special definition. Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi, May. I understand SILICONID_ConvertToMacAddr make MAC address using fixed NXP OUI and three bytes of silicon ID(it's part of OCOTP->CFG0/1). I observed the OCOTP->CFG0/1 of our target product. Those values are following: - one MIMXRT1062   - OCOTP->CFG0: (uint32_t)0x615c'faa4   - OCOTP->CFG1: (uint32_t)0x2a1e'61d7 - other MIMXRT1062   - OCOTP->CFG0: (uint32_t)0x615c'faa4   - OCOTP->CFG1: (uint32_t)0x4922'61d7 Because lower three bytes of OCOTP->CFG0 is used for MAC address in SILICONID_ConvertToMacAddr, they have similar MAC address. So, many of our product have similar MAC address. (Now we have handreds of prototype and we don't check all MAC address, but we couldn't find differnt MAC address with 54:27:8D:A4:FA:5C yet.) thank you. Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? Hi @shigeru-tsujita, Thank you so much for your interest in our products and for using our community. Assuming the SDK silicon_id component is correctly integrated, no additional setting is required before calling SILICONID_ConvertToMacAddr() for MIMXRT1062. Please note that SILICONID_ConvertToMacAddr() does not use the full 64-bit silicon ID to generate the MAC address. It uses a fixed NXP OUI for the first 3 bytes and only 3 bytes from the silicon ID for the last 3 bytes. According to the SDK code: Could you please read the 64-bit silicon unique ID from several devices and check whether the ID values are read correctly? Please also compare siliconId[0] , siliconId[1] , and siliconId[2] , as these are the bytes used to generate the MAC address. If these three bytes are identical across devices, the generated MAC addresses will also be identical. Best Regards May

Yoctoのリリーノーズビルド失敗 imx-car-navigation こんにちは、 最新の6.18.20-2.0.0 BSP上でFRDM-IMX93用の「imx-image-full」をビルドしようとすると、次のように失敗します。 ERROR: imx-car-navigation-1.0-r0 do_compile: Execution of '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/temp/run.do_compile.1753043' failed with exit code 1 ERROR: Logfile of failure stored in: /media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/temp/log.do_compile.1753043 Log data follows: | DEBUG: Executing shell function do_compile | Cloning into '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode'... | fatal: unable to access 'https://github.com/CANopenNode/CANopenNode.git/': Could not resolve host: github.com | fatal: clone of 'https://github.com/CANopenNode/CANopenNode.git' into submodule path '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode' failed | Failed to clone 'CANopenNode'. Retry scheduled | Cloning into '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode'... | fatal: unable to access 'https://github.com/CANopenNode/CANopenNode.git/': Could not resolve host: github.com | fatal: clone of 'https://github.com/CANopenNode/CANopenNode.git' into submodule path '/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/build-imx93-frdm/tmp/work/armv8-2a-poky-linux/imx-car-navigation/1.0/sources/imx-car-navigation-1.0/CANopenNode' failed | Failed to clone 'CANopenNode' a second time, aborting | WARNING: exit code 1 from a shell command. ERROR: Task (/media/dzu/hd01-xfs/nxp/imx-yocto-6.18.20-2.0.0/sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb:do_compile) failed with exit code '1' これは100％再現可能であり、必ずここで失敗します。また、bitbakeが「コンパイル」ステップを実行しているにもかかわらず、リポジトリのダウンロードが失敗する点にもご注意ください。現状では、コンパイルの段階でダウンロードを行うべきではないことと、Bitbakeがネットワーク機能をダウンロード段階に限定していることが関係しているのではないかと考えています。最近このレシピを試した人はいますか？ Re: Yocto wrynose build failure for 'imx-car-navigation' 私の直感は正しかったようだ。以下のパッチを適用することで、私の場合は問題が解決しました。 --- sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb.ORIG 2026-07-13 16:02:28.733344421 +0200 +++ sources/meta-nxp-demo-experience/recipes-examples/imx-car-navigation/imx-car-navigation.bb 2026-07-13 16:02:11.178539144 +0200 @@ -14,6 +14,7 @@ do_configure[noexec] = "1" +do_compile[network] = "1" do_compile() { cd ${S} ただし、これはあくまで一時的な回避策であることに注意してください。これがデフォルトで許可されていない理由があります。コンパイルステップはネットワークアクセスを行わないはずです。

当请求 HMAC 验证作业时，HSE 返回“HSE_SRV_RSP_INVALID_PARAM” 您好，NXP团队， 我有一个使用 HMAC 验证作业的用例。触发作业加密驱动程序后抛出 DET，HSE 的响应为“HSE_SRV_RSP_INVALID_PARAM”。 我无法理解我当前的配置出了什么问题。请查收附件中的配置文件压缩包。 需要技术支持来解决问题。 谢谢！ 阿迪亚 Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job 嗨@lukaszadrapa ， 细节： 设备：S32K311 HSE固件：HSE_FW_S32K311_0_2_55_0 RTD：SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 谢谢！ 阿迪亚 Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job 嗨@WagdeoA 请问您能否确认一下您使用的是哪款设备、哪款RTD以及哪款HSE固件版本？ 此致， Lukas Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job 嗨@WagdeoA 您的配置没有问题。 在我这边运行正常。但一个可能的问题可能是标签的长度（secondaryInputLength）。 这可以在函数 Crypto_Ipw_HmacVerify 中找到： 如果重定向被禁用，则必须以比特为单位提供标签长度，而不是以字节为单位。难道这不是问题所在吗？ 此致， Lukas

IMXRT EDMA error IRQ handler is not implemented in the SDK Hi, The IMXRT EDMA API in the SDK seems to handle "happy case" interrupts correctly.  However, there doesn't seem to be any provision for handling error interrupts.  Not only that, but it appears there is one global DMA_ERROR_IRQHandler for all DMA.  So if you're using both DMA0 and DMA1, when things are "happy" the DMA0/DMA1 IRQHandler would be called and the SDK can distinguish which DMA got the happy interrupt.  However, if there's a DMA error, since there's one global error interrupt handler, there's no easy way to know which DMA (0 or 1 or whatever) the error happened on. As in my previous question about LPUART error IRQ handling.  Why isn't this baked into the SDK to handle DMA errors and call appropriate callbacks?  Now I have to figure out how to determine which DMA the error is on by hand and call special handling outside the SDK instead of just having it call a callback for me. For an SDK that is supposed to be usable in production code, there seem to be a lot of missing robustness features, and I'm betting most people are just assuming these errors are handled under the hood by the SDK, and they don't think about the fact that they really aren't. -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK Dear @nxp16 , Which i.MX RT device are you using? When you mention DMA0 and DMA1, are you referring to two DMA channels rather than two DMA controller peripherals? Not all i.MX RT devices have two eDMA controllers. For example: i.MX RT1180 contains two eDMA controllers. In the startup file (for example, startup_mimxrt1189_cm33.c), you can find two DMA error handlers: DMA_ERROR_IRQHandler and DMA4_ERROR_IRQHandler. i.MX RT1050 contains only one eDMA controller. In the startup file (for example, startup_mimxrt1052.c), there is only one DMA error handler: DMA_ERROR_IRQHandler. In general, DMA errors are relatively infrequent events. From the hardware architecture perspective, channel error status is aggregated into a module-level error request, which triggers the DMA error interrupt. Therefore, the software must examine each channel's error status register (for example, CHn_ES) to determine which specific channel caused the error. Best Regards, Shelly Zhang Re: IMXRT EDMA error IRQ handler is not implemented in the SDK Sorry, I meant channel.  I'm using IMXRT1172. Wouldn't DMA errors occur if there was a problem with whatever peripheral it was being used with?  I.e. if it was LPSPI with DMA wouldn't any SPI errors cause a DMA error?  If not, then do SPI errors when using DMA trigger a SPI error interrupt? Thanks, -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK I figured as much.  In that case, the SDK's transfer API is even less robust.  Having to handle peripheral and DMA errors outside the SDK requires quite a bit of extra work, including somewhat hacky overriding of the default IRQ handlers and making sure they still call into the SDK handlers after processing any errors.  The fact that this stuff isn't part of the SDK transfer API is very discouraging. Re: IMXRT EDMA error IRQ handler is not implemented in the SDK Dear @nxp16 , No. A peripheral error occurring while using DMA does not necessarily mean that the DMA controller itself will report an error. In most cases, SPI errors and DMA errors are handled by two separate status and interrupt mechanisms. DMA reports only DMA-, bus-, or transfer-layer errors. Protocol-level or FIFO-related errors in LPSPI should be handled through the LPSPI peripheral's own status flags and error interrupts. Operating in DMA mode does not automatically convert all SPI errors into DMA errors. Best Regards, Shelly Zhang Re: IMXRT EDMA error IRQ handler is not implemented in the SDK Dear @nxp16 , I understand your concern, and I agree that handling peripheral error conditions separately from the SDK transfer API can increase the amount of application-level code required. Thank you for the feedback. I will pass your comments to the SDK team. Best Regards, Shelly Zhang

新建项目向导失败：未自动添加 FreeRTOS 端口 大家好， 我正在尝试使用 MCUXpresso IDE V24.12 为 LPC5536 创建一个基于 freeRTOS 的项目。 “创建新的 C/C++ 项目”向导（可从快速入门面板获取）似乎提供了一种简单的方法，可以将 freeRTOS 支持添加到项目中（请参见下方屏幕截图中的标记）： 如您所见，“新建项目向导”提供了一个复选框，用于添加 freeRTOS 作为“操作系统”。选中此复选框后，向导会自动添加 freeRTOS 的另一个关键部分——内存管理器（请参见下方标记的复选框）： 然而，该向导未能添加freeRTOS 中最重要的部分，即 MCU 特定的代码（请参见下方屏幕截图中的标记）： 如果您不自行选择此元器件，则生成的项目会抛出编译错误。我认为“新建项目向导”应该始终生成一个可编译的项目。此外，MCUXpresso IDE 手册明确指出：“同时，选择一个元器件会自动选择其所有依赖项。”（第 5.1.1 节）SDK 新建项目向导）。 我认为这至少是一个用户体验方面的缺陷。 我希望这个问题能在下一个 SDK / MCUXpresso 版本中得到修复。 谢谢。 丹尼尔 Re: New Project Wizard fAiL: no freeRTOS port added automatically 我使用 MCUXpresso IDE v25.6（撰写本文时的最新版本）和 LPC5536 SDK（版本 25.06，清单 3.15）进行了尝试，但 FreeRTOS 内核和 cm33 端口之间的依赖关系仍然缺失，需要手动选择。 Re: New Project Wizard fAiL: no freeRTOS port added automatically 你好@EdwinHz ， 感谢您的及时支持。 谢谢。 丹尼尔 Re: New Project Wizard fAiL: no freeRTOS port added automatically 嗨@danielholala ， 我重现了这个问题，这绝对是一个 bug，因为项目向导应该会自动选择所有依赖项。我会将此问题报告给 IDE 团队，以便他们可以在 MCUXpresso 项目向导的未来版本中进行修正。 感谢您报告此问题。 BR， 埃德温。

i.MX8M PLUS) 交換部品互換性 LPDDR4 NXP様、 I.MX8PLUS EVBで使用されたLPDDR4部品である*Z2BMは生産終了です。 部品供給業者は、交換部品として**Z2BMと***Z42BMを推奨しています。 *Z2BM: MT53E1536M32D4DT-046 WT:A (EVB部品) **Z4BM: MT53E1536M32D4DE-046 WT:C (交換部品 1) ***Z42M: MT53E1G32D2FW-046 WT:BP (交換部品 2) これら2種類の交換部品を使用しても問題ないかどうかお伺いしたいのですが。 よろしくお願いします。 よろしくお願いいたします。 チョン・インホ Ace テクノロジ Re: i.MX8M PLUS) Replacement part compatibility LPDDR4 こんにちは、 @Inho さん。 上記の2種類のDRAMは問題なく使えます。 BR

运行外部闪存 大家好， 我正在使用 MCXN547-EVK 开发板，并尝试 使用 四通道SPI (FlexSPI) 接口连接外部 W25Q64JWTBJQ 闪存 。我正在使用 IAR Embedded Workbench 构建项目 。 在使用 MCUXpresso SDK 构建spi_flash示例时，我遇到了以下错误： CMake Error: Cannot find source file: .../examples/_boards/mcxn5xxevk/demo_apps/spi/spi_flash/cm33_core0/pin_mux.c 之前有人遇到过这个问题吗？请问您能否帮我分析一下造成这种情况的原因以及如何解决？ 任何建议都将不胜感激。谢谢你！ MCX N Re: Run External Flash 你好@Ashish-625 请您确认一下 pin_mux.c 文件是否正确。文件是否存在于以下路径？ examples/_boards/mcxn5xxevk/demo_apps/spi/spi_flash/cm33_core0/pin_mux.c   此外，请确认您使用的是哪个 MCUXpresso SDK 版本，以及 spi_flash 演示是否基于 IAR Embedded Workbench 下载。   谢谢！   BR 爱丽丝

Offering Contribution: Complete PFE Plugin for S32DS, LWIP Integration & tcpip/LLCE Fixes Hello NXP Team and S32G Community, I have developed a complete PFE plugin for S32 Design Studio (S32DS) / S32 Configuration Tools. Previously, PFE configuration support was available only through EB Tresos. The new plugin includes: Full native integration within the S32DS environment Seamless integration with NXP’s official tcpip plugin for LWIP stack support Complete TSN traffic shaper configuration (TAS and CBS) Thorough testing with LWIP and LLCE, including offload scenarios In the process, I also identified and resolved several bugs in the official tcpip and LLCE plugins. This enhancement enables smoother development of advanced Ethernet and TSN applications on S32G platforms. I would like to contribute the full plugin, integration components, bug fixes, documentation, and test results to NXP. This could be integrated into future RTD or S32 Configuration Tools releases, or shared as an official reference for the community. Questions for the NXP Team: What is the recommended process to formally submit this contribution (e.g., via a technical support case or other channel)? Are there any particular requirements regarding documentation, packaging, or agreements (such as NDA)? I have prepared a comprehensive package including the plugin files, installation/integration guide, detailed changelog, and verification results. I am happy to share it privately and support any technical review or discussion. Thank you in advance for your guidance. I look forward to your feedback. Best regards, Arsal Imam SDV Architect @ GK Automobiltechnologie (Disrupt) GoldVIP Re: Offering Contribution: Complete PFE Plugin for S32DS, LWIP Integration & tcpip/LLCE Fixes Hi，arsalimam First of all, thank you for sharing this impressive work and for your willingness to contribute it to the NXP. The functionality you described—including native S32 Design Studio integration, LWIP/tcpip integration, TSN traffic shaping support (TAS/CBS), LLCE validation, and the related bug fixes—appears very valuable for S32G Ethernet and TSN development. At this stage, contributions of software components, plugins, and modifications to existing NXP tooling require review by the relevant product and software teams. As the acceptance process may involve technical evaluation as well as intellectual property and legal considerations. You can share your materials through our customer support system: https://support.nxp.com We appreciate your effort and your interest in improving the S32G software ecosystem. BR Joey

i.MX8M PLUS）替换部件兼容性 LPDDR4 尊敬的恩智浦： *Z2BM 是 I.MX8PLUS EVB 中使用的 LPDDR4 元器件，现已停产。 零件供应商推荐使用 **Z2BM 和 ***Z42BM 作为替换零件。 *Z2BM：MT53E1536M32D4DT-046 WT:A（EVB部件） **Z4BM：MT53E1536M32D4DE-046 WT:C（替换零件 1） ***Z42M：MT53E1G32D2FW-046 WT：BP（替换零件 2） 我想咨询一下，使用这两种类型的替换零件是否可以。 谢谢！ 顺祝商祺！ 全仁浩 艾斯科技 Re: i.MX8M PLUS) Replacement part compatibility LPDDR4 嗨@Inho 您可以毫无问题地使用上述两种类型的动态随机存取存储器(DRAM)。 BR

HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job Hello Nxp team, I have use case to use HMAC verify job. After triggering the job crypto driver throw DET and the response from HSE is "HSE_SRV_RSP_INVALID_PARAM". I am not able to understand what wrong with my current configuration. could you please check attached config zip file?  Need support to resolve issue. Thanks, Aditya Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job Hi @lukaszadrapa , Details: Device: S32K311 HSE FW: HSE_FW_S32K311_0_2_55_0 RTD: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 Thanks, Aditya Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job Hi @WagdeoA  Could you confirm which device, which RTD and which HSE firmware version you have? Regards, Lukas Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job Hi @WagdeoA  There’s no problem in your configuration. It works on my side. But one possible issue could be the length of tag (secondaryInputLength). This can be found in function Crypto_Ipw_HmacVerify: If redirection is disabled, it’s necessary to provide the length of tag in bits, not in bytes. Isn’t this the problem? Regards, Lukas

如何为我们使用的 i.mx RT1062 路由器获取唯一的以太网 MAC 地址？ 你好， 我们使用MIMXRT1062DVL6B，并通过以太网实现我们的产品。 首先，我们使用 `fsl_silicon_id.c` 中的 ` SILICONID_ConvertToMacAddr`为我们的产品实现 MAC 地址，以便使用 NXP 的 OUI 和硅 ID 为每个设备获取唯一的 MAC 地址。 但是，我们通过` SILICONID_ConvertToMacAddr`获取的 MAC 地址并不唯一，它们都相同。 我有个问题。 在调用 `SILICONID_ConvertToMacAddr` 之前，我们需要做哪些设置？ 或者，`SILICONID_ConvertToMacAddr` 无法通过 NXP 设备获取唯一的 MAC 地址？ 我们在 IMXRT1060RM.pdf 的 Rev. 4, 01/2026 中找不到答案。 您能给我们答案吗？ 谢谢。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? 嗨，阿布纳 感谢您的支持！ 我们了解到，我们可以使用通过SILICONID_ConvertToMacAddr 函数获取的 MAC 地址作为我们产品的 MAC 地址。但我明白 SILICONID_ConvertToMacAddr 只是一个示例，我们不能将其用于我们的大规模产品。我们必须使用我们 OUI 下的 MAC 地址。 顺祝商祺！ 茂 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? 嗨@shigeru-tsujita 感谢您发现这种情况。我们使用 SILICONID_ConvertToMacAddr 函数来减少 NXP MCUX SDK 示例中的 MAC 地址冲突，以用于我们的测试环境。我们在同一交换机上连接不同 SoC 的以太网接口。对于同一系列 SoC 的情况，我们可能无法涵盖。 但我不太明白的是，为什么你们要用这种方式生成产品 MAC 地址。首先，您的 OUI 应该使用您公司的 OUI。那么，我认为贵公司应该对唯一标识符有一个内部特殊定义。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? 你好，梅。 我理解 SILICONID_ConvertToMacAddr 使用固定的 NXP OUI 和三个字节的硅 ID（它是 OCOTP->CFG0/1 的一部分）来生成 MAC 地址。 我观察了我们目标产品的 OCOTP->CFG0/1。 这些数值如下： - 一个 MIMXRT1062 - OCOTP->CFG0: (uint32_t)0x615c'faa4 - OCOTP->CFG1: (uint32_t)0x2a1e'61d7 - 其他 MIMXRT1062 - OCOTP->CFG0: (uint32_t)0x615c'faa4 - OCOTP->CFG1: (uint32_t)0x4922'61d7 因为 OCOTP->CFG0 的低三个字节在 SILICONID_ConvertToMacAddr 中用作 MAC 地址，所以它们的 MAC 地址相似。 因此，我们很多产品的 MAC 地址都很相似。（现在我们有几十个原型机，虽然我们不会检查所有的 MAC 地址，但我们还没有找到与 54:27:8D:A4:FA:5C 不同的 MAC 地址。） 谢谢。 Re: How can I get unique ethernet MAC address all over the i.mx RT1062 we use? 嗨@shigeru-tsujita ， 非常感谢您对我们产品的关注以及对我们社区的使用。 假设 SDK 的 silicon_id 元器件已正确集成，则在调用 MIMXRT1062 的 SILICONID_ConvertToMacAddr() 之前无需进行其他设置。 请注意，SILICONID_ConvertToMacAddr() 不使用完整的 64 位硅 ID 来生成 MAC 地址。它使用固定的 NXP OUI 作为前 3 个字节，而最后 3 个字节仅使用来自硅 ID 的 3 个字节。 根据SDK代码： 请您读取几个设备的 64 位硅唯一 ID，并检查 ID 值是否读取正确？另外，请比较 siliconId[0]、siliconId[1] 和 siliconId[2]，因为这些是用于生成 MAC 地址的字节。 如果这三个字节在各个设备上都相同，则生成的 MAC 地址也将相同。 顺祝商祺！ 5月

外部フラッシュを実行する こんにちは、みんな、 私は MCXN547-EVK 開発ボードを使っており、 Quad SPI(FlexSPI) を使って外部 W25Q64JWTBJQ フラッシュメモリ とインターフェースしようとしています 。 私は IAR Embedded Workbench でプロジェクトを構築しています 。 MCUXpresso SDKからspi_flash例を構築していると、以下のエラーに遭遇しました: CMake Error: Cannot find source file: .../examples/_boards/mcxn5xxevk/demo_apps/spi/spi_flash/cm33_core0/pin_mux.c 以前にこの問題に遭遇した方はいますか？原因と解決方法を教えていただけませんか? 何かご提案があれば大変ありがたいです。ありがとう！ MCX N Re: Run External Flash こんにちは、 @Ashish-625さん pin_mux.c.がファイルは以下のパスに存在しますか？ examples/_boards/mcxn5xxevk/demo_apps/spi/spi_flash/cm33_core0/pin_mux.c   さらに、どのMCUXpresso SDKバージョンを使用しているか、またspi_flashデモがIAR Embedded Workbenchベースのダウンロード版かどうかも確認してください。   よろしくお願いします。   BR アリス

i.MX8M PLUS) Replacement part compatibility LPDDR4 Dear NXP,  The *Z2BM, an LPDDR4 component used in the I.MX8PLUS EVB, has been discontinued. The parts supplier has recommended the **Z2BM and ***Z42BM as replacement parts. *Z2BM: MT53E1536M32D4DT-046 WT:A (EVB Part) **Z4BM: MT53E1536M32D4DE-046 WT:C (Replacement Part 1) ***Z42M: MT53E1G32D2FW-046 WT:B P (Replacement Part 2) I would like to inquire if it is acceptable to use these two types of replacement parts. Thank you. Best Regards, Inho Jeon Ace Technologies Re: i.MX8M PLUS) Replacement part compatibility LPDDR4 Hi @Inho  You can use  two types of DRAM mentioned above without any problems. B.R

IMXRT EDMAエラーIRQハンドラはSDKには実装されていません こんにちは、 SDK内のIMXRT EDMA APIは「ハッピーケース」割り込みを正しく処理しているようです。しかし、エラー割り込みを処理するための仕組みは見当たらないようだ。それだけでなく、すべてのDMAに対して1つのグローバルなDMA_ERROR_IRQHandlerが存在するようです。例えばDMA0とDMA1の両方を使っている場合、状況が「良好」な状態にあるときにDMA0/DMA1のIRQHandlerが呼び出され、SDKがどのDMAがハッピーインタラプトを受け取ったかを識別できます。しかし、DMAエラーが発生した場合、グローバルなエラー割り込みハンドラが1つしかないため、どのDMA（0、1、またはその他）でエラーが発生したかを簡単に知る方法はありません。 以前の質問で、LPUARTエラーIRQ処理について質問したのと同様です。なぜこれがSDKに組み込まれていて、DMAエラーを処理したり適切なコールバックを呼び出したりしないのでしょうか?今は、エラーがどのDMAにあるかを手作業で特定し、SDK外の特別な処理を呼ぶ方法を考えなければなりません。単にコールバックを呼んでもらうのではなく。 本番コードで使えるはずのSDKにしては、堅牢性の機能が欠けているように思えますし、多くの人はこれらのエラーがSDKによって処理されていると思い込んでいて、実際にはそうではないという事実を考えていないのだと思います。 -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK @nxp16様、 どのi.MX RTデバイスをお使いですか？DMA0とDMA1の話ですが、2つのDMAコントローラペリフェラルではなく、2つのDMAチャネルのことを指していますか? すべての i.MX RTデバイスに2つのeDMAコントローラーがあるわけではありません。例えば： i.MX RT1180には2つのeDMAコントローラが含まれています。スタートアップファイル(例:startup_mimxrt1189_cm33.c)には、DMA_ERROR_IRQHandlerとDMA4_ERROR_IRQHandlerの2つのDMAエラーハンドラがあります。 i.MX RT1050にはeDMAコントローラが1つしかありません。起動ファイル（例えば、startup_mimxrt1052.c）では、DMAエラーハンドラはDMA_ERROR_IRQHandlerという1つだけです。 一般的に、DMAエラーは比較的まれなイベントです。ハードウェアアーキテクチャの観点からは、チャネルエラーの状態はモジュールレベルのエラー要求に集約され、DMAエラー割り込みを引き起こします。したがって、ソフトウェアは各チャネルのエラーステータスレジスタ(例えばCHn_ES)を調べ、どの特定のチャネルがエラーを引き起こしたかを特定しなければなりません。 よろしくお願いいたします。 シェリー・チャン Re: IMXRT EDMA error IRQ handler is not implemented in the SDK すみません、チャネルのことを言いました。私はIMXRT1172を使用しています。 もし使っていた周辺機器に問題があった場合、DMAエラーは起こるのではないでしょうか?つまり、LPSPIとDMAを組み合わせた場合、SPIエラーが発生するとDMAエラーも発生するのではないでしょうか？そうでない場合、DMA使用時のSPIエラーはSPIエラー割り込みをトリガーしますか？ ありがとうございます -m Re: IMXRT EDMA error IRQ handler is not implemented in the SDK @nxp16様、 いいえ。DMA使用中に周辺エラーが発生しても、必ずしもDMAコントローラ自体がエラーを報告するわけではありません。ほとんどの場合、SPIエラーとDMAエラーは2つの別々のステータスおよび割り込み機構で処理されます。 DMAは、DMA、バス、または転送層のエラーのみを報告します。LPSPIにおけるプロトコルレベルまたはFIFO関連のエラーは、LPSPIペリフェラル自身のステータスフラグやエラー割り込みを通じて処理されるべきです。DMAモードで動作させた場合でも、すべてのSPIエラーが自動的にDMAエラーに変換されるわけではありません。 よろしくお願いいたします。 シェリー・チャン Re: IMXRT EDMA error IRQ handler is not implemented in the SDK やはりそうだったか。その場合、SDKの転送APIはさらに堅牢性が低くなります。SDK外でペリフェラルやDMAエラーを処理しなければならない場合、デフォルトのIRQハンドラをやや巧妙にオーバーライドしたり、エラープロセッシング後もSDKハンドラーに呼び出すようにするなど、かなりの追加作業が必要です。これらの機能がSDKの転送APIに含まれていないのは非常に落胆します。 Re: IMXRT EDMA error IRQ handler is not implemented in the SDK @nxp16様、 ご懸念は理解できますし、SDKトランスファーAPIと別にペリフェラルエラーを扱うことで必要なアプリケーションレベルのコード量が増えることに同意します。ご意見ありがとうございます。皆さんのご意見はSDKチームにお伝えします。 よろしくお願いいたします。 シェリー・チャン

Battery Management System - Overview 1 Table of Contents • Introduction • Overview • Target Audience • Context • References • Conclusion 2 Introduction A Battery Management System (BMS) is a system that monitors and manages a battery pack to ensure it operates safely, efficiently, and reliably, making it a critical component in electric vehicles. Its main functions include measuring voltages, currents, and temperatures and balancing the cells to maintain consistent performance. This overview introduces a series on the architecture, development and integration of a battery management system developed using NXP hardware and software. To accelerate this process, MathWorks ecosystem is used to streamline the development, maintain traceability from model to implementation and to validate complex embedded applications.   3 Overview Articles roadmap Developing a battery management system is a complex undertaking, and explaining it thoroughly requires a structured series of articles. Each article focuses on a key stage of the development process, offering detailed insight into how such a system is designed, implemented, tested, and validated from concept to deployment. The series includes the following articles: Software and Hardware Environment - An overview of the required software environment, including NXP software development kits (SDKs), real-time drivers (RTDs), and MathWorks toolboxes, together with the hardware platform used in the application. Architecture and Model Description - A detailed description of the system architecture, including the model structure, input and output signals, and the core algorithms used in the battery management system. Validate the BMS Algorithms (Model-in-the-Loop) - An explanation of how validated MathWorks battery management assets - such as state-of-charge (SoC) and state-of-health (SoH) estimation algorithms - can be adapted, integrated, and verified within the application model. Preparing BMS Algorithms for Code Generation (Software-in-the-Loop) - Guidance on generating production-oriented code from validated models and running software-in-the-loop (SiL) simulations to compare code behavior against the model-in-the-loop (MiL) baseline. Bringing the BMS Closer to Hardware (Processor-in-the-Loop) - Steps to prepare the model for execution on target hardware by deploying the generated software to an NXP evaluation board while emulating battery measurements on a host PC. Deployment and Validation on the High-Voltage BMS Reference Design Kit - Configuration of external devices to supply real data to the BMS algorithms, followed by system-level validation. Extending the Controller with CAN Communication - Integration of controller area network (CAN) communication by defining the CAN database, configuring the communication stack, and validating message exchange on the NXP hardware. Final Results - A summary and discussion of results, along with final validation of the complete battery management system. What is the Battery Management System? A Battery Management System (BMS) is a combined hardware and software system responsible for monitoring, controlling, and protecting an electric vehicle's battery pack. Technically, it acts as the central authority that has full visibility into the battery's operating conditions, such as cell voltages, pack current, and temperatures. Based on this information, the BMS makes real-time decisions to keep the battery within safe operating limits. It also enforces critical protections - such as preventing overcharge, over-discharge, over-temperature, or short-circuit conditions - which are essential for safety, reliability, and regulatory compliance. From a functional perspective, the BMS performs several key jobs that directly impact vehicle performance and longevity. These include estimating battery states such as State of Charge (SoC), State of Health (SoH), and available power, which higher-level vehicle systems rely on for range prediction and energy management. The BMS also manages cell balancing, ensuring that individual cells within the pack age uniformly and maintain similar voltage levels. This combination of accurate state estimation and active control helps maximize usable energy, protect the battery from accelerated degradation, and maintain consistent performance throughout the vehicle's life. On the hardware side, a BMS typically consists of sensing components (voltage, current, and temperature sensors), cell monitoring and balancing ICs, a microcontroller, isolation components, and communication interfaces. These elements work together to acquire high-precision measurement data from the battery pack and execute control actions such as enabling contactors or activating balancing circuits. In many architectures, the system is distributed, with multiple cell monitoring units communicating with a central BMS controller. The software layer ties everything together and is often the most complex part of the system. BMS software includes low-level drivers for sensors and communication, real-time control logic, diagnostic and fault-handling mechanisms, and advanced algorithms for state of charge estimation. It must integrate seamlessly with the rest of the vehicle through networks such as CAN, allowing the BMS to exchange data with vehicle control units, chargers, thermal management systems, and the powertrain. Through this tight hardware-software integration, the BMS becomes a core enabler of safe operation, efficient energy use, and coordinated vehicle behavior. 4 Target Audience This article series is intended for engineers, technical specialists, and decision-makers involved in the development, integration, or evaluation of high-voltage battery management systems for electric vehicle applications. It is especially relevant for readers who want to understand how BMS algorithms, embedded software, hardware platforms, and validation workflows come together in a complete development process. The content is suitable for both engineers looking for practical implementation guidance and technical stakeholders interested in the benefits of using a Model-Based Design approach with MathWorks and NXP solutions. The main target audience includes: Embedded software engineers Control and algorithm engineers Battery system engineers Electric vehicle system architects Model-Based Design engineers Hardware and integration engineers Test and validation engineers Technical managers and project leads 5 Context In the electric vehicle architecture presented in this series, the Battery Management System is located in the rear zone of the vehicle. It is a safety-critical controller responsible for battery supervision, but it operates within a highly interconnected ecosystem. It bridges: Battery pack (physical layer) Vehicle Control Network (communication layer) Powertrain and Vehicle Behavior (functional layer) The HVBMS is implemented on the reference design bundle for 800 V high-voltage battery management systems. It provides a complete hardware solution including: RD-K358BMU - battery management Unit (BMU) RD33774CNT3EVB - cell monitoring unit (CMU) RD772BJBTPL8EV - battery junction box (BJB) 18 Cell Battery Pack Emulator 6 References Speed-Up BMS Application Development with NXP's HVBMS RD and Model-Based Design Toolbox (MBDT) Model-Based Design Toolbox NXP Community 800 V Battery Management System (BMS) Reference Designs Using ETPL Model-Based Design Toolbox (MBDT) 7 Conclusion This article introduced the Battery Management System within the context of an electric vehicle architecture and established the technical foundation for the rest of the series. It described the role of the Battery Management System and illustrated how a Model-Based Design workflow can be implemented by combining the MathWorks and NXP ecosystems. The next article will focus on the software and hardware environment needed to develop, simulate, and deploy a Battery Management System using MathWorks and NXP solutions.