虽然以前也玩过ARM，但那时候都是成形的系统了已经，自己无非是写写驱动做做应用，底层硬件对我来讲基本也就是一个“黑匣子”。这回我的目的自然不是移植一个操作系统，然后跑几个应用这么简单啦，所以在挑选开发板的时候自然就有所考虑了。这所谓的考虑说到底就只有一个原则：越简单越好，因为我要从最小系统玩开始！

最后挑选的是一块基于STM32F103 VET6芯片的最小系统开发板，板子上就只带一个JTAG接口，以及用来给芯片供电的USB接口和电源插座，其它所有引脚均通过2.54插针的方式引出，正好满足虐待自己的目的。当然，为了能够向开发板中下载程序，一条编程电缆自然是少不了的，与这个板配套使用的是JLink（估计应该是clone的）。

板子拿到手后，第一感觉就是做工比较细致，算是自己下一步追求的目标:) 前两天忙了点别的，昨天才正式开始给板子上电，试着装了开发板自带的JLink驱动，没有费什么劲系统就找到了该下载线，于是立即转向OpenOCD。OpenOCD是德国人的一个开源项目，主要目的是实现一个在线调试器，同时也能够实现程序烧写等目的，目前支持很多种编程线，这与我对想像中的STM32环境构想一致，所以很快就决定使用它了。

现在的问题是怎么让手头的这个JLink能够与OpenOCD通信上。首先按照YAGARTO网站上介绍的步骤在Windows下安装好了OpenOCD，可惜这个好像并没有编译进对JLink的支持。于是从OpenOCD的官方网址下了一个最新的安装文件安装后，并按照网友在Mac下的步骤启动OpenOCD，毫无悬念地得到了如下的出错信息（玩家第一规律：出错是必然的，出什么错是偶然的）：

Error: Cannot find jlink Interface! Please check connection and permission.

好了，开始猜原因吧！Google依然是最好的助手，先把出错信息Search一把，发现Sparkfun上有人也在讨论类似的问题，但没有给出解来。同时也有人非常肯定地指出说OpenOCD是支持JLink的，至少在Linux系统上是没有问题。从各种收集到的信息来看，我想可能会是下面几个原因：

• OpenOCD不支持clone的JLink
• 需要重新编译OpenOCD的代码
• Windows下OpenOCD对JLink的支持不完备

第二条很快经过实践检验之后被证明是不对的，但自己也不是完全没有收获，至少整理出了OpenOCD在Cygwin下的编译过程：

$ svn co http://svn.berlios.de/svnroot/repos/openocd openocd
$ cd openocd/trunk/
$ ./bootstrap
$ ./configure --enable-jlink
$ make

编译完成之后，使用下面的配置文件stm32cfg运行openocd命令：

$ ./openocd.exe -f stm32.cfg

得到的错误依然是无法找到JLink。好在开源虽然有层出不穷的问题，但不管什么时候你都可以拿到代码去寻找问题所在。OpenOCD是拿C语言写的，在做了一些简单的分析和调试之后，确认应该是通过libusb无法得到USB设备所至的，也就是jtag/jlink.c文件中的这一条语句：

	busses = usb_get_busses();

接着Google，原来这个是LibUsb-Win32库，有人在讨论说Vista64下这个库没法用，但显然不属于我的情况。由于怀疑可能是libusb库版本导致的问题，把之前安装的OpenOCD全部删除，但编译依然能够通过，原因是Cygwin的/bin/cygusb0.dll文件似乎就是这个库。抱着试试看的态度，下载了LibUsb-Win32官方的安装包重新安装，安装完后运行其测试程序，终于能够顺利找到J-Link这个设备了：

此时再运行openocd命令，看起来就一切正常了：

$ ./openocd.exe -f stm32.cfg
Open On-Chip Debugger 0.2.0-in-development (2009-06-06-01:25) svn:2076

BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS

$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $
500 kHz
Info : J-Link ARM V6 compiled Apr  1 2009 11:56:10
Info : JLink caps 0x19ff7bbf
Info : JLink hw version 60000
Info : JLink max mem block 8832
Info : Vref = 3.287 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 1

Info : J-Link JTAG Interface ready
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)
Info : JTAG Tap/device matched
Info : JTAG tap: stm32.bs tap/device found: 0x06414041 (Manufacturer: 0x020, Part: 0x6414, Version: 0x0)
Info : JTAG Tap/device matched

试着用telnet连接到OpenOCD

C:\Documents and Settings\Administrator>telnet localhost 4444
Open On-Chip Debugger
>

再按照STM32 Primer programming with OpenOCD on GNU/Linux中的说明执行了几个测试命令：

> halt
target was in unknown state when halt was requested

这个命令像是挂起CPU？

> flash probe 0
device id = 0x10016414
flash size = 512kbytes
flash 'stm32x' found at 0x08000000

这个命令是用来检测Flash类型的。

> flash erase_check 0

这个是命令是检查Flash中特定块是否擦除，这就算开始对ARM动刀了已经;-)

> flash erase_check 0

过了一把擦除Flash的瘾！

中间有一个小的插曲，开始的时候将stm32.cfg中的JTAG时钟设置成自动识别的，似乎不是很稳定。刚开始的时候还能够正常地跟STM32通信上，后来就一直报错，并且需要重新启动计算机，再能够再次工作。

jtag_khz 0

这一问题一直困扰了我一个晚上，今天早上把这一频率设置成固定值后，稳定了不少：

jtag_khz 500

目前暂时先宣告JLink + OpenOCD部分正常工作吧，接下去硬件要实现的目标，是用基于FT2232的编程电缆，实现对STM32的控制，这还需要假以时日。软件上就相对明确多了：编译ARM上运行的HelloWorld，并下载到STM32中运行！