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例を公開しています:
この例は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()も確認してください:
スクリーンショットから判断すると、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キャッシュ管理が本当に有効であるかを確認することです。
よろしくお願いいたします。
パベル
