我們從2016年開始零星使用395Q，當時是D版，做服務器時UDP丟包率超過50%(連發(fā)5個SNTP包)，網(wǎng)絡端不定期失聯(lián)(SPI端沒問題)，大約7天左右會出一次，斷電重啟才能恢復，基本沒法用，反應給貴司后回應可能2端數(shù)據(jù)處理沖突，正在想辦法解決。

?

2018年又撿起來試驗，目前版本F版，做UDP服務器時丟包率大約還有15%，有所改善，湊合能用，期間做了個維修用的設(shè)備，MACRAW方式LLC協(xié)議只發(fā)不收，現(xiàn)場24小時運行3個多月來挺好；

?

2019年繼續(xù)測試，這次同時使用socket 0和socket 3.
socket 3使用UDP協(xié)議客戶端發(fā)送SNTP包獲取時間，芯片硬復位后第一個發(fā)送的包必定丟失，返回超時，抓包軟件什么都看不到，后面正常，但是每次收發(fā)后都會多一個空中斷，就是全局中斷0x80套接字中斷0x00；
socket 0使用TCP長連接給服務器提供數(shù)據(jù)，只發(fā)現(xiàn)每次收發(fā)有空中斷。
測試中發(fā)現(xiàn)網(wǎng)絡端仍然有失聯(lián)現(xiàn)象，發(fā)作時間最短10小時，最長15天，發(fā)作后收不到任何東西，恢復方法：1.斷電重啟 2.RESET腳復位 3.拔一下網(wǎng)線

?

以上都是實際應用中積累的記錄，不是特意建立的試驗環(huán)境。

國產(chǎn)通用協(xié)議棧目前只找到貴司有生產(chǎn)，CH395比較適合我們小數(shù)據(jù)量使用，希望能完善發(fā)現(xiàn)的問題。
貼一些調(diào)試期間的狀態(tài)數(shù)據(jù)，其中G是全局中斷寄存器，S是套接字中斷寄存器，S0/S1是套接字狀態(tài)寄存器。

CH395 Hardware Version = 46
IP = 192.168.1.177
IP Gateway = 192.168.1.1
IP Mask = 255.255.255.0
MAC = 84.C2.E4.F8.34.C1
G=80,S=41,TCP ready, S0=00, S1=00
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 18
TCP send len = 10
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 10
TCP send len = 34
G=10,S=01,G=10,S=00,G=10,S=02,G=10,S=04,TCP receive len = 18
TCP send len = 10
G=10,S=01,G=10,S=00,G=10,S=02,G=80,S=03,G=80,S=04,SNTP receive len = 48G=80,S=00,

收到您的反饋，我們已經(jīng)安排人員在測試

您好，感謝對問題的耐心分享，帖子中關(guān)于芯片可靠性問題，之前并沒有客戶遇到過，還在復現(xiàn)分析中。

關(guān)于芯片復位后，第一包數(shù)據(jù)無法發(fā)送成功問題，應該是PHY復位后，重新初始化沒有來得及建立連接造成；

空中斷是指“SEND_BUF_FREE”? TCP 發(fā)送成功后正常會產(chǎn)生“SEND_BUF_FREE”和SEND_OK”中斷。

詳細技術(shù)問題可否電話溝通下，我的電話025-89692395

客戶您好，首先感謝您的反饋。根據(jù)您今年運用CH395的場景發(fā)現(xiàn)的問題，我將其分析為這四個問題：

1，用SOCKET 3發(fā)送sntp包獲取時間，第一個sntp請求包必丟;

2，在1中的使用環(huán)境下，每次收發(fā)會報一個空中斷；

3，用SOCKET 0做TCP客戶端時，也會有空中斷產(chǎn)生；

4，連續(xù)使用10小時到15天的時間長度內(nèi)，CH395會不定時死機；

??

? 針對這幾個問題，我使用CH395 socket 3走UDP協(xié)議定時一秒一包向國家授時中心服務器發(fā)送NTP請求包，并解析回復，以此希望復現(xiàn)出您提出的問題。時間有限我復現(xiàn)出您提出的前三個問題。我們會檢查CH395固件并最終解決這些問題。對于第一個必丟包的問題，您可以運用CH395的如下功能：每發(fā)出一個包，且成功發(fā)送，CH395都會報一個“SINT_STAT_SEND_OK”的SOCKET中斷，中斷值為0x10，您的sntp運用中第一個必丟的UDP包發(fā)送后不會產(chǎn)生這個中斷，當前運用時，如果您對UDP的發(fā)送成功率有要求，建議您寫一個檢測“SINT_STAT_SEND_OK”中斷的重發(fā)機制；針對第二個和第三個問題，確實有值為0x80的全局中斷產(chǎn)生，這個值的中斷屬于誤報，請忽視這個值的中斷。您提出的第四個問題我們還在測試中。

? 希望我的回復對您有幫助。歡迎您繼續(xù)在此帖中跟進或者直接聯(lián)系我：郵箱：lq@wch.cn，電話：025-52638373.

換個瀏覽器就可以回復了。。。。。

CH395的主要問題是2個，第一是網(wǎng)絡側(cè)會死機，收不到任何數(shù)據(jù)，剛開始以為地址之類的數(shù)據(jù)被破壞，專門寫了一段程序

驗證，結(jié)果一切正常，后發(fā)現(xiàn)插拔一次網(wǎng)線也可以恢復到正常狀態(tài)，期間發(fā)送是好的；目前在要求不高的地方做客戶端，

加入軟件看門狗，若干時間內(nèi)收不到回答就RESET腳硬復位，重新初始化，這樣勉強能夠使用。

第二個問題是UDP丟包，CH395做SNTP服務器端，和電腦點對點方式連接，電腦一次連發(fā)5個請求包，大約有15%的丟包率。

以上2個問題影響使用，其他作為用戶可以忽略，檢查固件用的。

第一：

? ? 網(wǎng)絡側(cè)死機，先檢查硬件網(wǎng)口燈狀態(tài)是否正常，其次檢查CH395能否被ping通，接下來再檢查CH395的中斷引腳電平狀態(tài)；如果只是單純的收不到數(shù)據(jù)，那么請確認是否是由于中斷信號丟失引起的，CH395的中斷引腳如果用作單片機的外部中斷，那么請將中斷觸發(fā)方式設(shè)置為低電平觸發(fā)，不要設(shè)置為邊沿觸發(fā)

第二：

? ? 關(guān)于UDP丟包的問題，丟包主要受外部網(wǎng)絡環(huán)境影響，和通信雙方之間的網(wǎng)絡構(gòu)成有關(guān)

上星期五通電樣機，今早發(fā)現(xiàn)Socket 3的UDP失聯(lián)(SNTP服務器端)，Socket 0的TCP短連接正常，長連接未試(104服務器端)，Socket 2的TCP短連接正常(Telnet 服務器端)，Ping正常。

顯然是CH395的固件BUG造成的，如果有內(nèi)部調(diào)試手段的話可以來我這里檢測，我也是南京的。

針對您目前的情況，建議您留一下您的公司信息和聯(lián)系人方式，我們會安排專人和您對接，您反應的情況可能與您的網(wǎng)絡測試環(huán)境也有關(guān)系，如果有必要，我們會派人去現(xiàn)場調(diào)試檢測。您也可以直接聯(lián)系我們技術(shù)人員：電話025-52638370

用戶信息里有

又發(fā)現(xiàn)新問題，TCP服務端大部分時間有重發(fā)包，偶爾一段時間正常，翻了翻論壇有人早就發(fā)生同樣問題：

http://wch.cn/bbs/thread-67676-1.html

當時回復把原因歸咎于網(wǎng)絡延時，但是仔細看看重發(fā)包沒到200ms就發(fā)出來了，我這里都是在100ms-150ms之間。

還有這一篇：

http://wch.cn/bbs/thread-67836-1.html

也許就是我在1樓寫的空中斷的來源吧。

104_20191008.zip

認真點好么

再寫一點，CH395網(wǎng)絡側(cè)崩潰是逐步發(fā)生的，首先UDP失去響應，若干時間后ping應答逐漸困難，直到無任何響應，此時tcp也無法連通。

如果這時拔掉網(wǎng)線過1分鐘再插上，基本可以恢復正常。

期間指示燈和SPI端一直正常

您好，關(guān)于您反饋的TCP重傳的問題，是TCP協(xié)議棧為了保證數(shù)據(jù)可靠性的機制，重傳不會影響正常傳輸，不會造成重復接收。

空中斷是由于CH395正在處理內(nèi)部中斷事物中，還沒有完全處理完，所以調(diào)用讀取中斷命令會顯示無中斷，待內(nèi)部處理完成后，INT引腳會恢復正常

使用貴公司ch395q，做熱插拔測試和服務器通信，拔網(wǎng)線初始化后剛開始一切正常，過幾分鐘再發(fā)數(shù)據(jù)包就是掉線，然后再初始化正常了

395Q網(wǎng)絡側(cè)死機的問題有進展了嗎？我們這邊也碰到了。。。而且是幾十個小時就會出現(xiàn)。目前實驗樣本還比較少，不能可靠復現(xiàn)，但短期內(nèi)已經(jīng)出現(xiàn)2次，沒有一直通信，第一次大概隔30多個小時后通信，第二次大概隔60多個小時后通信。PING不通，UDP無法通信。

這芯片問題這么多？