2138507_ja-JP

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

2138507_ja-JP

2138507_ja-JP

MDIORead が RMII インターフェースで常に 0xFFFF を返す

こんにちは。私は s32k148 と Microchip LAN8720A phy ドーターボードを使って通信できるように取り組んでいます。私は、PHY からの信号を J16 コネクタにルーティングするための嵌合 PCB を設計しました。電源投入時に PHY を適切に初期化することができ、Windows コンピューターに接続するとオレンジと緑の LED が表示され、PC 側では Wireshark のアクティビティも確認できます。次のステップは、ボードの MAC インターフェースを PHY と通信させることですが、ここで問題が発生します。tja1101 の例をできるだけ忠実にコピーするようにコードを設定しましたが、実行しようとするたびに、メイン関数命令の PHY_SHARED_ReadBasicStatus() 内の ENET_DRV_MDIORead() が 0xFFFF を返します。

私が二重チェックした項目のリストは次のとおりです。
- 50MHz クロックは仕様範囲内であり、PHY の CLKIN ピンと J16 の PTD11 の両方にあります。
- 内部モジュール クロックと MII_SPEED ビットによって指定される MDC 周波数は 2.4MHz です (内部モジュール クロック = 48MHz、MII_SPEED ビット = 9)。
- データシートによれば、物理アドレスは0です(RXER/PHYADD0は内部でローにプルダウンされています)

初期化コードと PHY のデータシートが適切であることを確認できるように、プロジェクト全体をこの投稿に添付しました。

また、オシロスコープを使用して MDIO および MDC ラインのアクティビティを測定しましたが、それが適切な形式であったかどうかはわかりません。

よろしくお願いします!

Re: MDIORead always returning 0xFFFF on RMII interface

こんにちは@christopherlajoie

休暇に関してお知らせいただきありがとうございます。そうすれば、詳細な回答を準備するのに十分な時間が得られます。

最新情報と詳細な観察に感謝します。

MDIO および MDC 信号のレベル シフターに関しては、ボード上の U14 (MDIO) と U22 (MDC) (黄色のもの) の位置については添付の画像を参照してください。オシロスコープを使用して動作を調べ、信号の整合性を検証CAN。ボードが新品であれば、製造上の欠陥がない限り、損傷の可能性は低いことに同意します。

PavelL_0-1754043975153.png

セットアップ時間に関するご質問ですが、SMI インターフェースでは、MDIO は MDC の次の立ち上がりエッジでサンプリングされます。つまり、セットアップ時間要件は、必ずしもキャプチャに表示される現在のエッジの前ではなく、そのエッジの前に有効になっているデータに適用されます。SO、セットアップ時間の要件は簡単に満たされます。

動作を検証するために、次の設定を使用して S32K148EVB-Q176 ボードで lwip_s32k148 の例を実行しました。

ソフトウェア:

  • S32 Design Studio v3.5
  • SDK: s32sdk_s32k1xx_rtm_401

ハードウェア:

  • TJA1103-SDBRドーターボード(rev-RMIIモード)
  • PHYアドレス: 0x02
  • MDIOラインにプルアップ抵抗がない

PHY ドライバーを追加し、PHY エントリを定義しました。

PavelL_1-1754044357429.png

LED を点滅させ、PHY_Read() を使用して 2 つの PHY レジスタを定期的に読み取る FreeRTOS タスクが作成されました。MSCR 設定をデフォルトのままにしておくと、次のようになります。

  • MDC周波数: ~2.39 MHz
  • ホールド時間: 20 ns (MSCR.HOLDTIME = 0x0)
  • ホールド時間: 170 ns (MSCR.HOLDTIME = 0x7 - デバッガによって設定)

PavelL_2-1754044404052.png

PHY をリセットしようとしましたが、不要であることが判明したSO、関連コードをコメント アウトしました。

抵抗器 R46 (MDIO) と R38 (MDC) で信号が観測されました。以下は、完全な第 22 条の読み取りトランザクションの波形キャプチャです。

  • ターゲットPHY: 0x02
  • 読み取りレジスタ: 0x03
  • TJA1103 によって返されたデータ: 0xB013 (カーソル間)

PavelL_3-1754044640726.png

比較のために、オシロスコープで第 22 条の完全なトランザクションをキャプチャしてみてください。波形は、マネジメントデータ入出力 - Wikipediaに記載されているタイミング図に似ているはずです。

コード全体を確認することはできませんが、とにかく共有していただきありがとうございます。ただし、PHY_Read (および他の PHY 関数) の最初のパラメーターは PHY アドレスではなく、PHY エントリのインデックスであるSO、0 または PHY_INSTANCE_0 になる必要があることに注意してください。PHY アドレスは、PHY エントリ自体内に設定する必要があります。

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

パベル

Re: MDIORead always returning 0xFFFF on RMII interfaceLAN8720A にあった 1.5k オームの抵抗の代わりに 10k オームの抵抗をはんだ付けしましたが、これが強すぎるようで、3.3V ライン全体が 1.5V 程度まで引き下げられています。信号全体が途切れてしまう、SOこれは解決策にはなりません。Digi-Key の注文を受け取ったら、1.5k から 10k までの他の値を試してみます。来週は休暇を取る予定です。SOこれ以上のデバッグ作業は行えないことをご了承ください。8月4日月曜日(EST時間)に戻りますRe: MDIORead always returning 0xFFFF on RMII interface

こんにちは、パベルさん。詳しい回答をありがとうございます。3.3V ラインへのプルアップ抵抗を増やして、信号が改善されるかどうか確認してみます。

TXB0104 双方向レベル シフターに関しては、どのようにテストすればよいのか、ボード自体のどこにあるのかもわかりません。それを実行する方法について教えていただけますか?また、ボードはかなり新しいSO、欠陥がない限り、壊れている可能性は非常に低いと思います。

セットアップ時間に関する質問について、何かご意見はありますか?私の写真に示されているように、MDC の立ち上がりエッジの少なくとも 10 ns 前に MDIO 信号がトリガーされないのは非常に奇妙だと思います。ホールドタイム パラメータを 1 サイクルに設定しました。これは、私のCASE、48 MHz で約 20 ns に相当します。データシートには、セットアップ時間は少なくとも 10 ns である必要があることが明記されています。PHY への読み取り操作と書き込み操作の両方をテストしましたが、どちらもセットアップ時間は表示されません。

christopherlajoie_0-1753448062961.png

サポートありがとうございました!


Re: MDIORead always returning 0xFFFF on RMII interface

こんにちは@christopherlajoie

詳細なフォローアップと測定に感謝します。回答と提案は以下をご覧ください。

  • MDIO ラインの急激なスパイクは確かに異常です。プルアップ抵抗を10kΩ以上に増やしてみてください。1.5 kΩ のプルアップは厳密には必要ではなく、このCASEは強すぎる可能性があります。

  • S32K148-Q176 ボードは、MCU と PHY の間に TXB0104 双方向レベル シフタを使用します。これらは信号の形状とタイミングにCAN影響を与える可能性があります。PTB4 で観察されるリンギングや歪みの原因となっている可能性があるため、正しく動作していることを確認してください。

  • ドライブ強度について: これを High に設定すると、より強力な出力ドライバ (より多くのトランジスタ) が有効になり、立ち上がり/立ち下がり時間が改善され、電流能力が向上します。これは、特に長いトレースや容量性負荷の場合に、信号の整合性を高めるのにCAN。違いは S32K1 のデータシートに記載されています。

  • MDC 周波数を調整するということは、プルアップ抵抗、トレース長、寄生静電容量など、MDIO ラインの電気的特性に合わせて調整することを意味します。MDC は技術的には最大 2.5 MHz までCANますが、それを下げると (たとえば、500 kHz または 250 kHz に)、限界信号条件を安定させることができます。ただし、すでにこれを試しても改善が見られない場合、問題は他の場所にある可能性があります。

  • MDC は MSCR レジスタを介して ENET モジュール クロックから派生されるという事実を除けば、コア クロックと MDC クロックの間に厳密な依存関係はありません。MDC が仕様内である限り、コア クロックは MDIO タイミングに直接影響しません。


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

パベル

Re: MDIORead always returning 0xFFFF on RMII interface

また、LAN8720A のデータシートの表 5-12 には、MDC の立ち上がりエッジを基準としたデータ入力の MDIO 信号セットアップ時間は少なくとも 10 ns である必要があると記載されています。ただし、電源が入っていないボードで PHY を外して信号を測定したところ、セットアップ時間はまったくないようです。設定し忘れたパラメータでしょうか?ホールド時間は設定しましたが、セットアップ時間は設定しませんでした。下の写真をご覧ください

Re: MDIORead always returning 0xFFFF on RMII interface

また、3.3V 間と GND 間の MDIO ラインの抵抗も測定しました。PHY のみで測定した場合 (NXP ボードに接続されていない)、3.3V に対して 1.5k オーム、GND に対して 120k オームが得られます。ただし、ボードに接続した状態で測定すると (電源が入っていない状態で)、3.3V に対して 1.5k オームになりますが、GND に対しては 2.9k オームになります。PTB4 は電源が入っていないときにシンクする可能性があると思いますが、それはボードに接続されていないときは MDIO ラインが正常であることも意味します。

Re: MDIORead always returning 0xFFFF on RMII interface

私が間違っていたようです。PCB を接続せずに (PHY なしで) MDIO ライン上の信号を測定しただけなので、MCU の読み取り要求に何も応答せず、信号は実際にはクリーンに見えます。また、全体的な形式は同じで信号が不良であり、これは MDIO ライン上の MCU との物理的な相互作用により、MCU の信号が何らかの形で破損していることを意味します。下の画像をご覧ください

Re: MDIORead always returning 0xFFFF on RMII interface

また、問題が PCB にないことを確認するために、R46 抵抗器で MDIO 信号を測定しましたが、抵抗器に十分近い GND スポットが見つからなかったため、多少のノイズはありましたが、まったく同じ信号が得られました。下の写真をご覧ください

Re: MDIORead always returning 0xFFFF on RMII interface

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

それは知っておいてよかったです!内部で自動的に制御されているはずだと考えましたが、確かめたかったのです。しかし、それでは私の問題は解決されないのではないかと心配しています。前に述べたように、MDC のクロック サイクル間の高ロジックと低ロジックの間の急速なスパイクにより、MDIO ラインは本来あるべき姿ではなくなります。PTB4 のラインおよび動作にはまだ問題があります。

ご提案のとおり、MDC 速度を 1 MHz から 500KHz、さらに 250KHz まで下げてみましたが、動作は同じでした。いつもあの鋭いスパイクです。MDC クロックは、PHY の基本レジスタ 1 から取得する読み取り値に影響しているようですが、これは MDIO ラインの問題によるものだと思います。通常のCASE、MDC 速度は 2.5MHz 未満であれば何も影響しないはずです。コア クロックと MDC クロックの間には、従うべき何らかの関係があるのでしょうか?

PTB4のプルアップ機能の設定も試してみました。プルアップとプルダウンの両方を試しましたが、成功しませんでした。高いドライブ強度と低いドライブ強度の違いは何か知りたいです。

最後に、「MDC 周波数を調整する」とはどういう意味かわかりませんが、私の理解では、2.5 MHz 未満であればマターないはずです。このラインは通信のために MAC と PHY の間で共有される唯一のラインなので、PTB4 と組み合わせるとラインの電気的動作に何か問題があるのではないかと思います。他に何をテストすればよいかというアイデアや、S32k148EVB-Q176 で実行されて成功した同様のプロジェクトの他の例はありますか?

継続的なサポートに感謝します。とても感謝しています!

Re: MDIORead always returning 0xFFFF on RMII interface

こんにちは@christopherlajoie

MDIO ピン (PTB4) は ENET ペリフェラルによって制御され、Clause-22 操作中に方向 (TX/RX) とオープン ドレイン動作を自動的に管理します。ピンを手動でオープンドレインとして設定する必要はありません。

MDC 周波数を 1 MHz に下げたのは良い動きでした。安定性と可視性を向上させるには、さらに低い周波数 (たとえば、500 kHz) に設定してみるとよいでしょう。PHY には MDC 最大クロックの制限はありません。

MDC のエッジ間の最小時間は 160 ns です。エッジ間の最大時間はありません。最小サイクル時間 (2 つの連続する立ち上がりエッジまたは 2 つの連続する立ち下がりエッジ間の時間) は 400 ns です。これらの適度なタイミング要件により、このインターフェースはマイクロコントローラの I/O ポートによって簡単に駆動できます。

ドライブ強度を「高」に設定すると、適切な調整になりました。

実際の状況に合わせて MDC 周波数を調整するだけです。

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

パベル

Re: MDIORead always returning 0xFFFF on RMII interface

こんにちは、PaveILさん

ご意見ありがとうございます。アンダーサンプリングについてはおっしゃる通りで、確かに信号を正しく読み取っていませんでした。きちんとサンプリングしてみた結果は次のとおりです。
- すべての PHY_read() トランザクションで、信号の MDIO バス部分への MAC 書き込みが乱れているように見えますが、バスへの PHY 書き込みはクリーンに見えます。
- リンクした画像から判断すると、MAC はラインを適切にローに引き下げて論理 0 を送信することができず、書き込み期間全体にわたって 0V と 3.3V の間で非常に急激なスパイクが発生するようです。
- 私が見た限りでは、書き込みのタイミングは問題ないようです。

調べてみたところ、J16 コネクタの MDIO/PTB4 ピンに問題があるのではないかと思いました。下記のように適切に設定しましたが、オープンドレインコレクターとして動作していないようです。何か設定が足りないのでしょうか?

設定を変更して、MDC 周波数を 1 MHz に設定しました。そのため、画像では 1 MHz と表示されています。また、ホールド時間は 48MHz で 3 モジュール クロック サイクルに設定されています。

christopherlajoie_0-1753290612216.png

よろしくお願いします!

Re: MDIORead always returning 0xFFFF on RMII interface物理識別子1レジスタから物理ID番号を正常に読み取ることができたので、このCASE 0が正しいアドレスであると考えています。Re: MDIORead always returning 0xFFFF on RMII interface

CASE、他の PHY アドレスをスキャンしてみましたか?ストラップが適切に機能せず、PHY が予想とは異なるアドレスで起動するCASEがありました。

Re: MDIORead always returning 0xFFFF on RMII interface

こんにちは@christopherlajoie

提供されているすべての利用可能な構成ファイル、初期化コード、およびオシロスコープのキャプチャを確認しました。MDC 信号は正しく構成され、2.4 MHz で動作するようになりました。MDIO ラインには適切な 1.5 kΩ の外部プルアップ抵抗があり、ENET ペリフェラルは正しく初期化されています。これを踏まえると、残る問題は機能障害ではなく信号観測に関連していると思われます。

更新してすべてのデータを共有していただきありがとうございます。あなたの説明とオシロスコープのキャプチャに基づくと、あなたが観察しているMDIO信号の不安定性は、おそらく以下の原因によるものです。 アンダーサンプリング

  • 各 MDIO トランザクション (Clause-22 読み取り) は 64 ビットで構成され、クロック速度は約 2.4 MHz → 合計所要時間は約 27 µs です。
  • タイムベースが 500 µs/div の場合、オシロスコープはトランザクションごとに数個のサンプルしかキャプチャできません。
  • その結果、放電/充電曲線や「V 字型」の低下に似た歪んだ波形や部分的な波形が発生するCANがあります。

PHY 読み取りによって有効なデータが返され、MDC 信号が正しいことが確認されたため、MDIO ラインは正常に機能していると考えられます。

推奨される次のステップ:

  • オシロスコープを1~5µs/divに設定します。
  • MDC の立ち上がりエッジでトリガーします。
  • 既知の PHY_Read() 中にシングルショット モードでキャプチャします。

これにより、完全な MDIO トランザクションを観察し、信号の整合性を確認することができます。

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

パベル

Re: MDIORead always returning 0xFFFF on RMII interfaceまた、MDIOのV字型信号がMDCの立ち下がりエッジとタイミングが合わず、1.5V~2Vまでしか下がらないこともあります。Re: MDIORead always returning 0xFFFF on RMII interface

両方の信号が一緒に写っている写真がこちらです

Re: MDIORead always returning 0xFFFF on RMII interface

状況を更新したところ、MDC の正しいピンを多重化していなかったことが判明しました。変更後、MDC 信号は 2MHz で完璧です。ただし、MDIO の安定性にはまだ問題があります。Mac は PHY から読み取ることができますが、リンクの安定性はひどいです。オシロスコープから読み取った MDIO の画像をいくつか添付しました。私は、MII_RMII_MDIO であるピン PTB4 は、MAC と phy の両方が書き込めるようにするためにはオープン ドレインである必要があることを理解しました。ただし、ピン多重化メニュー内にそのオプションは表示されず、入力/出力ピンとしてロックされています。何らかの理由で、PHY と MAC が争っているような印象を受けます。また、写真上の 3.3V 付近の信号は、放電/充電曲線のように見えます。

Tags (1)
No ratings
Version history
Last update:
‎11-20-2025 04:38 PM
Updated by: