I try to debug the FPGA (Xilinx 3e Starter Kit) with adv_jtag_brigde command in cygwin. I have already install:
1. libusb (apt-cyg install libusb)
2. libioperm (apt-cyg install libioperm)
3. libftdi (http://www.intra2net.com/en/developer/libftdi/download.php) and execute the commands
a) cd libftdi-0.16
b) ./configure --prefix=/usr
c) make
d) sudo make install
I successfully implement the design with ISE and download it to FPGA but when I execute the command
adv_jtag_bridge xpc_usb
I take the following error message:
Failed to find Xilinx Platform Cable USB
Failed to initialize cable 'xpc_usb', aborting.
Obviously I have connect the programming cable with FPGA.

Any help?

I'm not entirely sure, but I suppose it is a known problem related to xpc_usb state after uploading the bitfile.

Description:
Nathan Yawn: �The Xilinx Parallel Cable DLC9 is not publicly documented. Downloading a bitstream to the FPGA puts the DLC9 into a mode from which we cannot recover. The cable must be unplugged from the workstation an re-attached before it can be used with adv_jtag_bridge. (In some cases, unlocking the cable in Impact has been reported to work.)�
Related discussion: http://opencores.org/forum,OpenRISC,0,3624

Difficulty: Many current boards are being delivered with the DLC9 cable already on-board. That means that only a regular USB cable is connected between computer and board, without the old-style DLC9 cable-box in between. However, that makes it impossible to reset the cable without powering off the entire board, losing the FPGA configuration on the process. If unlocking the cable in Impact does not work, there is no direct way for adv_jtag_bridge to use the connection.

You could try to: After uploading the bitfile to the FPGA and before starting adv_jtag_bridge, reprogram the cable to reset it. Under Linux the command (below) is found on a udev rule, xusbdfwu.rules.

fxload -v -t fx2 -I /usr/share/xusbdfwu.hex -D $TEMPNODE

$TEMPNODE has to be substituted with bus and device position on bus. To check that use lsusb. Then, substitute for instance with: -D 003:005 where 003 is the bus and 005 the device position.

If that does not work, you will have to try the options described in the FAQ.pdf document available with minsoc. If that works, I will add to the FAQ as an option.

Best regards,
Raul

Thanks Raul. I had already read that topics and try the solutions. Unfortunately disconnect and reconnect the cable doesn't work.

More info:
When i execute testlibisb command from cygwin reports:
Dev #0: 0000 - 0000

It seems that libusb cannot identify the usb devices that i connect to the system. Even if I connect a usb flash drive testlibisb produce the same result while mount command has already mount the devices to cygwin.

My system is Windows 7 64bit with cygwin

I changed my environment. Now I am using Windows XP 32 bit with cygwin. My problem again is adv_jtag_bridge. Here is my output

Found Xilinx Platform Cable USB (DLC9)
Found Xilinx Platform Cable USB (DLC9)
firmware version = 0x0404 (1028)
cable CPLD version = 0x0012 (18)
Enumerating JTAG chain...
WARNING: maximum supported devices on JTAG chain (1024) exceeded.
Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: (unknown) 0xFFFFFFFF -1
1: (unknown) 0xFFFFFFFF -1
2: (unknown) 0xFFFFFFFF -1
3: (unknown) 0xFFFFFFFF -1
.
1022: (unknown) 0xFFFFFFFF -1
1023: (unknown) 0xFFFFFFFF -1
Target device 0, JTAG ID = 0xffffffff
ERROR! Unable to autoprobe IR length for device index 0; Must set IR size on command line. Aborting.

I have already read FQA.pdf and disconnecting and connecting again the cable didn't work. I also read this topic
http://opencores.org/forum,OpenRISC,0,3624
So if I power off the FPGA and power on again (obviously with this step I am loosing my configuration) when I execute the command adv_jtag_bridge xpc_usb the output is the following:

Found Xilinx Platform Cable USB (DLC9)
Found Xilinx Platform Cable USB (DLC9)
firmware version = 0x0404 (1028)
cable CPLD version = 0x0012 (18)
Enumerating JTAG chain...
Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: (unknown) 0x06E5E093 -1
1: (unknown) 0xF5046093 -1
2: XC3S500E_FG320 0x41C22093 6
Target device 0, JTAG ID = 0x06e5e093
ERROR! Unable to autoprobe IR length for device index 0; Must set IR size on command line. Aborting.

I have my bsdl files in home directory and inside the directory of adv_jtag_bridge.

Any help?
Andreas

Adv_jtag_bridge is not finding the BSDL files for devices 0 and 1 on your JTAG chain. That's why the IR length is listed as -1. Make sure you've got the right BSDL files for these chips, and put them in the same place that you have the BSDL file for device 2.

I've got experimental code that may help with the other problem (no communication after downloading the bitstream). Send an e-mail to my opencores address if you'd like to experiment with it.

I am facing the same problem (or at least the same symptom ) running native linux:

after executing ( bundled in a script ):
fxload -v -t fx2 -I /usr/share/xusbdfwu.hex -D /dev/bus/usb/002/036
sudo adv_jtag_bridge -b . xpc_usb

I get:

microcontroller type: fx2
single stage: load on-chip memory
open RAM hexfile image /usr/share/xusbdfwu.hex
stop CPU
write on-chip, addr 0x1d2f len 10 (0x000a)
write on-chip, addr 0x06d9 len 12 (0x000c)
write on-chip, addr 0x170d len 81 (0x0051)
write on-chip, addr 0x0c4c len 536 (0x0218)
write on-chip, addr 0x156e len 120 (0x0078)
write on-chip, addr 0x1c59 len 23 (0x0017)
write on-chip, addr 0x0090 len 232 (0x00e8)
write on-chip, addr 0x06e5 len 584 (0x0248)
write on-chip, addr 0x15e6 len 112 (0x0070)
...
write on-chip, addr 0x0000 len 3 (0x0003)
write on-chip, addr 0x14e2 len 12 (0x000c)
write on-chip, addr 0x09d2 len 555 (0x022b)
write on-chip, addr 0x14ee len 128 (0x0080)
write on-chip, addr 0x09d1 len 1 (0x0001)
write on-chip, addr 0x0bfd len 79 (0x004f)
... WROTE: 7443 bytes, 85 segments, avg 87
reset CPU
Failed to find Xilinx Platform Cable USB
Failed to initialize cable 'xpc_usb', aborting.

Is it possible to share any possible experimentation/info how to pass this point?

Thanks,

Stoev

Does your cable light up green after you upload the firmware, after fxload?

I believe you should wait a while after uploading the cable's firmware with fxload and before using it with adv_jtag_bridge. Try to split them in two scripts or execute the commands manually. Wait for the green light to light up before proceeding with adv_jtag_bridge.

If it still does not work, could you check with lsusb which are the product and product ids of the usb device after firmware upload (fxload)?

Adv_jtag_bridge expects
vendor id 0x3fd
product id 0x08

If they differ, you could try changing their values on cable_xpc_dlc9.c lines 101 and 102.

Good luck,
Raul

Thank you Paul,

The issue disappear after I ran the 2 command manually instead of bundled in a script.
After the second one:
`adv_jtag_bridge xpc_usb`
Found Xilinx Platform Cable USB (DLC9)
Found Xilinx Platform Cable USB (DLC9)
firmware version = 0x0406 (1030)
cable CPLD version = 0x0012 (18)
Enumerating JTAG chain...

Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: xc2c64a_vq44 0x06E5E093 8
1: XCF04S 0xF5046093 8
2: XCF04S 0xF5046093 8
3: XC3S1600E_FG320 0x21C3A093 6

Target device 0, JTAG ID = 0x06e5e093
Xilinx IDCODE, assuming internal BSCAN mode
(using USER1 instead of DEBUG TAP command)
ERROR! Unable to find DEBUG command for device index 0, device ID 0x6E5E093
Unable to find DEBUG command, aborting.

I am not sure at the current point why it is failing on debugging the xc2c64a_vq44 device.
As per doc for my board Xilinx ug257 (Spartan-3E 16000), the device is CoolRunner-CPLD.

My only refference what to expect it the "Advanced Debug System FAQ".pdf doc (http://www.minsoc.com/advanced_jtag_bridge_faq)

Any pointers what I should try in order to jump over it?

Regards,

Stoev

Sorry for the unexperienced question.

The option for the device index had to be given:

`adv_jtag_bridge -x 3 xpc_usb`

IDCODE sanity test passed, chain OK!
JSP server listening on host tesla-energy (0.0.0.0), port 9944, address family IPv4
JSP server thread running!
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 0 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 1 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 2 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 3 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 4 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 5 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 6 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 7 at startup! 'max retries'
No watchpoint hardware found, HWP server not starting
HWP server listening on host tesla-energy (0.0.0.0), port 9928, address family IPv4
JTAG bridge ready!
HWP server thread running!

Regards,

Stoev

I have reach a point of executing :

`/opt/openrisc/bin/or32-elf-gdb uart.or32`

Building automata... done, num uncovered: 0/216.
Parsing operands data... done.
GNU gdb (OpenRISC 32-bit toolchain for or32-elf (built 20120322)) 7.2-or32-1.0rc3
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later " target="_blank">http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=or32-elf".
For bug reporting instructions, please see:
..." target="_blank">http://bugzilla.opencores.org/>...
Reading symbols from /home/tesla/dev/fpga/opencores/minsoc/sw/uart/uart.or32...done.
(gdb) target remote :9999
Remote debugging using :9999
Remote failure reply: E01
(gdb) Quit
(gdb)

on the terminal where `adv_jtag_bridge -x 3 xpc_usb` is running the logs are:

HWP server thread running!
Burst read timed out.
Retry count exceeded in burst read!
Burst read timed out.
Retry count exceeded in burst read!
Burst read timed out.
Retry count exceeded in burst read!
Burst read timed out.
Retry count exceeded in burst read!
Error while reading all registers: 'max retries'

There probably many things could be wrong, but any idea where I would start digging and trying to pass forward at this point?

Regards,

Stoev

Which minsoc version are you using?

I'd recommend you to use the development version because of your cable.

http://www.minsoc.com/dev:start

Raul

And use gdb-6.8 not 7.2

http://www.minsoc.com/gdb_install

Hi Paul,

Thank you for your help.

I was using 1.0 version.
After the advice, I downloaded the dev version from the link ( using minsoc-install.sh ) and now am synthesizing against it and using and running gdb-6.8, but seems that the same symptom appears:

/opt/gdb_stable/bin/or32-elf-gdb uart.or32
Building automata... done, num uncovered: 0/216.
Parsing operands data... done.
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later " target="_blank">http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=or32-elf"...
(gdb) target remote :9999
Remote debugging using :9999
Remote failure reply: E01

adv_jtag_bridge -b . -x 3 xpc_usb ( correctly detecting the device, the same as before, so including only the last lines ):

ERROR reading DCR 6 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 7 at startup! 'max retries'
No watchpoint hardware found, HWP server not starting
HWP server listening on host tesla-energy (0.0.0.0), port 9928, address family IPv4
JTAG bridge ready!
HWP server thread running!
Burst read timed out.
Retry count exceeded in burst read!
Burst read timed out.
Retry count exceeded in burst read!
Burst read timed out.
Retry count exceeded in burst read!
Burst read timed out.
Retry count exceeded in burst read!
Error while reading all registers: 'max retries'

Any advice, what I can try in order to detect what my problem is.

Thanks,

Stoev

Running adv_jtab_bridge with -t options gives:

Found Xilinx Platform Cable USB (DLC9)
Found Xilinx Platform Cable USB (DLC9)
XPC USB driver opening cable
firmware version = 0x0406 (1030)
cable CPLD version = 0x0012 (18)
Enumerating JTAG chain...

Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: xc2c64a_vq44 0x06E5E093 8
1: XCF04S 0xF5046093 8
2: XCF04S 0xF5046093 8
3: XC3S1600E_FG320 0x21C3A093 6

Target device 3, JTAG ID = 0x21c3a093
Xilinx IDCODE, assuming internal BSCAN mode
(using USER1 instead of DEBUG TAP command)
IDCODE sanity test passed, chain OK!
*** Doing self-test ***
Stall or1k - CPU(s) stalled.
SRAM test:
ERROR! WB bus error during burst write, address 0x0 (index 0x0), retrying!
ERROR! WB bus error during burst write, address 0x0 (index 0x0), retrying!
ERROR! WB bus error during burst write, address 0x0 (index 0x0), retrying!
ERROR! WB bus error during burst write, address 0x0 (index 0x0), retrying!
ERROR! WB bus error during burst write, address 0x0 (index 0x0), retrying!
ERROR! WB bus error during burst write, address 0x0 (index 0x0), retrying!
ERROR! WB bus error during burst write, address 0x0 (index 0x0), retrying!
ERROR! WB bus error during burst write, address 0x0 (index 0x0), retrying!
ERROR! WB bus error during burst write, address 0x0 (index 0x0), retrying!
ERROR! WB bus error during burst write, address 0x0 (index 0x0), retrying!
ERROR! WB bus error during burst write, address 0x0 (index 0x0), retrying!
Max WB bus errors reached!
or32_selftest.c:359: Jtag error 16 occured; exiting.

What board are you testing the system on?

Assure yourself of having set the correct reset level and clock frequency on minsoc_defines.v. http://www.minsoc.com/advanced_jtag_bridge_faq#adv_jtag_bridge_self_test_fails

It probably does not matter much. But minsoc-install.sh has installed a new version of adv_jtag_bridge somewhere. You probably had it before yourself. Therefore, try to check if you are using the old or the new one by issuing "which adv_jtag_bridge" and comparing the resulting path.

Regards,
Raul