嵌入式系統交叉調試原理和方法

嵌入式系統交叉調試方法通常分爲兩種，一種是基於JTAG的片上調試方法，一種是基於調試代理的遠程調試方法。

JTAG是一種國際標準芯片測試協議，目前大多數CPU體系都支持JTAG。基於JTAG的片上調試方法最突出的表明就是JLink調試器，其定義了一個軟件調試層面的RDI接口標準，而後JLink調試器將調試環境軟件（IAR、KEIL等）發出的RDI接口轉化爲JTAG命令，對芯片進行調試。該方法多適用於嵌入式系統底層驅動調試、裸系統調試和單應用調試。

 基於調試代理的遠程調試方法是在目標機上運行一個調試代理程序，與宿主機的調試器進行通訊交互，一塊兒配合完成調試的任務。該方法主要使用軟件陷入來模擬斷點以接管CPU來完成調試。GDB遠程調試是主要表明，其提供兩種方式。一種是gdbserver，其能在目標機的系統上獨立運行，用於調試有操做系統的應用程序；另外一種是stub，其和嵌入式系統程序一塊兒連接運行，通常用於調試系統程序。Gdbserver比較容易，但須要操做系統支持；stub調試比較難，須要針對具體的芯片體系進行移植。二者的工做原理是類似的。GDB調試基於串口協議或者TCP/IP協議。因爲調試代理、串口驅動或者TCP/IP驅動須要佔用大量的內存空間，所以該方法通常用於內存資源比較豐富的嵌入式系統的調試。

 

嵌入式系統通常分資源寬裕型系統和資源緊缺型系統，前者CPU處理能力強、內存資源豐富（通常在M字節級以上），如能支持Linux內核運行的嵌入式系統，而其通常都是選用基於調試代理的遠程調試方法來進行開發；然後者的CPU處理能力通常、內存資源有限（通常在100K字節如下），多見於單片機控制器類成本敏感的消費類電子系統，系統程序難以和stub程序一塊兒在內存中運行，所以難以選擇基於調試代理的遠程調試方法來進行開發，而是選擇基於JTAG的片上調試方法或者直接串口打印的方式來進行調試。可是，在資源緊缺型嵌入式系統上，針對帶操做系統（如基於UCOS內核、FreeRTOS內核）的應用程序進行調試，基於JTAG的片上調試方法也是難以勝任的。考慮如下類型的嵌入式系統：

帶嵌入式操做系統的電子產品每每都具備多個應用，例如一些帶LCD平的音頻播放器，它除了有音樂應用，也有圖片應用、FM應用、電子書應用等等，同時還能夠充當一個U盤進行文件拷貝。該系統同時可能運行一到兩個應用，例如聽音樂看電子書，而其餘應用則不能同時運行。嵌入式系統學習加意義氣嗚嗚吧久零就易，這些應用程序和操做系統、UI資源文件、配置文件都是存在於外存（如nand flash或者nor flash）的固件區，對使用用戶不可見；而音樂文件、電子書等則是存在於外存的用戶區，對使用用戶可見。從中可當作，各個應用程序是分時複用寶貴的內存資源。因爲成本敏感，內存資源的大小是通過精心設計的。對於單個應用程序，也會將代碼分爲常駐內存類型和可切換類型。例如，對性能影響比較大的解碼部分代碼就須要常駐內存，而選擇文件相關的代碼則能夠在須要時才加載到內存。同時，使用固化一部份內核的代碼，就能作到以100K左右的內存來支撐整個系統的運行。應用程序在非運行狀態時存儲在外存中，在應用運行時纔會被操做系統加載到內存中，同時對可切換類型的代碼進行調度切換。

若是要調試這種帶操做系統類型的應用程序，因爲內存的緣由，依然不能選擇基於調試代理的遠程調試方法，而選擇基於JTAG的片上調試方法會遇到如下問題：

因爲沒有STUB在目標機運行，因此基於JTAG的片上調試方法只能經過JTAG協議接口來對內存進行讀寫。而上述應用程序包括常駐代碼和可切換類型代碼，在未運行時須要存儲到外存中，在須要的時候才能由定製的操做系統加載到內存中。很明顯，JTAG接口沒法將代碼寫到外存中去。所以，須要經過其餘的手段將固件（包括操做系統、全部的應用程序、UI資源文件、配置文件）燒寫到固件區，才能使用基於JTAG的片上調試方法進行調試。即不使用該方法的程序下載功能，而是使用讀內存、設置斷點等功能。

所以，調試這種帶操做系統類型的應用程序通常的流程以下：

1）  調試過程當中遇到問題，中止調試，修改好，編譯連接該應用程序。

2）  打包固件，將操做系統、全部的應用程序、UI資源文件、配置文件等打包成一個固件。

3）  燒寫固件，通常使用USB量產工具，或者直接的外存燒寫工具。

4）  啓動系統，並運行到該程序，進入調試狀態。

這種調試方式最大的問題就是效率很低，由於每次修改程序，都要從新打包整個固件，通常要耗費10分鐘以上，同時，還要從新燒寫整個固件，燒寫前還要先擦除外存，這裏也要耗費很多時間。另外，因爲燒寫固件和JTAG調試是兩套不一樣的工具，板子上電到鏈接工具也須要消耗很多時間。