Unable to Debug dio_ToggledLED_S32K144 Example – Debug Error After Flashing Hi, I am working with S32K144 using S32 Design Studio 3.4. I tried debugging the dio_ToggledLED_S32K144 example project. The code flashes successfully, and I can see the LED toggling output initially. However, after some time, an error window appears, and after that, I am not able to continue debugging. Due to this issue, I am unable to debug the application properly. Could you please help with the following: What could be the possible reason for this debug error appearing after flashing? Is this related to debugger connection (J-Link / PEMicro), watchdog, or clock configuration? Are there any known issues with the dio_ToggledLED_S32K144 example in S32 Design Studio 3.4? What are the recommended steps to resolve this issue and debug the project correctly? Any guidance to resolve this issue would be very helpful. Thank you for your support. Re: Unable to Debug dio_ToggledLED_S32K144 Example – Debug Error After Flashing Hi Julián, Thank you for your response. Please find the details below: The issue appears after running the project for a few seconds to about one minute. Initially, the code runs correctly and the LED toggles, but after some time, a debug error window appears, and the debug session stops. When the issue occurs, I am not able to continue debugging. In some cases, I need to terminate the debug session and restart S32 Design Studio to flash the MCU again. I will recheck and confirm the PEmicro driver version. Currently, I am using the default PEmicro version installed with S32 Design Studio 3.4. To clarify, this issue is not only with the Dio example code. I created a separate user application (custom GPIO project) from scratch. In this user-created project, I enabled the following MCAL components: Mcu Port Dio Dem Ecuc In the Dio configuration, I selected RED LED (Dio channel 15). When I debug this user-created GPIO application, I face the same debug issue, similar to the one shown in the attached image. Based on this, the problem seems to be related to the debug configuration or PEmicro connection, rather than the Dio example logic itself. Please let me know if you need any additional details or logs from my side. Re: Unable to Debug dio_ToggledLED_S32K144 Example – Debug Error After Flashing Hi @KAVIN7, No, there should not be any problems with the Dio example, as the project only toggles a LED. Could you provide a bit more information about how to reproduce your issue? 1. How long are you running the project before the issue appears? 2. When the issue happens, are you able to reload the debug session and flash the MCU again? 3. Can you confirm you have the latest Pemicro version available? 4. Have you modified the project in any way? This issue seems to point to PEmicro drivers or debug configuration, as the Dio example does not configure anything related to watchdog or power modes. Best regards, Julián Re: Unable to Debug dio_ToggledLED_S32K144 Example – Debug Error After Flashing Hi @KAVIN7, Looking through your configuration, I can see you do not have any pins configured in the "UnTouchedPortPin" container. In order to be able to use the debug capabilities, the JTAG and Reset pins need to be configured in the Port driver using mechanism B. This means that the following pins/functionalities need to be added in the UnTouchedPortPin list: 4, 5, 10, 68 & 69. Julin_AragnM_0-1769798262371.png This may not be your root cause, since your issue appears after running the project for some time, but it does not hurt to try. Like I've said in my previous response, you can also try updating your SW. Latest versions are: S32DS: 3.6.5 S32K1 RTD: 3.0.0 Pemicro: 6.1.7  Lastly, please try sharing a log form the debug interface, as well as debug configuration, as it is very difficult to pinpoint an issue like this, as it cannot be reproduced on my side. Here is my debug configuration which seems to work correctly: Julin_AragnM_1-1769798396741.png Julin_AragnM_2-1769798399613.png Julin_AragnM_3-1769798403492.png Julin_AragnM_4-1769798407178.png Julin_AragnM_5-1769798417111.png Best regards, Julián Re: Unable to Debug dio_ToggledLED_S32K144 Example – Debug Error After Flashing Hi, Thank you for the information. However, I believe the issue discussed in this thread (Unable to Debug dio_ToggledLED_S32K144 Example — Debug Error…) is not the exact problem I’m facing. My issue is described in this other ticket instead, where I’m getting a PE Micro Connection Assistant error due to missing port configuration: https://community.nxp.com/t5/S32K/PE-Micro-Connection-Assistant-Error-Due-to-Missing/m-p/2303757#M56494 In my case: I created a custom GPIO application for LED toggle. I enabled only the RED LED pin in Dio/Port configuration. I did not enable the “UntouchedPortPin” debug pins (JTAG/RESET/XTAL/EXTAL). This results in the PE Micro connection failure, as shown in the attached image in that ticket. I believe the issue is related to missing port pin configuration required for debug interfaces (JTAG/RESET/XTAL/EXTAL), and not a problem with the dio example itself. I need this resolved because I cannot proceed with further implementation until the basic debug connection works. Could someone please review the linked ticket and advise on the correct pin configuration or steps to fix the debug connection issue? Thank you.

8CH-DMIC board configuration, flashing and testing on MIMXRT685-EVK Hi, I’m trying to run the dmic_multi_channel CM33 demo on EVK-MIMXRT685 with the 8-DMIC array board. Per the demo documentation, enabling the 8-DMIC board on J31 requires moving several resistors (e.g. R379, R380, R384, R389, R390, R391, R392 to 2–3). After doing this, FlexSPI Octal Flash (U19) becomes inaccessible: - LinkServer flashing fails - ROM ISP (blhost) connects, but FLEX-SPI-NOR shows Sector Size = 0 / Page Size = 0 - Flash erase/write is impossible My questions: Is this demo expected to run without Octal Flash (RAM-only workflow)? Is there an official flashing/boot procedure after the resistor changes? Are all resistor changes required, or can some remain in the default state to keep FlexSPI flash working? Right now it looks like the required DMIC hardware setup prevents normal flash programming/boot. How can I test and run the demo? Thanks for any guidance. MIMXRT685-EVK 8CH-DMIC  i.MXRT 600 Re: 8CH-DMIC board configuration, flashing and testing on MIMXRT685-EVK Hi @mlkezarev , Thank you so much for your interest in our products and for using our community. Q1:  Is this demo expected to run without Octal Flash (RAM-only workflow)? A1:   Yes. This demo is designed to run from SRAM only and does not require Octal Flash. Q2:Is there an official flashing/boot procedure after the resistor changes? A2: After the resistor changes are applied, the external Flash is physically disconnected. Therefore, flashing or booting from Flash is not supported in this hardware configuration. Q3:Are all resistor changes required, or can some remain in the default state to keep FlexSPI flash working? A3: If you want to enable 8 DMICs, all the specified resistor changes are required. I have post a pin configuration screenshot for your reference. mayliu1_0-1769497506571.png Q4: Right now it looks like the required DMIC hardware setup prevents normal flash programming/boot. How can I test and run the demo? A4: You can run on SRAM, just like the SDK demo "evkmimxrt685_dmic_multi_channel_cm33" mayliu1_1-1769497840920.png Best Regards MayLiu

T4240から間違ったIDCODEを読み取ったため、USB-TAP経由でダウンロードできません T4240 (T4240RDB に類似) をベースにしたボードをデバッグしています。私の問題は、Codewarrior で USB-TAP 経由でコードをダウンロードできないことです。 1.ハードコードされた RCW をテストしたところ、T4240 は電源投入後約 10 ミリ秒以内に RESET_REQ をアサートすることがわかりました。 2. Codewarrior によって「JTAG チェーンを正しく構成できませんでした」というエラー メッセージが表示され、コンソールに表示されるチップ IDCODE は、QorIQ T4240 リファレンス マニュアルに記載されている 0x0022001d ではなく、0x1022001d になります。 3. Codewarrior のコンソールの出力メッセージには、「エラー メッセージ: T4240: トランザクション中に HRESET が発生しました」と表示されました (以下に添付)。 4. 電源とクロックをすべて測定しましたが、問題ないようです。 誰かこの問題を解決するのを手伝ってくれませんか? ---------------------------------------------------------------------------- ccs_open ipaddr = 127.0.0.1 ポート = 41475 タイムアウト = 15 サーバーh = 0 ccs_open; ccs_error = 0 ccs_get_connection_count サーバーh = 0 カウント = 1 ccs_get_connection_count; ccs_error = 0 ccs_available_connections サーバーh = 0 カウント = 1 ccs_available_connections; ccs_error = 0 ccs_available_connections サーバーh = 0 カウント = 1 ccs_available_connections; ccs_error = 0 ccs_cc_バージョン サーバーh = 0 cc = 0 バージョン.メジャー = 1 バージョン.マイナー = 3 ccs_cc_version; ccs_error = 0 ccs_set_timeout サーバーh = 0 タイムアウト = 15 ccs_set_timeout; ccs_error = 0 ccs_available_connections サーバーh = 0 カウント = 1 ccs_available_connections; ccs_error = 0 ccs_config_server サーバーh = 0 cc = 0 サーバー構成 = 0 値 = 4040 ccs_config_server; ccs_error = 0 ccs_config_chain サーバーh = 0 cc = 0 device_list: (サイズ = 1) デバイス[0]:: core_type=テストコア(20) ccs_config_chain; ccs_error = 0 ccs_jtag_ロック サーバーh = 0 cc = 0 ccs_jtag_lock; ccs_error = 0 JTAG診断   プローブ テスト時の始動電力... テスト結果: 合格   IR スキャン テストを開始しています... テスト結果: 合格   バイパス スキャン テストを開始しています... テスト結果: 合格   任意の TAP 状態移動テストを開始しています... テスト結果: 合格   検出されたJTAG IDコード: OK デバイス0 IDコード: 0x1022001D   ccs_jtag_unlock サーバーh = 0 cc = 0 ccs_jtag_unlock; ccs_error = 0 ccs_config_chain サーバーh = 0 cc = 0 device_list: (サイズ = 1) デバイス[0]:: core_type=T4240(206) ccs_config_chain; ccs_error = 39 エラーメッセージ: T4240: トランザクション中に HRESET が発生しました ccs_get_subcore_error サーバーh = 0 cc = 0 エラー = 60 チェーン位置 = 0 ccs_get_subcore_error; ccs_error = 0; 期間=2ミリ秒 ccs_close サーバーh = 0 ccs_close; ccs_error = 0 Re: Wrong IDCODE read from T4240 and cannot download via USB-TAP こんにちは、 CW の問題のスクリーンショットを共有してください。RCW が間違っている可能性があります。RCWは SB_EN ビットが設定されたターゲットにロードされましたか? 他のボードでもこの問題は発生しますか? WCTAP が他のデバイスで正しく動作していることを確認できますか? Re: Wrong IDCODE read from T4240 and cannot download via USB-TAP サポートありがとうございます。スクリーンショットを以下に添付します。ハードコードされた RCW を使用しており、この場合 SB_EN は無効になっています。私は 5 つのボードを持っていますが、すべて同じ問題で動作しています。現時点では、USB-TAP をテストできるリファレンス ボードがありません。 Re: Wrong IDCODE read from T4240 and cannot download via USB-TAP こんにちは、 RCW が有効でないか、JTAG クロック速度が速いことが原因である可能性があります。JTAGクロック速度を下げて試してください。

MCXN647との接続問題（Ee(42)エラー） こんにちは、 FRDM-MCXN947に問題があります。プロジェクトをデバッグまたはフラッシュしようとすると、次のエラーが発生します。 PeterD_0-1766924466842.png PeterD_1-1766924526627.png 関係があるかどうかはわかりませんが、while(1) ループのこの行を変更して頻度を上げたときに発生しました: SDK_DelayAtLeastUs( 30000 , SystemCoreClock); -> SDK_DelayAtLeastUs( 10000 , SystemCoreClock); 問題が発生する前にアップデートしていなかったのですが、その後LinkFlashをアップデートしても何も解決しませんでした。 すでに SPT 消去を試しましたが、機能しませんでした。（多分、やり方が間違っていたのでしょう。） SPT では、ISP モードを有効にした後、「イメージの構築」および「イメージの書き込み」操作を実行できましたが、消去はまだ機能しません。 PeterD_3-1766926202287.png PeterD_4-1766926211594.png ご協力をよろしくお願いいたします。 追伸: 英語と専門用語が下手で申し訳ありません。私は工学部でこのプロジェクトを始めたばかりです。 ブートROM|ブート|フラッシュ クロック|タイマー MCX N USB Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Peter-D SPT ツール内のフラッシュ プログラマーを使用して、blinky SDK デモを消去およびプログラムし、正常に動作するかどうかを確認してください。詳細は添付の動画をご参照ください。 これらの手順がうまく機能しても、オンボード デバッガーでデバッグできない場合は、外部デバッガーを使用してテストしてください。 まだ問題がある場合は、お気軽にお問い合わせください。 よろしくお願いします。 BR アリス Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Alice_Yang 、 ご返信ありがとうございます。 ビデオの指示に従いましたが、その方法で LED が点滅しました。 ただし、MCUXpresso IDE からデバッガーに戻ると、同じエラーが発生します。 問題がオンボード デバッガーから発生している場合、特に私が使用しているボードは学校で貸与されたものなので、PEMicro や SEGGER J-Link (それが言及されている場合) などの外部デバッガーを購入するつもりはありません。 解決策が見つからない場合は、私のプロジェクトでも機能するフラッシュ プログラマーを引き続き使用し、教授に外部デバッガーがあるかどうかを尋ねます。 よろしくお願いいたします。 ピーター Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Peter-D あなたのボード上のデバッガーが実際に壊れているかどうかはわかりません。次の手順に従って、デバッガー ファームウェアを更新してください: https://docs.nxp.com/bundle/UM12018/page/topics/Updating_MCU_Link_firmware.html 更新後、ボードの電源を入れ直し、MCUXpresso IDE で新しいワークスペースを作成し、新しい SDK デモをインポートして、再度デバッグを試みます。 ビデオを撮って私と共有していただけると嬉しいです。確認をお手伝いします。 よろしくお願いします。     BR アリス Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Alice_Yang ご返信よろしくお願いします。 提案されたとおりに LinkServer を更新しましたが、問題が発生した後にすでに更新されていたと思います。とにかくもう一度アップデートを試み、ボードの電源を入れ直し、新しいワークスペースを作成し、デモ プロジェクトをインポートしましたが、デバッグしようとすると同じ Ee(42) エラーが発生します。 プロセスを示す短いビデオを録画したので添付します。 ご協力ありがとうございました。良い新年をお迎えください。 よろしくお願いします、 ピーター Re: Connection problem with MCXN647 (Ee(42) error) こんにちは@Peter-D ビデオをありがとう。 .launch ファイル (下の画像) を削除して、ボードを再度消去してください。 デバッグを開始するには、下の図に示すデバッグ ボタンを使用します。 Alice_Yang_0-1767148514011.png それでも動作しない場合は、ボードを交換することをお勧めします。 ちなみに、私は正月休みを頂き、1月5日に復帰します。もしご不明な点がございましたら、当日にお問い合わせください。 ご理解のほどよろしくお願いいたします。新年あけましておめでとうございます。 BR アリス

TMU 导致 LS1046a CPU 在 -40C 的低温室下 RESET 我们有一块基于 LS4046a 的板正在零下40摄氏度的温度箱中进行测试，系统已关闭，报告“温度过高”，如下所示。我在散热驱动器中添加了日志代码来报告关机时的确切温度，关机温度为 101 度，这让我们感到困惑，板的低温室低于 -40 摄氏度，为什么 TMU 报告了临界高温？ [2025-12-23 15:41:31.267] root@E7-2:~# [ 2435.041159] thermal thermal_zone0: ddr-controller：达到临界温度十六进制 0x18a88，十进制 101000，无符号 101000，正在关闭。 [2025-12-23 15:46:04.940] [ 2435.053636] 重新启动：硬件保护关闭（温度过高） Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 我与 AE 团队讨论了这个问题，请参阅他们的以下更新。 TMU 的指定测量范围为 0~110C。-40℃超出范围，寄存器值可能会被软件误读。 客户可参阅 AN12310 和 LSDK 用户指南第 11.3 章。 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 我还编写了一个脚本，在 -40C 环境下轮询温度寄存器（TRITSR0 - TRITSR4），大部分时间 V 位为 0（无效），但不时 V 位设置为 1（有效），当 V 位为 1 时，TEMP 字段显示高温，见下图，温度寄存器报告 0x65000080，其中 0x80 表示 V 位为 1，0x65 是温度值，十进制为 101 度。 temp_val=0x65000080, (temp_val& 0xff000000)=0x65000000, (temp_val& 0x000000ff)=0x00000080 为什么 TRITSR 寄存器的 V 位被设置为 -40C 下有效，从而误导软件读取无效温度？ kenny_zhou_1-1767488386337.png Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 请参阅 AE 团队提供的以下信息。 这不是错误，而是预期行为。 LS1046A TMU 的指定测量温度范围有限（约 0 °C 至 110 °C）。在 -40 °C 时，TMU 的工作温度超出其有效范围。 当温度超出范围时，TMU 仍会偶尔断言 V（有效）位，这意味着转换已完成，尽管转换结果没有物理意义。 与此同时，TMU 状态寄存器（TSR）中的 ORL（低电平超出范围）标志也会被确认。 如果软件仅检查 V=1 而忽略 ORL=1，它可能会将该值误解为正常温度（例如，0x65 → 101 °C），并触发错误的超温关机。 建议 在使用 TRITSR 温度值之前，请务必检查 ORL 标志。 如果 ORL=1，则将温度读数视为无效，与 V 位无关。 或者，推迟启用 TMU 监控，直到 SoC 温度恢复到有效范围内（≥0 °C）。 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 我检查了 ORL 位，似乎该位在检测超出范围的低温时并不可靠，如下所示 我的显卡在室温下运行，TMU 的温度约为 58 摄氏度。 root@E7-2:~# cat /sys/class/thermal/thermal_zone0/temp 58000 root@E7-2:~# cat /sys/class/thermal/thermal_zone1/temp 59000 读取 TMU 模式寄存器 (TMR) 和 TMU 状态寄存器 (TSR)，启用 TMU 模式并钳位 ORL root@E7-2:~# devmem 0x1f00000 w 0xFFFF008C root@E7-2:~# devmem 0x1f00004 w 0x000000A0 然后我禁用了 TMU 监控模式，发现 ORL 已被清除 root@E7-2:~# devmem 0x1f00000 w 0xFFFF008C root@E7-2:~# devmem 0x1f00000 w 0xFFFF000C #disable the monitoring mode root@E7-2:~# devmem 0x1f00000 w 0xFFFF000C root@E7-2:~# devmem 0x1f00004 w #ORL bit was cleared 0x00000020 然后我重新启用了 TMU 监控模式，ORL 位又被钳位 root@E7-2:~# devmem 0x1f00000 w 0xFFFF008C root@E7-2:~# devmem 0x1f00004 w 0x000000A0 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber TMU 温度测量范围为 0-125°C。 RM 表示寄存器 ORL - 检测到超出范围的低温测量值。温度传感器检测到的温度读数低于 0 摄氏度的最低可测量温度。TMU监控（重新）启用后，该位将自动清零。 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 该卡处于室温下而不是环境低于 0 摄氏度，TMU 报告 56 摄氏度，而 ORL 仍然钳位 ORL 表明低温超出范围，这没有道理，为什么即使卡在室温下也钳位 ORL 位？如前面的评论所示，我重新启用了 TMU 监控，重新启用 TMU 监控模式后，ORL 位仍处于钳位状态。 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 这个问题有什么新进展吗？ 上周，我们在另一种具有相同 CPU 的显卡上发现了同样的问题，我们想知道是否有解决方法，谢谢。 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 请参考我在 LS1046ARDB u-boot 上的验证结果。 => mw 0x1f000000x00F8000C => mw 0x1f000000x00F8008C => md 0x1f00100 1 01f00100:25000080...% => md 0x1f00004 1 01f00004:00000000.... = md 0x1f00004 1 01f00004:00000000.... => Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 请使用以下值配置寄存器0x1f00000。 => mw 0x1f00000 0x00F8000C => mw 0x1f00000 0x00F8008C Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 将 TMU 寄存器的 RESERVED 位（bits21 ~ bit31）设置为 0 似乎可以清除我的卡上的 ORL 位。如果这些保留位为 1，则无法清除 ORL，不知道为什么。总之，我会在 TMU 驱动程序中将这些位初始化为 0，然后在读取温度之前检查 ORL 位。谢谢 kenny_zhou_0-1769150337835.png Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber 是的，谢谢，我做到了，而且将再次进行 -40C 下的热测试，以检验代码的更改，希望它能通过测试。 Re: TMU caused LS1046a CPU reset at a -40C low temperature chamber root@LG871:~# devmem 0x1f00000 w 0x00F8008C //保留位为 0，则未钳位 ORL 位 root@LG871:~# devmem 0x1f00004 w 0x00000080 root@LG871:~# root@LG871:~# devmem 0x1f00000 w 0xFFF8008C //保留位为 1，然后 ORL 位钳位为 root@LG871:~# devmem 0x1f00004 w 0x000000A0

如何替换自定义板的 Yocto 电路板支持包中的 DDR 二进制文件？ 你好 正在尝试替换自定义板的 Yocto 电路板支持包 中的 DDR 二进制。 新计算机已创建，配方 ddr-firmware 的目录也是在自定义元层中创建的，其中包含所需的文件。但是，为 SRC_URI 分配新值并删除配方附加中的原始值并不能阻止 Bitbake 在评估板的原始路径中搜索。不使用配方追加也不会改变本次搜索的任何内容。 似乎唯一有效的方法是掩盖原始配方并在自定义层中创建新配方。 但我不认为这是一种可取的方式。使用为自定义计算机创建的 DDR 二进制文件应该很容易做到这一点。这里可能遗漏了什么？ 谢谢您！ 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 好的，它能用。似乎与 NXP_FIRMWARE_LOCAL_DIR 中设置的文件夹不一致。但不管怎么说，它还是有用的。 还有一个问题，如何关闭自定义层 .bbappend 中的 NXP-EULA 许可证？ 此致， 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，仙鹤 感谢您的回复。 客户的 DDR 还应该有 DDR 固件，你能否尝试参考 S32G3_Linuxbsp_44.0_user_Manual.pdf 在 Yocto 中版本电路板支持包期间添加 DDR 固件。 Joey_z_0-1766541662147.png BR 乔伊 Re: How to replace DDR binaries in Yocto BSP for the custom board? 你好，乔伊、 感谢您的回复。 它是 S32G3，电路板支持包 是 "bsp44.0"。 此致， 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，起重机 感谢您与我们联系。 你使用的是哪个版本的电路板支持包？ 您使用的是 S32G3 还是 S32G2 芯片？ BR 乔伊 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，乔伊、 添加 .bbappend 时尝试过，但不起作用用于定制板。 ERROR: /home/crane/work/yocto/sources/meta-alb/meta-alb-bsp/recipes-bsp/ddr-firmware/ddr-firmware.bb: Unable to get checksum for ddr-firmware SRC_URI entry NXP-EULA: file could not be found The following paths were searched: 尝试了 .bbappend只有 SUMMARY，LICENSE ="CLOSED" 和 LIC_FILES_CHKSUM ="" ，也试过不使用 .bbappend、都得到了相同的错误信息。 这是处理自定义 DDR 二进制文件的唯一方法是掩盖恩智浦的原始配方并创建自定义配方，而不是根据原始配方添加配方附加吗？ 此致， 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，仙鹤 请尝试修改文件夹 (fsl-auto-yocto-电路板支持包-build_s32g274ardb2/conf) 中 local.conf 文件。 accept_fsl_eula ="1" Joey_z_0-1766656675683.png BR 乔伊 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，起重机 您是否在文件夹中添加了 NXP-EULA 文件？ Joey_z_0-1766735378837.png BR 乔伊 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，乔伊、 我试图将这个文件复制到原始配方或自定义配方中，但都不起作用。两种方法都能找到文件，但都会产生以下错误信息： ERROR: No recipes in default available for: /home/crane/work/yocto/sources/meta-crane/recipes-bsp/ddr-firmware/ddr-firmware_%.bbappend 由于我没有使用恩智浦的DDR二进制文件，我认为使用恩智浦生成的NXP-EULA没有意义。禁用检查 NXP-EULA 是感知的，对吧？ 此致， 起重机 Re: How to replace DDR binaries in Yocto BSP for the custom board? 嗨，起重机 感谢您的回复。 我们应该找到问题的根源。请尝试在 Yocto 中版本 BSP44 以使用恩智浦的 DDR 固件和 NXP-EULA 文件。如果你能成功版本 BSP44，你可以尝试更换 DDR 固件，然后重新版本。 BR 乔伊

使用 PN7160 — P2P 与 Type-4 标签模式在两个 Linux 板之间共享 Wi-Fi DPP 凭证？ 您好，NXP团队， 我正在使用 PN7160 NFC控制器和恩智浦 Linux NFC 堆栈在两个 Linux 板（联发科 Genio 510 EVK）之间进行 Wi-Fi 接入 ： https://github.com/NXPNFCLinux/linux_libnfc-nci 系统设置 Board-1 (M1) 使用 hostapd 充当 Wi-Fi 接入点 (AP) PN7160 支持 NFC Board-2 (M2) 使用 wpa_supplicant 充当 Wi-Fi 站 (STA) PN7160 支持 NFC 目前是 手动配置凭证时，Wi-Fi 接入点/STA 连接正常工作 nfcDemoApp 中的 NFC 读/写和轮询示例正常工作 目标 我想使用以 NFC 作为引导通道的 Wi-Fi DPP（Easy Connect）自动配置从 M1（AP）到 M2（STA）的 Wi-Fi 凭证 ，这 与 Wi-Fi 联盟的入门操作类似。 问题 1.NFC 模式选择 对于两块板之间的 Wi-Fi DPP 凭证配置： 是否应使用NFC 点对点（P2P / LLCP / SNEP）模式？ 还是应该在接入点侧使用Type-4 Tag 仿真（NDEF、application/vnd.wfa.wsc 或 DPP URI），由 STA 充当 NFC 读卡器？ 从Wi-Fi联盟的参考资料来看，NFC似乎主要用作引导渠道，但我想确认一下在使用 PN7160 时推荐的NFC模式。 2.使用恩智浦 demoapp 使用现有的linux_libnfc-nci demoapp 示例： 能否将Type-4 标签仿真示例扩展到： 在 M1（接入点）上模拟 Wi-Fi 配置标签 向 M2（STA）提供 Wi-Fi 接入数据 对于 Wi-Fi DPP 上载，推荐还是不推荐使用NFC P2P + SNEP？ 3.Wi-Fi DPP 集成 一旦在 M2 上接收到 NFC 数据： 是建议的流量： NFC → DPP 引导信息（URI/公钥） 然后使用 wpa_supplicant通过 Wi-Fi 进行 DPP 验证？ 恩智浦是否有集成方面的参考示例或指南： PN7160 NFC 栈 Linux wpa_supplicant DPP 命令 可实现AP-STA 自动连接？ 摘要 我正在寻求以下方面的指导： Wi-Fi DPP 的正确 NFC 模式（P2P 与 Type-4 标签 如何重复使用或扩展现有的恩智浦演示应用程序 推荐架构，用于在两个 Linux 板之间实现安全、符合 Wi-Fi 联盟标准的接入 如有任何参考、样本流程或最佳实践，将不胜感激。 感谢您的支持。 致以最崇高的敬意， Niranjan Re: Wi-Fi DPP credential sharing between two Linux boards using PN7160 – P2P vs Type-4 Tag mode? 感谢您对我们的产品感兴趣。 建议的解决方案是使用我们的 "连接 "标签之一。在您描述的设置中，我们建议在 M1 (AP) 主板上连接 NTAG 5 Link 板。主机在 Tag 中生成要读取的正确的 NDEF 消息，并为安全访问配置所需的凭据。   如果您想使用 SNEP，则需要在双方都安装 NFC 阅读器。这将增加成本和 P2P 的实施，需要额外的指令交换。这还需要额外的符合规范的软件开发工作。   请记住，在接入点端使用 NTAG 5，您需要根据 NDEF 消息和 Type 5 标签内存配置规范的 NFC 论坛规范构建 NDEF 消息。有必要同时购买两种规格。 在 M2 板上，您将需要像 PN7160 这样的 NFC 读取器，它可以读取 NDEF 并与 AP 建立连接。 希望这些信息对您有所帮助。 Re: Wi-Fi DPP credential sharing between two Linux boards using PN7160 – P2P vs Type-4 Tag mode? 你好@Fabian_R 谢谢你的澄清。 我知道使用SNEP 需要在双方都安装 NFC 读卡器，这会增加 BOM 成本，而且由于P2P 命令交换和根据 NFC 规范进行额外的软件开发，也会增加复杂性。 不过，对于我们的使用案例，我们希望进一步评估这种方法。 能否请您就基于 SNEP 的解决方案澄清以下几点： 建筑指导 两个 Linux 板都应该在启用 P2P 读取器/启动器模式下运行吗？ 一个板应该充当 SNEP 服务器，另一个板充当 SNEP 客户端，还是两者都需要支持这两个角色？ 软件堆栈要求 能否使用linux_libnfc-nci 协议栈和演示应用程序（如 SNEP 或 P2P 示例）来实现？ 基于 SNEP 的凭据交换是否需要对 NFC 栈进行任何特定的配置更改？ 数据交换流程 是否建议通过 SNEP 有效载荷交换Wi-Fi DPP 引导信息（QR URI / 公钥）？ 通过 NFC 接收数据后，应用程序是否应该直接在注册者端触发信号 wpa_supplicant DPP 命令？ 合规方面的考虑 在这种情况下，基于 SNEP 的 P2P 通信是否需要遵守NFC 论坛的强制合规要求？ 有关使用 SNEP 在两个 Linux 主板之间传输 Wi-Fi DPP 凭证的详细分步流程或参考实施指南将对我们评估可行性非常有帮助。 感谢您的支持。 Re: Wi-Fi DPP credential sharing between two Linux boards using PN7160 – P2P vs Type-4 Tag mode? 您好，先生， 我们提供的应用程序接口支持客户端和服务器角色。有关使用和实施的详细信息，请查阅规范（SNEP 和 LLCP）。P2P 的相关函数和实用程序可在 NfcLibrary/NdefLibrary/src/P2P_NDEF.c 中找到。 关于数据交换流问题，可以在Wifi联盟规格文档中找到此信息：连接移交技术规范和Wifi Easy Connect规范（设备配置协议）。 请记住，我们无法提供这些文件的具体内容。请务必购买。

How to download documents on chip-related resources Example: S32K3xx_interrupt_map.xlsx Re: 如何下载芯片的相关资源的文档 Hi@PQF Download the datasheet and instruction manual from the official website. You can find these documents you are looking for in the attachment to the instruction manual. https://www.nxp.com/products/S32K3 Senlent_0-1766974059469.png Senlent_1-1766974085433.png

パスワード保護（AUTH0/アクセス）を有効にした後、NTAG213 の書き込み保護を解除できません NXPチームの皆様、こんにちは。 私は、 PN7160 NFC コントローラとNXP Linux nfcDemoAppを使用してNTAG213タグを操作しています。 私が成功したこと: nfcDemoApp (main.c)を変更し、次のように設定して NTAG213 の書き込み専用パスワード保護を有効にしました。 障害者 パック 認証0 アクセス (PROT = 0) 書き込み保護は正常に機能します: モバイルNFCアプリは書き込みができなくなりました アプリケーションからPWD_AUTHを送信した後にのみ書き込みが可能 AUTH0を0xFFにリセットする アクセスをクリア 設定ページを書き直す また、 NXP NFC TagInfo / NFC Toolsアプリを使用して別の NTAG213 の書き込み保護を有効にしましたが、これも期待どおりに機能しました。 私が直面している問題: 現在、どちらのCASEも書き込み保護を解除できません。 独自のコードを使用する（nfcDemoApp） Using NXP NFCツール/タグライターモバイルアプリの使用 正しいパスワード (PWD_AUTH) で認証した後でも、次の試行は失敗します。 私の理解： NTAG213 のデータシートから、次のことを理解しました。 PWD_AUTHはRFセッション中に保護されたページへの書き込みを許可する必要がある 認証後、AUTH0とアクセスを変更できるようになる。 NTAG213には、パスワード保護のための永続的なロックビットはありません（ロックバイトとは異なります）。 しかし、実際には、タグを保護されていない状態に戻すことはできません。 質問: NTAG213 のパスワードベースの書き込み保護を有効にした後で、それを削除または無効にすることは正式にサポートされていますか? PWD_AUTH が成功した後、AUTH0 ページとアクセス ページは書き込み可能になりますか、それとも一度設定されると永続的に保護されますか? NTAG213 を書き込み可能 (保護されていない) 状態に戻すための推奨シーケンスはありますか? NXP NFC ツール / タグライターは NTAG213 のパスワード保護を削除できるか、またはカスタムの raw コマンド処理が必要ですか? 構成ページを変更するには、認証後に完全なリセット (RF セッションのリセット/電源サイクル) が必要ですか? NXP チームからのガイダンスや説明は非常に役立ちます。 再開まで今しばらくお待ちください。 よろしくお願いします、 ニランジャン Re: Unable to remove write protection on NTAG213 after enabling password protection (AUTH0/ACCESS) 私はRFIDDiscoverを使用します。設定ページで設定を変更して保護を解除することができます。

S32 DS 3.3 许可证过期 你好，我的 S32 Design Studio 3.3 已过期： S32 Design Studio v.3.3 版 订购编号 S32DS-3-3_146477567 订购单编号 许可证总数： 101 激活代码 AF1B-F377-2238-53BB 您能帮我解决这个问题吗？非常感谢！ 亚历山大-穆勒 Re: S32 DS 3.3 License expired 你好、 您的 S32DS 许可证已延期。请使用旧代码重新激活 S32DS。

STM32Cube IDEからMCUXpresso IDEへ STアプリケーションのポーティング このセクションでは、STM32Cube IDEで開発されたアプリケーションを、NXP MCU用の互換SDKを使用してNXP MCUXpresso IDEに移行するプロセスについて概説します。 STM32Cube IDEに慣れているユーザーの場合、同様の開発環境を維持することで移行が容易になり、学習曲線を緩和できます。この例では、STM32デバイス用に元々開発されたI2Cベースのアプリケーションを、NXP MCU用に再作成し、適応させます。 移行は、必要なI2Cドライバを含む最小限のプロジェクトをMCUXpresso IDEで作成することから始まります。元のSTアプリケーションは、同じボード上のコンポーネント間の通信に2つのI2Cインスタンスを利用します。この機能を再現するには、2組のI2Cピンを初期化する必要があります。さらに、アプリケーションはプッシュボタン入力とLED出力を使用して動作の変化を示すため、MCUxpressoピン構成ツールを使用して対応するGPIOを設定する必要があります。 移行を開始するには、元のSTプロジェクトのメイン・ソース・ファイルと、STの標準ドライバ・セットに含まれていないカスタム・ソース・ファイルを、新しいNXPプロジェクトに組み込む必要があります。 以下の手順は、MCUXpresso IDEでの初期プロジェクトセットアップの概要を示すものです。 ［Create a new C/C++ project（新しいC/C++プロジェクトを作成）］を選択します。 ターゲットとなるMCU（例：MCXA156）を選択します。 ［Next（次へ）］をクリックします。 ［Drivers（ドライバ）］セクションを展開します。 I2Cを選択してください。 ［Next（次へ）］をクリックします。 ［Finish（完了）］をクリックします。 プロジェクトを作成すると、基本的な「Hello World」のサンプルが含まれます。このテンプレートを開始点として使用できます。メインソースファイルのすべてのコンテンツ（初期マクロ定義を除く）は、アプリケーションロジックを統合するために段階的に置き換えることができ、モジュール式で制御された移行プロセスを可能にします。 Sabina_Bruce_1-1763569353713.png 次のステップでは、元のSTプロジェクトから新しく作成したMCUXpressoプロジェクトにメインソースファイルを転送します。このプロセス中、標準なSTは含まれ、ドライバ参照は除外されますが、カスタムヘッダーファイルが必要な場合を除きます。この場合、カスタムヘッダは使用されていないため、コアアプリケーションロジックのみが移行されます。 STソース・ファイル内の関数呼び出しの多くは、STM32固有のHAL APIに依存しています。これらの機能は見直され、NXP SDKの同等の機能に体系的に置き換えられます。このアプローチでは、main()ルーチン内の各関数を解析してその目的を理解し、それをNXP環境の対応する実装に置き換えます。   Sabina_Bruce_2-1763569353730.png STプロジェクトの簡単の概要： 割込み優先度の設定 複数の割込みが同時に発生した際に優先度レベルを管理するよう、マイクロコントローラの割込みシステムを設定します。 パワー・ペリフェラル・クロックのイネーブルメント パワーマネージメント設定を構成するための前提条件として、パワー（PWR）ペリフェラル・クロックを有効にします。 パワーマネージメントのセットアップ 内部コンポーネント全体のエネルギー効率とパフォーマンスを最適化するために、STM32U5xxマイクロコントローラのパワーマネージメント機能を初期化します。 System Clock Configuration マイクロコントローラのタイミングシステムを設定し、160 MHzの周波数で動作するように構成します。 ペリフェラルの初期化 ペリフェラルのピン構成や機能設定を確立します。このアプリケーションでは、I2C1がフォロワー、I2C3がリーダーとして構成されています。 LED初期化 LEDを低アクティブ状態で開始し、初期状態または通信フィードバックを示すために点灯するように設定します。 GPIO Polling for Button Press GPIO入力ピンの状態を継続的に監視します。ボタンが押されていないと、LEDは速く点滅します。一度押すと、ループは終了し、LEDは点灯したままです。 I2C通信開始 マスター側からI2C通信プロセスを開始し、2つのI2Cインターフェース間のデータ転送を実行します。 NXP SDKではどのように処理されていますか？ 割込み優先度の設定 この機能はCMSISコアNVIC機能を通じてサポートされており、直接再利用できます。必要なプリエンプション優先度レベルを確立するには、マクロを定義する必要があります。 クロックと電源の設定 これらの機能は、boardフォルダ内のclock_config.cにあるBOARD_InitBootClocks関数に統合されています。この関数は、NXP MCUのシステムクロックと電源設定の両方を初期化します。 ペリフェラルとピンの初期化 ペリフェラルのセットアップは2つの関数に分かれています。 BOARD_InitBootPins（pin_mux.c内）はI2CとGPIOのピン設定を処理します。 BOARD_InitBootPeripherals（peripherals.c内）はI2Cペリフェラルの初期化とGPIO割込み設定を管理します。 LEDの初期化 GPIOピンは、希望する初期状態に応じて出力を「ハイ」または「ロー」に設定できます。LEDはGPIO_PinWriteを使用して切り替えたり設定したりできます。 ボタン押下のGPIOポーリング この動作は、GPIO_PinReadを使用してボタンの状態を監視するカスタムポーリング関数を使用して再現できます。 I2C通信開始 I2Cマスター通信はLPI2C_MasterStartを使用して開始され、指定されたスレーブデバイスとのデータ転送プロセスが始まります。 Clock Config Toolを使用したクロックの初期化 MCUXpresso IDEには、統合構成ツールが含まれており、インターフェースの右上にあるドロップダウンメニューから適切なオプションを選択することで、プロジェクトエクスプローラからアクセスできます。 Sabina_Bruce_3-1763569353733.png システムクロックを設定するには、MCUXpresso IDE内のクロックツールを開きます。 クロック図は選択したMCUでサポートされている構成を示しています。この例では、デバイスの最大コアクロック周波数は96MHzです。これはアプリケーションの要件を満たしているので、デフォルトのクロック設定を変更する必要はありません。 Sabina_Bruce_4-1763569353743.png I2Cインスタンスのペリフェラル・クロックを有効にするには、MCUXpresso Config Tools内のクロック構成図に移動します。図をスクロールして利用可能なペリフェラルを見つけ、適切なクロックソースを選択してI2Cモジュールをアクティブにします。 Sabina_Bruce_5-1763569353757.png I2C0およびI2C3ペリフェラルのクロックソースを設定するには、クロック構成図の各インスタンスに関連付けられているCLKSELフィールドをダブルクリックします。このセットアップでは、I2C0およびI2C3の両方のクロックソースとしてFRO_HF_DIVを選択します。 Sabina_Bruce_6-1763569353761.png 次に、クロック構成図で対応するフィールドを選択してクロック分周器を構成します。詳細はインターフェースの右上パネルに表示されます。I2Cペリフェラルへのクロックパスを有効にするには、「Divider clock is running（クロック分周期が実行中）」オプションが選択されていることを確認してください。 Sabina_Bruce_7-1763569353764.png この段階で、I2Cペリフェラルクロックは正常に有効化されています。 Sabina_Bruce_8-1763569353777.png 構成の変更を適用してプロジェクトに統合するには、「コードの更新」をクリックしてください。このアクションにより、対応するソースファイルが生成され、新しい設定がプロジェクト構造に反映されます。 Pins Config Toolを使用したピンの初期化 MCUXpresso IDEには、統合設定ツールが含まれており、インターフェースの右上にあるドロップダウンメニューから適切なオプションを選択することで、プロジェクトエクスプローラからアクセスできます。 Sabina_Bruce_9-1763569353780.png I2Cピンの構成を開始するには、MCUXpresso IDEの構成ツールメニューから「Open Pins（ピンを開く）」を選択します。 フィルタ機能を使用して、I2Cインスタンス0と互換性のある使用可能なピンを検索します。ボードの回路図を確認した後、ヘッダー経由でアクセスできるピンP0_16とP0_17が選択されました。LPI2C0:SDAとLPI2C0:SCLを構成オプションから選択して、これらのピンに適切なI2C機能を割り当てます。 Sabina_Bruce_10-1763569353815.png I2Cインスタンス3の構成プロセスを繰り返します。ボードの回路図に基づき、P3_27ピンとP3_28ピンがこのインスタンス用に選択されています。ピン構成ツールでLPI2C3:SDAとLPI2C3:SCLを選択し、適切な機能を割り当てます。 Sabina_Bruce_11-1763569353825.png ピンの選択が完了すると、各ピンのルーティングと設定を表示する構成テーブルが生成されます。このテーブル内で、ルーティングの詳細を使用して、必要に応じてピンを設定します。I2Cピンに対して、通信中の適切な信号の整合性を確保するために、内部プルアップ抵抗を有効にしてください。 Sabina_Bruce_12-1763569353838.png I2Cピンの構成に加えて、入力用と出力用の2つのGPIOピンを設定する必要があります。このボードでは、SW2（P1_7）がボタン入力機能、P3_0がLED出力に割り当てられています。 Sabina_Bruce_13-1763569353842.png Sabina_Bruce_14-1763569353845.png ピン構成テーブルのルーティング詳細内で、入力GPIOと出力GPIOの両方の動作を定義します。アプリケーション要件に基づいて、LEDをアクティブにするために、出力ピンをロジック・ロー状態（論理0を選択）に初期化する必要があります。入力ピンに対して、ボタンの押下を正確に登録するために、立ち下がりエッジでの割込み検出を有効にします。 Sabina_Bruce_15-1763569353848.png 構成を確定し、変更をプロジェクトに統合するには、「Update Code（コードを更新）」をクリックします。これにより、必要なソースファイルが生成され、選択した設定がプロジェクト構造に適用されます。 Peripheral Config Toolを使用したペリフェラルの初期化 MCUXpresso IDEには統合構成ツールがあり、プロジェクトエクスプローラからアクセスできます。これらのツールを起動するには、インターフェースの右上にあるドロップダウンメニューを使用します。 Sabina_Bruce_16-1763569353851.png ペリフェラルの構成を開始するには、MCUXpresso IDE内の構成ツールメニューから「Open Peripherals（ペリフェラルを開く）」を選択します。 このビューでは、各インスタンスのGPIOとI2C設定の初期化に集中してください。続行するには、 「Peripheral Drivers（ペリフェラル・ドライバ）」を選択して、対象デバイスで利用可能なサポートされているドライバのリストにアクセスします。 Sabina_Bruce_17-1763569353857.png GPIO1設定 利用可能なペリフェラル・オプションを絞り込むには、ペリフェラル・ドライバ・ビューの検索フィールドに「GPIO」と入力します。関連するオプションが表示されたら、「OK」をクリックしてGPIOの設定を進めます。 Sabina_Bruce_18-1763569353865.png ボタン入力に割り当てられているP1_7の割込み機能を有効にするには、まず新しいペリフェラル・ドライバを選択します。フィルタを使用してGPIOを検索し、適切なドライバを選択して、GPIO1割込みハンドラをアクティブ化します。 Sabina_Bruce_19-1763569353875.png I2C3リーダー/マスター構成 I2Cペリフェラルを構成するには、ペリフェラル・ドライバ・ビュー内の検索フィールドに「I2C」を入力して利用可能なオプションをフィルタリングします。該当するドライバが表示されたら、アプリケーションに適したドライバを選択し、「OK」をクリックして続行します。 Sabina_Bruce_20-1763569353885.png I2C3をマスター（リーダー）デバイスとして設定し、割り込み駆動のデータ転送を有効にします。この設定により、I2C3インスタンスは通信を開始し、割り込みメカニズムを使用してデータ送信を処理できるため、応答性と効率が向上します。 Sabina_Bruce_21-1763569353900.png さらに、I2C3ペリフェラルの割込みハンドラを有効にします。適切な優先度レベルを設定し、送信データ・レディ・フラグを有効にして、割り込みによるデータ転送をサポートします。 Sabina_Bruce_22-1763569353910.png I2C0フォロワー/スレーブの構成 I2C0フォロワー・ペリフェラルを構成するには、ペリフェラル・ドライバ・ビュー内の検索フィールドに「I2C」を入力して、利用可能なドライバをフィルタリングします。該当するドライバが表示されたら、適切なものを選択し、「OK」をクリックして構成を進めます。 Sabina_Bruce_23-1763569353920.png I2C0をスレーブ（フォロワー）デバイスとして構成します。割込み駆動型転送方式を有効にし、通信に使用するスレーブアドレスを指定します。この設定により、I2C0インスタンスはマスタ要求に応答し、割込み経由でデータ受信を処理できるようになります。 Sabina_Bruce_24-1763569353944.png さらに、I2C0ペリフェラルの割込みハンドラを有効にします。適切な優先レベルを設定し、割り当てられたフォロワーアドレスを検証し、受信データ・レディ・フラグをアクティブにして、割り込み駆動型のデータ受信をサポートします。 Sabina_Bruce_25-1763569353954.png 設定を適用してプロジェクトに統合するには、「Update Code（コードを更新）」をクリックします。このアクションにより、必要なソースファイルが生成され、すべてのペリフェラルとピンの構成がプロジェクト構造に反映されることを確認します。 Config Toolsが生成したファイル MCUXpresso構成ツールは、選択した設定に基づいて自動的にソースコードを生成し、メインアプリケーションへの統合を効率化します。この生成されたコードには、前のステップで構成されたクロック、ピン、およびペリフェラルの初期化ルーチンが含まれます。生成されたすべてのファイルは、プロジェクト構造内のboardディレクトリ内に整理されます。 Sabina_Bruce_26-1763569353958.png board.c NXPの開発ボードを使用してプロジェクトを作成する場合、デフォルト構成には、シリアル端末通信用のデバッグUARTピンの初期化が含まれます。この場合、UART機能は不要であり、board.c内の対応する関数は使用されません。 clock_config.c このファイルには、すべてのシステムクロック設定が含まれています。BOARD_InitBootClocks関数を使用して、クロック周波数と電源モードの設定を初期化します。このアプリケーションでは、システムは96 MHzで動作するように構成されています。 peripherals.c このファイルには、Config Toolsで構成されたペリフェラルの初期化コードが含まれています。この例では、I2CインスタンスとGPIO割込みの両方のセットアップルーチンが含まれています。BOARD_InitPeripherals関数を使用することもできますが、生成されたコードをアプリケーション内の特定の場所に選択的に統合し、必要な実行シーケンスに合わせる方が効果的な場合がよくあります。 pin_mux.c このファイルは、I2CとGPIOの割り当てを含む、アプリケーション用に選択されたすべてのピン構成を定義します。UARTピンはデフォルトで含まれていますが、このプロジェクトでは使用しません。BOARD_InitBootPins機能を使ってピン設定を適用してください。 さらに、元のSTアプリケーションにはキャッシュ初期化機能（mx_ICache_init）が含まれています。NXP SDKでは、キャッシュ構成がスタートアップコード内で処理されます。これは、デバイスフォルダの下にあるSystem_MCU.cのSystemInit関数で確認できます。 初期化関数の置き換え Sabina_Bruce_41-1763577157030.png クロックとピンの初期化 NXPベースのプロジェクトの主な機能では、システムクロックとピン構成が、構成ツールによって生成された関数を使用して初期化されます。 BOARD_InitBootClocks BOARD_InitBootPins 周辺機器の初期化 ペリフェラルの初期化コードは、Config Tools によって生成されたperipherals.cから提供されます。コードの最初のブロックは、優先度レベルとNVIC構成を含むGPIO割込みハンドラを設定します。 続いて、I2Cマスタとスレーブのインスタンスが、それぞれの割込みハンドラと優先レベルとともに初期化されます。この段階では、割込みフラグはまだ有効になっていません。割込みフラグは、適切なシーケンスを確保し、早すぎる割込みのトリガを回避するために、データ転送機能において後でアクティブ化されます。 peripherals.cファイルには、スレーブ操作用にLPI2C0ペリフェラルを初期化するためのコードスニペットが含まれています。このコードは、目的の実行フローに合わせて、メイン機能やアプリケーション内の他の適切な場所に選択的に組み込むことができます。 Sabina_Bruce_28-1763569353988.png MCUXpresso IDEの構成ツールは必要な初期化コードを効果的に生成しますが、アプリケーション内でこのコードの最も適切な配置するのは開発者の責任です。この決定は、実装される特定のプロトコルやペリフェラルに必要な操作シーケンスに基づいて行う必要があります。 たとえば、I2C通信では、データ転送は割込みによって管理されます。タイミングを考慮せずにLPI2C0_init機能を使用すると、割込みが早期に発生し、トランザクションが不完全になったり、誤って管理されたりする可能性があります。 適切に実行するために、推奨されるシーケンスは以下のとおりです。 ペリフェラルと関連する割り込みハンドラを初期化します。 I2Cトランザクションを開始します。 マスタ操作とスレーブ操作の両方で割込みを有効にします。 このアプリケーションでは、初期化はmain()関数内で実行され、割込みフラグは、正しいタイミングとコントロールを維持するため、後からHandle_I2C_Master関数内で選択的に有効化されます。 Sabina_Bruce_29-1763569353999.png アクション関数の置き換え Sabina_Bruce_43-1763577293016.png SYSTICKの初期化 SYSTICKタイマは、LED点滅速度の制御など、アプリケーション内での遅延操作をサポートするように構成されています。SYSTICKの初期化に関する詳細な手順は以下のセクションで説明されています。 ボタンポーリングとLED制御 この機能は、ボタン入力を継続的にポーリングするカスタム関数を通じて実装されます。ユーザーの操作を待つ間、LEDが切り替わり、準備完了を示します。ボタンを押すと、LEDが点灯したままになり、I2Cデータ転送フェーズに進んでいることを示します。 I2Cマスタの処理 Handle_I2C_Master関数は、NXP SDKのI2Cペリフェラル用に提供されているドライバAPIを使用して実装されています。この関数はI2Cトランザクションを開始し、通信シーケンスを管理します。 マスターおよびスレーブI2Cインスタンスの割込みハンドラは、ペリフェラルの初期化コードから派生しています。この段階では、アプリケーションが必要とする特定の動作をサポートするために、関連する割込みフラグが選択的にイネーブルされます。 WaitForUserButtonPress 関数 GPIO割り込みハンドラのカスタマイズを開始するには、MCUXpresso IDE内でPeripherals Config Toolを開きます。そこから、自動生成されたGPIO用のIRQハンドラをコピーすることができます。このコードは、アプリケーションの特定の要件に合わせて修正することができます。 Sabina_Bruce_31-1763569354026.png ペリフェラルを構成した後、コードエディタに戻るには、MCUXpresso IDEの右上にある「Develop（開発）」ボタンをクリックします。開発環境に入ったら、コピーしたIRQハンドラコードをメインのソースファイル（できれば上部周辺）に貼り付けて、アクセスと整理を容易にします。 Sabina_Bruce_32-1763569354031.png 修正が加えられ、whileループ内に制御変数が含まれるようになり、アプリケーションはボタンが押されるまで実行を一時停止するようになりました。これにより、プログラムはユーザーの操作後にのみ進行し、アプリケーションの意図したフローに沿うことが保証されます。 Sabina_Bruce_33-1763569354037.png WaitForUserButtonPress機能は、GPIOの切り替え操作と書き込み操作を利用してLEDの状態を制御し、遅延メカニズムを使用してポーリングループ中の点滅間隔を管理します。遅延を実装するには、SYSTICKタイマーを初期化し、それに応じて構成します。 さらに、アプリケーション内の時間ベースの操作をサポートするために、対応するSYSTICK割込みハンドラとともにグローバルカウンター変数が導入されました。 Sabina_Bruce_34-1763569354042.png main()関数内では、ボタンのポーリングロジックの前にSYSTICKタイマーの初期化を追加する必要があります。これにより、ユーザー入力を待機するループに入る前に、遅延メカニズムが完全に動作することが保証されます。 Sabina_Bruce_35-1763569354044.png 最終的なWaitForUserButtonPress関数には以下が含まれます。 GPIO操作でLED状態の切り替えと制御を行います。 ボタンの状態を継続的にチェックし、押下イベントが検出されたときにのみ続行するwhileループ。 Sabina_Bruce_36-1763569354052.png GPIO_* APIは、NXP GPIOドライバライブラリの一部であり、初期化、ピン制御、割込み処理などのさまざまな操作に使用されます。コード内で強調表示されているマクロ（IDEs内では通常ピンクで表示）は、Config Toolsによって生成され、pin_mux.hで定義されます。 アプリケーションで使用される遅延機能は、前述のカスタムSYSTICKベースの関数によって実装されています。 利用可能なGPIO APIの全セットを見るには、fsl_gpio.hヘッダーファイルを参照してください。このファイルは、ポートとピンレベルの制御、構成、割込み管理など、GPIO操作の包括的なサポートを提供します。 I2C割り込みハンドラのカスタマイズ GPIOハンドラと同様の方法でI2C割込みハンドラをカスタマイズするには、まずMCUXpresso IDEでペリフェラル設定ツールを開きます。次に、I2C0用に自動生成されたIRQハンドラを見つけてコピーします。これは、アプリケーションの特定の要件を満たすように変更できる基本テンプレートとして機能します。 Sabina_Bruce_37-1763569354056.png コードエディタに戻るには、MCUXpresso IDEの右上にある「Develop（開発）」ボタンをクリックします。開発環境に入ったら、コピーしたI2C割込みハンドラコードをメインソースファイルに貼り付けます。整理とアクセス性を高めるため、できれば上部に貼り付けてください。 Sabina_Bruce_38-1763569354061.png Peripherals Config Toolから自動生成された割り込みハンドラをコピーして、I2C3に対し、同じプロセスを繰り返します。このハンドラはI2C0で採用されている方法と同様に、カスタマイズのベースとして利用できます。 I2C割り込みハンドラの統合 元のSTベースのプロジェクトでは、各I2Cインスタンスは、標準操作用とエラー処理用の2つの割込みハンドラを使用していました。ただし、今回の移行で使用されるNXP MCUは、I2Cインスタンスごとに1つの割込みベクタを提供し、標準状態とエラー状態の両方を処理します。 その結果、元の4つのハンドラの機能を、各I2Cインスタンスに1つずつ、合計2つに統合する必要があります。これには、元の割込みロジックを慎重に確認して、マージされた実装で関連するすべてのフラグと動作が保持されるようにする必要があります。 たとえば、元のプロジェクトのスレーブハンドラは、アドレス一致フラグをチェックし、検出されると、データを受信する準備ができているかどうかを確認します。NXP環境における同等の動作は、統合された割込みハンドラ内で適切なステータスフラグを監視することで実装され、アドレス認識とデータ受信の両方が正しく処理されることを保証します。 スレーブハンドラ Sabina_Bruce_39-1763569354077.png I2Cスレーブ割込みハンドラは、マスタデバイスが0x7Eでスレーブにアドレスを指定するときにトリガーされます。このアドレスの一致を検出すると、スレーブは要求を確認し、着信データを受信する準備をします。 ハンドラの2番目の部分はデータ受信プロセスを管理します。マスタから送信された各バイトを処理し、送信終了を示すNACK（Not Acknowledge）状態を監視し、受信したデータを指定されたバッファに保存します。これにより、スレーブは通信シーケンスを正しく処理し、すべてのデータが受信された後にスムーズに転送を終了します。 マスタハンドラ Sabina_Bruce_40-1763569354092.png I2Cマスタ割込みハンドラは マスタ転送レディ・フラグを監視し、ペリフェラルが次のバイトのデータを送信する準備ができていることを示します。この状態を検出すると、ハンドラは送信バッファをチェックして、送信すべき追加データが残っているかどうかを判断します。送信の進行状況を追跡するためにカウンタが使用されます。 適切なマスタ送信動作を使用して、ハンドラは次のバイトを送信し、バッファポインタを進めます。最後のバイトが送信されると、ハンドラはSTOP条件を発行して、データ転送シーケンスの完了を通知します。 Handle_I2C_Master関数 Handle_I2C_Master関数は、I2C通信プロセスの開始と管理を担当します。最初に、MasterStartコマンドを発行して、指定されたアドレスのスレーブデバイスとの通信を開始します。スレーブからの確認応答が成功すると、対応する割り込みルーチンを通じてデータ転送が処理されます。 Sabina_Bruce_0-1763577716125.png この関数はまた、マスタおよびスレーブの両方のI2Cインスタンスの割込みハンドラを初期化します。前述のように、トランザクションシーケンスを中断させる可能性のある早すぎる割込みトリガを防ぐために、マスタが通信を開始した後に割り込みを有効にすることが重要です。 データ転送が完了し、スレーブが想定されるすべてのバイトを受信すると、関数はLEDを定常状態に設定して終了し、実行の成功とアプリケーションフローの終了を示します。 まとめ MCUXpresso IDEを使用してアプリケーションをSTM32開発環境からNXP MCXプラットフォームに移行するには、構造化された体系的なアプローチが必要です。統合構成ツールを利用し、STM32とNXP SDKコンポーネント間の機能の同等性を理解することで、開発者はパフォーマンスと機能を維持しながらアプリケーションを効果的に移行できます。 このガイドでは、I2Cベースのアプリケーションを複製する際の主要な手順を概説しています。これには、プロジェクトのセットアップ、ペリフェラルの構成、ピンとクロックの初期化、および割込み処理が含まれます。ツールは自動生成されたコードを通じて強力な基盤を提供しますが、信頼性の高い操作を保証するために、初期化とランタイムロジックのシーケンスと統合を慎重に検討する必要があります。 両方の環境を明確に理解し、アプリケーションロジックを慎重に適応させることで、開発者は移行プロセスを合理化し、NXP MCXプラットフォームが提供する機能を最大限に活用できます。

HSEコンセプト こんにちは、NXPさん M7 と A53 から HSE に並行してアクセスするために、内部で同期が行われますでしょうか?完全に分離されていますか? M7 で SHE 仕様に従って HSE が使用され、A53 で pkcs11 に従って HSE が使用される場合、理論的にはそれらは互いのキーにアクセスできますか (一部の暗号化に同じキーを使用)?SHE でキーをプロビジョニングして、それを他のパーティションで使用することはできますか? s32g274を使用したカスタムボード よろしくお願いいたします。 あんぱ Re: HSE concept こんにちは、 @anpa711 ご投稿ありがとうございます。 1. 通常、M7 部分は 1 つの MU を介して HSE にアクセスしますが、A53 部分は別の MU を介して並行して HSE にアクセスする場合があり、HSE は内部ロジックに基づいてこれらの要件を処理し、ユーザーには透過的です。 2. HSE では、SHE キーは HSE_KEY_TYPE_SHE であり、共通操作は HSE_KEY_TYPE_AES である可能性がありますが、これらは HSE では異なるタイプであり、SHE 操作は SHE サービス経由でのみプロビジョニングできるため、 HSE_KEY_TYPE_SHE タイプのキーをエクスポートすることはできません。 BR チェイン Re: HSE concept こんにちは、 @anpa711 ご返信ありがとうございます。 はい、可能です。 BR チェイン Re: HSE concept こんにちは、 @anpa711 ご返信ありがとうございます。 1. S32G の観点からは、HSE_DEMOAPP に含まれる SHE ベースのセキュア ブート デモのみが提供されています。これは、NXP アカウントの HSE FW ダウンロード ページから入手できます。 2. S32K の部分については、あまり詳しくないので申し訳ありませんが、返信は、この掲示板に返信した同僚によって提供されるはずです: https://community.nxp.com/t5/S32K/bd-p/S32K BR チェイン Re: HSE concept こんにちは、 chenyin_hさん ありがとう、これは良さそうです。 s32K および s32g の MCAL には、SHE 仕様 (EB Autosar スタックと MCAL を使用しています) に従って、または他の形式で、いくつかのキー プロビジョニング デモ/テストが付属していますか? よろしくお願いいたします。 あんぱ Re: HSE concept こんにちは、 chenyin_h さん 回答ありがとうございます。 1. わかりました。同期は必要ないようですね。 2. キーを抽出するつもりはなく、次のUSE CASEを意味しました。SHE 仕様では、AES キーをスロット 8 にプロビジョニングします。このキーが存在する場合、A53 側でこのキーを使用して pkcs11 を使用して復号化/暗号化します。これは可能ですか？ よろしくお願いいたします。 あんぱ

Imx95 verdin EVK、Aquantia10gbpsインターフェースはudpで1.2gbpsに制限されています こんにちは、 私は、Aquantia 10 Gbps インターフェースを介して、2 つの Imx95 verdin EVK A1 シリコン バージョン ボード間の通信を確立しようとしています。両方のボードは、nxp インストーラー (aquantia-firmware-utility/aq_api_2_9_7 at master · nxp-qoriq/aquantia-firmware-utility · GitHub) を使用して適切にインストールされた aquantia10 G ファームウェア (AQR-G4_v5.6.D-AQR_Marvell_NoSwap_XFI_ID44834_VER2068.cld) とともに Debian 12 (Linux カーネル 6.12.3 ) を実行しています。これらは Cat6a イーサネット ケーブルを使用して物理的にコネクテッドされます。 iperf3 を使用してパフォーマンス テストを実行すると、ターゲット帯域幅を 7 Gbps に指定した場合でも、TCP で約 5 Gbps、UDP で約 1.2 Gbps が得られ、損失は 0% になります。 # TCPテスト 最初のボードで iperf3 -s # iperf3 -c -t 30 # 2番目のボード # UDPテスト iperf3 -s iperf3 -c -u -b 7G -t 30 ip link set dev enp1s0 mtu 9000 でジャンボ フレームを有効にしようとすると、制限を超えたというエラーが発生します (10Gbps インターフェースがジャンボ フレームを受け入れないのは奇妙です) また、UDPバッファサイズを増やそうとしましたが、同じビットフレームが発生します 両側でiperf3を実行してもCPU負荷は40%を超えません 最大スループット (10 Gbps 近く) を達成するために、適用する特定の n 構成やインストールする追加ツールはありますか? Aquantia FW バージョンは適切ですか? Linux カーネルのバージョンは適切ですか? FW インストーラーのバージョンは適切ですか? 誰かがすでにこのターゲットで 10Gbps インターフェースを使用しようとしましたか? よろしくお願いいたします。 アブデルモナエム Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 1. 両方のシステムで次の設定を構成してみます。 cpufreq-set -g パフォーマンス sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.wmem_max=26214400 sysctl -w net.core.netdev_max_backlog=250000 sysctl -w net.ipv4.tcp_rmem='409687380 16777216' sysctl -w net.ipv4.tcp_wmem='409665536 16777216' 2. 可能であれば、iperfサーバーとは異なる参照システムを使用します（例：インテル Xeon 3. iperf3 自体はテスト ストリームごとにシングル Thread なので、-P オプションを使用してみてください。 例えばiperf3 -c -u -b 10G -t 30 -P 6 （6つのストリーム） 4. 順方向と逆方向の両方のストリームをチェックする（-R） iperf3 -c 192.168.1.1 -t 10 -b 10G -u -R Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp こんにちは、 ご意見ありがとうございます。 設定を適用します: cpufreq-set -g パフォーマンス sysctl -w net.core.rmem_max=26214400 sysctl -w net.core.wmem_max=26214400 sysctl -w net.core.netdev_max_backlog=250000 sysctl -w net.ipv4.tcp_rmem='409687380 16777216' sysctl -w net.ipv4.tcp_wmem='409665536 16777216' 現在、送信側のみで10Gbps、時には8、8または9、8Gbpsを達成でき、iperfのみでiperf3は使用していません。レシーバ側では、フレーム損失が36%で5.59Gbpsしか達成できません。この問題を解決するのを手伝っていただけますか？ Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 6.12.49へのマイナーバージョンアップグレードとなります ところで、スループットを向上させるために、DPDK または AF_XDP も検討してみてはいかがでしょうか? Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp => TCPとUDPの送信パフォーマンス iperf3 を使用して TCP パケットを送信する場合、各 TCP パケットは 128 KB であり、パケットは ENETC ハードウェアの LSO 機能によって断片化されます。SO、TCP 転送パフォーマンスが向上します。 iperf3 は、UDP ソケットを作成するときに UDP_SEGMENT を有効にしません。したがって： - 各 UDP パケットのサイズは、およそ MTU サイズ (≈1500 バイト) です。 - 同じデータ サイズの場合、UDP は TCP よりも多くのパケットを送信する必要があります。 パケット数の増加 → カーネルプロセッシングの増加 → LSO を使用した TCP と比較してパフォーマンスの低下。 => TCP の場合、受信が送信に比べて大幅に低いのはなぜですか? - Linux カーネルでは TX パスと RX パスが対称ではないため、カーネル内の各 RX パケットと各 TX パケットのプロセッシング時間は異なります。また、TCP は送信時に LSO オフロードを使用しています。 - RSC はカーネル内でデフォルトで有効になっていません。ENETC の RSC が適切に動作するように、TCP タイムスタンプを無効にする必要があります。現在、i.MX95 の RSC はデフォルトで無効になっています。 a) i.MX95（レシーバ）のRSCを有効にする： ethtool -K eth1 大容量受信オフロードオン b) TCPタイムスタンプを無効にする（送信側）: sysctl -w net.ipv4.tcp_timestamps=0 sysctl -p /etc/sysctl.conf RSC を有効にすると、レシーバの TCP パフォーマンスが向上します。 さらに、より高いスループットを得るためにジャンボ フレームを使用することもできます。(最新リリースを実行していることを願います)。 # 両側のMTUを9000に変更します IPリンク設定 dev eth1 mtu 9000 # イーサネット ドライバの RX バッファの長さを変更します。 ethtool -G eth1 受信バッファ長 16384 マルチストリーム モードでは、8 ～ 10 Gbps の UDP RX/TX が確認できます。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp こんにちは、 私は今のところUDPだけに興味があり、TCPには興味がありません。そして、オフロードは メカニズムはUDPには適用されません MTU を 9000 に設定してジャンボ フレームを有効にしようとしましたが、制限の 1500 を超えたというエラーが表示されます (カーネル バージョン 6.12.3 を使用しています) よろしくお願いいたします。 アブデルモナエム Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp RSC 設定により UDP パフォーマンスも向上します。 ENETC のジャンボ フレームの変更/修正は、2 週間以内にリリースされる LF-Q4 で利用可能になる予定です。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp わかりました、これを試してみます、そして結果がどうなったかお伝えします、 LF-Q4 の Linux カーネル バージョンを詳しく教えていただけますか?先ほど言ったように、私は 6.12.3 を使っていますが、シリコン リビジョンが A1 なので上位バージョンに移行できません。B0 リビジョンにアップグレードする必要があるかどうかを知る必要があります。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 問題はありません。iperf で 1 つのフローだけで 5Gbps の並列フローで 9、8Bps で 10Gbps まで行くことができますが、大きな問題は UDP です。モノフローでは 2Gbps でフレーム損失はなく問題ありませんが、並列フローでは 5、5Gbps で 42% の損失があります。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp AF_XDP や DPDK が 46% の損失を 0% に減らすのに役立つとは思えません。また、IRQ の親和性も検証したところ、10G インターフェースには 6 つの IRQ があり、それぞれが CPU に影響を与えていることがわかりました。テスト中に CPU 負荷の問題は発生しませんでした。1 つの CPU の最大 CPU 負荷は 40% です。フレームが失われ続ける理由がまだわかりません。使用しているカーネル バージョンがジャンボ フレームをサポートしていないことが原因かもしれません。 あなたの側（NXP）で10Gインターフェースのパフォーマンステストは実施しましたか？あなたの側でテストして、私と同じ問題があるかどうかを確認する必要があると思います。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp AF_XDP または DPDK はカーネル ネットワーク スタックを使用しません。 DPDK には特別なドライバがあり、ユーザー空間でのみ動作します。ネットワークとパケットプロセッシングに高度に最適化されています。すべての IP パケットに対して非常に高速なパフォーマンスをCANで提供できます。以下のサイトで確認することができます。 第10章: https://www.nxp.com/docs/en/reference-manual/RM00293.pdf Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp このテストは、シリコン リビジョン A1 または B0 で実行されます。 このテストに使用されたカーネル バージョン 6.12.49 が B0 にのみ適用可能か、それとも A1 にも適用可能かを確認しますか? このカーネル バージョンは BSP 配信には表示されません。最新のものは 6.12.34 ですhttps://www.nxp.com/pages/alpha-beta-bsps-for-microprocessors:IMXPRERELEASES Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 新しいカーネル ツリーと変更は次の場所で入手できます。 https://github.com/nxp-imx/linux-imx/commits/lf-6.12.49-2.2.0 新しい LF リリースでは A1 サポートが削除されました。 次のオプションがあります。 1. カーネルを個別にビルドし、ビルド内のカーネルのみを置き換えます。（うまくいくかもしれない） 2. マーケティングお問い合わせにボードを B0 に交換してもらい、LF-Q4'2025 リリースを実行できるように SO CAN します。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp これらの行からは理解できません: 単一 UDP ストリーム送信 (1500 MTU): 2 Gbps (単一ストリームで MTU 1500 の送信では 2 Gbps になるようです) マルチ UDP ストリーム送信 (1500 MTU): 10 Gbps (これは、マルチ ストリームで MTU 1500 の送信では 10 Gbps になるようです) 単一 UDP ストリーム送信 (9000 MTU): 8.2 Gbps (単一ストリームで MTU 900 の送信では 8.2 Gbps になるようです) 単一 UDP ストリーム受信 (9000 MTU): 3.9 Gbps (単一ストリームで MTU 9000 の Rx では 3.9 Gbps になるようです) マルチ UDP ストリーム受信 (9000 MTU): 10Gbps (マルチストリームの MTU 9000 の Rx では 2Gbps になるようです) 私には見えません: 単一UDPストリーム受信（1500 MTU） マルチUDPストリーム受信(1500 MTU) Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp わかりました。念のため、受信側で MTU = 1500 でテストを行ってください。この新しいバージョンで私と同じ結果が得られるか知りたいです。また、テストでは送信を 1500、受信を 9000 に設定していますが、これでは何も変わりません。両側で 1500 になっているようなものです。ジャンボ フレームをテストする必要がある場合は、両側で 9000 にする必要があります。次の構成でテストをやり直してください。 1- モノおよびマルチストリームで両側に MTU = 1500 の RX/TX 2- モノおよびマルチストリームで両側に MTU = 9000 の RX/TX よろしくお願いします Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp はい、このようにして結果がテストされました。 MTU はすべてのCASEで両側で同じでした (両方とも 1500 または両方とも 9000) Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 添付資料参照 また、A1 SOCでも実行していることにも注意してください。 UBOOT ログ: - U-Boot 2025.04-g8c1de2e1deca(2025年5月9日 - 15:29:26 +0000) CPU: i.MX95 rev1.1（1800MHz） CPU: オートモーティブ温度グレード (-40℃～125℃)、30℃ LM ブート理由: sw、オリジン: 2、エラー: 1 LM シャットダウン理由: sw、発生元: 2、エラー: 1 モデル: NXP i.MX95 19X19 ボード DRAM: 15.8ギブ --- SMログ >$ 情報 SM バージョン = ビルド 633、コミット c37b26da SM 構成 = mx95evk、mSel=0 ボード = i.MX95 EVK、属性 = 0x00000000 シリコン = i.MX95 A1 ブートモード = 通常 ブートデバイス = MMC1 ブートステージ = プライマリ ブートセット = 1 ECID = 0x6E5F04BA0000000500041D0899123F81 PMIC 0 (0x08) = 0x20、0x09、0x10、0x00、0x01 PMIC 1 (0x2A) = 0x54, 0x22, 0x00, 0x0B PMIC 2 (0x29) = 0x55, 0x22, 0x00, 0x0A コンパイラ = gcc 14.2.1 20241119

操作指南：在 S32G 电路板支持包中配置静态 IP 1. 简介 当使用由电路板支持包（如 BSP43）生成的 Yocto 根文件系统时，默认的网络配置通常设置为使用 DHCP。因此，S32G-VNP-RDB3 板上连接到每个端口的 DHCP 服务器可能会为不同的以太网端口分配不同的 IP 地址。 这种默认行为对大多数客户来说很方便，因为它不需要额外的网络配置。端口在连接以太网电缆后立即可用，这与已包含DHCP服务器的典型开发环境非常吻合。 然而，有些客户可能没有可用的 DHCP 服务器，或者他们需要特定的网络配置，而不是使用 DHCP 自动分配的设置。例如，客户可能希望将某个以太网端口专门用于某个子网，以便通过 SSH 进行访问。在无法使用 UART 调试控制台的情况下，预先设置好静态 IP，便可在开发板启动后立即进行远程访问。 本文档介绍了一种方法，可为某个特定以太网端口配置静态 IP 地址，同时让其余端口继续使用默认的 DHCP 配置。客户还可以进一步定制配置以满足其具体的网络需求。 S32G

为什么在 S32K3 模块中添加 EMCEM 会导致硬故障处理程序？ 我想在当前代码中添加 EMCEM，但添加后发现它要进入硬故障处理程序。但是，如果我删除 EMCEM，我的代码就会恢复工作状态。 Q23.png Q24.png 我试着关闭故障组和 DCM 故障，看看问题是否是由 EMCEM 的检测引起的，但还是不行。 q26.png 我尝试调整 FREERTOS 的 TOTAL HEAP SIZE = 32768、TIMER TASK STACK DEPTH = 2048 和 QUEUE REGISTRY SIZE = 10，但都不起作用。 q27.png 消息显示 " 总线故障，" 但是在我添加 EMCEM 模块之前，所有功能都运行良好，没有总线故障。我不知道为什么要这么说。 q28.png Re: Why does adding EMCEM to the S32K3 module cause a hard fault handler? 配置 EMCEM 时，我没有配置时钟。我只添加了 EMCEM 模块，并添加了 `eMcem_Init(&eMcem_Config_0)`。不过，我检查了时钟配置，显示 "ERM0_CLK = 40 MHz"。这样做对吗？ 6.png 然后我发现问题出在 `eMcem_Erm_Init` 的 `SAFETYBASE_REG_WRITE32( addr, ERM_SR_CLEAR_VAL_U32 );` 操作中。如果我注释了 `SAFETYBASE_REG_WRITE32( addr, ERM_SR_CLEAR_VAL_U32 );` ，就不会出现 `HARD FAULT HANDLER` 错误。但是，这是 RTD 驱动程序，我认为我不应该修改它。 7.png Re: Why does adding EMCEM to the S32K3 module cause a hard fault handler? 嗨，@Allen_863、 故障似乎发生在 ERM 初始化过程中。能否确认 ERM 时钟是否被禁用？ 如果时钟已启用，请提供有关故障的其他详细信息，以便我们进一步调查。 https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-HARDFAULT-Handling-Interrupt-DS3-5-RTD300/ta-p/1806259   https://community.nxp.com/t5/S32K-Knowledge-Base/How-To-Debug-A-Fault-Exception-On-ARM-Cortex-M-V7M-MCU-S32K3XX/ta-p/1595570   https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447 BR，丹尼尔 Re: Why does adding EMCEM to the S32K3 module cause a hard fault handler? 我检查了 MC_ME PRTN1_COFB0_STAT 的第 23 位，发现它为 0，然后找到了 PRTN1_COFB0_REQ23 的开关。 Q2.png 感谢您的帮助。 Re: Why does adding EMCEM to the S32K3 module cause a hard fault handler? 嗨，@Allen_863、 在 eMCEM 和 ERM 初始化之前，能否在 MC_ME PRTN1_COFB0_STAT 寄存器中检查 ERM 时钟是否运行？ danielmartynek_1-1764321468681.png danielmartynek_0-1764321388232.png 谢谢！ BR，丹尼尔

Problem of the CAN sampling point test value being too small for S32K3 Hi, NXP When developing with S32K311, an external crystal oscillator of 16 MHz is selected. When configuring CANFD, the CAN clock source uses the AIPS_PLAT_CLK at 60 MHz. 80% sampling point is configured for the data field, and TDC is enabled. However, the actual measured sampling point in CANOE can only reach 72%. This issue also occurs in tests on other models such as the S32K312 and S32K342. The following is one of our configurations where we set the sampling points and test data. We configured the sampling point to be 76%, but the actual test result was 67%. wuxianlong_0-1764121103863.png wuxianlong_1-1764121141564.png Best Regards， xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong Could you please share your project, i will take time to test it. Re: Problem of the CAN sampling point test value being too small for S32K3 Hi, @Senlent  We have modified multiple configurations. Under the condition that S32K3 is configured to 80%, the best result tested by CANoe is 72% Best Regards, xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong For CAN FD data phase the latest possible sample point must be set in CANoe. Then the VH6501 sends frames and lengthens the individual bits by one tick after each interval. This seems to be a configuration issue with your VH6501. You can try modifying the parameters here to 70%, 76.667%, and 80% and then testing again. Senlent_0-1764124913617.png Re: Problem of the CAN sampling point test value being too small for S32K3 Hi,@Senlent  We consulted several experienced engineers. They described that there are also problems with the small sampling point test in S32K1 and K3, and this problem may not be strongly related to the MCU.However, the test results vary when different testing instruments are used. When using CANoe for testing, the test results are all on the low side. They suggest that the sampling point configured for S32K3 can be appropriately increased under the actual test requirement of 80%. You can use any NXP demo to conduct a test, and this phenomenon should be reproducible. Best Regards, xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong This should still be a testing issue, not caused by the MCU. However, I will spend some time doing some simple tests. I will probably use an oscilloscope to test directly, which should be the most accurate measurement method. Re: Problem of the CAN sampling point test value being too small for S32K3 Hi,@Senlent  If you have more convincing results, please share them with us as well. We used some other instruments for testing, and the obtained sampling points are relatively close to what we expected in the settings. However, for customers, CANoe has a very high level of industry recognition. Best Regards, xianlong Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong It's possible that the client's tests are flawed; please trust your own testing. I will take some time to conduct a few tests, but this isn't a priority for me and may take a few days to get back to you. Re: Problem of the CAN sampling point test value being too small for S32K3 ok Re: Problem of the CAN sampling point test value being too small for S32K3 Hi@wuxianlong I'm sorry, I cannot perform this test. I do not have suitable interference equipment to conduct it, and the test results in the FLEXCAN report already prove that the test passed. I can send you the relevant proof privately. Re: Problem of the CAN sampling point test value being too small for S32K3 Thank you very much.

FRDM-K64F mcuexpresso 在多个目标之间切换 当您通过拔下旧目标/插入新目标来切换目标后进行调试时，它会要求您通过序列号确认目标。我想保留三个目标并能够在它们之间切换，无需拔掉电源即可进入此确认屏幕，但看不到执行此操作的选项。由于 USB 连接器断断续续，我损坏了一台价值 700 美元的逻辑分析仪，并且不想对我的任何评估套件也发生同样的问题！ 回复：FRDM-K64F mcuexpresso 在多个目标之间切换 埃里希，您是一位学者，也是一位绅士！非常感谢。幸运的是，昨天由于磁盘错误，我刚刚升级到 24.12，并且运行良好！ 干杯 奈杰尔 回复：FRDM-K64F mcuexpresso 在多个目标之间切换 非常感谢您辛勤地帮助我。现在您的评论“进入闪光屏幕”引起了我的兴趣。你的意思是有一个图标可以故意输入吗？如果是的话我还没有找到。重新插入模块后，我唯一可以进入它的时间是当我进入“调试（项目名称）链接服务器调试”时。或者也许存在一个项目设置，当我在重建后尝试调试时，我还没有找到它来输入？我已经浏览了所有设置和图标来寻找这样的快捷方式！ 回复：FRDM-K64F mcuexpresso 在多个目标之间切换 感谢您对我的问题的考虑，但我已经了解该屏幕并使用过它。问题是，如果不拔掉模块，我就无法进入该屏幕。如果它找不到最后编程的模块，它就会出现，否则它将始终重新刷新最后一个模块而不会弹出该对话框！我需要的是一种无需拔掉刚刚闪现的目标即可更改目标的方法。 回复：FRDM-K64F mcuexpresso 在多个目标之间切换 谢谢您的回复，但我想您误解了我的困境。我有三个相同的 MCU，当我打开刚刚收到的三个 MCU 时，总共有六个。我正在构建一个将使用所有这六个的网络项目。它们都是相同的 FRDM-K64F，并且都将运行相同的代码。当我更新代码时，我需要立即将其加载到每个模块中，以便它们保持同步。拥有六个不同的项目并且每次代码更改时都更新所有六个项目将非常耗时。现在我正在拔下每个模块并插入下一个模块来刷新它们。这会导致 USB 插座因磨损而出现一些间歇性故障。我想一直保留它们并选择从 MCUexpresso 中刷新和运行哪一个。 谢谢！ 奈杰尔

KW45B41Z RTC not running during power off (Power backup given by super capacitor) The RTC is retaining its value in the KW45B41Z-EVK during power off when power back up is provided by Coin cell battery, but in i am using KW45B41Z for my project where i am using a super capacitor(25F/3.8V) to power RTC during power off. Here RTC is not retaining its value. So do I need to enable any Low power mode through SPC or is there any special configuration that i should do? I have also verified the voltage across the super capacitor that is enough to power the RTC during power off. Any low power mode configurations are there for RTC? Regards Kaif Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) According to the EVK schematics, the VDD_DCDC pin powers the RTC when JP5 pins 2 and 3 are connected. With this configuration, the RTC functions correctly on the EVK. We observed that the RTC draws approximately 1 mA in this setup. When we replicate this arrangement on our custom board using a supercapacitor, the supercapacitor discharges very quickly. We specifically chose a supercapacitor because we required a rechargeable power source capable of maintaining RTC operation for at least 1–2 months, which is typical for RTC applications. However, a coin cell was not considered suitable since it is not rechargeable. Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) Hello What values are you getting from voltage across the capacitor? As if goes to a very low voltage (from the capacitor discharging) or approximates to minimal values according to Datasheet, it may cause abnormal functionality such as loss of RTC Functionality: The most immediate consequence is that the RTC will likely stop operating reliably. The timekeeping accuracy will be compromised, and any data stored in the RTC's backup registers may be lost. A coin cell offers a stable and nearly constant voltage over most of its lifespan, which ensures that the RTC always receives a voltage above its minimum operating threshold. Best Regards Luis Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) I am using kw45b41zevk_rtc demo (not rtc_func or power mode switch as in AN14122). Instead of Coin Cell (as in KW45B41Z EVK) I am using a super capacitor for RTC Power Backup. During power on RTC will be powered by VDD_SWITCH but during power off, super capacitor will supply power to RTC.  During power off Super capacitor is discharging (tested) but RTC is not retaining its register value. I have attached the schematics of RTC supply configuration i am using.  Why in the KW45B41Z EVK coin cell backup is given for RTC why there is no rechargeable source like super capacitor or battery? Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) Hello Kaif, As shown in the KW45B41Z-EVK, the coin cell or lithium battery will be the preferred methods, this to achieve long battery life and voltage stability. Regarding the RTC not retaining values, Could you please kindly describe what is the procedure you are using for the configuration and test? By any chance, are you using the demo called "rtc_func" or power_mode_switch as in AN14122? Also please consider the recommendations mentioned in the AN14122 to start the RTC from a low-power mode. Best Regards Luis Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) I am using KW45B41Z in custom board with back up power using super capacitor. Can we use super capacitor to power RTC during power off? or Lithium battery is the only way? I would really appreciate your support on this. Regards  Kaif Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) Hello, Could you help us confirm if you are using a custom board with the KW45B41Z or the KW45-EVK? The Application note 14122 describes how to integrate the RTC feature to a low-power application with the KW45 and explains the file modifications needed to implement it. AN14122: How to use RTC on KW45-EVK | NXP Semiconductors Best Regards Luis Re: KW45B41Z RTC not running during power off (Power backup given by super capacitor) We have attached schematics of super capacitor going to VDD_SWITCH line, do we need to enable any specific bits through software in rtc or power section? Best Regards Kaif

在 MPC5748G MCU 的扩展 SPI 模式下，EOQF 标志未被设置 你好，团队、 我在 MPC5748G MCU 中使用扩展 SPI 模式进行 32 位帧传输，发现传输结束时 EOQF 标志没有被设置。我在 MPC5777C MCU 上使用了相同的代码，一切正常。 你知道为什么会出现这个问题吗？任何建议或想法都会被极大地采纳。 期待您的真知灼见。 谢谢！ 此致， 克里希纳 用于 i.MX RT 的 eIQ 机器学习软件 Re: EOQF flag is not getting set in EXTENDED SPI mode in MPC5748G MCU 你好，伊谢、 谢谢您的答复。我已正确配置 SPI 模块以传输 32 位帧，如果不查看 EOQ 标志，读取和写入均可在 MPC5748 中正常工作。我还设置了 EOQ 标志，以便传输最后一个字，但模块不承认这一点。 仅供参考，我不在 EOQ 中使用中断我正在轮询寻找那个标志。 您提到"虚假队列结束语" ，能否请您解释一下这是什么意思？ 谢谢！ 此致， 克里希纳

GD3162 新しい回路図デザインで GD3162 ゲート ドライバを使用する予定です。NXP のサイトで短いデータシートを見つけました。完全なデータシートはありますか? Re: GD3162 この製品に関して要求されたドキュメントは管理リリース下にあり、NDA (秘密保持契約) に基づいてセキュア ファイル経由でアクセスできます。 アクセスをリクエストするには、こちらをクリックしてください: https://www.nxp.com/webapp-signup/docstoreReg  フォームの送信時に、有効な NDA のコピーをアップロードするよう求められることにご注意ください。NXPについてにまだNDAがない場合は、まずNDAのフォームにご記入ください。 https://www.nxp.com/webapp-signup/ndaReqForm NDA の準備ができたら、安全なファイルへのアクセスをリクエストできます。 プロセスを理解するには、以下のリンク/FAQを確認してください。 https://www.nxp.com/support/support/secure-access-rights:SEC-ACCESS https://www.nxp.com/support/support/secure-access-rights/secure-access-rights-faqs:SEC-ACCESS-FAQS