いつもお世話になっております。よしと申します。
アルファプロジェクト様のRX65Nマイコン搭載基板のTCP/IP部分の回路をそのまま活用して自作基板を製作しています。貴社のM3S-T4-Tinyのライブラリを用いて、TCP/IPの通信を実現したいと考えており、動作の確認を進めている状況にございます。
サンプルプログラムのベースは「RXファミリ 組み込み用 TCP/IP M3S-T4-Tiny 導入ガイド Firmware Integration Technology アプリケーションノート」にある「r20an0051xx0209-rx-t4-fit」の中の「rskrx65n_2mb_tcp_nonblocking」です。
現在困っているのが、PC - CPU基板間でTCP/IPの通信ができておらず、最終的には、PCとCPUそれぞれでサーバー側とクライアント側を用意して非同期に通信をしたいです。
他のフォーラム投稿も拝見をしておりまして、比較的似た現象にあるのが以下の投稿です。
https://community-ja.renesas.com/cafe_rene/forums-groups/beginners/f/002-2095199602/6122/rx65n-tcp私の方では、ETHER_CFG_MODE_SELを(1)にしてRMIIに設定をして、基板のIPアドレスを"192.168.0.3"、PC側のIPアドレスを"192.168.0.200"として動作を進めています。この投稿内で確認を促されている内容に沿って、以下は確認ができています。 ・「The link status is detected」はUnusedでLANケーブル挿すとcallback_link_onに来る。 LANケーブル抜くとcallback_link_offに来る。 ・ phy.cのphy_start_autonegotiate関数は正常に終了している。 lan_open関数も正常処理で終了している。
ここからいくつかご質問になります。
１．投稿内で確認を促されていて正常かどうか判断が分からない部分が以下になります。
ping実行時にARPのブロードキャストパケットがRX65N側で受信するはずで、t4_driver.c の以下コードにブレークすれば直前の条件判断にあるdriver_ret が正になっており、
何かデータを受信したということが確定です。とご指南の文面があるが、ping実行をしなくても常にここの処理へ入ってくる。
https://github.com/renesas-rx/rx-driver-package/blob/66374738dd2e915cd12192dd7dff350eff0cbe05/source/r_t4_driver_rx/r_t4_driver_rx_vx.xx/r_t4_driver_rx/src/t4_driver.c#L329
if (driver_ret > 0)と else if (driver_ret == 0)のどちらもブレイクを張ると処理が来ている状況で、正常かどうかが判断できておりません。
この状態は正常なものと判断して良さそうでしょうか？
２．この状態でpingを実行するとデフォルトが32バイト×4回送信なのですが、
「192.168.0.200 からの応答: 宛先ホストに到達できません。」と表示されるものの、3回失敗して1回成功となります。
ping実行回数を1回に指定すると1/1で成功していますので、pingは通っているものと認識していますが、継続して2回以上のping実行をすると失敗します。
2回目以降のping実行で失敗となるのはどのような理由が考えられますでしょうか？
⇒すみません、、、ping実行が1/1で成功していると記載しましたが、宛先ホストに到達できません。を見逃していました。
よって、pingは全く成功していない状態となります。
３．受信データを処理するcallbuck関数として以下を登録しています。こちらの関数に遷移してこないのはどの様な理由がありそうでしょうか？
ER tcp_nonblocking_server_callback(ID cepid, FN fncd , VP p_parblk)
こちらの環境は以下になります。
CS+forCC V8.10.00V3 for RX(CC-RX)ノードロックライセンス
CPU：R5F565N9BxFB
PHYデバイス：LAN8710AI-EZK-ABC(Microchip)
※アルファプロジェクト様の回路で採用されていました
PCとCPU基板はクロスケーブルで接続
初心者となり的を得た質問ができていないかもしれませんが宜しくお願いいたします。
よしさん
シェルティです、こんにちは。
以下スレッドでユーザさんの支援をさせていただきました。ルネサスの中の人です。M3S-T4-Tinyのライブラリの設計者です。
https://community-ja.renesas.com/cafe_rene/forums-groups/beginners/f/002-2095199602/6122/rx65n-tcp
RX65Nを用いたネットワークシステムの検討をいただきありがとうございます。「LANケーブル挿すとcallback_link_onに来る」ということで8割方組みあがっていてもう少しで完成するような印象を受けました。以下回答します。
>>１．投稿内で確認を促されていて正常かどうか判断が分からない部分が以下になります。
>> ：
>> この状態は正常なものと判断して良さそうでしょうか？
はい。正常です。
以下条件それぞれで起きていることを説明します。
if (driver_ret > 0)： 正常受信しています。driver_ret に入っている正数で示すバイトサイズの受信データが *buf に格納されています。デバッガのウォッチウィンドウ等で中身を確認してみてください。WiresharkというフリーソフトでLAN回線上のパケットをモニタ出来るので、パケット内容とウォッチウィンドウの内容を照合すると分かりやすいです。
マイコンボードとping通信等をしていない状態でもLAN回線上ではブロードキャストパケット(Etherフレーム先頭6バイトがall 0xff)が流れていることが多いので、マイコンボード側で特に通信処理をしてなくてもパケット受信毎にEtherの割り込みが発生し、この条件を満たします。
else if (driver_ret == 0)
受信APIを読んだときに特に受信パケットが無い場合の処理です。
通常はEther割込みで受信パケットをすぐ取得するのでdriver_ret は正数になるのですが、割込み処理が忙しすぎる等で受信パケットの処理が割込み駆動で実行しきれない場合、タイマ処理で定期的に受信処理を起動しています。そのときに受信パケットがないとこの条件を満たします。
>>２．この状態でpingを実行するとデフォルトが32バイト×4回送信なのですが、
>>2回目以降のping実行で失敗となるのはどのような理由が考えられますでしょうか？
特に思い当たらないです、すみません。
>>３．受信データを処理するcallbuck関数として以下を登録しています。こちらの関数に遷移してこないのはどの様な理由がありそうでしょうか？
>>ER tcp_nonblocking_server_callback(ID cepid, FN fncd , VP p_parblk)
cepidを指定したTCP関連のAPI(例えばTCP接続を待ち受ける tcp_acp_cep()等)が完了することがこの関数に遷移する条件ですので、遷移してこない理由としては、「TCP関連のAPIが完了していない」になります。
ここまでの内容から原因を推測しますと、Ether関連の端子設定がボード仕様と完全には合致していない（部分的に合っているのでLinkはOKになったり、受信処理が動いているようには見える）のでは、と思います。以下2点をご確認いただけますか。
(1) Wireshark を使いパケットモニタし、実際のパケットとマイコン内部のメモリに展開された受信データを照合する
→完全合致していればEther関連端子設定に問題なし。受信データがT4ライブラリに入力された後のソフトウェア上の問題となるため、T4ライブラリの設定（DHCPとかIPアドレスとか）を更に確認していくと良いと思います。まずはping応答が出来るところを目指すのが良いです。
(2) (1)が照合できない場合（受信パケットが部分的に欠落しているなど）は端子設定またはハードウェアの問題の可能性を確認
→Etherの端子設定はスマートコンフィグレータの利用がおすすめです。以下利用方法をまとめていて参考になるかもしれません。ご利用いただいているボードの回路図をよく確認し、スマートコンフィグレータの設定と合致しているか端子1個ずつの設定をご確認ください。
https://github.com/renesas/rx72n-envision-kit/wiki/1-Ether-TCP-IP
あと、アルファプロジェクト様の回路参照されているとのことなので、少しおかねはかかりますが、アルファプロジェクト様のボードを購入してきて、アルファプロジェクト様のサンプルコードを動かしてみてソフトウェア挙動を見るためのリファレンスとする、というのも良い手段と思います。アルファプロジェクト様のサンプルもT4ライブラリを使っていらっしゃると思います。
以上です
シェルティさんご返信ありがとうございます。種々確認を行いまして、何となくですが原因が特定できた次第でございます。結果論となりますが、pingが通ってサーバーとして送受信ができる所まで来ました。原因となったのは、PHYチップのRESETではないかと推察しております。E1を接続してデバッガにてSTEP実行をしながら試行錯誤を繰り返していたのですが、ソフトウェアの設定を色々と変更しつつ、動作確認を行っていたことで、E1からCPUはRESETが実行されますが、PHYチップへのRESETはボードの電源をOFFにしない限り実行されることがなく、不定な設定状態のままソフトの試行錯誤を繰り返していたと見ています。ある時に休憩を取る際にボードの電源を落としたことがきっかけで、電源OFF前とON後の挙動が異なることに気づきました。一つずつあるべき状態を確認しながら進めていく事で、何とか通信ができる状態まで辿り着くことができたという感じです。もう一つご質問があるのですが、IPアドレスやポート番号は動的に変更することはできないものでしょうか？define定義でハードコーディングされている値を、外部取得してきた設定値を反映したいと考えております。ご多忙のところ恐縮ですがご指導頂けますと幸いです。
こんにちは、シェルティです。
なるほどPHYチップのリセット端子でしたか。私も過去1度はまったことがある罠ですね。確認項目として挙げられず、力不足ですみません。またよしさんが根気強い解析により原因を掴み取ったこと、とても素晴らしいと思います。
PHYチップのリセット端子が仮にマイコンの汎用ポートと接続されている場合、電源ON後に改めてマイコンの汎用ポートからHi/Lo信号を出してリセット解除してやるのが良いですね。おそらくはボード自体の電源ON/OFFで挙動が変わることからPHYチップのリセット端子は何も繋がっていないかマイコン関連リセットとは別系統のリセット回路が実装されているものと思います。ボード設計者と相談してPHYチップへのリセット信号の適切な入力方法を確認するのが良さそうですね。
さてもう一つの質問ですが、IPアドレスやポート番号の動的変更は可能です。
IPアドレスを変えるには、tcpudp_envのIPアドレスのメンバ内容を変更、になります。
https://github.com/renesas/rx-driver-package/blob/16c0de74501df2e91767db192b4879ab03caf114/source/r_t4_rx/r_t4_rx_vx.xx/r_t4_rx/ref/config_tcpudp_reference.tpl#L244
(T4が待ち受ける) ポート番号を変えるには、tcp_crepのポート番号のメンバ内容を変更、になります。
https://github.com/renesas/rx-driver-package/blob/16c0de74501df2e91767db192b4879ab03caf114/source/r_t4_rx/r_t4_rx_vx.xx/r_t4_rx/ref/config_tcpudp_reference.tpl#L97
tcpudp_close()で一旦TCP/IP動作を停止し、上記メンバを変更、再度tcpudp_open()で設定値が変わります。
ただ、IPアドレスの方は_t4_dhcp_enableがONになっているとDHCPで取得したIPアドレスで上書きされるので、自分が指定したIPアドレスを利用したい場合はDHCPをOFFにしてください。
https://github.com/renesas/rx-driver-package/blob/16c0de74501df2e91767db192b4879ab03caf114/source/r_t4_rx/r_t4_rx_vx.xx/r_t4_rx/ref/config_tcpudp_reference.tpl#L93
シェルティさんご教示ありがとうございました。試しにIPアドレスをopen前に変更すると反映されることが確認できました。ポート番号の方は、tcp_crepがconst付になるので、const修飾子を無くして確認しますとポート番号も任意の値に変更され、接続動作としても指定ポート番号以外では接続されなくなりました。種々のアドバイスありがとうございました。