[quote author="ian"]However, you would need to add that to every app that you use (OpenOCD, urJTAG, crossworks, etc, etc) or it might never switch to UART mode.[/quote]
I was hoping that there would be a transition on the ft2232's pins when it changed modes from rs232 to jtag - or that the real jtagkey hardware required initialization. If so, one cpld configuration would work with any program that supports the jtagkey.
I guess I'll just use an extra pin on jp2, or reprogram it as necessary.
[quote author="ian"]That's a good point. I find they are usually hi-Z unless the com port is open, but out of extra caution I will make a buffer that goes hi-z on the CPLD->FT2232 side when not enabled.[/quote]
So there's a known sequence the FT2232 output pins go through when switching to MPSSE/JTAG mode? I was wondering if there was, but wasn't sure how to find out.
I want to configure the cpld so that it is in "serial passthrough mode"[1] on powerup, and switches to JTAG mode when the ft2232 is reconfigured.
Now that I think about it, the JTAG pins must not be a problem since the ft2232 is marketed for apps with jtag on one channel and serial on the other.
Oh, I did finally find sink/source current info in the datasheets - just not where I was expecting it. However, neither device's datasheet says how many pins can be shorted, for how long, etc.
[1] all serial lines pass straight through to either the jtag header or to JP2
[quote author="ian"]Hi r250r - No, I don't think that will work. The buffer uses various control signals that would have to be set correctly, and I think the RX/TX are actually a different direction (input/output) than the JTAG signals on the same pins. [/quote]
You're right. It would be nice if they had used the same directions for both!
Quote
It would be possible to make a new buffer that gave access to the RX/TX pins.
Yes, I was thinking of doing that.
In the UCF, there are two pins that connect to the 2232 that aren't used. I was wondering about programming the cpld with logic that would allow either jtag mode or serial mode, configurable using one or both of those spare IOs.
If I do that, the IO directions will change. I want to make sure that both chips can handle short-circuited IO.
I cannot find anything about short-circuit tolerance, or even absolute maximum output current, for the CoolRunner-II. I looked at 4-5 different PDFs on xilinx.com.
The ft2232 datasheet doesn't seem to say anything either.
I hope the JTAG pins on the CoolRunner can handle abuse, as it looks like both channels of the ft2232 default to RS232 async serial.
I just tried the latest version of urJTAG (git 08e714ef68513) with libFTDI, and it works fine. Thanks for the bus blaster, and thanks to whoever fixed the issue as well!
I edited the original post to reflect the fact that this is fixed.
Looking at the output I guess you are using urJTAG on Linux with the libFTDI GPL drivers?
Yes, the GPL driver and 64-bit Debian (also tried 64-bit Ubuntu, same result).
Quote
Just to check - did you compile the latest SVN version without applying our patch? Our patch is no longer needed because it is included in the project.
I used the latest revision of urjtag, and no patches.
Quote
Would it be possible to test the FTDI drivers instead? You may have found a bug in our patch for GPL libFTDI support.
EDIT: this is fixed as of urjtag git revision 08e714ef68513
I got my BBv2 yesterday. I downloaded and compiled the latest version of urjtag.
If I try to autodetect, urjtag says my board is a flyswatter.
If I use the ft2232 driver, I get a warning that TDO seems to be stuck at 1. I get this no matter the interface, and also if I try to use the jtagkey driver (which I thought the board was supposed to come preconfigured for).
Quote
jtag> cable ft2232 vid=0x403 pid=0x6010 interface=2 Connected to libftdi driver. jtag> detect ../../../src/tap/discovery.c:117 urj_tap_detect_register_size() Warning: TDO seems to be stuck at 1 Error: (null):0 (null)() no error: jtag>
I've tried interface=0, =1, and =2 -- all with the same result. Urjtag has been acting strange - for example, the error above, and parameters seem to persist, which doesn't make sense to me:
Quote
jtag> cable ft2232 vid=0x403 pid=0x6010 interface=b Usage: cable DRIVER [DRIVER_OPTS] <snipped rest of usage message> Error: ../../../src/global/params.c:201 parse_param_lu() syntax: need unsigned int, not 'b' jtag> cable ft2232 vid=0x403 pid=0x6010 interface=1 Connected to libftdi driver. jtag> detect ../../../src/tap/discovery.c:117 urj_tap_detect_register_size() Warning: TDO seems to be stuck at 1 Error: ../../../src/global/params.c:201 parse_param_lu() no error: need unsigned int, not 'b' jtag>
So I'm not sure if urjtag is the problem or if it's something else.
One thing I noticed about my board is that the FTDI chip looks different than the one pictured at http://dangerousprototypes.com/docs/Bus ... ew#FT2232H . The last three letters of FTDI look like they cut deep into the package, instead of being on the surface. ?!