您好，你的數據包里面還有DHCP協(xié)議數據包的收發(fā)，直接連PC的時(shí)候需要關(guān)閉DHCP的使能。

你好，我這個(gè)問(wèn)題解決了，是復位腳的問(wèn)題，謝謝

你好，我描述一下我的問(wèn)題，我這邊采用CH395Q，8個(gè)socket全部使用，其中7個(gè)作為UDP客戶(hù)端，一個(gè)作為T(mén)CP客戶(hù)端；

出現的現象呢是：之前8個(gè)socket一起打開(kāi)時(shí)會(huì )出現程序運行期間突然收到一個(gè)Tcp Connect 中斷，然后某socket突然接受到大量數據（大量ffff），然后所有的socket狀態(tài)就變成了ff，

起初我以為是TCP socket的問(wèn)題，然后我將TCPsocket代碼屏蔽后依然會(huì )出現這個(gè)問(wèn)題。經(jīng)過(guò)數分鐘后，可以自動(dòng)恢復，不清楚是什么原因。

您好，先確定開(kāi)啟的8個(gè)socket能正常通信。程序默認分配4個(gè)socket的量，使用8個(gè)socket需要重新分配緩沖區。

緩沖區我是重新分配了的

您好，相關(guān)問(wèn)題可聯(lián)系我司網(wǎng)絡(luò )產(chǎn)品線(xiàn)技術(shù)支持，可以詳述問(wèn)問(wèn)題情況。http://www.fszrt.cn/services/technical_support.html?

?

我們使用CH395Q和W5500進(jìn)行背板以太網(wǎng)通信（無(wú)變壓器，通過(guò)0.1uF電容耦合），現在上電會(huì )偶發(fā)二者無(wú)法通信，重新掉電之后又好了，請問(wèn)可能是什么原因？另外貴司的電話(huà)技術(shù)支持也太拉跨了，換了幾個(gè)人感覺(jué)就沒(méi)一個(gè)懂的，就在那兒沉默，敷衍，不解決問(wèn)題也不提供思路，真的氣。

工程師您好，首先對您不愉快的咨詢(xún)過(guò)程深表歉意，不論是您方的期望還是我司方的目的都會(huì )以解決客戶(hù)問(wèn)題為首要，希望能您能多支持。我們接受對產(chǎn)品不足上的批評，但同時(shí)希望之后在電話(huà)咨詢(xún)的過(guò)程中減少對公司、產(chǎn)品及通話(huà)人的罵責行為，能在通話(huà)過(guò)程中提供有效的問(wèn)題信息。

以下是想對一些問(wèn)題進(jìn)行詢(xún)問(wèn)

（1）是否經(jīng)過(guò)調試測試，對兩顆芯片哪一方存在的問(wèn)題（鑒于您在另外一個(gè)帖子中說(shuō)的是插座鏈接，大致上可以交換兩端芯片? ? ? ? ? ?板的種類(lèi)進(jìn)行測試）。

（2）以太網(wǎng)通信不上，是指物理層Link不上，還是指傳輸層的通信收發(fā)問(wèn)題（包括使用UDP無(wú)法發(fā)送或是TCP模式下無(wú)法握手? ? ? ? ? ?成功），可以詳述問(wèn)題狀況。

（3)? 您說(shuō)的上電偶發(fā)“二者無(wú)法通信的狀況”是指如果上電后能通信便一直正常，上電后不正常就無(wú)法恢復的現象嗎？

（4）您直接用的背板通信，雖然相對來(lái)說(shuō)是小負載驅動(dòng)，但還是除了必需的耦合電容之外還是在收發(fā)線(xiàn)路上加上上拉，以增強? ? ? ? ? ?穩定的驅動(dòng)性。

（5）您使用的FPGA進(jìn)行驅動(dòng)，還是希望提供能反映運行過(guò)程的信息，比如FPGA驅動(dòng)CH395出問(wèn)題時(shí)狀態(tài)機的狀態(tài)位，和讀? ? ? ? ? ? ?取到的CH395本身的運行狀態(tài)信息。

（6）上電“偶發(fā)二者無(wú)法通信”現象，是否此次上電前保持過(guò)較長(cháng)時(shí)間掉電狀態(tài)？

通過(guò)您的描述，出問(wèn)題的情況基本固定在上電時(shí)刻（即假設上述第 2 項成立），在此狀況下提供的假設建議：

（1）網(wǎng)絡(luò )口通過(guò)50cm的傳輸線(xiàn)進(jìn)行傳輸此前沒(méi)有做過(guò)相關(guān)的驗證，鑒于您之前在其他帖子下的發(fā)問(wèn)，可能的問(wèn)題可以看一? ? ? ? ? ? ? ?下：?http://www.fszrt.cn/bbs/thread-65673-1.html? 的帖子。

（2）芯片啟動(dòng)時(shí)刻整個(gè)通信線(xiàn)路上的信號循環(huán)反射程度基本上是最強的時(shí)刻，并且電源線(xiàn)上的電壓振鈴會(huì )增加芯片啟動(dòng)的不穩

? ? ? ? ?定性

（3）信號線(xiàn)下層和兩邊都要盡量鋪地，兩邊地上并排打上過(guò)孔

（4）中間加上的電容主要是隔直作用，但若兩者本身的交流信號存在差異，0.1uF不是固定值，可以依據實(shí)際帶寬進(jìn)行優(yōu)化? ? ? ? ? ? ?（鑒于正常傳輸下始終正常傳輸，很可能還是上啟動(dòng)存在問(wèn)題），可以適當降低電容值，或者在電容旁并聯(lián)兆歐電阻或者? ? ? ? ? ? ? 串聯(lián)小幾十歐姆左右電阻）。

? 在目前您有的通信板的情況下，建議做的測試項：

（1）可以交換兩端芯片板的種類(lèi)進(jìn)行測試（CH395與CH395，CH395與W5500，W5500與W5500）

（2）監測 INT RSTI SEL等重要功能腳上電前后的電平位，查看正常不正常時(shí)是否有明顯的分別。

（2）嘗試給CH395與其FPGA主控和W5500及其FPGA主控先后上電（可改變上電的先后順序），看是否減少甚至不復現異常? ? ? ? ? ?的概率。

（3）嘗試增加各CH395Q電源周?chē)椭麟娫摧斎氲臑V波電容的電容值

（4）監測出現異常狀況時(shí)候CH395芯片的晶振的起振狀態(tài)

（5）如果信號線(xiàn)上未接電阻上拉，建議飛線(xiàn)嘗試

CH395 TCP服務(wù)器端，在傳輸過(guò)程中斷開(kāi)連接的問(wèn)題：

將CH395配置成主機端模式，并發(fā)送數據，在發(fā)送過(guò)程中，會(huì )出現斷開(kāi)連接的問(wèn)題，用CMD_GET_INT_STATUS_SN獲取狀態(tài)，獲取到值為SINT_STAT_DISCONNECT （socket斷開(kāi)狀態(tài)）。

現在按照討論區的方法，進(jìn)行重連，如果直接按照open socket 再監聽(tīng)的步驟，會(huì )出現1B（已被使用）或者17（連接關(guān)閉）的問(wèn)題。

現在想咨詢(xún)遇到該問(wèn)題的解決步驟和問(wèn)題排查方法.

（1）可能是接收線(xiàn)程調度的問(wèn)題。由于其他線(xiàn)程在某時(shí)刻的占用導致對端發(fā)送的數據無(wú)法及時(shí)接收。

（2）主要可能是數據接收的后處理導致?？梢云帘翁幚泶a，單純的接收測試，如測試后確定與接收后處理有關(guān)，請對處理項

? ? ? ?? 逐一調試。

技術(shù)支持你好，請問(wèn)可以提供一份使用STM32的SPI接口驅動(dòng)CH395的例程嗎？最好是使用FREERTOS系統的。

謝謝。

您好，只有裸機程序，暫無(wú)操作系統。已發(fā)送至您郵箱。

謝謝

您好，我用CH395Q的socket1發(fā)送UDP數據，電腦一直無(wú)法收到，而socket中斷一直回饋數據為0x41，根據手冊描述，是空閑以及超時(shí)中斷？超時(shí)中斷是怎么產(chǎn)生的？我電腦的IP和端口設置都正確。

您好，UDP協(xié)議下第一包數據可能因為為存在A(yíng)RP而發(fā)送失敗，需要在超時(shí)終端里補發(fā)。