SparkFun Forums 

Where electronics enthusiasts find answers.

Open source ARM Debugger
By VV
#39176
After a few hours of scratching my head I got the following combination to work:

- OpenOCD
- Olimex ARM-USB-OCD
- Mac OS X
- with libusb/libftdi (for d2xx drivers, please see another message further down in this chain)

I guess I might save somebody else's trouble by documenting the main parts of the process. The process is rather straightforward for those who are familiar with compiling their own tools. However, there are at least two gotchas which really bit me.

The instructions should be not-too-dependent-on-the-version-but-you-never-know, so here are the versions I used:

- Mac OS X 10.5.1 with FTDI USB serial driver 2.2.8 (this will work in Tiger, as well)
- OpenOCD from SVN, r214
- libusb 0.1.12
- libftdi 0.10

Approximately the same process should work with any FT2232-based JTAG (e.g. Amontec), but the part below about the USB driver has to be modified accordingly.

---

So, let's start. I downloaded the source code into directories libusb-0.1.12, libftdi-0.10 and openocd.
Code: Select all
cd libusb-0.1.12
./configure
make
sudo make install
cd ..

cd libftdi-0.10
./configure
make
sudo make install
cd ..

cd openocd
./bootstrap
./configure --enable-ft2232_libftdi --enable-usbprog
make
sudo make install
cd ..
The point here is that while everything compiles fine without the --enable_usbprog, nothing works. The start-up will fail because of the symbol _usb_busses is not found. Both libraries need to be given to the configure script. (This one made me plunge into the deep waters of OS X dylib's. It did not help in solving this problem, but at least I now know a lot about two-level symbols in dylibs, the use of otool, and so on...)

Now everything is compiled and installed, and OpenOCD will complain about missing configuration files. This can be fixed by obtaining one, e.g. http://www.yagarto.de/download/openocd/ ... usbocd.cfg

So, let's try:
Code: Select all
openocd -f at91r40008_armusbocd.cfg
At least in an out-of-the-box Leopard it won't work. There will be a complaint:
Code: Select all
unable to claim usb device. Make sure ftdi_sio is unloaded!
This complaint is actually almost correct. It is helpful if you happen to know how things work in Linux. The problem is that there is already something using the adapter.

Leopard ships with the drivers for FT2232, they are a kernel extension in /System/Library/Extensions/FTDIUSBSerialDriver.kext. This extension will be loaded for all FTDI serial adapters to give com ports. And as this extension is automatically loaded, the USB JTAG adapter will be seen as two serial ports:
Code: Select all
vvs-macbook:usb vv$ ls /dev/tty.usb*
/dev/tty.usbserial-FTNF55BUA
/dev/tty.usbserial-FTNF55BUB
So, the OpenOCD cannot use the JTAG adapter because the system has already taken it into use as a serial adapter.

The trivial (sledgehammer) solution is to get rid of the FTDI serial driver:
Code: Select all
sudo rm -r /System/Library/Extensions/FTDIUSBSerialDriver.kext
Unfortunately, this has the very nasty side effect that no FTDI-based serial adapter will work in the future any more. That may be acceptable in some cases, but many people need the serial port for embedded systems, as well.

Ideally, the operating system should be prevented from loading the serial driver for port A of the JTAG adapter. Port B is actually used as a serial port in the Olimex adapter, so even that driver should be loaded.

This can be achieved by editing the FTDI kernel extension. Sounds frightening but is not that difficult, just edit the file /System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist. This is an OS X property list file, and it is a valid XML file, so any text editor or XML editor will do.

This file lists all known FTDI based USB devices with the VID ad PID (Vendor and Product ID) values and names. The file lists both serial ports of the Olimex part, and the A port defintion needs to be removed. Here is the part to be removed:
Code: Select all
<key>Olimex OpenOCD JTAG A</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.FTDI.driver.FTDIUSBSerialDriver</string>
<key>IOClass</key>
<string>FTDIUSBSerialDriver</string>
<key>IOProviderClass</key>
<string>IOUSBInterface</string>
<key>bConfigurationValue</key>
<integer>1</integer>
<key>bInterfaceNumber</key>
<integer>0</integer>
<key>idProduct</key>
<integer>3</integer>
<key>idVendor</key>
<integer>5562</integer>
</dict>
Remove this part and leave the B device intact. Save the file (and remember to check the file permissions).

Now reboot the computer. That is not absolutely necessary; removing and reinserting the USB device may suffice, but as the FTDI driver refuses to unload with kextunload, the best way to ensure everything works is to reboot.

Now you should have a working system with both a working USB JTAG adapter and a working serial port in that adapter. You can check that the plist editing went right by:
Code: Select all
vvs-macbook:usb vv$ ls /dev/tty.usb*
/dev/tty.usbserial-FTNF55BUB
Only the B port should be available when the device is plugged in.

...

IMHO, FTDI has made a mistake here. The Olimex USB port A cannot ever been used as a serial port, so it should not be listed in the driver. Also, FTDI could have saved some of my time by documenting their OS X driver a bit better.
Last edited by VV on Fri Dec 07, 2007 4:17 am, edited 1 time in total.
By wiml
#39178
Thanks for the description, VV. I'll probably be going down this path soon and I bet your post will save me some frustration.
By VV
#39185
Surprisingly, making it work with D2XX was simple (if you don't mind resorting to non-open s/w). D2XX should be faster and there are reports of it being more stable than libftdi+libusb combination.

The outline:

- get the FTDI driver
- ignore the FTDI Readme for the most part
- compile OpenOCD with the right flags
- perform the USB driver lobotomy for Olimex JTAG A

There aren't any very difficult steps, the only hindrance is the FTDI documentation which is not really up-to-date.

---

So, let's start with the FTDI driver installation. Get the .dmg file from the FTDI website ("Universal D2XX.0.1.0.dmg"). Mount (attach it) and read the ReadMe to get the overall picture, but do not pay too much attention to the VID/PID table stuff in there, as that part is just to intimidate the casual bypasser. The Xcode project files referred to in the documentation neither exist nor are needed.

The installation:
Code: Select all
cd /Volumes/Universal\ D2XX/D2XX
sudo cp bin/libftd2xx.0.1.0.dylib /usr/local/lib
sudo ln -sf /usr/local/lib/libftd2xx.0.1.0.dylib /usr/local/lib/libftd2xx.dylib
sudo cp bin/ftd2xx.h /usr/local/include
sudo cp Samples/WinTypes.h /usr/local/include
What was done? A dylib was placed to the right place and a link was made to it. Then a couple of header files were moved where they belong. This is exactly what "make install" does for libftdi.

The FTDI D2XX OS X driver is really different from the serial driver. The serial driver is a kernel extension which is automatically loaded when the USB detects the correct device. The D2XX library is only loaded if a program using it is loaded. This way it is very similar to the libftdi.

---

N.B. The test scripts in the "Samples" directory do not work with non-standard VID/PID combinations (i.e. with any programming dongles). If you want to make them work, add the following statement first in the main program:
Code: Select all
FT_SetVIDPID(0x15ba, 0x0003);
This will tell the driver to use non-standard VID/PID (the VID/PID there are correct for the Olimex JTAG).

Of course, you do not need to try any of the sample programs if your only aim is to make OpenOCD work. They may, however, help in debugging should anything go wrong.

---

Now that the D2XX driver is happily installed, let's get to compile the OpenOCD for it:
Code: Select all
./bootstrap
./configure --enable-ft2232_ftd2xx
make
make install
---

Last thing (or first, do it whenever you want) is to perform the driver lobotomy for Olimex JTAG A. It can be done by editing the relevant .plist as explained in the first mesage of this thread.

---

And that's it. Seems to work for me (reported RAM upload time for 37 kB of code was 0.12 s to an AT91R40008).
By mifi
#39220
Hello vv,

you wrote:
D2XX should be faster and there are reports of it being more stable than libftdi+libusb combination.
This is strange, I have test the FTDI driver with OpenOCD on my Mac
too with Eclipse. And I could see some strange behaviour. Take a looke here:
https://lists.berlios.de/pipermail/open ... 00412.html

Now I have removed the FTDI driver and use libusb/libftdi instead and have no
problem like I describe above. Strange...

Regards,

mifi
By VV
#39428
mifi,

I really do not have a clue on what is going on. There are two possibilities I can think of:

1. There is something Leopard-specific going on. As far as I have been able to see, the OS X driver is the same as the Linux driver, just the USB IO commands have been changed. (Again, this is just a feeling or a guess, as I have not seen the source for either of them.) That way it should be relatively stable, but if there have been any changes in the USB infrastructure between Tiger and Leopard, then things could go wrong.

2. The D2XX driver should be a lot faster than the libusb+libftdi combo. In my very limited experience, D2XX is faster in OS X than in Windows. So, if you have problems with OS X + D2XX but not with any other combination, your JTAG may simply be too fast for the target at some point. (OTOH, if Linux people have it working with D2XX, then the problem isn't there.)

Neither of those is an easy one to debug. Let's see if other people have had similar experience.
By Sojastar
#47019
Hello all,

I am trying to get my Olimex ARM-USB-OCD to work on both Windows XP and Mac OS X (Leopard), but haven't had any luck so far on any system.

I followed VV's instructions for libftdi and D2XX. Each time, everything compiled fine. I think the problem may come from the ".plist lobotomy" part. I do cut the <key>Olimex OpenOCD JTAG A</key> ... </dict> piece but, after reboot, serial A still shows in /dev.

And I get this message from OpenOCD :

mac0016cbcc0d6b:Desktop sojastar$ openocd -f at91sam7s256-armusbocd.cfg
Info: openocd.c:93 main(): Open On-Chip Debugger (2007-09-05 09:00 CEST)
Error: ft2232.c:1381 ft2232_init_ftd2xx(): unable to open ftdi device: 3
Error: ft2232.c:1396 ft2232_init_ftd2xx(): ListDevices: 2

Error: ft2232.c:1398 ft2232_init_ftd2xx(): 0: Olimex OpenOCD JTAG A
Error: ft2232.c:1398 ft2232_init_ftd2xx(): 1: Olimex OpenOCD JTAG B

Any idea?

Thanks,
Julien
By mah
#47184
Sojastar wrote:Hello all,

I am trying to get my Olimex ARM-USB-OCD to work on both Windows XP and Mac OS X (Leopard), but haven't had any luck so far on any system.

I followed VV's instructions for libftdi and D2XX. Each time, everything compiled fine. I think the problem may come from the ".plist lobotomy" part. I do cut the <key>Olimex OpenOCD JTAG A</key> ... </dict> piece but, after reboot, serial A still shows in /dev.
...
Julien
I had exactly the same thing.

Try:
- unplug the ARM-USB-OCD
- sudo kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext/
- sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext/

see wether /dev/cu.* shows only the JTAG B serial port - did it for me

-Michael
By Sojastar
#47202
Many thanks!

It works fine. A strange thing happens though : when unloading the extension, kextunload returns :

kextunload: unload kext /System/Library/Extensions/FTDIUSBSerialDriver.kext/ failed

Yet, the trick works after I reload the extension. I won't complain.

Thanks again,
Julien
User avatar
By jstoezel
#64313
Hi,

Thanks for the detailed post.

I'm at the point where I have:
- downloaded eclipse,
- an Olimex ARM-USB-OCD,
- compiled and installed openOCD following the instructions,
- modified the D2xx driver configuration,
- only device B seen as a serial port on my mac.

Again, thanks for the detailed post but now... What? How do I get from there to the point where I use Eclipse to compile a project for my ARM, burn it to flash and run it with the debugger?
VV wrote:After a few hours of scratching my head I got the following combination to work:

- OpenOCD
- Olimex ARM-USB-OCD
- Mac OS X
- with libusb/libftdi (for d2xx drivers, please see another message further down in this chain)

I guess I might save somebody else's trouble by documenting the main parts of the process. The process is rather straightforward for those who are familiar with compiling their own tools. However, there are at least two gotchas which really bit me.

The instructions should be not-too-dependent-on-the-version-but-you-never-know, so here are the versions I used:

- Mac OS X 10.5.1 with FTDI USB serial driver 2.2.8 (this will work in Tiger, as well)
- OpenOCD from SVN, r214
- libusb 0.1.12
- libftdi 0.10

Approximately the same process should work with any FT2232-based JTAG (e.g. Amontec), but the part below about the USB driver has to be modified accordingly.

---

So, let's start. I downloaded the source code into directories libusb-0.1.12, libftdi-0.10 and openocd.
Code: Select all
cd libusb-0.1.12
./configure
make
sudo make install
cd ..

cd libftdi-0.10
./configure
make
sudo make install
cd ..

cd openocd
./bootstrap
./configure --enable-ft2232_libftdi --enable-usbprog
make
sudo make install
cd ..
The point here is that while everything compiles fine without the --enable_usbprog, nothing works. The start-up will fail because of the symbol _usb_busses is not found. Both libraries need to be given to the configure script. (This one made me plunge into the deep waters of OS X dylib's. It did not help in solving this problem, but at least I now know a lot about two-level symbols in dylibs, the use of otool, and so on...)

Now everything is compiled and installed, and OpenOCD will complain about missing configuration files. This can be fixed by obtaining one, e.g. http://www.yagarto.de/download/openocd/ ... usbocd.cfg

So, let's try:
Code: Select all
openocd -f at91r40008_armusbocd.cfg
At least in an out-of-the-box Leopard it won't work. There will be a complaint:
Code: Select all
unable to claim usb device. Make sure ftdi_sio is unloaded!
This complaint is actually almost correct. It is helpful if you happen to know how things work in Linux. The problem is that there is already something using the adapter.

Leopard ships with the drivers for FT2232, they are a kernel extension in /System/Library/Extensions/FTDIUSBSerialDriver.kext. This extension will be loaded for all FTDI serial adapters to give com ports. And as this extension is automatically loaded, the USB JTAG adapter will be seen as two serial ports:
Code: Select all
vvs-macbook:usb vv$ ls /dev/tty.usb*
/dev/tty.usbserial-FTNF55BUA
/dev/tty.usbserial-FTNF55BUB
So, the OpenOCD cannot use the JTAG adapter because the system has already taken it into use as a serial adapter.

The trivial (sledgehammer) solution is to get rid of the FTDI serial driver:
Code: Select all
sudo rm -r /System/Library/Extensions/FTDIUSBSerialDriver.kext
Unfortunately, this has the very nasty side effect that no FTDI-based serial adapter will work in the future any more. That may be acceptable in some cases, but many people need the serial port for embedded systems, as well.

Ideally, the operating system should be prevented from loading the serial driver for port A of the JTAG adapter. Port B is actually used as a serial port in the Olimex adapter, so even that driver should be loaded.

This can be achieved by editing the FTDI kernel extension. Sounds frightening but is not that difficult, just edit the file /System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist. This is an OS X property list file, and it is a valid XML file, so any text editor or XML editor will do.

This file lists all known FTDI based USB devices with the VID ad PID (Vendor and Product ID) values and names. The file lists both serial ports of the Olimex part, and the A port defintion needs to be removed. Here is the part to be removed:
Code: Select all
<key>Olimex OpenOCD JTAG A</key>
<dict>
<key>CFBundleIdentifier</key>
<string>com.FTDI.driver.FTDIUSBSerialDriver</string>
<key>IOClass</key>
<string>FTDIUSBSerialDriver</string>
<key>IOProviderClass</key>
<string>IOUSBInterface</string>
<key>bConfigurationValue</key>
<integer>1</integer>
<key>bInterfaceNumber</key>
<integer>0</integer>
<key>idProduct</key>
<integer>3</integer>
<key>idVendor</key>
<integer>5562</integer>
</dict>
Remove this part and leave the B device intact. Save the file (and remember to check the file permissions).

Now reboot the computer. That is not absolutely necessary; removing and reinserting the USB device may suffice, but as the FTDI driver refuses to unload with kextunload, the best way to ensure everything works is to reboot.

Now you should have a working system with both a working USB JTAG adapter and a working serial port in that adapter. You can check that the plist editing went right by:
Code: Select all
vvs-macbook:usb vv$ ls /dev/tty.usb*
/dev/tty.usbserial-FTNF55BUB
Only the B port should be available when the device is plugged in.

...

IMHO, FTDI has made a mistake here. The Olimex USB port A cannot ever been used as a serial port, so it should not be listed in the driver. Also, FTDI could have saved some of my time by documenting their OS X driver a bit better.
By jas
#66305
Came across this thread and it helped me... but with the latest release
of openocd (release "1.0"), if you try to configure with d2xx drivers on OS-X, it will
say something like:

error: The (linux) ftd2xx library from FTDICHIP.com is linux only. Try --enable-ft2232-libftdi instead

However the d2xx drivers do seem to still work... just hack the configure/configure.in file so that it assumes that your version of
OS-X is ok.

Look for something like:

# Cause FTDICHIP does not supply a MAC-OS version
if test $host_os != linux-gnu && test $host_os != linux; then

and change to (inserting your OS-X version):

if test $host_os != linux-gnu && test $host_os != linux && test $host_os != darwin9.6.0; then

[/b]
By JJ
#68114
(This post intentionally left blank.)
Last edited by JJ on Tue Mar 10, 2009 2:55 pm, edited 1 time in total.
By JJ
#68117
I got openocd-0.1.0 to build after modifying configure.in to look for the libftdi library and header files in /opt/local and /usr/local. It took me a while to create a config file, but it works great now. Here's the config file I used:
Code: Select all
if { [info exists CHIPNAME] } {	
   set  _CHIPNAME $CHIPNAME    
} else {	 
   set  _CHIPNAME lpc2294
}

if { [info exists ENDIAN] } {	
   set  _ENDIAN $ENDIAN    
} else {	 
   set  _ENDIAN little
}

if { [info exists CPUTAPID ] } {
   set _CPUTAPID $CPUTAPID
} else {
  # force an error till we get a good number
   set _CPUTAPID 0x4f1f0f0f
}

telnet_port 4444
gdb_port 3333
tcl_port 6666

#interface
interface ft2232
ft2232_device_desc "Amontec JTAGkey"
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0xcff8

jtag_khz 500
# jtag_speed 3
jtag_nsrst_delay 200
jtag_ntrst_delay 200

#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst srst_pulls_trst

#jtag scan chain
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID

set _TARGETNAME [format "%s.cpu" $_CHIPNAME]
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm7tdmi-s_r4
$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x40000000 -work-area-size 0x4000 -work-area-backup 0

fast enable

#flash configuration
#flash bank lpc2000 <base> <size> 0 0 <target#> <variant>
flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14765 calc_checksum

gdb_flash_program enable

init

# For more information about the configuration files, take a look at:
# openocd.texi
Maybe this can be of use to someone else with the same setup.

For the toolchain I use darwinports' arm-elf-gcc (4.3.2), which builds the sample projects from the Olimex website without a hitch. Flashes and runs great using the JTAGkey.

After some experimentation I settled on the following timing parameters:
Code: Select all
jtag_khz 5000
jtag_nsrst_delay 5
jtag_ntrst_delay 5
The upper limit seems to be about 5.3-5.4MHz and the reset timing starts failing at about 3-4 msec. So I settled on these, but even a 10msec delay would be fine - it's still unnoticable. (The 200msec value in the file above is noticable by comparison.) Bisect is your friend here.

(Crap, I see the original post was lost when I edited. I could only edit, trying to post another reply was only giving me an internal server error.)
Last edited by JJ on Tue Mar 10, 2009 3:54 pm, edited 3 times in total.
By Katagia
#68153
I use a cvs version from last week with libftdi unter OS X. My jtag device is a jtagkey tiny. I haven't change any sources and it works.

What configuration do you use and what commands are you using to flash?

Newer versions of openocd seems to have direct flash support but I wasn't able to figgure out how it should work.

I flash it as described in http://www.stud.uni-karlsruhe.de/~usjp/aduc/
By cyphunk
#68661
I tried to recompile find_all using the same method but had some trouble. I'm sure the issue is that I'm using two different sources for my installation. Regardless, when reading the find_all code you can see that it is a simple parse of the USB dev parameters. You can do the same using internal OSX tools.

Specifically, I ran system_profiler SPUSBDataType which gives you details on connected USB devices. To see it more clearly, unplug your device and run system_profiler SPUSBDataType > /tmp/1.txt then plug in your Amontec or other device and run system_profiler SPUSBDataType > /tmp/2.txt and the run a diff diff /tmp/1.txt /tmp/2.txt. Here is my output:
92a93,104
> Amontec JTAGkey:
>
> Product ID: 0xcff8
> Vendor ID: 0x0403 (Future Technology Devices International Limited)
> Version: 5.00
> Serial Number: ********
> Speed: Up to 12 Mb/sec
> Manufacturer: Amontec
> Location ID: 0x04100000
> Current Available (mA): 500
> Current Required (mA): 100
>
Side question: why does the amontec not show up as a /dev/tty* device for me? thanks
Last edited by cyphunk on Sat Mar 21, 2009 4:10 am, edited 1 time in total.
By Katagia
#68891
Because it's eeprom is configured to not show up as uart device.