HMAC検証ジョブのリクエスト時にHSEが「HSE_SRV_RSP_INVALID_PARAM」を返す NXPチームの皆様、こんにちは。 HMACのVerifyジョブを使うユースケースがあります。ジョブ暗号ドライバーをトリガーした後、DETを投げると、HSEからの返答は「HSE_SRV_RSP_INVALID_PARAM」でした。 現在の設定のどこが間違っているのか理解できません。添付されたconfig zipファイルを確認していただけますか? 問題解決のためのサポートが必要です。 ありがとうございます アディティヤ Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @lukaszadrapa さん。 詳細： デバイス: S32K311 HSE FW: HSE_FW_S32K311_0_2_55_0 RTD: SW32K3_S32M27x_RTD_R21-11_6.0.0_QLP01 ありがとうございます アディティヤ Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @WagdeoA さん。 どのデバイス、どのRTD、どのHSEファームウェアバージョンを使っているか確認していただけますか? よろしくお願いいたします。 ルーカス Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、 @WagdeoA さん。 設定に問題はありません。 私の環境では問題なく動作しています。しかし、タグの長さ(secondaryInputLength)が一つの問題かもしれません。 これは関数Crypto_Ipw_HmacVerifyで確認できます: リダイレクトが無効になっている場合は、タグの長さをバイト単位ではなくビット単位で指定する必要があります。これこそが問題なのではないですか？ よろしくお願いいたします。 ルーカス Re: HSE return "HSE_SRV_RSP_INVALID_PARAM" when request for HMAC verify job こんにちは、ルーカスさん。 返信が遅くなり申し訳ありません。 はい、タグの長さはビット単位で指定します。私の環境でも問題なく動作します。 ありがとう！ よろしくお願いします、 アディティヤ

imx93 lpddr4x の JSL4BAG16 設定が不安定です こんにちは、専門家の皆様： JSL4BAG16 の lpddr4x 設定に関して問題があります。設定後、「機能」テストはパスしますが、「最適化->CA 最適化の Vref」で失敗することがあります。常に失敗するわけではなく、時々失敗します。 「vTSA -> CA eye」のテストを実行すると、合格と表示されますが、同時に「エラーログ」も表示されます。 「Vref DQ config」と「Vref CA config」の調整方法について質問があります。JSL4BAG16のVref値は「EVKで使用されているミクロン値」と異なりますが、範囲0または範囲1を設定する必要がありますか？ 私の知る限り、Vref DQは「アイダイアグラム」テストの結果に基づいて設定されますが、「読み取りダイアグラム」と「書き込みダイアグラム」のどちらを使用すればよいのでしょうか？ JSL4BAGのデータシートと、「CA eye」テストログおよびmexファイルを添付しました。     よろしくお願いします。 Re: imx93 lpddr4x config for JSL4BAG16 unstable こんにちは、 LPDDR4Xは、 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-93-Memory-Compatibility-Guide/ta-p/1725656の一部です。 Vref DQ チューニングには、JSL4BAG16 のレンジ 1 (デフォルト) を使用し、読み取りではなく書き込みアイ ダイアグラムを使用してください。   Micron/EVKの設定を再利用しないでください。必ずJSL4BAG16に合わせてVrefを再調整してください。 Re: imx93 lpddr4x config for JSL4BAG16 unstable こんにちは、オズワラグさん。 ご返信ありがとうございます。私は「i.MX config tool」でテストに合格し、「最適化」テスト結果でDQとCAの「Vref」を使用しました。 しかし、まだ2つの問題があります。 1.あるボードでは「CA Charts」が表示されず、「CA Eye」テストには誤差がありますが、合格と表示されます 2.lpddr4x_timing.cを更新した後すべての合格ボードで「i.MX config tool」によって生成されたものをシステムで「memtest」を実行すると、「Stuck Address」で失敗します。常にではありませんが、時々発生します。 よろしくお願いします。 Re: imx93 lpddr4x config for JSL4BAG16 unstable 私のFRDM-IMX93ボードにも同じチップが搭載されていますが、市販のイメージファイルでは正常に起動しません。どうすれば解決できますか？

RT1170 NVCC_XXX電源シーケンスと未使用のIOバンク こんにちは、 1 - 未使用の IO バンク NVCC_XXX の電源を、DCDC_IN と Pswitch がオン (コアもオン) の状態でオフにしても安全かどうかを尋ねています。未使用の IO バンク ピンは外部から駆動されていないものとします。 2 - また、他のIOバンクをオフにした状態で、IO状態を維持するためにIOバンクを1つだけオンにしておくことは問題ないでしょうか？ 前もって感謝します Re: RT1170 NVCC_XXX power sequence and unsued IO banks こんにちは、@Marwan。 未使用の電源グループの電源を切断しようと考えていると理解しています。私の理解は正しいでしょうか？ 最適な方法は、対応するNVCC_xxx電源を常時供給し、使用されていないGPIOをフローティング状態にしておくことです。しかし、RT1170は柔軟なPower Architectureを備えており、特定のドメインをダウンして全体の消費電力を削減できます。 RT1170の電源アーキテクチャと低消費電力アーキテクチャ設計について詳しく説明されているAN13148を参照することをおすすめします。AN13104も有用な参考資料であり、電力ドメインとLP状態に関する有用な情報を提供しています。 さらに、カスタムボードを開発する場合は、 MIMXRT1160/1170 のハードウェア開発ガイドを参照することを強くお勧めします。この文書は、ファーストパス成功を確保し、ボードのブランクアップ問題を避けるためのボードレイアウト推奨事項やデザインチェックリストに関する情報を提供します。 BR ハビブ Re: RT1170 NVCC_XXX power sequence and unsued IO banks ご返信と参考資料をありがとうございます。 その通りです。使用しないIOバンクはオフにしておきたいのですが、推奨されないとは明確に記載されていませんが、参照した文書の行間から私が理解した内容はそういうことです。 2つ目の質問について： DCDC_IN と DCDC_PSWITCHが オフ（接地）になっている間（SNVSとIOバンクを除くすべてのドメインがオフになっている間）、IOバンクを 常にオン （IOの状態を維持し、外部から駆動されないようにするため）にしておくのはどうでしょうか？ MCUはホストではないので、この質問をするのは、MCUがSNVSモードの間、IOが外部から駆動されるのを防ぐためです。 敬具 マルワン Re: RT1170 NVCC_XXX power sequence and unsued IO banks こんにちは、 @Marwan さん。 ご説明ありがとうございます。 ご質問をよりよく理解するために、「IOバンクを常にオンにする」という言葉で、具体的に何を指しているのか教えていただけますか?各I/Oバンクに関連付けられたNVCC_xxx電源レールに継続的に電力を供給することを指しているのでしょうか？ 最適な方法は、対応するNVCC_xxx電源を常時供給し、使用されていないGPIOをフローティング状態にしておくことです。Setpoint機能を使うことを強くおすすめします。パワーモードスイッチがより簡単で安全になります。 DCDCを無効にしつつ、SNVS電源のみをアクティブにする可能性について。もしあなたのアプリケーションがM7を使う必要があり、外部PMICを使わない場合は、DCDCを無効にすることはできません。M7はWAKEUPMIXドメインに属しており、このドメインはVDD_SOC_INによって電源供給され、 AN13104の第2章「RT1170電源ドメイン」で述べられているようにDCDCによって直接供給されているからです。 消費電力を最小限に抑えることが目的であれば、SNVSドメインのみに電力を供給したまま、デバイスを低電力状態に移行させるためにSetpointsを使用することを検討してください。詳細については、表4.1.5を参照してください。データシートの「標準的な電源モード供給電流」を参照して、さまざまな設定値構成を確認してください。 さらに、 AN13104には、ウェイクアップソースの設定方法を示す実践的な例が含まれています。実装の際の参考として、第4.9章「ウェイクアップソースの設定」が役立つかもしれません。 最後に、IO状態を維持するためにはSSARCが有用かもしれません。デフォルトでは、ペリフェラルが属する電力ミックスが電源が切れている場合、ペリフェラルの構成は失われ、再初期化されるまで直接使用できません。しかしSSARCでは、電源オフ前に機能モジュールのレジスタをメモリに保存し、モジュールの電源を入れた後にメモリからレジスタを復元できます。これはAN13104の第4.14章「ウェイクアップ後の周辺機器の状態」にも記載されています。「ssarc_software_trigger_cm7」と呼ばれるペリフェラル機能を示すSDKの例があれば参考にできます。 BR ハビブ

S32N55: 高速ウェイクアップ ブート用の BLOB イメージを構築する方法。 こんにちは、チームの皆さん ご存知のとおり、S32N55 は Fast Wake-up Boot をサポートしています。 Full Wake-up Boot と同じ形式を使用して BLOB イメージをビルディングしようとしましたが、ブート プロセスが失敗しました。 Fast Wake-up Boot 用の BLOB イメージを正しく構築する方法を教えてください。 ご回答をお待ちしています。 よろしくお願いいたします。 唐生。 FSS_FW 優先度: 中 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん チームがこのCASEを引き受け、できるだけ早く回答を提供します。 よろしくお願いします、 ラドゥ Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @RaduBragaさん このチケットがクローズされていることに気づきました。進捗状況について何か最新情報はありますか？   よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 私はこのCASEを引き継ぎ、できるだけ早く返答をいたします。   よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 直接お客様を支援される場合は、以下の書類をご提供ください: BSSM契約：あり／なし 顧客会社*: プロジェクト名*: カスタマーコンタクトポイント*(氏名およびメールアドレス): ソフトウェアおよびハードウェア情報: SWパッケージ情報*: ハードウェア*(ボード/チップセット/プラットフォーム) ソフトウェアバージョン*: *必須 このケースの開発チームとはまだ協力しています よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 このケースは特定の顧客やプロジェクトに縛られていません。しかし、FUTURE的に同様の質問に直面する可能性があると考えており、このリクエストを出したのです。   よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 詳しい情報をありがとうございます。私はこの事件に取り組んでおり、できるだけ早く答えを提供いたします! よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん ブロブ画像を作ろうとした際に実際に踏んだ手順を教えていただけると助かります。そうすれば問題点を特定しやすくなると思います。   よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 以下に、テストの詳細な手順を示します。   1. AOSRAMメモリ領域内に小さなFSSイメージを構築しました（IVTヘッダーは予約済み）。このイメージにはmain.cのwhileループのみが含まれています。 2. FSSファームウェアイメージを作成する際、FRBしきい値レジスタを入力する必要がありますか？もしそうなら、どうやって埋めるか、あるいは特別なものを考える必要があります。 3. IVTツールでIVTブロブイメージを構築し、開始アドレスを0x24800000とする。 4. IVTブロブイメージをフラッシュメモリの0xD00000に書き込みます。 5. システムがスリープ状態に入る前に、IVTブロブイメージをAOSRAMにコピーし、FSS_WKUP0のWKPUモードを高速ウェイクアップモードとして構成します。 5. FSS_WAKUP0 を介してシステムイメージを起動します。 FSSは while(1) ループに到達できませんでした。ウェイクアップの際に高速ウェイクアップではなく、リセットイベントがトリガーされたようです。   サポートありがとうございます!   よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん FRBはTCMメモリ（ITCM + DTCM）用です。 理論的には2つのケースがあります 1: 高速起動ブート イメージはAON SRAMメモリから起動するため、高速起動にはFRBは必要ありません。 2: フルウェイクアップブート ITCMに起動したいかどうか教えてもらえますか?もしはい、FRBの閾値0はFSSイメージヘッダーで提供されるべきです。アドレスは12ビットマスクされ、FRBの場合は8kbの倍数として計算されます。 少しでもお役に立てれば幸いです。また、IVTの塊も教えてもらえますか? よろしくお願いいたします。 ポール

UM11490 and Bluetooth Classic Dear NXP support, one of our customer is running the following commands from pag 149 of UM11490, but cannot see any waveform. Please kindly check and verify if any additional command / condition is missing. Thanks Best Regards Pier ------------------------------------ # RESET root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCI Command: ogf 0x03, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 03 0C 00 # ENABLE SCAN root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI Command: ogf 0x03, ocf 0x001a, plen 1 03 > HCI Event: 0x0e plen 4 01 1A 0C 00 # ENABLE EVENT FILTER root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI Command: ogf 0x03, ocf 0x0005, plen 3 02 00 02 > HCI Event: 0x0e plen 4 01 05 0C 00 # ENTER IN TEST MODE root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCI Command: ogf 0x06, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 03 18 00 # START THE TX TRANSMISSION root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0x0e plen 4 01 19 FC 00 # STOP THE TX TRANSMISSION root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xF F 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0xff plen 6 19 01 39 00 00 00 -------------------- STOPPING THE SCAN FOR BLE AND CLASSIC BEFORE THE TX TRANSMISSION ---------------- # RESET root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCI Command: ogf 0x03, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 03 0C 00 # ENABLE SCAN root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCI Command: ogf 0x03, ocf 0x001a, plen 1 03 > HCI Event: 0x0e plen 4 01 1A 0C 00 # ENABLE EVENT FILTER root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCI Command: ogf 0x03, ocf 0x0005, plen 3 02 00 02 > HCI Event: 0x0e plen 4 01 05 0C 00 # ENTER IN TEST MODE root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCI Command: ogf 0x06, ocf 0x0003, plen 0 > HCI Event: 0x0e plen 4 01 03 18 00 # DISABLE THE BLE SCAN root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x0 < HCI Command: ogf 0x03, ocf 0x001a, plen 1 00 > HCI Event: 0x0e plen 4 01 1A 0C 00 # DISABLE THE CLASSIC SCAN root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x08 0x000C 0x00 0x00 < HCI Command: ogf 0x08, ocf 0x000c, plen 2 00 00 > HCI Event: 0x0e plen 4 01 0C 20 00 # START THE TX TRANSMISSION root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 01 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0x0e plen 4 01 19 FC 00 # STOP THE TX TRANSMISSION root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0xff plen 6 19 01 63 07 00 00 ** When disabling the scan before entering in the test mode, the stop for TX transmission give us: root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI Command: ogf 0x3f, ocf 0x0019, plen 18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCI Event: 0xff plen 6 19 01 ED 04 00 00 For Wifi 5 GHz -------------------------------------------------------------------------------- Paramters: Continuous transmit, BW = 40 MHz, 802.11ac, No DFS, CH = 40, MCS0 (13.5), Power = 14 dBm root@myboard:/home/BTtest# cat /proc/mwlan/adapter0/config hardware_status=0 netlink_num=31 drv_mode=7 hssetpara=7,0xff,200,400 sdcmd52rw=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 rx_antenna=1 band=1 bw=1 channel=44 radio_mode[0]=3 radio_mode[1]= total rx pkt count=0 rx multicast/broadcast pkt count=0 rx fcs error pkt count=0 tx_power=14 2 0 tx_continuous=0 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 4294967295 0 0 0 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff he_tb_tx=0 trigger_frame=0 otp_mac_add_rd_wr= 00:00:00:00:00:00 Re: UM11490 and Bluetooth Classic Hi @Christine_Li, sorry for missing the context: kernel version: lf-6.6.52-2.2.2 merged with 6.6.y community kernel FW version: IW612-18.99.3.p25.7, sepaated BT/WiFi FW, no combo product: IW612 UM11490 version: Rev. 1.8 — 2 June 2025 The following details will come ASAP dmesg logs or console logs when you load FW screenshot of the spectrum analyzer settings In the meanwhile, please let us know if you may need anything else. Thanks Best Regards Pier Re: UM11490 and Bluetooth Classic Hi, @pierluigi_p  Which Wi-Fi/Bluetooth product are you using? And what is your Linux kernel version? WiFi/Bluetooth driver and FW version? From the command logs, all HCI commands are completed successfully and the TX start command is accepted by the controller. In addition, the vendor-specific event returned by the TX stop command contains non-zero packet counters, which indicates that the controller believes packets have been transmitted during the test period. Therefore, the issue does not appear to be caused by a missing HCI command in the test sequence. I would recommend checking: The spectrum analyzer center frequency and span settings. The Bluetooth channel configured by the TX test command. The RF antenna configuration on the board. Whether the Bluetooth firmware are loaded correctly. Could you also share: The chip being used (IW416/IW612/etc.)? The exact UM11490 version? The dmesg logs or console logs when you load FW? Are you loading a combo FW or BT only FW? A screenshot of the spectrum analyzer settings? Best regards, Christine. Re: UM11490 and Bluetooth Classic Just adding, it was attempted with different settings for HackRF (gain and graphic adjustments), and we can see the 2.4 GHz (wifi) waveforms. Furthermore, we tested using different firmwares, for different versions in the imx-firmware repository, which includes one firmware for RF-test (sduart_nw61x_rftm_v1.bin.se in https://github.com/nxp-imx/imx-firmware/blob/lf-6.1.1_1.0.0/nxp/FwImage_IW612_SD/IW612_SD_RFTest/sduart_nw61x_rftm_v1.bin.se) without success. Re: UM11490 and Bluetooth Classic Hello Pier and Christine I'm Helbert, the developer who started the thread in the Veriscite forum. Here are some attachments about the testing: Dmesg log (without the power configuration):  Dmesg log (with the power configuration):  Screenshot with the spectrum analyzer and the config file for 5 GHz (own implementation and NXP implementation) after Note: it was found that using -1 for power, we use the default value, however different values was experimented too. NXP script: Screenshot with the classic Bluetooth test: As you can see, there is no waveform generated Screenshot with the BLE test running: Screenshot after the BLE testing (waveform interrupted):   We can see in the graphic below that the waveform was interrupted when finishing the test Modinfo log: Tested HCI cmds: 

S32K358マルチコアデータ共有 こんにちは 、 私はs32k358マルチコアで共有メモリを使用しようとしています。 私はユーザー定義の例に従っています。 buzzer_state_shared_data_U32で値を割り当てようとすると(現在はコア0のみがこのメモリにアクセスしています)、コア0がハングし、SWTがコントローラーをリセットします。 しかし、デバッグフラッシュにコードを書き込むと、正常に動作します。電源リセット後、コア0がハングアップしています。 フラッシュ中は正常に動作するのに、電源のオンオフでは動作しないのはなぜですか？ Re: S32K358 multi core data sharing こんにちは、 @Julián_AragónM さん、 迅速なご対応ありがとうございます。 起動ファイルを確認したところ、SRAMの初期化が実行されている。 起動ファイルとリンカーファイルを添付しました。この問題を解決するために、ぜひ私をサポートしてください Re: S32K358 multi core data sharing こんにちは、 @nirmal_masilamani さん、 しかし、デバッグフラッシュにコードを書き込むと、正常に動作します。電源リセット後、コア0がハングアップしています。 これはおそらくECC RAMのエラーが原因です。通常、デバッガは揮発性メモリ上でECCを初期化しますが、電源オン・オフ時にRAMを初期化せず、メモリへのアクセス時にハードフォールトが発生します。 これは通常、メイン関数の前に実行される起動コード内で行われます。 このセクションはキャッシュ不可に設定する必要があります。 2つ目の問題についてですが、タイマーISRやOSタスクからアクセスしようとすると、コア0がハードフォールに切り替わります。 ハードフォルトを遡って追跡してみることもできます。HardFault_Handler()でコアを停止し、コアレジスタでSP値を見つけます:How To Debug A Fault Exception On ARM Cortex-M(V7M) MCU(S32K3XX)。 よろしくお願いします、 ジュリアン Re: S32K358 multi core data sharing こんにちは、 main()で共有メモリにアクセスすると、電源オフ・オンでも問題なく動作しますが、タイマーISRやOSタスクからアクセスしようとすると、コア0がハードフォールに切り替わります。 どうか私をサポートしてください。 Re: S32K358 multi core data sharing こんにちは、 @Julián_AragónM さん、 この質問についてサポートしてください。私が何か見落としているのでしょうか？ Re: S32K358 multi core data sharing こんにちは、 @nirmal_masilamani さん、 PORリセット後にデバッガなしでmain()の共有メモリにアクセスできますか?問題はRAMの初期化だったのでしょうか？ しかし、タイマー、ISR、OSタスクからアクセスしようとすると、コア0がハードフォールトに切り替わります。 前回の返信でお伝えしたように、故障の種類を特定できましたか？ 変数がキャッシュされない領域に配置されているか、またはキャッシュが無効になっていることを確認しましたか？ 提案として： core1Status を揮発性のままにしておき、読み取り側 (Core0) と書き込み側 (Core1) の両方で__DMB()/__ DSB() バリアを使用します。 問題がMPU設定が原因かもしれません。もし定義MPU_ENABLEなら、ISRやOSタスクが実行される前にMPU設定を呼び出してください。 以下のリンクを参照してください:Arm Cortex-M7 デバイス汎用ユーザーガイド r1p2 & AN14715: S32K3XX ハードウェアリソースのアイソレータと保護。 よろしくお願いします、 ジュリアン Re: S32K358 multi core data sharing こんにちは、 @Julián_AragónM さん、 ご回答ありがとうございます。 残念ながら、これ以上続けることができませんでした。いただいたご指摘を確認させていただきます。

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

FS26 Reset issue Hi Team, We are facing a reset issue in the SBC section. During initial testing, I assembled only the NXP Semiconductors MFS2633HMDB2AD SBC section and checked the reset output. The reset line was HIGH, and the IC was working properly. After assembling the MCU and other related components, the PMIC reset line is always LOW, and all associated reset signals are being pulled LOW. When I connect the JTAG debugger, the reset line becomes HIGH and the system enters debug mode successfully. Additional observations: Removed  MCU reset line using a 0Ω resistor. MCU reset line is HIGH. PMIC reset line remains LOW. FS26 is working correctly in debug mode. Without JTAG connection, the PMIC reset output remains LOW. It appears that the issue occurs only after MCU integration. The SBC section works correctly when tested independently, but after MCU connection, the PMIC reset sequence is not releasing. Thanks. Re: FS26 Reset issue Hi Guoweisun, The FS26 is operating in Debug mode, and all the power outputs (LDOs and VCORE) are present and within the expected range. However, the RESET line is still not going HIGH. Our application includes an external watchdog, so we removed it from the circuit and tested again. Even after removing the external watchdog, the RESET line remains LOW. Could you please let us know what other conditions could prevent the RESET line from being released or what additional checks we should perform? Thank you. Re: FS26 Reset issue The FCCU1 and FCCU2 pins are connected with the recommended pull-up and pull-down resistors. Should we leave these connections as they are, or do you recommend isolating the FCCU pins from the MCU as well for debugging? Re: FS26 Reset issue In the INIT phase setting as above circled. Re: FS26 Reset issue We ḥave checked the pins FCC 1 & 2 pin  are low still the reset line is not released high Re: FS26 Reset issue Since in debug mode still RSTB pull low which is not related with WD. Please try to disable FCCU function in INIT phase to test it again. Re: FS26 Reset issue Hi Please Confirm whether there is some error for WD refresh and the power rails UV/OV. Re: FS26 Reset issue According my last reply to disable this FCCU function in the INIT phase of SBC to test again.

MCXN547:SWD DP IDは読み取れるが、AP0/AP2アクセスはWIRE ACKフォルトを返す こんにちは、NXPサポートの皆さん、 カスタムボード上のMCXN547VKLTと外部のMCU-Linkプローブを使用しています。 デバッグセッションを開始する際にSWD接続が失敗する： Ee(42). Could not connect to core. Et:31: No connection to chip's debug port. Remote connection closed. SWD-DPは正しく検出できます: DPID = 0x6BA02477 しかし、CPU0 AHB-AP(AP0)へのアクセスは以下の場合に失敗します: WIRE ACK FAULT デバッグ用メールボックスのリクエストも失敗します。LinkServer のレポート: DM-AP status: 60F93638 DM-AP: AHB_OR_ERR DM-AP: DBG_OR_ERR 確認した内容： SWD周波数は1MHzから10kHzまでテスト済み。 SWDIOとSWCLKの波形はオシロスコープ上で良好に見える。 VDD_CORE = 1.2 V VDD_SYS = 1.8 V VDD_DCDCおよびI/O電源 = 3.3V RESET_Bは正しく動作します MCU-Linkファームウェア:CMSIS-DAP V3.172 LinkServer バージョン: 26.5.59 同じMCU-LinkはMCXN947開発ボードで動作します MCXN547は新しいチップに交換されたが、問題は解決していない。 USB ISPはVID/PID 1FC9:014Fで正しく動作します。blhostを使えば、以下ができます: 内部フラッシュを消す 内部フラッシュのプログラムと読み取り アプリケーションを正常に実行してください アプリケーションのUSBコンポジットデバイスを列挙します ROMの報告によると、 Security State = UNSECURE USB ISP経由でPFRも読み取りました。 CMPAは完全に消去されました（0xFF） CFPAはROMで生成されたCMACを除いて消去されます。 お客様向けのSOCUやデバッグ認証の設定は存在しません 何かアドバイスをいただけますか: AP0とAP2が利用可能になるには、どのような条件が必要ですか？ DM-APステータス0x60F93638は、既知の電源、リセット、またはハードウェア構成の問題に関連していますか？ SWDやDebug Mailboxへのアクセスに関する既知のMCXN547エラタはありますか? この症状を確認するには、どの電源信号とリセット信号をチェックすればよいでしょうか？ MCX N Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT こんにちは、ルイスさん。 SPSDKデバッグメールボックスツールを使用して、SWDデバッグ接続を確立することができました。 私たちが用いた手順は以下のとおりです。 1. デバッグメールボックスを通じてMCUをリセットする: NXPDEBUGMBOX -i MCU-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=真 \ --オペレーションタイムアウト 5000 \ ツールリセット -f mcxn547 2. デバッグメールボックスからデバッグセッションを開始します。 NXPDEBUGMBOX -i MCU-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=真 \ --オペレーションタイムアウト 5000 \ cmd -f mcxn547 start-debug-session 3. デバッグセッションが開かれた後、SWD経由でLinkServerを使ってCortex-M33コアに接続します。 認証キー、パスワード、デバッグ認証情報、一括消去コマンドは一切使用しませんでした。「start-debug-session」コマンドは、常時アクセス可能なAP2デバッグメールボックスを介して、一時的にAP0を有効にするようです。 デバッグセッションを開いた後、NXP LS_preconnect_MCXN5XX.scpスクリプトからGDETレジスタシーケンスも使用しました。このシーケンスは、デバッグ中にaGDETおよびdGDETのリセットルーティングを無効にし、SPCグリッチ検出を無効にします。 電源装置に関して： - VDD_VBATはVDDに直接接続されており、どちらも3.3Vです。 - VDD_P4はVDDに直接接続されており、どちらも3.3Vです。 - VDD_ANAはフェライトビーズを介してVDDに接続されています。 - VDDは3.3Vです。 しかし、今度は別のデバッグ問題が発生しました。 SWDデバッグリセットを行わずにボードを通常通り電源投入した場合、ファームウェアは正しく動作します。しかし、上記のデバッグメールボックスリセット手順を使用してデバッグセッションに入ると、ファームウェアが正しく起動しません。 以下のSDK関数をシングルステップで実行するとデバッグ接続が失われます。 static inline void SPC_SetActiveModeDCDCRegulatorVoltageLevel( SPC_タイプ *ベース、 spc_dcdc_voltage_level_t voltageLevel) ヤージュ base->ACTIVE_CFG = (base->ACTIVE_CFG & (~SPC_ACTIVE_CFG_DCDC_VDD_LVL_MASK)) | SPC_ACTIVE_CFG_DCDC_VDD_LVL(voltageLevel); } より具体的に言うと、アクティブモードのDCDC電圧レベルを変更するためにACTIVE_CFGが書き込まれると、接続が失われます。 したがって、以下の2つの場合で挙動が異なります。 1. 電源投入時の冷間状態： ファームウェアは正常に起動し、正常に動作します。 2. デバッグ:メールボックスリセット、続いて開始・デバッグセッションおよびSWD接続: ファームウェアはSPC DCDC構成に到達しますが、ACTIVE_CFGが書き込まれるとデバッガはターゲットを失い、アプリケーションは通常起動できません。 デバッグメールボックスのリセットが、完全な電源オンリセットと異なる状態にしてしまいますか? デバッグメールボックスのデバッグセッションを開始した後、SPC ACTIVE_CFGを変更する前に、必要な手順はありますか？例えば： - SPC_SC[BUSY]がクリアされるのを待っています。 - SPCまたはGDETステータスフラグをクリアする。 - グリッチ検出のロック解除または無効化。 - 特定のリセットタイプを使用する。 - デバッグセッション開始後のソフトリセットを回避する。 または、LS_preconnect_MCXN5XX.scp シーケンス全体を適用する？ デバッグ中にDCDC電圧レベルを書き込むと、GDETイベント、DCDC保護イベント、ブラウンアウトリセット、または別のシステムリセットがトリガーされる可能性はありますか? ACTIVE_CFG書き込みの直前に取得すべきレジスタについてもご教示ください。SPC_SC、SPC_CNTRL、SPC_ACTIVE_CFG、SPC_GLITCH_DETECT_SC、CMC_SRS、CMC_SSRS、そしてデバッグメールボックスCSWなどのレジスタの値を提供できます。 よろしくお願いいたします。 Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT これは難しい問題だ！接続問題のデバッグは特にカスタムボードの場合非常にフラストレーションが溜まります。その「WIRE ACK FAULT」は、間違いなく通信障害を示しています。異なるSWDクロック速度を試したり、デバッグセッション中にMCUの電源を確認したりしてみましたか?時には限界的な電力供給がこのような断続的な故障を引き起こすことがあります。これは Snow Rider 3D で完璧なランを狙うような感覚を少し思い出させます。ほんの小さなミスで全てが狂ってしまうこともあります!早く真相が解明されることを願っています！

FS26 RESET 问题 大家好， 我们在SBC部分遇到了RESET问题。 在初步测试期间，我只组装了 NXP Semiconductors MFS2633HMDB2AD SBC 部分，并检查了 RESET 输出。RESET 线为高电平，集成电路工作正常。 组装好 MCU 和其他相关组件后，PMIC RESET 线始终为低电平，所有相关的 RESET 信号都被拉低。 连接 JTAG 调试器后，复位线变为高电平，系统成功进入调试模式。 补充说明： 使用 0Ω 电阻移除 MCU RESET 线。 MCU RESET line is HIGH. PMIC RESET 线保持低电平。 FS26 在调试模式下运行正常。 如果没有 JTAG 连接，PMIC RESET 输出将保持低电平。 这个问题似乎只在MCU集成后才会出现。单独测试时，SBC 部分工作正常，但连接 MCU 后，PMIC RESET 序列无法释放。 谢谢。 Re: FS26 Reset issue 郭伟孙您好， FS26 处于调试模式，所有电源输出（LDO 和 VCORE）均存在且在预期范围内。然而，RESET 线仍然没有变为高电平。 我们的应用程序包含一个外部看门狗，所以我们将其从电路中移除并再次进行了测试。即使移除外部看门狗，RESET 线仍然保持低电平。 请问还有哪些情况可能导致 RESET 线无法释放？或者我们应该进行哪些额外的检查？ 谢谢！ Re: FS26 Reset issue 在 INIT 阶段设置如上圈出的部分。 Re: FS26 Reset issue FCCU1 和 FCCU2 引脚分别连接推荐的上拉电阻和下拉电阻。我们应该保持这些连接不变，还是建议为了调试也把 FCCU 引脚与 MCU 隔离？ Re: FS26 Reset issue 因为在调试模式下 RSTB 仍然拉低，这与 WD 无关。 请尝试在初始化阶段禁用 FCCU 功能，然后再进行测试。 Re: FS26 Reset issue HI 请确认 WD 刷新和电源轨 UV/OV 是否存在错误。 Re: FS26 Reset issue 我们已检查过 FCC 1 和 2 引脚，它们均为低电平，但 RESET 线仍未释放。 Re: FS26 Reset issue 根据我上次的回复，需要在 SBC 的 INIT 阶段禁用此 FCCU 功能以再次进行测试。

i.MX95 Neutron NPU用にYOLOv8/YOLO11 TFLiteモデルをコンパイルできません こんにちは、NXPサポートチームの皆さん、 私たちはNeutron SDK v3.1.3を用いてFRDM i.MX95プラットフォーム上の物体検出を評価していますまた、NPU互換モデルを生成できません。Neutronコンバータはモデルを正常にロードしますが、 Neutron NPUに割り当てられたオペレーターは0個と報告します。 環境 対象ボード：FRDM i.MX95 Neutron SDK: 3.1.3 Ultralytics: YOLO11とYOLOv8の両方でテスト済み eIQツールキット：ONNXからTFLiteへの変換に使用 モデル:カスタムの単一クラスペグ検出器 トレーニング司令部 $ yolo detect train \ model=yolov11n.pt \ data=/visual_inspect_yolo/dataset/dataset.yaml \ imgsz=640 \ epochs=100 \ batch=16 \ project=モデル \ name=peg_detector_v8 エクスポートコマンド $ yolo export \ model=models/peg_detector_v84/weights/best.pt \ format=tflite \ int8=True \ data=/visual_inspect_yolo/dataset/dataset.yaml また、別のワークフローもテストしました。 PyTorchをエクスポート → ONNX NXP eIQツールキットを使用してONNXをINT8 TFLiteに変換する Neutron SDKでコンパイルした場合、両方のワークフローは同じ結果を生み出しました。   Neutron コンパイル ~/Downloads/eiq-neutron-sdk-linux-3.1.3/bin/neutron-converter--target imx95 --input best_int8.tflite --output my_model_int8_npu.tflite   コンバータ出力 コンバーターは次のように報告しています: インポート後のオペレーター数：341 最適化後の演算子数：367 変換された演算子: 0 オペレーター変換率：0 / 367 Number of Neutron graphs: 0 警告： 警告:グラフの演算子はニュートロンにマッピングされていません。 警告:変換されたモデルは入力モデルと同じで、演算子が中性子にマッピングされていないためです。 警告：グラフにはサポートされていない浮動小数点演算子が含まれています！これによりコンバージョン率が低くなることがあります。 その他の情報 以下のケースでも同様の挙動が観察されました。 YOLO11 YOLOv8 ダイレクトUltralytics TFLiteエクスポート ONNX → eIQ ツールキット → INT8 TFLite 生成されたすべてのTFLiteモデルは、Neutronコンパイラによって 0演算子をマッピング します。 質問 YOLOv8またはYOLO11のオブジェクト検出モデルは、i.MX95用のNeutronコンパイラで公式にサポートされているのでしょうか? i.MX95 NPUをターゲットにしたYOLOモデル向けの推奨エクスポートパイプラインはありますか? 現在のNeutron SDK(v3.1.3)には既知の制限はありますか?YOLO検出ヘッドに関してですか？ NXPはi.MX95 NPU向けに正常にコンパイルできるリファレンスYOLOv8/YOLO11モデルを提供していますか? 演算子マッピングを有効にするために、追加のコンパイラオプションや前処理手順が必要ですか？ i.MX95 Neutron NPUで動作することが知られているガイダンス、推奨ワークフロー、または参照モデルがあればぜひ教えていただけるとありがたいです。 よろしくお願いします。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU そして、あなたの人生を本当に大切にしてください。 もし本当に 、私がこのゲームを望むなら、私はこのゲームを L に x x 95 でイノシシd. 私たちは今、AR A2 を手に入れたので、そのキャパビリのつながりと 、あなたたちの兄弟の絆を活用します。 私たちはNXで実際にデモを作ったことがあるし、あなたはこのマットで最初に知られるだろうと、もっと早くアプリに報告されるだろう. あなたの LPに感謝します。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU eIQ Model zooのyolo8mモデルをimx95ボードで試し、LF 2026年Q2リリースイメージを使いました。カーネルバージョンはNeutron SDK 3.1.2を使用して6.18.2です。うまくいく。     まずは以下から試してみることもできます: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite root@imx95evk:/usr/bin/tensorflow-lite-2.19.0/examples# ./benchmark_model--graph=yolov8n-det-int8-Smart.imx95.tflite --external_delegate_path=/USR/LIB/libneutron_delegate.so 詳細はREADMEのeiq-model-zoo/tasks/ビジョン/object-detection/yolov8を参照してください。NXP/eiq-model-zoo さらに、モデルやコンプリエーションの詳細なログを添付することもできます。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU コンバーターログに基づくと、最初に解決すべき問題は、生成されたTFLiteモデルに依然としてFLOAT演算子が含まれていることです。 警告：グラフにはサポートされていない浮動小数点演算子が含まれています！ i.MX95 Neutronの場合、ニュートロンコンバータへの入力は、演算子と量子化フォーマットがNeutronコンパイラと互換性のあるTFLiteモデルでなければなりません。特に、i.MX95中性子流は量子化されたTFLiteと対称int8重みを期待しています。UltralyticsエクスポートやONNXからTFLiteへの変換後もモデルにFLOAT演算子/テンソルが残っている場合、コンバーターは報告された結果と整合するNeutron互換の部分グラフを作成できない可能性があります。 変換された演算子: 0 中性子グラフの数:0 YOLOv8はi.MX95上で一部のフローにおいて評価されていますが、任意のUltralyticsエクスポートにおいて、エンドツーエンドのYOLOv8/YOLO11オフロードが完全に実現されるとは限りません。エクスポートされたTFLiteグラフによっては、モデルの一部のみがNeutronGraphに変換され、サポートされていない演算子はCPU上に残ります。したがって、次の推奨ステップは生成されたTFLiteモデルを検査・プロファイリングし、以下のことを確認することです: グラフは完全に量子化されており、 FLOAT演算子はありません。 重みは対称な int8、 入出力テンソルタイプは互換性があり、該当する場合はNeutron変換器のuint8からint8への変換オプションで変換されます。 デコードやNMSなどのYOLO後処理は、SDKで正確な演算子がサポートされていることが確認されない限り、NPUグラフの外に保管されます。 また、Neutron-Converter版とボード上のNeutronランタイム/ファームウェア/デリゲートが同じ互換性のあるSDK/BSPリリースから来ていることも確認してください。 推奨される手順として、NXP/eIQ変換パスをお試しください。 PyTorch -> 静的入力形状のONNX -> 代表的な較正データを用いたNXP/eIQ量子化 ->量子化されたTFLite -> Neutron-converter --ターゲットIMX95 モデルにuint8の入力/出力テンソルがある場合は、以下もテストしてください: --入力値をuint8からint8に変換 --出力をuint8からint8に変換 FLOAT演算子を削除した後も変換結果にマッピングされた演算子が0と表示される場合は、以下の情報を共有してください。 - 詳細/プロファイリング出力を含む完全な中性子変換ログ - TFLiteオペレーターリスト、 - テンソルデータ型と量子化パラメータ、 - FRDM i.MX95ボード上のBSP/実行時Neutronデリゲート/ファームウェアバージョンの正確なバージョン、 - YOLO検出ヘッドにNMSやその他の後処理が含まれているかどうか。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 私のテストでは、 自分でトレーニングもエクスポートもしていません。eIQ Model Zooのプリ生成されたYOLOv8モデルを使い、i.MX95プラットフォームで動作することを確認しました。 私が実際に使用したコマンドはこれだけです。 ./benchmark_model \ --graph=yolov8n-det-int8-smart.imx95.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so 「 モデルでは: wget https://huggingface.co/EdgeFirst/yolov8-det/resolve/main/imx95/yolov8n-det-int8-smart.imx95.tflite カスタムモデルの場合、推奨されるNXPフローは以下の通りです: PyTorch ↓ ONNX（静的入力形状） ↓ eIQツールキット ONNX2Quant ↓ eIQツールキット ONNX2TFLite ↓ 量子化されたTFLite ↓ Neutron-converter --ターゲットIMX95 あなたのモデルが報告しているので: プレーンテキスト 変換された演算子: 0 Number of Neutron graphs: 0 警告：グラフにはサポートされていない浮動小数点演算子が含まれています！ あなたの生成されたTFLiteグラフは、eIQ Model Zooの参照モデルとは構造的に異なるのではないかと推測しています。まず最初におすすめしたいのは、以下の2つのモデルを比較することです: 入力/出力テンソル型（INT8 vs UINT8） FLOAT演算子の存在 グラフ内のデコード/NMSレイヤー Netron / TFLiteアナライザーによって報告されたオペレーターリスト Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 推奨されるエンドツーエンドのワークフロー モデルトレーニング(PC) お好みのフレームワークを使用してトレーニングしてください。 ウルトラリティクス YOLOv8 PyTorch テンソルフロー ONNXネイティブワークフロー 物体検出に関しては、NXPはすでにeIQモデルズーでYOLO参照レシピを提供しており、YOLOv8オブジェクト検出モデルも含まれています。[github.com] 、[github.com] 例： シェル YOLO検出トレーニング model=yolov8n.pt \ data=dataset.yaml \ imgsz=640 \ エポック数=100 ` ONNX形式でエクスポート NXPは一般的に、量子化および展開の前に、交換フォーマットとしてONNXを使用することを推奨しています。 YOLOエクスポート model=best.pt \ フォーマット=onnx Neutron イネーブルメントのプレゼンテーションは、以下に基づくフローを明示的に記述しています: プレーンテキスト PyTorch ↓ ONNX ↓ 量子化 ↓ TFLite ↓ Neutron コンバータ 訓練アーティファクトから直接展開を狙うのではなく、 eIQツールキットを使用した量子化 Neutronのワークフロードキュメントでは、eIQ Toolkitの量子化ユーティリティの使用を推奨しています: python -m onnx2quant \ model.onnx \ -o model_quant.onnx \ -c input:: 「 に続く： python -m onnx2tflite \ model_quant.onnx \ -o model_int8.tflite もっと行を表示 この流れはi.MX95 Neutron イネーブルメント材料に明示的に記録されています。 i.MX95 Neutron NPU用にコンパイル Neutron-converter \ --ターゲット imx95 \ --input model_int8.tflite \ --出力 model_neutron.tflite ニュートロンコンバーターは、NPUにオフロードできるNeutron特有のグラフパーティションを作成します。 コンバージョン率の検証 NPUのデプロイが成功すると、以下のようなレポートが表示されます。 変換されたオペレーターの数 > 0 Number of Neutron graphs > 0 次のような場合： 変換された演算子: 0 Number of Neutron graphs: 0 この場合、モデルはNPUによって加速されていません。 あなたの抱えている問題は、このカテゴリーに該当します。 FRDM-i.MX95に展開する TensorFlow LiteでNeutronデリゲートを使い実行します: ./benchmark_model \ --graph=model_neutron.tflite \ --external_delegate_path=/usr/lib/libneutron_delegate.so 「 または ./label_image \ --external_delegate_path=/usr/lib/libneutron_delegate.so i.MX Machine Learning User Guideでは、 Neutron Delegate がi.MX95 TensorFlow Liteモデルの加速機構として特定されています。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU yolov8m_full_integer_quant.tfliteをどのように変換してIMX95のNPUで動作させたのか教えてもらえますか? 手順に従って環境設定データ(HOST)を経て...私たちにとって大いに助けになるでしょう。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU こんにちは 私はUbuntu 24.04を使用していますが、eiq_toolkitは20.04.03でのみ利用可能です。 eiqToolkitとeIQ Toolkitを使った量子化の使い方 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU eIQ ToolkitはUbuntu 20.04で検証済みであるため、最も安全な方法は以下のとおりです。 Docker Ubuntu 24.04ホスト上でUbuntu 20.04コンテナを実行します。 docker run -it --name eiq \ ubuntu:20.04 /bin/bash 次に、コンテナ内に必要な依存関係とeIQ Toolkitをインストールします。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU eIQ Toolkit(onnx2quant)を使ってカスタムYOLOv8 ONNXモデルを変換する際に信頼度を維持できない 概要 こんにちは、NXPチームの皆さん、 私はfdm i.MX95上でeIQ Toolkitを使ってカスタムYOLOv8単一クラスオブジェクト検出モデルを展開しようとしています。 変換パイプライン全体は正常に実行されますが、onnx2quant の後、信頼度出力がすべてゼロになり、バウンディングボックス出力は有効なままです。 環境 - Ubuntu 24.04 - Python 3.10 - eIQ ONNX2TFLite 0.9.0 - ONNX ランタイム 1.21.1 - テンソルフロー 2.21 - Neutron-コンバータ 3.1.3 - ターゲット:FRDM i.MX95(tflite_runtime 2.19+Neutronデリゲート) 変換パイプライン 1. 列車 Yolo Detect Train Model=yolov8N.pt data=dataset.yaml imgsz=640 epochs=50 2. ONNXのエクスポート Yolo export model=best.pt format=onnx opset=13 3. ONNXの検証 入力:(1,3,640,640) 出力:(1,5,8400) ONNXランタイム推論: 信頼チャネル最大値 = 0.773 4. キャリブレーションデータセットの生成 形状:(1,3,640,640) dtype : float32 範囲:0.0 - 1.0 5. 量子化 onnx2quant best.onnx -c "images;キャリブレーション/画像」 -o best_quant.onnx また、以下の項目もテストしました。 onnx2quant best.onnx -u どちらも同じ結果を生み出す。 6. 量子化されたONNXの検証 出力:(1,5,8400) バウンディングボックスチャネルは有効のままです。 自信： 最小値 = 0 最大値 = 0 平均 = 0 デコードされた検出数 = 0 7. TFLite形式に変換する onnx2tflite best_quant.onnx -o best.tflite 8. Compile for Neutron Neutron-converter --ターゲット IMX95 --入力 best.tflite --出力 best_neutron.tflite コンパイルに成功しました。 オペレーター変換率：278 / 325 (85.5%) 調査実施 検証済み: • PyTorchモデルの動作 • ONNX輸出作品 • ONNXランタイム推論の動作 • キャリブレーションデータセットは正確です • 実数およびランダムキャリブレーションで同一の結果が得られます • TFLiteは量子化されたONNX出力を再現します • NeutronはTFLite出力を再現します この問題は以下以下に初めて現れます: ONNX ↓ onnx2quant ↓ 量子化されたONNX(信頼度がゼロになる) 追加の観察 NXPの参照モデル: 入力:(1,640,640,3) INT8 出力:(1,84,8400)INT8 私の改造モデル: 入力:(1,3,640,640) FLOAT32 出力:(1,5,8400) FLOAT32 カスタムYOLOv8モデルの信頼度を保つ推奨されるエクスポートや量子化のワークフローはありますか? これは、(1,5,8400)出力を持つモデルのonnx2quantの制限やバグでしょうか? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU AEチームと話し合っています。 Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU Ara240のエンドツーエンド評価は実施されましたか？データシートには、シグモイドやNMSなどの後処理操作を実行できる2つのベクターコアが記載されています。コンパイラはNMSの操作をベクターコアにマッピングできますか? Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU YOLOv8の出力テンソルに適用される完全なINT8量子化（ inference_output_type=tf.int8 ）の根本的な制限により、信頼度出力が失われます。 YOLOv8 は、境界ボックスの座標と信頼度スコアを (1, 5, 8400) の形状の単一の出力テンソルにパックします。bboxの値は広いダイナミックレンジ（約640ピクセル）を持ち、信頼度スコアは約0から1の範囲にあります。出力テンソル全体が単一の量子化スケールを共有する場合、そのスケールは大きなbbox値（約640）によって支配され、信頼区間全体（約1）を表すために1つの整数レベルのごく一部しか残されません。その結果、INT8量子化後、すべての信頼度値は実質的にゼロに丸められます。 推奨される解決策   onnx2quant を通す代わりに、Ultralyticsを使って訓練した  .pt  モデルからINT8 TFLiteを直接エクスポートし、それを  neutron-converter に入力します: # INT8 TFLite 直接エクスポート(キャリブレーションはトレーニングデータセットを使用) yolo export model=best.pt \ format=litert \ imgsz=640 \ quantize=8 \ data=dataset.yaml \ fraction=0.1 # ニュートロン 用 にコンパイル(変更なし) ニュートロンコンバーター --target imx95 --input best_int8.tflite --output best_neutron.tflite 入力および出力データの型は、np.int8であることを確認してください。 interp = tf.lite.Interpreter(model_path=TFLITE_INT8) interp.allocate_tensors()inp_d = interp.get_input_details()[0]out_ds = interp.get_output_details()inp_scale、inp_zp = inp_d[ "quantization" ] out_d = out_ds[0] out_scale、out_zp = out_d[ "quantization" ] print(f " 入力 dtype={inp_d['dtype']} shape={inp_d['shape'].tolist()}" f " quant=(scale={inp_scale:.6f}, zp={inp_zp})" ) print(f " 出力 dtype={out_d['dtype']} shape={out_d['shape'].tolist()}" f " quant=(scale={out_scale:.6f}, zp={out_zp})" )# 形状から入力フォーマットを決定します in_shape = inp_d[ "shape" ].tolist()# [1,3,640,640] または [1,640,640,3] in_shape[1] == 3 の場合: #NCHW src=img_nchw それ以外： #NHWC src=img_nhwcif inp_d[ "dtype" ] == np.int8: src_int8 = np.clip(np.round(src/ inp_scale + inp_zp), -128, 127).astype(np.int8) interp.set_tensor(inp_d[ "インデックス" ],src_int8) それ以外： interp.set_tensor(inp_d[ "インデックス" ],src.astype(np.float32))interp.invoke()raw_out = interp.get_tensor(out_d[ "index" ])# int8 または float32 の可能性があります if out_d[ "dtype" ] == np.int8: dq_out = (raw_out.astype(np.float32) - out_zp) * out_scale それ以外： dq_out = raw_out.astype(np.float32)dq_out= dq_out[0] # (5, 8400) 正規化 # 表示用にバウンディングボックスをピクセル座標に再スケーリング BBOX_SCALE = 640.0tfl_bbox = dq_out[:4] * BBOX_SCALE # (4, 8400) tfl_conf = dq_out[4] # (8400,) Re: Unable to compile YOLOv8/YOLO11 TFLite models for i.MX95 Neutron NPU 遅れてごめんなさい。変換ワークフローを再現しようとしています。 今のところ一つ質問ですが、なぜ変換されたモデルのデータ型がFLOAT32なのか?INT8形式への変換を試してみましたか？ニュートロンNPUはINT8型を入力データとして必要とします。他のモデルの変換でも似たエラーに遭遇しましたが、根本原因はデータ型にあります。

S32K358 + FreeRTOS: Random HardFault during PendSV_Handler Hi Team, I am facing a random HardFault issue on an S32K358 running FreeRTOS. The application runs normally for a long duration and then suddenly hangs. After the system stops executing, the Software Watchdog (SWT) is not serviced and eventually resets the controller. The failure is not immediate—it occurs after approximately 1 to 2 hours of continuous execution When halted after the failure, the call stack shows: PendSV_Handler() ↓ HardFault_Handler() Register values: LR = 0xA5A5A5A5 PC = 0x00407BD9 LR = 0xA5A5A5A5 looks like a memory initialization pattern rather than a valid return address. Other registers: R0 = 0x204011A8 R3 = 0x2040012C R12 = 0x20400010 Any suggestions or debugging recommendations would be greatly appreciated. Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler Hi @nirmal_masilamani, It looks like the task context saved during the FreeRTOS context switch has been corrupted. PendSV is used by FreeRTOS for context switching, therefore, if the HardFault occurs inside PendSV_Handler(), it often means the scheduler is attempting to restore an invalid task context. One possible root cause is a task stack overflow. I would recommend increasing the stack size of the tasks and enabling FreeRTOS stack overflow detection: configCHECK_FOR_STACK_OVERFLOW Implement: vApplicationStackOverflowHook(). Additionally, you can periodically monitor the remaining stack space of each task using uxTaskGetStackHighWaterMark(). This can help identify tasks that are running close to their stack limits before the fault occurs. Regards, Daniel Re: S32K358 + FreeRTOS: Random HardFault during PendSV_Handler Hello @danielmartynek , Thank you for response, I already tried increased stack size, enabled stack overflow hook. Added debug CAN msg in overflow hook, I am not receiving that message when fault occur. Also monitoring uxTaskGetStackHighWaterMark(), when fault occur Task 1 : 1977 × 4 ≈ 7908 bytes free Task 2: 1971 × 4 ≈ 7884 bytes free Task 3: 3988 × 4 ≈ 15952 bytes free

MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT Hello NXP Support, We are using an MCXN547VKLT on a custom board with an external MCU-Link probe. The SWD connection fails when starting a debug session: Ee(42). Could not connect to core. Et:31: No connection to chip's debug port. Remote connection closed. The SWD-DP can be detected correctly: DPID = 0x6BA02477 However, access to CPU0 AHB-AP (AP0) fails with: WIRE ACK FAULT The Debug Mailbox request also fails. LinkServer reports: DM-AP status: 60F93638 DM-AP: AHB_OR_ERR DM-AP: DBG_OR_ERR What we have checked: SWD frequency tested from 1 MHz down to 10 kHz SWDIO and SWCLK waveforms look good on an oscilloscope VDD_CORE = 1.2 V VDD_SYS = 1.8 V VDD_DCDC and I/O supplies = 3.3 V RESET_B works correctly MCU-Link firmware: CMSIS-DAP V3.172 LinkServer version: 26.5.59 The same MCU-Link works with an MCXN947 development board The MCXN547 was replaced with a new chip, but the problem remains USB ISP works correctly with VID/PID 1FC9:014F. Using blhost, we can: Erase internal Flash Program and read internal Flash Run the application successfully Enumerate the application USB composite device The ROM reports: Security State = UNSECURE We also read the PFR through USB ISP: CMPA is completely erased (0xFF) CFPA is erased except for the ROM-generated CMAC No customer SOCU or Debug Authentication configuration is present Could you please advise: What conditions are required before AP0 and AP2 become accessible? Is DM-AP status 0x60F93638 associated with a known power, reset, or hardware configuration issue? Are there any known MCXN547 errata related to SWD or Debug Mailbox access? Which power and reset signals should we check for this symptom? MCXN Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT Hello Luis, We have now been able to establish an SWD debug connection by using the SPSDK Debug Mailbox tool. The procedure we used is as follows: 1. Reset the MCU through the Debug Mailbox: nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=True \ --operation-timeout 5000 \ tool reset -f mcxn547 2. Start a debug session through the Debug Mailbox: nxpdebugmbox -i mcu-link -s NBTF0IZ0B3DCX \ -o enable_recovery_reset=True \ --operation-timeout 5000 \ cmd -f mcxn547 start-debug-session 3. After the debug session has been opened, we connect to the Cortex-M33 core with LinkServer over SWD. We did not use any authentication keys, passwords, debug credentials, or mass erase commands. It appears that the "start-debug-session" command temporarily enables AP0 through the always-accessible AP2 Debug Mailbox. We also used the GDET register sequence from the NXP LS_preconnect_MCXN5XX.scp script after opening the debug session. The sequence disables the aGDET and dGDET reset routing and disables SPC glitch detection during debugging. Regarding the power supplies: - VDD_VBAT is directly connected to VDD, and both are 3.3 V. - VDD_P4 is directly connected to VDD, and both are 3.3 V. - VDD_ANA is connected to VDD through a ferrite bead. - VDD is 3.3 V. However, we now have another debugging problem. When the board is powered on normally without an SWD debug reset, the firmware runs correctly. However, when we enter the debug session using the Debug Mailbox reset procedure described above, the firmware does not start correctly. The debug connection is lost when single-stepping through the following SDK function: static inline void SPC_SetActiveModeDCDCRegulatorVoltageLevel( SPC_Type *base, spc_dcdc_voltage_level_t voltageLevel) { base->ACTIVE_CFG = (base->ACTIVE_CFG & (~SPC_ACTIVE_CFG_DCDC_VDD_LVL_MASK)) | SPC_ACTIVE_CFG_DCDC_VDD_LVL(voltageLevel); } More specifically, the connection is lost when ACTIVE_CFG is written to change the active-mode DCDC voltage level. The behavior is therefore different between the following two cases: 1. Cold power-on: The firmware starts and runs normally. 2. Debug Mailbox reset followed by start-debug-session and SWD connection: The firmware reaches the SPC DCDC configuration, but the debugger loses the target when ACTIVE_CFG is written, and the application cannot start normally. Could the Debug Mailbox reset leave the SPC, DCDC, GDET, or reset status in a different state compared with a full power-on reset? Is there a required sequence before modifying SPC ACTIVE_CFG after starting a Debug Mailbox debug session? For example: - waiting for SPC_SC[BUSY] to clear; - clearing an SPC or GDET status flag; - unlocking or disabling glitch detection; - using a specific reset type; - avoiding a soft reset after start-debug-session; - or applying the complete LS_preconnect_MCXN5XX.scp sequence? Could writing the DCDC voltage level while debugging trigger a GDET event, DCDC protection event, brownout reset, or another system reset? Please also advise which registers we should capture immediately before the ACTIVE_CFG write. We can provide values for registers such as SPC_SC, SPC_CNTRL, SPC_ACTIVE_CFG, SPC_GLITCH_DETECT_SC, CMC_SRS, CMC_SSRS, and the Debug Mailbox CSW. Best Regards, Re: MCXN547: SWD DP ID is readable, but AP0/AP2 access returns WIRE ACK FAULT This is a tough one! Debugging connection issues can be really frustrating, especially with custom boards. That "WIRE ACK FAULT" definitely points to a communication breakdown. Have you had any luck trying different SWD clock speeds, or perhaps checking the power supply to the MCU during the debug session? Sometimes a marginal power delivery can cause these kinds of intermittent failures. It reminds me a bit of trying to get a perfect run in Snow Rider 3D – one small misstep can throw everything off! I hope you get to the bottom of it soon!

SW32K14-MCAL421-RTMC-1.0.1 ダウンロードへのアクセスを有効にするリクエスト こんにちは、NXPサポートチーム様 SW32K14-MCAL421-RTMC-1.0.1のダウンロード アクセスをリクエストします。 現在、NXP ソフトウェア ライセンス ページの [前へ] タブがグレー表示されており、このバージョンにアクセスできません。 私のアカウントのユーザー名はChefanqfです。 このバージョンは、 S32K14x MCAL 4.2に基づく既存のプロジェクトとの互換性を保つために必要です。 私のアカウントでこのソフトウェアの権限を有効にするのを手伝っていただけますか? サポートしていただき誠にありがとうございます！ よろしくお願いいたします。 Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download こんにちは@Chefanqf 、 NXP.com (検索 | NXP Semiconductors) で「S32K1 MCAL」を検索し、次のように flexera と入力してみてはいかがでしょうか。 この後、「オートモーティブ SW - AUTOSAR MCAL / QM」を選択すると、以前のソフトウェアが利用できるようになります。 「前へ」タブがまだグレー表示されている場合、直接リンク： SW32K14-MCAL421-RTMC-1.0.1 から入力してみてください。直接リンクを使用する場合は、nxp.com にログインしていることを確認してください。 よろしくお願いします、 ジュリアン Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download こんにちは、NXPサポートチーム様 SW32K14-MCAL421-RTMC-1.0.1 のダウンロードアクセスをお願いしたいです。 現在、NXPソフトウェアライセンスページの「前回」タブが グレーアウト 表示され このバージョンにアクセスできません。 私のアカウントのユーザー名はmianlongxuです。 このバージョンは、既存のプロジェクトとの互換性のために必要です。 S32K14x MCAL 4.2 。 私のアカウントでこのソフトウェアの権限を有効にするのを手伝っていただけますか? サポートしていただき誠にありがとうございます！ よろしくお願いいたします。 Re: Request to enable access for SW32K14-MCAL421-RTMC-1.0.1 download こんにちは、 @mianlongxu さん。 サポートチケットを入力してください:NXPサポート。 よろしくお願いします、 ジュリアン

S32DS 上的 LLCE FlexRay 配置 你好， 我在 S32DS 上使用 LLCE FlexRay 时遇到了配置问题。 我想将此参数设置为 TRUE，但在 IDE 中花费了很长时间后，仍然找不到更改它的正确位置。请问有人能提供一些线索吗？ 我的IDE版本是S32DS3.5.10。 提前谢谢您。 Re: LLCE FlexRay configuration on S32DS 你好， Yang_C 感谢您与我们联系。 你使用的是哪个版本的LLCE？您使用的是S32G2还是S32G3？ BR 乔伊 Re: LLCE FlexRay configuration on S32DS 嗨，乔伊， 我使用的是搭载 S32DS3.5.10 的 S32G399，LLCE 1.0.7，RTD 4.0.2。 BR， 杨 Re: LLCE FlexRay configuration on S32DS 你好， Yang_C 这似乎是软件本身的问题。我会协助您与内部软件开发人员确认！ BR 乔伊 Re: LLCE FlexRay configuration on S32DS 嗨，乔伊， 感谢您的帮助。 期待您的回复。 BR， 杨

[S32K3] [RTD 7.0.1] Three Issues in the BCTU Module I have found three problems with the BCTU module in the RTD code version S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206. The detailed issues are listed below:   Issue 1: In file Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c, line 1558, the current code uses bitwise OR assignment: BctuBasePtr->FIFOERR |= FifoWatermarkMask; It should be modified to direct assignment: BctuBasePtr->FIFOERR = FifoWatermarkMask;   Issue 2: In file Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c, lines 567 and 568, the existing code contains incorrect bit shift operations. The original code is shown below: ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << (Index * 2u))) != 0U) ? (BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << Index) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << (Index * 2u))) != 0U) ? (BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << Index) : 0U; These two lines should be revised to the correct shift logic as follows: ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_OVR_ERR << Index)) != 0U) ? (BCTU_FIFOERR_OVR_ERR_FIFO1_MASK << (Index * 2u)) : 0U; ClrMask |= ((u32Mask & (BCTU_IP_STATUS_FIFO1_UNDR_ERR << Index)) != 0U) ? (BCTU_FIFOERR_UNDR_ERR_FIFO1_MASK << (Index * 2u)) : 0U;   Issue 3: There is a type inconsistency alignment issue between the MCAL/SDK code generation tools and the static source code of the BCTU module. In the MCAL generated code (Adc_TS_T40D34M70I1R0/generate_PB/Adc_RegOperations.m, line 2397), the arrays defined in both header and C files uniformly adopt the uint32 type. In the SDK generated code, the type definition is inconsistent between header and C files: the array type in eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.h (line 249) switches between uint16 and uint32 depending on whether the BctuFifoDmaRawData option is enabled, while the corresponding array in eclipse/mcu_data/components/PlatformSDK_S32K3/Bctu_Ip/Bctu_Ip_PBcfg.c (line 317) is fixed as uint32 type. In the static code (Adc_TS_T40D34M70I1R0/src/Bctu_Ip.c, line 1629), the transmission length (2-byte or 4-byte) is determined dynamically based on the BctuFifoDmaRawData configuration. All the following abnormal problems occur when theBctuFifoDmaRawData option is unchecked: 1. For SDK projects: The mismatched array types between header and C files cause direct compilation failures. 2. For MCAL projects: Although compilation can succeed, the fixed uint32 array definition leads to half of the memory space being wasted. Besides, each uint32 data unit contains two ADC results, requiring manual splitting of high and low uint16 values during data parsing. The above three bugs exist in the official version S32K3_RTD_7_0_1_D2602_ASR_REL_4_9_REV_0000_20260206. We hope NXP software engineers can fix these BCTU module defects in the next RTD release. Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module Hi@chenwilsoft Your question has been escalated to the internal forum and is awaiting confirmation from the design team. Re: [S32K3] [RTD 7.0.1] Three Issues in the BCTU Module Hi@chenwilsoft Thank you for your feedback. The software team and I have confirmed these issues, they are indeed bugs. We have escalated these issues internally and will fix them in a future update.

关于 MRF300AN 27MHz 参考设计中 C16 电容额定值的问题 您好，NXP支持团队， 我目前正在审查 MRF300AN 27MHz 参考设计，对输出端的电容 C16 有一个疑问。 根据我手头的物料清单（例如，来自 Farnell 的数据手册），C16 被指定为 39,000 pF (39 nF) / 50V 的贴片电容（ATC 零件号 200B393KT50XT） 。鉴于 MRF300AN 的工作漏极电压为 50V，且输出级需处理高射频功率（高达 300W 以上），我担心在此位置使用 50V 额定值的电容可能不足以保证长期可靠运行。 我的问题是： 物料清单中 C16 的额定电压为 50V 是否正确，还是可能是笔误？ 在这个电路中，C16 的具体作用是什么？它是输出匹配网络的一部分、直流阻隔电容，还是旁路/去耦电容？ 如果它确实是射频输出路径中的直流阻隔或匹配电容，那么使用更高电压额定值（例如 100V 或更高）的电容来处理电压瞬变和驻波岂不是更合适？ 非常感谢您能就此事作出澄清。感谢您的时间和支持。 顺祝商祺！ Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 风雨绮你好 再会！ 300W 并不能直接决定电容上的电压应力。 电容的额定电压必须与该电容两端的实际射频电压进行比较，而不是与放大器的输出功率进行比较。 C16 不一定能看到完整的射频输出电压。 根据参考设计物料清单，C16 属于电源去耦/射频旁路网络，而不是直接跨接在 50 Ω 输出连接器上。 希望这些信息对您有所帮助，如果您还需要其他帮助，请告诉我。 祝你今天过得愉快，一切顺利。 Re: Question about C16 capacitor rating in MRF300AN 27MHz reference design 亲爱的 RafaR， 感谢您详尽且有帮助的回复。我非常感谢您抽出时间解释电容的电压应力问题。 我想承认您说得完全正确——C16 两端的电压没有射频输出电压那么高，因为电压应力取决于元器件两端的实际射频电压，而不是放大器的输出功率。我完全同意这一点。 不过，关于 C16，我想澄清一点。仔细检查我手头的 PCB 布局后，假设所有走线都布线在顶层，那么 C16 看起来确实是位于 RF 输出之前的直流阻隔电容器。我知道这可能与您文档中的物料清单名称有所不同，但根据我目前可以访问的布局文件，这是我观察到的情况。 目前我下载的资料仅包括 PCB 布局文件和一份简要概述文档——我无法访问完整的原理图、包含元器件功能的详细物料清单或完整的参考设计用户指南。 能否提供该参考设计的更详细文档，例如： 完整示意图 包含元器件功能描述的完整物料清单 参考设计用户手册或应用说明 如果您能提供任何其他资料，我将不胜感激。如果分享这些文件有任何限制，也请告知我，以便我可以通过正规渠道申请获取。 再次感谢您的指导，期待您的回复。 此致， 风雨绮

在 FRDM-K64F 上使用 MCUxpresso 25.6 时出现未定义的 SD 卡符号 我想在我的项目中使用 SD 卡来加载双向无线电系统的个人个性化数据。我收到 #include "tx_api.h"并且 #include "tx_event_flags.h" 未定义。 这是因为我没有在 SDK 中包含 Azure RTOS。 我尝试使用“管理 SDK 组件”将 Azure 安装到 SDK 中来解决这个问题，但显然 Azure RTOS 支持在 2.11 版本中被取消了，而我在发现这个问题之前已经为项目加载了该版本。 所以我在线创建了一个新的 SDK，但为了获得 Azure 支持，它又降级到了 2.10 版本。但是，当我尝试更改项目的 SDK 时，它不允许我删除我已有的 SDK，当我尝试添加另一个 SDK 时，它告诉我 SDK 2.x_FRDM-K64F 已经存在。 我如何获得 Azure 支持？我只需要它来访问SD卡！ Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F 你好@ve3id ， 感谢你的帖子。 提醒一下，在 FRDM-K64F 上，SDK 已经提供了基于 SDHC + FatFs 的 SD 卡文件系统示例，而 FatFs 可以在裸机模式下运行，无需 RTOS。FRDM-K64F SDK 示例包括 frdmk64f_driver_examples_sdcard_fatfs / fatfs_sdcard 风格的项目，用于挂载 SD 卡并执行目录/文件读写操作。 如果您仍然想要 Azure RTOS，对于“SDK 2.x_FRDM-K64F 已存在”的问题，这意味着 IDE 中已经安装了具有该身份的 SDK。MCUXpresso IDE 支持从该视图中删除已安装的 SDK 包。请参考下图进行卸载。 之后，您可以再次尝试安装 SDK v2.10。 希望对您有所帮助。如果您还有其他问题，请告诉我。 BR 塞莱斯特 Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F 谢谢你，塞莱斯特。从文献中并没有明确看出情况确实如此。不过，我已经通过将我的代码复制粘贴到示例中解决了这个问题，现在正在处理下一个问题，即挂载后尝试读取目录时返回零！ 干杯 奈杰尔 Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F 你好@ve3id ， 不客气，很高兴能帮到您！ 如有任何新问题，请随时发帖提问。 BR 塞莱斯特

Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F I want to use an SD card in my project to load individual personalisation data fpor a two-way radio system.   I am getting #include "tx_api.h" and #include "tx_event_flags.h" as not defined. This is due to the fact that I did not include azure rtos in the SDK. I try to overcome this by installing azure into the SDK using 'manage sdk components', but I apparently azure rtos support was dropped in 2.11, which I loaded for the project before I saw this problem. So I created a new SDK online, but it drops back to 2.10 to get azure support.  However when I try to change the SDK for my project, it will not let me remove the SDK I have, and when I try to add another one it tells me that SDK 2.x_FRDM-K64F already exists. How can I get azure support.  I only need it for SD card access! Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Thank you Celeste.  It was not clear from the literature that such was the case.  However I have solved the problem by cutting and pasting my code into the example and have moved on, working on the next problem now which is the fact that it returns zero when trying to read the directory after mounting! Cheers Nigel Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Hello @ve3id , Thanks for your post. Just a reminder, on FRDM-K64F, the SDK already provides SD card file-system examples based on SDHC + FatFs , and FatFs can run in bare-metal mode without an RTOS, the FRDM-K64F SDK examples include frdmk64f_driver_examples_sdcard_fatfs / fatfs_sdcard style projects for mounting an SD card and doing directory/file read-write operations. If you still want Azure RTOS, for the “SDK 2.x_FRDM-K64F already exists” issue, this means the IDE already has an SDK with that identity installed. MCUXpresso IDE supports deleting installed SDK packages from that view. Please refer to below picture to uninstall. After that, you can try to install SDK v2.10 again. Hope it helps. Please let me know if you have any other questions. BR Celeste Re: Undefined SD Card symbols using MCUxpresso 25.6 on FRDM-K64F Hello @ve3id , You are welcome, glad to help! Any new questions, please feel free to create a new post. BR Celeste

UM11490とBluetooth Classic NXPサポートの皆様、 お客様の一人がUM11490の149ページから以下のコマンドを実行していますが、波形が見えません。 追加のコマンドや条件が不足していないか、ご確認ください。 よろしくお願いします。 よろしくお願いいたします。 桟橋 ------------------------------------ # リセット root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCIコマンド:ogf 0x03、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 0C 00 # スキャンを有効にする root@myboard:/ホーム/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCIコマンド:ogf 0x03、ocf 0x001a、プレン1 03 > HCIイベント:0x0eプレン4 01 1A 0C 00 # イベント情報フィルターを有効にする root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCIコマンド:ogf 0x03、ocf 0x0005、プレン3 02 00 02 > HCIイベント:0x0eプレン4 01 05 0C 00 # テストモードでエントリー root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCIコマンド:ogf 0x06、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 18 00 # TXトランスミッションを開始 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 01 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCIイベント:0x0eプレン4 01 19 FC 00 # TXの送信を止めろ root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xF F 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 04 > HCIイベント情報:0xffプレン6 19 01 39 00 00 00 --------------------、TXトランスミッションの前にBLEとCLASSICのスキャンを止めること---------------- # リセット root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0003 < HCIコマンド:ogf 0x03、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 0C 00 # スキャンを有効にする root@myboard:/ホーム/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x3 < HCIコマンド:ogf 0x03、ocf 0x001a、プレン1 03 > HCIイベント:0x0eプレン4 01 1A 0C 00 # イベント情報フィルターを有効にする root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x0005 0x02 0x00 0x02 < HCIコマンド:ogf 0x03、ocf 0x0005、プレン3 02 00 02 > HCIイベント:0x0eプレン4 01 05 0C 00 # テストモードでエントリー root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x06 0x0003 < HCIコマンド:ogf 0x06、ocf 0x0003、プレン0 > HCIイベント:0x0eプレン4 01 03 18 00 # BLEスキャンを無効に root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x03 0x001a 0x0 < HCIコマンド:ogf 0x03、ocf 0x001a、プレン1 00 > HCIイベント:0x0eプレン4 01 1A 0C 00 # クラシックスキャンを無効にする root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x08 0x000C 0x00 0x00 < HCIコマンド:ogf 0x08、ocf 0x000c、プレン2 00 00 > HCIイベント:0x0eプレン4 01 0C 20 00 # TXトランスミッションを開始 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0x01 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 01 01 01 0D 03 0F 00 00 00 00 00 00 04 > HCIイベント:0x0eプレン4 01 19 FC 00 # TXの送信を止めろ root@myboard:/ホーム/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 04 > HCIイベント情報:0xffプレン6 19 01 63 07 00 00 **テストモードに入る前にスキャンを無効にすると、TX送信の停止により次のようになります。 root@myboard:/home/BTtest# hcitool -i hci0 cmd 0x3F 0x0019 0x80 0x80 0x80 0x80 0xFF 0x00 0x01 0x01 0x0D 0x03 0x0F 0x00 0x00 0x00 0x00 0x00 0x00 0x04 < HCI司令部:ogf 0x3f、ocf 0x0019、プレン18 80 80 80 80 FF 00 01 01 0D 03 0F 00 00 00 00 00 04 > HCIイベント:0xffプレン6 19 01 ED 04 00 00 Wi-Fi 5GHz用 -------------------------------------------------------------------------------- パラメータ: 連続送信、帯域幅 = 40 MHz、802.11ac、DFSなし、CH = 40、MCS0 (13.5)、電力 = 14 dBm root@myboard:/home/BTtest# cat /proc/mwlan/adapter0/config hardware_status=0 netlink_num=31 drv_mode=7 hssetpara=7,0xff,200,400 SDCMD52RW=0 0x0 0x00 rf_test_mode=1 tx_antenna=1 rx_antenna=1 バンド=1 BW=1 チャネル=44 radio_mode[0]=3 radio_mode[1]= 総処方PKT数=0 RXマルチキャスト/ブロードキャストのPKTカウント=0 rx FCSエラー PKTカウント=0 tx_power=14 2 0 tx_continuous=0 tx_frame=1 4352 0xaaa 1024 1 20 4294967295 0 0 0 4294967295 0 0 0 0 -1 -1 -1 -1 -1 -1 -1 -1 05:43:3f:c4:51:ff he_tb_tx=0 trigger_frame=0 otp_mac_add_rd_wr= 00:00:00:00:00:00 Re: UM11490 and Bluetooth Classic こんにちは、 @Christine_Li さん。 文脈が抜けていて申し訳ありません。 カーネルバージョン：lf-6.6.52-2.2.2（6.6.yとマージ済み）コミュニティカーネル FWバージョン：IW612-18.99.3.p25.7、BT/WiFiファームウェアは別々、コンボは不可 製品:IW612 UM11490 バージョン: Rev.1.8 — 2025年6月2日 以下の詳細は近日中に公開されます ファームウェアをロードしたときのdmesgログまたはコンソールログ スペクトラムアナライザの設定画面のスクリーンショット その間、他に何か必要なことがございましたら、お知らせください。 よろしくお願いします。 よろしくお願いいたします。 桟橋 Re: UM11490 and Bluetooth Classic こんにちは、 @pierluigi_p どのWi-Fi/Bluetooth製品を使っていますか? Linuxカーネルのバージョンは何ですか?WiFi/BluetoothドライバとFWバージョンは? コマンドログからは、すべてのHCIコマンドが正常に完了し、TXスタートコマンドがコントローラに受け入れられます。さらに、TX停止コマンドで返されるベンダー固有のイベント情報にはゼロでないパケットカウンタが含まれており、これはコントローラがテスト期間中にパケットが送信されたと判断していることを示します。 したがって、この問題はテストシーケンスにおけるHCIコマンドの欠落が原因ではないと考えられる。 確認することをお勧めします： スペクトラムアナライザの中心周波数とスパンの設定。 TXテストコマンドで設定したBluetoothチャネル。 基板上のRFアンテナ構成。 Bluetoothファームウェアが正しくロードされているかどうか。 また、以下のことも教えていただけますか: 使用されているチップはどれですか（IW416/IW612など）？ 正確なUM11490のバージョンは？ ファームウェアをロードしたときのdmesgログまたはコンソールログは？ コンボファームウェアをインストールしていますか、それともBluetooth専用ファームウェアをインストールしていますか？ スペクトラムアナライザの設定画面のスクリーンショットはありますか？ よろしくお願いいたします。 Christine。 Re: UM11490 and Bluetooth Classic こんにちは、ピアとクリスティーン 私はHelbert、Verisciteフォーラムでスレッドを始めた開発者です。 テストに関する添付ファイルは以下のとおりです。 dmesgログ（電源設定なし）： dmesgログ（電源設定を含む）： スペクトラムアナライザと5GHz帯の設定ファイル（自社実装およびNXP実装）のスクリーンショット 実行後 注：電力に-1を使用するとデフォルト値が使用されることがわかりましたが、異なる値も実験しました。 NXPスクリプト: 定番のBluetoothテストのスクリーンショット： ご覧の通り、波形は生成されません BLEテスト実行時のスクリーンショット： BLEテスト後のスクリーンショット（波形が途切れています）： 下の図で、テスト終了時に波形が中断されたことがわかります Modinfoのログ: テストされたHCI CMD: Re: UM11490 and Bluetooth Classic 補足ですが、HackRFの異なる設定(ゲインやグラフィック調整)で試したところ、2.4GHz(Wi-Fi)波形が見えます。さらに、imx-firmwareリポジトリ内の異なるバージョンの異なるファームウェアをテストし、RF-test用のファームウェアも含まれています(sduart_nw61x_rftm_v1.bin.se)は https://github.com/nxp-imx/imx-firmware/blob/lf-6.1.1_1.0.0/nxp/FwImage_IW612_SD/IW612_SD_RFTest/sduart_nw61x_rftm_v1.bin.se)で成功しませんでした。