在嵌入式軟件中發(fā)現(xiàn)并消除潛在的bug是一件困難的事情。要從觀察到的崩潰、掛起或其他計劃外運(yùn)行時行為追溯到根本原因，通常需要付出巨大的努力和昂貴的工具。嵌入式開發(fā)工程師們常常放棄尋找罕見異常的原因——因為這些異常無法在實(shí)驗室中輕易重現(xiàn)——而將其視為“用戶錯誤”或“小故障”，然而，機(jī)器中的這些潛在危機(jī)仍然一直存在。
因此，這里有一個關(guān)于難以重現(xiàn)的固件錯誤最常見的根本原因的指南。
1. 堆碎片
嵌入式軟件開發(fā)人員并未廣泛使用動態(tài)內(nèi)存分配——這是有充分理由的，其中之一是堆碎片的問題。
通過 C 的 malloc() 標(biāo)準(zhǔn)庫例程或 C++ 的 new 關(guān)鍵字創(chuàng)建的所有數(shù)據(jù)結(jié)構(gòu)都存在于堆中。堆是 RAM 中預(yù)先確定的最大大小的特定區(qū)域。最初，堆中的每個分配都會將剩余的“可用”空間減少相同的字節(jié)數(shù)。
不再需要的數(shù)據(jù)結(jié)構(gòu)的存儲可以通過調(diào)用 free() 或使用 delete 關(guān)鍵字返回到堆中。從理論上講，這使得該存儲空間可在后續(xù)分配期間重復(fù)使用。但是分配和刪除的順序通常至少是偽隨機(jī)的——導(dǎo)致堆變成一堆更小的碎片。
2. 堆棧溢出
每個程序員都知道堆棧溢出是一件非常糟糕的事情?。 但是，每個堆棧溢出的影響各不相同。 損害的性質(zhì)和不當(dāng)行為的時間完全取決于破壞了哪些數(shù)據(jù)或指令以及如何使用它們。重要的是，堆棧溢出與其對系統(tǒng)的負(fù)面影響之間的時間長度取決于使用破壞位之前的時間長度。
不幸的是，在嵌入式開發(fā)中，堆棧溢出對嵌入式系統(tǒng)的影響遠(yuǎn)遠(yuǎn)超過對臺式計算機(jī)的影響。這有幾個原因，包括：
嵌入式系統(tǒng)通常只能依靠少量的 RAM；
通常沒有可依賴的虛擬內(nèi)存（因為沒有磁盤）；
基于 RTOS 任務(wù)的固件設(shè)計利用多個堆棧（每個任務(wù)一個），每個堆棧的大小都必須足夠大，以確保不會出現(xiàn)唯一的最壞情況堆棧深度；
中斷處理程序可能會嘗試使用這些相同的堆棧。
3. 缺少“volatile”關(guān)鍵字
未能使用 C 的“volatile”關(guān)鍵字標(biāo)記某些類型的變量，可能會導(dǎo)致系統(tǒng)出現(xiàn)許多癥狀，這些癥狀只有在編譯器的優(yōu)化器設(shè)置為低級別或禁用時才能正常工作。 volatile 限定符在變量聲明期間使用，其目的是防止優(yōu)化該變量的讀取和寫入。
請注意，除了確保對給定變量進(jìn)行所有讀取和寫入之外，使用 volatile 還會通過添加額外的“序列點(diǎn)”來限制編譯器。對多個 volatile 的訪問必須按照它們在代碼中的寫入順序執(zhí)行。
4. 比賽條件
競爭條件是指兩個或多個執(zhí)行線程（可以是 RTOS 任務(wù)或 main() 加 ISR）的組合結(jié)果根據(jù)每個指令交錯的精確順序而變化的任何情況。
例如，假設(shè)嵌入式開發(fā)人員有兩個執(zhí)行線程，其中一個定期遞增全局變量 (g_counter += 1;)，另一個偶爾重置它 (g_counter = 0;)。如果增量不能始終以原子方式執(zhí)行(即，在單個指令周期中)，則此處存在競爭條件。計數(shù)器變量的兩次更新之間的沖突可能永遠(yuǎn)不會或很少發(fā)生。但是當(dāng)它這樣做時，計數(shù)器實(shí)際上不會在內(nèi)存中重置。這種影響可能會對系統(tǒng)產(chǎn)生嚴(yán)重后果，盡管可能要等到實(shí)際碰撞后很長時間才會發(fā)生。
最佳實(shí)踐：可以通過圍繞必須以適當(dāng)?shù)膿屨枷拗菩袨閷υ訄?zhí)行的代碼的“關(guān)鍵部分”來防止競爭條件。為了防止涉及 ISR 的競爭條件，必須在其他代碼的關(guān)鍵部分期間至少禁用一個中斷信號。在 RTOS 任務(wù)之間競爭的情況下，最佳實(shí)踐是創(chuàng)建特定于該共享對象的互斥鎖，每個任務(wù)必須在進(jìn)入臨界區(qū)之前獲取該互斥鎖。請注意，依靠特定 CPU 的功能來確保原子性并不是一個好主意，因為這只會防止競爭條件，直到更改編譯器或 CPU。
5. 不可重入函數(shù)
從技術(shù)上講，不可重入函數(shù)的問題是競爭條件問題的一個特例。 出于這個原因，由不可重入函數(shù)引起的運(yùn)行時錯誤是相似的，也不會以可重現(xiàn)的方式發(fā)生——這使得它們同樣難以調(diào)試。 不幸的是，與其他類型的競爭條件相比，不可重入函數(shù)在代碼審查中也更難發(fā)現(xiàn)。
使函數(shù)可重入的關(guān)鍵是暫停對外圍寄存器、全局變量（包括靜態(tài)局部變量）、持久堆對象和共享內(nèi)存區(qū)域的所有訪問的搶占。嵌入式開發(fā)人員可以通過禁用一個或多個中斷或通過獲取和釋放互斥鎖來完成，共享數(shù)據(jù)類型的細(xì)節(jié)通常決定了最佳解決方案。