關(guān)注+星標公眾號，不錯過精彩內(nèi)容

來源 | 博客園

嵌入式開發(fā)不單純是軟件的事，很多時候，硬件也可能存在問題。今天就來說說一些常見的問題及解決方法。

一、問題復現(xiàn)

穩(wěn)定復現(xiàn)問題才能正確的對問題進行定位、解決以及驗證。一般來說，越容易復現(xiàn)的問題越容易解決。

1.1 模擬復現(xiàn)條件

有的問題存在于特定的條件下，只需要模擬出現(xiàn)問題的條件即可復現(xiàn)。對于依賴外部輸入的條件，如果條件比較復雜難以模擬可以考慮程序里預設直接進入對應狀態(tài)。

1.2 提高相關(guān)任務執(zhí)行頻率

例如某個任務長時間運行才出現(xiàn)異常則可以提高該任務的執(zhí)行頻率。

1.3 增大測試樣本量

程序長時間運行后出現(xiàn)異常，問題難以復現(xiàn)，可以搭建測試環(huán)境多套設備同時進行測試。

二、問題定位

縮小排查范圍，確認引入問題的任務、函數(shù)、語句。

2.1 打印LOG

根據(jù)問題的現(xiàn)象，在抱有疑問的代碼處增加LOG輸出，以此來追蹤程序執(zhí)行流程以及關(guān)鍵變量的值，觀察是否與預期相符。

2.2 在線調(diào)試

在線調(diào)試可以起到和打印LOG類似的作用，另外此方法特別適合排查程序崩潰類的BUG，當程序陷入異常中斷(HardFault，看門狗中斷等)的時候可以直接STOP查看call stack以及內(nèi)核寄存器的值，快速定位問題點。

2.3 版本回退

使用版本管理工具時可以通過不斷回退版本并測試驗證來定位首次引入該問題的版本，之后可以圍繞該版本增改的代碼進行排查。

2.4 二分注釋

二分注釋即以類似二分查找法的方式注釋掉部分代碼，以此判斷問題是否由注釋掉的這部分代碼引起。

具體方法為將與問題不相干的部分代碼注釋掉一半，看問題是否解決，未解決則注釋另一半，如果解決則繼續(xù)將注釋范圍縮小一半，以此類推逐漸縮小問題的范圍。

2.5 保存內(nèi)核寄存器快照

Cortex M內(nèi)核陷入異常中斷時會將幾個內(nèi)核寄存器的值壓入棧中，如下圖：

我們可以在陷入異常中斷時將棧上的內(nèi)核寄存器值寫入RAM的一段復位后保留默認值的區(qū)域內(nèi)，執(zhí)行復位操作后再從RAM將該信息讀出并分析，通過PC、LR確認當時執(zhí)行的函數(shù)，通過R0-R3分析當時處理的變量是否異常，通過SP分析是否可能出現(xiàn)棧溢出等。

三、問題分析處理

結(jié)合問題現(xiàn)象以及定位的問題代碼位置分析造成問題的原因。

3.1 程序繼續(xù)運行

3.1.1 數(shù)值異常

3.1.1.1 軟件問題

1、數(shù)組越界

寫數(shù)組時下標超出數(shù)組長度，導致對應地址內(nèi)容被修改。如下：

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

2、棧溢出

0x20001ff8

g_val

0x20002000	棧底
…………	?？臻g
0x20002200	棧頂

如上圖，此類問題也需要結(jié)合map文件進行分析。假設棧從高地址往低地址增長，如果發(fā)生棧溢出，則g_val的值會被棧上的值覆蓋。微信搜索readdot，關(guān)注后回復編程資源獲取23種精品資料

出現(xiàn)棧溢出時要分析棧的最大使用情況，函數(shù)調(diào)用層數(shù)過多，中斷服務函數(shù)內(nèi)進行函數(shù)調(diào)用，函數(shù)內(nèi)部申明了較大的臨時變量等都有可能導致棧溢出。

解決此類問題有以下方法：

• 在設計階段應該合理分配內(nèi)存資源，為棧設置合適的大??；

• 將函數(shù)內(nèi)較大的臨時變量加”static”關(guān)鍵字轉(zhuǎn)化為靜態(tài)變量，或者使用malloc()動態(tài)分配，將其放到堆上；

• 改變函數(shù)調(diào)用方式，降低調(diào)用層數(shù)。

3、判斷語句條件寫錯

判斷語句的條件容易把相等運算符“==”寫成賦值運算符“=”導致被判斷的變量值被更改，該類錯誤編譯期不會報錯且總是返回真。

建議將要判斷的變量寫到運算符的右邊，這樣錯寫為賦值運算符時會在編譯期報錯。還可以使用一些靜態(tài)代碼檢查工具來發(fā)現(xiàn)此類問題。

4、同步問題

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

5、優(yōu)化問題

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

3.1.1.2 硬件問題

1、芯片BUG

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

2、通信時序錯誤

例如電源管理芯片Isl78600，假設現(xiàn)在兩片級聯(lián)，當同時讀取兩片的電壓采樣數(shù)據(jù)時，高端芯片會以固定周期通過菊花鏈將數(shù)據(jù)傳送到低端芯片，而低端芯片上只有一個緩存區(qū).

如果單片機不在規(guī)定時間內(nèi)將低端芯片上的數(shù)據(jù)讀走那么新的數(shù)據(jù)到來時將會覆蓋當前數(shù)據(jù)，導致數(shù)據(jù)丟失。此類問題需要仔細分析芯片的數(shù)據(jù)手冊，嚴格滿足芯片通信的時序要求。

3.1.2 動作異常

3.1.2.1 軟件問題

1、設計問題

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

2、實現(xiàn)與設計不符

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

3、狀態(tài)變量異常

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

3.1.2.2 硬件問題

1、硬件失效

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

2、通信異常

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

3.2 程序崩潰

3.2.1 停止運行

3.2.1.1 軟件問題

1、HardFault

以下情況會造成HardFault：

• 在外設時鐘門未使能的情況下操作該外設的寄存器；

• 跳轉(zhuǎn)函數(shù)地址越界，通常發(fā)生在函數(shù)指針被篡改，排查方法同數(shù)值異常；

• 解引用指針時出現(xiàn)對齊問題：

以小端序為例，如果我們聲明了一個強制對齊的結(jié)構(gòu)體如下：

地址

0x00000000

0x00000001

0x00000002

0x00000003

變量名	Val0	Val1_low	Val1_high	Val2
值	0x12	0x56	0x34	0x78

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

2、中斷服務函數(shù)中未清除中斷標志

中斷服務函數(shù)退出前不正確清除中斷標志，當程序執(zhí)行從中斷服務函數(shù)內(nèi)退出后又會立刻進入中斷服務函數(shù)，表現(xiàn)出程序的“假死”現(xiàn)象。

3、NMI中斷

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

3.2.1.2 硬件問題

1、晶振未起振

2、供電電壓不足

3、復位引腳拉低

3.2 .2 復位

3.2.2.1 軟件問題

1、看門狗復位

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

3.2.2.2 硬件問題

1、供電電壓不穩(wěn)

2、電源帶載能力不足

四、回歸測試

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

五、經(jīng)驗總結(jié)

總結(jié)本次問題產(chǎn)生的原因及解決問題的方法，思考類似問題今后如何防范，對相同平臺產(chǎn)品是否值得借鑒，做到舉一反三，從失敗中吸取經(jīng)驗。

來源地址：

https://www.cnblogs.com/jozochen/p/8541714.html

聲明：本文素材來源網(wǎng)絡，版權(quán)歸原作者所有。如涉及作品版權(quán)問題，請與我聯(lián)系刪除

低代碼平臺都是誰在使用？

Windows11 新版記事本開始內(nèi)測

以 Vuex 為引，一窺狀態(tài)管理全貌

我想給元宇宙潑點冷水

VS Code 1.63 版本又帶來哪些新特性？

點擊“閱讀原文”查看更多分享，歡迎點分享、收藏、點贊、在看。