从一个软件人员的角度看jtag调试
扫描二维码
随时随地手机看文章
wiggler是完成一个从并口到jtag header串行信号的转换功能,仅仅是一个电路,wiggler上面没有固件。调试软件向并口写入调试命令,通过wiggler即可转换成相应的jtag信号。开发机上的调试软件客户端(sdt中的axd,ads中的adw,gdb client)不需要作改动,但是需要调试服务器,比如cfly网站上的jtag.exe,以及redhat网站上提到的gdb-server for multiiice。调试服务器要做的是把来自调试器的命令转换成合适的对并口的访问,并口得到的信号通过wiggler直接转换成jtag信号。比如,jtag.exe我猜想它是一个在某个已知端口等待的服务器程序(用dumpbin可以看到它引入了socket dll ws2_32.dll),sdt axd调试器本身支持远程调试,所以可以在开发环境中把远程IP设置成本机ip地址和jtag.exe所等待的端口号。这样,axd的调试命令就会由jtag.exe得到,他根据这些命令(具体的协议为arm的rdi/adp?)向并口写入合适的值。
再举一个例子,redhat网站上提到的gdb-server-multiice(cygwin)。本来sdt支持通过multiice的调试(multiice的实现原理应该比较向下面的bdigdb),sdt通过集成一个multice.dll插件(相当于上面提到的jtag.exe的脚色,只不过它因为是arm 公司的产品,他们清楚sdt的插件机制,所以该dll可以集成到sdt中去)访问multiice,multiice负责根据收到的命令转换成对板子jtag口的访问。但gdb不支持通过multiice调试,为了在cygwin中通过multiice用gdb调试目标机,可以在开发机上跑一个gdbserver。该gdbserver做的和gdb交互(根据gdb远程调试协议),然后将得到的调试命令转换成multiice.dll的相关调用,就是说它通过multiice.dll将命令发出去,而不是像jtag.exe那样直接发给并口,也就是说这里其实又多了一层间接。
仔细想一下,其实连接jtag仿真器的pc,与运行调试器客户端的pc其实应该可以不是同一个机器的。这是因为axd和gdb都支持远程调试,即使在一台机器上也是通过远程网络连接的方式访问jtag.exe/gdb-server-multiice。有条件的不妨试一试验证一下,反正我没这个条件,我连一台arm目标板都没有 :
bdigdb是一个比较高级的ocd 仿真器,它可以调试Linux内核。他本身就是一个带有mcu(好像是68000)、flash、ram的典型的嵌入式系统。他还有cpld,针对不同的目标处理器,它只需要更新cpld和固件即可实现对另一种目标的支持。哪位解释一下这里cpld的道理?我是真的搞不懂硬件的东东阿。
其固件应该是实现了一个gdbserver,所以开发机上的调试器客户端(gdb client)就不需要做任何修改。gdb客户端使用gdb的调试协议通过ethernet接口与bidgdb上的gdbserver交互(比如,target remote ip_of_bdigdb port_of_gdbserver_on_bdigdb),bdigdb上的gdbserver根据得到的命令决定应该向jtag口写如什么命令。另外,bdigdb得一大特点是支持带mmu的linux内核调试,我猜想他可能是在gdbserver的实现中集成了一个从虚拟地址到物理地址的转换机制,调试时gdbserver将从gdb来得虚拟地址转换成物理地址,再根据该物理地址去访问目标机内存空间。至于转换机制如何得到,与linux在具体体系结构上的实现有关,比如在x86上一般物理地址加上0xc0000000就得到虚拟地址,在其他体系
结构入ppc,xscale上也可能有相应的转换办法,这个有待研究。对了,据说abtron bdi跟montavista linux关系密切,听说montavista特意在arch/xxx/kernel/head-xxx.s中加入了针对bdi调试的的支持代码。如果没有这个支持的话,一般.....也许....好像....就是刚才提到的用把虚拟地址减去0xc0000000来转换了,呵呵,还得研究
www.ocdemon.com 网站上free software栏目下,提供了上面提到的适合于gdb的gdbserver,它叫libremote。libremote可以支持多种目标机。