I already solved this while back but now I can't repeat it ...
I need to hook up mine xc2c256 board to busblaster but darn thing won't recognize it
This is the latest try
xc2c256 - BBv2 (jtagkey)
Vdd/3v3 - VTG (jumper on)
Vss - GND
Tck - TCK
TDO - TDO
TDI - TDI
TMS - TMS
can't remember what I did last time to make it work :(
solved, the problem was power ...
still can't program the device (no idea why) but at least I see it both in iMPACT and urJTAG
I have this same chip (TQFP100 version I think) on a dev-board that I use to test the Bus Blaster firmware in development. I have it out because I am working on bbv4 - I did a quick test and I can program a LED on/off on button press type bitstream ok using urJTAG. Please let me know if you find a hardware bug, I'll try to release a new bitstream with an update.
[quote author="ian"]I have this same chip (TQFP100 version I think) on a dev-board that I use to test the Bus Blaster firmware in development. I have it out because I am working on bbv4 - I did a quick test and I can program a LED on/off on button press type bitstream ok using urJTAG. Please let me know if you find a hardware bug, I'll try to release a new bitstream with an update.[/quote]
this one is TQG144 and for some reason I managed to erase it (so now is dead) but can't program anything into it :( ...
not even the on board atmel programmer (that uses some prehistoric adept software from digilent) works .. it also erase it successfully and then can't program it .. weeeeird
Weird, iMPACT (just downloaded latest version to be sure) detects cable properly, cable debugging works, it sees the cpld on board, but can't program it ?!?!?! Erase works, check blank works ... but programming fails even if you remove verify from programming parameters ?!?!?!
I'm clueless attm :(
INFO:iMPACT - Current time: 2/13/12 8:52 AM
// *** BATCH CMD : Program -p 1 -e
PROGRESS_START - Starting Operation.
Maximum TCK operating frequency for this device chain: 0.
Validating chain...
Boundary-scan chain validated successfully.
'1': Erasing device...
'1': Erasure completed successfully.
'1': Programming device...
done.
'1': Setting ISC done bits...done
INFO:iMPACT:1982 - '1':Done bit could not be programmed correctly.
'1': Programming of user selected options failed.
PROGRESS_END - End Operation.
Elapsed time = 1 sec.
now, if you look at the log .. it states "programming device... done" !??!?!??! if you check if device is blank after this, it will be .. so no programming actually happened ... and then this "done bit" .. no idea what the hack that is .. maybe this cpld is just dead, donno how many write cycles these babies have ..
XC2Cs should have 1000s I think, even at extreme temperatures and voltages.
yeah looks like 1000 .. donno, it might be that I pushed more then 1000 bitstreams into it .. can't say, I have the board for a long time .. I ordered another chip to replace this one, hopefully that will solve the problem ..
this dev board is nice but the atmel/adept programming part is really piece of @$#*&$@% .. does not work from ISE, does not work with new adept drivers .. I had to install blank XP and then put stuff from CD (as there's no info about this anymore on the net) in order to get it working ... nice that there's a temperature and current probe on board - I can't access it (except trough that unsupported windows app digilent wrote and forgot ..) .. I now assume cpld is dead (weird as it worked, I erased it and now I can't write anything into it) but who knows :( ... on top of all, I just noticed there's a serial flash (M25P40) on board connected to the cpld ... probably just for testing purposes, I don't believe it has anything to do with how this cpld works ..
Problem solved :)
1. CPLD was ok
2. ADEPT programming firmware in the on board Atmel for some reason won't program the cpld - it's definetely gone. I tried the darn thing with a blank winxp and software from supplied CD - nothing, ziltch, the software talks to atmel, gets all the data from atmel (temperature, current measurements etc etc) but it won't program cpld - why, donno, don't really care
3. BusBlaster, for some reason, after I managed to kill my operating system proper ftdi drivers and urjtag I properly built I started tweaking too many things in the same time. One of them was tweaking the content of the BusBlaster's on boad eprom (where FTDI2232H stores configuration). Luckily I have my old mini2232H board that does allow urjtag to connect to it so I checked out the eeprom content there and found what's wrong. If your busblaster don't accept connections as jtagkey you might want to fix the eeprom (if you already messed it up, original eeprom that comes when device comes from DP is OK so you do NOT need to mess with it), but if you messed up your eprom data like I did here are the steps to fix it
(assumes windows)
a) download FT_Prog_v2.4.2 or newer from ftdi site (http://http://www.ftdichip.com/Support/Utilities.htm)
b) connect your busblaster
c) start FT_Prog
d) scan for devices
e) load attached xml template file
f) write changes into ftdi eprom
g) disconnect your busblaster and it should be now ready to play :)
and a quick linux setup since latest distros come with libftdi only and jtag that behaves like it knows jtagkey but won't connect properly as it is build with libftdi only ...
0. get latest version of libftd2xx from ftdi site (http://http://www.ftdichip.com/Drivers/D2XX.htm)
1. unpack them somewhere
mkdir /home/arhimed/Dev/libftd2xx
cd /home/arhimed/Dev/libftd2xx
wget http://www.ftdichip.com/Drivers/D2XX/Linux/libftd2xx1.1.0.tar.gz
tar zxvf libftd2xx1.1.0.tar.gz
2. now install the libftd2xx (this part you do as root)
su -
cp /home/arhimed/Dev/libftd2xx/x86_64/libftd2xx.so.1.1.0 /usr/local/lib64
ln -s /usr/local/lib64/libftd2xx.so.1.1.0 /usr/local/lib64/libftd2xx.so
cp /home/arhimed/Dev/libftd2xx/i386/libftd2xx.so.1.1.0 /usr/local/lib
ln -s /usr/local/lib/libftd2xx.so.1.1.0 /usr/local/lib/libftd2xx.so
ldconfig
3. get latest version of urjtag:
mkdir /home/arhimed/Dev/URJTAG
cd /home/arhimed/Dev/URJTAG
svn co http://urjtag.svn.sourceforge.net/svnroot/urjtag/trunk urjtag
cd urjtag/trunk/urjtag
./autogen.sh
4. configure urjtag (I'm disabling python as I have no clue what it does and I don't use it for sure and the python support for urjtag won't compile on my F16 so this was fastest way around it, --with-ftd2xx compiles in the direct drivers you require, just point it to where your ftd2xx.h and WInTypes.h are)
cd /home/arhimed/Dev/URJTAG/urjtag/trunk/urjtag
./configure --without-python --with-ftd2xx="/home/arhimed/Dev/FTDI/libftd2xx"
make
5. install urjtag
su -
cd /home/arhimed/Dev/URJTAG/urjtag/trunk/urjtag
make install
In order to access busblaster as ordinary user the easiest way is to do following:
su -
echo "SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6010", MODE="0666"" > /etc/udev/rules.d/40-buspirate.rules
Thanks for the update, I'm glad you got it going. May I please copy these two posts to the BB wiki?
Oh yes, please do ... will be way easier to find them on wiki then on forum :)
Another important issue (what actually initiated the problem!!!)
FTDIO_SIO kernel module installed itself on my system with some updates. Donno with what the darn thing came in but is preventing FTD2xx drivers from working properly.
If you get something like this:
jtag> cable jtagkey interface=0
error: Couldn't connect to suitable USB device.
error: ftdi/ftd2xx error: ftdi_usb_open_desc() failed: device not found
As a root do this:
rmmod ftdi_sio
and the piece of crap will be removed from the loaded modules list. Now, you have to do this every time you connect the BB if you have this module. You can solve the problem permanently by blacking out this module (to /etc/modprobe.conf add line "alias ftdi_sio off" and/or add to /etc/modprobe.d/blacklist line "blacklist ftdi_sio") but note that then when you attach a ftdi based serial adapter, it won't work and you need to manually load the ftdi_sio module.