實時嵌入式系統軟件調試問題分析

　　例如，假設一個設備必須在向其發任何指令前就完成初始化。編譯器可能會移動指令位置，以便改善性能。這可能會造成設備的故障。如果你的設備驅動器調試后的版本是可行的，而采用經過優化的版本時會出現故障，那么你會想查看設備的初始化中是否有被移動的指令。你可能不得不采用恰當的編譯器指南以便指導編譯器不去對每條基本函數執行這樣的優化，而不至于損失性能。

　　有時，將代碼從一個架構移植到另一種架構上，也會帶來某種數據類型上的問題。例如，一種架構內的整數可能是32 bit的，而其它的架構中可能是48 bit或者64 bit的。這可能會導致數據的失效或者被截斷。

　　異常所帶來的問題

　　如果異常是與程序的執行相同步的，則這往往是一種不當的操作的結果，例如零作為除數所造成的異常。某些異常則是架構所特有的。處理異常的最佳方法是采用缺省的異常處理器，并在出現異常時檢查異常出現的環境。異常所處的環境背景是寄存器量值的集合，包括狀態寄存器。大多數架構將擁有一個指令地址寄存器，用來保存造成問題的指令地址。在多數情況下，要知道一個異常是如何發生的并不難，但是，是何種指令路徑可以隔離出這一失效，則是調試時棘手的地方。有些架構支持跟蹤，即讓你可以看到程序順序執行的指令的歷史。這將給出造成異常的指令順序的某些細節信息。內存和寄存器訛誤則是造成異常及程序邏輯錯誤的主要原因。通過細致檢查造成異常的內存指向或者寄存器，將可以縮小問題的范圍。

　　不能執行錯誤檢驗的代碼會造成內存的訛誤

　　由于性能方面的原因，開發商可能會放棄對錯誤的檢查。跳過錯誤檢查將讓內存泄漏等事件無法為人所知，而最終導致內存訛誤。例如，如果malloc()出現故障，而由于返回的值并未得到檢驗，則開發商將開始覆蓋在內存的地址0x0地址所寫入的量值，在很多嵌入式系統中，這則是一個有效的內存區域。一個技巧是，讓某些地址0x0處的內存控制，以便排查出任何一種潛在的訛誤。某些處理器架構就容許應用監測數據總線的活動，從而能抓住相應事件。

　　探尋架構特有的功能:

　　大多數嵌入式處理器都支持某種層次上的調試功能。內置的跟蹤單元就是一種得到硬件支持的跟蹤機制。例如，ADI公司的Blackfin處理器系列就具有硬件跟蹤單元，它可以跟蹤至少16路的時序控制器的訪問。當硬件跟蹤緩沖器充滿后，就會產生跟蹤異常。使用這種跟蹤單元后，人們可以構建出完整的執行路徑。所提供的跟蹤輸出來自于一種可以免費提供的工具(http://www.blackfin.org/) ，它可以構造完整的執行路徑。

　　觀察點：

　　觀察點可以讓你監測特定的內存位置或者內存塊區正在被更改時出現的情況。觀察點可以監測內部的數據總線傳送，如果在觀察點寄存器中，發現任何匹配的對象，則讓處理器暫停。如果一個特定內存位置不斷出現訛誤，則觀察點就非常有用。對內存塊區進行觀察以查看是否有任何正在損毀存儲器數據的惡意代碼。

　　大多數當前的調試環境都容許對內存和寄存器的內容進行修改。有時，修改寄存器的內容，可以讓我們洞察何處出現了故障。例如，通過更改程序計數器，你可以迫使程序在特定函數出現時恢復執行。必須謹慎地對恰當的寄存器設定恰當的量值，具體方式則取決于處理器C函數的運行時間模型。另外一個有用的寄存器是IMASK，如果你正在調試任何一種實時操作系統，則調試(分步深入時)進程中任何時刻都會出現中斷。由于調試后的代碼不一定處于關鍵區，你可能幾乎時時刻刻都要訪問中斷的例程。你可能無法屏蔽中斷，因為它們讓你的系統完成設定，并運行起來。例如，任何系統中的定時器的中斷都可能會被觸發。更好的方法是對IMASK寄存器進行編輯，將所有的中斷都屏蔽掉，直到你調試完代碼為止。

　　結論：

　　總之，由于調試是開發過程的最后步驟，因此它將對產品上市時間造成直接的影響。調試本身也是難以調度的，因為所發現的問題在復雜性和可避免性方面都大相徑庭，上面所討論的是一些在嵌入式系統開發期間常見的問題。這些調試技巧和提示旨在著重強調節省時間，因此在開發復雜的嵌入式系統時，應用現代的開發工具和擁有豐富調試功能的處理器能夠改善投資收益。