Hi everyone,

I started to build a OR1200 SOC system and can't get the adv_jtag_bridge to work.

I added to the or1200 core the 'adv_dbg_if' and 'xilinx_internal_jtag'.
I connected the or1200 core with the adv_dbg_if and the adv_dbg_if with the xilinx_internal_jtag (no wishbone connection and no other IP)

I loaded this design on a spartan3an-starter-kit with impact.


I compiled the adv_jtag_bridge for linux and downloaded the BSDL files from Xilinx.
With the info from the BSDL file, I run

./adv_jtag_bridge -c 0x02 -l 0:6 xpc_usb
Found Xilinx Platform Cable USB (DLC9)
Found Xilinx Platform Cable USB (DLC9)
firmware version = 0x0517 (1303)
cable CPLD version = 0x0012 (18)
Enumerating JTAG chain...
WARNING: maximum supported devices on JTAG chain (16) 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
4: (unknown) 0xFFFFFFFF -1
5: (unknown) 0xFFFFFFFF -1
6: (unknown) 0xFFFFFFFF -1
7: (unknown) 0xFFFFFFFF -1
8: (unknown) 0xFFFFFFFF -1
9: (unknown) 0xFFFFFFFF -1
10: (unknown) 0xFFFFFFFF -1
11: (unknown) 0xFFFFFFFF -1
12: (unknown) 0xFFFFFFFF -1
13: (unknown) 0xFFFFFFFF -1
14: (unknown) 0xFFFFFFFF -1
15: (unknown) 0xFFFFFFFF -1

Target device 0, JTAG ID = 0xffffffff
ERROR! Unable to autoprobe IR length for device index 1; Must set IR size on command line. Aborting.

So it seems there is a connection problem between the cable and the TAP.


I simplified the setup and created a very small hardware-setup:

-----------------------------
module tap_test (
unused
);

input unused;


BSCAN_SPARTAN3A BSCAN_SPARTAN3A_inst (
.CAPTURE(), // CAPTURE output from TAP controller
.DRCK1(), // Data register output for USER1 functions
.DRCK2(), // Data register output for USER2 functions
.RESET(), // Reset output from TAP controller
.SEL1(), // USER1 active output
.SEL2(), // USER2 active output
.SHIFT(), // SHIFT output from TAP controller
.TCK(), // TCK output from TAP controller
.TDI(), // TDI output from TAP controller
.TMS(), // TMS output from TAP controller
.UPDATE( ), // UPDATE output from TAP controller
.TDO1( 1'b0 ), // Data input for USER1 function
.TDO2( 1'b0 ) // Data input for USER2 function
);
-----------------------------------------------------------


I loaded this on the fpga but adv_jtag_bridge gets still only 1's.

Does anybody use the adv_jtag_bridge successful with the spartan3a(n)-starter-kit?

It does sound like the problem is between the JTAG cable and the TAP. But remember that if you're using the xilinx_internal_jtag block, the TAP is part of the SPARTAN2 chip, it's not created from the LUTs in the FPGA. So, adv_jtag_bridge should be able to enumerate the jtag chain even if no bitstream has been downloaded to chip.

A couple of suggestions. First, don't use command-line parameters to define the jtag chain parameteres, just let adv_jtag_bridge parse and use the BSDL files directly (though this won't help with the enumeration problem). Second, try resetting the JTAG cable between downloading the bitstream and starting adv_jtag_bridge - you may be able to do it using 'impact', or you may just unplug and reconnect the cable to the USB. Make sure you exit 'impact' before starting adv_jtag_bridge. Whatever mode the DLC9 uses to download a bitstream, it's not the same as regular JTAG mode, and since Xilinx won't release the cable API, adv_jtag_bridge can't set the cable mode (but, it defaults to JTAG).

Thank you very much,

I found the problem. After using Impact, I have to turn the board off and on.
Everything else (unplugging cable, Impact cable reset ect.) doesn't work.
I also tried the official xilinx driver on windows and adv_jtag_bridge with cygwin, where the same happens.

So this could be a firmware-problem on the board.




In addition, I found a little bug bsdl.c line 213:
-->> ptr = parse_extract_values(direntry->d_name);
The argument is only the filename, not the complete path.

For example if I put all my BSDL files in ~/SomeData/xilinx/BSDL-Files/
and I use the adv_jtag_bridge from somewhere else like

cd ~/adv_jtag
./adv_jtag_bridge -b ~/SomeData/xilinx/BSDL-Files

the function parse_extract_values can't find the file.

The board might be supplying power to the DLC9 cable, so you might try leaving the board on, but unplugging the cable from both the computer/USB and from the spartan board.

It's really not a 'bug' per se...I just don't know the command to send the DLC9 cable to put it into stardard JTAG mode, so adv_jtag_bridge doesn't send it.

Thanks for the bug report in the BSDL parser. I'm working on a new release sometime in the next month, so hopefully a fix will get included with that.

Hello,

I'm facing the same problem with the spartan3a starter kit.

The problem is, that this starter-kit has an on-board USB/JTAG programmer.
So simple unplugging the cable doesn't work. There is a jumber, which should be responsible for
the USB/JTAG programmer (see [1], page 5), but removing it doesn't work neither.


@nyawn
You wrote that you don't know the command to send the DLC9 cable to put it into standard JTAG mode.
How is it possible to find this command. Do you have any ideas for reverse-engineering for getting this command?


[1] http://www.xilinx.com/support/documentation/boards_and_kits/s3astarter_schematic.pdf

I'm guessing the starter-kit gets its power from the USB JTAG connection? (Or at least, the on-board JTAG interface logic gets its power from the same source as the FPGA, so stopping power to the JTAG I/F also kills the FPGA?) Yep, that's a problem, one I don't know how to solve, unfortunately. You may be stuck with getting a second JTAG cable, and using the stand-alone JTAG TAP core through FPGA I/O pins.

I have since found a little bit more information about the DLC9 protocol, but don't hold your breath...it may not be accurate, and I don't have access to a DLC9 to test it with.

To reverse-engineer the DLC9, my first attempts would probably involve trying to use software to log raw USB transactions, then using the DLC9 and looking at what gets logged. There may already be software projects to log USB traffic. If not, I'm sure libusb or the Linux kernel drivers could be hacked to do the logging. Of course, if you've actually got a commercial USB protocol analyser, that would make things easiest of all...sadly, I no longer have access to one.

If you do try to reverse-engineer the DLC9, please let me know what you find...this is a problem I'd love to fix.

Logging raw usb data is no problem. Wireshark in combination with usbmon (see [1]) on my linux box seems to work fine.


You wrote, that you have a little bit more information about the DLC9 protocol.
Is it more than in 'cable_xpc_dlc9.c'?

It would be nice to have a little bit more information, so I don't need to search from scratch.



[1] http://wiki.wireshark.org/CaptureSetup/USB

All my information on the DLC9 comes from the UrJTAG project, I wrote cable_xpc_dlc9.c based on an older version of their DLC9 driver, then experimented with the actual cable until I got it to work.

The last time I looked at UrJTAG, it appeared that they had added more functionality, but I have not taken the time to study it. It's possible they have already discovered the call to set the cable back to JTAG mode. But, I no longer have a DLC9 to test with (or a Xilinx board to use it with, for that matter). If you don't mind hacking some C code, you might experiment with some of the USB transactions in UrJTAG that aren't in my driver, and see what they do.

If you do dump the USB packets, then what we're looking for happens either at the end of the bitstream upload operation, or more likely just before the first JTAG operation. I'd probably try implementing a minimal microblaze system in the FPGA, then use the Xilinx debugger to connect to it and upload some code. The cable mode set command must happen between the last large data packet of bitstream data and the first large data packet of code upload, and most likely it happens when the debugger is first started. There will probably be a similar-looking packet (command number or data different by one?) sent at the beginning of the bitstream upload, setting the cable to a different mode.

If you'd like discuss it in more depth, you can mail me directly at my opencores.org address.