嵌入式系统交叉调试方法一般分为两种，一种是基于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调试是两套不同的工具，板子上电到连接工具也需要消耗不少时间。