背景

前段時間接到一個項目，要求用主控用485和MCU通信。將代碼調(diào)試好之后，驗證沒問題就發(fā)給測試了。測試測的也沒問題。

但是，到設備量產(chǎn)時，發(fā)現(xiàn)有幾臺設備功能異常。將設備拿回來排查，發(fā)現(xiàn)是485通信有問題，偶現(xiàn)通信失敗。

排查思路

復現(xiàn)問題

發(fā)給測試之前，功能都驗證了很多次，但是并沒有發(fā)現(xiàn)通信失敗的問題。設備拿到手，第一時間就嘗試復現(xiàn)通信失敗的問題，也沒有成功。

于是，寫了一個腳本，不斷的和MCU通信，看什么情況下會失敗。

果然，在通信若干次后，發(fā)現(xiàn)日志異常，主控接收數(shù)據(jù)出現(xiàn)了錯亂。

接著，繼續(xù)跑腳本，想看下什么情況下會失敗。但是，每次通信異常的時機都是隨機的，沒有規(guī)律。

觀察了下錯亂的數(shù)據(jù)，和正確的數(shù)據(jù)做了對比，也沒有什么發(fā)現(xiàn)。

清空buf

接收的數(shù)據(jù)出現(xiàn)了異常，第一個想到的是，是不是接收buffer不干凈，有其他數(shù)據(jù)干擾呢？

嘗試在接收buffer和發(fā)送buffer之前，手動清空下buf。確保不會有其它數(shù)據(jù)干擾。

重新跑腳本和MCU 通信，但是仍會失敗。

收發(fā)時序

光看是什么辦法了。上示波器看下主控和MCU的時序的。

正常來講，主控和MCU的485控制管腳應該是正好反向的電平。即主控485控制管腳高電平發(fā)送的時候，MCU的485控制管腳應該是低電平。

問題復現(xiàn)時，對比了管腳的電平，確實是反向的，沒有問題。這也排除了收發(fā)時序?qū)Σ簧系膯栴}。

(綠色的是MCU的485控制管腳，黃色的是主控的485控制管腳)

收發(fā)數(shù)據(jù)正確

小示波器沒有解碼的功能，只能找硬件來量下主控的RX和MCU的TX。確認下，到底是主控接收的不對，還是MCU發(fā)的不對。

顯然，是主控接收的數(shù)據(jù)有問題了。

仔細觀察會發(fā)現(xiàn)，綠色波形這里有個半高電平，覆蓋了黃色的低電平。導致第一幀出錯了，后面的數(shù)據(jù)也都錯亂了。

又重新復現(xiàn)了幾次，發(fā)現(xiàn)每次失敗時都是這種現(xiàn)象。那為什么這里會有個半高電平呢？

確認問題

和硬件對著原理圖經(jīng)過一番討論，硬件給到的結(jié)論是，485芯片的RX管腳接了3.3V的上拉，只有當485芯片的使能管腳拉高時，RX才會有3.3V的半高電平出現(xiàn)。硬件懷疑是485控制管腳和MCU的時序沒對上。

不過，我之前也量了主控和MCU的485控制管腳的電平，看了是對的？難道是我看錯了？

接著又重新量了主控和MCU的485控制管腳，發(fā)現(xiàn)確實有問題，具體如下圖。兩者有1.5ms的高電平是重合的，這或許就是問題所在！

又重新復現(xiàn)了幾次問題，發(fā)現(xiàn)每次通信失敗時，都會有一段高電平是重合的。

到這里，基本也就明確了問題原因：主控和MCU的485控制管腳時序沒對上！

尋找問題根因

從波形找出了問題所在，回歸串口編程，繼續(xù)看下代碼吧。把重點放在了時序切換的代碼上。

代碼里面，在切換485管腳時有這樣兩段代碼。

以下只是偽代碼

代碼一：

setdir(SEND)??//切換為發(fā)送狀態(tài)
write()????//發(fā)送數(shù)據(jù)
tcdrain(fd)???//判斷是否寫完
setdir(READ)??//切換為讀狀態(tài)

代碼二：

do
{
?ioctl(fd,TIOCSERGETLSR,&lsr)?//判斷發(fā)送buffer是否寫完
}while(!(lsr&TIOCSER_TEMT))?//如果TX為空，返回TIOCSER_TEMT

這兩段代碼，都是和485管腳切換相關的，根據(jù)不同情況走不同邏輯，出問題的代碼走的是代碼一片段。

tcdrain 和 TIOCSERGETLSR

那這兩段代碼有什么區(qū)別呢？

tcdrain是應用層控制tty的一個函數(shù)，調(diào)用 tcdrain()函數(shù)后會使得應用程序阻塞， 直到串口輸出緩沖區(qū)中的數(shù)據(jù)全部發(fā)送完畢為止。

ioctl(fd,TIOCSERGETLSR,&lsr)是獲取tty 設備的線路狀態(tài)寄存器( LSR )的值。

這兩段代碼最大區(qū)別就是延時不同！

tcdrain()是等待fd所引用的串口設備數(shù)據(jù)傳輸完畢。雖然在物理上數(shù)據(jù)已傳輸完畢時，但Linux對硬件實時性高，對于用戶請求的實時性較低。所以操作系統(tǒng)會有延時，導致tcdrain()多停留幾ms，從而導致數(shù)據(jù)發(fā)送完后，485管腳的控制方向不能及時切換。

如果對接的485設備，接收和應答的延遲小于tcdrain()的延時，那方向切換不及時將導致數(shù)據(jù)接收丟失。這就是問題根因所在。

那為什么操作系統(tǒng)會有延時呢？

這個得說說Linux工作隊列相關機制，對于硬件操作Linux處理的很及時，但是對于數(shù)據(jù)Linux可能將其交給系統(tǒng)的下半部的內(nèi)核線程去處理，這就可能導致用戶的系統(tǒng)調(diào)用存在一定的延時，而485通信對時間要求又很嚴格，1ms的延時就會導致數(shù)據(jù)錯亂。

總結(jié)

嚴謹細致。在問題發(fā)生時，我也去量過主控和和MCU 485控制管腳的電平，只看到了兩者是反向的，但是并沒有放大去看最后一段電平的細節(jié)。導致遺漏了解決問題的線索。

一切問題發(fā)生都是有原因的。偶現(xiàn)問題并不好排查，但是我們可以嘗試制作偶現(xiàn)問題發(fā)生的條件，看有沒有可能成為必現(xiàn)問題。如果不能必現(xiàn)，可嘗試通過腳本去不斷運行在問題發(fā)生的場景，使其出現(xiàn)的概率提升。

心態(tài)。放平心態(tài)，多看代碼。認真分析。

審核編輯：黃飛

?