我們做開發的應該都會有深刻的體會，有時候會遇到一些莫名奇妙的BUG不知所措，解決BUG到近乎崩潰，更有甚者有人居然會在夢中解決掉BUG。下面我們看幾個有意思的解決Bug的故事：

知乎網友李幼萌：

08年的時候，我所在的公司除錯三星的一款新的arm9 CPU，型號是S3C2416，是S3C2450的簡配版。開發板剛入手的時候還是熱乎的，因為三星的這個晶片剛剛出來，國內的代理商一共就幾塊開發板。各公司評估開發板都是分時使用的，只能預約幾天。開發板入手的時候，三星那面連BSP都沒有準備好，沒有test code，沒有u-boot，沒有linux-kernel，甚至連Spec都是錯誤百出。還好我公司雖然小，研發能力在本地區還算不差，沒有的東西可以自己移植。  

公司急著要出新品，在沒有完全驗證處理器的情況下，已經layout好了PCB，並且去打樣了（當時競爭確實比較激烈，400M主頻處理器而且這麼低的價格絕對非常有誘惑力，所以公司決定冒這個險了）。在沒黑沒白的工作兩週後，硬體和軟體做的都差不多穩定了。這時候經理說，功能上問題不大了，我們來調一調休眠時的功耗吧（我們的產品一直以待機時極低功耗作為產品的賣點之一）。然而這卻是噩夢的開始……

公司的指標是待機時休眠電流500～800uA（電源電壓4V）之間。以前所有的產品都在這個範圍之內，三星方面的技術支援也明確表示，他們的解決方案達到這個指標。

在我們除錯過程中發現，整個系統休眠時的功耗在1800uA左右，一直降不下來。我們重新核對了所有的IO和外圍電路的所有連線，以及IO口的電平配製，都沒有問題。這時，我們決定測試每一個單元的功耗，用電流表分別串聯進每一個外圍電路，每個單元都很正常，就是系統總體偏大1000uA。

我們連flash和ram的待機電流都測過了，仍然正常。好了，通過排除法已經確定了就是CPU的功耗過大。但是在開發板上除錯休眠的時候，CPU功耗卻是正常的。

我們懷疑是開發板上CPU批號和拿到的CPU樣品的批號之間有區別導致的，因為三星那面也在同步修正CPU的BUG，所以我們“大膽地”把開發板上的CPU用風槍吹下來，換到我們的PCB上，把我們的CPU貼到了開發板上進行交叉驗證。結果是開發板仍然功耗正常，我們自己的板子上功耗偏大，還是大了1000uA。

CPU周邊的核心電路設計出現了問題！這是我們一致的判斷！但是問題出在哪裡，我們反覆核對開發板的原理圖和我們自己板子的原理圖，簡直就是一模一樣！因為整個核心電路這部分就是從開發板上抄過來的，實在沒有什麼可比對的。我們轉而又去懷疑PCB的問題了。 

我是做系統移植和軟體的，純電氣的問題我就無能為力了。閒著沒事，我就反覆檢查我在linux中對系統休眠的IO引腳配置。然後掛著電流表做反覆測試。電流表也對的起我，每次都是那個數。在一次系統待機的時候，我實在忍無可忍，一把抓起了板子。突然之間，電流表的讀數飛快下降，降到了300uA！我鬆開手電流表的讀數就又爬回來了。我把我這個驚奇的發現告訴了同事——一個硬體工程師。同事說可能是哪兒摸短路了，讓我試試還能不能喚醒系統。我給了一個外部中斷，系統神奇的正常喚醒了！

“難道這就是問題？”，我想重現一下。但是再次在待機的時候抓起電路板的時候，讀數並沒有顯著發生變化。“可能是手法不好”，我這麼想著，用手在板子上繼續撫摸著。果然！當我的手指按到PCB中的某一個位置時，電流又降了下來！反覆試了幾次，都是這樣，就是在我手指按壓的這一片，只要是用手指按著，電流就正常！

這回同事開始重視了，開啟PCB圖，拿著電路圖和萬用表，查查我摸的到底是那塊電路。硬體工程師覺得不可思議，因為我摸的部分並沒有連線任何的電路——焊盤是空的。他於是用萬用表的表筆去檢查是不是PCB製版的問題，測一下這些空焊盤到底哪一個有電壓。但是萬用表中沒有讀數，這塊都沒有電。但是當萬用表的表筆落在一處空焊盤的時候，電流表的讀數又降下來了！

這可是重大發現，我們對照了一下電路圖。這處空焊盤是CPU中USB-Host模組的D+訊號。由於我們的產品不需要USB的主機功能，所以這一塊兒沒有做任何處理。多虧了畫原理圖和PCB的同事，多留了一手，把USB Host的引腳都在PCB上做了個引出。誰也沒想到是這個引腳出現了問題，辛虧這個訊號引出來了，要是沒有引出來，一輩子也查不出問題。我們給D+訊號加了一個下拉電阻後，系統的功耗瞬間正常了。

事後分析，三星自己開發板上有USB-Host的功能，所以USB-Host的外圍電路也是完備的，所以功耗不會有問題。但是我們自己的產品上不使用USB-Host功能，沒有相關外圍電路，所以出了問題。這是因為在CPU休眠的時候，D+訊號內部被懸空了！一句話，是三星CPU自己的BUG。我們修改了我們的PCB，增加了一個下拉電阻，同時將問題反饋給了三星。        

 一個月後，當我們的產品量產時，三星也及時的解決了這個問題。那個下拉電阻也不需要再貼上去了。

知乎網友辛曉晨

每次想起這個bug，雖然很多很多年了，我仍然滿臉都是淚水啊！當年做x86 BIOS，客戶是長城電腦。有一回我們的新版本釋出給他們後進行系統重啟測試，就是安裝好作業系統後反覆不停的重啟機器，看看重啟幾百上千次後情況如何。原因是客戶買了電腦每天用，至少得保障人家用個倆三年沒事吧。結果我們的新版本重啟到一百多次的時候掛了，現象就是開機黑屏，沒有任何輸出，就和當年的CIH病毒發作一模一樣，經驗判斷系統壓根還沒有boot OS就跑飛了，我們自己測試也是這樣，而且一旦出現問題就只能重新刷BIOS這個bug非常難調，因為當時我們的版本將近300萬行原始碼，大概2%的彙編與98%的C，幾千個原始檔，光是用來參與build過程的工具就有十幾個。而且這些工具都是自己寫的，構建專案的時候先編譯這些工具，再去用這些工具加編譯器來生成最後的ROM檔案並且更加惱人的是，我們當時沒有source level的debug tool，甚至連彙編級別的單步除錯工具也沒有，壓根沒法對程式碼做step into/over，更沒法加個斷點。。。

當時可以用來除錯BIOS的工具有兩個，一個是Intel自己內部用的ITP，這個是人家公司自己的，一般不給外面人用，當時我們公司與I公司的關係尚處蜜月期，給了我們兩個，但是當時被Chipset team霸佔著做porting用；另一個工具就是American Arium（這家鳥公司不知道現在還活著不），這個東西說白了就是商品化的ITP，因為目標客戶少，所以價格巨貴巨貴！一套系統價格幾萬美金，而且每一代CPU都要換一個插座上的介面卡，這個介面卡又是一萬美金好像，還不太穩定，用著用著就掛了。。。我們公司當時有倆，但是因為沒有買新一代處理器的介面卡，於是只能吃灰了於是我們唯一的除錯手段就是serial debug，就是系統啟動的時候會通過port 80把一些重要資訊打出來，然後我們根據這些資訊判斷執行到哪裡了，系統的情況如何。這類似原始的printf列印。如果要看一個變數的值或者驗證一下我們的判斷，就得重新寫程式碼，在需要的地方加入除錯語句，然後花上半個小時rebuild bios，再重新燒錄，再上電執行看看打出來的到底是啥。如果有疑問，或者發現這裡沒有問題，又或者有了新的思路，重複上述過程。記憶中整整一個禮拜，我們都在不停的看debug info，反覆燒錄bios 哭啊！簡直不是人過的日子！最後發現系統可以成功的跑過PEI，到了DXE階段的某個環節，突然就像心臟驟停一樣，跑飛了！去看疑似跑飛的DXE Driver，是個很普通的平臺硬體初始化程式，沒什麼疑點，壓根沒有頭緒。那段時間，幾乎每時每刻都在想著這個bug，實在是茶飯不思，根本沒心情做任何事！就這樣差不多過了倆禮拜，經過了無數次的重啟與燒錄bios，以及猜測，驗證，被否定，再猜測，再驗證，再否定。。。。。的過程後，我們終於發現了問題的原因：大家可能還記得電腦主機板上有個CMOS，傳統上用來存bios設定，但是現代的系統已經逐漸棄用這個東西。我們現在的bios晶片都是可擦寫的，也就是用程式可程式設計。bios大小是8MB，裡面會規劃好，哪裡是code，哪裡放設定等等，然後程式碼裡有專門寫flash的函式，讓大家可以儲存一些東西，比如你想用硬碟還是光碟機啟動等等。同時系統每次啟動也都會自己寫一點沒什麼鳥用的資訊進來。問題就出在這個寫flash的函式上，我們後來發現，這哥們算錯了儲存區域的地址，導致寫很多次後終於越界，誤寫到了人家程式碼區，把人家好端端的程式碼給寫的亂七八糟，就如同當年CIH破壞系統的方法一模一樣，照這樣哪個機器能點亮才怪呢！又因為每次系統寫的資訊不一樣，比如啟動時間就不太一樣，所以越界需要的次數不是恆定，更加重了我們排錯的難度，淚啊！

知乎網友林鎧鵬

差不多10年前，我們做了一個ARM核的晶片，據說還是國內第一批用ARM7做的，還挺高階，帶有很多安全功能，當然安全就意味著難以除錯，整個系統全部打散，不能分塊。俺負責前端設計，系統，硬體軟體驅動等雜七雜八一堆工作。    然後晶片流出來了，封裝回來，幾天幾夜的除錯，功能都正常了，那個高興呀，第一個晶片就成功，獎金有了！

不過做穩定性測試時候有一個問題一直困擾著，這系統總是莫名其妙的有時候啟動不起來，概率有個百分之幾左右。上電就是不LOAD。而一旦起來之後，就很容易了。

反正功能設計，硬體，驅動都是俺的，那就調唄，軟體，硬體，電路，模擬，研究了好幾天，抓狂，無解。又整個系統不能分塊，我都開始懷疑是不是ARM核的問題。

又做了一個不斷重啟的測試系統，不斷啪啪響上電斷電，針對上電的情況作了統計。得出結論就是，上午不啟動的概率高，下午不啟動的概率低，晚上不啟動的概率高，深夜不啟動的概率低。。。。。和飢餓程度快掛鉤了。。。

那時候那個抓狂啊，懷疑是什麼干擾的，連遮蔽房，隔離電源啥都整出來了。就是沒頭緒，而公司給客戶演示的時間快到了，要是現場掛掉就丟臉了，心裡那個急啊。那段時間，每個深夜，公司裡就是我座位上啪啪啪的聲音------繼電器的啪啪聲。      接下來一個週日測試，公司空調壞了，汗流浹背，脾氣極壞，幾乎就要摔板子了。不過發現這天運氣非常好，成功概率很高。沒頭緒，直接抽上煙，看著板子發呆，不知那根神經搭錯，直接把菸頭對著晶片戳上去！咱第一個親生晶片！！如果不行了就掐死它！！！結果發現怪了，戳了菸頭，啟動嘩嘩的，每次都OK。遂懷疑是尼古丁過敏或者是溫度原因。拿著烙鐵燙著它，每次必成。於是送進高低溫箱，做溫度曲線測試，發現環境溫度40度以上，成功概率極高，剛好碰見今天加班沒空調，平均溫度高，所以表現良好。而啟動起來因為系統一發熱，所以後面啟動就容易了，溫度一涼下來表現慘不忍睹，敢情這晶片是非洲來的。

有了方向就好說，先解決DEMO，給領導好看。遂做了一個電熱絲髮熱電路，貼在晶片上，用單穩開關控制，一上電就加熱，然後不斷自動啪啪啪對晶片重啟，一旦晶片重啟成功了就斷開發熱電路和重啟電路。進入正常執行情況。系統搭起來一測，效果槓槓的！！！基本都能保證幾秒鐘內就能啟動，公司上下一片讚譽。 於是，領導拿著這套帶著電爐絲的系統去做報告，銷售拿著這個電爐絲Demo去給客戶演示，取得極好成功，老闆都在準備後續的銷售計劃了。俺心裡急啊，總不能出貨產品也帶著電爐絲吧。。。

靜下心好好分析，和溫度有關，又是隨機故障，應該很可能是哪個地方懸空，存在不定態的問題，外面的電路是不可能了，前端模擬加入隨機量也不能重現，那很大可能是後端的人搞的鬼，遂拉來後端人員(暫且稱為C公司)，檢查掃描鏈和測試電路，果然發現有一個暫存器沒有初始化復位。於是後面的情況就簡單了，往掃描鏈中灌入一串資料，把未知量洗出來。成功！！！

所以我們第一代的產品，主晶片旁有一個奇怪的晶片。據線人報告，有競爭對手和盜版者都認為這是安全反盜版電路，因為拆掉這一塊，系統工作就時不時的異常，抓不到規律，可能包含短時間正版驗證，長時間正版驗證，隨機正版驗證等高精尖反盜版措施。反正無法破解。。。。俺笑而不語。

至於說為什麼暫存器沒有初始化復位沒檢查出來，我也不知道，這是人家C公司做的後端，他們的軟體自己加進去的電路。而據說這C公司雖然牛，但那時候後端服務還是新的，軟體也是新的，剛進國內，給我們一個特惠價做白老鼠。。。

知乎網友Xiang Liu

之前用xilinx一塊比較高階的開發板驗證一個高速訊號的功能，發現有一路輸出幅度是其他的1/10，感覺很詫異，於是和師弟翻了一天手冊文件，難不成這貨還有配置幅度的功能。最後無解，用萬用表在BGA焊盤和走線上一點一點地量，過了一個小時，發現....

（Bug微距圖）

尼瑪一萬多的板子 表貼SMA接頭漏焊！中間大概有0.5mm的距離，高速訊號空間耦合過去10%。

於是默默用熱風槍吹上，一切正常了。

這個bug的恐怖之處在於，高速訊號可以從斷點發射出去，然後讓人誤以為臥槽這有輸出啊，不會想到根本就是個直流的斷路，直到你用了萬用表。

知乎網友包治百病的板藍根

讀大學的時候，第一次接觸嵌入式程式設計，當時目標是從一個感測器中讀取溫度變化，當溫度達到某個閾值後傳送簡訊到指定機器。由於晶片廠商給的官方編輯器很難用，當時我們是在VC上編寫好，再用官方工具燒錄到晶片裡。

VC裡環境和晶片專用的環境各種不相容的問題前前後後折騰了不少時間，當終於把程式燒錄進去併成功執行後，卻總不能收到簡訊。嵌入式平臺無法做單步除錯這種事情，於是我們只能無奈用最基本的方式排除問題。先是一眾人review程式碼，但顯然並不能檢查出什麼問題，在模擬環境中確實是可以跑通的。接下來軟硬兼施，隔離各個方法，燒錄進去執行並檢視晶片的引腳電壓變化作判斷。大作業經費有限。由於晶片很貴，我們整個專業也沒多少套這個平臺。晶片燒錄次數也是有限制的，我們並不能無限次的燒進去測試。整個過程大家都很小心謹慎，痛苦得想死。但最後都檢查不出個所以然。直到作業結束，我們仍然沒能把發簡訊這步完成。

不過老師檢查過我們程式碼後仍然給出了個很高的分數，算是對我們這波努力的肯定。然後高潮來了，助教，就是老師帶的研究生，清理我們上交的機器，把機器裡的電話卡回收，於是我們知道了一直髮不出去簡訊的原因。欠！費！

來源：ADI 工程師

BUG: 為什麼我的處理器這麼耗電？

這是我遇到過得解決起來比較費勁一個BUG了，寫的略微詳細了一些，希望能夠幫助到大家。

記得有一次，客戶拿著處理器板走進我的辦公室，說它的功耗太大，耗盡了電池電量。由於我們曾驕傲地宣稱該處理器屬於超低功耗器件，因此舉證責任在我們這邊。我準備按照慣例，一個一個地切斷電路板上不同器件的電源，直至找到真正肇事者，這時我想起不久之前的一個類似案例，那個案例的“元凶”是一個獨自掛在供電軌和地之間的LED，沒有限流電阻與之為伍。LED最終失效是因為過流，還是純粹因為它覺得無聊了，我不能完全肯定，不過這是題外話，我們暫且不談。從經驗出發，我做的第一件事是檢查電路板上有無閃閃發光的LED。但遺憾的是，這次沒有類似的、昭示問題的希望曙光。另外，我發現處理器是板上的唯一器件，沒有其他器件可以讓我歸咎責任。客戶接下來丟擲的一條資訊讓我的心情更加低落：通過實驗室測試，他發現功耗和電池壽命處於預期水平，但把系統部署到現場之後，電池電量快速耗盡。此類問題是最難解決的問題，因為這些問題非常難以再現“第一案發現場”。這就給數字世界的問題增加了模擬性的無法預測性和挑戰，而數字世界通常只是可預測的、簡單的1和0的世界。

在最簡單意義上，處理器功耗主要有兩方面：核心和I/O。當涉及到抑制核心功耗時，我會檢查諸如以下的事情：PLL配置/時鐘速度、核心供電軌、核心的運算量。有多種辦法可以使核心功耗降低，例如：降低核心時鐘速度，或執行某些指令迫使核心停止執行或進入睡眠/休眠狀態。如果懷疑I/O吞噬了所有功耗，我會關注I/O電源、I/O開關頻率及其驅動的負載。

我能探究的只有這兩個方面。結果是，問題同核心方面沒有任何關係，因此必然與I/O有關。這時，客戶表示他使用該處理器純粹是為了計算，I/O活動極少。事實上，器件上的大部分可用I/O介面都沒有得到使用。

“等等!有些I/O您沒有使用。您的意思是這些I/O引腳未使用。您是如何連線它們的?”

“理所當然，我沒有把它們連線到任何地方!”

“原來如此!”

這是一個令人狂喜的時刻，我終於找到了問題所在。雖然沒有沿路尖叫，但我著實花了一會工夫才按捺住興奮之情，然後坐下來向他解釋。

典型CMOS數字輸入類似下圖：

圖1.典型CMOS輸入電路(左)和CMOS電平邏輯(右)

當以推薦的高(1)或低(0)電平驅動該輸入時，PMOS和NMOS FET一次導通一個，絕不會同時導通。輸入驅動電壓有一個不確定區，稱為“閾值區域”，其中PMOS和NMOS可能同時部分導通，從而在供電軌和地之間產生一個洩漏路徑。當輸入浮空並遇到雜散噪聲時，可能會發生這種情況。這既解釋了客戶電路板上功耗很高的事實，又解釋了高功耗為什麼是隨機發生的。

圖2.PMOS和NMOS均部分導通，在電源和地之間產生一個洩漏路徑

某些情況下，這可能引起閂鎖之類的狀況，即器件持續汲取過大電流，最終燒燬。可以說，這個問題較容易發現和解決，因為眼前的器件正在冒煙，證據確鑿。我的客戶報告的問題則更難對付，因為當您在實驗室的涼爽環境下進行測試時，它沒什麼問題，但送到現場時，就會引起很大麻煩。

現在我們知道了問題的根源，顯而易見的解決辦法是將所有未使用輸入驅動到有效邏輯電平(高或低)。然而，有一些細微事項需要注意。我們再看幾個CMOS輸入處理不當引起麻煩的情形。我們需要擴大範圍，不僅考慮徹底斷開/浮空的輸入，而且要考慮似乎連線到適當邏輯電平的輸入。

如果只是通過電阻將引腳連線到供電軌或地，應注意所用上拉或下拉電阻的大小。它與引腳的拉/灌電流一起，可能使引腳的實際電壓偏移到非期望電平。換言之，您需要確保上拉或下拉電阻足夠強。

如果選擇以有源方式驅動引腳，務必確保驅動強度對所用的CMOS負載足夠好。若非如此，電路周圍的噪聲可能強到足以超過驅動訊號，迫使引腳進入非預期的狀態。

我們來研究幾種情形：

1.在實驗室正常工作的處理器，在現場可能莫名重啟，因為噪聲耦合到沒有足夠強上拉電阻的RESET(復位)線中。

圖3.噪聲耦合到帶弱上拉電阻的RESET)引腳中，可能引起處理器重啟

2.想象CMOS輸入屬於一個柵極驅動器的情況，該柵極驅動器控制一個高功率MOSFET/IGBT，後者在應當斷開的時候意外導通!簡直糟糕透了。

圖4.噪聲過驅一個弱驅動的CMOS輸入柵極驅動器，引起高壓匯流排短路

另一種相關但不那麼明顯的問題情形是當驅動訊號的上升/下降非常慢時。這種情況下，輸入可能會在中間電平停留一定的時間，進而引起各種問題。

圖5.CMOS輸入的上升/下降很慢，導致過渡期間暫時短路

我們已經在一般意義上討論了CMOS輸入可能發生的一些問題，值得注意的是，就設計而言，有些器件比其他器件更擅長處理這些問題。例如，採用施密特觸發器輸入的器件能夠更好地處理具有高噪聲或慢邊沿的訊號。

我們的一些最新處理器也注意到這種問題，並在設計中採取了特殊預防措施，或釋出了明確的指南，以確保執行順利。例如，ADSP-SC58x/ADSP-2158x資料手冊清楚說明了有些管腳具有內部端接電阻或其他邏輯電路以確保這些管腳不會浮空。

最後，正如大家常說的，正確完成所有收尾工作很重要，尤其是CMOS數字輸入。

好了就分享這麼多，接下來就看大家留言補充了，評論往往更精彩！

文章版權歸原作者所有，轉載僅供學習使用，不用於任何商業用途，如有侵權請留言聯絡刪除，感謝合作。