一只鱼's profileEE小站PhotosBlogListsMore ![]() | Help |
|
|
EE小站为生计奔波的工程师的梦想后花园
October 10 Mum计划之urjtag、gdbproxy的下载速度优化国庆假期宅在北京,下回放假一定要出去走走。不过也有收获,就是今天这篇文章。
本文的主要内容是如何修改urjtag和gdbproxy的代码,提高Blackfin GDB调试时,代码下载的速度。
本文属于Mum计划,Mum计划的目的是制作一套开源的Blackfin调试和开发解决方案。
Mum计划使用基于FT2232的JTAG电缆——MumJTAG进行Blackfin处理器的GDB调试。
MumJTAG的硬件制作请看这篇文章:http://xianzilu.spaces.live.com/blog/cns!4201FDC93932DDAF!786.entry
MumJTAG使用urjtag和gdbproxy来进行GDB调试:urjtag和gdbproxy的基本编译请看这篇文章:http://xianzilu.spaces.live.com/blog/cns!4201FDC93932DDAF!850.entry
本文隐含性的提到JTAG调试原理知识,如果不明白,请自行查找文章。
本文参考文档有,http://blackfin.uclinux.org上的这两篇:
还有http://www.hjtag.com的Twentyone大侠写的一篇,我给放到EE小站的SkyDrive了:
关于DCC下载,请看http://blackfin.uclinux.org上的这篇:
以及ADI官方的Blackfin手册,我下载下来,放到EE小站的SkyDrive:
下面开始正题,转载请注明来自我是一只鱼的EE小站,邮件cosine@126.com。
虽说之前我成功编译了Blackfin的GDB调试代理,但用起来可不像OpenOCD那么好用,尤其是gdbproxy的代码下载速度仅有4kb/s,一个u-boot就要一分钟才能下载完,简直无法接受。为了让Mum计划的调试方案实用,我付出了很多努力。虽然我没有深究Blackfin JTAG调试原理,但我的代码勉强让gdbproxy的代码下载速度提高到了40~60kb/s,虽然比不上有人专门研究的可以达到120kb/s的ICEBear(http://www.section5.ch/icebear),但是作为开源调试器,60kb/s的下载速度应该可以对付大多数应用了,我就偷点懒,不继续优化,就让ICEBear有点钱赚。
为什么urjtag和gdbproxy那么慢呢?因为FT2232这种器件仅仅是一个信号转换器,所有的JTAG操作都是用程序模拟的。FT2232是USB的,这就带来一个问题,USB数据传输不是实时的,每个设备都占用一定的轮询时间;如果要从JTAG读取某些东西,就必须以轮询周期为单位读取。例如,gdbproxy每向JTAG写4个字节(unsigned long),就要读取JTAG状态,看是不是CPU准备好了。由于USB的轮询周期较长,说实话我也不记得了,也许是125us,也许是1ms,那么这个周期写一下数据,下个周期读一下状态,下载速度就只能是个位数的kb了。
说说我是怎么做到的:
1.将默认JTAG TCK频率提高到6MHz;
2.实现传说中的DCC下载功能;
3.关闭大于4字节批量写操作的Cache清空功能。
第一点没有什么说到的,很好理解。
第二点,什么是DCC下载?DCC这个名字其实借用了ARM公司的说法(Debug Communication Channel),ADI有别的叫法,不管怎么叫,他们描述的事实是一致的——CPU和JTAG扫描链共享某个寄存器。说说DCC下载怎么工作吧,CPU运行一段小程序,不断扫描JTAG共享的寄存器里是不是有新数据,如果有,就保存到内存中;JTAG电缆不断通过JTAG口,向JTAG共享寄存器里写入新数据。由于现代CPU的读取和保存数据速度一般都比JTAG扫描链快很多,所以JTAG电缆就不需要看CPU是不是准备好了,节约了读取CPU状态的时间。这里还牵涉到两个问题:(1)如果不使用DCC下载,是什么样子?(2)为什么节约读取CPU状态的时间就能提高速度?问题(1),不使用DCC下载,CPU的JTAG调试逻辑里一般都有一个仿真指令寄存器(Emulation Instruction Register),用JTAG可以向这个寄存器里写入单条处理器指令,例如对于ARM,可以是MOV R0, 0x00之类的,并执行,这样,R0的数值就变成0了,再写入STR R1, R0之类的指令,就把数据存到内存去了,但对于Blackfin,这样需要查询CPU是不是完成了仿真指令。问题(2),刚才提到了,USB的轮询周期时间太长,FT2232内部有FIFO,可以储存4k个的JTAG信号电平变换的时序数据,也就是说,如果不接收,只发送,那么每当JTAG电平数据达到4k个的时候才需要发送一次,这样一次发送就大约可以发送几十个字节,而不是原先的4个字节;再说接收造成的影响,由于每个USB的轮询周期,数据既有读,又有写,如果某个周期必须读一次数据,而写数据没有那么多,就造成了FT2232内部FIFO不能被填满,浪费了时间。呵呵,很复杂。
DCC下载的使用是有代价的——需要一个很小的内存空间来跑CPU DCC扫描程序。也就是说,先通过JTAG下载一段小程序到CPU的SRAM,然后运行这段小程序来下载代码。在我这个优化里,我使用了0xffa08000~0xffa08020这段32字节的空间,这段空间BF531~533都有。我写的CPU DCC扫描程序很简单:
需要做的就是启动DCC之前,保护R0、R1、P0、P1和PC,并把R0设成要下载数据的首地址;在执行程序之后,还原被保护的寄存器。
第三点,我是自作主张的,因为我觉得一般执行load命令的时候才会有大量的数据写入,而load命令执行之后,本身程序就要重启,跟cache没有什么关系,所以无所谓。
原理说明白了,下面贴上程序:
还有一个值得说的是,http://blackfin.uclinux.org上最新的urjtag源码中使用了strcasestr函数,这个函数在cygwin的gcc的glibc里面没有,编译无法通过。不过没有关系,可以自己写一个。
今天就写到这里。过一段时间我会放出整理测试后的源代码以及可执行文件,如果你觉得修改过程太过复杂,可以直接使用我写的代码。 September 22 关于J-Link GDBServer的BUG发现J-Link GDBServer有个BUG,它不能获取CPSR的值,导致GDB条件执行语句的时候会把断点放在错误的位置,表现为条件执行语句有的时候不能单步——一单步就运行起来了。虽然我买的是盗版的J-Link,但我还是厚着脸皮到Segger的官网发帖子问了,嘿嘿。Segger反应用了17天的时间,我觉得还算及时,看这个地址:http://www.segger2.com/index.php?page=Thread&threadID=363
从J-Link 4.09b开始这个问题就解决了,我也试过了,如果大家遇到这个问题可以尝试更新下J-Link软件。 小述电磁兼容我必须写点什么证明这个Blog还在我的维护之下,呵呵。
先赞一下我公司的领导,终于请专业咨询公司为我们进行了为期两天的电磁兼容知识的培训;收获还真的不小,困扰我很久的一些问题有了明确的理论答案,下面就要针对我的实际工作应用这些理论了,呵呵。
为了防止我自己忘记,同时也给需要的同学们提供个参考,我决定把这两天培训的要点和我工作以来的体会写下来。转载请注明来自我是一只鱼的EE小站,邮件cosine@126.com,欢迎有问题在此留言或来信交流。
April 15 Mum计划之MumJTAG GDB代理程序编译——OpenOCD、urjtag和gdbproxy的编译
MumJTAG是我设计的一个JTAG调试电缆,它的制作请看这篇文章:http://xianzilu.spaces.live.com/blog/cns!4201FDC93932DDAF!786.entry。 本文在Windows下用Cygwin环境,配合FT2232的D2XX驱动,成功编译了OpenOCD、urjtag和gdbproxy;换句话说,采用本文介绍的方法,可以在Windows下使用FTDI提供的驱动,使用FT2232电缆。OpenOCD在Cygwin下的编译没有什么难度,urjtag和gdbproxy的编译,因为没有找到类似的文章,我花了2天的时间……希望我的记录能给大家提供些方便,不要走我的弯路。转载请注明来自我是一只鱼同学的EE小站,邮件cosine@126.com。 另外说一下,其实ADI提供了Windows环境下的gdbproxy,但是我试了下,不好使,也许是因为它用的是libftdi驱动的原因,我没有调查在Windows环境下怎么装libftdi驱动,因为我想绝大多数人会使用D2XX驱动吧。给出ADI工具链的地址:http://blackfin.uclinux.org/gf/download/frsrelease/392/5211/blackfin-toolchain-win32-2008R1.5.exe。
如果你觉得以上这一切都很麻烦,那么,你可以从EE小站的SkyDrive下载已经编译好的OpenOCD、urjtag和gdbproxy。注意,这些程序必须使用FTDI官方的FTD2XX驱动;这些程序只能在Windows下运行。我测了下,应该不需要Cygwin的Dll;如果不是这样,请留言,我会把Dll加上。地址如下: March 16 Mum计划之陈年往事嘿嘿,先做个铺垫,我的Mum计划基于我的毕业设计中嵌入式视觉这一块。毕业已经有段时间了,我觉得可以贴出来了。视频里的履带机器人识别的目标是我手里拿着的一个红色发光二极管,摄像头安装在机器人中间的那个小突起里面。
解释下那个履带机器人为什么“抽”着动:
设计机构的时候,电机功率选小了,如果不增加电机电压,机器人动不起来;但是增加了电压,机器人运动速度太快,转向无法控制。所以只好让机器人动一下,歇一下,看上去比较别扭
今后的目标,就是把这个东东发扬光大。
|
|||||
|
|