一只鱼's profileEE小站PhotosBlogListsMore  |  Tools Help |
|
|
EE小站为生计奔波的工程师的梦想后花园
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计划基于我的毕业设计中嵌入式视觉这一块。毕业已经有段时间了，我觉得可以贴出来了。视频里的履带机器人识别的目标是我手里拿着的一个红色发光二极管，摄像头安装在机器人中间的那个小突起里面。
解释下那个履带机器人为什么“抽”着动：
设计机构的时候，电机功率选小了，如果不增加电机电压，机器人动不起来；但是增加了电压，机器人运动速度太快，转向无法控制。所以只好让机器人动一下，歇一下，看上去比较别扭
 。但是视觉识别部分是没有问题的，可以准确地找到我手里的发光二极管。今后的目标，就是把这个东东发扬光大。
 March 13 Mum计划之MumJTAG——ARM和Blackfin JTAG调试电缆（FT2232电缆）硬件制作距离上次更新已经3个多月了
 。这段时间我工作的重点在电磁兼容测试上，这东西估计没有什么人有兴趣吧？其实通过测试很简单，对策也就是那些，就是这事情很烦琐。幸好我们公司有Schaffner的快瞬、浪涌发生器和ESD枪，在我无数次的实验轰炸下，把某个我设计的产品抗扰度，快瞬由不到1000V提高到4800V（我们公司标准比国标高多了
 ），ESD由不到1000V提高到15000V空气和8000V接触；还有另一个产品，把差模浪涌从炸机提高到1500~2000V，可惜还有待提高。累死了，光装卸时拧螺钉就拧了能有一千次，后来不行了，申请了个电动螺丝刀……做完测试，我的收获还是很大的，明白了该如何接地、如何屏蔽、如何进行内外互联；相应的，设计产品的风格也变了一些，终于自我感觉入了设计牛X产品的大门了。下一步还有个可靠性需要摸索，还需努力啊，等加速寿命试验做完了，估计就完成绝世武功目录的学习了，嘿嘿。感觉这段时间的收获就是在小公司的好处，可以接触到产品设计的每一个细节。在业余时间，我启动了一个计划——Mum，这是一个用BF系列DSP进行视觉东东开发的计划，分为Mum、MumBurst和MumSW（SW for Silkworm）三个阶段
，哈哈，上MOP的同学们可以很快看出来含义。MumJTAG是整个计划的第一步，这是个FT2232电缆，可以通过OpenOCD调试ARM，通过urjtag和gdbproxy调试Blackfin。MumJTAG和Hubert Hoegl的USB to JTAG Interface电缆（http://www.hs-augsburg.de/~hhoegl/proj/usbjtag/usbjtag.html）是兼容的，但是速度比它快，可以到6MHz，不用它的VID和PID，所以配置文件还需要修改。至于Blackfin调试，我参考了gnICE（http://blackfin.uclinux.org/gf/project/stamp/frs/?action=FrsReleaseBrowse&frs_package_id=146），但为了和ARM调试兼容，也要修改配置。不过这对开源项目来讲，不算什么难事。转载本文，请注明来自我是一只鱼的EE小站，邮件cosine@126.com。
先介绍下FT2232电缆。也许有的人不知道这个电缆，但没有搞嵌入式的人不知道Wiggler的各种Clone；FT2232电缆就可以看作Wiggler的升级版本。它的特点是，便宜（批量成本大约50~60RMB），速度快（下载速度可以达到60~70KB/s），可以配置成JTAG和串口并存的模式（非常适合笔记本电脑），开源。嘿嘿，惭愧，在我写“最低成本的ARM调试解决方案”（http://xianzilu.spaces.live.com/blog/cns!4201FDC93932DDAF!485.entry）的时候，我还不看好FT2232电缆，直到我发现它可以调试Blackfin以后，兴趣才来了。
MumJTAG的简要信息：
国内其实已经有人用FT2232做出电缆来了，比如Simon的Versaloon（http://group.ednchina.com/1065/）和淘宝有售的OpenJTAG。Versaloon看起来卖得不好，我觉得主要的问题是Simon想用擅长于GDB调试的东西去占领已经被各种成熟仿真器占领的，并不需要GDB调试的单片机开发市场，而且宣传的力度又不够。至于OpenJTAG，我觉得设计者把FT2232电缆+OpenOCD拿来赚钱这一点非常失败，首先FT2232电缆完全开源的；再者170这个价格和我刚才提供的实际成本有很大差距；另外，OpenJTAG怎么面对现在只有100块钱的盗版J-Link？当然，也许OpenJTAG设计出来的时候，盗版J-Link还没有这么便宜；但现在情况已经是这样了，OpenJTAG还卖得动么？
因此，MumJTAG从诞生起就完完全全开源，原理图、Gerber、BOM、调试代理程序映像都公开，想自己做的就自己做；我可能会开淘宝店卖空板，还没有想好。目前，在AT91RM9200和AT91SAM9263上试了下，可以用；在BF531的板子上试了下，可以用Insight修改内存数值，我对Blackfin的开发还不熟悉，目前没有跑程序，所以Blackfin GDB调试的结果未知。另外说一下，Blackfin的调试工具urjtag和gdbproxy编译起来太复杂了，具体过程看我后面的文章。
经过我的努力，已经解决了MumJTAG目标板上电时OpenOCD说找不到FT2232的BUG。毕竟我是做工控设备的
 ，MumJTAG设计时考虑了脉冲群、静电对策，并对目标板交流电源冲击采取了抗扰措施；我做了几百次电源冲击测试，还用我这个天天和铁桌腿、水龙头放静电的肉身做了几十次放电测试（对比真正的ESD枪的击穿距离，我觉得放电大概有3000~4000V，好疼啊）；目前来看，MumJTAG V1.1版还比较稳定，单纯从电路上看，相信MumJTAG比现有所有FT2232电缆都稳定。当然，家里的测试条件有限，不能模拟所有的情况；如果你使用MumJTAG V1.1 Gerber做的板子出现问题，欢迎与我联系：cosine@126.com。MumJTAG将不断更新，请关注EE小站。（更新日期2009年3月28日，如果你看到的是转载的文章，请从这里查看最新信息http://xianzilu.spaces.live.com/blog/cns!4201FDC93932DDAF!786.entry）。请注意我在BOM中选取的元件具体型号，钽电容的耐压、ESR，磁珠绝对不能用电感或零欧姆电阻代替，否则稳定性会下降很多。串口插座我用了带共模滤波器的器件，当然也可以用不带滤波器的，但是这样会稍微降低稳定性。
MumJTAG原理图：http://cid-4201fdc93932ddaf.skydrive.live.com/self.aspx/Mum%e8%ae%a1%e5%88%92/MumJTAG/MumJTAG%201.1.pdf。
MumJTAG Gerber：http://cid-4201fdc93932ddaf.skydrive.live.com/self.aspx/Mum%e8%ae%a1%e5%88%92/MumJTAG/MumJTAG%201.1%20Gerber.rar
Blackfin转接板原理图：http://cid-4201fdc93932ddaf.skydrive.live.com/self.aspx/Mum%e8%ae%a1%e5%88%92/MumJTAG/ARM2Blackfin%201.0.pdf
Blackfin转接板Gerber：http://cid-4201fdc93932ddaf.skydrive.live.com/self.aspx/Mum%e8%ae%a1%e5%88%92/MumJTAG/ARM2Blackfin%201.0%20Gerber.rar
Blackfin转接板BOM：http://cid-4201fdc93932ddaf.skydrive.live.com/self.aspx/Mum%e8%ae%a1%e5%88%92/MumJTAG/ARM2Blackfin%201.0%20BOM.xls
先上一张做好的MumJTAG图片：
 梳理下制作MumJTAG需要做的事情：
我的习惯是在Windows下用虚拟机进行Linux开发，所以，我的文章不涉及Linux下驱动，请原谅。设计焊接PCB就不说了，从修改EEPROM开始。
与FT2232配套的，有一片串行EEPROM，其作用是记录用户自定义的设备名称，USB的VID和PID。在EEPROM没有编程的时候，FT2232使用厂家默认的VID 0x0403和PID 0x6010。这个http://www.ftdichip.com/Resources/Utilities/MProg.pdf是官方的EEPROM编程工具MProg的使用说明，我下面提供的过程是这份说明的简化版。
在开始之前，请准备这几样东西：
FTDI的链接总有一天会失效，如果这样，请访问http://www.ftdichip.com查找。
先解压缩驱动程序，假设解压到E:\FT2232，然后连接MumJTAG到USB，提示安驱动的时候选择E:\FT2232，这部分不详细写了，相信大家都会。
驱动安好后，打开MProg，出现如下界面：
然后选择菜单Device>Scan，如果硬件正常，窗口下方应该出现：
 然后选择菜单File>Open，打开下载的MumJTAG EEPROM信息文件"MumJTAG USB 配置文件.ept"，窗口变为：
 上图这些，就是需要烧写的配置。可以不用EE小站提供的这个EEPROM信息，但请注意右边的FT2232C/D Options中的设置，将FT2232设置为Side A为JTAG，Side B为串口；你也可以更改Vendor ID、Product ID、Manufacturer、Product Description为你想要的东西。然后点选菜单Device>Program，将信息下载到EEPROM中，拔掉USB插头，硬件方面的动作就完成了。
此时，MumJTAG的VID和PID已经不是FT2232默认的了，FTDI的驱动已经不可用，需要对驱动程序信息进行修改。可以重新解压缩一份驱动程序，例如解压缩到E:\MumJTAG。用文本编辑器打开E:\MumJTAG\ftdibus.inf，修改其中的FtdiHW、FtdiHW.NTamd64、Strings等几段，红色字体表示增加或有变化的部分：
用文本编辑器打开E:\MumJTAG\ftdibus.inf，修改其中的FtdiHW、FtdiHW.NTamd64、Strings等几段，红色字体表示增加或有变化的部分：
这样，驱动程序就修改好了。将MumJTAG的USB电缆连上，提示安装驱动的时候，将路径指向E:\MumJTAG。
至此，MumJTAG就制作完成了。要验证它能不能用，我们还需要使用OpenOCD、urjtag和gdbproxy，请看我后面的文章。
November 19 PowerPC处理器MPC8313E初体验
这篇文章是绝对的菜鸟文，用于记录我在玩8313过程中遇到的问题和解决方案。首先展示下我焊的那块8313板后面的好几十个0402的104电容，焊这些东西耗费了我一天时间…… 先给一个参照物，这是一支笔 然后是我手焊的0402电容…… 开始正文，PowerPC的启动比较奇怪（当然我是带着ARM的眼光看的），CPU内核需要从外部存储设备加载配置字，用这些配置字初始化PLL，并决定从哪个地址启动。PLL初始化之后就不能更改，看来PowerPC根本没有打算往低功耗方面发展。在8313上，Flash内没有内容时，可以用配置字b1100启动，CPU速度是333M，DDR内存时钟MCK是166M；用这个配置可以烧写Flash。我很疑惑的是b1100这个配置字令CPU处于PCI从模式，理论上需要有PCI_CLK，CPU才能启动。但是在我们的板上，PCI_CLK接地，而PCI_SYNC_IN用一个22欧电阻接到了PCI_SYNC_OUT上（当然这是抄官方开发板的），所有晶振都没有焊呢，不知道怎么搞得，就能产生很准确的66M时钟，我真很汗。 焊好电源、CPU、DDR之后，测试了下DDR，速度还是不错的，120MB的内存两秒就扫描完了，ARM可做不到这点。进一步研究了下，发现Freescale晃点我，开发板上用的是DDR2 667的内存芯片，但是MPC8313 DDR控制器的最高速度只有166M即DDR 333的水平……估计MPC8313也就用了DDR2芯片的ODT功能，要是外接电阻的话，DDR一代的芯片也可以用。 经过很长时间的资料搜索和摸索，终于知道怎么用CodeWarrior（Windows版）调试U-Boot了。跟过去一样，还是虚拟机下用Samba共享U-Boot的程序目录，然后用CodeWarrior打开。编译器刚才已经提到了，用Freescale自己的BSP来做一个，调试的具体操作可以看CodeWarrior（Linux版）的文档。我还是把这部分贴出来，CodeWarrior Linux版有550M，下载需要好久，给大家提供个方便吧。 需要注意的是，不可以直接将U-Boot加载到内存里进行调试，要先烧写；简单点说就严格按照下面这篇教学里说的做。可能你会需要一个U-Boot在DDR里的执行入口（文中描述的Now running in RAM - U-boot at: XXXX），这个入口U-Boot 1.3.4默认是不打印的，打印这个信息的代码在board.c中的board_init_f()函数末尾部分，默认是个DEBUG宏，把它改成printf就可以了。等以后我彻底研究明白了再上来写为什么要先烧写才能调试。
This section shows you how to use the CodeWarrior debugger to debug the U-Boot universal boot loader. U-Boot resides in flash memory on target systems and boots an embedded Linux image developed for those systems.
Note: The Linux Application Edition of this product does not support debugging the U-Boot bootstrap firmware.
The topics in this section are:
To prepare to debug U-Boot on a target system, you first install on the host Linux computer the Board Support Package (BSP) for the particular target system you want to debug. Then you configure the BSP U-Boot package to place debugger symbolic information in the U-Boot binary executable file. Finally, you create a new CodeWarrior project that you will use to debug U-Boot on the target system.
Note: The first part of this procedure must be performed on a Linux host.
To prepare to debug U-Boot on a target system:
You can obtain BSPs for Freescale Power Architecture target systems from this web page: Note: If you are using a Linux Target Image Builder (LTIB) BSP, you may need to change the optimization flag of the CFLAGS argument in this file: You now have an ELF-format U-Boot binary executable file that contains debugger symbolic information. In addition, you have a U-Boot raw binary (.bin) file that you can write to flash memory on the target board.
Note: It is best to leave the ELF-format U-Boot binary file in this location, so that when you create a CodeWarrior project with the file, the CodeWarrior IDE can find all of the source U-Boot source code files needed to debug the binary file.
Note: The following procedure must be performed using the Professional Edition of this CodeWarrior product.
Refer to the "Flashing U-Boot" section of the target system's BSP User's Guide for instructions that show how to flash U-Boot to the system. This document is typically located in the help/software folder of the BSP.
Warning: Do not write the ELF-format U-Boot file to flash memory; you must use the raw binary U-Boot file.
The standard Open dialog box appears.
Note: You must use a JTAG run-control device to debug U-Boot. The CodeWarrior USB TAP and the CodeWarrior Ethernet TAP are each JTAG devices.
The CodeWarrior IDE creates a CodeWarrior project containing the source files used to build the U-boot binary file. The CodeWarrior project file is located in the same directory as the ELF-format U-Boot file.
Note: For the IDE to create complete a U-Boot project file, all source files used to build the ELF format U-Boot file must be available. While the IDE is building the new CodeWarrior project, if it cannot find a U-Boot source code file, it displays a dialog box with which you can navigate to and select the file. For each source code file that cannot be found, the IDE logs a message to the Project Creator Log window.
Once project creation is complete, the IDE displays the project in a project window. (See Figure 3.73.)
You now have CodeWarrior project with which you can debug the U-Boot bootstrap firmware.
Note: While debugging U-Boot on 86xx, if address translations has not been enabled and you set a breakpoint in a part of code after the address translation is done, this breakpoint will not be hit. Breakpoints can be used until enable address translation is done. You can use step into to debug through the address translation section (breakpoints / step over / run to cursor cannot be used). After the translation is enabled, you can start using again the hardware breakpoints. A breakpoint set in the c) part of code while debugging in the a) part of code will not be hit.
During a typical U-Boot start-up sequence, the target processor starts executing U-Boot in flash memory. U-Boot then enables the Memory Management Unit (MMU), and relocates itself to RAM.
CodeWarrior build target settings required to debug U-Boot in flash memory differ from the settings required to debug U-Boot in RAM. Therefore, you must use individual CodeWarrior debug sessions to debug the flash memory and RAM sections:
This procedure shows how to debug U-Boot in flash memory before the memory management unit (MMU) is initialized.
This procedure shows how to debug U-Boot in flash memory after the memory management unit (MMU) is initialized.
This procedure shows how to debug U-Boot in RAM. To debug U-Boot in flash memory before the target board's memory management unit (MMU) is enabled:
The Target Settings window (Figure 3.74) appears.
The Debugger Settings panel (Figure 3.75) appears.
The Remote Debugging settings panel (Figure 3.76) appears.
The Edit Connection dialog box (Figure 3.77) appears, displaying the configuration for the selected remote connection.
The Edit Connection dialog box disappears.
The Debugger PIC Settings settings panel (Figure 3.78) appears.
Note: An alternate load address causes the debugger to assume that all sections have been relocated to RAM. If you specify no alternate load address, the debugger can display source code only for sections in flash memory. If you specify an alternate load address, the debugger can display source code only for sections in RAM.
The EPPC Debugger Settings settings panel (Figure 3.79) appears.
The Target Settings window disappears. The CodeWarrior IDE saves your changes to target settings.
The system resets.The terminal emulator displays U-Boot status messages.
Note: If U-Boot asks for the MAC address of the board's Ethernet interface, enter a valid MAC address, such as 00:01:03:00:01:04.
U-Boot finishes initialization and displays this message (where N is the number of seconds left before autoboot starts): The U-Boot command prompt appears: The CodeWarrior debugger connects to the target system and displays a debugger window.
The debugger halts U-Boot execution and displays disassembled code in the Source pane of the debugger window (See Figure 3.80).
The debugger sends a hard reset signal to the board. The debugger window displays the __start section. You can debug from this point up to the first blr instruction in start.S. To debug U-Boot in flash memory after the target board's memory management unit (MMU) is enabled:
The Target Settings window (Figure 3.74) appears.
The Debugger Settings panel (Figure 3.75) appears.
The Remote Debugging settings panel (Figure 3.76) appears.
The Edit Connection dialog box (Figure 3.77) appears, displaying the configuration for the selected remote connection.
The Edit Connection dialog box disappears.
The Debugger PIC Settings settings panel (Figure 3.78) appears.
Note: An alternate load address causes the debugger to assume that all sections have been relocated to RAM. If you specify no alternate load address, the debugger can display source code only for sections in flash memory. If you specify an alternate load address, the debugger can display source code only for sections in RAM.
The EPPC Debugger Settings settings panel (Figure 3.79) appears.
The Target Settings window disappears. The CodeWarrior IDE saves your changes to target settings.
The system resets.The terminal emulator displays U-Boot status messages.
Note: If U-Boot asks for the MAC address of the board's Ethernet interface, enter a valid MAC address, such as 00:01:03:00:01:04.
U-Boot finishes initialization and displays this message (where N is the number of seconds left before autoboot starts): The U-Boot command prompt appears: The CodeWarrior debugger connects to the target system and displays a debugger window.
The debugger halts U-Boot execution and displays disassembled code in the Source pane of the debugger window (See Figure 3.80).
The debugger sends a hard reset signal to the board. The debugger window displays the __start section. You can debug from this point up to the first blr instruction in start.S.
The Symbolics Window (Figure 3.88) appears.
A contextual menu appears, as shown in Figure 3.89.
The IDE sets the hardware breakpoint on the selected line of code. A blue diamond symbol appears over the tick mark in the breakpoint column, indicating that a hardware breakpoint is set.
The debugger resets the target system and halts U-Boot execution at the start of U-Boot.
The debugger starts U-Boot execution. When execution reaches the hardware breakpoint, the debugger halts execution. A debugger window (Figure 3.90) appears, showing the source code of the board_init_f() function.
Note: In this debugger window, the blue arrow indicates that the program counter (PC) is at the line of code on which you set the hardware breakpoint. You may now use the features of the CodeWarrior debugger to step through the source code and debug U-Boot in flash memory.
To debug U-Boot in RAM:
The system resets.The terminal emulator displays U-Boot status messages (as shown in Figure 3.91).
U-Boot finishes initialization and displays this message (where N is the number of seconds left before autoboot starts): The U-Boot command prompt appears (as shown in Figure 3.91): The Target Settings window (Figure 3.92) appears.
The Debugger Settings panel (Figure 3.93) appears.
The Remote Debugging settings panel (Figure 3.94) appears.
The Edit Connection dialog box (Figure 3.95) appears, displaying the configuration for the selected remote connection.
The Edit Connection dialog box disappears.
The Debugger PIC Settings settings panel (Figure 3.96) appears.
Use the format: 0xFFFFFFFF
Note: An alternate load address causes the debugger to assume that all sections have been relocated to RAM. If you specify no alternate load address, the debugger can display source code only for sections in flash memory. If you specify an alternate load address, the debugger can display source code only for sections in RAM.
The EPPC Debugger Settings settings panel (Figure 3.79) appears.
The Target Settings window disappears. The CodeWarrior IDE saves your changes to target settings.
The CodeWarrior debugger connects to the target system and displays a debugger window.
The debugger halts U-Boot execution and displays disassembled code in the Source pane of the debugger window (See Figure 3.98).
The Symbolics Window (Figure 3.99) appears.
A contextual menu appears, as shown in Figure 3.89.
The IDE sets the hardware breakpoint on the selected line of code. A blue triangle appears over the tick mark in the breakpoint column, indicating that a hardware breakpoint is set.
The debugger resets the target system and halts U-Boot execution at the start of U-Boot.
Note: In this debugger window, the blue arrow indicates that the program counter (PC) is at the line of code on which you set the hardware breakpoint. You may now use the features of the CodeWarrior debugger to step through the source code and debug U-Boot in RAM. October 09 使用J-Link GDB Server + Eclipse CDT进行ARM程序调试之前我预告过这篇文章，这段时间以来，我工作一直比较忙，而且在装修我的小破窝，生活的压力让我把业余的时间都贡献给奥山战场了，我的小牧师，杀人很慢，被杀倒是挺速度的，呵呵；想当年上学的时候，我也是副本RL，逃课带MC；现在工作了就只能沦为战场混荣誉的了……平时没有太多时间，职业不开UT跟混收麦子；周末开UT打各种麦子和各种国家队。国际惯例，二区风行者暗夜暗牧，多多和雯雯（Sigh，这个名字我GF取的，她叫雯雯和多多）。欢迎风行者的周末一同UT，我排队相当狠的，嘿嘿。
在开始前另外提一件事情，我之前说想找个便宜的PowerPC调试解决方案，现在其实我也算找到了——还是Macraigor的OCDRemote，用起来和OpenOCD差不多，具体用法和支持的器件请看Macraigor的官网http://www.macraigor.com/。不过，“0f 84 f0 fc ff ff”->“0f 85 f0 fc ff ff”；我所提供的信息来自互联网，仅可以用于个人学习和研究，对于产生的后果，我不负任何责任；如果你喜欢这个软件，请联系Macraigor的销售，购买他们的调试硬件。但OCDRemote + Wiggler目前并不支持e300、e500内核，我要用的MPC8313还是调试不了……
首先明确一下，为什么我要抛开IAR、ADS、Keil这样的IDE选择GNU阵营的东西——这并不是因为GNU是自由软件，而是因为在一个CPU刚上手的时候，往往还是需要别人的代码来参考的，u-boot里面的样例很多，但是移植到IDE环境下开发却很困难。
之前这篇文章里http://xianzilu.spaces.live.com/blog/cns!4201FDC93932DDAF!485.entry，我介绍过J-Link是一个非常不错的ARM调试工具，它的软件包里带有GDB Server。J-Link在JTAG频率为8MHz时，ARM926EJ-S可以达到300~400kB/s的下载速度。Eclipse是一个免费的JAVA开发调试IDE，因为它很受欢迎，所以Eclipse也增加了对C/C++开发的支持；过去是需要下载Eclipse，然后再下载C/C++开发插件CDT，现在官网已经有直接打包好的Eclipse + CDT下载了，地址是http://www.eclipse.org/downloads/，无论你在Windows还是在Linux下使用Eclipse，都需要安装Java Runtime Environment。但我们进行的是交叉开发，CDT里头自带的Debug Configuration无法完成这种开发，需要安装一个插件。具体步骤：首先确认你的操作系统可以上网（实际的、虚拟机里的都一样）；然后在Eclipse的菜单里选择Help->Software Updates；选择Available Software选项卡，点Add Site按钮；输入地址http://www.zylin.com/zylincdt，列表里就多了一项；刷新之后点上面的Install按钮安装。
ZylinCDT用起来很方便，只需要在Debug Configuration里面配置Commands选项卡，填入Initiate Commands和Run Commands；其他和Eclipse自己的Debug Configuration差不多。事实上，ZylinCDT就是用这些填入的内容取代了正常的GDB初始化命令，给出我的Initiate Commands给大家参考（Run Commands为空）：
我调试的目标CPU是AT91SAM9263，通过以上的初始化命令，可以实现PLL、SDRAM的初始化，并将u-boot带码加载到内存中。J-Link的monitor命令可以看J-Link安装之后的文档J-Link GDB server user guide的3.4节Supported remote commands。
今天说的这些事情没有什么难度，用Eclipse + J-Link调试的关键就是要用ZylinCDT这样的插件，关于ZylinCDT的信息可以看它的官网http://www.zylin.com/，解释的比我说的详细多了。Eclipse的教学文档网络上也多得很，Eclipse本身界面就很友好，不用什么教学，自己摸索一会儿也就会了。我就总结下：Eclipse可以自动创建Makefile，虽然使用的是GCC工具链，却有像ADS、Codewarrior这样IDE环境的便利；对于U-boot、Linux内核这样的有现成Makefile的程序，Eclipse能将它们导入，一样能调试。但是，和Source Insight强大的自动完成功能相比，Eclipse逊色太多了。我的开发解决方案是：Linux虚拟机下的SMB共享代码 + Windows下的Source Insight编辑 + Linux虚拟机下的arm-linux-gcc编译 + Windows下的J-Link GDB Server + Linux虚拟机下的Eclipse CDT & ZylinCDT；呵呵，好绕啊；但如果代码不复杂，就直接用Eclipse编辑也挺好。 |
||||||||||||||||||||||||||||||||||||||||||
|
|
