Background: I've been porting MinSoc to the Altera DE2_115 board the last few days. I stuck some temp "probes" down in the decoder and it seems to be active. I'm now at the point where I'm trying to get sw loaded into the core. So I'm attempting to bring up the adv_jtag_bridge. I'm doing all this on Win7/64bit.

I've tried several command line arrangements like:
"adv_jtag_bridge -b ./bsdl_files usbblaster"

but still get:

"Failed to find USB-Blaster with VID 0x9FB, PID 0x6001
Failed to initialize cable 'usbblaster', aborting."

I've verified via device manager that these are the VID and PID are right.

I've debugged into the app enough to know that those PID/VIDs are not matching down in usbblaster_enumerate_bus.

So the question is (before I dig into this much more) what is the correct usb support library? I ask because reading the doc and the source comments, I'm not 100% sure.

Also has anyone else seen problems like this? Thoughts?

I'm also very new to opencores, so I'm pretty sure I'm missing something basic.

Thanks,

Rich

Hi Rich,

you should need libftdi and libusb-0.1. Take a look at Advanced Debug System project page under Dependencies:
http://opencores.org/project,adv_debug_sys

Change adv_jtag_bridge to print out the values of the VID and PID to see what could be going on.

Raul

I never actually had a successful test using adv_jtag_bridge under Win7/64, any sort of USB access locked up my machine so hard I had to reboot. I'm guessing that a newer version of libusb for Win7/64 has been released since the last time I tried.

You need to have libusb 0.1 installed. This used to be the only version available for windows, but it's possible that version 1.0 has been ported now as well. The two versions have different APIs. If you have to use 1.0, make sure you also install the compatibility layer for 0.1 (at least, that's how it works in Linux, not sure if the windows version works the same way or not).

Last I checked, libusb came with a test application that enumerated all of the USB devices it found. Plug in your cable and run the test app. If it doesn't find your cable, then the problem is in the libusb setup.

You do not need libftdi unless the usbblaster driver fails, and you want to try the ft245 driver (which also works with USB-Blaster cables). If you don't have libftdi installed, make sure to change your makefile appropriately (if you're using a pre-3.0 version of the ADS) or re-run configure to disable libftdi support (for ADS 3.0).

Short update: MinSoc is running on the DE2_115 - but my board seems to have a bad RS232 RxD path. I'm going to push to include the vir uart because of this - any know issues with this?

Indeed the usb library/driver situation is messy on win64. I do have things cobbled together and have used both usbblaster and ft245 with the server. FWIW I went the filter driver path (libusb over the FT/Altera low level driver. This allows using the Altera tools side-by-side with the server. Not driver switching needed.

There are lots of flacky issues I've seen with the server->libusb with usbblaster/ft245 - kinda "smells" like an un-inited variable some place. Will keep digging on this as I move along.

Thanks very for your guys' help.

And Happy New Years!

Rich

I assume you mean the JTAG serial port that's part of the adv_dbg_if core? It should work with minsoc, I've actually set that up in the last week - just make sure you have a matching set of #defines between the hardware core and the adv_jtag_bridge.

There are two caveats with the JSP. First, I've never had a report of anyone successfully using the interrupt/IRQ functionality (not that I have any bug reports either). Second, one user has reported problems transferring data host->SoC, which I suspect is related to the relative clock speeds of the JTAG cable and and WishBone (JTAG is too fast). This is actually the bug I'm looking at right now.



Could you add an entry to the minsoc wiki describing the system you cobbled together? You're probably not the only one who's run into this...



Hm, usbblaster and ft245 are completely separate drivers (though the high-speed transfer code was a copy/paste between the two). Let me know if you find anything, I'll be happy to merge a fix into the SVN version. Also, I don't how old your version of adv_jtag_bridge is, or if you're using BSDL files, but at one point I checked in fixes for multiple off-by-1 errors in the BSDL parsing code which could have overwritten other parts of the heap or stack, causing flaky problems. You may want to see if a newer version of adv_jtag_bridge helps.

Inline...



Yes - I did mean the JTAG UART. I assume that beyond changing defines in hw and adv_jtag_bridge, I have to wire the jsp up thru the wb slave i/f of adbg_wb_module - in minsoc_top - right? I saw no other way for address decode to happen but I'm very new to this environment...

I'm heading down the path of using target 6 for the jsp - and wiring it up as uart is wired in minsoc_top. This should make the jsp regs map to memory address 0x9E000000+ I think - but I'm seeing "SIGBUS, Bus error" when any of those memory locations are touched by the jsp init code I've added off of main(). Not sure what's going on but will keep digging into this.

Has target 6 been used before?



I will do that. I'm actually trying to nail down a more repeatable pattern and will capture that into the Wiki. The work-around does entail running the Altera JTAG Chain Debugger's tests. It does seem the issue has to do with Altera's "usb-blaster" logic in the MAX II (between the FT245 and the FPGA). But once whatever that state is, it seems to be cleared with the jtag debugger tests and then the bridge will work over and over - most of the time - even across multiple MinSoc bitstream loads - and in fact windows driver unloads/loads. Not always however. I'll keep messing with this. I could dig a bit better if I understood better how the values written into the FT245 end up driving the JTAG bus (inc timing kinds of things) - more of a MAX II+Altera blaster firmware design question. Any pointers to documentation or your experience in this space would be helpful.



Bad use of overloaded terms on my part. I was making ref to windows *drivers* not your driver code in the bridge. I am wondering if there is some unknown command being sent to the MAX II resident firmware by the Altera JTAG Tester. Any detailed specs on the usbblaster design?

Per your RxD interrupt point: Let me report that I have been able to verify that RxD interrupts are working on the jsp uart in my use case. No heavy duty tests but they seem to work fine.

Thanks,

Rich

You are correct, after changing the #defines in adbg_defines.v, you'll need to add the JSP wishbone signals to the declaration of the adv_dbg_if in minsoc_top.v. I have no idea if target 6 will work, I've never tried it.

To use the JSP, I actually un-defined the 16550 UART in minsoc_defines.v, and used the target the UART had been using (this also requires commenting out the code that holds some of those signals to a constant value when UART is not defined - come to think of it, could this be the problem with target 6? Some input lines being held at a constant state?)

I'm afraid I don't know anything about the CPLD in the USB-Blaster. I wrote the 'usbblaster' driver based on two sources. These two projects are for Cypress FX2 firmware that emulates a USB-Blaster (without using a CPLD, I think). Since my hardware uses the second one, that's what I tested against (I also borrowed a real Altera cable once to make sure everything worked). Here are the links:

http://ixo-jtag.sourceforge.net/
http://fpga4u.epfl.ch/wiki/FX2

Thanks for the report on success with the interrupts, it's always good to know my code works for someone other than me...

Target 6 has no problems. I tested it with JTAG UART now, no issues. Interrupt is also working.

It took me some time to realize that telnet only really sends the data when you type enter. I was there, inputing a, b, c and expecting the interrupt outcome while nothing happened. A enter after each letter is required.

Raul