正文

上一篇文章跟大家聊了一下軟件開發中偶發性問題的處理辦法，這些都是手段，看似不是很難，其實最重要還是對問題的敏感度，而這份敏感度來源于你對整個系統的理解和把握。

當你能夠盡快的縮小問題代碼的范圍，在一定程度上就已經加快了解決問題的進度。在上一篇文章末尾bug菌提到MCU程序直接死了以后軟件上也有力不從心的時候，這時候我覺得你應該把做硬件的哥們揪過來了。

做嵌入式軟件的朋友們也不要太高估了自己，雖然大家可以把硬件秀起來，但是你拯救不了“無藥可救”的硬件。不要一頭扎到代碼的調試中，而是更多的分析現場和一些可能性的問題，先排查一些更加常見且易查的硬件問題，此時此刻示波器得秀起來~

1電源問題

對于電源問題引起的死機，在這么多年軟件調試過程中，至少有碰到過10次左右，特別是一些經驗不是特別豐富的軟件工程師們在開發的過程中很少去質疑硬件問題，所以一言不合就從嵌入式軟件開始排查，同時也有許多硬件伙計覺得軟件可以優化非常多的硬件問題。

所以嵌入式軟件沒有一定經驗在調試硬件問題會比較難受，那么對于電源這塊能量的核心，主要是電壓、功率和穩定性等。大部分芯片都會有一個穩定運行的電壓范圍，過高或者過低都有可能導致運行異常，注意是可能，不是一定，甚至同一個型號，不同批次的芯片都有所差異~

所以功率不夠，電壓過低會導致芯片內外供電不夠，使得相應模塊、外設運行異常，最終程序死機、跑飛是經常發生的。特別是整個系統的功率需求并不是特別穩定，且電源的設計并沒有太多的余量，當出現比如動作繼電器等等功耗較大的動作時，其電源就有可能出現不穩定狀態，最終影響到芯片運行。

當然如果你是購買的劣質或者參數虛標的電源，就要更多的去測試和監控一下電源的穩定程度了。

所以bug菌目前親自開發的項目，在項目的設計評審初期，會要硬件多留一個MCU的AD采樣電路用來實時采集供電電壓等，軟件內部做一些快速的電壓保護或者故障偵測，以檢測出大部分電源異常問題。

2復位電路干擾

相比電源問題會少一些，不過也遇到過幾次，大部分都是板子剛打樣回來上電調試的時候，MCU直接不運行的情況，大多都是復位電路中的電阻或者電容貼錯了，虛焊了等等;如果是采用復位芯片的大多估計供電不足，選型有問題等等。

不過有一次遇到是在PCB走線上，復位電路與功率部分挨得比較近導致MCU概率性復位，當然如果有使用外部看門狗的話就更需要排查一下了。

3晶振失效或受干擾

晶振本身失效或者受干擾，一般MCU都會選擇外部晶振，相比內部的會更加準確一些。

然而對于這個MCU的心臟也是有概率出問題的，之前有個項目采用定時測量時間，每次測量信號的誤差都是忽大忽小，后來直接把捕獲的信號用IO信號翻轉出來與實際信號進行對比，發現并無差異，才定位到是計時這塊的頻率出了問題，最終定位外部晶振電路存在干擾，導致時鐘頻率發生變化，最終影響測量結果，如果干擾再大一些估計就跑飛宕機了。

對于當出現了一些死機或者計時不準的問題，不僅僅要看軟件，也要從硬件晶振時鐘這塊進行排查，所以對于目前主流的一些MCU都會存在時鐘頻率輸出的引腳，一方面是用來供外部進行內部時鐘的監控，另外一個應用就是進行不同芯片之間時鐘上的同步。

4最后幾小點

最后，靜電問題說實在的在開發中真的是虛無縹緲的存在，曾經一個伙計徒手換芯片，10個芯片換上去，壞了一半，大概率是因為天氣比較干燥，用手觸碰了幾下芯片，后來硬件人手準備一套裝備~

同時在系統中與MCU沒有隔離的IO口，通信等等都要做好保護，這些對外的接口會把靜電、或者是浪涌電壓等引入MCU內部，使得MCU內部邏輯混亂導致死機。

高速運行的MCU會受外界輻射等電磁干擾，做好一些屏蔽措施等。

基本上遇到的MCU死機或者復位暫時就總結這么多吧，以后再想到一些再寫寫~

審核編輯：湯梓紅