第9章 嵌入式系統設計與調試

9.1 嵌入式系統設計流程

在我工作的第二年（大約10年前），我第一次私下完全獨立地設計制作了一款模塊冷水機組單片機集中控制系統，由單片控制系統根據環境的實際負荷智能控制多臺冷水機組協調平衡運行。我記得自己是按以下步驟開展工作的：

1）詳細了解控制對象，制定出控制器的模擬輸入/輸出數量以及數字輸入/輸出數量；

2）制定輸入與輸出的控制邏輯關系；

3）參考以前類似產品的設計資料；

4）制定出整體設計方案；

5）廣泛查閱相關芯片的數據手冊以及市場供應情況；

6）完成芯片選型，采購芯片；

7）繪制電路原理圖；

8）照芯片制作封裝圖，繪制PCB圖；

9）找制板廠制作PCB電路板，自己開始寫程序代碼（都是匯編）；

10）自己焊接；

11）使用仿真調試器進行調試；

12）調試完之后對原理圖、PCB圖和源代碼作相應修改；

13）進行第二次制板；

14）再次調試；

15）結束。

經過以上步驟，克服了種種困難，我自己獨立設計制作的第一個產品就這樣誕生了，而且得到了公司的全額資金支持，成為公司自研項目，替換外購產品。這是對我的最好認可，也是對我自信心的最大激勵。我能做到，相信所有有志做點事情的讀者同樣能夠做到。開了個好頭，后面的事就順理成章了，即使碰到再大的困難也都是能夠克服的。

9.2 嵌入式系統硬件原理設計與審核

以下是我根據10多年電路設計與調試經歷總結出的一點經驗和感想，姑且叫它“電路原理圖設計審核規范”吧，只是一家之言，摘錄到這里僅供讀者參考。

1）詳細理解設計需求，從需求中整理出電路功能模塊和性能指標要求。

2）根據功能和性能需求制定總體設計方案，對CPU進行選型，CPU選型有以下幾點要求：

a）性價比高；

b）容易開發：體現在硬件調試工具種類多，參考設計多，軟件資源豐富，成功案例多；

c）可擴展性好。

3）針對已經選定的CPU芯片，選擇一個與我們需求比較接近的成功參考設計，一般CPU生產商或他們的合作方都會對每款CPU芯片做若干款開發板進行驗證，比如AMCC的PPC440EP就有yosemite和bamboo兩款開發版。廠家最后公開給用戶的參考設計圖雖說不是產品級的東西，也應該是經過嚴格驗證的，否則將會影響到他們的芯片推廣應用。縱然參考設計的外圍電路有可推敲的地方，CPU本身的管腳連接使用方法也絕對是值得我們信賴的，當然如果萬一出現多個參考設計某些管腳連接方式不同的情況，我們可以細讀CPU芯片手冊和勘誤表，或者找廠商確認。另外在設計之前，最好能外借或者購買一塊選定的參考板進行軟件驗證，如果軟件驗證沒有問題，那么硬件參考設計也是可以信賴的。但要注意一點，現在很多CPU都有若干種啟動模式，我們要自己選一種最適合的啟動模式，或者做成兼容設計。

4）根據需求對外設功能模塊進行元器件選型，元器件選型應該遵守以下原則：

a）普遍性原則：所選的元器件要是被廣泛使用驗證過的，盡量少使用冷門、偏門芯片，減少開發風險。

b）高性價比原則：在功能、性能、使用率都相近的情況下，盡量選擇價格比較好的元器件，降低成本。

c）采購方便原則：盡量選擇容易買到、供貨周期短的元器件。

d）持續發展原則：盡量選擇在可預見的時間內不會停產的元器件。

e）可替代原則：盡量選擇pin to pin兼容芯片品牌比較多的元器件。

f）向上兼容原則：盡量選擇以前老產品用過的元器件。

g）資源節約原則：盡量用上元器件的全部功能和管腳。

5）對選定的CPU參考設計原理圖外圍電路進行修改。修改時對于每個功能模塊都要找至少3個相同外圍芯片的成功參考設計，如果找到的參考設計連接方法都是完全一樣的，那么基本可以放心參照設計，但即使只有一個參考設計與其他的不一樣，也不能簡單地按少數服從多數的原則，而是要細讀芯片數據手冊，深入理解那些管腳含義，多方討論，聯系芯片廠技術支持，最終確定科學、正確的連接方式，如果仍有疑義，可以做兼容設計。這是整個原理圖設計過程中最關鍵的部分，我們必須做到以下幾點：

a）對于每個功能模塊要盡量找到更多的成功參考設計，越難的應該越多，成功的參考設計是“前人”的經驗和財富，我們理當借鑒吸收，站在“前人”的肩膀上，也就提高了自己的起點。

b）要多向權威請教、學習，但不能迷信權威，因為人人都有認知誤差，很難保證對哪怕是自己最了解的事物總能做出最科學的理解和判斷，開發人員一定要在廣泛調查、學習和討論的基礎上做出最科學正確的決定。

c）如果是參考已有的老產品設計，設計中要留意老產品有哪些遺留問題，這些遺留問題與硬件哪些功能模塊相關，在設計這些相關模塊時要更加注意推敲，不能機械照抄原來設計，比如我們老產品中的IDE經常出問題，經過仔細斟酌，廣泛討論和參考其他成功設計，發現我們的IDE接口有兩個管腳連線方式確實不規范。還有，針對FGPI通道丟失視頻同步信號的問題，可以在硬件設計中引出硬件同步信號管腳，以便進一步驗證，更好發現問題的本質。

6）硬件原理圖設計還應該遵守一些基本原則，這些基本原則要貫徹到整個設計過程，雖然成功的參考設計中也體現了這些原則，但因為是“拼”出來的原理圖，所以我們還要隨時根據這些原則來設計審查原理圖，這些原則包括：

a）數字電源和模擬電源分割。

b）數字地和模擬地分割，單點接地，數字地可以直接接機殼地（大地），機殼必須接地，以保護用護人身安全。

c）保證系統各模塊資源不能沖突，例如：同一I2C總線上的設備地址不能相同等。

d）閱讀系統中所有芯片的手冊（一般是設計參考手冊），看它們未用的輸入管腳是否需要做外部處理，是要上拉、下拉，還是懸空，如果需要上拉或下拉，則一定要做相應處理，否則可能引起芯片內部振蕩，導致芯片不能正常工作。

e）在不增加硬件設計難度的情況下盡量保證軟件開發方便，或者以較小的硬件設計難度來換取更多方便、可靠、高效的軟件設計，這點需要硬件設計人員懂得底層軟件開發調試，要求較高。

f）功耗問題，設計時盡量降低功耗。

g）產品散熱問題，可以在功耗和發熱較大的芯片增加散熱片或風扇，產品機箱也要考慮這個問題，不能把機箱做成保溫盒，電路板對“溫室”是感冒的。還要考慮產品的安放位置，最好是放在空間比較大，空氣流動暢通的位置，有利于熱量散發出去。

7）硬件原理圖設計完成之后，設計人員應該按照以上步驟和要求首先進行自審，自審后要有95%以上的把握和信心，然后再提交給他人審核，其他審核人員同樣按照以上要求對原理圖進行嚴格審查，如發現問題要及時進行討論分析，分析解決過程同樣遵循以上原則和步驟。

8）只要開發和審核人員都能夠嚴格按照以上要求進行電路設計和審查，我們就有理由相信，所有硬件開發人員設計出的電路板第一版成功率都會很高的，所以我提出以下幾點：

a）設計人員自身應該保證原理圖的正確性和可靠性，要做到設計即是審核，嚴格自審，不要把希望寄托在審核人員身上，設計出現的任何問題應由設計人員自己承擔，其他審核人員不負連帶責任。

b）其他審核人員雖然不承擔連帶責任，也應該按照以上要求進行嚴格審查，一旦設計出現問題，同樣反映了審核人員的水平、作風和態度。

c）普通原理圖設計，包括老產品升級修改，原則上要求原理圖一版成功，最多兩版封板，超過兩版將進行績效處罰。

d）對于功能復雜，疑點較多的全新設計，原則上要求原理圖兩版內成功，最多三版封板，超過三版要進行績效處罰。

e）原理圖封板標準為：電路板沒有任何原理性飛線和其他處理點。

9）制定上述規范的目的和出發點是為了培養硬件開發人員嚴謹、務實的工作作風和嚴肅、認真的工作態度，增強他們的責任感和使命感，提高工作效率和開發成功率，保證產品質量。希望年輕的硬件開發人員能在磨煉中迅速成長起來。

對于復雜的PCB板設計，如高頻多層板一般都請專人布線，因為復雜的PCB板涉及電磁兼容和電磁干擾方面的問題，這是一門高深的學問，除了一些基本的注意事項外還有一些特殊的防護措施，比如設計時使用一些專門的電磁兼容芯片等，感興趣的讀者可以看一些電磁理論方面的書籍。

9.3 硬件設計工具軟件

目前設計原理圖一般使用Protel99SE或者OrCAD Capture軟件。而PCB布線一般使用Protel99SE、PADS或者Allgero（Cadence），其中Allgero的綜合功能最強，有非常強的硬件仿真功能，受到越來越多硬件設計工程師的青睞。

Protel99SE的安裝比較簡單，網上有只需雙擊一個安裝圖標就可以一次完成安裝的版本。而Cadence和PADS的安裝有時會碰到一些麻煩，主要是安裝license的問題，我就曾經碰到過，但只要讀者耐心細致一點總是能成功的：只要把有效license.txt文件放到PADS安裝目錄下，然后在安裝license時，把路徑指到該文件就可以了。cadence的license文件則是做好了的license.lic文件，只要把它放到某個目錄下，再設置Windows環境變量LM_LICENSE_FILE指到這個文件就可以了。

9.4 嵌入式系統調試仿真工具

嵌入式硬件系統設計出來后就要進行調試，不管是硬件調試還是軟件調試或者程序固化，都需要用到調試仿真工具。

隨著處理器新品種、新型號的不斷涌現和不斷更新，目前市面上的嵌入式系統調試仿真工具也層出不窮，這些調試仿真工具因其功能、性能、通用性的不同價格也相差非常懸殊，從幾十元的簡易JTAG調試器到幾萬元甚至幾十萬元的高端調試仿真器應有盡有，以前這方面的工具大部分都是進口的，現在國內有些公司也開始開發這方面的工具，而且性價比很好，只是國內做的大部分都是專用的，通用的比較少，因為通用的應用也很少，而且價格昂貴。

下面列舉一些我曾經用過的調試仿真工具：

1）MCS-51單片機調試仿真系統MDS-55-B5，由三環電子生產；

2）調試PPC860、IXP425和PPC440EP用的BDI2000（進口）；

3）調試SB1250（MIPS）和PPC405GP用的Risc Watch Debugger（進口）；

4）調試PPC860用的EST ICE（進口）和BDM Probe（進口）；

5）調試MC68K用的Code Cruiser加串口；

6）調試S3C44B0和S3C4510用的簡易JTAG調試器，用于S3C44B0和S3C4510調試的簡易JTAG調試器有兩種，一種是與SDT2.51軟件配合使用簡易JTAG調試器，另一種是與ADS1.2配合使用簡易JTAG調試器（不過我沒有用成過，因為我下載的ADS1.2不能用），叫做Wiggler線纜，第10章中的簡易JTAG線纜燒寫器就是指Wiggler，這兩種簡易JTAG的Protel99SE版原理圖和PCB圖都可以從本書附帶的光盤中找到。

9.5 嵌入式系統調試診斷方法

嵌入式系統開發過程實際上就是一個調試診斷的過程，而且調試診斷將一直伴隨著一個產品的終身，即使是最成熟的產品也偶爾會出現這樣或那樣的問題，這都需要開發人員去診斷、排查。

嵌入式系統的調試包括硬件調試、軟件調試以及綜合調試。硬件調試一般是指系統剛開發出來時上電前后的檢查，包括：

1）上電前檢查電源和地是否短路，目視檢查是否有虛焊、漏焊；

2）上電后檢查時鐘線上的頻率和波形、幅度是否正常，各電源電壓是否穩定正常，各芯片溫度是否正常，各指示燈是否正常。

軟件調試一般是指保證硬件一切正常的情況下驗證程序執行的時序是否正確，邏輯和結果是否與設計要求相符，能否滿足功能和性能要求等。軟件調試的方法有很多，包括：

1）用指示燈跟蹤調試；

2）用串口打印調試；

3）用簡單的調試器進行匯編代碼級調試；

4）用比較高端的調試器進行源代碼級調試；

5）用仿真器進行硬件仿真。

上述單純的硬件調試或軟件調試都是相對比較簡單的，困難的是綜合調試。下面我先舉一些自己在工作中曾經碰到的疑難問題，然后再從中歸納出一些一般的調試方法和注意事項。

例1：我們自主設計制作的PPC860（Motorola）網絡引擎平臺的調試已接近尾聲，同一批生產的4塊板子都通過了全部軟件測試，于是又去焊了第二批，可是在第二批板子中有1塊板子的FEC不能正常工作，我們幾個軟件和硬件工程師使用了各種手段，重新看了多遍芯片手冊，還是沒找出原因，于是把板子發回工廠重新焊接BGA，可是回來問題還是照樣存在，沒辦法最后打算將這塊板子當做個樣處理，把板子上的芯片都焊下來。按常理來說這種做法很符合邏輯，因為元器件都是一樣的，板子也是一批的，那就可能是這塊板子的某個地方焊接不好，但又不好查，反復重新焊接可能會把主板焊壞。后來有人從PPC860芯片上用放大鏡都要睜大眼睛才能看清的字符上（據說我國第一代國產高端處理器芯片“寒心”就是某“科學家”將“摩托”同一類型芯片上的這些字母磨掉后刻上“寒心一號”搖身一變造出來的！！！）發現這塊板子的CPU版本號是“D4”，而其他板子的CPU版本號是“D3”，可芯片手冊上并沒有這兩個版本之間的比較說明，從網上找到PPC860的勘誤手冊，發現在PPC860TZP50D4版本中，ECNTRL寄存器增加了一個叫FEC_PIN_MUX的位（bit2）來控制FEC各管腳的復用功能，如果要使用FEC就必須將該位設置為1，所以要在FEC的相關程序中加上ECNTRL |= 0x00000004語句行。

例2：當我調試業余自制的MC68VZ328板子時，電路板硬件檢查沒有問題，用Code warrior通過串口往flash中燒制編譯好的uClinux程序也一切正常，但是重新上電，發現串口沒有任何數據，用萬用表檢查（當時自己沒有示波器等“先進設備”）也沒查出結果，然后每天上下班把這塊板子放在包里，沒事就拿出來瞪大眼睛看看，看著也不免窩火，但有一天卻發現一個標著電阻符號的地方卻焊上了電容，回到家把電阻換上去再上電，串口一下就打印出uClinux的啟動信息，呵，那滋味，比喝了蜂蜜都甜，當然當時也是因為沒有太多經驗，如果這問題放現在，估計一天內肯定解決掉。另外在初次調試自制的S3C4510開發板時，就是不能從串口輸出字符，費了半天時間才發現把串口電平轉換芯片max3232cse的第6腳上的旦電容極性焊反了。

例3：在調試SB1250嵌入式服務器主板時，由于使用的是DDR1代內存條，數據線和時鐘線上串并聯的去耦電容電阻相當多，第一批焊回來的板子幾乎沒有一塊能夠順利進入CFE（BIOS）菜單界面的，檢查時鐘波形和電源與借用的DEMO板相比都很好，我把主板上DDR DIM槽周圍的那些去耦電阻電容都全部用烙鐵重新過一遍錫，嘿嘿，還真管用，這種方法屢試不爽，而且在后面調試PCI和HT總線時使用這招也很有用，可能是因為SB1250系統是高頻電路，對焊接要求比較高，稍微有一點漏焊或者虛焊都不行，我是這樣認為的。

例4：在一個使用實時時鐘芯片SD2000的應用系統中，經常會出現讀出的時間被復位到“2000年1月1日”的情況，我用自己編寫的測試程序經過多次測試發現，按照SD2000芯片手冊中的時序進行連續讀寫確實會經常出現復位現象，好像是芯片錯把讀寫時序當成了復位操作時序，而且每次必出，所以我感覺到芯片本身應該有Bug，于是告訴同事可能是芯片本身有問題，讓他跟廠家聯系，但因為這個芯片在老產品中用了比較長的時間，所以同事不太認同我的看法，但還是與SD2000廠家取得了聯系，廠家經過兩天專門強化測試后通知我們“SD2000本身確實有Bug，可能因為干擾導致芯片復位到2000年1月1日”。

例5：在用PNX1700（DSP）處理器設計成的音視頻開發平臺上，常會出現CVBS輸出黑白圖像（應該是彩色）或顏色不正常現象，于是先詳細閱讀CVBS輸出芯片AVS3169的手冊，然后用示波器測量3169芯片的時鐘管腳，在測量的過程中經常會出現顏色恢復正常的現象，再做多次測試發現這種現象是由于將場同步VSYNC信號與相鄰的數據線Data7短路造成的，再測試發現將VSYNC與其他數據線（Data[0:6]）任一根短接一下都可以恢復正常，再用視頻時鐘信號CLK與數據線短接一下有時也能恢復正常，但有時也不能恢復，所以懷疑是視頻場同步信號有問題。順著這根線索查了一下AVS3169的VSYNC信號與PNX1700的連接方式，發現在用CVBS輸出時，PNX1700上與AVS3169的VSYNC信號相連的引腳是輸出QVCP_VSYNC信號，檢查VO輸出模式設置沒有問題，再查QVCP的設置，看哪個寄存器能控制QVCP_SYNC信號，發現在QVCP_CONTROL(0x10e020)寄存器中有對HSYNC和VSYNC的控制，用命令在線修改了直接相關的該寄存器中4個位的值，但沒有任何效果，再在整個PNX1700芯片手冊中查找關鍵字VSYNC，發現在398頁有對QVCP VSYNC設置要求的描述：該寄存器的bit1(Master)要求設成1，即從模式，而我們現在是設成0，即主模式，我把該位改成1后屏幕出現黑屏，沒有任何顯示，再把這位恢復到0，竟然出現了顏色，屢試不爽，仔細研究這個寄存器的bit1和bit0分別是控制屏幕時鐘發生器（STG）工作模式（主/從）和STG的復位，分析覺得在系統上電后對QVCP初始化之前先把QVCP的STG置成從模式并且復位STG，然后再用原有的初始化程序，這樣應該可以解決視頻信號的時鐘和數據不同步問題，所以在主程序中初始化QVCP之前加入MMIO(0x10e020) = 0x20050006行，測試果然不再出現上述問題，問題解決；并順勢延伸一下，以前用SAA7105做CVBS輸出時偶爾也會出現屏幕頂部顯示不正常問題應該與這個問題一樣，所以用上述相同的方法修改程序后對SAA7105 CVBS輸出進行強化測試（每8秒鐘重新啟動一次，強化測試3天），結果沒有再出現顯示不正常現象。

例6：同樣是PNX1700音視頻開發平臺上遇到的問題，VGA輸出時OSD菜單會抖動，最先想到的方法是把OSD的scaler改用QVCP來做而不是MBS來做，這樣在1500上會減輕OSD抖動現象，幾乎不出，但在1700上測試效果還是很不好，抖動仍然很厲害，后來安排同事將1500種DDR時鐘的工作頻率從166MHz提高到200MHz，并告訴他需要改哪個模塊的哪幾個寄存器，這時正好是用VGA做視頻輸出（一般情況是用CVBS做視頻輸出，但因為此時正在跟蹤VGA中OSD抖動問題，所以用了VGA輸出模式）來調DDR工作頻率的，在同事修改DDR寄存器過程中我卻發現OSD怎么不抖了，仔細研究同時修改過的寄存器相關位的定義，發現在DDR模塊中有兩個寄存器與DDR仲裁相關，一個是ARB_HRT_WINDOW（0x65184，DDR仲裁硬件實時窗口），另一個是ARB_CPU_WINDOW（0x65188，DDR仲裁CPU窗口），將這兩個寄存器分別設置成ARB_HRT_WINDOW = 0xffff及ARB_CPU_WINDOW = 0x0就不會出現OSD抖動，因為在這種設置情況下DDR對DMA的占有權高于CPU對DDR的擁有權，DDR可以搶斷CPU，原來的設置使CPU可以搶斷DDR占有DMA。其實在發現問題VGA中的OSD抖動問題之初我也找過與memory相關的寄存器設置，因為根據以前經驗和習慣思維，DDR配置寄存器只是負責DDR部分，而memory與CPU之間關系的寄存器應該在系統寄存器中，所以沒有去查找DDR配置寄存器，可是在這一例子中卻偏偏在DDR配置寄存器中。

從上述幾個例子中我們可以總結歸納以下幾點調試方法和注意事項：

1）加深理解法：加深理解包括加深對硬件和軟件的理解，加深對硬件的理解主要是詳細閱讀相關的芯片數據手冊，而加深對軟件的理解是因為現在開發嵌入式系統并不是所有程序都需要自己編寫，很多都是已經做好的，直接從網上獲取或者采購獲得，但這些軟件不一定是完全針對我們自己的目標板的，所以在使用過程中經常會發現一些問題，特別是底層軟件，而一旦出現問題，開發人員首先必須了解出現問題的代碼。只有建立在對相關硬件和軟件深入理解的基礎上才可能做出更符合實際的判斷，才可能更好地解決問題。

2）比較法：比較的方法有很多，比如將同樣的軟件放在兩個類似但不相同的硬件平臺上運行比較現象；將兩個不同版本的軟件放在同一個硬件平臺上運行比較現象；將相同的軟件放到相同批次但不同的兩個硬件平臺上運行比較現象。對于一些不是很隱蔽的問題通過比較法通常能得到不錯的效果。

3）分解法：當碰到分析起來比較復雜、可能有很多因素的問題時，可以把問題分成解幾個小問題來測試診斷，比如編寫幾個單獨的小測試程序對各種可能因素進行排查測試，根據這些測試結果再進行科學判斷。

4）軟硬件結合法：這種方法是需要一定靈感和悟性的。比如上面的例5，在測試過程中，可以在不破壞硬件的前提下臨時改變一下硬件的狀態（比如該例中將數據線和時鐘線短路），看問題現象會不會有所變化，如果有，那么多做類似試驗找出變化規律和關鍵因素，然后再進行分析解決。在底層軟件開發中，對于時序要求嚴格的硬件模塊的軟件編程要特別注意，一旦程序的時序出了問題，而這部分軟件已經與其他系統軟件融合到一起，那么這種軟件讓別人去檢查是很難查出問題的。

5）診斷、排故要建立在大量實驗的基礎之上，要多動手，不能光知道臆想，不愿實際操作，還美其名曰“善于思考和分析”。嵌入式系統開發是一門實踐性很強的科學，需要在實踐中總結出事物客觀規律，從而更好地認識和利用它們，讓它們更好地按我們的意圖工作。

6）嵌入式系統開發調試要求開發人員有嚴謹細致的工作態度，決不放過調試過程中發現的任何一點蛛絲馬跡，因為它很可能就是打開潘多拉寶盒的鑰匙。

7）要有實事求是的工作作風，要有敢于懷疑一切的精神和勇氣，我們理當尊重權威和前人的科技成果，但當出現矛盾時我們更應該相信實驗結果，這樣科學才會進步。

8）要勇于挑戰自我，拋開習慣性思維和成見，拓寬思路，多角度分析問題。

9）嵌入式系統開發特別是底層軟件和操作系統內核開發因為需要同時跟軟件和硬件打交道，所以是一件比較艱苦的工作，很有挑戰性。即使我們各方面都做得非常好，考慮得非常細致周全，目標系統仍然可能跟我們開一些小小的玩笑，我們經常會碰到一個非常小的問題困擾我們幾天甚至幾周的時間，這期間我們可能茶飯不思、夜不能寐，因此嵌入式系統底層軟件開發人員不但要有平和的心態，且具備一定的耐心和毅力，還要有勇于克服一切困難的勇氣和信心！只要我們做得足夠好，那么可能解決一個具體疑難的過程帶有一定偶然性，但我們終將排除所有阻礙！

所以說，嵌入式系統調試過程就是一個更加深入了解我們的目標系統以及系統中的每個單元模塊特性的過程，就是一個鍛煉我們的邏輯思維和分析推理能力的過程，就是一個開拓思路、向習慣思維和權威挑戰的過程，就是一個培養嚴謹細致的工作態度和實事求是工作作風的過程，就是一個鍛煉我們耐力和毅力的過程，最終是一個學習進步的過程！

嵌入式系統調試診斷能力的提升是一個長期實踐、積累、提高的過程！