S32K328のGMAC RX割り込み 私はS32K328のGMACを使っていて、PCからパッケージを受け取るために割り込み方式を使いたいと思っています。しかし、いくつかの異なる現象が発見された。 1. 割り込みハンドラGMAC0_CH0_RX_IRQHandlerを呼び出し、通常通りパッケージを受信できます。 2. PCがパッケージを送信した後、何秒も通話GMAC0_CH0_RX_IRQHandler。 3. GMAC0_CH0_RX_IRQHandler電話できず、パッケージも届かない? その理由は一体何だろうか？どうすれば解決できるでしょうか？ Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 設定情報を共有していただきありがとうございます。EB tresosが手元にないため、提供いただいたファイルからGMACの設定を手動で確認しました。 あなたのEth_43_GMAC構成を、正常に動作するS32K358 GMAC 1G lwIP FreeRTOSリファレンスプロジェクトと比較しました。大きな違いの一つは、Egress FIFO構成です。あなたのプロジェクトでは、Egress FIFOバッファ長は128バイト、MTL Egressキューサイズは256バイトに設定されています。一方、リファレンスプロジェクトでは、Egress FIFOバッファ長は1536バイト、MTL Egressキューサイズは4096バイトです。   もしアプリケーションがフレームを送信したり、上位層が応答を送る場合、この小さなTX/Egress構成は標準的なイーサネットフレーム、特に1G RGMIIモードでは制限が多すぎる可能性があります。テストとして、以下の値を増やしてみてください。   - EthCtrlConfigEgressFifoBufLenByte を 1536 に変更 - EthCtrlConfigMTLEgressQueueSizeInBytes を 4096 に変更   RXパスの場合、RXバッファの長さ自体は1536バイトで、これは妥当な値に見えます。しかし、あなたのMTLイングレスキューのサイズは1536バイトですが、参照プロジェクトでは4096バイトを使用しています。したがって、別のテストとして、以下の値も増やしてみてください。   - EthCtrlConfigMTLIngressQueueSizeInBytes を 4096 に変更   さらに、デバッグのために、一時的に全受信モードを有効にしてください。現在の設定ではPKT_FILTER_RECV_ALLが無効になっていますが、参照プロジェクトでは有効になっています。これにより、MACフィルタリングを分析から除外することができます。   EthEnableCacheManagementなど、他にも違いがあります。 EthCtrlReleaseResourceAfterReception ですが、これは必ずしも間違っているわけではありません。   よろしくお願いいたします。 パベル Re: GMAC RX interrupt of S32K328 こんにちは： ユニキャストフレームとブロードキャストフレームの両方を試しましたが、各フレーム間の遅延は1秒で、十分遅いと思います。 現象は同じで、最初は RxStatsDropEvents は発生しませんが、数フレーム後に発生します。 私のEB構成は添付ファイルの通りです。ご都合の良い内容かどうかご確認いただけますでしょうか。 ありがとうございます。 Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 RxStatsDropEventsは、一部のフレームがGMACによって認識されているものの、RXパスのどこかでドロップされていることを示唆しています。これはRXリソースの可用性、RX FIFO/キュー処理、ディスクリプタ/バッファの可用性、パケットフィルタリング、または上位層の受信処理に関連している場合があります。   以下の点を確認してください。   1. PCから同じユニキャストフレームをゆっくりと送信してください。例えば、一度に1フレームずつ送信したり、フレーム間に大きな遅延を設けたりして、テストの前後の受信統計を比較してください。もしRxStatsDropEventsが増加しなくなった場合、その問題はRXバッファのリサイクル、プロセッシング時間、またはPCからのトラフィックのバーストに関連している可能性があります。   2. ブロードキャストフレームでテストを繰り返し、その後GMACドライバで設定されたMACアドレスに正確に割り当てられたユニキャストフレームでテストを繰り返してください。これにより、MACアドレスやフィルタリングの問題を除外することができます。   RGMIIクロックとペリフェラルの設定も必ず確認してください。参考までに、NXPコミュニティでGMACのS32K358例を公開しています: https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K358-GMAC-1G-lwIP-FreeRTOS-S32DS-3-6-1-RTD600/ta-p/2355872     この例はS32K358向けでありS32K328用ではないため、S32K328ピン配置とクロック構成を確認せずに直接コピーしないでください。しかし、全体のクロック設定、Eth_43_GMAC設定、DCMRWFレジスタの回避策の参考として利用できます。   可能であれば、あなたのzip化プロジェクトも共有していただけますか?プロジェクトがなければ、ドロップが設定、RXリソース処理、キュールーティング、またはアプリケーションの受信経路によるものかを判断するのは困難です。 よろしくお願いいたします。 パベル Re: GMAC RX interrupt of S32K328 こんにちは： RTD関数のフレーム情報を読みEth_43_GMAC_GetRxStats、ドロップイベントがあるようです。 zyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.png RXフローはすべて以下のようにRTDによって処理され、私は変更していません。 GMAC0_CH0_RX_IRQHandler -> GMAC_RxIRQHandler -> Eth_43_GMAC_RxIrqCallback -> Eth_43_GMAC_Receive その理由は一体何だろうか？ありがとう。 Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 詳細を教えていただきありがとうございます。   また、このThreadに従ってピン/クロック/device_init()も確認してください: S32K358 - GMACクロック構成   スクリーンショットから判断すると、GMAC0割り込みベクタは、GMAC0_CH_0_RX_IRQHandlerを含むRTDハンドラに設定され、マッピングされているようです。このハンドラが時々入力され、フレームが受信されるため、基本的な割り込みルーティングは完全に間違っているわけではありません。   ただし、AUTOSAR Eth_43_GMACドライバーを使用する際は、低レベルIRQハンドラ上の受信フローも必ず確認してください。RX割り込みハンドラ自体は通常、完全なアプリケーションレベルの受信処理ではありません。アプリケーションや上位層は、例えばEth_43_GMAC_Receive()のように期待されるEth_43_GMAC受信APIフローを呼び出す必要があります。これにより、受信フレームがドライバから読み込まれ、設定済みのコールバックパスをさらに通過します。   以下の点をご確認ください。   1. Eth_43_GMAC_Receive()がRX割り込みイベント情報の後、またはアプリケーションデザインに応じてメイン/タスクコンテキストから定期的に呼び出されるかを確認してください。割り込みが発生したにもかかわらず、受信したフレームがRXバッファから消費されない場合、後続のフレームが期待どおりに受信されない可能性があります。   2. 受信されたユニキャストフレーム宛先MACアドレスがGMACドライバで設定されたMACアドレスと正確に一致しているか確認してください。デバッグの目的で、MACフィルタリングを理由に除外するために、一時的にReceive-all/promiscuousモードを有効にすることができます。   3. どのRXキュー/FIFOが使用されているか確認してください。スクリーンショットには、CH0、CH1、CH2のRX割り込みハンドラが表示されています。パケットフィルタやキュー構成がフレームを別のRXキューにルーティングする場合、アプリケーションは対応するFIFOインデックス付きの受信関数を呼び出し、そのキューを正しく処理しなければなりません。   4. RXバッファ/ディスクリプタが利用可能であることを確認してください。受信フレームが処理された後、ドライバはRXバッファを再利用または取得できる必要があります。受信バッファが枯渇した場合、最初のフレームは正しく受信される可能性がありますが、それ以降のフレームは遅延したり、失われたりする可能性があります。   5. キャッシュが有効になっている場合は、GMAC ディスクリプタと RX バッファがキャッシュ不可能なメモリ領域に配置されているか、必要なキャッシュメンテナンスが実行されていることを確認してください。そうしないと、CPUは古い記述子ステータスや古い受信データを認識する可能性があります。   6. フレームはPythonスクリプトからユニキャストフレームとして送信されるため、PCが期待される宛先MACアドレスでフレームを継続的に送信していることをWiresharkで確認してください。一部のフレームがアドレス解決を必要としたり、宛先に期待通り到達できない場合、PC側は再試行や遅延を導入し、MCU側での遅延RX割り込み動作のように見えることがあります。   参考までに、まずは改造されたS32K3イーサネット/lwIPの例と比較してみることをおすすめします。これにより、RGMII PHYインターフェース、クロック、MACアドレス、基本的なRXパスが動作しているか確認し、カスタムAUTOSAR Eth_43_GMAC割り込み受信実装に注力する前に確認できます。   それでも問題が解決する場合は、Eth_43_GMAC_Receive()が呼び出された場合、RX FIFO設定、MACアドレス/フィルター設定、失敗後のGMAC DMA/MTL/MACステータスレジスタなどのアプリケーションEth_43_GMAC受信部分を共有してください。 よろしくお願いいたします。 パベル Re: GMAC RX interrupt of S32K328 こんにちは： 1.私はRGMIIを使用しています 2. 私はRTD 6.0.0を使用しています。 3. 私はEth_43_GMACドライバを使用しています。 4. 中断とは次のようなものです。 zyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.png 5. Pythonスクリプトを使ってユニキャストフレームを送信します。 私が送信するパッケージはすべて同じで、GMAC0_CH0_RX_IRQHandler は RTD からのもので、上の図のように最も下位のハンドラです。 Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 あなたのセットアップについてもう少し詳しく教えていただけますか?   1. S32K328で使っているMAC/PHYインターフェースは、例えばMII、RMII、RGMIIのいずれかです。 2. 使用しているS32K3 RTDのバージョンは何ですか？ 3. AUTOSAR MCAL Eth_43_GMACドライバーを使っていますか?それとも低レベルのGMAC IPドライバーを使っていますか? 4. 関連する割り込み設定とGMAC0_CH0_RX_IRQHandlerの実装について教えていただけますか? 5. PCから送信されるフレームの種類は、ping/ICMP、UDP、生のイーサネットフレーム、ブロードキャストフレームやユニキャストフレームなどです。   参考テストとして、まずは適応したS32K3イーサネット/lwIPの例を使ってこの挙動を再現してみることもおすすめします。これにより、基本的なGMAC/PHY/クロック/設定の問題と、アプリケーション固有の割り込みやRXバッファの処理問題を区別するのに役立ちます。     症状についてですが、時折RX割り込みが呼び出されフレームが正しく受信できれば、基本的なRXパスは少なくとも部分的に動作している可能性が高いです。しかし、この一貫性のない動作は、以下のいずれかの原因による可能性があります。   - RXバッファまたはディスクリプタ処理:受信フレームが処理された後、RXバッファ/ディスクリプタはドライバ/DMAに戻されなければなりません。これが正しく行われないと、RXバッファが使用できなくなり、その後のRX割り込みが停止したり、不安定になったりする可能性があります。   - 割り込み処理:RX割り込みが正しいGMACチャネルに設定されており、期待されるドライバー割り込みハンドラ/状態クリアリングフローが使用されていることを確認してください。割り込み状態が正しくクリアされていない場合、以下のRXイベント情報が期待通りに報告されないことがあります。   - キャッシュ/メモリの一貫性: キャッシュが有効になっている場合は、GMAC ディスクリプタと RX バッファが適切なキャッシュ不可のメモリ領域に配置されているか、必要なキャッシュメンテナンスが実行されていることを確認してください。そうしないと、CPUは古い記述子ステータスや古い受信データを認識する可能性があります。   - パケットフィルタリング/MACアドレス: デバッグ目的で、一時的に受信全モード/プロミスキャスモードを有効にしてみてください。これは、フレームがMACアドレスフィルタ、VLANフィルタ、またはその他のパケットフィルタ設定によって拒否されたかどうかを確認するのに役立ちます。   - フレームの種類と PC の動作: PC が ping などの IP トラフィックを送信する場合、ICMP トラフィックが送信される前に、最初のフレームは ARP 要求/応答である可能性があります。ARPの解像度が失敗したり、一部のフレームがフィルタリング・ドロップされた場合、PCがARPを再送信したり、アプリケーションが後で再試行したりして割り込みが数秒遅れているように見えることがあります。   - PHYリンクとクロック:PHYリンクが稼働していること、選択したMII/RMII/RGMIIインターフェースに必要な入力クロックが安定していることも確認してください。   上記の構成の詳細と、可能であれば、障害発生後のGMAC DMA/MTL/MACステータスレジスタを共有してください。これにより、問題が割り込み設定、RXディスクリプタ/バッファ処理、パケットフィルタリング、外部PHY/インターフェース設定に関連しているかどうかを特定するのに役立ちます。 よろしくお願いいたします。 パベル Re: GMAC RX interrupt of S32K328 こんにちは： 以下のように、ご指示いただいたとおりに設定しました。 zyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.png zyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.png zyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.png zyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.png EthCtrlReleaseResourceAfterReceptionは外部データバッファを使用した場合にのみ適用されるため、変更できません。 zyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.png これらを変更した後も結果は同じで、RxStatsDropEvents が表示されました。 zyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.png 変更された設定ファイルは添付ファイルのようなものです。 もう少しアドバイスをいただけますか?ありがとう。 Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 最新情報のご提供ありがとうございます。あなたのファイルを再度確認しましたが、不審な点は何も見つかりませんでした。FIFO/キューのリソースを増やしても動作が変わらない場合は、設定パラメータをむやみに変更し続けるべきではありません。次のステップは、実際にRxStatsDropEventsとしてカウントされるフレームを特定することです。ドロップカウンターが増加するのは、Pythonのユニキャストフレームが送信された時だけなのか、それともPythonのトラフィックが実行されていない時にも増加するのかを確認してください。PC側のバックグラウンドトラフィックやフィルタリングされたフレームも受信統計に影響を与える可能性があるためです。 よろしくお願いいたします。 パベル Re: GMAC RX interrupt of S32K328 すみません、あなたがEBに加入していないことを忘れていました。 添付ファイルは、修正後に生成されたファイルです。 Re: GMAC RX interrupt of S32K328 こんにちは： 私のテストでは、ブロードキャストフレームもユニキャストフレームもドロップでき、pヘノメノンは同じで、PCは私のコントロール外のフレームを送りません。 フレームを送信すると、RTD 関数 Gmac_Ip_ReadFrame が以下の分岐に入るという特別な現象が時々発生します。 zyt_0-1787101369298.pngzyt_0-1787101369298.pngzyt_0-1787101369298.pngzyt_0-1787101369298.pngzyt_0-1787101369298.png それは、(((Bd->Des3 & GMAC_RDES3_OWN_MASK) != 0U) だからです。 zyt_1-1787101442166.pngzyt_1-1787101442166.pngzyt_1-1787101442166.pngzyt_1-1787101442166.pngzyt_1-1787101442166.png 関数コールフローは以下の通りで、すべてRTDドライバーに属します: zyt_2-1787101651452.pngzyt_2-1787101651452.pngzyt_2-1787101651452.pngzyt_2-1787101651452.pngzyt_2-1787101651452.png 現時点では、Eth_43_GMAC_Receive は GMAC バッファのデータを読み取りません。 しばらくするとGMACのFIFOが満タンになると、後から来たフレームが落ちます。 私の分析は理にかなっていると思いますか？ もしそうなら、なぜ(((Bd->Des3 & GMAC_RDES3_OWN_MASK) != 0U) が起こったのでしょうか?その理由は一体何だろうか？ ありがとう。 Re: GMAC RX interrupt of S32K328 こんにちは： 問題はキャッシュが原因です。プロジェクトからマクロ D_CACHE_ENABLE を削除すると、すべて正常に戻ります。 それはキャッシュコヒーレンシの問題を意味しますか？ しかし、D_CACHE_ENABLE を追加して下のチェックボックスをオンにすると、問題も発生しました。 zyt_2-1787215536381.pngzyt_2-1787215536381.pngzyt_2-1787215536381.pngzyt_2-1787215536381.png RTDの可変領域設定は一切変更していませんし、 RTDドライバーを確認したところ、GMAC_0_Rx/TXRing_0_Desc/DataBufferはno_cacheリージョンにありますが、Gmac_apxStateのようにキャッシュされているmcal_bssに入っていません。そんなに妥当なのか? zyt_4-1787215940789.pngzyt_4-1787215940789.pngzyt_4-1787215940789.pngzyt_4-1787215940789.png では、D_CACHE_ENABLEを加えた上でこの問題をどう解決すればいいのでしょうか? ありがとうございます。 Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 詳細なデバッグ情報をありがとうございました。あなたの指摘は参考になりますが、「OWN」の部分については、私は少し違った解釈をします。   RDES3.OWNが設定されている場合、RXディスクリプタはCPUではなくDMAによって所有されます。したがって、Gmac_Ip_ReadFrame()は現在の記述子がまだ完成してソフトウェアに戻されていないため、正しくGMAC_STATUS_RX_QUEUE_EMPTYを報告します。OWN = 1のRXディスクリプタは通常DMAに利用可能であるため、この条件だけでRXリングがブロックされていることやGMACのFIFOが満杯であることを示すわけではありません。   重要な疑問は、RxCurrentDescがまだDMAによって所有されているディスクリプタを指しているにもかかわらず、なぜRX割り込みコールバックが実行されるのかということである。割り込みは別のRX/DMAステータス条件によって引き起こされた場合や、完了した記述子が現在のソフトウェア記述子ポインタと一致しない可能性があります。   生成されたコードは、GMAC RX ディスクリプタと RX データバッファをキャッシュ不可能な MemMap セクションに配置します。しかし、共有プロジェクトにはリンカーマップファイルが見当たらないため、このセクションが最終実行ファイル内のキャッシュできないメモリ領域に実際にマッピングされているかどうか確認できません。   ビルドで生成されたリンカーマップファイルを共有してもらえますか?特に、以下の最終住所とセクションを確認したいと思います。   - GMAC_0_RxRing_0_DescBuffer - GMAC_0_RxRing_0_DataBuffer - GMAC_0_TxRing_0_DescBuffer - GMAC_0_TxRing_0_DataBuffer   また、GMAC_STATUS_RX_QUEUE_EMPTY が、RX 割り込み後の最初の Gmac_Ip_ReadFrame() 呼び出し時に発生するのか、それとも 1 つ以上のフレームが正常に読み取られた後にのみ発生するのかを確認してください。OWNビットが1に設定されている場合、それは単に受信ループの通常の終了を示している可能性があり、次のディスクリプタは既にDMAによって所有されており、別のフレームを待っている状態です。 よろしくお願いいたします。 パベル Re: GMAC RX interrupt of S32K328 こんにちは、 @zyt さん。 最新情報のご提供ありがとうございます。はい、D_CACHE_ENABLEを削除すると問題が解消されるという事実は、キャッシュの一貫性またはメモリ領域の設定に問題があることを強く示唆しています。   しかし、Gmac_apxState自体は通常、キャッシュ不可能なメモリに配置する必要はありません。CPU側のドライバの状態とポインタを含み、GMAC DMAから直接アクセスされることはありません。CPUとGMAC DMAの間で共有される重要なオブジェクトは、ハードウェア記述子リングとRX/TXデータバッファである。   以前共有された生成ファイルを確認しました。Gmac_Ip_Cfg.h では、生成された設定には以下が含まれていました。   #define GMAC_HAS_CACHE_MANAGEMENT (STD_OFF)   同時に、Gmac_Ip_Cfg.cGMACのRX/TX記述子とデータバッファをNO_CACHEABLE MemMapセクションに配置します。したがって、生成される構成は、これらのオブジェクトが本当にキャッシュできないメモリ領域にマッピングされることに依存しており、GMACドライバーによる明示的なキャッシュ保守に依存していないようです。   EthEnableCacheManagementを有効にした後、RTD構成全体を再生成し、クリーンビルドを実行してください。次に、Gmac_Ip_Cfg.h 内の GMAC_HAS_CACHE_MANAGEMENT の値を確認してください。実際にコンパイルされるファイル。STD_OFFのままの場合、生成されたビルドでは低レベルのGMACキャッシュメンテナンスが有効になっていません。   リンカーマップファイルと、関連するリンカー/MPUメモリ領域の設定も共有してください。以下の最終セクションとメモリ属性を検証する必要があります。   - GMAC_0_RxRing_0_DescBuffer - GMAC_0_RxRing_0_DataBuffer - GMAC_0_TxRing_0_DescBuffer - GMAC_0_TxRing_0_DataBuffer   生成されたソースコードはこれらのオブジェクトをキャッシュ不可能なセクションに配置しますが、リンカースクリプトとMPU構成もそのセクションを真にキャッシュ不可能な領域にマッピングする必要があります。そうしないと、DMAがRAM内の記述子を更新した後でも、CPUは古いキャッシュされた記述子値（例えばOWN = 1）を読み取ってしまう可能性があります。   現時点では、Gmac_apxStateをキャッシュ不可能なメモリに移動することはお勧めしません。最初のステップは、すべてのDMA共有ディスクリプタとバッファが正しい非キャッシュ可能なMPU領域に配置されているか、あるいはコンパイル済みドライバ構成でGMACキャッシュ管理が本当に有効であるかを確認することです。 よろしくお願いいたします。 パベル

S32N55: How to build a blob image for fast wake-up boot. Hello Team, As we know, the S32N55 supports Fast Wake-up Boot. I tried building a blob image using the same format as Full Wake-up Boot, but the boot process failed. Could you please guide me on how to correctly build a blob image for Fast Wake-up Boot? Thank you! Tangsheng_Zhou_0-1766369489644.pngTangsheng_Zhou_0-1766369489644.png Best regards, Tangsheng. FSS_FW Priority: MEDIUM Re: S32N55: How to build a blob image for fast wake-up boot. Hello @Tangsheng_Zhou, The team has picked up the case and will provide an answer as soon as possible.  Best regards, Radu  Re: S32N55: How to build a blob image for fast wake-up boot. Hello @RaduBraga  I noticed that this ticket has been closed. Is there any update on the progress?   Best regards, Tangsheng. Re: S32N55: How to build a blob image for fast wake-up boot. Hello @Tangsheng_Zhou , I took over the case and will provide a response as soon as possible.   Best regards, Paul Re: S32N55: How to build a blob image for fast wake-up boot. Hello @Tangsheng_Zhou , If you are supporting a Direct Customer, please provide: BSSM Contract: Yes / No Customer Company*: Project Name*: Customer Contact Point* (Name & Email): Software & Hardware Information: SW Package Info*: HW* (Board/Chipset/Platform): SW Version*: *required I am still working with the development team for this case Best regards, Paul Re: S32N55: How to build a blob image for fast wake-up boot. Hello @Tangsheng_Zhou , Thank you for these details, I am working on this case and will provide an answer as soon as possible! Best regards, Paul Re: S32N55: How to build a blob image for fast wake-up boot. Hello @PaulB0bes  This case is not tied to any specific customer or project. However, I believe customers may encounter similar questions in the future, which is why I raised this request.   Best regards, Tangsheng. Re: S32N55: How to build a blob image for fast wake-up boot. Hello @PaulB0bes  Below are the detailed steps for testing.   1. built a small FSS image within AOSRAM memory region(reserved the IVT header), which only have a while loop in main.c Tangsheng_Zhou_0-1784553297963.pngTangsheng_Zhou_0-1784553297963.png 2. build the FSS Firmware image,  do I need to fill the FRB Threshold Reg? If so, how to fill it or any special thing need to be considered. Tangsheng_Zhou_1-1784553422329.pngTangsheng_Zhou_1-1784553422329.png 3. built the IVT blob image in IVT tool, with start address from 0x24800000 4. write the IVT blob image into flash at 0xD00000. 5. before the system enter sleep, copy the IVT blob image into AOSRAM, and configure the WKPU mode for FSS_WKUP0 as fast wake-up mode. Tangsheng_Zhou_2-1784553712231.pngTangsheng_Zhou_2-1784553712231.png Tangsheng_Zhou_3-1784553730808.pngTangsheng_Zhou_3-1784553730808.png 5. wakeup the system image via FSS_WAKUP0. The FSS could not reach the while(1) loop. It appears that a reset event was triggered during the wake-up process instead of a fast wake-up.   Thanks for your support!   Best regards, Tangsheng. Re: S32N55: How to build a blob image for fast wake-up boot. Hello @Tangsheng_Zhou , It would help if you could share the exact steps you followed when you tried to build the blob image. I think it would be easier for us to identify the issue that way.   Best regards, Paul Re: S32N55: How to build a blob image for fast wake-up boot. Hi @Tangsheng_Zhou , FRB is for TCM memory (ITCM +DTCM). In theory we have 2 cases 1: FAST wakeup Boot      for fast wakeup FRB is not needed, due to the fact that image boots from AON SRAM Memory. 2: FULL wakeup Boot      Can you tell me if you want to boot to ITCM? if yes FRB threshold 0 should be provided in FSS Image header, the address is 12 bit masked and address will be calculated as multiple of 8kb for FRB .       Hope this helps a little. Also could you provide me the IVT blob? Best regards, Paul Re: S32N55: How to build a blob image for fast wake-up boot. Hello @PaulB0bes  No, I just want to run the F-Core in AO-SRAM.  main_app1.bin is the FSS firmware image. How to fill these two field, should it be started from AO_SRAM address, 0x24800000? the start pointer and entry pointer of my image is 0x24800240. Tangsheng_Zhou_0-1784682563629.pngTangsheng_Zhou_0-1784682563629.png main_blob1.bin is the blob image that contain IVT header. Thanks! Best regards, Tangsheng. Re: S32N55: How to build a blob image for fast wake-up boot. Hello @PaulB0bes  The complete IVT image rather than the FSS Firmware was copied to AO_SRAM before entering sleep mode to test the fast wake-up functionality.   Thanks! Best regards, Tangsheng Re: S32N55: How to build a blob image for fast wake-up boot. Hello @PaulB0bes  The whole IVT blob image was copied to start of AO_SRAM, including IVT header and FSS FW header, and FSS FW binary. Thanks! Best regards, Tangsheng. Re: S32N55: How to build a blob image for fast wake-up boot. Hi @Tangsheng_Zhou , Just to make sure I understand the flow, are you copying the complete IVT blob image to the beginning of AO_SRAM before sleep, or are you copying only the FSS firmware image for Fast Wake-up Boot? Best regards, Paul Re: S32N55: How to build a blob image for fast wake-up boot. Hi @Tangsheng_Zhou , Could you please confirm that the Fast Wake-up Boot is completing successfully? If the wake-up process is confirmed to be working as expected, this may indicate an issue with the image.  I would like to narrow down the possible causes step by step   Best regards, Paul Re: S32N55: How to build a blob image for fast wake-up boot. Hello @PaulB0bes  I think the WKPU configuration is correct. As I understand it, the main difference between Full Wake-up and Fast Wake-up is the WBMSR configuration. Is that right? Are there any other settings or factors that need to be considered? Also, could you please share the correct steps or a fast wake-up blob image verified by you or your team? Thanks for your support! Best regards, Tangsheng. Re: S32N55: How to build a blob image for fast wake-up boot. Hi @Tangsheng_Zhou , The team is currently overloaded with releases. I’ll apply a bit of pressure on my side, do some investigation and get back to you with an answer as soon as possible.   Best regards, Paul Re: S32N55: How to build a blob image for fast wake-up boot. Hi @Tangsheng_Zhou , WBMSR is one of the key differences between Full Wake-up and Fast Wake-up Boot. However, it is not the only factor. For Fast Wake-up Boot, BootROM expects a valid image (IVT + FSS FW, with Wakeup DCD if required) to be available in AON SRAM before entering sleep. In addition to WBMSR, the wake-up source configuration, AON SRAM retention and valid IVT/FSS headers should also be verified. The expected Fast Wake-up flow is:   1. Generate the IVT blob image containing IVT + FSS FW. 2. Add Wakeup DCD if required. 3. Copy the blob image to the beginning of AON SRAM. 4. Configure the system for Fast Wake-up mode. 5. Enter sleep and trigger the wake-up source Regarding a verified Fast Wake-up blob image, I am checking internally and will update you if a validated reference image is available   Hope this helps a little.   Best regards, Paul Re: S32N55: How to build a blob image for fast wake-up boot. Hello @PaulB0bes  Thanks for your reply. I tested the fast wake-up function following the steps you provided, but the issue is still present. Could you please confirm whether you have tested it successfully on your side?   Thanks!  Best regards, Tangsheng. Re: S32N55: How to build a blob image for fast wake-up boot. Hi @Tangsheng_Zhou , If you believe the provided answer is appropriate and you have no further questions regarding the ticket, please mark the answer as "Accept as Solution". For future cases please use NXP JIRA: Jira Project  Additionally, if we do not receive a response within the next 7 days, we will close the case. Best regards,  Paul 

imx8mp-evk SAI5外部I2Sマイク（SPH0645） - クロック生成に失敗しました。正しいクロックについて助けが必要です。 こんにちは、 基板：i.MX8MPLUSLPD4-EVK（8MPLUS-BBベース基板）   SAI5に外部I2S MEMSマイクロフォン（Knowles SPH0645LM4H）を取り付けます。 J21（EXP_CN）に物理的に配線されているSoC側のピンを使用する ベースボードの回路図に従って、レベルシフターU57/U58を介して拡張ヘッダーを接続 （SPF-46370）   1. ハードウェア配線（回路図と照合し、オシロスコープで検証済み）   SPH0645 BCLK -> J21 ピン 40 ("PDM_CLK", SoC パッド SAI5_RXC) SPH0645 LRCL -> J21 ピン 32 ("PWM4_3V3", SoC パッド SAI5_RXFS) SPH0645 DOUT -> J21 ピン 38 ("PDM_STREAM_0"、SoC パッド SAI5_RXD0) SPH0645 SEL - > GND(左チャンネル) SPH0645 3V -> J21 ピン 1 SPH0645 GND  -> J21 ピン 6   外部I2S MEMSマイクロフォン（SPH0645）を接続しようとしています SAI5、J21拡張ヘッダーに配線（BCLK -> SAI5_RXC、LRCL -> SAI5_RXFS、DOUT > SAI5_RXD0、8MPLUS-BB回路図と照合して確認済み （オシロスコープで確認済み）。   私たちはこの問題に直面しており、解決のための支援を必要としています。   サウンドカードは正しく認識されています。   root@imx8mp-LPDDR4-EVK:~# Arecord -l カード2:SPH0645audio [SPH0645-オーディオ]、デバイス0:...   しかし、クロックエラーにより録音が失敗します。   root@imx8mp-lpddr4-evk:~# arecord -D hw:CARD=sph0645audio,DEV=0 \ -f S16_LE -r 48000 -c 1 mic.wav [  140.950940]fsl-sai 30c50000.sai:必要な処方率を算出できませんでした: 3072000 [  140.958042]fsl-sai 30c50000.sai:ASoC: 30c50000.sai の snd_soc_dai_hw_params でエラーが発生しました:-22 arecord: set_params:1435: ハードウェアパラメータをインストールできません   clk_summaryを確認すると、sai5は依然として24MHzから派生していることがわかります。 オーディオPLLではなくオシレーター:   sai_pll_out_div2      0  0  50000  Y   0  0  0  24576000 sai5                  0  0  50000  N   0  0  0  24000000 sai5_root             0  0  50000  N   0  0  0  24000000   現在の&sai5ノード：   &sai5 { #sound-dai-cells = <0> pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai5>; assignment-clocks = <&clk IMX8MP_CLK_SAI5>; assignment-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; 割り当てられたクロックレート = <12288000>; fsl、sai-mclk方向出力; fsl、sai非同期; fsl,dataline = <0 0x1 0x0>; ステータス = "okay" };   pinctrl_sai5: sai5grp { fsl,pins = < MX8MP_IOMUXC_SAI5_RXFS__AUDIOMIX_SAI5_RX_SYNC 0xd6 MX8MP_IOMUXC_SAI5_RXC__AUDIOMIX_SAI5_RX_BCLK 0xd6 MX8MP_IOMUXC_SAI5_RXD0__AUDIOMIX_SAI5_RX_DATA00 0xd6 ＞ };   また、pinctrlグループが このボード上のSAI5_RXC/RXD0/RXFSと同じ物理パッドです。   SAI5のクロックをオーディオPLLに正しくルーティングするにはどうすればいいでしょうか。 24MHz発振器を使用する代わりに、3072000Hz（48kHz）を生成する パス？   参考までに画像も添付しました。   ありがとう。 IMG_8200.jpegIMG_8200.jpeg IMG_8205.jpegIMG_8205.jpeg    preview.jpgpreview.jpg preview (1).jpgプレビュー（1）.jpg    Re: imx8mp-evk SAI5 external I2S mic (SPH0645) - clock derivation fails, need help with correct cloc こんにちは、 次の設定を試してみることをお勧めします。 &sai5 { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai5>; assigned-clocks = <&clk IMX8MP_CLK_SAI5>; assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; assigned-clock-rates = <12288000>; clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI5_IPG>, <&clk IMX8MP_CLK_DUMMY>, <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI5_MCLK1>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_AUDIO_PLL1_OUT>, <&clk IMX8MP_AUDIO_PLL2_OUT>; clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k"; fsl,sai-asynchronous; fsl,dataline = <0 0x1 0x0>; status = "okay"; }; クロックやクロック名のバインディングがない場合、ドライバは24 MHz発振器にフォールバックします。また、マイクに接続しない場合は、fsl,sai-mclk-direction-outputプロパティは必要ありません。 よろしくお願いいたします。

S32K344 FlexIO I2C DMA 你好， 我有一些关于S32K344上的FlexIO I2C DMA的问题，希望您能提供一些见解。 1. 当使用 FlexIO 模拟 I2C 时，Tx 长度设置为 尺寸 + 1。这是因为 “发送移位器在 SCL 引脚的最后一个下降沿加载一个额外的字” ？ 1.png1.png1.png1.png 2.png2.png2.png2.png 2. 当使用DMA发送数据时， 主要循环计数 也设置为 大小 + 1。这是出于同样的原因吗？使用 DMA 时，所有传输的数据都来自 Master->TxData 。调用时 Flexio_I2c_Ip_MasterSendData ，应该 德州牛 长度为 大小 + 1 ，最后一个字节是否为 0xFF 或者 0x00 ？ 3.png3.png3.png3.png 3. 用于接收数据， 主要循环计数 设置为 尺寸 – 1。这是为什么呢？ 4. 我在 S32K344 上进行了测试，发现使用 DMA 进行 FlexIO I2C 接收数据时，接收到的数据比预期少一个字节。用示波器观察，最后一个字节的时钟信号只显示大约五六位波形。在 S32K312 上进行同样的测试没有问题。 S32K344 S32DS3.6.4 RTD700   BR， 杰森 Re: S32K344 FlexIO I2C DMA 嗨@Jason07 由于 FlexIO 不是专用的 I2C 外设，因此其实现需要额外的内部步骤才能正确完成 I2C 总线序列。 传输中的 Size + 1U 与 FlexIO 完成 I2C 帧序列所需的最终移位器负载有关。此次额外传输并不代表额外的有效载荷字节。相反，它被 FlexIO 硬件内部用于生成最终时钟脉冲，并将总线正确转换到传输结束状态。 接收端需要使用 1U 的尺寸，因为接收到的最后一个字节需要单独处理。这样，驱动程序就可以在正确的时间生成所需的 NACK 和 STOP 条件。 另外，请注意，使用 DMA 传输模式时，数据传输可能会受到缓存一致性问题的影响。为避免启用 数据缓存 时出现潜在问题，请确保用作 DMA TCD 源和目标的缓冲区分配在不可缓存的内存区域中。 调用 Flexio_I2c_Ip_MasterReceiveData() 函数时，无需增加 TRANSFER_SIZE 参数。驱动程序已经处理了接收序列所需的内部调整。 最后，在检查您的配置时，我注意到相同的 DMA 中断回调被分配给了两个 DMA 通道。根据 Flexio_I2c_Ip.c 中的描述，发送和接收应该使用不同的回调函数： FlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter0() 用于 FlexIO 通道 0/1 TX FlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter1() 用于 FlexIO 通道 0/1 RX BR，VaneB Re: S32K344 FlexIO I2C DMA 您好@VaneB 我找到了“单独处理最后一个接收到的字节”的代码。 然而，关于发送方面我还有一个疑问。使用中断驱动发送时，数据长度设置为 Size + 1。发送过程中，代码会检查是否是最后一个字节；如果是，则发送 0xFF 或 0x00。实际发送的数据长度仍然是 Size。但是，使用 DMA 发送时，DMA 会从发送缓冲区复制 Size + 1 个字节，并且在 Flexio_I2c_Ip_MasterEndDmaTransfer 函数中，也会将 0xFF 或 0x00 填充到 ShiftBuffer 中。这意味着实际发送的数据长度是 Size + 1，而不是 Size。这是为什么呢？ 1.png1.png1.png 2.png2.png2.png 我已将附件项目中所有出现的 TRANSFER_SIZE + 1 修改为 TRANSFER_SIZE (8)，并按说明修改了 DMA 中断回调。此外，我还禁用了 数据缓存。 在使用 DMA 进行 FlexIO I2C 发送时，我用示波器观察到，在 -Os 优化级别下，时钟信号正常，只有 8 个字节。然而，在 -O0 优化级别下，前 8 个字节的时钟信号正常，但在发送 ACK 之后，并没有按预期生成停止信号；相反，出现了一个额外的 1 位时钟脉冲。 3.jpg3.jpg3.jpg 对于通过 DMA 接收 FlexIO I2C 信号，LPI2C0 用作从设备发送 8 字节（0x10–0x17）。在 -O0 优化级别下，传输第 7 个字节时时钟信号异常，FlexIO 接收缓冲区仅包含 6 个字节（0x10–0x15）。 4.jpg4.jpg4.jpg 在 -Os 优化级别，传输第 8 个字节时时钟信号异常，FlexIO 接收缓冲区仅包含 7 个字节（0x10–0x16）。 5.jpg5.jpg5.jpg 以上所有问题均可可靠地重现。 Re: S32K344 FlexIO I2C DMA 嗨@Jason07 我认为关键在于 I2C 使用的是开漏信号传输： 逻辑 0 会主动将 SDA 拉低。 逻辑 1 释放 SDA，使上拉电阻将线路拉高。 由于 FlexIO 是一个可编程外设，而不是专用的 I2C 控制器，因此驱动程序必须通过控制加载到移位器中的位模式来生成 I2C 协议事件。 因此，最后的 0x00 和 0xFF 值不一定应被视为额外的有效载荷字节。相反，它们用于将 SDA 置于正确的状态以完成循环。 当 Master->SendStop == TRUE 时，驱动程序加载 0x00，强制 SDA 为低电平。当换挡器完成且 FlexIO 释放线路后，上拉电阻会使 SDA 变为高电平，而 SCL 已经为高电平，从而产生所需的停止条件（SDA：低电平 → 高电平，而 SCL 为高电平）。 当 Master>SendStop == FALSE 时，驱动程序加载 0xFF，这将保持 SDA 释放状态。上拉使 SDA 保持高电平，防止出现停止状态，并使总线准备好进行重复启动（SDA：高电平 → 低电平，而 SCL 为高电平）。 另外，我建议启用 DMA 优化模式。线程中提供了一个示例：示例 S32K344 FlexIO I2C 带 DMA 优化选项 S32DS 3.6.0 RTD 6.0.0 。 最后，您使用的是定制电路板还是EVB/FRDM？

S32K328 的 GMAC RX 中断 我使用的是 S32K328 的 GMAC，想使用中断方法从我的 PC 接收数据包。但发现了一些不同的现象： 1. 可以调用中断处理程序 GMAC0_CH0_RX_IRQHandler，并正常接收数据包。 2. PC 发送数据包后，GMAC0_CH0_RX_IRQHandler 被调用了数秒。 3. GMAC0_CH0_RX_IRQHandler 无法调用，且未收到数据包？ 原因可能是什么？如何解决这个问题？ Re: GMAC RX interrupt of S32K328 你好@zyt ， 感谢您分享配置信息。由于我没有 EB Tresos 设备，所以我根据提供的文件手动检查了 GMAC 的配置。 我将您的 Eth_43_GMAC 配置与一个可正常运行的 S32K358 GMAC 1G lwIP FreeRTOS 参考项目进行了比较。一个显著的区别是出口 FIFO 配置。在您的项目中，出口 FIFO 缓冲区长度配置为 128 字节，MTL 出口队列大小为 256 字节。而在参考项目中，出口 FIFO 缓冲区长度为 1536 字节，MTL 出口队列大小为 4096 字节。   如果您的应用程序发送任何帧或上层发送响应，则这种小型 TX/Egress 配置对于标准以太网帧来说可能过于有限，尤其是在 1G RGMII 模式下。请尝试增加以下数值：   - 将 EthCtrlConfigEgressFifoBufLenByte 设置为 1536 - 将 EthCtrlConfigMTLEgressQueueSizeInBytes 设置为 4096   对于 RX 路径，RX 缓冲区长度本身为 1536 字节，这看起来很合理。但是，您的 MTL Ingress 队列大小也是 1536 字节，而参考项目使用 4096 字节。因此，作为另一项测试，请尝试增加以下数值：   - 将 EthCtrlConfigMTLIngressQueueSizeInBytes 设置为 4096   另外，为了进行调试，请暂时启用接收所有模式。您当前的配置已禁用 PKT_FILTER_RECV_ALL，而参考项目已启用它。这有助于将 MAC 过滤从分析中排除。   此外，还有其他一些区别，例如EthEnableCacheManagement 和 EthCtrlReleaseResourceAfterReception，但这未必是错误的。   顺祝商祺！ 帕维尔 Re: GMAC RX interrupt of S32K328 你好： 我尝试过单播帧和广播帧，每帧之间的延迟是 1 秒，我觉得这速度已经够慢了。 现象相同，开始时没有 RxStatsDropEvents，但几帧后就会出现。 我的EB配置如附件所示，请帮忙检查一下是否方便您使用。 谢谢。 Re: GMAC RX interrupt of S32K328 你好@zyt ， RxStatsDropEvents 表明 GMAC 接收到了一些帧，但这些帧在接收路径中的某个地方被丢弃了。这可能与接收资源可用性、接收 FIFO/队列处理、描述符/缓冲区可用性、数据包过滤或上层接收处理有关。   请尝试以下检查：   1. 请从 PC 缓慢发送相同的单播帧，例如一次发送一帧或帧之间延迟较大，并比较测试前后的 RX 统计数据。如果 RxStatsDropEvents 不再增加，则问题可能与 RX 缓冲区回收、处理时间或来自 PC 的突发流量有关。   2. 请用广播帧重复测试，然后用精确到 GMAC 驱动程序中配置的 MAC 地址的单播帧重复测试。这有助于排除 MAC 地址/过滤问题。   请同时检查RGMII时钟和外设配置。作为参考，我在NXP社区发布了一个S32K358 GMAC示例： https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K358-GMAC-1G-lwIP-FreeRTOS-S32DS-3-6-1-RTD600/ta-p/2355872     请注意，此示例适用于 S32K358，而不是 S32K328，因此未经检查 S32K328 引脚排列和时钟配置，不得直接复制。但是，它可以作为整体时钟设置、Eth_43_GMAC 配置和 DCMRWF 寄存器解决方法的参考。   如果可以的话，能否也分享一下您压缩后的项目文件？如果没有该项目，很难确定丢包是由配置、RX 资源处理、队列路由还是应用程序接收路径引起的。 顺祝商祺！ 帕维尔 Re: GMAC RX interrupt of S32K328 你好： 我通过 RTD 函数 Eth_43_GMAC_GetRxStats 读取帧信息，看起来有丢帧事件。 zyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.pngzyt_0-1787017861198.png RX 流全部由 RTD 处理，如下所示，我没有修改。 GMAC0_CH0_RX_IRQHandler > GMAC_RxIRQHandler > Eth_43_GMAC_RxIrqCallback > Eth_43_GMAC_Receive 造成这种情况的原因可能是什么？谢谢。 Re: GMAC RX interrupt of S32K328 你好@zyt ， 谢谢你提供的详细信息。   请同时根据此帖检查 Pins/Clocks/device_init()： S32K358 - GMAC 时钟配置   从截图中可以看出，GMAC0 中断向量似乎已配置并映射到 RTD 处理程序，包括 GMAC0_CH_0_RX_IRQHandler。由于有时会进入此处理程序并接收到帧，因此基本的中断路由看起来并没有完全错误。   但是，在使用 AUTOSAR Eth_43_GMAC 驱动程序时，请同时检查底层 IRQ 处理程序之上的接收流程。RX 中断处理程序本身通常不是完整的应用程序级接收处理。应用程序或上层仍然需要调用预期的 Eth_43_GMAC 接收 API 流程，例如 Eth_43_GMAC_Receive()，以便从驱动程序读取接收到的帧，并通过配置的回调路径进一步传递。   请检查以下几点：   1. 请确认 Eth_43_GMAC_Receive() 是否在 RX 中断事件之后调用，或者根据您的应用程序设计，是否定期从您的主/任务上下文中调用。如果发生中断，但接收到的帧没有从 RX 缓冲区中被消耗，则后续帧可能无法按预期接收。   2. 请验证接收到的单播帧目标 MAC 地址是否与 GMAC 驱动程序中配置的 MAC 地址完全匹配。为了进行调试，您可以暂时启用接收所有/混杂模式，以排除 MAC 过滤作为原因。   3. 请检查使用的是哪个接收队列/FIFO。您的屏幕截图显示了 CH0、CH1 和 CH2 的 RX 中断处理程序。如果数据包过滤器或队列配置将帧路由到另一个 RX 队列，则应用程序必须使用相应的 FIFO 索引调用接收函数并正确处理该队列。   4. 请验证接收缓冲区/描述符的可用性。接收到帧并处理完毕后，驱动程序必须能够再次重用或获取 RX 缓冲区。如果接收缓冲区耗尽，第一帧可能被正确接收，但后面的帧可能会延迟或丢失。   5. 如果启用了缓存，请验证 GMAC 描述符和 RX 缓冲区是否放置在不可缓存的内存区域中，或者是否执行了所需的缓存维护。否则，CPU 可能会看到过时的描述符状态或过时的接收数据。   6. 由于帧是从 Python 脚本以单播帧的形式发送的，请通过 Wireshark 确认 PC 是否确实连续发送了具有预期目标 MAC 地址的帧。如果某些帧需要地址解析，或者目标地址无法按预期到达，则 PC 端可能会引入重试或延迟，这在 MCU 端可能看起来像是延迟的 RX 中断行为。   作为参考，我建议先将该项目与改编的 S32K3 Ethernet/lwIP 示例进行比较。这有助于确认 RGMII PHY 接口、时钟、MAC 地址和基本 RX 路径是否正常工作，然后再关注自定义 AUTOSAR Eth_43_GMAC 中断接收实现。   如果问题仍然存在，请分享应用程序的 Eth_43_GMAC 接收部分，特别是调用 Eth_43_GMAC_Receive() 的位置、RX FIFO 配置、MAC 地址/过滤器配置以及故障后的 GMAC DMA/MTL/MAC 状态寄存器。 贝茨致意， 帕维尔 Re: GMAC RX interrupt of S32K328 Hello： 1. I use RGMII 2. I use  RTD 6.0.0. 3. I use Eth_43_GMAC driver. 4. Interrupt is like below: zyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.pngzyt_0-1786962682804.png 5. I send unicast frames with python script. All the packages I send are the same, and GMAC0_CH0_RX_IRQHandler is from RTD which is the lowest handler like picture above. Re: GMAC RX interrupt of S32K328 你好@zyt ， 您能否提供更多关于您设备配置的详细信息？   1. 你在 S32K328 上使用的是哪个 MAC/PHY 接口，例如 MII、RMII 或 RGMII？ 2. 您使用的是哪个版本的S32K3 RTD？ 3. 您使用的是 AUTOSAR MCAL Eth_43_GMAC 驱动程序还是底层 GMAC IP 驱动程序？ 4. 能否分享一下相关的中断配置以及 GMAC0_CH0_RX_IRQHandler 的实现？ 5. PC 发送的是哪种类型的帧，例如 ping/ICMP、UDP、原始以太网帧、广播帧或单播帧？   作为参考测试，我还建议首先尝试使用修改后的 S32K3 Ethernet/lwIP 示例来重现该行为。这有助于将基本的 GMAC/PHY/时钟/配置问题与特定应用中断或 RX 缓冲区处理问题区分开来。     关于症状，如果 RX 中断有时会被调用，并且可以正确接收帧，则基本的 RX 路径可能至少部分有效。然而，这种不一致的行为仍然可能由以下几点之一造成：   - RX 缓冲区或描述符处理：在处理接收到的帧之后，必须将 RX 缓冲区/描述符返回给驱动程序/DMA。如果操作不当，RX 缓冲区可能变得不可用，并且进一步的 RX 中断可能会停止或变得不一致。   - 中断处理：请确保 RX 中断已配置为正确的 GMAC 通道，并且使用了预期的驱动程序中断处理程序/状态清除流程。如果中断状态未正确清除，则以下 RX 事件可能无法按预期报告。   - 缓存/内存一致性：如果启用了缓存，请验证 GMAC 描述符和 RX 缓冲区是否放置在合适的不可缓存内存区域中，或者是否执行了所需的缓存维护。否则，CPU 可能会看到过时的描述符状态或过时的接收数据。   - 数据包过滤/MAC 地址：为了调试目的，请尝试暂时启用接收所有/混杂模式。这有助于检查帧是否被 MAC 地址过滤器、VLAN 过滤器或其他数据包过滤器设置拒绝。   - 帧类型和 PC 行为：如果 PC 发送 ping 等 IP 流量，则在发送 ICMP 流量之前，第一个帧可能是 ARP 请求/回复。如果 ARP 解析失败或某些帧被过滤/丢弃，则中断可能会延迟几秒钟，因为 PC 会重新发送 ARP 或应用程序稍后重试。   - PHY 链路和时钟：请确认 PHY 链路是否正常，以及所选 MII/RMII/RGMII 接口所需的输入时钟是否存在且稳定。   请分享上述配置详情，如果可能，请提供故障发生后的 GMAC DMA/MTL/MAC 状态寄存器。这应该有助于确定问题是与中断配置、RX 描述符/缓冲区处理、数据包过滤还是外部 PHY/接口设置有关。 顺祝商祺！ 帕维尔 Re: GMAC RX interrupt of S32K328 你好@zyt ， 谢谢你的更新。我再次查看了您的文件，没有发现任何可疑之处。如果在增加 FIFO/队列资源后行为仍然没有改变，我不会盲目地继续更改配置参数。下一步应该是确定哪些帧实际被计为 RxStatsDropEvents。请检查丢包计数器是否仅在发送 Python 单播帧时增加，还是在没有 Python 流量运行时也会增加，因为 PC 端后台流量或过滤帧也可能影响 RX 统计信息。 贝茨致意， 帕维尔 Re: GMAC RX interrupt of S32K328 抱歉，我忘了你没有EB。 附件是修改后生成的文件。 Re: GMAC RX interrupt of S32K328 你好： 我按照您的建议进行了如下配置： zyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.pngzyt_0-1787045193851.png zyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.pngzyt_1-1787045222335.png zyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.pngzyt_2-1787045282610.png zyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.pngzyt_3-1787045358003.png EthCtrlReleaseResourceAfterReception 为灰色，无法修改，因为它仅在使用外部数据缓冲区时应用。 zyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.pngzyt_4-1787045508280.png 修改这些设置后，结果仍然一样，出现了 RxStatsDropEvents。 zyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.pngzyt_5-1787045605969.png 修改后的配置文件就像附件一样。 您还能提供一些建议吗？谢谢。 Re: GMAC RX interrupt of S32K328 你好： 根据我的测试，无论是广播帧还是单播帧都可能丢失，p现象相同，而且 PC 不会发送任何其他超出我控制范围的帧。 我发现一个特殊情况，有时当我发送帧时，RTD 函数 Gmac_Ip_ReadFrame 会进入以下分支： zyt_0-1787101369298.pngzyt_0-1787101369298.pngzyt_0-1787101369298.pngzyt_0-1787101369298.pngzyt_0-1787101369298.png 这是因为 (((Bd->Des3 & GMAC_RDES3_OWN_MASK) != 0U) zyt_1-1787101442166.pngzyt_1-1787101442166.pngzyt_1-1787101442166.pngzyt_1-1787101442166.pngzyt_1-1787101442166.png 函数调用流程如下所示，全部属于RTD驱动程序： zyt_2-1787101651452.pngzyt_2-1787101651452.pngzyt_2-1787101651452.pngzyt_2-1787101651452.pngzyt_2-1787101651452.png 此时，Eth_43_GMAC_Receive 将不会读取 GMAC 缓冲区的数据。 因此，一段时间后，GMAC 的 FIFO 已满，所以后来的帧将被丢弃。 你觉得我的分析有道理吗？ 如果是这样，为什么会发生 (((Bd->Des3 & GMAC_RDES3_OWN_MASK) != 0U)？原因可能是什么？ 谢谢。 Re: GMAC RX interrupt of S32K328 你好： 问题是由缓存引起的，当我从项目中删除宏 D_CACHE_ENABLE 时，一切就恢复正常了。 那是不是意味着缓存一致性问题？ 但是，当我添加 D_CACHE_ENABLE 并选中下面的复选框时，问题仍然存在。 zyt_2-1787215536381.pngzyt_2-1787215536381.pngzyt_2-1787215536381.pngzyt_2-1787215536381.png 我没有修改RTD的任何可变区域设置，并且我检查了RTD驱动程序，GMAC_0_Rx/TXRing_0_Desc/DataBuffer位于no_cache区域，但其他一些变量（例如Gmac_apxState）不在，而是在mcal_bss区域，而mcal_bss区域是缓存的。这合理吗？ zyt_4-1787215940789.pngzyt_4-1787215940789.pngzyt_4-1787215940789.pngzyt_4-1787215940789.png 那么，在添加了 D_CACHE_ENABLE 之后，该如何解决这个问题呢？ 谢谢。 Re: GMAC RX interrupt of S32K328 你好@zyt ， 感谢您提供的详细调试信息。你的观察很有用，但我对“OWN”这部分会有不同的解读。   当设置了 RDES3.OWN 时，RX 描述符归 DMA 所有，而不是归 CPU 所有。因此，Gmac_Ip_ReadFrame() 正确地报告 GMAC_STATUS_RX_QUEUE_EMPTY，因为当前描述符尚未完成并返回给软件。OWN = 1 的 RX 描述符通常可供 DMA 使用，因此仅凭此条件并不能表明 RX 环被阻塞或 GMAC FIFO 必须已满。   关键问题是，为什么在 RxCurrentDesc 指向仍由 DMA 拥有的描述符时，会进入 RX 中断回调。中断可能是由另一个 RX/DMA 状态条件引起的，或者已完成的描述符可能与当前的软件描述符指针不匹配。   生成的代码将 GMAC RX 描述符和 RX 数据缓冲区放入不可缓存的 MemMap 部分。但是，我在共享项目中没有看到链接器映射文件，因此我无法验证该部分是否真的映射到最终可执行文件中不可缓存的内存区域。   请问您能否分享一下构建过程中生成的链接器映射文件？我尤其想核对以下各项的最终地址和部分内容：   - GMAC_0_RxRing_0_DescBuffer - GMAC_0_RxRing_0_DataBuffer - GMAC_0_TxRing_0_DescBuffer - GMAC_0_TxRing_0_DataBuffer   请确认 GMAC_STATUS_RX_QUEUE_EMPTY 是在 RX 中断后的第一次 Gmac_Ip_ReadFrame() 调用时发生，还是仅在成功读取一个或多个帧后发生。OWN 位设置为 1 可能仅仅表示接收循环的正常结束，其中下一个描述符已被 DMA 拥有，并正在等待另一个帧。 顺祝商祺！ 帕维尔 Re: GMAC RX interrupt of S32K328 你好@zyt ， 谢谢你的更新。是的，移除 D_CACHE_ENABLE 后问题消失这一事实强烈表明存在缓存一致性或内存区域配置问题。   但是，Gmac_apxState 本身通常不需要放在不可缓存的内存中。它包含 CPU 端驱动程序状态和指针，但 GMAC DMA 不会直接访问它。CPU 和 GMAC DMA 之间共享的重要对象是硬件描述符环和 RX/TX 数据缓冲区。   我检查了之前共享的生成文件。在 Gmac_Ip_Cfg.h 中，生成的配置包含：   #define GMAC_HAS_CACHE_MANAGEMENT (STD_OFF)   同时，Gmac_Ip_Cfg.c将 GMAC RX/TX 描述符和数据缓冲区放入 NO_CACHEABLE MemMap 部分。因此，生成的配置似乎依赖于将这些对象映射到真正不可缓存的内存区域，而不是依赖于 GMAC 驱动程序的显式缓存维护。   启用 EthEnableCacheManagement 后，请重新生成完整的 RTD 配置并执行清理构建。然后请检查 Gmac_Ip_Cfg.h 文件中 GMAC_HAS_CACHE_MANAGEMENT 的值。实际编译的文件。如果仍然保持 STD_OFF 状态，则该复选框不会在生成的版本中启用底层 GMAC 缓存维护。   请同时分享链接器映射文件和相关的链接器/MPU内存区域配置。我们需要验证以下部分的最终内容和内存属性：   - GMAC_0_RxRing_0_DescBuffer - GMAC_0_RxRing_0_DataBuffer - GMAC_0_TxRing_0_DescBuffer - GMAC_0_TxRing_0_DataBuffer   生成的源代码将这些对象放入不可缓存的部分，但链接器脚本和 MPU 配置也必须将该部分映射到真正不可缓存的区域。否则，即使 DMA 已更新 RAM 中的描述符，CPU 也可能读取过时的缓存描述符值，例如 OWN = 1。   目前我不建议将 Gmac_apxState 移动到不可缓存的内存中。第一步是验证所有 DMA 共享描述符和缓冲区是否放置在正确的不可缓存 MPU 区域中，或者验证编译后的驱动程序配置中是否真正启用了 GMAC 缓存管理。 顺祝商祺！ 帕维尔

AMMCLib support for S32R294 e200z7 cores Hello NXP team, We are developing an application for the S32R294 and would like to use AMMCLib on its e200z7 cores. Is there an AMMCLib release that officially supports the S32R294? If not, could you recommend another NXP-provided math library that is compatible with the S32R294 e200z7 core? Please also let us know whether a specific S32 Design Studio toolchain, SDK, or RSDK version is required. Thank you. C|C++ Libraries Re: AMMCLib support for S32R294 e200z7 cores Hi Peter, Thank you for the clarification. Our target application is a radar signal-processing pipeline. We plan to run the following algorithms on the S32R294 e200z7 cores: DML-based direction-of-arrival estimation A small number of FFT operations Kalman filtering, including matrix multiplication, transposition, and linear-system solving or matrix inversion Feature extraction and lightweight radar target classification using vector, matrix, and statistical operations Running these algorithms on the e200z7 cores would reduce data transfers and data-format conversions between the SPT and e200z7, which should improve processing efficiency. We are looking for optimized FFT, complex arithmetic, matrix, vector, and linear algebra functions for the S32R294 e200z7 cores. Does NXP provide a suitable math or DSP library for these use cases?  Best regards, Re: AMMCLib support for S32R294 e200z7 cores Hello, There is not an AMMCLib release that officially supports the S32R294 platform. The AMMCLib device support list currently includes several Power Architecture MCU families (for example MPC577xK/MPC5775E), but S32R294 is not listed as a supported target. For S32R294 development, NXP's primary software offering is the Radar SDK for S32R29x together with the S32 Design Studio Power Architecture toolchain. What should be the target application? Best regards, Peter

NXPはユーザーにPlug and TrustミドルウェアとMBED TLSをどのように統合することを期待しているのでしょうか? NXPはユーザーにPlug & Trustミドルウェアに付属しているMbed TLSのバージョンを使うことを期待しているのでしょうか?もしそうなら、NXPは新しいMbedのTLSバージョンを含む更新されたミドルウェアリリースをタイムリーに提供しているのでしょうか?例えば、現在のミドルウェアバンドルにはMbed TLS 3.6.2が含まれています。Mbed TLS 3.6.7は既に利用可能ですが。 SE050 Re: How Does NXP Expect Users to Integrate Mbed TLS with the Plug & Trust Middleware? こんにちは、@ph-yac さん。 ご連絡ありがとうございます！私の意見は以下の通りです。 Plug & Trust MWはMCUXpresso SDKの下流からMbed TLSを供給し、アップデートはNXPのH1/H2 SDKリリーススケジュールに従って行われ、すべての上流Mbed TLSパッチリリースを追跡するわけではありません。現在同梱されているバージョンは3.6.2です。次のアップデートでは、次のSDKのダウンストリームリリースサイクルが導入されます。 ミドルウェアはバンドルされたバージョンに対して正式に検証されていますが、同じ 3.6.x 内のパッチレベルのアップグレードではLTS支店は一般的にリスクが低い。お客様は、バンドルされたMbedのTLSソースファイルを手動で置き換えることを試みることができます。ビルド互換性は'SSS_HAVE_MBEDTLS_3_X' CMakeフラグで確認してください。NXPは、MWリリース間のすべてのパッチリリースを正式に検証するわけではありません。 最新のMWはMbed TLS 2.28.xと3.6.xの両方をサポートしています`SSS_HAVE_MBEDTLS_2_X` / `SSS_HAVE_MBEDTLS_3_X` CMakeフラグを介して分岐します。Mbed TLS 3.x と統合する場合は、**SSS ALT**（PSA ALT ではありません）を使用する必要があることにご注意ください。 Plug & Trust ミドルウェアにおけるMbed TLS 4.xのサポートは、2027年Q1のリリースに向けて現在検討されています。正式な約束はまだなされていないが、ロードマップには含まれている。 お役に立てば幸いです。 すてきな一日を、 カン ------------------------------------------------------------------------------- 注記： この投稿があなたの質問への回答になっている場合は、「正解としてマーク」ボタンをクリックしてください。ありがとうございます! - 前回の投稿から7週間Threadをフォローしており、その後の返信は無視しています もし後で関連する質問があれば、新しいThreadを開き、閉じたThreadを参照してください。 -------------------------------------------------------------------------------

imx8mp-evk SAI5 external I2S mic (SPH0645) - clock derivation fails, need help with correct clock Hello, Board: i.MX8MPLUSLPD4-EVK (8MPLUS-BB base board)   attach an external I2S MEMS microphone (Knowles SPH0645LM4H) to SAI5, using the SoC-side pins that are physically routed to the J21 (EXP_CN) expansion header via level shifters U57/U58, per the base board schematic (SPF-46370).   1. Hardware wiring (confirmed against schematic, verified on scope)   SPH0645 BCLK -> J21 pin 40 ("PDM_CLK",      SoC pad SAI5_RXC) SPH0645 LRCL -> J21 pin 32 ("PWM4_3V3",     SoC pad SAI5_RXFS) SPH0645 DOUT -> J21 pin 38 ("PDM_STREAM_0", SoC pad SAI5_RXD0) SPH0645 SEL  -> GND (left channel) SPH0645 3V   -> J21 pin 1 SPH0645 GND  -> J21 pin 6   We are trying to connect an external I2S MEMS microphone (SPH0645) to SAI5, wired to the J21 expansion header (BCLK -> SAI5_RXC, LRCL -> SAI5_RXFS, DOUT -> SAI5_RXD0, confirmed against the 8MPLUS-BB schematic and verified on oscilloscope).   We are facing this issue and need help resolving it:   The sound card registers correctly:   root@imx8mp-lpddr4-evk:~# arecord -l card 2: sph0645audio [sph0645-audio], device 0: ...   But recording fails with a clock error:   root@imx8mp-lpddr4-evk:~# arecord -D hw:CARD=sph0645audio,DEV=0 \     -f S16_LE -r 48000 -c 1 mic.wav [  140.950940] fsl-sai 30c50000.sai: failed to derive required Rx rate: 3072000 [  140.958042] fsl-sai 30c50000.sai: ASoC: error at snd_soc_dai_hw_params on 30c50000.sai: -22 arecord: set_params:1435: Unable to install hw params   Checking clk_summary shows sai5 is still deriving from the 24MHz oscillator rather than the audio PLL:   sai_pll_out_div2      0  0  50000  Y   0  0  0  24576000 sai5                  0  0  50000  N   0  0  0  24000000 sai5_root             0  0  50000  N   0  0  0  24000000   Our current &sai5 node:   &sai5 { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai5>; assigned-clocks = <&clk IMX8MP_CLK_SAI5>; assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; assigned-clock-rates = <12288000>; fsl,sai-mclk-direction-output; fsl,sai-asynchronous; fsl,dataline = <0 0x1 0x0>; status = "okay"; };   pinctrl_sai5: sai5grp { fsl,pins = < MX8MP_IOMUXC_SAI5_RXFS__AUDIOMIX_SAI5_RX_SYNC 0xd6 MX8MP_IOMUXC_SAI5_RXC__AUDIOMIX_SAI5_RX_BCLK 0xd6 MX8MP_IOMUXC_SAI5_RXD0__AUDIOMIX_SAI5_RX_DATA00 0xd6 >; };   We also disabled &micfil and &pwm4, since their pinctrl groups share the same physical pads as SAI5_RXC/RXD0/RXFS on this board.   How do we correctly route SAI5's clock through the audio PLL so it can derive 3072000 Hz (48kHz) instead of sitting on the 24MHz oscillator path?    Also attached the some images for your reference.    Thank you. IMG_8200.jpegIMG_8200.jpeg IMG_8205.jpegIMG_8205.jpeg    preview.jpgpreview.jpg preview (1).jpgpreview (1).jpg    Re: imx8mp-evk SAI5 external I2S mic (SPH0645) - clock derivation fails, need help with correct cloc Hello, I suggest you try with the next configuration: &sai5 { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai5>; assigned-clocks = <&clk IMX8MP_CLK_SAI5>; assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; assigned-clock-rates = <12288000>; clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI5_IPG>, <&clk IMX8MP_CLK_DUMMY>, <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI5_MCLK1>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_AUDIO_PLL1_OUT>, <&clk IMX8MP_AUDIO_PLL2_OUT>; clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k"; fsl,sai-asynchronous; fsl,dataline = <0 0x1 0x0>; status = "okay"; }; Without the clocks/clock-names binding, the driver falls back to the 24 MHz oscillator. Also, there is no need of fsl,sai-mclk-direction-output property if you are not connecting it to the microphone. Best regards.

How Does NXP Expect Users to Integrate Mbed TLS with the Plug & Trust Middleware? Does NXP expect users to use the version of Mbed TLS bundled with the Plug & Trust Middleware? If so, does NXP provide updated middleware releases containing newer Mbed TLS versions in a timely manner? For example, the current middleware bundles Mbed TLS 3.6.2, although Mbed TLS 3.6.7 is already available. SE050 Re: How Does NXP Expect Users to Integrate Mbed TLS with the Plug & Trust Middleware? Hi @ph-yac , Thanks for the reaching out! Please have my comments as below: The Plug & Trust MW sources Mbed TLS from the MCUXpresso SDK downstream, and updates follow NXP's H1/H2 SDK release schedule rather than tracking every upstream Mbed TLS patch release. The currently bundled version is 3.6.2, and the next update will come with the next SDK downstream release cycle. The middleware is formally validated against the bundled version, but patch-level upgrades within the same 3.6.x LTS branch are generally low-risk. Customers are welcome to attempt replacing the bundled Mbed TLS source files manually; just verify build compatibility using the `SSS_HAVE_MBEDTLS_3_X` CMake flag. NXP does not formally validate every patch release between MW releases. The latest MW supports both Mbed TLS 2.28.x and 3.6.x branches via the `SSS_HAVE_MBEDTLS_2_X` / `SSS_HAVE_MBEDTLS_3_X` CMake flags. Please note that **SSS ALT** (not PSA ALT) should be used when integrating with Mbed TLS 3.x. Support for Mbed TLS 4.x in the Plug & Trust Middleware is currently being considered for a Q1 2027 release. No formal commitment has been made yet, but it is on the roadmap. Hope that helps, Have a great day, Kan ------------------------------------------------------------------------------- Note: - If this post answers your question, please click the "Mark Correct" button. Thank you! - We are following threads for 7 weeks after the last post, later replies are ignored Please open a new thread and refer to the closed one, if you have a related question at a later point in time. -------------------------------------------------------------------------------

S32K344 FlexIO I2C DMA こんにちは、 S32K344のFlexIO I2C DMAに関していくつか質問がありますので、ご意見をいただければ幸いです。 1. FlexIOを使用してI2Cをエミュレートする場合、Txの長さは次のように設定されます。 サイズ+1 。これは 「送信シフターは、SCLピンの最後の立ち下がりエッジで追加のワードを1つロードします」 ？ 1.png1.png1.png1.png 2.png2.png2.png2.png 2. DMAを使用してデータを送信する場合、 メジャーループ数 また、 サイズ + 1。これは同じ理由ですか? DMA を使用する場合、送信されるすべてのデータは Master->TxDataを呼び出すとき Flexio_I2c_Ip_MasterSendData 、 送信バッファ 長さは サイズ + 1 、最後のバイトは 0xFF または 0x00 ? 3.png3.png3.png3.png 3. データを受信するには、 メジャーループ数 設定されています サイズ – 1。なぜでしょうか？ 4. S32K344でこれをテストしたところ、FlexIO I2CでDMAを使用してデータを受信すると、受信データが予想より1バイト少ないことがわかりました。オシロスコープで観測すると、最後のバイトのクロック信号には、わずか5～6ビット程度の波形しか見られない。S32K312での同じテストは問題なく動作します。 S32K344 S32DS3.6.4 RTD700   BR、 ジェイソン Re: S32K344 FlexIO I2C DMA こんにちは、 @Jason07さん FlexIOは専用のI2Cペリフェラルではないため、その実装にはI2Cバスシーケンスを正しく完成させるための追加の内部手順が必要です。 伝送における「サイズ + 1U」は、FlexIOがI2Cフレームシーケンスを完了するために必要な最終的なシフター負荷に関連しています。この追加転送は、追加のペイロードバイトを表すものではありません。その代わりに、FlexIOハードウェア内部で最終的なクロックパルスを生成し、バスを正しく転送終了状態に移行させるために使用されます。 受信時のサイズ指定（-1U）が必要なのは、最後に受信したバイトが個別に処理されるためです。これにより、運転者は必要なNACKおよびSTOP条件を適切なタイミングで生成できます。 また、DMA転送モードを使用する場合、データ転送はキャッシュの一貫性の問題によって影響を受ける可能性があることを考慮してください。Dキャッシュが有効になっている場合に発生する可能性のある問題を回避するため、DMA TCDの送信元および送信先として使用されるバッファは、キャッシュ不可能なメモリ領域に割り当てられていることを確認してください。 Flexio_I2c_Ip_MasterReceiveData() 関数を呼び出す際に、TRANSFER_SIZE パラメータを増やす必要はありません。ドライバーは受信シーケンスの必要な内部調整をすでに処理しています。 最後に、あなたの設定を確認していると、両方のDMAチャネルに同じDMA割り込みコールバックが割り当てられていることに気づきました。Flexio_I2c_Ip.cに記載されている説明によると、送信と受信には異なるコールバック関数を使用する必要があります。 FlexIOチャンネル0/1 TX用のFlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter0() FlexIOチャンネル0/1 RX用のFlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter1() BR、VaneB Re: S32K344 FlexIO I2C DMA こんにちは、@ VaneBさん 「最後に受信したバイトは個別に処理される」というコードを見つけました。 しかし、送信に関してまだ疑問があります。割り込み駆動送信を使用する場合、長さはサイズ+1に設定されます。送信時にコードはそれが最後のバイトかどうかをチェックします。もしそうなら、0xFFか0x00を送ります。実際に送信されるデータの長さは依然としてサイズです。しかしDMAで送信を行う場合、DMAは送信バッファからサイズ+1バイトをコピーし、Flexio_I2c_Ip_MasterEndDmaTransfer関数ではShiftBufferに0xFFまたは0x00も埋めます。つまり、実際に送信されるデータ長はサイズではなくサイズ+1です。なぜでしょうか? 1.png1.png1.png 2.png2.png2.png 添付のプロジェクト内のTRANSFER_SIZE + 1のすべての箇所をTRANSFER_SIZE (8)に変更し、説明されているとおりDMA割り込みコールバックも変更しました。また、Dキャッシュも無効にしました。 FlexIO I2C送信にDMAを使用する際、オシロスコープで観察したところ、-Os最適化レベルではクロック信号は8バイトのみで正常でした。しかし、-O0最適化レベルでは、最初の8バイトのクロックは正常でしたが、ACK送信後に期待どおりストップ信号が生成されず、代わりに1ビットの余分なクロックパルスが現れました。 3.jpg3.jpg3.jpg FlexIO I2C を DMA 経由で受信する場合、LPI2C0 はスレーブとして使用され、8 バイト (0x10～0x17) を送信します。-O0最適化レベルでは、7バイト目の送信中にクロック信号が異常になり、FlexIO受信バッファには6バイト（0x10～0x15）しか含まれません。 4.jpg4.jpg4.jpg -Os最適化レベルでは、8バイト目の送信中にクロック信号が異常になり、FlexIO受信バッファには7バイト（0x10～0x16）しか含まれません。 5.jpg5.jpg5.jpg 上記の問題はすべて確実に再現可能です。 Re: S32K344 FlexIO I2C DMA こんにちは、 @Jason07さん 重要な点は、I2Cがオープンドレイン信号方式を採用していることだと思います。 論理0はSDAを積極的にローに引き下げます。 論理値1はSDAを解放し、プルアップ抵抗によってラインがハイレベルに駆動される。 FlexIOは専用のI2Cコントローラではなくプログラム可能な周辺機器であるため、ドライバはシフターに読み込まれるビットパターンを制御してI2Cプロトコルイベントを生成しなければなりません。 このため、末尾の0x00と0xFFの値は、必ずしも追加のペイロードバイトとみなすべきではありません。むしろ、それらはSDAを適切な状態に配置し、ルーチンを完了させるために使用される。 Master->SendStop == TRUEの場合、ドライバーは0x00をロードし、SDAを強制的に低くなります。シフターの処理が完了し、FlexIOがラインを解放すると、プルアップによってSDAがハイになり、SCLは既にハイになっているため、必要な停止条件（SDA：LOW → HIGH、SCLはHIGH）が生成されます。 Master->SendStop == FALSEの場合、ドライバーは0xFFをロードし、SDAは解放されたままになります。プルアップによりSDAがハイレベルに維持され、停止状態が防止され、バスは繰り返し始動（SCLがハイレベルの間、SDA：ハイレベル→ローレベル）の準備が整います。 また、DMA最適化モードを有効にすることをお勧めします。例はスレッドにあります: S32K344 DMA Optimize オプション S32DS 3.6.0 RTD 6.0.0 を用いた FlexIO I2C の例。 最後に、カスタムボードを使用していますか、それともEVB/FRDMを使用していますか？

DESFire EV3 NDA電子署名リクエストが送信されませんでした MIFARE DESFire EV3のNDA承認されましたが、Adobe Signのリクエストは届かず、サポートがNXP契約へのエスカレーションを拒否しています(ケース00996763) こんにちは、 NXP側の技術的な理由で停滞しているNDAプロセスを終わらせるのを手伝ってくれる方を探しています。 バックグラウンド: 私はチェコ共和国のソフトウェア開発者で、MIFARE DESFire EV3(MF3DHx3)をベースにしたクローズドループNFC決済拡張機能を備えたモバイルPOSアプリケーション(Android/iOS)を開発しています。DocStoreからEV3の機密ドキュメント(完全なデータシート/コマンドセット、セキュアメッセージング、キーマネジメント)が必要です。 2026年8月1日にNXPのオンラインプロセス(サポートケース#00996763)を通じてNDA申請を提出しました。 8月1日から7日の間に、NXPのコンプライアンス要求に応じたすべての書類を提出しました:会社ウェブサイト、公式取引登録簿、所有構造、詳細なプロジェクト説明、ボリューム、設計段階、最終用途。 8月12日、NXPテクニカルサポートはNDAが承認され、NXP Contracts/Adobe Acrobat Signを通じて私の署名メールに送信されたことを確認しました。8月18日、彼らは2回目の電子署名リクエストを確認した。 問題： Adobe Signのリクエストはどちらも届きませんでした。受信トレイにも、迷惑メールフォルダにも、Adobe Signアカウントにも見当たらず、そして最も重要なことに、Microsoft 365 Exchangeのメッセージ追跡記録には、当該期間全体を通してadobesign.com / echosign.comからの配信試行の痕跡が一切残っていない。トランザクションは私のメールサーバーに到達する前に失敗します。 技術サポートは「セキュリティ上の理由からファイルの再送信はできません」と言い、「メールアドレスの確認はこれ以上できない」と言い、認可された代理店を通じてやり直すように言われました。Adobe Sign取引を確認して新しい契約を発行してもらうため、単にNXPコントラクトに案件を転送する(またはNDAをPDF形式で送って手書き署名を求める)という要請は、まだ対応されていません。 問題のメールアドレスは私のドメイン内の唯一の事業用アドレスであり、この件では他のすべてのやり取り、[email protected] からのすべてのメールも有効です。 私が求めているもの： NXP Contracts、MIFARE製品チーム、またはAdobe Sign監査記録にアクセスできる方がいれば、ケース#00996763を見て、eSignの再発行か、別のフォームでNDAを提出していただけませんか?デューデリジェンス審査は完了し承認されました。残っているのは書類1点のみです。 適切なお問い合わせのヒントをいただけると大変ありがたいです。ありがとう。 ペトル・ザフラドニク チェコ共和国 Re: DESFire EV3 NDA eSign request never delivered こんにちは、エドゥアルドさん。 ご返信ありがとうございます。理解していますし、NDAのチケットを続けたいと思います。問題はチケットが事実上閉じられていることです。 テクニカルサポートは2度「オンラインは進めない」と返答し、代理店を通じてやり直すように言われており、法務・契約チームへの転送の要請も対応されていません。 そこでお願いはこれだけです:ケース番号00996763を内部の法務チームに渡していただけますか?Adobe Signの取引が見られる誰かに確認してもらえますか?秘密保持契約は8月12日に承認されましたが、電子署名依頼が私の手元に届きませんでした（メールサーバーの追跡記録にも配信試行の記録が全くありません）。電子署名依頼を再発行するか、手書き署名用のPDF形式のNDAを提供すれば、すぐに解決するでしょう。 このThreadを参照したチケットにメモを追加します。ありがとう。 ペトル Re: DESFire EV3 NDA eSign request never delivered こんにちは、 @clexpert さん。 あなたの調子が良いといいのですが。 申し訳ありませんが、NDAの話題を扱う適切な方法ではありません。すべての手続きは、 NDAオンラインフォームの発行後、当社の法務チームが担当します。 処理状況に関する詳細については、NDAチケットで引き続きお問い合わせください。 よろしくお願いいたします。 エドゥアルド。 Re: DESFire EV3 NDA eSign request never delivered こんにちは、エドゥアルドさん。 改めてありがとうございました。あなたのアドバイスに従い、NDAチケット(CASE 00996763)を継続し、あなたが言ったように法務・契約チームに案件を転送するよう明確にお願いしました。彼らがこれらの案件を担当しています。 今日受け取った唯一の返信は、3回目の一行だけのメッセージでした:「NDAの作成についてはNXP代理店にご連絡ください。」法務部への転送もなく、Adobe Signの納品失敗に関するコメントもなく、私が問い合わせた監査証跡への言及もなかった。 3週間経過した現状をまとめると以下のようになります。 秘密保持契約書は8月12日に審査、承認され、発行されました。 - 2件のAdobe Signリクエストがメールサーバーに届かなかった(完全なメッセージトレースで確認され、配達の試みは全くありません)。 - 技術サポートは再発行できず、代理店のアドバイスを繰り返すのみです。 - 私は並行して認可された代理店に連絡し、待っています。 法務・契約部への内部引き継ぎを自分で行ってもらえるか、直接連絡先を教えていただけますか?既に承認済みの秘密保持契約書を、再発行された電子署名リクエスト、または手書き署名用のPDFファイルとして送付していただきたいです。私は建設的なトーンを保っています。ただ、これで行動できる誰かに届くことが欲しいのです。 ありがとう。 ペトル

imx8mp-evk SAI5 外置 I2S 麦克风 (SPH0645) - 时钟推导失败，需要正确的时钟帮助 你好， 主板：i.MX8MPLUSLPD4-EVK（8MPLUS-BB底板）   将外部 I2S MEMS 麦克风（Knowles SPH0645LM4H）连接到 SAI5， 使用物理连接到 J21 (EXP_CN) 的 SoC 端引脚 根据底板原理图，通过电平转换器 U57/U58 连接扩展接口。 （SPF-46370）   1. 硬件接线（已对照原理图确认，并用示波器验证）   SPH0645 BCLK -> J21 引脚 40 ("PDM_CLK", SoC 焊盘 SAI5_RXC) SPH0645 LRCL -> J21 引脚 32 ("PWM4_3V3",     SoC 焊盘 SAI5_RXFS) SPH0645 DOUT -> J21 引脚 38 ("PDM_STREAM_0", SoC 焊盘 SAI5_RXD0) SPH0645 SEL -> GND（左声道） SPH0645 3V -> J21 引脚 1 SPH0645 GND -> J21 引脚 6   我们正在尝试将外部 I2S MEMS 麦克风 (SPH0645) 连接到 SAI5，连接到 J21 扩展接头（BCLK -> SAI5_RXC，LRCL -> SAI5_RXFS，DOUT > SAI5_RXD0，已根据 8MPLUS-BB 原理图确认 并在示波器上进行了验证）。   我们遇到了这个问题，需要帮助解决：   声卡识别正常：   root@imx8mp-lpddr4-evk:~# arecord -l 卡 2：sph0645audio [sph0645-audio]，设备 0：...   但录制失败，出现时钟错误：   root@imx8mp-lpddr4-evk:~# arecord -D hw:CARD=sph0645audio,DEV=0 \ -f S16_LE -r 48000 -c 1 mic.wav [ 140.950940]fsl-sai 30c50000.sai：未能得出所需的处方费率：3072000 [ 140.958042]fsl-sai 30c50000.sai：ASoC：30c50000.sai 上的 snd_soc_dai_hw_params 出错：-22 arecord: set_params:1435: 无法安装硬件参数   检查 clk_summary 显示 sai5 仍然使用 24MHz 的频率。 振荡器而不是音频锁相环：   sai_pll_out_div2      0  0  50000  Y   0  0  0  24576000 sai5 0 0 50000 N 0 0 0 24000000 sai5_root 0 0 50000 N 0 0 0 24000000   我们当前的 &sai5 节点：   &sai5 { #sound-dai-cells = <0> pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai5>; 已分配时钟 = <&clk IMX8MP_CLK_SAI5>; assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT> 分配的时钟速率 = <12288000>; fsl，sai-mclk-direction-output； fsl，sai-异步； fsl,dataline = <0 0x1 0x0>; 状态 = "好的" };   pinctrl_sai5：sai5grp { fsl，pins = < MX8MP_IOMUXC_SAI5_RXFS__AUDIOMIX_SAI5_RX_SYNC 0xd6 MX8MP_IOMUXC_SAI5_RXC__AUDIOMIX_SAI5_RX_BCLK 0xd6 MX8MP_IOMUXC_SAI5_RXD0__AUDIOMIX_SAI5_RX_DATA00 0xd6 > };   我们还禁用了 &micfil 和 &pwm4，因为它们的 pinctrl 组共享 本主板上与 SAI5_RXC/RXD0/RXFS 具有相同的物理焊盘。   我们如何正确地将SAI5的时钟信号通过音频PLL进行路由，使其能够…… 导出 3072000 Hz (48kHz) 的频率，而不是使用 24MHz 的振荡器。 小路？   另附几张图片供您参考。   谢谢。 IMG_8200.jpegIMG_8200.jpeg IMG_8205.jpegIMG_8205.jpeg    preview.jpg预览.jpg preview (1).jpg预览 (1).jpg    Re: imx8mp-evk SAI5 external I2S mic (SPH0645) - clock derivation fails, need help with correct cloc 你好， 我建议您尝试以下配置： &sai5 { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai5>; assigned-clocks = <&clk IMX8MP_CLK_SAI5>; assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; assigned-clock-rates = <12288000>; clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI5_IPG>, <&clk IMX8MP_CLK_DUMMY>, <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI5_MCLK1>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_CLK_DUMMY>, <&clk IMX8MP_AUDIO_PLL1_OUT>, <&clk IMX8MP_AUDIO_PLL2_OUT>; clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k"; fsl,sai-asynchronous; fsl,dataline = <0 0x1 0x0>; status = "okay"; }; 如果没有时钟/时钟名称绑定，驱动程序将回退到 24 MHz 振荡器。另外，如果您没有将麦克风连接到它，则不需要fsl,sai-mclk-direction-output属性。 顺祝商祺！

S32R294 e200z7コアのAMMCLibサポート NXPチームの皆様、こんにちは。 私たちはS32R294向けのアプリケーションを開発しており、AMMCLibをe200z7コアで使用したいと考えています。 公式にS32R294をサポートするAMMCLibのリリースはありますか?もしそうでなければ、NXPが提供する他の、S32R294 e200z7コアに対応した数学ライブラリをおすすめしてもらえますか? また、特定のS32 Design Studioツールチェーン、SDK、またはRSDKのバージョンが必要かどうかもご案内ください。 よろしくお願いします。 C|C++ライブラリ Re: AMMCLib support for S32R294 e200z7 cores こんにちは、ピーターさん。 ご説明いただきありがとうございます。 私たちの対象アプリケーションはレーダー信号プロセッシングパイプラインです。S32R294 e200z7コア上で、以下のアルゴリズムを実行する予定です。 DMLベースの到来方向推定 少数のFFT演算 カルマンフィルタリング(マトリックス乗算、転置、線形系解法またはマトリックス反転を含む) ベクトル、行列、統計演算を用いた特徴抽出および軽量レーダー目標分類 これらのアルゴリズムをe200z7コアで実行することで、SPTとe200z7間のデータ転送やデータフォーマット変換が減少し、プロセッシング効率が向上します。 S32R294 e200z7コア向けに最適化されたFFT、複素算術、マトリックス、ベクトル、線形代数関数を探しています。NXPはこれらの用途に適した数学やDSPライブラリを提供していますか? よろしくお願いいたします。 Re: AMMCLib support for S32R294 e200z7 cores こんにちは、 S32R294プラットフォームを公式にサポートするAMMCLibのリリースはありません。 AMMCLibデバイスのサポートリストには現在、いくつかのPower Architecture MCUファミリ(例:MPC577xK/MPC5775E)が含まれていますが、S32R294はサポート対象としては記載されていません。 S32R294開発向けに、NXPの主なソフトウェアはS32R29x用のレーダー SDKsとS32 Design Studio Power Architectureツールチェーンです。 ターゲットとなるアプリケーションは何でしょうか? よろしくお願いいたします。 ピーター

S32K344 FlexIO I2C DMA Hello, I have some questions regarding the FlexIO I2C DMA  on S32K344, and I would appreciate your insights. 1. When using FlexIO to emulate I2C, the Tx length is set to Size + 1. Is this because "The transmit shifter loads one additional word on the last falling edge of the SCL pin"? 1.png1.png1.png1.png 2.png2.png2.png2.png 2. When using DMA for sending data, the MAJORLOOP_COUNT is also set to Size + 1. Is this for the same reason? When using DMA, all transmitted data comes from Master->TxData. When calling Flexio_I2c_Ip_MasterSendData, should the TxBuff length be Size + 1, and should the last byte be 0xFF or 0x00? 3.png3.png3.png3.png 3. For receiving data, the MAJORLOOP_COUNT is set to Size – 1. Why is this? 4. I tested this on the S32K344 and found that when using DMA for FlexIO I2C receiving data, the received data is one byte less than expected. Observing with an oscilloscope, the clock signal for the last byte shows only about five or six bits of waveform. The same test on the S32K312 works fine. S32K344 S32DS3.6.4 RTD700   BR, Jason Re: S32K344 FlexIO I2C DMA Hi @Jason07  As FlexIO is not a dedicated I2C peripheral, its implementation requires additional internal steps to complete the I2C bus sequence correctly. The Size + 1U in the transmission is related to the final shifter load required by FlexIO to complete the I2C frame sequence. This additional transfer does not represent an extra payload byte. Instead, it is used internally by the FlexIO hardware to generate the final clock pulses and correctly transition the bus to the end-of-transfer state. The Size - 1U in the reception is necessary because the last received byte is handled separately. This allows the driver to generate the required NACK and STOP conditions at the correct time. Also, take into consideration that when using DMA transfer mode, data transfers may be affected by cache coherency issues. To avoid potential problems when D-Cache is enabled, ensure that the buffers used as the source and destination of the DMA TCD are allocated in a non-cacheable memory region. There is no need to increase the TRANSFER_SIZE parameter when calling the Flexio_I2c_Ip_MasterReceiveData() function. The driver already handles the required internal adjustments for the receive sequence. By last, while reviewing your configuration, I noticed that the same DMA interrupt callback has been assigned to both DMA channels. According to the descriptions provided in Flexio_I2c_Ip.c, different callbacks should be used for the transmit and receive: FlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter0() for the FlexIO Channel 0/1 TX FlexIO_I2c_Ip_DmaTransferCompleteNotificationShifter1() for the FlexIO Channel 0/1 RX BR,VaneB Re: S32K344 FlexIO I2C DMA Hi@VaneB I found the code where “the last received byte is handled separately”. However, I still have a question regarding sending. When using interrupt‑driven sending, the length is set to Size + 1. During sending, the code checks whether it is the last byte; if so, it sends 0xFF or 0x00. The actual sent data length is still Size. But when using DMA for sending, the DMA copies Size + 1 bytes from the send buffer, and in the Flexio_I2c_Ip_MasterEndDmaTransfer function, it also fills 0xFF or 0x00 into the ShiftBuffer. This means the actual sent data length is Size + 1, not Size. Why? 1.png1.png1.png 2.png2.png2.png I modified all occurrences of TRANSFER_SIZE + 1 in the attached project to TRANSFER_SIZE (8), and also modified the DMA interrupt callback as described. I also disabled the D‑Cache. When using DMA for FlexIO I2C sending, I observed with an oscilloscope that at -Os optimization level, the clock signal is normal with only 8 bytes. However, at -O0 optimization level, the clock for the first 8 bytes is normal, but after the ACK is sent, the stop signal is not generated as expected; instead, an extra 1‑bit clock pulse appears. 3.jpg3.jpg3.jpg For FlexIO I2C receiving via DMA, LPI2C0 is used as a slave to send 8 bytes (0x10–0x17). At -O0 optimization level, the clock signal becomes abnormal during the transmission of the 7th byte, and the FlexIO receive buffer contains only 6 bytes (0x10–0x15). 4.jpg4.jpg4.jpg At -Os optimization level, the clock signal becomes abnormal during the transmission of the 8th byte, and the FlexIO receive buffer contains only 7 bytes (0x10–0x16). 5.jpg5.jpg5.jpg All of the above issues are reliably reproducible. Re: S32K344 FlexIO I2C DMA Hi @Jason07  I think the key point is that I2C uses open-drain signaling: Logical 0 actively pulls SDA low. Logical 1 releases SDA, allowing the pull-up resistor to drive the line high. Since FlexIO is a programmable peripheral rather than a dedicated I2C controller, the driver must generate I2C protocol events by controlling the bit patterns loaded into the shifters. Because of this, the final 0x00 and 0xFF values should not necessarily be considered additional payload bytes. Instead, they are used to place SDA in the correct state to complete the rotine. When Master->SendStop == TRUE, the driver loads 0x00, forcing SDA low. Once the shifter finishes and FlexIO releases the line, the pull-up brings SDA high while SCL is already high, creating the required STOP condition (SDA: LOW → HIGH while SCL is HIGH). When Master->SendStop == FALSE, the driver loads 0xFF, which keeps SDA released. The pull-up keeps SDA high, preventing a STOP condition and leaving the bus ready for a Repeated START (SDA: HIGH → LOW while SCL is HIGH). Also, I recommend enabling the DMA Optimize mode. An example is available in the thread: Example S32K344 FlexIO I2C with DMA Optimize option S32DS 3.6.0 RTD 6.0.0. By last, Are working with a custom board or an EVB/FRDM?

DESFire EV3 NDA eSign request never delivered MIFARE DESFire EV3 NDA approved but Adobe Sign request never delivered – support refuses to escalate to NXP Contracts (case 00996763) Hello, I am looking for someone at NXP who can help me finish an NDA process that is stuck for purely technical reasons on NXP's side. Background: I am a software developer in the Czech Republic building a mobile POS application (Android/iOS) with a closed-loop NFC payment extension based on MIFARE DESFire EV3 (MF3DHx3). I need the confidential EV3 documentation (full data sheet / command set, secure messaging, key management) from DocStore. On 1 August 2026 I submitted an NDA request through the NXP online process (support case #00996763). Between 1 and 7 August I provided everything NXP compliance asked for: company website, official trade register document, ownership structure, detailed project description, volumes, design stage, end use. On 12 August NXP Technical Support confirmed the NDA was approved and sent via NXP Contracts / Adobe Acrobat Sign to my signatory e-mail. On 18 August they confirmed a second eSign request. The problem: Neither Adobe Sign request ever arrived. Not in the inbox, not in junk, not in my Adobe Sign account, and – most importantly – there is no trace of any delivery attempt from adobesign.com / echosign.com in the Microsoft 365 Exchange message trace for the whole period. The transaction fails before it reaches my mail server. Technical Support says that "for security reasons we cannot resend the file", that they "cannot verify my e-mail address further", and that I should start over through an authorised distributor. A request to simply forward the case to NXP Contracts so they can check the Adobe Sign transaction and issue a new agreement (or send the NDA as a PDF for a handwritten signature) has not been actioned. The e-mail address in question is my only business address on my own domain and has been working for all other correspondence in this case, including all e-mails from [email protected]. What I am asking for: Could someone from NXP Contracts, the MIFARE product team, or anyone with access to the Adobe Sign audit trail please look at case #00996763 and either re-issue the eSign request or provide the NDA in another form? The due-diligence review is complete and approved – the only missing step is delivering one document. Any pointer to the right contact would be greatly appreciated. Thank you. Petr Zahradnik Czech Republic Re: DESFire EV3 NDA eSign request never delivered Hello Eduardo, thank you for the reply. I understand, and I would be glad to continue in the NDA ticket — the problem is that the ticket is effectively closed: Technical Support has twice answered that they "cannot proceed online" and that I should start over through a distributor, and my request to forward the case to the Legal / Contracts team has not been actioned. So my only ask is this: could you please pass case number 00996763 to the Legal team internally, so that someone who can see the Adobe Sign transaction looks at it? The NDA was approved on 12 August; the eSign request just never reached me (no delivery attempt in my mail server trace at all). A re-issued eSign request, or the NDA as a PDF for a handwritten signature, would resolve it immediately. I will add a note to the ticket referencing this thread. Thank you. Petr Re: DESFire EV3 NDA eSign request never delivered Hello @clexpert Hope you are doing well. Please accept my apologies, this is not the proper path to address any NDA topic. All the processes are handled by our Legal team after issuing the NDA online form. For further information about the status of your process, please continue the communication in your NDA ticket. Regards, Eduardo. Re: DESFire EV3 NDA eSign request never delivered Hello Eduardo, thank you again. Following your advice I continued in the NDA ticket (case 00996763) and explicitly asked for the case to be forwarded to the Legal / Contracts team, as you mentioned they handle these. The only reply I received today was, for the third time, a one-line message: "please contact NXP distributor for NDA creation." No forwarding to Legal, no comment on the failed Adobe Sign delivery, no reference to the audit trail I asked about. To summarise where this stands after three weeks: - The NDA was reviewed, approved and issued on 12 August. - Two Adobe Sign requests never reached my mail server (confirmed by a full message trace - no delivery attempt at all). - Technical Support cannot re-issue it and will only repeat the distributor advice. - I have contacted authorised distributors in parallel and am waiting. Could you please make the internal hand-off to Legal / Contracts yourself, or give me a direct contact there? I would simply like the already-approved NDA to be delivered - by a re-issued eSign request or as a PDF for a handwritten signature. I am keeping the tone constructive; I just need this to reach someone who can act on it. Thank you. Petr

S32N55: 高速ウェイクアップ ブート用の BLOB イメージを構築する方法。 こんにちは、チームの皆さん ご存知のとおり、S32N55 は Fast Wake-up Boot をサポートしています。 Full Wake-up Boot と同じ形式を使用して BLOB イメージをビルディングしようとしましたが、ブート プロセスが失敗しました。 Fast Wake-up Boot 用の BLOB イメージを正しく構築する方法を教えてください。 ご回答をお待ちしています。 Tangsheng_Zhou_0-1766369489644.pngTangsheng_Zhou_0-1766369489644.png よろしくお願いいたします。 唐生。 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ループのみが含まれています。 Tangsheng_Zhou_0-1784553297963.pngTangsheng_Zhou_0-1784553297963.png 2. FSSファームウェアイメージを作成する際、FRBしきい値レジスタを入力する必要がありますか？もしそうなら、どうやって埋めるか、あるいは特別なものを考える必要があります。 Tangsheng_Zhou_1-1784553422329.pngTangsheng_Zhou_1-1784553422329.png 3. IVTツールでIVTブロブイメージを構築し、開始アドレスを0x24800000とする。 4. IVTブロブイメージをフラッシュメモリの0xD00000に書き込みます。 5. システムがスリープ状態に入る前に、IVTブロブイメージをAOSRAMにコピーし、FSS_WKUP0のWKPUモードを高速ウェイクアップモードとして構成します。 Tangsheng_Zhou_2-1784553712231.pngTangsheng_Zhou_2-1784553712231.png Tangsheng_Zhou_3-1784553730808.pngTangsheng_Zhou_3-1784553730808.png 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の塊も教えてもらえますか? よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 いいえ、私は単にF-CoreをAO-SRAMで動作させたいだけです。 main_app1.binはFSSファームウェアイメージです。 これら2つのフィールドをどのように埋めるべきでしょうか？AO_SRAMアドレス0x24800000から始めるべきでしょうか？私のイメージの開始ポインタとエントリポインタは0x24800240です。 Tangsheng_Zhou_0-1784682563629.pngTangsheng_Zhou_0-1784682563629.png main_blob1.binは、IVTヘッダーを含むブロブイメージです。 よろしくお願いします！ よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 FSSファームウェアではなく、完全なIVTイメージをスリープモードに入る前にAO_SRAMにコピーし、高速ウェイクアップ機能をテストしました。   よろしくお願いします！ よろしくお願いいたします。 唐勝 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 IVTヘッダー、FSS FWヘッダー、およびFSS FWバイナリを含む、IVTブロブイメージ全体がAO_SRAMの先頭にコピーされました。 よろしくお願いします！ よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 流れを正しく理解しているか確認させてください。スリープ前に完全なIVTブロブイメージをAO_SRAMの先頭にコピーしているのですか、それとも高速ウェイクアップブート用のFSSファームウェアイメージのみをコピーしているのですか？ よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん Fast Wake-up Bootが正常に完了しているか確認していただけますか?起動プロセスが正常に動作していることが確認された場合、画像に問題がある可能性があります。 考えられる原因を段階的に絞り込んでいきたいと思います。   よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 WKPUの設定は正しいと思います。私の理解では、フルウェイクアップとファストウェイクアップの主な違いは、WBMSRの設定にある。それで合っていますか？ 他に考慮すべき設定や要素はありますか？ また、正しい手順や、あなたやチームが確認した速い目覚めのブロブ画像も教えていただけますか? サポートありがとうございます! よろしくお願いいたします。 唐生。 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さん WBMSRは、フルウェイクアップブートとファストウェイクアップブートの主な違いの一つです。しかし、それは唯一の要因ではない。 高速ウェイクアップブートの場合、BootROMはスリープに入る前に、AON SRAMに有効なイメージ（IVT + FSS FW、必要に応じてウェイクアップDCDを含む）が存在することを想定しています。WBMSRに加えて、ウェイクアップソースの設定、AON SRAMの保持、および有効なIVT/FSSヘッダーも検証する必要があります。 想定される高速起動フローは以下のとおりです。   1. IVT + FSS FW を含む IVT ブロブイメージを生成します。 2. 必要に応じて、ウェイクアップDCDを追加します。 3. ブロブイメージをAON SRAMの先頭にコピーします。 4. システムを高速起動モードに設定します。 5. スリープモードに入り、ウェイクアップソースをトリガーする 検証済みのFast Wake-upブロブイメージについては、現在社内で確認しており、検証済みの参照イメージが入手可能になり次第、ご連絡いたします。   少しでもお役に立てれば幸いです。   よろしくお願いいたします。 ポール Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは、 @PaulB0besさん。 ご返信ありがとうございます。ご指示いただいた手順に従って高速起動機能をテストしましたが、問題は依然として発生しています。ご自身の側で成功裏にテストしたか確認いただけますか?   ありがとうございます！ よろしくお願いいたします。 唐生。 Re: S32N55: How to build a blob image for fast wake-up boot. こんにちは@Tangsheng_Zhouさん 提供された回答が適切であり、チケットに関して他に質問がない場合は、回答を「解決策として承認」としてマークしてください。 今後のケースでは、NXP JIRA: Jira Projectをご利用ください  さらに、7日以内に返答がなければ、CASEを終了します。 よろしくお願いいたします。 ポール

FRDM-MCX C162 Low Power Presence Detection Demo In this lab, we will learn how to connect and configure expansion boards on the Freedom MCXE 162, including a pressing sensor and a display. Hardware requisites: FRDM-MCXC162 Board Type C USB Cable MikroE OLED B/W Click display in I2C mode SparkFun Qwiic dToF Imager (TMF8820) Software requisites: IDE: Visual Studio Code 1.130.0 or later SDK: v26.06.00 Windows OS (It was used Windows 11 for this hands-on) This hands-on describes Expansion boards Lab Guide (function() { var wrapper = document.getElementById('lia-vid-6403406600112w960h540r95'); 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) Application Code Hub Community Support If you have questions regarding this training, please leave your comments in our MCU Community! here  FRDM-Training Hands-On Training MCXC

FRDM-MCX C162 Firmware Binary Programming Lab In this lab, we will learn how to program a firmware binary onto the FRDM-MCXC162 development board. The lab will guide you through the complete firmware programming process, starting with the required hardware and software, and continuing with the development environment setup. Hardware requisites: FRDM-MCXC162 Board Type C USB Cable Software requisites: IDE: Visual Studio Code 1.130.0 or later SDK: v26.06.00 Windows OS (It was used Windows 11 for this hands-on) Link Server v25.5.59 Any Recent Phyton 3 Version Windows Command Prompt (CMD) This hands-on describes  Firmware Binary Programming Lab Guide (function() { var wrapper = document.getElementById('lia-vid-6403407390112w960h540r472'); 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) Application Code Hub Community Support If you have questions regarding this training, please leave your comments in our MCU Community! here  FRDM-Training Hands-On Training MCXC

FRDM-MCX C162 Low Power Temperature Sensing Demo In this lab, we'll learn how to access Application Code Hub directly from Visual Studio Code, download a low-power sensing application, and run it on the FRDM-MCXC162. Hardware requisites: FRDM-MCXC162 Board Type C USB Cable Software requisites: IDE: Visual Studio Code 1.130.0 or later SDK: v26.06.00 Windows OS (It was used Windows 11 for this hands-on) This hands-on describes Low Power Temperature Sensing Lab Guide (function() { var wrapper = document.getElementById('lia-vid-6403407289112w960h540r333'); 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) Application Code Hub Community Support If you have questions regarding this training, please leave your comments in our MCU Community! here  FRDM-Training Hands-On Training MCXC

FRDM-MCX C162 Low Power SDK Demo Lab In this lab, we will learn how to import and run a low-power SDK demo on the FRDM-MCXC162 development board. We will configure the application, build and debug the project, and use a serial monitor to control the available power modes. Hardware requisites: FRDM-MCXC162 Board Type C USB Cable Software requisites: IDE: Visual Studio Code 1.130.0 or later SDK: v26.06.00 Windows OS (It was used Windows 11 for this hands-on) This hands-on describes Low Power SDK Lab Guide (function() { var wrapper = document.getElementById('lia-vid-6403407386112w960h540r227'); 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) Community Support If you have questions regarding this training, please leave your comments in our MCU Community! here  FRDM-Training Hands-On Training MCXC