If I have the cpld configured with jtagkey logic, is it possible to use the BBv2 for serial IO with a "normal" serial communication program?
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.
It would be possible to make a new buffer that gave access to the RX/TX pins.
[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!
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 hope the JTAG pins on the CoolRunner can handle abuse, as it looks like both channels of the ft2232 default to RS232 async serial.
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 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
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.
This might be possible. For example an unused pin on the FT2232->CPLD connection could go low when the JTAG interface is active and switch to JTAGkey mode. 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. Given the number of apps that we are compatible with, I can't think of a creative way to do it automatically (detect the mode from CPLD) without an extra pin.
Another thing could be a jumper on the breakout area puts it in serial pass-though mode. That is how the self-test firmware works. It's not automatic, but it is a sure thing. You could even probably solder a slide switch on the breakout pins to change modes.
[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.