PN7161 同时移除标签时的 NFC 发现阻塞问题 我正在使用 PN7161 芯片识别 NFC 卡。 当我同时标记 MIFARE Classic 卡和智能手机的 NFC 时，然后同时移除它们，函数NxpNci_WaitForDiscoveryNotification 就会被阻止。 打印 " WAITING FOR 设备 DISCOVERY " 后，程序无法继续打印 " test_1 "。 我使用的是 SW6705。 /////////////////////////////////////////////////////////////// /* 开始探索 */ 如果(::NxpNci_StartDiscovery(RW_DiscoveryTechnologies, sizeof(RW_DiscoveryTechnologies)) != NFC_SUCCESS) { LOG_ERR("无法开始发现"); 返回; } 虽然(_nfcRfMode == NFC_RF_MODE_RW) { LOG_INF( " 等待设备发现 "); /* 等待，直到发现对等设备 */ 而(::NxpNci_WaitForDiscoveryNotification(&RfInterface) != NFC_SUCCESS) { 日志文件("test_1"); 如果(_nfcRfMode != NFC_RF_MODE_RW) { ::NxpNci_StopDiscovery(); 日志文件("模式已更改，退出 RW 模式"); 返回; } } 如果((RfInterface.ModeTech & MODE_MASK) == MODE_POLL) { ////////////////////////////////////////////////////////////////////////////// 以下是出现问题时显示的 NCI 信息。之后，即使将卡靠近，也无法识别。只有在关闭电源并重新打开后，才能再次识别该卡。 [00:03:24.623,321] Iso14443_4Handler: === ISO14443-4 Scenario Complete === NCI>> 2f 11 00 NCI<< 4f 11 01 00 [00:03:25.265,533] NfcManager：CARD REMOVED NCI>> 21 06 01 00 NCI<< 6f 11 01 00 NCI<< 41 06 01 00 NCI>> 21 03 07 03 00 01 01 06 01 NCI<< 61 06 02 00 00 NCI>> 21 03 07 03 00 01 01 06 01 NCI<< 41 03 01 00 [00:03:25.288,543] nfcManager：等待设备发现 NCI < < 41 03 01 a0 NCI < < 60 07 01 a1 a1 NCI < > 21 06 01 03 NCI < < 41 06 01 00 NCI < < 61 06 02 03 00 NC I < < 61 03 0f 01 80 00 0a 04 00 04 aa 4e 46 0e 0e 01 08 00 02 NC I < < 61 03 0f 02 00 04 00 04 08 c0 b9 fa 01 20 00 02 02 02 02 04 00 04 04 08 c0 fa 01 20 00 01 //////////////////////////////////////////////////////////////////////////// 是否有人遇到过这个问题，或者是否有建议的方法来处理同时删除标签的问题，以避免在发现通知功能中阻塞？ Re: PN7161 NFC Discovery Blocking Issue with Simultaneous Tag Removal 你好@Jaden_jung 希望你一切顺利。 能否请您提供有关设置的更多详细信息？您使用的主机平台是什么？你使用的智能手机是iOS设备，还是安卓设备？ 我使用 SW6705 Rev 1.2（使用未修改的 LPC55S6x RW 演示）、OM27160、LPCXpresso55S69 并同时移除 Pixel 3 和 MIFARE Classic，都无法重现这种行为。您能否使用 PN7160 开发套件 (OM27160) 重现这种行为？ Eduardo。 Re: PN7161 NFC Discovery Blocking Issue with Simultaneous Tag Removal 照片显示了症状再现时的电流值。据怀疑，即使在取出卡之后，系统仍无法恢复到轮询状态。 Re: PN7161 NFC Discovery Blocking Issue with Simultaneous Tag Removal 主机是 nrf52840，手机是安卓手机。(Samsung Galaxy s25 和 flip) 同时访问两张 MIFARE 经典卡时没有问题。 将 OM27160 板与树莓派搭配使用（使用 linux_libnfc-nci）时没有问题。 定义 REMOVE_P2P_SUPPORT 可以解决问题。 出现问题时，它是否按照下面的流程工作？ 0. at 946line if (Answer[1] == 0x05) // true { pRfIntf->Interface = Answer[4]; // = 0x02 = INTF_ISODEP pRfIntf->Protocol = Answer[5]; // = 0x04 = PROT_ISODEP ...... NCI<< 61 05 19 01 02 04 01 ff 01 0c 0b 64 c6 b2 a3 00 00 00 80 81 71 01 00 00 02 01 00 1.在 WaitForDiscoveryNotification 处分支（第 962-963 行）： 在未定义 REMOVE_P2P_SUPPORT 时执行分支。 NCI>> 21 06 01 03 (NxpNci_HostTransceive) NCI<< 41 06 01 00 (NxpNci_WaitForReception) 2.从 do-while 循环退出： 收到以下通知后，循环终止（第 966 行）： NCI<< 61 06 02 03 00（成功退出循环） 3.多张卡片检测（找到 2 张卡片）： 该设备可识别野外两个目标： 目标 1：61 03 0f 01 80 00 0a 04 00 04 aa 4e 46 0e 0e 01 08 00 02 目标 2：61 03 0f 02 04 00 0a 04 00 04 04 08 c0 b9 fa 01 20 00 02 02 02 04 04 08 c0 b9 fa 01 20 00 01 4.处理条件分支：（第 986 行） 由于接收到的响应与条件不符（Answer[0] == 0x61&& Answer[1] == 0x05），逻辑会跳转到 if (AnswerSize != 0) 块。 5.第 989 行的潜在阻塞： 在第 989 行，条件 while(Answer != 0) 似乎总是为真，导致潜在的无限循环或阻塞状态。这似乎是启用 P2P 支持时系统挂起的根本原因。

RT685: SDK 25.12 に HASHCRYPT アクセラレーションがない こんにちは、 最近、SDK 25.12 にアップデートしたところ、TLS 復号化率が半分に低下していることに気付きました。 mbedTLS v3.x は、 fsl_hashcryptハードウェア機能を使用して高速化されなくなりました。 以下は、以前の SDK 25.09 を使用してmbedtls_ssl_readを呼び出すコールスタックです。ご覧のとおり、最終的にはHASHCRYPT_AES_EncryptEcbが使用されます。 hashcrypt_aes_one_block_aligned() at fsl_hashcrypt.c:437 hashcrypt_aes_one_block() at fsl_hashcrypt.c:581 HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,284 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_update() at gcm.c:358 mbedtls_gcm_crypt_and_tag() at gcm.c:456 mbedtls_gcm_auth_decrypt() at gcm.c:491 mbedtls_cipher_aead_decrypt() at cipher.c:1,407 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,613 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,242 ssl_prepare_record_content() at ssl_msg.c:3,667 ssl_get_next_record() at ssl_msg.c:4,551 mbedtls_ssl_read_record() at ssl_msg.c:3,817 mbedtls_ssl_read() at ssl_msg.c:5,237 <...more frames...> MBEDTLS_USE_PSA_CRYPTOが定義された SDK 25.12 のコールスタックを以下に示します。このバージョンでは、 mbedtls_internal_aes_encryptはすべて C コードで、ハードウェアアクセラレーションは使用されていません。 mbedtls_internal_aes_encrypt() at aes.c:894 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:641 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> 以下は、 MBEDTLS_USE_PSA_CRYPTOが定義されていない SDK 25.12 のコールスタックです。このバージョンでは、 mbedtls_internal_aes_encryptはすべて C コードであり、HW アクセラレーションはなく、PSA は使用されません。 mbedtls_internal_aes_encrypt() at aes.c:899 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 gcm_mask() at gcm.c:546 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_cipher_aead_decrypt() at cipher.c:1,528 mbedtls_cipher_auth_decrypt_ext() at cipher.c:1,674 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,639 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> RT685 HASHCRYPT ハードウェア アクセラレーションを mbedTLS に復元する予定はありますか?特定の PSA Crypto ドライバーが実装されていないようです。 よろしくお願いします。 Re: RT685: SDK 25.12 no HASHCRYPT acceleration こんにちは、エドウィン。 移行ガイドを確認しました。ただし、このバージョンの SDK では、PSA なしの mbedTLS 2.x または mbedTLS 3.x がどのようにハードウェア アクセラレーションされるかはわかりません。aes_alt.c が削除され、HASHCRYPT 機能は PSA ドライバでのみサポートされるようになりました。 SDK 25.12 ではアプリですべてが動作し、接続には間違いなく TLS 1.3 を使用したいと考えていますが、現状ではパフォーマンスが大幅に低下します。 これについては引き続き調査していきます。例の 1 つを変更して、パフォーマンスの低下を再現できるかどうかを確認します。 よろしくお願いいたします。 アミルカル Re: RT685: SDK 25.12 no HASHCRYPT acceleration こんにちは、エドウィン。 EVKで問題を再現しました。2つのサンプルに、200回の反復処理のループを追加して修正しました。 mbedtls_gcm_self_test RTC クロックを使用して全体の実行時間を計測しました。 evkmimxrt685_mbedtls_selftest_cm33 SDK 25.09からテストを実行しました 1087ミリ秒 このコールスタックでは: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,260 mbedtls_internal_aes_encrypt() at aes_alt.c:1,959 mbedtls_aes_crypt_ecb() at aes_alt.c:1,323 aes_crypt_ecb_wrap() at cipher_wrap.c:114 mbedtls_cipher_update() at cipher.c:521 mbedtls_gcm_starts() at gcm.c:294 mbedtls_gcm_crypt_and_tag() at gcm.c:452 mbedtls_gcm_self_test() at gcm.c:826 evkmimxrt685_mbedtls3x_psatest_cm33 SDK 25.12からテストを実行しました 8990ミリ秒 このコールスタックでは: mbedtls_internal_aes_encrypt() at aes.c:896 mbedtls_aes_crypt_ecb() at aes.c:1,062 aes_crypt_ecb_wrap() at cipher_wrap.c:166 mbedtls_cipher_update() at cipher.c:611 mbedtls_gcm_starts() at gcm.c:441 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075   evkmimxrt685_mbedtls3x_psatest_cm33 SDK 25.12以降 MBEDTLS_PSA_ACCEL_KEY_TYPE_AES 定義されたテストを実行した 8744ミリ秒 このコールスタックでは: HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:187 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 mbedtls_gcm_starts() at gcm.c:439 mbedtls_gcm_crypt_and_tag() at gcm.c:718 mbedtls_gcm_self_test() at gcm.c:1,075 例の変更点の要点は次のとおりです。 BOARD_InitHardware(); test_rtc_init(); psa_crypto_init(); uint64_t ms_start = test_rtc_get_msecs(); for (int i = 0; i < 200; ++i) { PRINTF("test iteration %d\r\n", i+1); mbedtls_gcm_self_test(0); } uint64_t ms_end = test_rtc_get_msecs(); PRINTF("test time = %ums\r\n", (unsigned)(ms_end - ms_start)); ...ここで、 test_rtc_get_msecs は、1 秒未満の精度を使用して現在の RTC 時刻を返します。 ご覧のとおり、新しい SDK で GCM/AES を暗号化すると、速度が約 8 倍低下します。 ご希望であれば、修正したサンプルを添付することもできます。 よろしくお願いいたします。 アミルカル Re: RT685: SDK 25.12 no HASHCRYPT acceleration こんにちは@hrc-amilcar 、 この質問にご辛抱いただきありがとうございます。社内チームからの返答を受け取りましたので、以下をご覧ください。 コールスタックから、従来の mbedtls_xxx 暗号 API を使用していることがわかります。実際、HW アクセラレーションではありません。mbedTLS3.xCrypto 用の新しい API が導入されました。これは PSA です。mbedtls/docs/psa-transition.md は v3.6.5 · Mbed-TLS/mbedtls · GitHub で高速化されています。レガシー暗号 API は MbedTLS4.x でさらに削除されます。 RT600 用の SDK で psa_crypto_examples を確認したところ、 PSA_CRYPTO_DRIVER_HASHCRYPT が定義されているため、暗号ドライバー ラッパーが暗号計算を HW にオフロードできるようになり、HASHCRYPT HW アクセラレーションがデフォルトで有効になっています。一方、MbedTLS3.x+ はより複雑で、PSA API 仕様に準拠しているため、一部のユースケースでは実際にパフォーマンスが低下する可能性があります。TLS の場合、この IP は bignum アクセラレーションのみをサポートし、HW IP がアルゴリズム全体を実装することを期待する PSA API との互換性があまりないため、むしろ非対称暗号化 (CASPER HW IP) がパフォーマンスのボトルネックになると予想されます。少なくとも一部の ECC 操作 (署名、検証) を高速化するために最善を尽くしましたが、ECDHE キー交換中の keygen などの他の操作では速度が低下する可能性があります。 ここで、パフォーマンス測定に PSA API を使用して、PSA_CRYPTO_DRIVER_HASHCRYPT が定義され、コール スタックがそれを使用していることを確認できるとよいでしょう。参考までに: Hashcrypt は AES-GCM アクセラレーションをネイティブに提供していないため、HW IP の実際のメリットを確認するには、AES-CBC または AES-CTR をベンチマークすることをお勧めします。 BR、 エドウィン。 Re: RT685: SDK 25.12 no HASHCRYPT acceleration こんにちは@hrc-amilcar 、 mbedTLS 2.x (PSA なし) から mbedTLS 3.x (PSA あり) に移行すると、次の理由によりパフォーマンスが低下する可能性があります。 PSAドライバインターフェースはまだ部分的にしか実装されていません。そのため、ドライバ作成に必要な成果物や、ドライバをMbed TLSに統合する方法は、高速化対象となる操作によって異なります。( https://mcuxpresso.nxp.com/mcuxsdk/latest/html/middleware/mbedtls3x/docs/psa-driver-example-and-guide.html) 現時点では、2.xから3.xへの適切な移行方法に関するガイドラインに従うことをお勧めしています: Mbed TLS 2.xからMbed TLS 3.0への移行 — MCUXpresso SDKドキュメント PSA APIへの適切な移行ガイド： PSA APIへの移行 - MCUXpresso SDKドキュメント ご不便をおかけして申し訳ございません。 BR、 エドウィン。 Re: RT685: SDK 25.12 no HASHCRYPT acceleration こんにちは@hrc-amilcar 、 SDK をアップデートした後に何か変更を加えましたか？SDK のサンプルコードでも同様の現象が見られますか？スタンドアロン IDE を使用していますか、それとも VS Code 拡張機能を使用していますか? BR、 エドウィン。 Re: RT685: SDK 25.12 no HASHCRYPT acceleration mbedTLS設定ファイルに MBEDTLS_PSA_ACCEL_KEY_TYPE_AES を 定義したのです が、HASHCRYPTまで呼び出されるようになりました。しかし、mbedtls_ssl_readの読み取り速度がさらに遅くなっています。他に定義が不足しているのか、PSAレイヤーが余分なオーバーヘッドを加えているのか、疑問に思っています。   TLS ソケット経由で WiFi から 4KB パケットをダウンロードする速度: SDK 25.09: 205KB/秒 (PSAなし、ksdkポートファイルありのmbedTLS 2.x) SDK 25.12: 138KB/秒 (MBEDTLS_PSA_ACCEL_KEY_TYPE_AES なし) SDK 25.12: 125KB/秒 (MBEDTLS_PSA_ACCEL_KEY_TYPE_AES 使用時) MBEDTLS_PSA_ACCEL_KEY_TYPE_AES を使用した新しいコールスタックは次のとおりです。 HASHCRYPT_AES_EncryptEcb() at fsl_hashcrypt.c:1,255 hashcrypt_cipher_encrypt() at mcux_psa_hashcrypt_common_cipher.c:203 psa_driver_wrapper_cipher_encrypt() at psa_crypto_driver_wrappers.h:2,353 psa_cipher_encrypt() at psa_crypto.c:4,766 mbedtls_block_cipher_encrypt() at block_cipher.c:177 gcm_mask() at gcm.c:543 mbedtls_gcm_update() at gcm.c:628 mbedtls_gcm_crypt_and_tag() at gcm.c:726 mbedtls_gcm_auth_decrypt() at gcm.c:753 mbedtls_psa_aead_decrypt() at psa_crypto_aead.c:270 psa_driver_wrapper_aead_decrypt() at psa_crypto_driver_wrappers.h:4,114 psa_aead_decrypt() at psa_crypto.c:5,023 mbedtls_ssl_decrypt_buf() at ssl_msg.c:1,625 ssl_prepare_record_content() at ssl_msg.c:4,093 ssl_get_next_record() at ssl_msg.c:5,068 mbedtls_ssl_read_record() at ssl_msg.c:4,323 mbedtls_ssl_read() at ssl_msg.c:5,983 <...more frames...> Re: RT685: SDK 25.12 no HASHCRYPT acceleration こんにちは@EdwinHz 、 MCUXpresso IDEを使用しています。 SDK を更新した後、追加の変更はありません。 SDK を更新するときは、「SDK マネジメント」→「SDK コンポーネントの更新」を再実行して、新しい更新されたファイルを取得します。 次に.cprojectを比較します同様の機能が有効になっているサンプルの1つに構成を変更します（例：evkmimxrt685_wifi_wpa_supplicant_cm33) PSA_CRYPTO_DRIVER_CASPER=1 PSA_CRYPTO_DRIVER_HASHCRYPT=1 CONFIG_WPA_SUPP_CRYPTO_MBEDTLS_PSA=1 等... メインの mbedTLS 構成ヘッダーとしてデフォルトのmcux_mbedtls_config.h を使用し、 evkmimxrt685_wifi_wpa_supplicant_cm33の例のwpa_supp_mbedtls_config.hとほぼ同じ独自のユーザー構成ファイルを使用しています。 mbedtls3x_examples を試して、どのように動作するか確認します。おそらく、いくつかの定義が欠落しているのでしょう。 コードをステップ実行しているときに、 gcm 操作を高速化するために、おそらくMBEDTLS_BLOCK_CIPHER_C を定義する必要があることに気付きました。 ヘッダーmbedtls3x/include/mbedtls/config_adjust_legacy_crypto.hがこれに関係しているようですが、何らかの理由でそのマクロが定義されません。 Re: RT685: SDK 25.12 no HASHCRYPT acceleration 他人の利益のために... mbedTLS 3.xのmbedtls_xorは、一度に4バイトのデータをループして呼び出しているようです。 mbedtls_get_unaligned_uint32 そして mbedtls_put_unaligned_uint32 どちらも単一の uint32 に対して memcpy を使用します。 mbedTLS の作者たちは、一度に 4 バイトの XOR ブロックを計算する (剰余ループを使用) ことでパフォーマンスの向上を試みていることは承知していますが、memcpy の完全な呼び出しによって、実際にはコードの速度が低下しています。 逆アセンブリを調査した結果、プロジェクトが -fno-builtin でコンパイルされており、小さな memcpy がコンパイラによってインライン化されないことが判明しました。 このオプションを削除すると、AES-GCM 操作に使用されていない HASHCRYPT ハードウェアのパフォーマンス損失の多くが回復しました。SO、私が投稿した例では、実行時間が 8600 ミリ秒から 2100 ミリ秒に短縮されました。mbedTLS 2.x + ksdk alt (1087 ミリ秒) のレベルには達していません。しかし、復元されたパフォーマンスは十分良好です。 -アミルカル

RTD- Need support for using Wdg(watchdog )driver for saf9000 RTD driver version (R23-11 v1.0.0) We are from the Quantum rfp team, working for the SAF9000 chip. We are trying to use RTD's-Wdg (watchdog) driver and see some issues like wdg calls trying to suspend all interrupts and then resuming interrupts.This is affecting some of the features. So wanted some support to help identify root cause/proper usage of wdg and fix the issues we are facing. Could you please support. Current RTD Configuration we are trying to use are attached (wdg and platform xdm files): wdg- in enable direct service mode. using below calls:  For initialization:  Wdg_43_Instance0_Init((Wdg_ConfigType*)NULL_PTR); //since using post build variant   For toggle/feeding watchdog regularly we are using: Wdg_43_Instance0_SetMode(WDGIF_FAST_MODE); Let me know in direct service mode the calls to be used to initialize and feed watch dog are correct or not? Will any of these calls disturb any other interrupt, causing us other functionality issues? RTD Re: RTD- Need support for using Wdg(watchdog )driver for saf9000 Thanks Cuong. To start with we started using indirect servicing, but since we were using GptChannelConfiguration_0 for some other timer purpose already, we could not use the same in wdg configuration for "Wdg External Trigger Counter  " . We tried defining  GptChannelConfiguration_1 in addition and tried to use it for "Wdg External Trigger Counter  " in wdg tresos configuration, but it was not allowing it for some reasons(was getting red cross mark). That is when we switched to direct mode. As per your suggestion i will try using   function Wdg_43_Instance0_Service function. If problem persists then i will again try to use indirect servicing, and for configuration problem, i will approach you. Re: RTD- Need support for using Wdg(watchdog )driver for saf9000 Hi @renukasc  I see that you used SetMode to feeding watchdog is wrong. With direct service: use Wdg_43_Instance0_Service function With indirect service: use Wdg_43_Instance0_SetTriggerCondition function. Please check our example in Wdg module to refer how we use Wdg_43_Instance0_SetTriggerCondition  Path: \plugins\Wdg_TS_T40D34M50I0R0\examples Furthermore: Wdg_43_Instance0_Init((Wdg_ConfigType*)NULL_PTR) -> Using with Precompile, not Post-built Re: RTD- Need support for using Wdg(watchdog )driver for saf9000 i could try using Wdg_43_Instance0_Service. Watchdog functionality fine as said before.If not fed , watchdog isr is triggering as expected.But problem is when watchdog apis are used,i could see it affecting all our other functinalities.Looks like it is affecting interrupts. Could you please provide one WDT example application, that has timer and other ISR like UART in which WDT is not affecting these ISRs using direct service mode .   Re: RTD- Need support for using Wdg(watchdog )driver for saf9000 One more update, as indicated earlier when wachdog calls are used in our app, looks like other interrupts like timer(gpt) are not getting served, we dont get isrs triggering for this any more. Tried changing priority of the interrupts,not helping. Also tried commenting OsIf_SuspendAllInterrupts(), OsIf_ResumeAllInterrupts()  in /RTD/eclipse/plugins/Rte_TS_T40D94M10I0R0/src/SchM_Wdg.c . This is also not helping. Could you please provide one WDT example application, that has timer and other ISR like UART in which WDT is not affecting these ISRs using direct service mode.   Re: RTD- Need support for using Wdg(watchdog )driver for saf9000 Below is the flow when WDG service is called:  Wdg_43_Instance0_Service()   → Wdg_ChannelService(WDG_IPW_INSTANCE0)       → Wdg_Ipw_Service(Instance)           → Swt_Ip_Service(Instance)               → SchM_Enter_Wdg_WDG_EXCLUSIVE_AREA_09();   // This can call OsIf_SuspendAllInterrupts()               → ...               → SchM_Exit_Wdg_WDG_EXCLUSIVE_AREA_09();    // This can call OsIf_ResumeAllInterrupts() So, If you call Wdg_43_Instance0_Service and in your RTE, the definition of SchM_Enter_Wdg_WDG_EXCLUSIVE_AREA_09 and SchM_Exit_Wdg_WDG_EXCLUSIVE_AREA_09 are call OsIf_SuspendAllInterrupts/OsIf_ResumeAllInterrupts then yes it could affect to interrupt. However, after call this function, the interrupt should be back to normal.  Do you mean that even exit this function Wdg_43_Instance0_Service, interrupts still cannot be triggered? Can you share me how do you implemented OsIf_SuspendAllInterrupts(), OsIf_ResumeAllInterrupts()  in your project?   Re: RTD- Need support for using Wdg(watchdog )driver for saf9000 @renukasc  When "Development Error Detection" is enabled, Wdg APIs use Wdg_ChannelValidateGlobalCall and Wdg_ChannelEndValidateGlobalCall. These functions use SchM_Enter/Exit_Wdg_WDG_EXCLUSIVE_AREA_06 and SchM_Enter/Exit_Wdg_WDG_EXCLUSIVE_AREA_07. Please verify in your SchM implementation how SuspendAllInterrupts and ResumeAllInterrupts behave. In particular: after ResumeAllInterrupts is called, do all interrupts return to their normal state? Re: RTD- Need support for using Wdg(watchdog )driver for saf9000 what we finally observed when debugged is the normal timer interrupt will stop and will not resume if Wdg_43_Instance0_Init and Wdg_43_Instance0_Service calls are made with tresos configuration "Development Error Detection " is set. When we disabled 'Development Error Detection ' in tresos, we observe that other interrupts are fine when enabled with wdg calls.  

i.MX RT1064：在 GPIO_AD_B1_09 上启用 FlexPWM 的问题 我正在使用 i.MX RT1064，并尝试在以下引脚上生成 PWM 信号。尽管通过 MCUXpresso SDK 配置了 IOMUX 并初始化了 FlexPWM 模块，但我在引脚上看不到任何输出。 GPIO_AD_B1_09：配置为 ALT1 (FLEXPWM4_PWM1_A) 当前设置： 我正在按照 SDK 中的示例——exkmimxrt1064_pwm 作为设置 PWM 的参考。 我使用标准的 50% 占空比进行测试。 问题 RT1064 上的这些特定引脚是否存在已知的内部冲突？ 对于GPIO_AD_B1_09，是否需要特定的焊盘属性（DSE、速度）来覆盖默认的 USDHC 功能？ 另外，我想在 GPIO_SD_B1_04 和 GPIO_AD_B1_05 上启用 PWM，但在 FlexPWM 下看不到这些引脚，有没有办法在这些引脚上也启用 PWM？ 感谢您的帮助。 i.MX RT106x Re: i.MX RT1064: Issues enabling FlexPWM on GPIO_AD_B1_09 您好 ，对于 GPIO_AD_B1_09，请确保 IOMUXC_FLEXPWM4_PWMA1_SELECT_INPUT = IOMUXC_FLEXPWM4_PWMA1_SELECT_INPUT_GPIO_AD_B1_09_ALT1; 已被设置（值为 0x00000001），否则输出将被 GPIO_EMC_02（默认值）取代。 确保驱动设置 IOMUXC_SW_PAD_CTL_PAD_GPIO_AD_B1_09 设置为启用驱动强度，因为将其设置为 0 不会启用输出驱动。 GPIO_SD_B1_04 和 GPIO_AD_B1_05 没有柔性定时器功能： 在此查看 1064 引脚复用器电子表格： https://www.utasker.com/iMX/iMXRT1064/iMX_RT_1064.xls Regards Mark Re: i.MX RT1064: Issues enabling FlexPWM on GPIO_AD_B1_09 你好@shreya1、 你使用的是自定义板还是 EVK？我知道您是根据示例代码将引脚初始化为 PWM，但您修改了示例代码的哪些具体部分？此外，还可以让 ConfigTools 将 GPIO_AD_B1_09 引脚配置为 PWM，甚至整个 PWM 模块。 BR, Edwin. Re: i.MX RT1064: Issues enabling FlexPWM on GPIO_AD_B1_09 嗨 @EdwinHz， 我使用的是自定义板，从示例代码中我根据自己的密码更改了 PWM 编号、子模块和通道。我尝试了另一种方法，也使用了外设工具，让它来管理整个配置，但我没有看到任何输出。 你好@mjbcswitzerland， ，我确保完成了你提到的两项设置，但仍然看不到任何输出。我确定引脚已被路由，因为在将其配置为 GPIO 时，我看到了切换。 Re: i.MX RT1064: Issues enabling FlexPWM on GPIO_AD_B1_09 你好@shreya1、 感谢您的澄清。如果你能分享代码，我可以看一看，以便更好地理解初始化，更好地确定问题是与软件还是硬件有关。 BR, Edwin.

FRDM-IMXRT1186 I want to use FRDM-IMXRT1186. Application 1 > Board Should work with Internal 1.5MB RAM and with External QSPI Flash. A> Ethernet 1 MII port (Named with Label ECAT0) can be configured with TCP/IP MODBUS Master ?  B> Ethernet 2 MII port (Named with Label ECAT1) can be configured with ETHERCAT Master ? Application 2 > Board Should work with Internal 1.5MB RAM and with External QSPI Flash. Arduino & MC Interface connector. A> Ethernet 1 MII port (Named with Label ECAT0) & Ethernet 2 MII port (Named with Label ECAT1) can be used for Ethercat Slave & Arduino & MC Interface connector Analog/Digital GPIO ? Re: FRDM-IMXRT1186 Hi @sarikaautomations , Thanks for your interest in NXP MIMXRT series! 1. A: It's recommend using J56A/J56B (RGMII ports for ETH0/ETH2) for TCP/IP/Modbus communication. Using J57A (ECAT0 port) is not advised. B: No. The RT1180 integrates ESC, not an ECAT master. 2. Yes, this is supported. For more detailed information, please refer to this guide: UM12450: FRDM-IMXRT1186 Board User Manual Best regards, Gavin

s32k3 eMIOS IMP 模式 你好、 我目前正试图在 s32k3 微型计算机上使用 eMIOS IPM 模式读取输入信号频率。在等待状态寄存器告诉我它已捕获测量值后，我先读取 A 寄存器，然后读取 B 寄存器，并对两种情况（正常情况和溢出情况）执行周期计算。但是，计算结果给出的是"High Time" 或"Low time" ，而不是信号的周期。看来IPM模式给我的是高/低占空比，而不是周期。有什么好办法解决这个问题吗？我已确认控制寄存器使用了正确的模式。 谢谢！ Re: s32k3 eMIOS IMP Mode @VaneB你好， ，我也遇到了类似的问题，你能分享一下我如何配置 EMIOS 来测量频率吗？ Re: s32k3 eMIOS IMP Mode 你好@jfranklin 如果可能的话，能否与我们分享一下您的配置？ Re: s32k3 eMIOS IMP Mode 你好，这是我们自己的软件。我们的目标是不使用提供的图形界面。基本上，我只是想读取频率输入的周期。尽管 IPM 模式应该只在上升沿或下降沿更新，但它似乎在上升沿和下降沿都更新。 Re: s32k3 eMIOS IMP Mode 你好@jfranklin 您使用的是 RTD 控制器还是定制软件？能否提供有关您申请的更多信息？ BR、VaneB

Getting Started with FRDM-A-S32K312 Using Model-Based Design Toolbox (MBDT) Table of Contents 1. Introduction 2. Requirements 2.1 Software Required 2.2 Hardware Required 3. NXP Account Login 4. Installation 4.1 PEmicro Driver Installation 4.2 FreeMASTER Installation 4.3 MATLAB® Installation 4.4 MATLAB® Add-Ons Installation 4.5 MBDT for S32K3 v1.8.0 Installation 5. Running a Demo from the MBDT Examples for S32K3 6. Running a Motor Control Demo using MBDT 7. Conclusion 1. Introduction This article aims to help new users prepare and install the necessary software and hardware to use the FRDM Automotive S32K312 with the latest  Model-Based Design Toolbox for S32K3 version 1.8.0. Note: These steps can also be followed with any NXP Evaluation Board from the supported list referenced in the toolbox documentation. S32K312MINI‑EVB Renamed to FRDM‑A‑S32K312: Now part of the FRDM Automotive Ecosystem under its new name, the board keeps the same hardware and adds full ecosystem compatibility for flexible, scalable development.     2. Requirements   2.1 Software Required MATLAB® R2023b or later, with the following Add-ons: AUTOSAR Blockset Embedded Coder Support Package for ARM Cortex-M Processors Motor Control Blockset NXP_Support_Package_S32K3 Stateflow NXP Model-Based Design Toolbox for S32K3 version 1.8.0 FreeMASTER Run-Time Debugging Tool PEmicro Hardware Interface Drivers   2.2 Hardware Required FRDM-A-S32K312 Development Board MCSPTE1AK344 Motor Control Kit, which includes: Sunrise motor  DEVKIT-MOTORGD  12V power supply USB Type-C cable   3. NXP Account Login Open Software Licensing: Support, make sure you are logged into your NXP Account, and select: Click on My NXP Account. Select Software Licensing and Support. Then click on View accounts: These steps will ensure that you are properly authenticated with your NXP Account before proceeding with step 4.5 MBDT for S32K3 v1.8.0 Installation. Keep the page open for the login to persist.   4. Installation Note: Before proceeding, make sure you have full access to your PC or Laptop. Some installers require local admin rights. Contact your IT department to assist you with installation. 4.1 PEmicro Driver Installation After downloading the PEmicro Hardware Interface Drivers: Open the installer package and select the default Destination Folder: Click on Install and then wait for it to finish successfully. Connect the USB cable to your PC and the FRDM Automotive S32K312 board: Open Device Manager to check OpenSDA and the COM port number. OpenSDA - CDC Serial Port → note this COM port number: Note: The COM port number may differ on your system.   4.2 FreeMASTER Installation Download the  FreeMASTER Run-Time Debugging Tool: Open the installer FMASTERSW32.exe Click Next, then select all available products: Use the default installation path: C:\NXP\FreeMASTER 3.2 Wait for the installation to complete.   4.3 MATLAB® Installation First, check whether MATLAB® R2023b or later is already installed. If so, you can skip this section. For this tutorial, MATLAB® R2025b is downloaded from MathWorks®: Download the matlab_R2025b_Windows.exe (246 MB) file. A MathWorks® Account login is required. After signing in, select the installation directory; the default is C:\Program Files\MATLAB\R2025b For minimum requirements, install the following products: MATLAB® Simulink® AUTOSAR Blockset Embedded Coder MATLAB® Coder Motor Control Blockset Simulink® Coder Stateflow By default, Select All is enabled during install: Wait for the installation to finish. After installation, open MATLAB® and change the default Add-ons path to a shorter path such as C:\MathWorks .   4.4 MATLAB® Add-Ons Installation Open Add-On Explorer and install: Embedded Coder Support Package for ARM Cortex-M Processors NXP Support Package for S32K3 (NXP_Support_Package_S32K3)   4.5 MBDT for S32K3 v1.8.0 Installation After installing the support package, run the following command in MATLAB®: sp_s32k3.nxp.setup(); Select version 1.8.0; the installer will check prerequisites: If any toolboxes are missing, install them before continuing. Click Download to proceed. The Download button opens the Software Terms and Conditions dialog; if the page is not loading properly, follow the steps in 3. NXP Account Login. After reading, click I Agree. Download the SW32_MBDT_S32K3_1.8.0_D2512.mltbx file (approx. 1.6 GB): Once the download completes, browse to the location of the SW32_MBDT_S32K3_1.8.0_D2512.zip file: Click Install to proceed and accept the license agreement. After a few minutes, the dialog will display: Installation successfully completed! Click Next. Select an option such as Open S32K3 Root Folder. MATLAB®'s current folder will change to the root of the toolbox. Click Finish to close the installer. The current folder in MATLAB® is now C:\MathWorks\Toolboxes\NXP_MBDToolbox_S32K3 :   5. Running a Demo from the MBDT Examples for S32K3 Navigate to C:\MathWorks\Toolboxes\NXP_MBDToolbox_S32K3\S32K3_Examples\demos\s32k3xx_uart_leds_s32ct Open the model s32k3xx_uart_leds_s32ct.mdl . Click on Hardware Settings: Go to Hardware Board Settings → Hardware → Select Configuration Project Template: For the FRDM-A-S32K312 select Custom: S32K312MINI-EVB S32 Config Tool. A Warning Dialog will appear; click OK. Wait for the configuration update to complete. Click on Apply and close the Configuration Parameters window. Press Build, Deploy & Start (CTRL+B) to generate the code: After the build completes successfully, the executable is downloaded to the board. Open a terminal application and connect to the board's COM port at 115200 baud: Pressing r, g, or b on the keyboard toggles the corresponding RGB LED on the board.   6. Running a Motor Control Demo using MBDT Navigate to C:\MathWorks\Toolboxes\NXP_MBDToolbox_S32K3\S32K3_Examples\mc\PMSM Open the folder s32k312_mc_pmsm_2sh_s32ct : Open the model s32k312_mc_pmsm_2sh_s32ct.mdl : Press Build, Deploy & Start (CTRL+B) to generate the code. After the executable file is downloaded to the board: Disconnect the FRDM-A-S32K312 board from the PC. Insert the DEVKIT-MOTORGD on top of the FRDM-A-S32K312, ensuring proper pin alignment. Plug in the 12V power supply to the DEVKIT-MOTORGD. Reconnect the USB Type-C cable to the FRDM-A-S32K312.  The RGB LED and User Buttons are on the top side, the Reset Button is on the left side, while the 12V power, Motor Phases, and USB Type-C are on the right side.    Open FreeMASTER s32k312_mc_pmsm_2sh_s32ct.pmpx : Press GO to connect at 115200 baud. In the App Control tab, press On and set Speed Required to 1000 RPM: Apply a small mechanical load to the motor (friction force to the motor shaft) and observe the iABC currents. Here is a short video with the steps above explained: (function() { var wrapper = document.getElementById('lia-vid-6397308123112w960h540r525'); var videoEl = wrapper ? wrapper.querySelector('video-js') : null; if (videoEl) { if (window.videojs) { window.videojs(videoEl).ready(function() { this.on('loadedmetadata', function() { this.el().querySelectorAll('.vjs-load-progress div[data-start]').forEach(function(bar) { bar.setAttribute('role', 'presentation'); bar.setAttribute('aria-hidden', 'true'); }); }); }); } }})(); (view in My Videos)   7. Conclusion These steps conclude the Getting Started with FRDM Automotive S32K312 using the Model-Based Design Toolbox guide. For more details, refer to: s32k312_mc_pmsm_2sh_s32ct_example_readme.html The corresponding example_readme.html for the selected model. Thank you for your time, Stefan V.

How to Update eIQ Projects with the Latest eIQ Neutron SDK Libraries eIQ Neutron SDK is a new software package that includes the Neutron Converter tool and eIQ Neutron libraries to run Neutron converted neural network models on devices that have an eIQ Neutron NPU like MCX N, i.MX RT700, or i.MX95 Previously the Neutron Converter tool was part of eIQ Toolkit. However going forward, new versions of the Neutron Converter tool will be released as part of the eIQ Neutron SDK. This change will allow for more frequent updates to provide better performance and additional operator support. MCUXpresso SDK and Linux BSP use Neutron libraries as part of the eIQ examples included in those software releases. However to use the latest Neutron Converter, an eIQ project will need to be updated to use the latest Neutron software libraries. This post walks through where to place the updated Neutron libraries and header files.  If the version of the Neutron Converter tool that was used to convert a model does not match the Neutron libraries used by the eIQ project, then during inference you will see the following error(s) printed on the serial terminal and may get incorrect results: Microcode version mismatch Or Internal Neutron NPU driver error 281b in model prepare Or Incompatible Neutron NPU microcode and driver versions The version of the Neutron Converter tool that was used to convert a model can be found by either viewing the converted model in Netron or by looking at the generated header file:   Here is a table showing where you can find the matching version of the Neutron Converter tool for the default Neutron libraries found in different versions of MCUXpresso SDK: MCUXpresso SDK Default Neutron Library Version in MCUXpresso SDK Default Compatible Neutron Converter Can Be Found In 24.12 1.2.0+0x6f710a6d eIQ Toolkit 1.17 25.03 1.2.0+0X1b86b19d eIQ Toolkit 1.17 25.06 2.0.2 eIQ Toolkit 1.17 25.09 2.1.3 eIQ Toolkit 1.17 25.12 2.2.2 eIQ Neutron SDK 2.2.2 26.03 3.0.0 eIQ Neutron SDK 3.0.0 Manually Update SDK Libraries To Use Latest Version eIQ Neutron SDK 3.1.2 It is highly recommend to always use the latest Neutron Converter tool and to update the libraries in your eIQ project to match the latest Neutron Converter tool. The libraries can be updated by overwriting the original files. You may wish to make a backup first though as the default eIQ examples in that SDK will use models that were converted to match those original Neutron libraries. The Neutron file structure in eIQ Neutron SDK and MCUXpresso SDK are now the same so that the entire Neutron folder can be overwritten directly.  Updating Neutron Libraries in MCUXpresso SDK 25.12 and later: File Source Directory in eIQ Neutron SDK Target Directory in MCUXpresso SDK libNeutronDriver.a target\imxrt700\ rt700\cm33\ \middleware\eiq\neutron\rt700\cm33\ libNeutronFirmware.a target\imxrt700\ rt700\cm33\ \middleware\eiq\neutron\rt700\cm33\ NeutronDriver.h target\imxrt700\ driver\include\ \middleware\eiq\neutron\driver\include\ NeutronErrors.h target\imxrt700\ common\include\ \middleware\eiq\neutron\common\include\ Note: The target\imxrt700\driver\include\NeutronEnvConfig.h and the libraries in target\imxrt700\cmodel are used by the ExecuTorch inference engine and so are not needed for TFLM eIQ projects.  Note: In MCUXpresso SDK 26.03 there are two sets of Neutron libraries in imported projects. It's the files in the /middleware/eiq folder that need to be updated.  Updating Neutron Libraries in MCUXpresso SDK 25.09 or before: File Source Directory in eIQ Neutron SDK Target Directory in MCUXpresso SDK libNeutronDriver.a target\imxrt700\ rt700\cm33\ \middleware\eiq\tensorflow-lite\third_party\neutron\rt700\ libNeutronFirmware.a target\imxrt700\ rt700\cm33\ \middleware\eiq\tensorflow-lite\third_party\neutron\rt700\ NeutronDriver.h target\imxrt700\ driver\include\ \middleware\eiq\tensorflow-lite\third_party\neutron\driver\include\ NeutronErrors.h target\imxrt700\ common\include\ \middleware\eiq\tensorflow-lite\third_party\neutron\common\include\ Updating Neutron Libraries for MCUXpresso SDK 2.16 or before: Replace the entire middleware\eiq directory from MCUXpresso SDK 26.03 into your project, and then the Neutron libraries can be updated per the instructions above. In these older MCUXpresso SDK releases there were additional eIQ changes beyond just the four files above, so the easiest method to update those older projects is just to replace the entire eIQ middleware directory.  Updating Neutron Libraries for i.MX devices: To update the neutron runtime on a target device, upload the files to their designated directories, as follows: File Target Directory NeutronFirmware.elf /lib/firmware libNeutronDriver.so /lib/ libneutron_delegate.so /lib/

MCUXpresso IDE 上的 ITM 与 UART 打印。 1. 简介 在嵌入式系统开发中，调试和日志输出对于确保代码正确性和优化性能至关重要。通过实时监控系统状态、捕获异常行为并记录关键数据，开发人员能够快速发现问题并验证功能。在资源受限的嵌入式环境中，选择合适的调试工具和方法显著影响开发效率。 MCXN947 是恩智浦上市的高性能微控制器，提供多种调试和记录解决方案，其中最常用的是ITM（仪器跟踪宏单元）和UART打印。ITM 利用 Cortex-M 内核的调试功能，通过调试接口高速传输数据，使其适用于具有严格实时要求的场景。UART 打印则通过 UART 外设输出日志，具有很强的通用性，适合生产环境。 本文解释了如何在MCUXpresso IDE 中使用这两种输出方法，以提高开发效率和系统可靠性。 2. ITM 和 UART 打印的原理和特点 2.1 ITM – 原理与特点 工作原理： ITM（Instrumentation Trace Macrocell）是 Cortex-M 内核提供的一项调试功能。它通过调试接口（例如 SWD/JTAG）使用 SWO 实时传输数据。开发人员可以使用 ITM_SendChar() 函数将调试信息发送到 ITM端口，然后由调试器捕获并显示在 IDE 的调试控制台中。 优势： 高速传输：ITM 利用调试接口的带宽，速度远超 UART（通常超过 10 Mbps）。 低 CPU 占用： ITM 由硬件处理，几乎不消耗 CPU 资源。 无额外外设： 不依赖 UART 或其他外设，节省硬件资源。 劣势： 调试器依赖： 需要连接调试器（如 MCU-Link、J-Link），不能直接用于生产环境。 配置复杂：需要正确的 ITM 端口和调试器设置，这对初学者来说可能具有挑战性。 2.2 UART 打印——原理和特点 工作原理： UART 打印通过 UART 外设将调试信息发送到串行终端。开发人员通常将 printf 函数重定向到UART，从而使标准库函数用于日志输出。数据通过 TX/RX 引脚传输，可以使用串行工具（例如 PuTTY、Tera Term）在 PC 上查看。MCUXpresso IDE 还内置了一个用于 UART 调试的终端。 优势： 高度通用：几乎所有嵌入式板都支持UART，使其广泛适用。 生产就绪：不需要调试器，可以直接在生产环境中使用。 易于实施：配置简单，非常适合初学者和快速原型制作。 劣势： 低速： 受限于 UART 波特率，导致传输效率降低。 外围资源使用： 占用 UART 外设和引脚，可能影响其他功能。 实时性能差： 由于中断延迟和波特率限制，不适合高实时场景。 2.3 对比总结 下表总结了 ITM 与 UART 打印的主要特点： 特性 ITM UART 打印 传输速度 高（10 Mbps 或更高） 低（通常为 115200 bps） CPU 开销 低 更高 外围依赖 无 需要 UART 外设和引脚 调试器依赖 需要 不需要 生产适用性 不合适 合适 配置复杂性 复杂 Simple 实时性能 高 低 使用场景： ITM： 非常适合开发阶段调试，且实时需求高（如电机控制、信号处理）。 UART 打印： 适合生产日志、初学者友好的设置以及一般调试需求。 3. 在 MCUXpresso IDE 中的实施步骤 3.1 使用 ITM 打印 硬件需求： 确保芯片的 SWO 引脚连接到调试器的 SWO 接口。 软件配置： 1）创建新项目时，选择“Redirect printf/scanf to ITM”以将 printf/scanf 重定向到 ITM。   2) 配置跟踪时钟： /*!< Switch TRACE to TRACE_DIV */ CLOCK_AttachClk(kTRACE_DIV_to_TRACE); /*!< Set up dividers */ /*!< Set TRACECLKDIV divider to value 3 */ CLOCK_SetClkDiv(kCLOCK_DivTraceClk, 3U);   3）在 MCUXpresso 集成开发环境中，打开 SWO ITM 控制台，配置核心时钟和跟踪时钟设置。     4）在 ITM 控制台中查看输出结果。 3.2 使用 UART 打印 1）创建新项目时，选择 SDK 调试控制台为 UART，设置 DebugConsole 使用 UART。          2）使用 MCUXpresso IDE 的外设工具配置 DebugConsole-UART。   3）使用引脚工具配置 UART TX/RX 引脚。 4）连接串行硬件，并在终端中查看输出结果。 4. 结论 ITM 和 UART 打印各有其优势。开发人员应根据项目需求选择合适的方法。ITM 更适合在开发过程中进行高实时调试，而 UART 打印则更适合生产环境和一般调试。

Imx95 verdin EVK、Aquantia10gbps 接口在 udp 上的速度限制为 1.2gbps 你好 我正在尝试通过两个 Imx95 verdin EVK A1 Silicon 版本板的 Aquantia 10 Gbps 接口在它们之间建立通信。两块板均运行 Debian 12（linux 内核 6.12.3），使用恩智浦安装程序（aquantia-firmware-utility/aq_api_2_9_7 at master 的 aquantia-firmware-utility/aq_api_2_9_7）正确安装了 aquantia10 G 固件（aqr-g4_v5.6.d-aqr_Marvell_noswap_xfi_id44834_ver2068.cld）aquantia-固件实用程序·GitHub)。它们使用 Cat6a 以太网电缆进行物理连接。 当我使用 iperf3 进行性能测试时，即使指定的目标带宽为 7 Gbps，我也能获得约 5 Gbps 的 TCP 带宽和 1.2 Gbps 的 UDP 带宽，损耗率为 0% ： # TCP 在第一块板上测试 iperf3-s # iperf3-c < Server_IP >-t 30 # 在第二块板上测试 iperf3-s # # 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 接口吗？ 此致， Abdelmonaem Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 您好， 感谢您的反馈， 应用您的配置： cpufreq-set -g performance 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' 现在，我在发射端仅使用 iperf 而不是 iperf3，就能达到 10Gbps 的速度，有时甚至能达到 8,8 或 9,8Gbps 的速度，而在接收端，我只能达到 5.59Gbps 的速度，丢失帧数为 36% ，您能帮助解决这个问题吗？ Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 1.尝试在两个系统上配置以下设置： cpufreq-set -g performance 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 服务器（例如英特尔至强） 3. iperf3 本身对每个测试流都是单线程的，请尝试使用 -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 它将是一个小版本升级到 6.12.49 顺便提一下，您可能还需要考虑 DPDK 或 AF_XDP，以获得更好的吞吐量？ Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp => TCP 与 UDP 的发送性能对比 使用 iperf3 发送 TCP 数据包时，每个 TCP 数据包为 128KB，数据包将被 ENETC 硬件的 LSO 功能分片。因此，你会看到更高的 TCP 传输性能。 iperf3 在创建 UDP 套接字时没有启用 UDP_SEGMENT。因此： -每个 UDP 数据包的大小约为 MTU（约 1500 字节）。 - 在数据量相同的情况下，UDP 需要比 TCP 发送更多的数据包。 更多数据包→更多内核处理→与带 LSO 的 TCP 相比性能降低。 => 为什么 TCP 的接收比发送低很多？ - 在 Linux 内核中，TX 和 RX 路径并不对称，因此内核中每个 RX 数据包和每个 TX 数据包的处理时间是不同的。 - RSC 在内核中默认未启用；我们需要禁用 TCP 时间戳，这样 ENETC 的 RSC 才能正常工作。目前，i.MX95 的 RSC 默认为禁用。 a) 启用 i.MX95 的 RSC（接收端）： ethtool -K eth1 large-receive-offload on b) 禁用 TCP 时间戳（发送端）： sysctl -w net.ipv4.tcp_timestamps=0 sysctl -p /etc/sysctl.conf 启用 RSC 后，接收端的 TCP 性能将会提高。 此外，您还可以尝试使用巨型帧来获得更高的吞吐量。（希望你运行的是最新版本）。 # 将两侧的 MTU 更改为 9000 ip link set dev eth1 mtu 9000 # 更改以太网驱动程序中的 RX 缓冲区长度。 ethtool -G eth1 rx-buf-len 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）。 问候， Abdelmonaem 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 RSC 设置还能提高 UDP 性能。 ENETC 中巨型帧的更改/修复将在两周后发布的 LF-Q4 版本中发布。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 使用 iperf 时，我的速度可以达到 10Gbps，有时甚至可以达到 9.8Bps；在并行数据流中，只有一个数据流的速度可以达到 5Gbps，但最大的问题是 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，每个 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 数据包提供真正的快速性能。 您可以登录 第 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？？ 我在你的电路板支持包交付中看不到这个内核版本，最后一个是 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 版本。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 我不明白这几行的意思： Single UDP Stream send (1500 MTU): 2 Gbps（在单数据流中，MTU 为 1500 的 tx 速率似乎为 2Gbps） Multi UDP Stream send (1500 MTU).10Gbps（在多数据流中，MTU 为 1500 的 tx 速率似乎为 10Gbps）：10Gbps（在多数据流中使用 MTU 1500 发送时，速率为 10Gbps） 单 UDP 数据流发送（MTU 为 9000）：8.2 Gbps（在单数据流中，使用 MTU 900 的 tx 速率为 8.2 Gbps） 接收单 UDP 数据流（MTU 为 9000）：3.9 Gbps（在多数据流中，使用 MTU 1500 的 tx 速率为 10Gbps）：3.9Gbps（在单数据流中使用 MTU 为 9000 的接收端，速度为 3.9Gbps） 多 UDP 数据流接收（MTU 为 9000）：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- RX/TX，MTU = 1500，两端均为单声道和多声道流 2- RX/TX，MTU = 9000，两端均为单声道和多声道流 谢谢您的帮助。 Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 是的，结果就是这样检验出来的。 所有情况下，双方的 MTU 都相同（都是 1500 或都是 9000） Re: Imx95 verdin EVK, Aquantia10gbps interface limited on 1.2gbps on udp 见附件、 请注意，我也是在 A1 SOC 上运行的。 UBOOT 日志：- U-Boot 2025.04-g8c1de2e1deca(May 09 2025 - 15:29:26 +0000) CPU：1800MHz 时的 i.MX95 rev1.1 CPU：30 摄氏度时的汽车温度等级（-40 摄氏度至 125 摄氏度） LM 启动原因：sw，起源：2，错误：1 LM 关机原因：sw，起源：2，错误：1 型号：恩智浦 i.MX95 19X19 板 动态随机存取存储器(DRAM)：15.8GiB --- SM 日志 >$ info SM 版本 = 版本 633，Commit c37b26da SM Config = mx95evk，mSel=0 板 = i.MX95 EVK，attr=0x00000000 硅 = i.MX95 A1 启动模式 = 普通 引导设备 = MMC1 启动阶段 = primary 启动集 = 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

i.MX8Qを例に、gpioget/gpiosetでGPIO（libgpiod）を使用する方法 GPIO制御におけるgpiogetおよび「cat /sys/class/gpio」の違い。 gpioget : これは、 libgpiod ライブラリが提供するコマンドライン・ユーティリティです。最新のLinux GPIOキャラクタ・デバイス・インターフェース（ /dev/gpiochipN ）を介して、GPIOラインとやり取りするように設計されています。 /sys/class/gpio : これは、LinuxのGPIO制御のためのsysfsレガシー・インターフェースを指します。このインターフェースは、かつて広く使用されていましたが、Linuxカーネルバージョン6.0以降、 libgpiod キャラクタ・デバイス・インターフェースが採用され、正式に非推奨になりました。 以下は、i.MX8Q-MEK、L6.12.3 BSPでテストされたlibgpiodの例です。 デバイスツリーの設定： この例では、GPIO1-05およびGPIO1-06を使用します。GPIO pinctrlを「gpio_test」のような特定のグループ、または「gpio-keys」のようなドライバの下に置くことができます。 gpio_test: gpio-test { pinctrl-names = "default", "sleep"; pinctrl-0 = <&pinctrl_gpio_test_default>; pinctrl-1 = <&pinctrl_gpio_test_sleep>; status = "okay"; }; gpio-keys { compatible = "gpio-keys"; pinctrl-names = "default", "sleep"; pinctrl-0 = <&pinctrl_gpio_example_default>; pinctrl-1 = <&pinctrl_gpio_example_sleep>; key_wakeup2{ label = "wakeup_key"; gpios = <&lsio_gpio2 1 GPIO_ACTIVE_LOW>; linux,code = ; wakeup-source; }; pinctrl_gpio_test_default: gpiotestgrp_default { fsl,pins = < IMX8QM_LVDS0_I2C0_SDA_LSIO_GPIO1_IO07 0x06000061 IMX8QM_QSPI1A_DATA0_LSIO_GPIO4_IO26 0x06000041 IMX8QM_MIPI_CSI1_I2C0_SCL_LSIO_GPIO2_IO00 0x06000021 IMX8QM_LVDS0_I2C0_SCL_LSIO_GPIO1_IO06 0x06000021 >; }; pinctrl_gpio_test_sleep: gpiotestgrp_sleep { fsl,pins = < IMX8QM_LVDS0_I2C0_SDA_LSIO_GPIO1_IO07 0x07800061 IMX8QM_QSPI1A_DATA0_LSIO_GPIO4_IO26 0x07800041 IMX8QM_MIPI_CSI1_I2C0_SCL_LSIO_GPIO2_IO00 0x07800021 IMX8QM_LVDS0_I2C0_SCL_LSIO_GPIO1_IO06 0x07800021 >; }; pinctrl_gpio_example_default: gpioexamplegrp_default { fsl,pins = < IMX8QM_LVDS0_GPIO01_LSIO_GPIO1_IO05 0x06000021 IMX8QM_MIPI_CSI1_I2C0_SDA_LSIO_GPIO2_IO01 0x06000021 >; }; pinctrl_gpio_example_sleep: gpioexamplegrp_sleep { fsl,pins = < IMX8QM_LVDS0_GPIO01_LSIO_GPIO1_IO05 0x07800021 IMX8QM_MIPI_CSI1_I2C0_SDA_LSIO_GPIO2_IO01 0x07800021 >; }; GPIO機能をテストするためのカーネル・コマンド： gpiodetect および gpioinfo コマンド： root@imx8qmmek:~# gpiodetect gpiochip0 [5d080000.gpio] (32 lines) gpiochip1 [5d090000.gpio] (32 lines) gpiochip2 [5d0a0000.gpio] (32 lines) gpiochip3 [5d0b0000.gpio] (32 lines) gpiochip4 [5d0c0000.gpio] (32 lines) gpiochip5 [5d0d0000.gpio] (32 lines) gpiochip6 [5d0e0000.gpio] (32 lines) gpiochip7 [5d0f0000.gpio] (32 lines) root@imx8qmmek:~# gpioinfo -c 1 gpiochip1 - 32 lines: line 0: unnamed input line 1: unnamed input line 2: unnamed input line 3: unnamed input line 4: unnamed input line 5: unnamed input line 6: unnamed output line 7: unnamed output line 8: unnamed input line 9: unnamed input line 10: unnamed input line 11: unnamed input line 12: unnamed input line 13: unnamed output consumer=regulator-pcie line 14: unnamed input line 15: unnamed input line 16: unnamed input line 17: unnamed input line 18: unnamed input line 19: unnamed input line 20: unnamed input line 21: unnamed input line 22: unnamed input line 23: unnamed input line 24: unnamed input line 25: unnamed input line 26: unnamed input line 27: unnamed input line 28: unnamed input line 29: unnamed input line 30: unnamed input line 31: unnamed input GPIO1-05およびGPIO1-06が設定される前の現在のGPIO設定を表示するには、 cat /sys/kernel/debug/gpio を使用します。 root@imx8qmmek:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 512-543, parent: platform/5d080000.gpio, 5d080000.gpio: gpio-526 ( |scl ) out lo gpio-527 ( |sda ) in lo gpiochip1: GPIOs 544-575, parent: platform/5d090000.gpio, 5d090000.gpio: gpio-557 ( |regulator-pcie ) out hi gpiochip2: GPIOs 576-607, parent: platform/5d0a0000.gpio, 5d0a0000.gpio: gpio-577 ( |wakeup_key ) in hi ACTIVE LOW gpiochip3: GPIOs 608-639, parent: platform/5d0b0000.gpio, 5d0b0000.gpio: gpio-618 ( |spi1 CS0 ) out hi ACTIVE LOW gpiochip4: GPIOs 640-671, parent: platform/5d0c0000.gpio, 5d0c0000.gpio: gpio-641 ( |enable ) out hi ACTIVE LOW gpio-643 ( |regulator-usbotg1-vb) out lo gpio-647 ( |usdhc2-vmmc ) out hi gpio-667 ( |enable ) out lo ACTIVE LOW gpio-668 ( |host-wake ) in hi ACTIVE LOW gpio-669 ( |PCIe reset ) out hi ACTIVE LOW gpiochip5: GPIOs 672-703, parent: platform/5d0d0000.gpio, 5d0d0000.gpio: gpio-673 ( |mux ) out hi gpio-693 ( |wp ) in lo gpio-694 ( |cd ) in lo ACTIVE LOW gpiochip6: GPIOs 704-735, parent: platform/5d0e0000.gpio, 5d0e0000.gpio: gpiochip7: GPIOs 736-767, parent: platform/5d0f0000.gpio, 5d0f0000.gpio: gpioset コマンドを使用してGPIO出力を設定します。また、GPIOの方向を変更することもできます（入力→出力）。 #set gpiochip1-5 and 1-6 root@imx8qmmek:~# gpioset -c gpiochip1 6=1 & [1] 700 root@imx8qmmek:~# gpioset -c gpiochip1 5=1 & [2] 702 上記のコマンドの変更点を cat /sys/kernel/debug/gpio および gpioinfo -c 1 で確認してください。 root@imx8qmmek:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 512-543, parent: platform/5d080000.gpio, 5d080000.gpio: gpio-526 ( |scl ) out lo gpio-527 ( |sda ) in lo gpiochip1: GPIOs 544-575, parent: platform/5d090000.gpio, 5d090000.gpio: gpio-549 ( |gpioset ) out hi gpio-550 ( |gpioset ) out hi gpio-557 ( |regulator-pcie ) out hi gpiochip2: GPIOs 576-607, parent: platform/5d0a0000.gpio, 5d0a0000.gpio: gpio-577 ( |wakeup_key ) in hi ACTIVE LOW gpiochip3: GPIOs 608-639, parent: platform/5d0b0000.gpio, 5d0b0000.gpio: gpio-618 ( |spi1 CS0 ) out hi ACTIVE LOW gpiochip4: GPIOs 640-671, parent: platform/5d0c0000.gpio, 5d0c0000.gpio: gpio-641 ( |enable ) out hi ACTIVE LOW gpio-643 ( |regulator-usbotg1-vb) out lo gpio-647 ( |usdhc2-vmmc ) out hi gpio-667 ( |enable ) out lo ACTIVE LOW gpio-668 ( |host-wake ) in hi ACTIVE LOW gpio-669 ( |PCIe reset ) out hi ACTIVE LOW gpiochip5: GPIOs 672-703, parent: platform/5d0d0000.gpio, 5d0d0000.gpio: gpio-673 ( |mux ) out hi gpio-693 ( |wp ) in lo gpio-694 ( |cd ) in lo ACTIVE LOW gpiochip6: GPIOs 704-735, parent: platform/5d0e0000.gpio, 5d0e0000.gpio: gpiochip7: GPIOs 736-767, parent: platform/5d0f0000.gpio, 5d0f0000.gpio: root@imx8qmmek:~# gpioinfo -c 1 gpiochip1 - 32 lines: line 0: unnamed input line 1: unnamed input line 2: unnamed input line 3: unnamed input line 4: unnamed input line 5: unnamed output consumer=gpioset line 6: unnamed output consumer=gpioset line 7: unnamed output line 8: unnamed input line 9: unnamed input line 10: unnamed input line 11: unnamed input line 12: unnamed input line 13: unnamed output consumer=regulator-pcie   レガシーGPIO SYSFS（L6カーネル以上ではデフォルトで無効）を有効にする方法 このコミットのコメントを参照してください。 https://github.com/nxp-imx/linux-imx/commit/3b4feb21158f873269ff3fbe2fe8d23a88d64b24 commit 3b4feb21158f873269ff3fbe2fe8d23a88d64b24 Author: Linus Walleij Date: Tue Nov 10 15:27:24 2020 +0100 gpio: sysfs: Enforce character device If users select sysfs support they get the character device as well so that end-users cannot complain that they "only have sysfs on my system". They should have the character device at all times. If someone is in so dire need of stripping out the character device while still enabling the sysfs ABI they can very well patch the kernel. Also only show this obsolete option to expert users. Signed-off-by: Linus Walleij Link: <> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 5d4de5cd6759..4dd566f7ea39 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -59,8 +59,9 @@ config DEBUG_GPIO that are most common when setting up new platforms or boards. config GPIO_SYSFS - bool "/sys/class/gpio/... (sysfs interface)" + bool "/sys/class/gpio/... (sysfs interface)" if EXPERT depends on SYSFS + select GPIO_CDEV # We need to encourage the new ABI help Say Y here to add the legacy sysfs interface for GPIOs. パッチから、GPIO_SYSFSを有効にするための最良の方法は、CONFIG_EXPERT= y、次に、CONFIG_GPIO_SYSFS= Yを有効にします。パッチを元に戻す必要はありません。 SYSFSは、LinuxのGPIO制御のためのレガシー・インターフェースです。このインターフェースは、かつて広く使用されていましたが、Linuxカーネルバージョン6.0以降、libgpiodキャラクタ・デバイス・インターフェースが採用され、正式に非推奨になりました。 i.MX Processors

如何构建示例项目的版本 — S32K1 AUTOSAR 您好，NXP团队， 我目前正在使用 S32K1 AUTOSAR RTD 2.0.0 示例项目。 我创建了一个 GPIO_DIO_LP_example_s32K118 项目并成功构建了 Debug_Flash 版本 。 不过，该示例项目默认情况下似乎只支持在调试模式下构建。 你能告诉我如何配置项目来构建发布版本吗？ 感谢您的支持！ Re: How to Build Release Version of Example Project – S32K1 AUTOSAR 你好，彼得斯 谢谢您的建议。 Re: How to Build Release Version of Example Project – S32K1 AUTOSAR 您好， 你可以进入项目的属性并添加新的版本配置 输入新名称并从现有调试配置中复制 最后删除调试标记 然后应用并版本 BR, Petr

AUT-N1798 統合型 MagniV ソリューションによるアプリケーションの小型化 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> シングルダイ・ソリューションを備えた統合型ミックスド・シグナル・マイクロコントローラにより、システム設計を簡素化し、市場投入までの時間を短縮します。この講義では、NXP MagniVポートフォリオの概要を説明し、アプリケーションを縮小するためのソリューションを提供します。 ビデオプレゼンテーションを見る <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> シングルダイ・ソリューションを備えた統合型ミックスド・シグナル・マイクロコントローラにより、システム設計を簡素化し、市場投入までの時間を短縮します。この講義では、NXP MagniVポートフォリオの概要を説明し、アプリケーションを縮小するためのソリューションを提供します。 ビデオプレゼンテーションを見る

[技術ノート] i.MX RT1170 JEDEC互換性 この記事ではi.MXRT1170を例に挙げていますが、ルールはi.MX RTシリーズにも適用されます。 1. 背景と質問 データシート（例：RT1170A、RT1170B）には 'NON JEDEC' パッケージが以下のように示されていますが、製品品質ページ（例：MIMXRT1172AVM8A）では WSL 3 （Moisture Sensitivity Level 3）としてマークされており、これはJEDEC-STD-020で定義された湿度感度レベルの1つです。 矛盾はあるのでしょうか? 製品はJEDEC-STD-020に準拠していますか？ 2. JEDEC-STD-020とは何ですか？ JEDEC-STD-020は、リフローはんだ付け工程中の表面実装デバイス（SMD）における湿度感度レベル（MSL）および事前条件要求事項を定義した規格です。 この規格に準拠しているということは、リフローはんだ付け前のデバイスの保管および取り扱いが業界仕様に適合しており、自動化製造環境での使用に適していることを意味します。 3. WSL 3およびJEDEC-STD-020準拠 NXPの製品品質ページでは、一部のi.MX RT1170バリアントがWSL 3（Moisture Sensitivity Level 3）としてマークされており、これはJEDEC-STD-020で定義された湿度感度レベルの1つです。これは次のことを意味します。 デバイスはリフローはんだ付け前に168時間まで周囲環境にさらすことができます。 また、乾燥梱包で保管する必要があります。 JEDEC-STD-020の取り扱いおよび処理要件に準拠しています。 これは、i.MX RT1170シリーズがJEDEC-STD-020に従ってテストおよび認定されていることを示しています。NXP製品ページからの主なパラメータ： MSL（吸湿感度レベル）：3 ピークパッケージ本体温度：260°C ピーク時の時間：40秒 4. データシートにおける「NON JEDEC」パッケージ i.MX RT1170データシートでは、一部のパッケージタイプが「NON JEDEC」とラベル付けされており、通常は以下を意味します。 パッケージの寸法やレイアウトがJEDEC標準のアウトラインに厳密には従っていない デバイスが正式なJEDEC-STD-020認証プロセスを経ていない 例えば、IMXRT1170BCEC Rev.1データシートでは以下のように記載されています。 パッケージ情報：プラスチックパッケージ 289ピン MAPBGA、14 x 14 mm、0.8 mmピッチ パッケージタイプ：NON JEDEC [1] これはパッケージがJEDEC標準の機械的アウトラインではないことを示しています。ただし、必ずしもデバイスがJEDEC-STD-020で定義された湿度感度要件を満たしていないことを意味するわけではありません。 5. まとめ 「NON JEDEC」は機械的形状のみを指し、信頼性規格には関係ありません。 データシート上の「NON JEDEC」の表示は物理的なパッケージアウトラインを指しており、製品品質ページのMSL 3評価は、JEDECの試験方法に基づいて決定された信頼性および取り扱い仕様を示しています。 JEDEC-STD-020は非密閉型表面実装デバイスにおける湿度感度レベルの試験規格です。i.MX RTは、MSL評価がJEDEC-STD-020の試験プロセスに基づいていることを明確に示しています。 パッケージがJEDEC標準（例えばMO-220）に準拠しているかどうかは、JEDEC-STD-020で試験可能かどうかに直接関係しません。 ‘NON JEDEC’是指物理封装中的机械形式，不是可靠性标准。 JEDEC-STD-020 是针对非气密性表面贴装器件的湿敏等级测试标准； NXP 明确表示i.MX RT产品 MSL 等级是依据 JEDEC-STD-020 测试流程； 封装是否为 JEDEC 标准（如 MO-220）与是否能进行 JEDEC-STD-020 测试无直接关系。 6. 参考資料 NXP i.MX RT1170製品ページ： https://www.nxp.com/part/MIMXRT1172AVM8A  i.MX RT1170 データシート: https://www.nxp.com/docs/en/data-sheet/IMXRT1170CEC.pdf JEDEC-STD-020規格： https://www.jedec.org/document_search/field_doc_type/151?search_api_views_fulltext=%E2%80%8BJ-STD-020&order=title&sort=asc     

安装 Zephyr SDK 版本 Zephyr SDK 是一套用于构建 Zephyr 应用程序的构建工具。它包含 GCC 和 CMake，并且每个 Zephyr 版本都与特定的 Zephyr SDK 版本相关联。此版本已在 Zephyr 存储库的 SDK_VERSION 文件中注明。使用推荐的 Zephyr SDK 版本非常重要——版本不匹配可能导致构建错误。 例如，Zephyr v4.1指定Zephyr SDK v0.17.0。如果在 Zephyr v4.1 中使用 Zephyr SDK v0.17.2（用于 Zephyr v4.2），会遇到版本错误。如果您需要为 Zephyr v4.1 版本应用程序，请安装Zephyr SDK v0.17.0。 您可以安装多个 Zephyr SDK 版本，并在构建时进行切换（请参阅下方说明）。 完整安装与最小安装。 完全安装：包括每个支持的 SoC 架构的所有工具链。建议初学者使用，但需要更多磁盘空间和下载时间。 最小安装：允许您仅选择所需的工具链。节省空间和时间。 对于最小化安装，运行 setup.cmd 脚本选择要安装的工具。在恩智浦板上，选择： 注册 Zephyr SDK CMake 软件包 安装主机工具 aarch64-zephyr-elf （64 位 ARM） arm-zephyr-eabi （32 位 ARM，包括 NXP 微控制器） 可选 xtensa-nxp… （Cadence Tensilica DSP 内核） 安装 Zephyr SDK 这些步骤包括使用 MCUXpresso 安装程序安装 Zephyr SDK、从 CLI 安装 West 或手动下载。 使用 MCUXpresso 安装程序进行安装 MCUXpresso 安装程序从 Zephyr v4.2 开始支持 Zephyr 软件包。每个软件包都会安装相应的 Zephyr SDK 版本（例如，v4.2 软件包会安装 SDK v0.17.2）。此选项安装了面向恩智浦开发的最小工具集。 MCUXpresso 安装程序不支持更早版本的 Zephyr SDK。对于 v0.17.1 或更早版本，请使用 West 或手动安装。 使用 West CLI 进行安装 Zephyr 项目已将 Zephyr SDK 安装添加到 West。 对于命令行界面 (CLI)，请激活Python 虚拟环境，然后运行： west sdk install --version 0.17.0   如果省略 --version ，West 将使用 Zephyr 仓库的 SDK_VERSION 文件中的版本。 默认情况下，安装完整软件包。如需最小化，请添加 -i 。 通过手动下载安装 从 https://github.com/zephyrproject-rtos/sdk-ng/releases 下载 Zephyr SDK。 请根据您的主机操作系统选择完整版或精简版。 解压到您的用户文件夹（West 和 MCUXpresso 的默认位置）： Windows： C:\Users\ \zephyr-sdk-0.17.0 Ubuntu: /home/ /zephyr-sdk-0.17.0 选择 Zephyr SDK 版本 多个 Zephyr SDK 版本可以共存。West 默认使用最新版本，但你可以将其覆盖： VS Code：导入示例时，在向导中选择 Zephyr SDK 版本。 CLI：在构建前设置环境变量 ZEPHYR_SDK_INSTALL_DIR 。此命令在 Ubuntu 中设置该变量： 导出 ZEPHYR_SDK_INSTALL_DIR="/home/ /zephyr-sdk-0.17.0" 或者在 Windows 中： set ZEPHYR_SDK_INSTALL_DIR= C:\Users\ \ zephyr-sdk-0.17.0   返回 Zephyr 知识中心    

GD31xx Altium and Cadence models The attached GD3100 and GD3160 models may be used by customers in developing their schematic and PCB layout.

MIIT (China) sharpened Homologation on FRDM-KW38 & KW36 The homologation requirements in China (MIIT [2002]353) obviously are planned (end of December 2022) to be sharpened (MIIT publication from 2021-01-27: “Notice on Matters Related to Radio Management in the 2400MHz, 5100MHz and 5800MHz Bands”). A modification register is need on the KW38 and KW36 to pass the new Chinese  requirement with acceptable margin: PA_RAMP_SEL value must be set to 0x02h (2us) instead of 0x01h (1us default value) Modification SW: XCVR_TX_DIG_PA_CTRL_PA_RAMP_SEL(2) in the nxp_xcvr_common_config.c All the details are in the attached file. Note: This SW modification is for China country only. BLE Software KW KW35 | 36

EIQ Software Application based on OpenCV Neural Network Framework on Layerscape Platforms NXP created eIQ machine learning software for QorIQ Layerscape applications processors, a set of ML tools which allows developing and deploying ML applications on the QorIQ Layerscape family of devices. OpenCV is an open-source computer vision library. It offers a unitary solution for both the neural network inference (DNN module) and the standard machine learning algorithms (ML module). It includes many computer vision functions, making it easier to build complex machine learning applications in a short amount of time and without being dependent on other libraries. This document describe applications YOLO object detection, Image segmentation, Image colorization, Image classification, Human pose estimation and Text detection developed based on OpenCV DNN framework.

i.MX RT1170 DVFS デモ ダイナミック電圧および周波数スケーリング(DVFS)は、電源電圧とCPU周波数を動的にスケールダウンすることで、CPUの消費電力を動的に削減できる電力管理手法です。i.MX RT1170の内部DCDCは、125°Cの接合部温度で必要な最大電流要件をカバーできないため、DVFS技術を使用して電流ドレインを低減し、内部DCDCとの互換性を確保できます。プロセッサの周波数を動的に下げると、チップの入力電流需要を減らし、チップが125°Cの接合部温度で動作し続けることができます。 デモが添付されています。IAR と armgcc のバージョンのみが有効になります。 対応するアプリケーションノートは、以下のリンクからダウンロードできます。 https://www.nxp.com/docs/en/application-note/AN13267.pdf

将 USB 摄像头与 GStreamer 结合使用 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 如果您想在 i.MX6 设备（Linux 内核版本 >= 3.035）上将 USB 摄像头（这些类型的摄像头也称为“网络摄像头”）与 GStreamer 一起使用，您需要动态加载模块或静态编译和链接，并在内核配置中选择（Y）以下配置 设备驱动程序 -> 多媒体支持 -> 视频捕获适配器 -> V4L USB 设备 -> <*> USB 视频类 (UVC) 内核映像构建完成后，将其刷入目标，插入网络摄像头，然后在（目标）终端上运行 gst-启动 v4l2src！mfw_v4lsink 您应该在显示屏上看到相机捕捉到的内容。如果需要对相机源数据进行编码，则需要将编码器放入管道中 gst-launch v4l2src num-buffers=100 !队列！vpuenc编解码器=0！matroskamux！文件接收器位置=输出.mkv 同步=false 我们正在使用某种编解码器（codec=0 表示 mpeg4），使用“gst-inspect vpuenc”检查选项。 i.MX6_全部 多媒体 回复：使用带有 GStreamer 的 USB 摄像头 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 请修复链接！我看不到 最良好的问候！ 回复：使用带有 GStreamer 的 USB 摄像头 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 感谢分享，但当编码“无法协商格式”时，这不适用于我的 2 个符合 UVC 1.1 标准的相机。 vpuenc 需要 TNVP、NV12 或 I420 中的原始 uyv，我可以强制原始输出，但我的相机不支持这些（对文件进行测试给出了 YUY2）。可以使用软件中的颜色转换来完成这项工作（至少在 vga 30 fps 中）： gst启动v4l2src num缓冲区=100！视频/x-raw-yuv！队列 ！ffmpeg色彩空间！队列 ！vpuenc编解码器=6！avimux！文件接收器位置=outputh264.avi 同步=false 在 iMX53 上，有 mfw_ipucsc，但我在 12.09 BSP 上发现的只有 ipucsc.imx，它不起作用，可能只有 DP 路径中的 CSC，这应该在图像转换器中是可能的，但我没有找到任何插件。有人有更好的管道吗？