OpenOCD and Altera USB blaster.

[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:

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:

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:

	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]

eligs:
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…

eligs:
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?

[buriedcode]

The USB blaster has a fixed TCK of 6Mb/sec I believe (but many places quote 3…). Although, that doesn’t mean to say it will transfer data at that rate. Just when it does transfer bytes using its ‘byte shift’ mode, that’ll be the speed at which is does it. I’m not sure the FTDI ‘set_baud’ would do anything for the USB blaster, it only affects FT245/232 based dongles when they are configured in ‘bit bang’ mode. The blaster is FT245 based, but used in its stock FIFO parallel buffer config, with a CPLD controlling the RD and WR lines and doing the donkey work. I could of course be wrong

The other mode it operates in is ‘bit bang’ mode. In this mode, a byte sent from the host (along with a few other config bytes for the FT245 specifically) appears on the IO’s of the FT245 inside the blaster. The CPLD simply copies this to the output port. This allows direct changing of IO’s, but is slow for transfering bytes serially. (it would require 3 bytes per change in IO’s, two for TCK, one for data = 3 per bit = 24 per byte, so its actually around 30x slower). I have also done this just with an FT245 connected to a CPLD, and some host software, its about the same speed as a parallel dongle (and can be built for around $5).

I think your OpenOCD (perhaps everyones?) is just using ‘bitbang’ mode, and not very well at that. If your measurements are correct, and one TCK is 10ms, that would mean the host is changing that line (remember one byte - one change in IO state) twice every period, or every 5ms. It could well be that it sends a byte to the FT245 in the blaster, but then doesn’t send anything else… then times out, and sends the next. Meaning the driver times-out 2/3 times per BIT. Does anyone know the timeout on the blaster FTDI driver?

Again, I’m afraid I cannot confirm your findings, or making my own tests until I knock up a ‘prototype blaster’ (one with test pins, so I can poke around), and I can’t make that until I finish several other designs, as they are all going on the same PCB. Hopefully, this week though!

I’ll also dig out some code I wrote for VB2008, my first ‘PC software’, which used the blaster to configure CPLD’s using SVF’s, since I wasn’t happy with anything available It was stand alone, so perhaps not easily integrated into a test code, but it does at least show how to get the blaster going at high speeds, using byte-shift mode.

[eligs]

Ok, up to now I thought it to be like this:

The FT245 receives some data via USB and then presents it to the CPLD serially with the clock set by set_baudrate(). Even if the CPLD runs at a higher clock, it cannot present data on its output, which it didnt receive from the FT245. I seem to be wrong in this case…

How are CPLD and FT245 connected ? Parallel? Do you have a link to some schematics of the blaster? I found some CPLD code, but I’d like to have the wiring to get the whole picture. Then it would be easier to (re-)do a proper implementation of the driver.

jfyi:At the moment, the device is NOT used in bit bang mode. OK, we are bitbanging, but using the CPLD for that, the FT245 is NOT in bit bang mode.

But I started to figure out where the problem is. It seems to be because of writing single bytes to the FT245, this only happens every couple of ms (of course one needs 2 bytes to do a complete TCK cycle). If I start to write more bytes to the FT245 at once, they are clocked out at higher speed (supposedly 3 or 6 Mbit/s) … then there is a rather long period of silence (a couple of ms) before the next x byte arrive at the adapter.

[buriedcode]

I cannot claim to be an expert in this, but I’ll try to explain how I understand the baster operates.

The FT245 is just in stock parallel mode, with FIFO buffers for in and out transfers, not serial. This is not ‘bit bang mode’ as per the FT245 datasheet. In order to get a byte out of the 245 after the host has sent a packet, one must trigger the RD line. Writing is the same deal just different direction, in the ‘bit bang mode’ you are refering to, bytes are spat out of the FT245, in paralllel, at a rate determined by the ‘set baud rate’ - automatically, with no intervention from an external trigger. (I have read that FTDI added this mode purely for the purpose of USB pogramming adapters!)

The CPLD inside the blaster, although basic, is rather clever, as it monitors what these bytes are. It is a state machine which, gets a byte from the FT245 buffer (using the RD line) does what it wants with it, then reads another. Without the CPLD’s intervention, no bytes can come out of the FT245.

I ‘think’ the MSB of a byte determines what the CPLD does with it. Either, it simply copies the 6 LSB’s to its output port (changing the IO lines manually, for TCK, TMS etc…bit bang mode) or, if the MSB is set, it interprets this as an instruction with the 6/7 LSB’s representing the number of ‘data’ bytes that will follow. This way, the next X number of bytes, are loaded in, in parallel, and shot out the CPLD serially at full speed (byte shift mode). This means one byte into the CPLD = 8 bits out, with a clock. - Meant for long strings of data with no change on the TMS line. For any changes in the TMS line, one must use the previous mode of operation. As for ‘reading’ bits/bytes, its very similar, either it reads what the TDO line is, and sends that as a byte (one bit per byte), or, it reads in an entire byte serially, and sends that (8 bits per byte).

This page has some details:

http://ixo-jtag.sourceforge.net/archive … _jtag.html

Also, I think the source code for openOCD has notes from the same guy.

I believe a point of confusion (my fault for mixing up my terminology) is the phrase ‘bit bang mode’. The FT245 can run in this mode (as per the datasheet), but I was actually refering to the mode the USB blaster is in (as in the firmware CPLD, not the FT245). As described above, the blaster has two modes: Bit bang, and Byte shift. These are specific to the USB blaster, not the FT245. So, even though the FT245 can do ‘bit bang’ all by itself the blaster doesn’t use it in this mode, instead, it uses the CPLD to emulate this mode. I’m not sure whether the FT245 had this function when the blaster was originally designed, so they put a CPLD in there to do it. The added logic also allows a more efficient transfer of data if its just long serial strings of bits, making good use of the USB buses speed.

Long winded explaination I know, and you’re right, a picture is worth a thousand words (so is code!) so later on today, I’ll provide what I have

Blueteeth

[eligs]

I get it, the CPLD is the clock master. Until now I thought the FT245 would pass the data to the CPLD…

It seems that with the introduction of the Bit Bang mode in the FT245BM, the CPLD used in the USB Blaster becomes superfluous.

At the moment, the only possibility to reduce the clock would be to send the same data for several times (using the CPLD bitbang mode). I’ll give it a try and implement this tonight. Besides I will check how to get the bit bang stuff aggregated to speed things up.

[eigma]

buriedcode is exactly right. “Bit-bang mode” refers to the CPLD only. For protocol details see: http://sourceforge.net/apps/mediawiki/u … SB-Blaster

In February 2010, someone submitted a patch to the driver which implemented byte shift mode (thread starting with http://lists.berlios.de/pipermail/openo … 14794.html), but it didn’t work on my hardware and there was no other feedback on the list. That patch is probably a good starting point for anyone wishing to get byte shift mode into OpenOCD.