嵌入式開發問題排查

很多人認為嵌入式開發很難，主要是因為在這個過程中常常會遇到各式各樣的問題。這些問題的復雜性和多樣性使得許多人感到困惑和無所適從。然而，如果將這些問題逐一拆解，實際上大部分都可以歸結為相對簡單的小問題。接下來，我們將討論一些嵌入式開發中常見的問題及其解決方法。

一、問題復現

要有效解決問題，首先需要能夠穩定地復現它。一般來說，容易復現的問題也相對容易解決。

• 模擬復現條件

某些問題只在特定環境下發生。通過模擬這些條件，就能成功復現問題。如果外部輸入條件復雜，可以考慮在程序中預設某些狀態來直接觸發問題。

• 提高相關任務執行頻率

如果某個任務運行時間較長后才出現異常，可以提高該任務的執行頻率，以便更快地觀察到問題。

• 增大測試樣本量

當程序長時間運行后才出現異常時，單一設備的測試可能不夠，可以搭建多個設備的測試環境，從而提高發現問題的概率。

二、問題定位

在復現問題的基礎上，接下來要縮小排查范圍，以確認引發問題的具體任務、函數或代碼語句。

• 打印LOG

在可疑代碼段增加LOG輸出，可以幫助追蹤程序的執行流程及關鍵變量的值，觀察這些值是否符合預期。

• 在線調試

在線調試能夠與打印LOG類似地追蹤問題，特別適合于排查程序崩潰類的錯誤。當程序進入異常狀態（如HardFault或看門狗中斷）時，可以直接暫停程序，查看調用棧和寄存器的值，從而快速定位問題。

• 版本回退

使用版本管理工具（如git）時，可以通過逐步回退代碼版本并進行測試，來定位首次引入問題的版本，之后再圍繞該版本的改動進行排查。

• 二分注釋

這種方法類似于二分查找，通過注釋掉一部分代碼來判斷問題是否由被注釋的部分引起。具體做法是分批注釋代碼，逐步縮小范圍，直到找到引發問題的代碼段。

通過上述方法，可以有效解決嵌入式開發中的常見問題，從而降低開發的難度感。

• 保存內核寄存器快照

Cortex M內核陷入異常中斷時會將幾個內核寄存器的值壓入棧中，如下圖：我們可以在陷入異常中斷時將棧上的內核寄存器值寫入RAM的一段復位后保留默認值的區域內，執行復位操作后再從RAM將該信息讀出并分析，通過PC、LR確認當時執行的函數，通過R0-R3分析當時處理的變量是否異常，通過SP分析是否可能出現棧溢出等。

三、問題分析處理

結合問題現象以及定位的問題代碼位置分析造成問題的原因。

3.1 程序繼續運行

3.1.1 數值異常

3.1.1.1 軟件問題

1、數組越界

寫數組時下標超出數組長度，導致對應地址內容被修改。如下：

此類問題通常需要結合map文件進行分析，通過map文件觀察被篡改變量地址附近的數組，查看對該數組的寫入操作是否存在如上圖所示不安全的代碼，將其修改為安全的代碼。

2、棧溢出

在分析棧溢出問題時，結合map文件的內容是非常重要的。假設棧是從高地址向低地址增長的，當發生棧溢出時，g_val的值可能會被棧中的其他值覆蓋。為了有效分析棧的最大使用情況，需要注意以下幾點：函數調用層數過多、中斷服務函數中進行額外的函數調用，以及在函數內聲明較大的臨時變量，都可能導致棧溢出。

為了解決這些問題，可以采取以下措施：

• 合理分配內存資源：在設計階段，應為棧設置合適的大小，以預防棧溢出。
• 使用靜態變量：對于函數內較大的臨時變量，可以使用static關鍵字將其轉化為靜態變量，或者通過malloc()動態分配內存，將其放置在堆上。
• 優化函數調用結構：降低函數的調用層數，以減少棧的使用深度。

通過以上方法，可以有效降低棧溢出的風險，保障程序的穩定性。

3、判斷語句條件寫錯

判斷語句的條件容易把相等運算符“==”寫成賦值運算符“=”導致被判斷的變量值被更改，該類錯誤編譯期不會報錯且總是返回真。建議將要判斷的變量寫到運算符的右邊，這樣錯寫為賦值運算符時會在編譯期報錯。還可以使用一些靜態代碼檢查工具來發現此類問題。

4、同步問題

例如操作隊列時，出隊操作執行的過程中發生中斷(任務切換)，并且在中斷(切換后的任務)中執行入隊操作則可能破壞隊列結構，對于這類情況應該操作時關中斷（使用互斥鎖同步）。

5、優化問題

如上圖程序，本意是等待irq中斷之后不再執行foo()函數，但被編譯器優化之后，實際運行過程中flg可能被裝入寄存器并且每次都判斷寄存器內的值而不重新從ram里讀取flg的值，導致即使irq中斷發生foo()也一直運行，此處需要在flg的申明前加“volatile”關鍵字，強制每次都從ram里獲取flg的值。

3.1.1.2 硬件問題

1、芯片BUG

芯片本身存在BUG，在某些特定情況下給單片機返回一個錯誤的值，需要程序對讀回的值進行判斷，過濾異常值。

2、通信時序錯誤

例如電源管理芯片Isl78600，假設現在兩片級聯，當同時讀取兩片的電壓采樣數據時，高端芯片會以固定周期通過菊花鏈將數據傳送到低端芯片，而低端芯片上只有一個緩存區.如果單片機不在規定時間內將低端芯片上的數據讀走那么新的數據到來時將會覆蓋當前數據，導致數據丟失。此類問題需要仔細分析芯片的數據手冊，嚴格滿足芯片通信的時序要求。

3.1.2 動作異常

3.1.2.1 軟件問題

1、設計問題

設計中存在錯誤或者疏漏，需要重新評審設計文檔。

2、實現與設計不符

代碼的實現與設計文檔不相符需要增加單元測試覆蓋所有條件分支，進行代碼交叉review。

3、狀態變量異常

例如記錄狀態機當前狀態的變量被篡改，分析該類問題的方法同前文數值異常部分。

3.1.2.2 硬件問題

1、硬件失效

目標IC失效，接收控制指令后不動作，需要排查硬件。

2、通信異常

與目標IC通信錯誤，無法正確執行控制命令，需要使用示波器或邏輯分析儀去觀察通信時序，分析是否發出的信號不對或者受到外部干擾。

3.2 程序崩潰

3.2.1 停止運行

3.2.1.1 軟件問題

1、HardFault

以下情況會造成HardFault：

• 在外設時鐘門未使能的情況下操作該外設的寄存器；
• 跳轉函數地址越界，通常發生在函數指針被篡改，排查方法同數值異常；
• 解引用指針時出現對齊問題：

以小端序為例，如果我們聲明了一個強制對齊的結構體如下：

此時a.val1的地址為0x00000001，如果以uint16_t類型去解引用此地址則會因為對齊問題進入HardFault，如果一定要用指針方式操作該變量則應當使用memcpy()。

2、中斷服務函數中未清除中斷標志

中斷服務函數退出前不正確清除中斷標志，當程序執行從中斷服務函數內退出后又會立刻進入中斷服務函數，表現出程序的“假死”現象。

3、NMI中斷

調試時曾遇到SPI的MISO引腳復用NMI功能，當通過SPI連接的外設損壞時MISO被拉高，導致單片機復位后在把NMI引腳配置成SPI功能之前就直接進入NMI中斷，程序掛死在NMI中斷中。這種情況可以在NMI的中斷服務函數內禁用NMI功能來使其退出NMI中斷。

3.2.1.2 硬件問題

1、晶振未起振

2、供電電壓不足

3、復位引腳拉低

3.2 .2 復位

3.2.2.1 軟件問題

1、看門狗復位

除了喂狗超時導致的復位以外，還要注意看門狗配置的特殊要求，以Freescale KEA單片機為例，該單片機看門狗在配置時需要執行解鎖序列（向其寄存器連續寫入兩個不同的值），該解鎖序列必須在16個總線時鐘內完成，超時則會引起看門狗復位。此類問題只能熟讀單片機數據手冊，注意類似的細節問題。

3.2.2.2 硬件問題

1、供電電壓不穩

2、電源帶載能力不足

四、回歸測試

問題解決后需要進行回歸測試，一方面確認問題是否不再復現，另一方面要確認修改不會引入其他問題。