隨著實時嵌入式系統的復雜程度不斷提高，低效率的調試方法的成本日益增加。鑒于當前嵌入式應用的復雜性還有繼續上升的趨勢，對這些系統的調試將成為加速產品上市和提供魯棒性最終產品的關鍵因素。隨著應用對多線程和中斷嵌套的使用，開發商的大部分時間目前都花在調試上。應用的實時屬性使得將伴隨同時發生多個事件的故障問題孤立起來變得更為困難。本文將討論常見的調試問題以及預防和檢查這些故障問題的一些方法。
　　從歷史角度上來看，嵌入式應用代碼的調試流程可以分為兩類。第一類調試流程是回答 “我的代碼現在執行到哪里？” 的問題。當開發商依靠打印語句或者LED的閃爍來指示應用程序執行到某個節點的調試方法時，往往就屬于這種情形。如果開發工具支持這種調試方法，可以沿著應用應當程序應當執行的路徑插入斷點。第二類調試流程是幫助回答“我看到的這一數值是從哪里來的？”這一問題。在這種情況下，人們往往依靠寄存器顯示窗口觀察變量信息、處理器內存的內容。人們還可以嘗試單步執行，并且觀察所有這些數據窗口以了解某個寄存器狀態何時出現錯誤，內存位置何時得到錯誤的數據，抑或指針何時出現了誤用。
　　當開發商寫完全部代碼后，如果無需了解網絡基礎設施，也沒有操作系統的任務調度需要考慮，那么就可以利用這些調試方法使一個應用程序運行起來。然而，現在的情況并非如此。嵌入式處理器以超過600 MHz的速度運行，并且擁有可支持Ethernet和USB等協議的嵌入式外設，它們支持功能齊備的操作系統，例如uClinux，而且這些操作系統所調度的各種應用程序是由數千行代碼構成。使用打印語句和利用LED來調試是不現實的，因為現在常常有如此之多的功能在執行是不可能的，或者它們會影響標準I/O口，從而造成處理器性能大幅度下降。
　　也可能發生這樣的情況：處理器的工作速度是如此之快，以至于LED的亮滅速度會快到人眼無法察覺。另外現代的嵌入式系統通常支持斷點的設定，但是伴隨這些處理器所運行的代碼數量，使得這種類型的斷點調試難以駕馭。中斷和多線程系統在代碼的任何一點上設置一個斷點，可能都無法指示系統的正確狀態。由于斷點設置在物理內存的某個地址上，索引不必了解線程的狀態。如果使用寄存器顯示方法，那么局部變量窗口和內存窗口都將有助于隔離出所載入的不恰當的量值，但是，由于這些是靜態化的工具，不能給出有意義的運行中的調試信息，其適用性也常常很有限。
　　實時嵌入式系統軟件最常見的調試問題可以大致劃分為如下幾類：
　　1. 同步問題
　　2. 內存和寄存器訛誤（corruption）
　　3. 與中斷相關的問題
　　4. 硬件配置問題
　　5. 異常情況
　　同步問題
　　在任何系統中，只要有多串序線程或者進程都在運行，而且是異步共享數據，則系統必然存在同步問題。對于共享數據的全部操作必須是原子化的，也就是說，只有在一個線程或者進程完成對數據的操作后，其它的線程才能對數據進行操作。
　　以圖1為例，線程A和線程B對共享變量“counter”進行操作，A讓counter 增加，而B則讓counter減少。下方示出了線程A的counter++和線程B counter—的匯編代碼。假設線程B的優先級要高于線程A，而線程A目前正在運行，則線程B將被阻止。
　　
　　舉例來說，假設初始的計數值是2，而線程A是執行線程。則線程A讀入計數值，并送入一個寄存器，在使其增加一個增量后，再將其寫回計數器變量上。
　　在可搶先的多線程系統中，高優先級的線程的執行可以搶先于低優先級的線程。例如，假定線程A執行Reg1 = Reg1+1指令后，一個事件喚醒線程B。此時，Reg1儲存量值3。現在線程B被喚醒（正如藍線所標示的那樣），并讀入計數器的量值2（它尚未被線程A刷新）并將其量值減小到1。正如棕色的線所顯示的那樣，經過一段時間，線程A恢復運行，將Reg1寫入計數器中，而該計數器的儲存量值為3。 在這個過程中，線程B的減量操作結果被丟棄。計數器存儲的量值變為2，即線程A進行一次增量后，線程B又進行了一次減量操作。被竄改的鏈接表則是另一個例子。如果數據被一個線程和中斷例程共享，則也會出現上面的問題，因為中斷的執行與線程的執行之間是異步關系。