Dangerous Prototypes

I just got rid of the school project of mine and have some spare time to look at urJtag. Hopefully I will come up with a solution for BBv2 :-)

That would be fantastic, thank you. I'm planning to order an initial batch of v2 on Monday. The BBv1 should be on sale this week, and I think it will probably be limited to the initial batch, sold at cost, because I would prefer to support the v2 in the long run.

I'm willing to sell v2 as is, and hope the internal connection can be used later. It's not ideal, but if we wait for me to add every feature before a launch then there would never be any new projects ;) At least it can be in the hands of skilled programmers who might be interested in getting it going.

If you find that you have time to work on this, I'll solder up another BBv2 (got some extra FT2232H last week) and send it to you. I have 32 and 64 macrocell CPLDs at your earlier request :)

Otherwise, anyone who comes across this post can consider this a bounty - I'll send a BBv2 prototype (assembled) to anyone who contributes a way to program the CPLD with interface B. urJTAG would be handy, but anything open source and distributable is fine.

Here it is - attached. It applies against latest UrJtag git.

Git repo:
git clone git://urjtag.git.sourceforge.net/gitroot/urjtag/urjtag (http://git://urjtag.git.sourceforge.net/gitroot/urjtag/urjtag)

What it does, it adds parameter "interface". So far there is no explicit BBv2 support added, Just choose something very similar :-).
When initializing cable you can add parameter "interface=X" and it will set the FTDI interface. (0,1=A, 2=B, 3=C, 4=D)

eg:
cable ARM-USB-OCD interface=2
(It does change the behaviour of the led, so i guess it does work).

If this gets the BBv2 working, I will add it's own configuration - most of the adapters use other pins for leds and buffers, it could interfere with CPLD pin configuration, burn something, etc... If you decide to send me one, i would probably want the 64macrocell one :-)

Thank you so much! I sent this on to the urJTAG development list, hoping for a reply. I'm going to solder you a BBv2 today, and then we'll try to get it compiling for some immediate feedback and gratification.

I just had to try it :)

I'm following these instructions:
http://urjtag.sourceforge.net/book/_com ... ation.html (http://urjtag.sourceforge.net/book/_compilation_and_installation.html)

I already use mingw for simple stuff, but I'm really inexperienced with dependencies and build tools on the desktop. So I downloaded and installed the needed stuff:

To run autogen.sh, you need autoconf and automake, bison, and a recent flex.

http://gnuwin32.sourceforge.net/packages/autoconf.htm (http://gnuwin32.sourceforge.net/packages/autoconf.htm)
http://gnuwin32.sourceforge.net/packages/automake.htm (http://gnuwin32.sourceforge.net/packages/automake.htm)
http://gnuwin32.sourceforge.net/packages/bison.htm (http://gnuwin32.sourceforge.net/packages/bison.htm)

The distributed source tarball contains source pregenerated with a current flex version; flex therefore is only needed if you want to compile code checked out from our Subversion repository. Flex 2.5.4a as it comes with most but the very latest Cygwin release cannot build the scanners for BSDL and SVF. Building these files requires Flex 2.5.33 or newer. The configure script will compare the available Flex version against these preconditions and enables or disables the related features.

http://gnuwin32.sourceforge.net/packages/flex.htm (http://gnuwin32.sourceforge.net/packages/flex.htm)

I could only find the 2.5.4a flex compiled for windows. We're just desperate for a chain test now, so I guess disabling these features is ok.

libtool should be available

http://gnuwin32.sourceforge.net/packages/libtool.htm (http://gnuwin32.sourceforge.net/packages/libtool.htm)

and "devel" versions of the following packages: gettext, readline (not needed, but really eases interactive use), ioperm (needed only for Cygwin)

http://gnuwin32.sourceforge.net/packages/gettext.htm (http://gnuwin32.sourceforge.net/packages/gettext.htm)
http://gnuwin32.sourceforge.net/packages/readline.htm (http://gnuwin32.sourceforge.net/packages/readline.htm)

[quote author="ian"]
Thank you so much! I sent this on to the urJTAG development list, hoping for a reply. I'm going to solder you a BBv2 today, and then we'll try to get it compiling for some immediate feedback and gratification.
[/quote]

Wasn't really supposed to go to main repository :-). I think urJtag needs some changes to the driver handling to better support this.

I just wondered if there was anyone on the list interested in working with us. It doesn't seem like it's too active, the list is l ow traffic, last release over a year ago. Kinda surprising, I see it as the most popular app for CPLD and fpga out there. Just about everyone uses it.

Hello all,

Just joined the list, I like what your doing here and am interested in helping/testing.
I'm pretty familiar with urjtag/openocd, etc... I program mostly on the linux side, but have been known to produce a few, win32/win 7 x64 apps.
Let me know if I can help...

I will try to find a link now to get your board.

P.S. Could not find a way to get this board online, could you please contact me via e-mail, or your chioce on how I might get my hands on one of these ?

Regards,

Tornado

[quote author="ian"]
I just wondered if there was anyone on the list interested in working with us. It doesn't seem like it's too active, the list is l ow traffic, last release over a year ago. Kinda surprising, I see it as the most popular app for CPLD and fpga out there. Just about everyone uses it.
[/quote]

I guess many use build-in tools in the FPGA devel kit like Impact. Anyways there is some development going on in the repository. The 0.10 vs HEAD has some changed in the drivers that I noticed.

[quote author="tjtag"]
Just joined the list, I like what your doing here and am interested in helping/testing.
I'm pretty familiar with urjtag/openocd, etc... I program mostly on the linux side, but have been known to produce a few, win32/win 7 x64 apps.
Let me know if I can help...

I will try to find a link now to get your board.

P.S. Could not find a way to get this board online, could you please contact me via e-mail, or your choice on how I might get my hands on one of these ?
[/quote]

You cannot get them on-line. It all depends on Ian's good will :-) And you should probably be familiar with internal structure of those programs.

robots,

Thanks for the reply,

Actually I write my own software, but it's mostly mips/and atheros based. I use urjtag and openocd for arm targets mostly. I'm adding ft2232h to my software, and looks like this board would do the job.

Regards,

Tornado

I always check people's custom email URLs, and I think tjtag is a master wrt hacker:
http://www.tiaowiki.com/w/TJTAG (http://www.tiaowiki.com/w/TJTAG)

I also sent an email:
What robots said - BBv1 will be on the shelves in a moment. I like BBv2 so much more that I've already requested the production prototype be built.
I can send a PCB and some of the parts, but I only had one extra FT2232H and it will go in robots PCB. I can probably get some more if you're really eager to work on it ;)

In terms of what still needs to be done:
1. Make it self-programmable by enabling the JTAG_B interface of urJTAG, we'll need our own custom compiles while we wait for urJTAG to catch up. I work in embedded stuff without much desktop programming experience, so compile environment setup is always a weak point for me.

2. Add a Bus Blaster v2 cable type that ensures all pins are happy (as noted by robots above)

3. A self-test app that twiddles the pins for manufacturing verification.

Any help at all is always appreciated.

Back to topic :-)

I just received mail - BBv2 (with a ugly little cable, that is going to be replaced with something better looking) I couldn't wait to try it.

robot@robot ~/urjtag/bin $ ./jtag 

UrJTAG 0.10 #
Copyright (C) 2002, 2003 ETC s.r.o.
Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authors

UrJTAG is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
There is absolutely no warranty for UrJTAG.

jtag.c:518 main() Warning: UrJTAG may damage your hardware!
Type "quit" to exit, "help" for help.

Couldn't connect to suitable USB device.
jtag> cable  ARM-USB-OCD interface=2 vid=0x0403 pid=0x6010
Connected to libftdi driver.
jtag> bsdl path /opt/Xilinx/12.3/ISE_DS/ISE/xbr/data
jtag> detect
IR length: 8
Chain length: 1
Device Id: 00000110111000011100000010010011 (0x06E1C093)
  Filename:     /opt/Xilinx/12.3/ISE_DS/ISE/xbr/data/xc2c32_1532.bsd
jtag>

As you can see it works :-)

ARM-USB-OCD is _NOT_ the best choice. I have to look for a safer option.

While I was posting :)

tjtag compiled urJTAG with the patch on windows and I tested it with the BBv2. The interface used doesn't seem to switch. I connected a CPLD DEV board with two devices to the A interface, and they are detected with all interface= settings.  Screen shot of the test attached. I used the jtagkey device type because the ft2232 just shows an error (because it is stuck on the A interface with jtagkey buffer).

Does it need to be ARM-USB-OCD specifically? I think Ft2232 is the best for B, and the A is a clone of jtagkey with the bitstream installed.

---

Fantastic, congratulations!  I'm glad the hardware is working :)

We compiled against the current trunk, was the patch against the .10 version instead?

I'll post a copy of the svf so you don't ahve to dig in SVN for it.

The problem i see is that my patch is only for libftdi, not the libfd2xx :-) (experimental patch was that, I can make some for the ftd2xx it it helps)

I guess that the TGT led is useless , It seems the CPLD is leaking 0.5 volts, and that makes it glow. Maybe Have the led connected to the spare FT2232 GPIOs ?

The ARM-USB-OCD was used because it was in the urjtag history, and I didn't remember any other name.

Here's the jtagkey implementation.

RE the TGT LED: Yup, I'm going to eliminate it from the first batch of boards, we can decide what to do in the next revision. Basically, if the CPLD is leaking like that from an input when not powered, then I don't see how it should every be connected without a target making the LED useless. The TI design had a different LED based on target ground, but that requires all the JTAG pins be connected and I usually just use a couple jumpers.

That would be very helpful, the compile for Win-32 only included support for the FTDI drivers.

I have not found the same functionality in the ftd2xx driver. I think i might have overlooked something.

I still think we should stick with libftdi as it is open-source :) Can we have the urjtag for win32 compiled with libftdi support ?

I agree. I switched my hardware over to the libusb driver, but got an error message when i tried:

jtag> cable jtagkey interface=2 driver=ftdi-mpsse
Couldn't connect to suitable USB device.
Error: parse.c:208 urj_parse_file() no error: Cannot open file 'C:Documents and
 Settingsian/.jtag/rc' to parse
jtag> cable jtagkey interface=2 driver=ftd2xx-mpsse
Connected to libftd2xx driver.

Tornado thought his compile included the FTd2xx drivers only, he'd need to elaborate on the driver situation.

Does urJTAG just use the bitbang mode of the FT2232H? I assumed it used the jtag features, but I don;t know if the FTJTAG driver is required or included with the FTD2xx package. It has this in the datasheet for the FTCJTAG.dll:

The FT2232H MPSSE controller is available through channels A and B of the FT2232H device; both channels A and B can be used for JTAG communication

http://www.ftdichip.com/Support/Documen ... AG_DLL.pdf (http://www.ftdichip.com/Support/Documents/AppNotes/AN_110_Programmers_Guide_for_High_Speed_FTCJTAG_DLL.pdf)

I'm reading the datasheets now, but it's not clear to me how the interface number is set.

From what I understand, libftdi drivers are supported by compiling under cybwin, but not mingw... however, a ftd2xx patch or change should be pretty simple, at least to test with for Ian... I will take a look, and see if I can come up with something for him, in my code, it looks something like this:

           if(devInfo.ID == USBID && strstr(devInfo.Description," A")>0)

               {

                  ftStatus = _FT_Open(0, &ftHandle);

                  ii=0;

                  break;

               }            

only needs to be:

           if(devInfo.ID == USBID && strstr(devInfo.Description," B")>0)

               {

                  ftStatus = _FT_Open(1, &ftHandle);

                  ii=0;

                  break;

               }            


but this is my src code, I will look at urjtag's

Ian, just found this in urjtag's src

#endif

    /* try various methods to open a FTDI device */
    if (p->serial)
    {
        /* serial number/description is specified */

        /* first try to match against the serial string */
        status = FT_OpenEx (p->serial, FT_OPEN_BY_SERIAL_NUMBER, &p->fc);

        if (status != FT_OK)
            /* then try to match against the description string */
            status = FT_OpenEx (p->serial, FT_OPEN_BY_DESCRIPTION, &p->fc);
    }
    else
        /* give it a plain try */
        status = FT_Open (0, &p->fc);


Changed   status = FT_Open (0, &p->fc); to  status = FT_Open (1, &p->fc);


sending via e-mail now

Regards

I have patched the "usb-driver" - alt. Xilinx impact driver, to include support for the interface 2. I can now see the cpld from Xilinx Impact. :-) yay!

http://rmdir.de/~michael/xilinx/ (http://rmdir.de/~michael/xilinx/)


Edit: of course ... attach :) (email has been sent to the maintainer)

Very cool robots !!!!

Nice! I added a section of the wiki with links to the patches so far:
http://dangerousprototypes.com/docs/Cla ... e_the_CPLD (http://dangerousprototypes.com/docs/Claire:_Bus_Blaster_v2#Patch_apps_to_see_the_CPLD)

Attached patch should (SHOULD (-: ) work for the ftd2xxx library. I don't have that library, and have not tried to compile the source. But it looks clean enough :-), most of it is copy/paste from old patch.

We just did a test that forced it to the B interface and it works. Will work on this now, thank you.

We got this going, but there are a few issues.

interface seems to be reserved, so we changed it to iface.

the parameter passing isn't working correctly. It always goes to interface 0 unless we force it to p->iface=1 in the source.

This compile (attached) forces to iface one and does a detect ok, but it has file loading issues so it doesn't program.

Funny that is is reserved ... It compiles fine here. Attached are minor changes to get it working(small corrections like include), and to be compatible with libftdi numbering.

The parameter passing works OK here. I wonder where the problem is :-/

You said you want a production test. I was thinking about using the led as indicator and have some large AND inside the cpld to light it up one the test passed. But then i noticed the led is on input pin:-/

There is another way to have the board checked. The CPLD has border scan. I have never used it, (except few minutes ago) and it is a brilliant way to test board:-). I mean the jtag interface is already on-board and has to be tested anyways. You just use the jtag and execute small script in the urjtag that fiddles with the pins and checks result.

The file (/opt/Xilinx/12.3/ISE_DS/ISE/xbr/data/xc2c32_1532.bsd) is what you want to check out. It contains name for instructions (INTEST, and EXTEST are interesting) one for reading pin state (INTEST) and one for setting (EXTEST).
If you want to execute them use the following:

jtag> instruction INTEST
jtag> shift ir

This shifts in the INTEST instruction, and now to obtain data:

jtag> shift dr
jtag> dr
1101101101101001001101101001001001001001001001001001001111001001001000001111111111001001111001001 (0x000000009249279241FF93C9)
jtag> get signal IN_16

dr will just print the whole data register, get signal will get the specific pin state. The pin names are in the bsdl file.
To toggle the pin use EXTEST instruction and "set signal xxx"

Be sure to have the "target" voltage present for the cpld :-)

That's a good idea, and urjtag can be called from other apps too.

My idea was a small app for the FT2232 that alternated the pins (aa/55). Using a pass-through CPLD implementation would allow testing of the JTAG header. Nut the JTAG scan seems a lot easier.

Is it possible to get a full path/diff of your working source? It looks like you're working from the last release (.10 #), we've been compiling from a development branch.

I sent the patches to Tornado. I am working with the git repository. Last commit from Dec 19th. It is definitely not .10 version

The problem is probably that all patches are incremental. You have to apply them in order I posted them. Which is much easier once they are in one place, and with correct numbering :)

UrJTAG 0.10 #

I saw this in your output and thought it was the release version, sorry about that.

robots,

svn co http://urjtag.svn.sourceforge.net/svnroot/urjtag/trunk (http://urjtag.svn.sourceforge.net/svnroot/urjtag/trunk) urjtag-current

gives us svn verison 1869, I think

I have the same thing, but from git repository. git makes it easier to create patches

How are you guys doing with the urjtag ?

I have just tested the OpenOCD and the JTAGkey "emulation" and works successfully with stm32 chip. (Up to 15mhz was tested)
I am going to create patch for the Interface B, so we can play the svf file also in OpenOCD.

Doesn't FTDI have some similar program as microchip  with (usb) PID "lending" ?.

Jamz just got the SVN version to compile and is applying patches now. We'll see if he has the same issues with 'interface' as Tornado.

There are currently two outstanding issues:
1. The parameters don't seem to pick up 0/1/2 on the Windows version. If we set it in code it works, otherwise it always goes to interface A.
2. All the tests have been cross-compiled on Linux, and the search paths are using Linux paths so manufacturer/bsdl/svf search is always unknown paths.

Jamz and I will keep hacking at it. The BBv2 manufacturing prototype was verified today and we ordered the initial production. The testers at Seeed would really appreciate a self-program utility so they don't have to do an extra connect step to program the CPLD in 500 of them :)

PS: The CPLD replacing the buffer made it $5 cheaper at the 100 quantity! Killer!

ad1.

It seems like he applied only the last patch, the last patch did not include the interface parameter parsing.

ad2.
on linux I had to "make install" for the urjtag to see the manuf... file. Also,I did provide BSDL files from Xilinx ISE, I didn't think that urjtag does have the bsdl files. I am sure you can download them from xilinx. (just the bsdl)


Less is better :) The cpld even adds coolness, and usefulnes :)

We tested earlier with the parser patch (Tornado caught the missing int i). It just never picked up the parameter. If at the end we did p->interface=1; then it would correctly go to one.

+    /* parse params */
+    if (params != NULL)
+        /* parse arguments beyond the cable name */
+        for (i = 0; params[i] != NULL; i++)
+        {
+            if (params[i]->key == URJ_CABLE_PARAM_KEY_INTERFACE)
+            {
+                if (params[i]->value.lu == 0) {
+                    p->interface = 0;
+                } else {
+                    p->interface = params[i]->value.lu - 1;
+                }
+            }
+        }
p->interface=1;

I wondered if it could be a ASCII->integer issue in param handling?

I'm running the updates from my windows URJTAG install, so the MANUFACTURERS file is located where it should be (relative to the windows executable). The error looks like this:

jtag> cable ft2232
Connected to libftd2xx driver.
jtag> detect
IR length: 8
Chain length: 1
Device Id: 00000110111000011100000010010011 (0x06E1C093)
Unable to open file '/usr/local/share/urjtag/MANUFACTURERS'
  Unknown manufacturer! (00001001001) (/usr/local/share/urjtag/MANUFACTURERS)
jtag> bsdl path c:bsdl
jtag> detect
IR length: 8
Chain length: 1
Device Id: 00000110111000011100000010010011 (0x06E1C093)
Unable to open file '/usr/local/share/urjtag/MANUFACTURERS'
  Unknown manufacturer! (00001001001) (/usr/local/share/urjtag/MANUFACTURERS)
jtag> svf c:svfbbv2.svf
Error: cmd_svf.c:89 cmd_svf_run() System error: No such file or directory svf: cannot open file 'c:svfbbv2.svf'
jtag>

I can't specify a BSDL search path at all because it throws an error when it can't grab the manufacturers file from the expected directory during detect. It also mangles the DOS format file name and path during the svf command.

interestingly, if I swap the / I get this:

jtag> svf c:/svf/bbv2.svf
Error: svf.c:1206 urj_svf_run() not found: svf: could not establish SIR instruct
ion
jtag>

so that is part of the issue, but then I still need to figure out this:

Unable to open file '/usr/local/share/urjtag/MANUFACTURERS'

The actual location on the windows install is data, or C:Program FilesUrJTAGdata exactly.

Try this

jag> svf c:\svf\bbv2.svf

 is special in C programs :)

Oh ...and ... when you run configure you need to specify prefix

./configure --prefix=/home/robot/urjtag

This is what I use so I dont have to install into global direcotry. It just stays in my home. I suppose having it changed to

./configure --prefix=C:\urjtag\

would lead to correct directory :)
Probably using the other slashes

./configure --prefix=C:/urjtag

I am not sure how this is handled in mingw/win32 environment

Here's a copy of the 'combined' batch.

jtag> bsdl path c:\bsdl
jtag> detect
IR length: 8
Chain length: 1
Device Id: 00000110111000011100000010010011 (0x06E1C093)
Unable to open file '/usr/local/share/urjtag/MANUFACTURERS'
  Unknown manufacturer! (00001001001) (/usr/local/share/urjtag/MANUFACTURERS)
jtag> svf c:\svf\bbv2.svf
Error: svf.c:1206 urj_svf_run() not found: svf: could not establish SIR instruct
ion
jtag>

I tried your suggestion, it find the file but cannot continue (because detect was not completed successfully?).

Success with issue 1. This patched file, with

p->interface

changed to

p->interfaceb

Compiles and works for Windows. The interface= parameter is accepted.

I still don't get it :) how can that be a problem..... must be something with mingw or what. 

there is a file called urjtag.nsi in the urjag directory that said

;Run makensis.exe in the root of an UrJTAG source directory
; extracted from a distributed archive of UrJTAG (make dist)
; after configuring and compiling. Usually you want to compile
; with --with-ftd2xx, --with-inpout32, --enable-relocatable and
; the CFLAGS=-mno-cygwin setting. To make UrJTAG search for
; its data files and BSDL declarations in the correct path,
; add JTAG_BIN_DIR and JTAG_DATA_DIR as follows to the CFLAGS
; on the same line together with ./configure and its options
; (this is used for building the UrJTAG.exe distributable):
;
;  CFLAGS="-mno-cygwin -O2 -DJTAG_BIN_DIR=\"/\" -DJTAG_DATA_DIR=\"/data\""
;  ./configure --enable-relocatable
;       --with-ftd2xx=/tmp/FTDI_CDM_204
;       --with-libusb=/tmp/LibUSB-Win32_112
;       --with-inpout32

so I tried it with:
CFLAGS="-DJTAG_BIN_DIR=\"/\" -DJTAG_DATA_DIR=\"/data\"" ./configure --enable-maintainer-mode --host=i586-mingw32msvc --with-ftd2xx="/home/username/CDM20808"  --disable-werror --disable-nls --without-libusb  --disable-silent-rules --enable-relocatable

but the resulting compile size is  smaller

Jamz' relocatable compile works!

I still had to use c:\bsdl and c:\svf\bbv2.svf (double slashes), so there is a minor bug, but this is good enough to use in manufacturing. Screen shot attached.

---

Updated programming wiki:
http://dangerousprototypes.com/docs/Bus ... ith_urJTAG (http://dangerousprototypes.com/docs/Bus_Blaster_v2_manufacturing_resources#Programming_the_CPLD_with_urJTAG)

Patched urJTAG, BSDL, and SVF files attached.

Here's an updated patch with interface changed to interfaceb, this should work but it is untested.

Just a friendly note if you're following this topic...

I split the monster thread into several small parts that should be easier to surf, but you will not get more notifications until you comment or click 'notify' on the new threads.

Bus Blaster v2 design thread http://dangerousprototypes.com/forum/in ... pic=1490.0 (http://dangerousprototypes.com/forum/index.php?topic=1490.0)
BBv2 CPLD design and implementation http://dangerousprototypes.com/forum/in ... pic=1659.0 (http://dangerousprototypes.com/forum/index.php?topic=1659.0)
urJTAG for BBv2 JTAG B http://dangerousprototypes.com/forum/in ... pic=1655.0 (http://dangerousprototypes.com/forum/index.php?topic=1655.0)
UART on BBv2 MSSPE2? http://dangerousprototypes.com/forum/in ... pic=1656.0 (http://dangerousprototypes.com/forum/index.php?topic=1656.0)
FT2232H EEPROM discussion http://dangerousprototypes.com/forum/in ... pic=1658.0 (http://dangerousprototypes.com/forum/index.php?topic=1658.0)

Here is an updated patch, based on list feedback. Thanks Tornado! A fresh compile is attached, it seems to work great.

Hi Ian

 I can't find the latest patch in the svn that worked for this project.  Its still build #1869 from the urjtag repositories.

I have finished populating BBv2 board and I was about to go through the patching process but it turns out the latest GIT version already includes all the patches.

However, it seems that the interface should be set to "1", default is "0" and not "2" as the Wiki says. At least this way I was able to program it with MacOSX. The only irritating thing about it is that I have to unload FTDIUSBSerialDriver.kext serial driver every time I want to use it, but I can live with that.

jtag> cable ft2232 interface=1
Connected to libftd2xx driver.
jtag>

Thanks pppd,

I'm not sure if that is specific to the GIT version or if we changed it. Sorry about the confusion, I updated the wiki.

Does it not co-exist peacefully with the serial driver under MacOSX? Is there anything we can change to help?

It has always been like that in MacOSX. I remember I had to disable the driver for libftdi use as well when coding the renaming utility.

There is a workaround for that, but it is a trick and should be used by individuals only, surely not in the production device. You can change the VID/PID of BBv2 to something non-existing and [s:]then patch the urJTAG to recognize the new VID/PID pair as FT2232H[/s:]. This does work well on my computer :)

edit: Actually there is no need to patch urJTAG at all, as you can specify VID/PID when connecting. I have changed my PID to 0xBB02 and it works perfectly along with FTDI serial drivers. All I have to do is use vid parameter when connecting:

cable ft2232 pid=0xbb02

I don't think this will work with other apps that depend on default VID/PID though.. so I guess I will need to unload the driver anyway.

So Far, So Good :)

OpenOCD is happy to accept custom vid/pid so it seems it will work just fine after all.

#
# Bus Blaster v2
#
# http://dangerousprototypes.com/docs/Bus_Blaster
#
interface ft2232
ft2232_device_desc "BusBlasterV2"
ft2232_serial "BBv2"
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0xbb02

Nice, thank you. May I please kind of condense this and add it to the manual?

You don't need to ask, feel free to modify it in any way :) I'll post the updated Pirate Rename utility when I come back home.

Thank you, I posted it here, and will add a link when you upload the utility:
http://dangerousprototypes.com/docs/FT2 ... _on_MacOSX (http://dangerousprototypes.com/docs/FT2232_drivers_on_MacOSX)

I have updated XCode to the version 4 and I am no longer able to build PPC binaries so this is an Intel only build. It includes source code and a Makefile so anyone can build it for their own platform and OSX version if necessary.

Libusb-1.xx is required for both compiling and working but you need it anyway for JTAG/OpenOCD. You can install it from Macports (http://http://www.macports.org) with the following command: "sudo port install libusb"

It is a command line utility which has a predefined EEPROM values, no fancy GUI there. It takes no arguments and detects devices by itself. Below is an extract from a successful session:

BusBlaster rename utility
Initializing libusb-1.0...OK
Initializing libftdi...OK
Listing USB devices...OK
Found 1 FTDI device(s):

 ID	VID  	PID  	Description (serial)
 01	0x0403  0x6010  FT2232H (1a74e44)

Which device would you like to program (1-1):1

Your device will be programmed with the following values:

 Vendor  ID  : 0x0403
 Product ID  : 0xBB02
 Manufacturer: Dangerous Prototypes
 Description : BusBlasterV2
 Serial      : BBv2
 Current req : 200mA

Are you sure you want to write EEPROM (yes/no):yes
Opening selected FTDI device...OK
Writing EEPROM...OK

You can now load the FTDI kernel driver back :)

[attachment=0]

Really nice, thank you.

Is there any chance you can make the VID/PID a user option? We've got a license to use Microchips VID, and I don't want to tick them off by camping on one of their IDs. You're free to do as you like, of course, but I would be happier hosting it and linking to it from the wiki without that setting :)

One thing I can do is buy some of those gray-market VIDs and you can adopt one of those for your app. I wouldn't want to sell a product with them, but if you just need it for this it is certainly no big deal.

Sure thing, I will have a breakfast and then post an updated utility. Right now it uses FTDI Vendor ID ( 0x0403 ) and the PID was selected to be an abbreviation of BusBlaster02. I will also add a restore option to bring the default VID/PID back.

I don't think you should use anything different than the original 0x0403/0x6010 when selling it. I guess Mac users are minority anyway and I believe Linux/Windows customers aren't affected by this problem. They can still put name strings though.

Never mind then :) I thought it was a microchip code (also had a 4 and 3), I don't care at all about FTDI! :)

Alright, so it stays as it is now ;)