SparkFun Forums

[buriedcode]

Hi,

Does anyone know if the Amtera USB blaster is supported by openOCD? It is mentioned (along with the config commands) on this page:

http://openocd.berlios.de/doc/html/Inte ... ation.html

Such as:

— Interface Driver: usb_blaster

USB JTAG/USB-Blaster compatibles over one of the userspace libraries for FTDI chips. These interfaces have several commands, used to configure the driver before initializing the JTAG scan chain:
— Config Command: usb_blaster_device_desc description

Provides the USB device description (the iProduct string) of the FTDI FT245 device. If not specified, the FTDI default value is used. This setting is only valid if compiled with FTD2XX support.

— Config Command: usb_blaster_vid_pid vid pid

The vendor ID and product ID of the FTDI FT245 device. If not specified, default values are used. Currently, only one vid, pid pair may be given, e.g. for Altera USB-Blaster (default):

ft2232_vid_pid 0x09FB 0x6001

The following VID/PID is for Kolja Waschk's USB JTAG:

ft2232_vid_pid 0x16C0 0x06AD

I have tried the bove commands but it is not recognised as an interface.

Tried with two versions. 0.3.1, and 2007re141. I have only ever successfully used the latter version, it is the same one used in Jim Lynch's wonderful tutorial.

I realise there is a patch for a 'USB blaster clone' on this page:
http://www.ixo.de/info/usb_jtag/

But I do'nt know how to use it with either version of OpenOCD. I would love to get this working, as I'm still having 'issues' with my FT2232 programer (JTAGkey based clone) - which could be hardware, or software,I don't know.

Hope someone can shed some light on this,

Blueteeth

[eigma]

USB Blaster should be supported starting with OpenOCD v0.4.0 (released 22 February 2010).

The command examples given in the documentation contain a typo.. instead of "ft2232_vid_pid", they should read "usb_blaster_vid_pid", as given in the command heading. I'll be submitting a patch for this shortly (thanks for the bug report ).

However, if you are using a genuine Altera USB Blaster or a clone, you shouldn't need to change the default VID/PID values. If you have a custom openocd.cfg file, use "interface usb_blaster", otherwise you can start openocd with the example cfg file in tcl/interface/altera-usb-blaster.cfg.

[buriedcode]

OK, thanks for the info!

Apologies for the late reply,I haven't done much work with ARM or CPLD's until a few days ago, when this saga started again

Before I made the first post in this topic I had managed to successfully use openocd 0.3.1, with a jtagkey-like interface to debug my At91SAM7256 board from omilex. Turns out I had issues with drivers (namely open source libftdi vs. ftd2xx) and a small hardware mistake on my part. I ended up using the libftdi drivers.

I had also used the above setup to configure one XC95144XL CPLD using an svf file - altohugh this took several attempts. I ran a couple of xilinx generated SVF files I created for a XC9536 crashed openOCD when they were run. I recieved an error the 'unexpected TDO' followed by 'cannot write MPSSE commands'. It did this at the same point on the SVF file in question so it wasn't random noise on the lines,or a hardware issue. The same SVF file worked fine using Xilinx IMPACT with a parallel cable. I am not sure if this is a problem with openOCD reading certain SVF files/lines... OR if it is a problem with the way it communicates with the drivers. As this was a prebuilt openocd, I could not use ftd2xx drivers, only libftdi. - ergo - OpenOCD 0.3.1 was useless to me for CPLD work.

Coming back to it, I decided to install the latest openOCD 0.4.0. I originally used a windows installer from freddie chopins page:
http://www.freddiechopin.info/index.php ... /4-openocd

However, it seems he didn't enable the USB-blaster in any build (not complaining, just an obseravtion) so I had to build it myself on windows XP using cygwin - this took 6 hours lol. I used this wonderful tutorial to help me understand how to do it, and whats going on:
http://www.openpilot.org/OpenOCD_Compile_on_x86

It refused to build using the libftdi drivers, OR the latest ftd2xx ones, until I eventually cleaned my system of ALL usb drivers, plugged in my ft2232 board, and installed the latest ft2dxx drivers for it. The SAME drivers I was using to build openOCD, only then did it actually create the makefile, and I was able to build.

So, at that point, I had openocd 0.3.1, built for libftdi drivers, which crashed on running xilinx svf files,and could not communicate with my ft2232 board (as my 0.3.1 was libftdi only, and my ft2232 board was installed with ftd2xx drivers).

So, having got 0.4.0 built, and enabled both the FT2232 AND the USB-blaster with ftd2xx drivers, I thought I would test the guts out of it. Running my SVF file on this new build, it once again failed at the SAME point in the SVF file using my FT2232 board with the 'unexpected TDO' error. However, this time it didnt' crash, but merely quit openOCD, leaving me at the prompt. So, it seems libftdi will crash the window when it can no longer send MPSSE commands (I suspect its buffer overflowed). But the official ftd2xx drivers, handle this error, and just quit out of openocd.

Last attempt: the USB blaster. This was a clone built by me, and extensively tested using the Quartus II 9.0 programmer software from Altera. Before using openOCD, I used Quartus to read the IDcode's of several xilinx CPLD's, as well as configure an EPM7064S altera CPLD. No errors, no problems, although Quartus refuses to configure any non-Altera device, by ANY means - I have had this confirm by Altera, it purposefully will only configure Altera deivces IDcodes

So, my Altera blaster is installed, and working, with ftd2xx drivers. However, using openocd 0.4.0, it doesn't work. It DOES recognise it, but claims it can't read the TAP, indicating it finds all 0's. It does this regardless of what I have connected, or what commands I give. So, considering my test with Quartus, I'm guessing the altera USB blaster isn't fully working with openOCD 0.4.0. I can provide logs if someone would like them (this post is too big already).

After spending a total of 15 hours on this (and endless cups of coffee later) a last ditch attempt was to use an old version of 'UrJtag', I installed a couple of years ago with the intention to use it as a generic SVF programmer. My USB blaster didn't work with this either! So perhaps, it is the drivers for the USB blaster not being access correctly by openOCD, OR UrJtag, only by Quartus. However, as a nice happy ending to this story, using my FT2232 board, UrJtag very happily ran my svf without any errors (I made sure it stopped on the first one), and I now have a well tested CPLD sitting on my desk running the design.

Apologies for a long post here, but as you can see, there are several versions/flavours of OpenOCD builds used, two types of hardware interface, several devices, and quit a number of different drivers used...the combination is soul destroying...

Has anyone successfully configured Xilinx devices using SVF files? Also, has anyone managed to get their USB blaster working with 0.4.0 ? if so, I would love to hear how it was done.

Scott.

[eigma]

Hi Scott,

Thanks for the long post actually I can't speak for the ft2232 issues you've been having but I'm very interested in the USB Blaster issues.

The only hardware I have for testing the OpenOCD USB Blaster driver is a USB Blaster clone (just to confirm, it works fine with Quartus Programmer). I'm interested in getting OpenOCD working with your blaster clone and, down the line, rewriting the driver to use byte-mode (currently it bitbangs).

Is there somewhere you can post the logs for OpenOCD 0.4.0 with your blaster clone?

[buriedcode]

Hi eigma,

I believe I can upload attachments in this thread, all info will be in txt/log files, so they aren't going to be huge and take up valuable board resources. Hopefully, either tonight or tomorrow, I shall run it again, providing as much info as I can. That is the following:

-My current OS.
-Altera USB driver version (as provided by Altera)
-OpenOCD version, with the build options I used (my './configure' command line).
-The configuration file used with OpenOCD.
-The log of OpenOCD.

As I said in my previous post, even though I'm not a programmer (just a hardware guy who doesn't give up) it seems to me almost all the problems one encounters are down to the drivers used, as well as how openOCD communicates with them. Even though the USB blaster's drivers are essentially 'ftd2xx', because of the unique VID/PID, one cannot use stock drivers from FTDI, which leads me to believe openOCD is having issues talking to it. That or I've missed something obvious, which happens a lot

Steeeep learning curve right here, never used cygwin before... or config scripts...

Ps. A year ago, after playing about with VB.NET (first time coding for a PC..) I managed to write a small app which used the USB blaster to scan JTAG chains, read IDcodes, erase and verify certain CPLD's. It was pretty basic, but I had no problems whatsoever communicating with the FTDI chip inside the blaster...altohugh I only ever sent a few commands at a time.

[AMONTEC]

I sure it is not related to specific VID PID of Altera USB Blaster nor kernel driver.

The Amontec JTAGkey dongle use a specific VID / PID too and it works great with openocd.
You could note that all Amontec JTAGkey dongles (JTAGkey / JTAGkey Tiny / JTAGkey-2 / JTAGkey-2P ) use the same VID / PID as there are all compatibles but come with different formats and different buffers ?

see http://www.amontec.com

So if Altera USB Blaster is not working with OpenOCD for you, it is not coming from the USB kernel driver (libusb libftdi or d2xx driver) but coming from the USB Blaster driver api in openocd/jtag/driver , learn OpenOCD, get the debug -d3 output file, correct the driver and give a patch to OpenOCD project.

Also, you could compare openocd -d3 debug output using a JTAGkey and using an Blaster ...

Laurent

[shahul]

Hi egma,
I am currently designing USB blaster cable. can i get the cpld code of the cable you said?
It will be the great help for me. thanx in advance.

Regards,
shahul

[eigma]

shahul, I do not have the CPLD code for my USB Blaster clone. It's a noname from eBay.

[majolsurf]

Hi everyone...

I built a USB-Blaster clone and would be interested in helping you guys make it OpenOCD compatible. I originally used Kawk's JTAG VHDL and modified it. I prefer to work with Verilog.

I call it USBoomer, details:

Design Files: http://majolsurf.net/wordpress/?page_id=667
USBoomer design and test progression: http://majolsurf.net/wordpress/?tag=usboomer
You can find a block diagram of the JTAG state-machine here: http://majolsurf.net/wordpress/?p=69

Hope I can be of some help!

Thanks,

Eric

Amani64: Arduino Compatible CPLD Shield
http://majolsurf.net/wordpress

[eligs]

Hi...

Also, has anyone managed to get their USB blaster working with 0.4.0 ? if so, I would love to hear how it was done.

I think I just got it to work with an original Altera USB-Blaster. At least my LPC1758 is found in the chain:

Code: Select all

Licensed under GNU GPL v2
For bug reports, read
	http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'usb_blaster' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
300 kHz
jtag_ntrst_delay: 200
none srst_pulls_trst
10 kHz
Error: Translation from khz to jtag_speed not implemented
Error: Translation from khz to jtag_speed not implemented
Error: Translation from jtag_speed to khz not implemented
Error: Translation from khz to jtag_speed not implemented
Info : adapter-specific clock speed value 0
Info : JTAG tap: lpc1758.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

I compared the code to the one from "urjtag" and it seems, that "usb_blaster_write()" does not enable the output of the USB Blaster (since OE is also connected to the LED, it doesnt light up either).
After including the output enable bit to the usb_blaster_write() function, it works:

Code: Select all

static void usb_blaster_write(int tck, int tms, int tdi)
{
#ifdef _DEBUG_JTAG_IO_
	LOG_DEBUG("---- usb_blaster_write(%d,%d,%d)\n", tck, tms, tdi);
#endif
	out_value &= ~(TCK | TMS | TDI);
	if (tck)
		out_value |= TCK;
	if (tms)
		out_value |= TMS;
	if (tdi)
		out_value |= TDI;

	// Output Enable / LED has to be set, otherwise writing is useless
	out_value |= LED;

	usb_blaster_write_data();
}

I have to admit I'm not so much a software guy (it took me 3 days to get everything compiled on OS-X and to figure out that it wasn't a problem with the USB stuff but rather with OpenOCD) , so I don't have a clue how to build a patch and include it to the repository. Maybe someone else could provide a little help?

btw: While messing around with the code I also included a USB Blaster buffer flush in the usb_blaster_init(). I don't know if this is really necessary, but here it is:

Code: Select all

	bitbang_interface = &usb_blaster_bitbang;

	usb_blaster_speed(jtag_get_speed());

	// flush buffer of USB Blaster (just like urjtag does)
	uint8_t dat[64];
	uint32_t i;
	memset(dat,0,64);
	usb_blaster_buf_write(dat, 64,&i);

I hope this was helpful.

[buriedcode]

Nice! you beat me to it

My USB blaster 'clone', also has a buffer (inside the CPLD and an external level driver), which has its output enable tied to the CPLD. I couldn't measure any output drive on the signals (also suspecting that the Openocd code wasn't using this line). So, next week I was about to prototype it again, just with the 'enable' line permanently active (I can't find my original CPLD image file, so I couldn't modify that). But I'm sure you've hit the nail on the head here.

Seems my other problem involving using OpenOCD with an FT2232 programmer was down to one SVF file generated from xilinx. It works beautifully for many other SVF's. But thats for another topic (lattice, altera, and xilinx SVF's are all different and have different options for formats, only some work with openocd). I believe you've touched on this too, as it's definately a buffer issue. Some SVF's with long strings cause a buffer overflow, and it craps all over my desktop.

Hopefully I'll be able to confirm your theory, compiling it with code modifications (or just changing my hardware), and then reply. Good man!


Buriedcode

[eligs]

Well, the learning curve seems to be rather steep when it comes to OpenOCD + USB Blaster (+Eclipse&GDB +Cortex-M3).
Now my CPU is recognized, but there are some issues concerning JTAG speed (it's soooo slow at the moment) and also reset.
I just implemented a crude speed setting, but I did not yet verify the actual speed with my scope. First I have to track down a reset issue (hey, good time to implement usb_blaster_reset - isnt it? )

[buriedcode]

Well, the learning curve seems to be rather steep when it comes to OpenOCD + USB Blaster (+Eclipse&GDB +Cortex-M3).

You're not wrong

I'm a hardware guy, very rarely doing any PC programming, mainly just microcontrollers and FPGA's. If it hadnt' been for several tutorials giving step by step instructions for installing eclipse+GDB as well as building openOCD on windows, I would have been completely lost. I have been spoiled by nice GUI's that do everything for you, so working in command lines and linker files got a bit hairy, but its a great learning experience. Just by doing the above I've already started writing my own scripts for things.

I am unsure why your USB blaster + openOCD is running slow. The original USB blaster's TCK runs at a fixed clock of 6MHz, which is the upper limit of an FT2232 dongle. Although they are quite different in how they use USB packets to control lnes (ft2232 is much more efficient) I don't see how it can make a huge impact on speed. - says the guy who hasn't even got his working yet...

First I have to track down a reset issue (hey, good time to implement usb_blaster_reset - isnt it? )

The original USB blaster has a couple of other lines, not used for JTAG but for serial interfaces that Altera chips use, active serial, and passive serial. The unused GPIO pins can be controlled by OpenOCD, but I don't know if they are fully implemented as reset lines.

Page 43 of the online documentation sheds some light on this:
http://openocd.berlios.de/doc/pdf/openocd.pdf

usb_blaster (‘pin6’|‘pin8’) (‘0’|‘1’) [Command] Sets the state of the unused GPIO pins on USB-Blasters (pins 6 and 8 on the female JTAG header). These pins can be used as SRST and/or TRST provided the appropriate connections are made on the target board.
For example, to use pin 6 as SRST (as with an AVR board):
$_TARGETNAME configure -event reset-assert \
"usb_blaster pin6 1; wait 1; usb_blaster pin6 0"

I'll have to try with with my SAM7 board.

[eligs]

I'm a hardware guy, very rarely doing any PC programming, mainly just microcontrollers and FPGA's. If it hadnt' been for several tutorials giving step by step instructions for installing eclipse+GDB as well as building openOCD on windows, I would have been completely lost.

I'd say that applies to me too. Fortunatly I have two systems around, Windows XP (I also managed to compiled OpenOCD there - thanks to a superb tutorial describing how to set up Cygwin properly AND mention how to build the application in a way to run without cygwin libraries) and OS-X 10.6 . But since there are usually more problems around when it comes to *nix software on Windows, I decided to use my Mac this time. There is one more advantage - since the original Altera USB Blaster drivers are not installed on my Mac, there is nothing to possibly interfere when it comes to USB communication.
The next thing that I really appreciate is the ability of the new Eclipse Helios to easily import Makefile projects.
At the moment I'm about to finish the work on the USB Blaster driver, I included new code to assign (n)TRST and/or (n)SRST to the GPIOs. Also improved the speed setting and converting stuff.
I think the next thing would be to figure out how to provide a patch to include this to the current development version of OpenOCD.
And then...maybe...at some distant point in the future I would be able to finally debug my little LPC1758...

cu

[eligs]

Ok, something is really messed up. I just checked the effective clockrate with a scope, and currently I'm somewhere around 100 Bit (!!) per second (one TCK period is about 10ms) ...that really explains the timeouts.
Unfortunatly a call to ftdi_set_baudrate() with a decent speed of 100k - 3M doesnt help here, it stays slow.
I checked against URJTAG and there I have some orders of magnitude more speed. I didnt measure it exactly, but it seems to be 3 Mbit/s.

What's wrong here? Libftdi problem or OpenOCD problem?