2374654_ja-JP

Yes

S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RXフレームがCRC_ERROR + DRIBBLE_ERRORで破棄されました

こんにちは、

私はS32K344上でイーサネットを動作させる作業を行っており、ベースボードとしてS32K344 Mini EVBを使用しています。このプロジェクトは、lwIPを使用せずにRTD Eth_43_GMACドライバを使用しています。このアプリケーションはNXPのethernet_no_lwipサンプルをベースにしていますが、当社のボードに合わせて調整されています。

ハードウェアは、Microchip/Micrel製のKSZ8091RND PHYをRMIIモードで使用しています。回路図によると、PHYはXIピンで50MHzのクロックを受信します。KSZ8091RNDのPHY制御2レジスタのビット7（RMIIリファレンスクロック選択）は0です。これは、XIで50MHzクロックを使用するRNDモードと一致していると考えられます。

MCUとPHY間のインターフェースは、RMII、100Mbps、全二重として構成されている。

.mexファイルではファイルにおいて、GMAC/EMACピンは以下のように構成されます。

PTD16、ピン 34: RMII_MDIO、emac_mii_rmii_mdio
PTD17、ピン 31: RMII_MDC、emac_mii_rmii_mdc
PTB5、ピン47：RMII_TX0、emac_mii_rmii_txd0
PTB4、ピン48：RMII_TX1、emac_mii_rmii_txd1
PTE9、ピン 36: RMII_TX_EN、emac_mii_rmii_tx_en
PTC0、ピン62：RMII_TX_CLK、emac_mii_rmii_tx_clk
PTD9、ピン63：RMII_RX0、emac_mii_rmii_rxd0
PTD8、ピン 64: RMII_RX1、emac_mii_rmii_rxd1
PTC15、ピン 68: RMII_RX_DV、emac_mii_rmii_rx_dv
PTC16、ピン 66: RMII_RX_ER、emac_mii_rmii_rx_er
PTC1、ピン61：RMII_RX_CLK、emac_mii_rx_clk
PTE21、ピン153：ENET_RESET

.mexファイル内の関連するイーサネット構成ファイル：

EthCtrlMacLayerType = ETH_MAC_LAYER_TYPE_XMII
EthCtrlMacLayerSubType = 縮小
EthCtrlMacLayerSpeed = ETH_MAC_LAYER_SPEED_100M
EthDuplexMode = ETH_FULL_DUPLEX
EthCtrlEnableRxInterrupt = false
EthCtrlEnableTxInterrupt = false

RTDによって生成された関連GMAC構成：

miiMode = GMAC_RMII_MODE
速度 = GMAC_SPEED_100M
デュプレックス = GMAC_FULL_DUPLEX

また、ドライバがコントローラをリセットする前にRMIIインターフェースを選択していることも確認しました。Eth_43_GMAC_Ipw.c では、モードがGMAC_RMII_MODEの場合、DCMRWF1 MAC_CONF_SELに値2Uを書き込みます。

生成されたコードに基づくと、MAC_CONF_SELはRMII用に設定されているようです。

時計に関しては、.mexファイルには以下が表示されます：

external_clocks.emac_mii_rmii_tx.outFreq = 50 MHz
EMAC_MII_RMII_TX.outFreq = 50 MHz
EMAC0_RX_CLK.outFreq = 25 MHz
EMAC0_TX_CLK.outFreq = 25 MHz
EMAC0_TS_CLK.outFreq = 50 MHz

EMACクロックマルチプレクサは、EMAC_MII_RMII_TX_CLKをソースとして使用します。

McuCgm0ClockMux7_Source = EMAC_MII_RMII_TX_CLK
McuCgm0ClockMux8_Source = EMAC_MII_RMII_TX_CLK
McuCgm0ClockMux9_Source = EMAC_MII_RMII_TX_CLK

これをNXPの.mexの例と比較するとファイルを確認したところ、EMAC_MII_RMII_TXが50MHz、EMAC0_RX_CLK / EMAC0_TX_CLKが25MHzと表示されていました。そのため、これはツール上では正常な動作だと思われますが、確認したいと思います。

このアプリケーションは、lwIPを使用せずに、Eth_43_GMACを介してイーサネットフレームを直接送受信します。

送信時には、以下のシーケンスを使用します。

Eth_43_GMAC_ProvideTxBuffer
Eth_43_GMAC_送信
Eth_43_GMAC_TxConfirmation

RX（受信）に関しては、RX/TX割り込みが無効になっているため、ポーリングを使用します。

ETH_43_GMAC_RX_IRQ_ENABLED = STD_OFF
ETH_43_GMAC_TX_IRQ_ENABLED = STD_OFF

RXコードは、CtrlIdx、FifoIdx、およびreceiveStatusを引数としてEth_43_GMAC_Receiveを繰り返し呼び出します。

また、EthIf_RxIndications[0]も監視します。なぜなら、ドライバは受信したフレームにエラーがない場合にのみEthIf_RxIndicationを呼び出すからです。

観測された挙動は以下のとおりです。

TXは複数回正常に確認されました。

一方、一部のフレームは受信されているように見える。

S32K344のRXはデータを受信するが、その後ドライバによって全てのフレームが破棄される。

receiveStatusは、フレームが受信されたことを示す場合があります。

しかし、ドライバがフレーム内のエラーを検出したため、EthIf_RxIndicationは呼び出されません。

Eth_43_GMAC_Ipw_axRxFrameInfo[0][0].ErrMask を検査したところ、観測された値は次のとおりでした。

ErrMask = 0x01080000

ドライバヘッダーによると、これは以下に対応します。

GMAC_RX_ERR_CRC_ERROR = 0x01000000
GMAC_RX_ERR_DRIBBLE_ERROR = 0x00080000

つまり、フレームはGMACに到達するが、CRCエラーとドリブルエラーが記録されている。

主な疑問は、GMACがRMII 100M全二重として構成され、KSZ8091RND PHYがXIで50MHzクロックを受信し、ドライバがMAC_CONF_SEL値2Uを選択している場合、RXでCRCエラーとドリブルエラーが同時に発生する原因は何なのか、ということです。

特に確認したい点は以下のとおりです。

S32K344、GMAC、RMII の場合、.mex はファイルにはEMAC_MII_RMII_TX = 50 MHzと記載されているが、EMAC0_RX_CLKとEMAC0_TX_CLKは25 MHzとなっている。
S32K344のRMIIモードでは、PTC0上のemac_mii_rmii_tx_clkとPTC1上のemac_mii_rx_clkの両方を設定することが想定されていますか、それともこのモードではこれらの信号のいずれかを使用またはルーティングしない必要がありますか？
MAC_CONF_SELの値が2Uであること以外に、RMIIのDCM_GPR、クロックツリー、またはピンマルチプレクサで追加の設定が必要ですか？
PHY制御2のビット7を0に設定し、XIに外部50MHzクロックを接続したKSZ8091RNDは、このGMAC構成と互換性がありますか？
RXでCRC_ERRORとDRIBBLE_ERRORが同時に発生した場合、オシロスコープまたはロジックアナライザで最初に確認すべきRMII信号はどれですか？REF_CLK、CRS_DV、RXD0、RXD1、RX_ER?
NXPの公式S32K344用サンプルコードで、lwIPを使用せずにRMIIモードでKSZ8091RND PHYを使用するものはありますか？

要約：リンクが確立され、TXが確認され、RXがフレームを検出しますが、CRC_ERRORとDRIBBLE_ERRORによりフレームが破棄されます。これがRMIIクロックの問題、ピン多重化／物理信号の問題、あるいはGMAC／RTDの追加設定要件を示しているのかどうかを判断しようとしています。

サポートとご指導を賜り、誠にありがとうございます。

Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR

こんにちは、パベルさん。

重要なお知らせが1つあります。

S32K344の内部MACループバックを有効にし、PHYループバックを有効にせず、PHYリンクの自動ネゴシエーションを待たずに、TXの後にRXのみを実行するようにテストを調整しました。

MAC内部ループバックを使用すると、テストは正しく合格します。受信したフレームは有効であり、CRCエラーやドリブルエラーはありません。

しかし、KSZ8091RND PHYのループバックを有効にしても問題は解決しません。フレームはRXバッファに到達しますが、一部のバイトが破損し、GMACがCRCエラーを報告します。

現在の結果は以下のとおりです。

MAC内部ループバック：OK、CRCドリブルエラーなし
PHYループバック：失敗、CRCエラーが残っています
通常の外部受信: 失敗、CRCエラーが残っています

これは、GMACドライバ、TX-RXソフトウェアフロー、バッファ、および内部MACパスが正しく動作していることを示しており、残りの問題はS32K344とKSZ8091RND間の外部RMIIパス、またはPHY-RMIIパッド構成にある可能性が高いことを示唆している。

MAC内部ループバックは合格しているのにPHYループバックが不合格となっている場合、次に何をチェックすべきか、何かおすすめはありますか？

よろしくお願いします。

Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR

こんにちは、パベルさん。

ご返信とご指導ありがとうございます。

ご指摘いただいた内容に基づき、ハードウェアとソフトウェアの追加チェックを実施しました。

まず、オシロスコープを使用して、PTC0であるemac_mii_rmii_tx_clkとして設定されたMCUピンに50MHzのRMIIクロックが存在し、安定していることを確認しました。また、このクロックはイーサネットドライバの初期化前に存在していることも確認しました。

emac_mii_rx_clk信号に関して、S32K344のRMIIモードでは使用されないというご説明は理解いたしました。混乱を避けるため、この信号を設定から削除しましたが、エラーの動作は変わりませんでした。

DCMRWF1も確認しました。ご指摘のとおり、RTDドライバはMAC_CONF_SEL = 2UでRMIIモードを設定しています。

回路図と基板の検査中に、ハードウェアの問題が見つかりました。PHY CRS_DV信号をMCUピンに接続する抵抗R190が断線しているか、取り付けられていませんでした。この信号は、mmac_mii_rmii_rx_dvとして構成されたMCUピンに接続されたRMII CRS_DV信号に対応します。

これを特定した後、抵抗器R190を取り付け/接続しました。その後、オシロスコープにCRS_DV信号が現れ始め、受信時にはMCUのピンでトグルするようになった。また、RX_ERも測定しましたが、フレーム中にパルスが発生しないため、常に低い値のままでした。

CRS_DVを修正した後も、問題は解決しなかった。ドライバは依然として ErrMask = 0x01080000 を報告しており、これは CRC_ERROR + DRIBBLE_ERROR を意味します。

RXバッファの内容も確認しました。フレームはGMACに到達しているようだが、一部のバイトに誤ったビットが含まれている。例えば、期待されるフレームは次のとおりでした。

宛先MACアドレス: 02:00:00:00:00:02
ソースMAC: 11:12:21:77:77:77
イーサリアムタイプ: 88:88

しかし、RXバッファに現れたのは次のようなものだった。

宛先MACアドレス: 21:00:00:00:00:02
送信元MACアドレス: 11:21:11:76:77:77
イーサリアムタイプ: 8B:88

その後、バイト08が現れ、残りのバイトはすべてゼロになった。

これは、フレームがGMACに到達しているものの、データが不正確または位置ずれしたビットでサンプリングされていることを示唆しています。

オシロスコープ上でCRS_DVも観測した。フレームの最後に、レベルが低くなると、数サイクルの間トグルした後、完全にレベルが低くなります。我々の理解では、RMIIではCRS_DVがCRSとRX_DVを統合しているため、この動作は正常である可能性がありますが、S32K344/GMACでも同様の挙動が想定されるかどうかを確認したいと思います。

その後、基板を再度確認し、残りのRMII信号用の抵抗器／ジャンパーが正しく取り付けられていることを確認しました。R190に問題が見つかった後、他のRMII信号も確認しましたが、他に欠落または断線している抵抗は見つかりませんでした。

また、KSZ8091RND PHY上でループバックテストを実施しました。基本制御レジスタにおいて、MDIOを介してPHYをループバック用に構成しました。デバッガーで、ビットが次のようになっていることを確認しました。

ループバック = 1
speedSelect = 1
autoNegotiationEnable = 0
デュプレックスモード = 1

つまり、PHYはループバックモード、100Mbps、全二重、オートネゴシエーション無効の状態です。

このモードでは、当社のソフトウェアはフレームをGMAC経由で送信し、Eth_43_GMAC_Receiveを使用して受信を即座にポーリングします。TXシーケンスは、Eth_43_GMAC_TxConfirmationと正しく照合されます。

PHYをループバックモードにしても、問題は解決しない。フレームは依然としてRXバッファに到達しますが、バイトが破損しており、ドライバは依然としてErrMask = 0x01080000を報告します。これはCRC_ERROR + DRIBBLE_ERRORを意味します。

このことから、ケーブルと他のデバイスは分析から除外されるようです。なぜなら、問題はローカルパス MCU -> PHY -> 内部 PHY ループバック -> MCU でも発生するからです。

現時点で、ご質問に対する回答は以下のとおりです。

1->EMAC_MII_RMII_TX = 50 MHz、EMAC0_RX_CLK / EMAC0_TX_CLK = 25 MHz は RMII で正常であることを確認しました。

2->RMIIではemac_mii_rx_clkは不要であることを確認しました。設定から削除したが、問題は解決しなかった。

3->ドライバがDCMRWF1.MAC_CONF_SEL = 2Uを構成することを確認しました。

4->オシロスコープで、50 MHz クロックが MCU ピン PTC0 / emac_mii_rmii_tx_clk に到達していることを確認しました。

5->抵抗R190を取り付け/閉じた後、CRS_DVがMCUに到達することを確認しました。

6->受信中は常にRX_ERが低いままであることを確認しました。

7->BMCRの読み出しにより、PHYループバックが実際にアクティブであることを確認しました。

8->残りのRMII信号用の抵抗器/ジャンパーが正しく取り付けられていることを確認しました。

それでも、破損したバイトとCRC_ERROR + DRIBBLE_ERRORを含むフレームを受信し続けています。

このシナリオでは、問題は依然としてS32K344とKSZ8091RND間のローカルRMIIインターフェースに関連しているようで、おそらくREF_CLK、TXD0/TXD1/TX_EN、CRS_DV、RXD0/RXD1間のタイミング/スキュー、またはRMII信号の電気的/パッド構成に問題があると考えられます。

PHYループバックを有効にした場合でもエラーが発生するようになったため、このケースについて何か具体的な推奨事項はありますか？S32K344 Mini EVBのRMIIに関して、確認すべきパッド構成、クロック位相、駆動強度、スルーレート、または直列抵抗の要件はありますか？

MCUからPHYへのTX RMIIパスに問題があるのか、それともPHYからMCUへのRX RMIIパスに問題があるのかを判別するために推奨されるGMACまたはPHYテストはありますか？

ご支援とご指導を賜り、誠にありがとうございます。

Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR

こんにちは、@brunoGT88 さん。

詳細な説明をありがとうございました。あなたの設定を注意深く確認しました。

ご説明いただいた内容に基づくと、これはEth_43_GMACのTX/RXソフトウェアフローの問題というよりは、典型的なRMIIクロックの問題のように見えます。

まず、Eth_43_GMAC_Init() を呼び出す前に、外部 RMII 50 MHz クロックが存在し、安定していることを確認してください。これはS32K344 RMIIの設定において重要な点です。

ご質問について：

1. はい - RMII モードでは、クロック構成で EMAC_MII_RMII_TX = 50 MHz と表示され、内部 EMAC0_RX_CLK と EMAC0_TX_CLK は 25 MHz として導出されることが想定されます。

2. いいえ - emac_mii_rx_clk は S32K344 EMAC の RMII モードでは使用されません。通常のS32K3 RMII構成では、PHYがMACに50MHzのTXクロックを供給し、内部EMACのRX/TXクロックは分周器2を使用してそのクロックから生成されます。

3. 私の場合、通常はDCMRWF1のRMII選択のみを主要な追加設定として使用し、通常はプロジェクトの最初の行に配置します。

IP_DCM_GPR -> DCMRWF1 = ( IP_DCM_GPR -> DCMRWF1 & ~DCM_GPR_DCMRWF1_MAC_CONF_SEL_MASK) | DCM_GPR_DCMRWF1_MAC_CONF_SEL(2U);
 

4. PHYクロックの部分については、あなたの説明からはまだ完全には理解できません。KSZ8091RNDがXIで50MHzを受信しているというだけでは、S32K344 MACがemac_mii_rmii_tx_clkで必要な50MHz RMIIリファレンスクロックを受信していることを自動的に確認することはできません。PHY/発振器とMCUの間で50MHz RMIIリファレンスクロックがどのように接続されているかを正確に確認し、可能であればその部分の回路図を共有してください。

5. RXでCRCエラーとドリブルエラーが発生した場合、RMIIクロック/信号を次の順序で確認します。

REF_CLK / RMII_TX_CLK (50 MHz)
CRS_DV
RXD0 / RXD1
RX_ER

6. S32K344 + KSZ8091RND + RMII + lwIPなしという構成に特化したNXPの公式サンプルは知りません。ただし、このS32K344 EMACの例を参照して、クロック/ピン設定をそれと比較するか、ボードに合わせて調整することもできます。

例：S32K344 EMAC lwIP FreeRTOS miniEVB S32DS 3.6.1 RTD 6.0.0

追加のデバッグ手順として、PHYが対応している場合は、PHY側でMII/RMIIループバックを有効にして、MACが送信したフレームを受信できるようにしてみてください。これは、PHY/リンクレベルの問題とMCUの受信サンプリングの問題を区別するのに役立ちます。

よろしくお願いいたします。

パベル

Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR

私はRTD 5.0.0を使用しています。

Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR

こんにちは、 @PavelL さん。

重要な新たな発見がありました。

PC上でWiresharkを使用して、ボードのTX（送信）機能をテストしました。ファームウェアは以下のフレームを送信します。

宛先MACアドレス: 70:69:79:A6:74:4F
ソースMAC: 11:12:21:77:77:77
イーサリアムタイプ: 0x8888
ペイロード: 0x55 パターン

しかし、Wiresharkで確認したところ、PCに届いたフレームは既に破損していた。送信元MACアドレス、宛先MACアドレス、およびEtherTypeが正しくありません。

つまり、問題はS32K344へのRXだけにあるわけではない。S32K344からPHY-PCへのTXパスでもビットが破損している。

MACの内部ループバックは正常に機能しているため、フレームはGMAC内部で正しく構築されます。フレームが外部RMIIインターフェースを介して送信される際に、破損が発生する。

これは、外部RMII TXパスまたはパッド構成に問題があることをより強く示唆している。

TXD0
TXD1
TX_EN
REF_CLK - RMII_TX_CLK

S32K344のRMII TXに関して、駆動強度、スルーレート、キーパー、プル構成など、特定のパッド設定を推奨しますか？現在生成されているピン構成では、TXD0、TXD1、TX_EN、およびTX_CLKのdriveStrengthEnableが無効になっています。

よろしくお願いします。

Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR

こんにちは、 @PavelL さん。

根本原因を突き止めました。

問題は初期化順序に関連していた。私のプロジェクトでは、SIUL2ピンマルチプレクサの初期化よりも前にMCUクロックの初期化が実行されていました。起動フローを変更し、MCUクロックの初期化よりも先にピン多重化の設定を行うようにしたところ、イーサネットフレームが正しく送信されるようになった。

これは、私が比較対象としたNXPのクリーンなサンプルで使用されている初期化順序とも一致します。

サポートありがとうございます。

Re: S32K344 Mini EVB + GMAC RMII + KSZ8091RND: RX frames discarded with CRC_ERROR + DRIBBLE_ERROR

こんにちは、@brunoGT88 さん。

詳細なアップデートと追加チェックを実施していただき、ありがとうございます。最新の結果は大変参考になります。MAC内部ループバックは通過するが、PHYループバックは依然として失敗し、
PC上で確認した時点で、送信時に既にフレームが破損している。これは、問題がGMACドライバのフロー、バッファ処理、または内部MACパスにあるのではないことを強く示唆している。

残りの疑わしい領域は、S32K344とKSZ8091RND間の外部RMIIインターフェースであり、信号ルーティング、ピンマッピング、I/O電圧互換性、またはRMIIライン上のタイミング/信号完全性などが含まれます。私の提案をぜひご検討ください。

KSZ8091RNDとS32K344のRMIIピン間のI/O電圧の互換性を確認してください。
すべてのRMIIラインについて、ピン間の導通と信号マッピングを確認してください。
基板上のどこでもTXD0/TXD1とRXD0/RXD1が入れ替わっていないことを確認してください。
RMII TXインターフェースのPHYピン（REF_CLK、TX_EN、TXD0、TXD1）を直接プローブします。
RMII TX信号から送信されたフレームを再構築し、期待されるフレームと比較する。
リセット後、PHYストラップの設定を再確認し、意図したRMII/リファレンスクロックモードになっていることを確認してください。

よろしくお願いいたします。

パベル