1：嵌入式系統調試
總體上說嵌入式系統，特别是基于SOC設計的ARM，利用自由和開源軟體作為嵌入式開發工具的一個完整部分在過去的幾年内有很大的發展。一項由
linuxdevices.com進行的調查表明43％的調查者使用嵌入式Linux在他們或者他們的公司産品中，另外55％
會在接下來的兩年中使用。設計中使用最多的是ARM處理器結構，在開發中占30％，其次占28％的x86。開源工具被59％的調查者作為第一選擇，82％的調查者認為這些工具對于開發嵌入式Linux是很好的是可以接受的。
自由和開源項目為ARM開發提供了一套高品質的開發工具鍊，然而卻缺乏調試的支援，特别是涉及到系統程式設計的時候。GNU調試器（gdb）提供了完美的調試支援，但是僅僅包含了嵌入式系統調試的某一些部分。底層的任務需要硬體的支援，現有的開源解決方案對此類任務是無能為力的，至少是有些不完善的。
這個畢業設計的目标就是設計和實作一個自由的針對ARM7和ARM9系列的調試解決方案，使得昂貴的商業工具沒有市場。作為工作一部分所寫出來的這個軟體開始隻支援處理器系列中的某幾種，但是通過适當的設計可以使得擴充很容易。目标接口應該基于IEEE标準測試通路端口和邊界掃描結構。支援不同的PC主機和IEEE
1149.1相容目标的接口是一個十分明确的目标。
嵌入式系統的調試和傳統的應用程式調試在許多方面都是不同的。相對于桌面系統，嵌入式系統有更少的資源，比如主存，處理器能力，或者輸入輸出能力。這就使得在一個系統上運作軟體調試程式和被調試的程式就不不友善甚至是不可能的。取決于開發的任務，有可能在目标系統上根本就沒有一點運作的軟體，比如Bootloader的開發。在這種情況下，系統上通常也沒有調試器。在應用程式的開發過程中，我們期望硬體是不出現錯誤的，也就是所有的子系統（CPU
,memory,storage,I/O）是可工作的。在嵌入式系統中，硬體是可能出錯的，比如一個不穩定的記憶體接口或者一個未測試的系統元件。加入記憶體系統失效或者未測試，任何代碼可能出錯，哪怕是一個調試器。
由于這些限制，嵌入式系統經常利用遠端調試器進行調試：調試器運作在一個主機上，然後通過硬體或者一個運作在目标系統上的小軟體控制目标系統。這樣開發者就有可能利用他的工作站提供的所有功能，而目标系統沒有必要運作一個全功能的調試器。
調試的目的是分辨和移除軟體程式中的缺陷。可以通過被動的看代碼，或者是資料流，也可以主動的将目标停在某個重要的點來達到上述目的。被動調試有不被打斷，可以讓程式順序地被檢測的優點。而主動調試可以讓開發者控制程式流，或者改變目标記憶體的内容。
幾年前，嵌入式系統不得不利用其他的程式将程式代碼下載下傳到記憶體晶片中。這個晶片從目标系統中分離出來，程式設計，再放回到目标系統中。現在可以通過在目标系統上運作一個非常簡單的嵌入式開發工具來下載下傳程式代碼到目标系統中。
接下來的幾部分列出了一些通用的嵌入式調試解決方案，也看一下實際中目前可用的ARM7/ARM9的調試解決方案。給出了一個嵌入式系統設計，調試的細節性評價。
1．1 調試解決方案
邏輯分析儀，硬體跟蹤
邏輯分析儀和專門的跟蹤硬體，像 ARM embedded trace
macrocell
(ETM) 允許程式流被動的被觀測。邏輯分析儀觀測目标的資料和位址總線，通常給出執行指令的一個清單，可能有通路資料的注釋。而對于一些老的微控制器，由于每次指令的執行都導緻記憶體系統的通路，所有沒辦法利用現代緩存結構來跟蹤程式的執行。包括進入緩存的指令不會在記憶體接口上表現出來，所有使得完整的跟蹤是不可能的。獨立的跟蹤硬體是和微控制器核心緊密結合的，使每條執行的指令路徑都不依賴于記憶體接口。在高速時鐘下，系統産生的自然資料增長的非常快，這樣就很難從目标系統中得到資訊，也很難找到相應的部分。進階解決方案比如ETM9允許觸發點，比如指令位址在跟蹤硬體開始監視核心的時候就被定義。過濾器進一步限制了從核心傳送到調試主機的資料量。
ICE仿真，ROM仿真
ICE使用一種特殊的調試變量取代目标微控制器，它包含一個硬體調試工具。仿真器連接配接一個運作調試軟體的主機。允許被動和主動調試，給出一個不中斷的程式流的視圖，允許對程式執行，CPU狀态和記憶體内容很好的控制。ROM仿真器利用雙端口随機通路記憶體子產品取代目标系統非易失性記憶體。這樣就能被調試器和目标系統同時通路。在不得不從ROM開始執行代碼的地方，就可以允許調試器利用必要的擷取調試入口的挂鈎來替換指令，比如TRAP或者失軟中斷（SWI）指令。代碼測試改進了，因為記憶體晶片不需要額外的工具來程式設計。ICE可能支援硬體斷點，在該處位址比較器始終監視位址總線，當取得的指令位址符合的時候就強制系統進入調試狀态。這就可以不使用ROM仿真器而在ROM中的代碼上設定斷點。如果ICE更進一步支援覆載記憶體，就可能下載下傳代碼到目标系統中，替換在ROM區域中的指令。ICE觀測可通路記憶體空間，當覆載記憶體發生時就跳轉到RAM.。
調試樁
調試樁，通常被稱為“調試代理”，運作在目标系統中，連接配接到運作調試軟體的主機。他們需要初始化代碼，設定調試時鐘，主記憶體，和通信管道。這就使得調試樁在早期的開發中不适用，初始化的代碼需要被調試。
調試樁利用目标系統的中斷來控制程式的執行，比如使用序列槽中斷向量的時候就會用到RS232通信。當主機調試器發送資料到調試樁時，中斷就發生，讓樁控制整個目标系統。樁就使用同種類的TRAP
或者 BREAKPOINT
指令，或者SWI指令來替換斷點指令。一旦目标系統觸發了一個斷點指令，控制權就交給了調試樁，它能将斷點資訊傳回給調試主機。
調試樁的主要缺點是要初始化和時候目标系統的資源，但是它們隻需要一點額外的硬體，使得對開發工具成本要求很嚴格的就很有吸引力。
內建調試電路，片上調試
內建調試電路使得ICE仿真器在高适應性上有很強的能力。相對于使用特殊的調試版本替換目标微控制器，每個出售的晶片上都有調試功能。使用少量的連接配接針腳，序列槽通信通道使用連接配接到調試主機的調試電路就能達到高速的操作。
ARM調試方案
因為基于ARM7和ARM9系列的片上系統設計的流行，好些供應商提供所有的ARM7
和ARM9
微控制器的內建調試電路。相對于商業工具，也有自由和開源的實作，提供很大範圍的支援功能。有些作為混合方案提供，主機PC和調試目标之間的接口硬體通過調試軟體實作連接配接，有些是純硬體的解決方案，能夠和各種軟體産品配合使用。這裡，測試軟體沒有必要是一個全功能調試器，而是一個和硬體通信，為調試前端提供一組調試功能的軟體。下面不是一個很容易了解的清單，而是展示一下典型的設計。
硬體和軟體混合解決方案
ARM Multi-ICE
http://www.arm.com/products/DevTools/MultiICE.html
ARM Multi-ICE 支援各種不同的ARM
核心，提供盡可能的功能，包括通路特殊系統控制寄存器，FLASH
燒寫。通過PC并口連接配接主機，通過達到10ＭHZ的JTAG時鐘通路目标系統。配套使用的軟體叫Multi-ICE
sever，它包含目标特殊調試功能，為調試前端提供遠端調試接口。Multi-ICE
sever 需要PC 機運作Microsoft windows 。不支援Linux
和其他的自由作業系統。
ARM RealView RVI
http://www.arm.com/products/DevTools/RVI.html
ARM RealView ICE
取代Multi-ICE，提供高達50MHZ的JTAG時鐘，更長的電纜，使用USB連接配接主機，這樣就提供了極大的靈活性。RVI包含一個處理所有目标系統特殊調試功能的ARM9處理器。需要RealView
Debugger 作為前端，可以在Microsoft Windows, Linux
和 Solaris 上使用。
Abatron BDI2000
http://www.abatron.ch/
BDI2000
通過RS232或者是10BASE-T以太網連接配接主機，支援16MHZ的JTAG時鐘。硬體能針對各種目标系統進行配置，包括針對ARM7
和ARM9
目标配置。目标特殊調試功能包含在BDI2000中。被各種調試前端支援，比如ARM
RealView Tools ,Metroverks CodeWarrior
或者是GDB。一個附加的遠端接口提供對特殊硬體調試功能的直接通路。BDI2000提供幾乎所有的調試功能，包括系統控制寄存器。
硬體解決方案
Macraigor Wiggler, Parallel Port Wigglers
http://www.macraigor.com/wiggler.htm
Macraigor Wiggler
是一個簡易裝置用來連接配接PC并口到目标的JTAG接口。主機PC
仿真目标接口靠切換信号開和關，是一種通常叫作
“bit-banging”
的技術。它表現像一個信号緩存，提供PC和目标系統間必要級别的轉換。Wiggler相容的克隆版的原理圖在網上是可以自由擷取的，可以修改适合特殊的需要，比如添加和移除JTAG标準中的某些信号。圖1.1是一個完整的wiggler
克隆。Wiggler的速度由PC的并口速度決定，每條指令進或者出大概需要1微秒。一個完整的時鐘周期至少需要2微秒，是以最高速度隻能達到500KHZ。
Macraigor Raven
http://www.macraigor.com/raven.htm
和wiggler類似，Macraigor raven 通過PC
并口連接配接主機，但是它使用的是增強的并口協定和進階别指令。邏輯上
raven
内部将并口資料轉換成高達8MHZ的串行流。Raven的内部設計是專有的，原理圖是不能用的。在Microsoft
Windows和Linux下二進制裝置是可用的。
Amontec Chameleon POD
http://www.amontec.com/chameleon.shtml
Amontec Chameleon POD 基于Xilinx Coolrunner (XPLA3) XCR3128XL-VQ100
Complex
Programmable Logic Device (CPLD)
(http://www.xilinx.com)。它通過PC的并口連接配接主機，支援許多不同的配置，包括
macraigor
wiggler和raven的仿真。配置可以免費下載下傳，在windows下通過适當的軟體燒寫到chameleon中。
USBJTAG-1
這個裝置由Hubert H?gl 設計，通過USB 1.1 全速接口連接配接PC
主機。FTDI晶片通過使用MPSSE，JTAG 時鐘可以達到6MHZ 到
93 HZ.
圖1.2是一個使用DLP-2232M的一個實作。
軟體方案
Macraigor OCD Commander, OCDRemote
http://www.macraigor.com/ocd_cmd.htm,
http://www.macraigor.com/full_gnu.htm
Macraigor 軟體包與Macraigor Wiggler，Raven ，usbDemon 和mpDemon
裝置一起使用，但是也可以使用自由軟體協定與Wiggler和Raven的克隆一起使用。支援的核包括
ARM7 ARM9成員，MIPS, MOTOROLA POWERPC ,INTEL
XSCALE。不能通路特殊寄存器。也每有擴充的cache和 MMU處理的資訊。OCD
Commander 是一個完整的圖形化的調試器，OCDRemote
是一個連接配接Macraigor 硬體和
GDB用戶端的終端程式。兩個都能在Microsoft windows
和Linux下使用。由于這個Linux版的隻是一個連結到指定核心子產品的二進制檔案，是以就沒有可能使用這個自由軟體來燒寫FLASH。但是Macraigor提供了一個叫“Flash
Programmer“的程式來提供ARM7 和ARM9 的Flash燒寫。
開源軟體
有幾個開源的項目支援ARM7
和ARM9的調試，都是GPL版權。比起商業軟體功能有不足，并且除了gdb-jtag-arm似乎都不在開發了。僅支援的JTAG硬體接口是Wiggler和相容的。沒有一個項目支援比如在ARM720t或者是ARM920t中的MMU處理或者caches。
JTAGER by Rongkai Zhan
http://jtager.sourceforge.net/
JTAGER支援ARM7TDMI,ARM720t和ARM920t
目标系統。對于ST39LF/VF160和MBM29LV650晶片支援FLASH
燒寫。對使用者實作了指令行接口，不支援GDB。2004年十月17号的Version0.3.0是穩定版，依舊處于早期開發階段。代碼的bugs和shortfalls可能導緻目标系統的崩潰和記憶體的混亂。
armtool by Erwin Authried
http://home.at/cgi-bin/viewcvs.cgi/midori/sources/armtool/
armtool
僅支援基于ARM7TDMI的系統。可以寫和讀目标系統記憶體，可以将代碼下載下傳到目标系統中運作。它适合于批處理，不允許使用者互動，沒有指令行接口也沒有使用調試前端。不支援FLASH燒寫。
jtag-arm9 by Simon Wood
http://jtag-arm9.sourceforge.net/
jtag-arm9
僅支援基于 ARM9的系統。包含一個指令行供使用者互動。能夠停止和重新開機目标系統，讀取和修改目标寄存器，支援記憶體讀寫操作。不支援FLASH。
gdb-jtag-arm by Tobias Lorenz
http://gdb-jtag-arm.sourceforge.net/
Gdb-jtag-arm
是唯一支援gdb作為調試前端的開源項目。它基于jtag-arm9
，修改了許多，但不是全部，原軟體的bugs。由于這些缺陷可能導緻在向目标系統記憶體寫入的時候引起目标系統的崩潰。
![Windows下配置Apache的SSL服務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)