User Tools

Site Tools


advanced_jtag_bridge_faq

Advanced Debug System FAQ

Current Problems

CRC errors on burst transfers

Advanced JTAG Bridge log:

$ adv_jtag_bridge -b ~/bsd_files xpc_usb
Found Xilinx Platform Cable USB (DLC9)
Found Xilinx Platform Cable USB (DLC9)
firmware version = 0x0961 (2401)
cable CPLD version = 0xFFFE (65534)
Enumerating JTAG chain...

Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: XC5VLX110T_FF1136 0x72AD6093 10
1: XCCACE 0x0A001093 8
2: xc95144xl_cs144 0x59608093 8
3: XCF32P_FS48 0xF5059093 16
4: XCF32P_FS48 0xF5059093 16

Target device 0, JTAG ID = 0x72ad6093
Xilinx IDCODE, assuming internal BSCAN mode
(using USER1 instead of DEBUG TAP command)
IDCODE sanity test passed, chain OK!
No watchpoint hardware found, HWP server not starting
HWP server listening on host longaville (0.0.0.0), port 9928, address family IPv4
HWP server thread running!
JTAG bridge ready!
CRC ERROR! match bit after write is 0 (computed CRC 0xe652ffc8)Retry count exceeded! Abort!

GDB log :

$ /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=x86_64-unknown-linux-gnu --target=or32-elf"...
(gdb) target remote :9999
Remote debugging using :9999
0x00000100 in _reset_vector ()
(gdb) load
Loading section .reset, size 0x190 lma 0x0
Remote communication error: Connection reset by peer.
(gdb) 

Generic Answer: Most probably, the SoC has not been configured correctly, wrong reset level or clock divisor configuration. Double-check your minsoc_defines.v file. Otherwise, you forgot to upload the FPGA bitfile.

Specific Answer: Nathan Yawn: “adv_jtag_bridge is talking to the cable and the hard TAP, but it doesn't look like it's talking to the internal TAP (the BSCAN block). I suspect either you have the wrong options defined in your HDL, your synthesis is wrong, or your bitstream isn't downloaded correctly.

Make sure you're using the right TAP for your FPGA, and make sure you're using the right defines for your FPGA. Then resynthesize, and download the bitstream to the FPGA before starting adv_jtag_bridge.”

Related discussion: http://opencores.org/forum,OpenRISC,0,4616

Adv_jtag_bridge does not connect to xpc_usb, why?

Example:

adv_jtag_bridge xpc_usb
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.

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

UPDATE: The DLC9 cable driver has been updated in version 3.0.0 of the Advanced Debug System. Some users have reported that this problem is fixed by the update.

cd minsoc/rtl/verilog/adv_debug_sys/Software/adv_jtag_bridge
svn switch http://opencores.org/ocsvn/adv_debug_sys/adv_debug_sys/tags/ADS_RELEASE_3_0_0/Software/adv_jtag_bridge
make
make install

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.

Option 0: Drop advanced debug system. If you are only interested in trying out the system with a firmware, you do not necessarily need the adv_debug_sys. You can use the tweak I want my design to automatically initialize my firmware on power-up, how do I do that? found in MinSoC FAQ instead, so the system will run the firmware automatically after the bitfile has been uploaded. The adv_debug_sys is designed mainly to debug the system, but has the advantage of being able to upload firmwares.

Alternatives: I really want the advanced debug system. The advanced debug system is standard and debugging might be invaluable. If you want or need it, you have three options to circumvent the xpc_usb problems:

Option 1: 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 /dev/bus/usb/003/005 where 003 is the bus and 005 the device position. You could also use the following command that finds the bus and device numbers:

fxload -v -t fx2 -I /usr/share/xusbdfwu.hex -D `lsusb | grep Xilinx | awk '{print "/dev/bus/usb/"$2"/"$4}' | sed -e "s/://"`

Option 2: You can write the bitfile to an available on-board memory, from which the FPGA can self- configure on power-on. This way the FPGA is already configured on power-on and the cable is unlocked, enabling the use of the adv_jtag_bridge.

Note: Be certain that the FPGA is configured with MinSoC. You can use the adv_jtag_bridge self-test for that. “adv_jtag_bridge -t <cable>”. The first test checks memory accesses and the second the CPU. However, the 3rd release of OpenRISC (OR1200v3) will fail the CPU test. It's possible to skip the self-test, but you will probably run into problems while debugging OR1200v3 anyway.

Option 3: For this solution, a second JTAG cable is necessary. Furthermore, the generic JTAG tap has to be used instead of the one available on the FPGA (“jtag” core instead of “xilinx_internal_jtag”). That is done by uncommenting “`define GENERIC_TAP” and commenting out “`define FPGA_TAP”. That also requires free FPGA pins available as board pins, that will be connected to the JTAG cable. The FPGA pins have to be bound to the SoC by the definition of a constraint file (e.g. ucf file under Xilinx).

Example: “minsoc/rtl/verilog/minsoc_defines.v”:

//
// TAP selection
//
`define GENERIC_TAP
//`define FPGA_TAP

“minsoc/backend/spartan3a_dsp_kit.ucf”:

###########################
##
## JTAG
##
net "jtag_tms" loc = "aa23";                                        #SAM D0
net "jtag_tdi" loc = "u20";                                         #SAM D2
net "jtag_tdo" loc = "aa25";                                        #SAM D4
net "jtag_tck" loc = "u18" | CLOCK_DEDICATED_ROUTE = FALSE;         #SAM D6
net "jtag_gnd" loc = "y23";                                         #SAM D8
net "jtag_vref" loc = "t20";                                        #SAM D10
###########################

Problems Archive

I have problems compiling the adv_jtag_bridge, what is going on?

Answer: If you set in Makefile SUPPORT_PARALLEL_CABLES to true, you will need libioperm under Cygwin, for Linux this option is standard.

Under Cygwin: run Cygwin setup.exe and select “libioperm”

If you set in Makefile SUPPORT_USB_CABLES and SUPPORT_FTDI_CABLES to true, you need libusb and libftdi:
Under Linux: install libusb (http://www.libusb.org/) and libftdi (http://www.intra2net.com/en/developer/libftdi/)
Under Debian based distributions: sudo apt-get install libusb-dev libftdi-dev
Under Cygwin: run Cygwin setup.exe and select “libusb-win32” and install libftdi from: http://www.intra2net.com/en/developer/libftdi/

Adv_jtag_bridge does not connect to my cable, why?

Answer: You may be using the wrong cable driver, either you are selecting the wrong cable (xpc3, xess, usbblaster, xpc_usb, ft2232, ft245), or you are using the wrong implementation for your cable. Wrong driver selection occurs especially for Altera USBBlasters. They have two different implementations, a libftdi-based driver (“ft245”) and a libusb-based driver (“usbblaster”). Both should be equally fast at this point. The “usbblaster” driver is older, and considered slightly more stable. But, some users report errors when using the “usbblaster” driver with their USB-Blaster cables, errors which do not occur when using the “ft245” driver.

You can solve the wrong cable selection by selecting the right cable. Remember that to have both of the USB-Blaster compatible drivers, you'll need to enable both libUSB and libFTDI drivers in the Makefile.

Example 1: 'Failed to find USB-Blaster'

Answer: Nathan Yawn: It's possible that libUSB enumerated all USB devices, but did not find one with the manufacturer / device ID combo it was looking for (09FB:6001). If libUSB cannot find your cable, adv_jtag_bridge cannot use it.

If you're using windows/cygwin, make sure you have a libUSB filter installed for the USBBlaster, then run the libUSB test program and see what devices it shows. If it shows a USBBlaster with a different ID, then you can change the ID in cable_usbblaster.c to match. If it shows nothing, then you need to set up libUSB correctly.

If you're using Linux, then I think “lsusb” will show all the USB devices in the system. Again, look for a USBBlaster and see if it's ID matches.

Related discussion: http://opencores.org/forum,OpenRISC,0,3954

Example 2: xpc_usb problem

Note: Further information about cables can be found under “rtl/verilog/adv_debug_sys/Software/adv_jtag_bridge/doc/adv_jtag_bridge.pdf”

Adv_jtag_bridge does not enumerate my device, why?

Example:

adv_jtag_bridge xpc_usb
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.

Answer: What occurs here is that the adv_jtag_bridge does not know which protocol the target chip uses. You have two options:

  1. That is generally solved by copying the bsdl files into your home directory. In this special case the FPGA chip is the third in the chain, in those cases the bsdl file for the two previous chips are also required for the automatic enumeration. So copying the respective bsdl files for the two remaining chips solves the issue.

    Note: Please, use the -b <directory> parameter of adv_jtag_bridge to indicate the directory where you put the bsdl files. The home directory should be automatically recognized, but I have seen cases where it was not.
  2. You input 3 configuration parameters besides of the cable type instead of relying on the bsdl files, for instance “adv_jtag_bridge.exe -x2 -l 0:4 -l 1:4 -l 2:6 -c 0x02 -t xpc3”. The parameter 'x' informs the device index in the chain, 2 in this example. The parameter 'l' informs first again the indexes of every chain chip '0', '1' and '2' and then the bit width of their chain commands, in this case '4', '4' and '6', you need to find out what is command length for every chip (using its bsdl file for example). Then you need to find out (through bsdl file for instance) what is the USER1 command of your FPGA chip, xc3s500e_fg320.bsd:612: “USER1” (000010),” Finally, -c informs the USER1 command we just picked out from the bsdl file, it is given in binary format so “2'b10” corresponds to 2 or 0x02 for 6 bit width.

Adv_jtag_bridge self test fails?

SoC flow mistakes:

Example 1: CPU cannot be stalled

Answer: That occurs because the generated MinSoC bitfile has not been uploaded to the FPGA, Synthesis step 6.

Example 2: SRAM test fails:

*** 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.

Nathan Yawn: “It's possible to get this error with a random stream of 1's and 0's, but unlikely. In this case, it's most likely that the debug unit on the target hardware is actually operating properly, but the Wishbone is not. The last time I saw this, it was a clocking issue - the debug unit hardware receives its clock from the JTAG cable, which is why it was working. But the system clock to the Wishbone hadn't been connected, so there was no bus clock. This caused an error the first time the debug unit tried to write to the bus.

Check your clock and reset inputs, make sure they are connected, and have the correct polarity.”

Note: Sometimes this occurs because people forget about step 5 of Synthesis, which is an advice to include the user constraint for system pinout to the project in the project manager (Quartus or ISE).

Known issues:

Example 1: The jtag chain enumerates correctly, the SRAM test completes successfully, but the CPU test fails with the following results:

Testing CPU0 (or1k) - writing instructions
Setting up CPU0
Starting CPU0!
Read npc = 00000010 ppc = 00000028 r1 = 00000005
Expected npc = 00000010 ppc = 00000028 r1 = 00000005
Read npc = 00000028 ppc = 00000028 r1 = 00000008
Expected npc = 00000010 ppc = 00000028 r1 = 00000008
Read npc = 00000024 ppc = 00000020 r1 = 0000000b
Expected npc = 00000028 ppc = 00000024 r1 = 0000000b
Read npc = 00000020 ppc = 00000020 r1 = 00000018
Expected npc = 00000024 ppc = 00000020 r1 = 00000018
Read npc = 0000001c ppc = 00000018 r1 = 00000031
Expected npc = 00000020 ppc = 0000001c r1 = 00000031
Read npc = 00000020 ppc = 0000001c r1 = 00000032
Expected npc = 00000024 ppc = 00000020 r1 = 00000032
Read npc = 00000010 ppc = 00000028 r1 = 00000063
Expected npc = 00000014 ppc = 00000010 r1 = 00000063
Read npc = 00000010 ppc = 00000028 r1 = 00000063
Expected npc = 00000028 ppc = 00000024 r1 = 00000065
Read npc = 00000010 ppc = 00000028 r1 = 00000094
Expected npc = 00000010 ppc = 00000028 r1 = 000000c9
result = deaddef0
Self-test FAILED *** Bailing out!

Answer: I have the same problem here, do not start adv_jtag_bridge with the “-t” option.

Nathan Yawn: “Yes, there appears to be some incompatibility with the OR1200v3 and the self-test that the Advanced Debug System uses. Since the self-test hasn't changed any, there are two possibilities:

  1. The self-test, which was written many years ago for jp2/OR1200v1, depends on some sort of non-spec behavior of the OR1200, which has been 'fixed' in OR1200v3.
  2. The OR1200v3 is broken.

I haven't taken the time to figure out which it is, and at this point I'm not sure I care to. I'll try again once the new OR1200 has stabilized.

Warning: even if you disable the self-test, you'll still have problems with ADS and OR1200v3. When I've tried it, the system (repeatably) stops responding the third time I do a stepi. YMMV.”

Related discussion: http://opencores.org/forum,OpenRISC,0,3861

Example 2:

[root@localhost run]# ./start_server
Enumerating JTAG chain...
Devices on JTAG chain:
Index Name
ID Code
IR Length
----------------------------------------------------------------
0:
(unknown)
0x149511C3
-1
Target device 0, JTAG ID = 0x149511c3
Using command-line debug command 0x8
*** Doing self-test ***
Stall or1k - CPU(s) stalled.
SRAM test:
expected 11112222, read 3211112222
expected 33334444, read 3233334444
expected 55556666, read 3255556666
expected 77778888, read 3277778888
expected 9999aaaa, read 329999aaaa
expected bbbbcccc, read 32bbbbcccc
expected ddddeeee, read 32ddddeeee
expected ffff0000, read 32ffff0000
expected dedababa, read 32dedababa
SRAM test failed!!!
Testing CPU0 (or1k) - writing instructions
Setting up CPU0
Starting CPU0!
Read
npc = 3200000010 ppc = 00000028 r1 = 00000005
Expected npc = 00000010 ppc = 00000028 r1 = 00000005
Read
npc = 3200000010 ppc = 00000028 r1 = 00000008
Expected npc = 00000010 ppc = 00000028 r1 = 00000008
Read
npc = 3200000028 ppc = 00000024 r1 = 0000000b
Expected npc = 00000028 ppc = 00000024 r1 = 0000000b
Read
npc = 3200000024 ppc = 00000020 r1 = 00000018
Expected npc = 00000024 ppc = 00000020 r1 = 00000018
Read
npc = 3200000020 ppc = 0000001c r1 = 00000031
Expected npc = 00000020 ppc = 0000001c r1 = 00000031
Read
npc = 3200000024 ppc = 00000020 r1 = 00000032
Expected npc = 00000024 ppc = 00000020 r1 = 00000032
Read
npc = 3200000014 ppc = 00000010 r1 = 00000063
Expected npc = 00000014 ppc = 00000010 r1 = 00000063
Read
npc = 3200000028 ppc = 00000024 r1 = 00000065
Expected npc = 00000028 ppc = 00000024 r1 = 00000065
Read
npc = 3200000010 ppc = 00000028 r1 = 000000c9
Expected npc = 00000010 ppc = 00000028 r1 = 000000c9
result = 1c2deaddead
Self-test FAILED *** Bailing out!

Answer: Edit the start_server file, remove the -t option. This will skip the tests, hopefully everything else will work out fine. If you take a look the error is about having longer results than expected: expected 11112222, read 3211112222

I suppose your system is 64 bits. That's an issue with the adv_jtag_bridge as far as I can tell. I already reported it to Nathan Yawn. That's the creator of the Advanced Debug System (adv_jtag_bridge). For now it hasn't been corrected.

Otherwise, if you use a 32 bit system, it will work flawlessly.

GDB reports “Value being assigned to is no longer active.”, what happened?

Example:

(gdb) set $pc=0x100
Value being assigned to is no longer active.

Answer: The adv_jtag_bridge connect the debug system to GDB, the GNU debugger. But the versions 6.8 and 7.2 of GDB have some issues, which have to be corrected before use. To do so, the adv_jtag_bridge software includes a patch for GDB 6.8. Follow this guide to install a patched GDB 6.8.

Nathan Yawn: “GDB 6.8 has a bug which prevents it from working when no stack frame is present (such as at start-up on a bare-metal debugger, such as this one). A simple patch applied to GDB will work around the problem (a general solution is not yet available). This patch can be found in the Patches/GDB6.8/ directory.”

Related discussions:

Adv_jtag_bridge “Ignoring packet error, continuing... “ problem:

Answer: Nathan Yawn: “Ignoring packet error, continuing” means that GDB is timing out waiting for a response from a packet. In adv_jtag_bridge, rsp-server.c, set GDB_BUF_MAX back to it's original value of ((NUM_REGS) * 8 + 1). Smaller packets, done faster, GDB won't have to wait as long. Then, be patient. Things happen very slowly in simulation. Minutes, not seconds.”

Note: same is true for xpc_usb and ftdi usbblaster, it seems.

Static solution:

Nathan Yawn: “In adv_jtag_bridge, open rsp-server.c in a text editor and change the GDB_BUF_MAX back to its earlier value of ((NUM_REGS) * 8 + 1).”

Furthermore, ignore the “Ignoring packet error, continuing…”, it might take time to load depending on the cable.

Dynamic solution:

AhmedHMSoliman: “Use the following command before any other command in gdb to set the remote timeout at the first place.

set remotetimeout 10

and you can make sure time out was set to 10 seconds by using the following gdb command:

show remotetimeout

after that connect to remote target in the ordinary fashion:

target remote :9999

Furthermore, ignore the “Ignoring packet error, continuing…”, it might take time to load depending on the cable.

Related discussions:

Cannot step through instructions after breakpoints, what to do?

Answer: Nathan Yawn: “This is a bug in the current versions of the OR1200 CPU (v3). The current version (SVN rev. 388) has a bug related to the hardware single-step function. The maintainers have improved the behavior some, but it's still a problem.

I recommend you checkout an older tag of the OR1200, and use that. Unless there's something in the OR1200v3 you really need, the OR1200v1 will work just fine, and it doesn't have the single-step bug.”

Related discussion: http://opencores.org/forum,OpenRISC,0,3948

Tweaks

I'm running adv_jtag_bridge under Linux. How do I use adv_jtag_bridge with xpc3 or xess cables in non-privileged mode?

Answer: This has been updated in the Advanced Debug System version 3.0.0 and newer, try upgrading to a newer version. For versions prior to 3.0.0, the adv_jtag_bridge accesses the parallel port physical memory directly. The advantage of that code is that it is portable under Linux and Cygwin equally. However, the code cannot be run by a non-privileged user on Linux. If you must run an older version of adv_jtag_bridge, you have to replace the “cable_parallel.c” file from adv_jtag_bridge with the one provided by MinSoC under “minsoc/utils”. Use the file in the MinSoC 1.0 release branch, as this file was removed from the MinSoC SVN repository once non-priviledged user support was merged into the mainline adv_jtag_bridge.

cp minsoc/utils/cable_parallel.c
minsoc/rtl/verilog/adv_debug_sys/Software/adv_jtag_bridge/cable_parallel.c
cd minsod/rtl/verilog/adv_debug_sys/Software/adv_jtag_bridge
make clean
make
sudo make install

Now you can run the older version of adv_jtag_bridge for xpc3 and xess without issuing the sudo command or being root.

My FT2232 cable doesn't work with adv_jtag_bridge

Answer: Some JTAG cables have additional buffer between the chip and the pins. There is an extra line: output-enable that needs to be driven. AMONTEC - compatible ARM JTAG cables have a line called JTAG_OE_N, located at ADBUS4. To enable the buffer, a small change in the code is required.

  1. open cable_ft2232.c file
  2. find cable_ftdi_init() function
  3. change buf[2] = 0x0b to 0x1b
  4. rebuild adv_jtag_bridge

Related discussion: http://antmicro.com/blog/2011/08/support-for-amontec-compatible-jtag-cables-in-advanced-debug-system/

UPDATE: This change has been merged into the adv_jtag_bridge mainline as of version 3.0.0, no modifications should be necessary when using this version or newer.

Failures of adv_jtag_bridge on Win7 64-bit targeting Altera DE2_115 with USB-Blaster/FT245 cables

Work-around: Getting the debug chain working with this combo can be troubling. While I have not found the core reason(s) for failures of adv_jtag_bridge when targeting the DE2_115 under Win 7 (64-bit), I have found a means to make it work most of the time.

First the setup:

1) Everything is setup according to the guidance given in the MinSoc dev and porting documentation.

2) Altera dev tools installed - we are after the JTAG Debugger tool that can be ran from Quartus.

3) Windows drivers:

  • The Altera USB Blaster drivers: These are basically an FT2xx (e.g. FT245) set of drivers. Make sure these are installed first.
  • Download libusb-win32-bin-1.2.5.0 from http://sourceforge.net/projects/libusb-win32 and un-zip the download.
  • libusb-win32: This package really offers adv_jtag_bridge two approaches to “talking” out over USB to the DE2 – a low level USB driver which can’t co-exist with the Altera’s USB Blaster USB Driver, thus disallowing use of those tools. Or a windows “filter driver” which can be installed on top of the installed Altera USB Blaster driver – allowing co-existence. Co-existence is the key to this hack. Use the filter driver control app, install-filter-win.exe, under <libusb-win32-bin-1.2.5.0 install dir>\bin\amd64 to install the filter driver over the Altera device driver.

Now we have the ability to mix Altera tools with the MinSoc’s build and adv_jtag_bridge based debug environment.

The key is to run Altera’s JTAG Debugger Tool’s (under Quartus’ Tools menu) “JTAG Integrity” and “IDCODE Iteration” tests when adv_jtag_bridge JTAG failures are occuring. For whatever reason this seems to get the USB Blaster stack and path in a state that adv_jtag_bridge seems to be ok with (most of the time).

Run adv_jtag_bridge with either the “usbblaster” or “ft245” cable options. Both have worked for me.

I have found that the first time or two that I run adv_jtag_bridge after the Altera JTAG Tests, it often fails. But try it a few times. In my case it starts running after one or two attempts and then seems to be fine with subsequent runs of adv_jtag_bridge until the FPGA is configured again. Most times I find that I have to run the JTAG Tests to get things in working order again.

I know this is really ugly but I have found no better way – pending a fix to the, yet undiscovered, root cause.

Related discussion: http://opencores.org/forum,OpenRISC,0,4671

advanced_jtag_bridge_faq.txt · Last modified: 2012/11/21 00:09 by Raul Fajardo