As a bit of a backup to the whole bootloader thing, I bought an Olimex ARM-USB-OCD JTAG adaptor. This is a multi purpose device that provides you with a USB JTAG interface to the ARM, a USB serial port and a power supply for your target board. It looks pretty useful and is supported by the openOCD project as well as Rowley Crossworks. JTAG is fast for flash programming and pretty well a one-touch solution in Crossworks. I was quite excited when it arrived and hurried to get it set up. By now, I should know better…
When I plugged it in to the Mac, Crossworks just would not talk to it. I tried all sorts but Crossworks stubbornly refused to open the JTAG adaptor. I wasted ages looking for solutions on the web, unplugging it, plugging it back in, and I was beginning to believe it was broken when I cam across a couple of pointers to the problem. There are two issues.
First, it seems that one of my USB leads is out of spec somehow. I had the JTAG adaptor plugged into a PC and discovered, quite by chance that it would work with one cable but not the other. This is a bit mystifying as I had seen no problems with the ‘bad’ cable before – it simply would not work with the Olimex adaptor. YOu see plenty of cables marked up these days as USB 2.0 standard but I had rather assumed this was just a way to get people to buy new cables. Maybe they are different. A bit of checking shows that the USB 3 standard has a specific cable requirement. Anyway, the ’good’ cable was used and the adaptor plugged back into the Mac. No good. Still could not open the JTAG adaptor. that was when I came across the other pointer on the web.
This type of JTAG adaptor is based on the FTDI USB to serial chip. I expect the software uses the serial port to waggle the port control lines to talk to the JTAG port. Anyway, Mac OS X Leopard has drivers built in for these so that wasn’t the problem. Indeed, when I looked at the available serial ports, I could see two associated with the JTAG adaptor. you can find these ports with a command like this:
IMAC:peterharrison$ ls -al /dev/tty.usb*
crw-rw-rw- 1 root wheel 10, 114 8 May 19:10 /dev/tty.usbserial-000014FDA
crw-rw-rw- 1 root wheel 10, 114 8 May 19:10 /dev/tty.usbserial-000014FDB
crw-rw-rw- 1 root wheel 10, 100 8 May 19:18 /dev/tty.usbserial-FTD3TMCH
That is where the problem lay. Since the kernel had seen the device before Crossworks had a chance to see the it, it had nabbed them and turned on both serial ports thus preventing it from behaving like a JTAG adaptor.
To my surprise, it turns out that the Leopard installation actually knows all about the Olimex adaptor and describes it as having two serial ports so they both get turned on. To make all this work properly, you have to tell the kernel to leave the first port alone. If you have a look on your Mac, you should be able to find the FTDI driver property list file here:
It is a text file so it can be edited with any suitable editor. You may need to set permissions or do it from the command line with sudo. CAUTION – make a copy. If you delete this file, all your FTDI serial devices will stop working when you next restart your computer.
When you have it in an editor, look for this section:
<key>Olimex OpenOCD JTAG A</key>
Delete it, leaving the similar ‘B’ section alone. If you then restart your Mac, you should find that only one serial port is listed for this device and Rowley Crossworks, if you have it, can recognise the JTAG adaptor. For those of you who are proud of how long your Mac has gone without a restart you might want to manually unload the kernel drivers and then reload them with the following commands:
IMAC:peterharrison$ sudo kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext/
IMAC:peterharrison$ sudo kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext/
The result will be the same.
This Post Has 7 Comments
If you find yourself without /System/Library/Extensions/FTDIUSBSerialDriver.kext (as I did on fresh Tiger and Snow Leopard installs) you can download it from FTDI at http://www.ftdichip.com/Drivers/VCP.htm
If I manage to stuff up the bootloader on my stm32 I think I’ll start investigating the SWD interface. The beauty of it is that the clock timing is done by the host, so any old microcontroller should be able to implement it. I could only find information on the cortex-m1 protocol, who knows if it’s the same for m3.
How did you stuff up the bootloader?
I did say “if” 😛
At the moment I have no way to reflash the bootloader “if” I manage to overwrite it etc.
I was just looking at all the information for the chip before I start playing with the stamp, just as a backup.
Oops – sorry. Must read these more carefully.
You had me a bit worried there for a while. I had visions of being able to kill the bootloader then have no way to talk to the chip.
There is not much practical information about SWD that I could find. It looks like it would be pretty handy though.
The interface has little-to-no documentation lying around and I can’t seem to figure out why because it seems so damned convenient. The idea of setting up a small python script to feed into a small 8-bit micro to program any SWD enabled chip seems excellent.
I did stumble upon a goldmine of info this evening, possibly enough to put something together 😛
1. The reference manual shows you how to set up the interface, including the sequence you have to clock in to turn the jtag pins into swd pins.
2. The SWD protocol manual
here – http://www.arm.com/miscPDFs/15531.pdf
and here – http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0413c/Babbdfad.html
3. This guy added SWD to openocd for stm32 programming and included his .bin file of his implementation for everyone to pour over.
When I get a chance I may try and roll my own using an avr.
Thanks a lot!!!! I was just stuck trying to get Crossworks work with the Olimex dongle!