Dangerous Prototypes

Hi,

I was developing my own version of a JTAG programmer with the FT2232H as I saw this project here.

I liked the Idea with the CPLD very much and I'd love to play with CPLD's or FPGA's so I decided to adopt this idea.

I didn't want to wait for this project not because I need it fast but because I wanted to have a JTAG programmer which also breaks out the B-BUS of the FT2232H so I could do other things with it than only JTAG at a time.

Well, now I wanted to share my somewhat forked design with you :).

It did get a little bit crazy: I have the FT2232H and a XC2C64A (I want to play with it, so this is the slightly bigger version ^^). The CPLD is used as a buffer for the JTAG channel A of the FT2232H (support for a wide range of voltages :) ). It can be programmed via the JTAG channel B.

The connection JTAG channel B -> CPLD JTAG can be interrupted - there is a buffer in the middle which can be disabled by removing a jumper - so the full channel B can be used otherwise.

I like the overall setup because this now is somewhat of a USB -> Dual Serial Communication + FT2232H breakout board + XC2C64A breakout board + XC2C64A small development board ^^. You could even cut the pcb in two halfs and each one would work as a breakout board on its own ^^.

I attached the schematics and a quick&dirty version of the PCB (100mmx46mm in size). The design is done with KiCad.
If anyone is interested in the design files I can post them here.

Also it is completly untested ;) PCB's are expensive so I have to wait for some other PCB's before I can send them to the manufacturer.
Sadly I'm completly unsure about the buffer - I have no idea if it will work this way - I think it will but I know me :) I'm thinking about replacing it with four simple jumpers - then it will work :).

Regards,
Nils

Nice work getting all the pins to headers.

It looks like it has a lot of elements of our design, even the exact same (broken) TARGET_PRESENT circuit :)

It can be programmed via the JTAG channel B.

Be sure the connections are correct, and check out our patched urJTAG, nothing else currently programs on JTAG B as far as I know.

Also, I'm going to split this thread into a new topic after posting this, it doesn't belong here :)

[quote author="ian"]
Nice work getting all the pins to headers.
[/quote]

Thank you :)

[quote author="ian"]
It looks like it has a lot of elements of our design, even the exact same (broken) TARGET_PRESENT circuit :)
[/quote]

Hehe, typical moment of "I KNEW I should've done it by myself and don't just copy it" :D. Thanks for the hint.
Yeah to say it clearly, all stuff on the right side was more or less copied from your design and then modified - regarding the target_present circuit, I wasn't shure if I want to have it or not. But it in the end LEDs are great ;).

Since I don't know much about CPLDs I wanted to use a design which should work for the CPLD part.

The rest is the FT2232H connection described in the datasheet.

[quote author="ian"]
Be sure the connections are correct, and check out our patched urJTAG, nothing else currently programs on JTAG B as far as I know.

Also, I'm going to split this thread into a new topic after posting this, it doesn't belong here :)
[/quote]

Yup, I'm already very thankfull for the patch :).

Regards,
Nils

Hey Nils,

When not powered from the target side, the CPLD leaks 0.6volts, which is enough to half-light the LED. The TARGET_DETECT part is just useless, so I stripped it from the v2.a1 PCB. Check out also the TI reference design we based the BBv2 on - they have a different circuit, though I don't think it will work for the way I typically use JTAG debuggers (single patch wires).

In our 2.1 update we have a couple enhancements:
*Series resistors on the IO pins
*resistor and zener to protect the CPLD from target supply >3.3volts
*LED coming OUT from CPLD (for general indicator and experimentation)


Also, I think only TDO (CPLD->FT2232H) and CLK (FT2232->CPLD) need to be buffered to use all of port B. I think if these are disabled between the FT2232 and CPLD then all the other CPLD pins are hi-z (maybe pullup) and shouldn't cause issues to the normal JTAG B use.

[quote author="ian"]
Hey Nils,

When not powered from the target side, the CPLD leaks 0.6volts, which is enough to half-light the LED. The TARGET_DETECT part is just useless, so I stripped it from the v2.a1 PCB. Check out also the TI reference design we based the BBv2 on - they have a different circuit, though I don't think it will work for the way I typically use JTAG debuggers (single patch wires).
[/quote]

Hey Ian,

that sounds interesting. I will look into this. When I have a new design I will post it here. Hopefully I will be able to test it on a PCB in the near future ;).

[quote author="ian"]
Also, I think only TDO (CPLD->FT2232H) and CLK (FT2232->CPLD) need to be buffered to use all of port B. I think if these are disabled between the FT2232 and CPLD then all the other CPLD pins are hi-z (maybe pullup) and shouldn't cause issues to the normal JTAG B use.
[/quote]

That's a good hint, I wasn't shure about this. Although I'm still thinking about just using some jumpers instead of a buffer.

Thanks for the replies.

Nils

This is more or less along the lines of what I suggested to free the B port for UART. Glad to see others have the same thoughts. If I know Ian there will be more revisions. Hopefully all the best ideas will merge back together.

Nice to see another KiCAD user also.

If I know Ian there will be more revisions.

2.1 PCBs are in the mail, I hope to get it today :) Then after some user feedback on v2.0a We'll probably go to v3 with a couple updates:
*buffered UART B for sure-thing extra com port (which chip?)
*FT2232 clock to GCK pin on CPLD
*clean USB in the middle opposite the JTAG header type layout

I split the target present fix to this thread:
http://dangerousprototypes.com/forum/in ... pic=1706.0 (http://dangerousprototypes.com/forum/index.php?topic=1706.0)

[quote author="ian"]
*buffered UART B for sure-thing extra com port (which chip?)
[/quote]

Not sure if you are asking me a specific question or not.

Wow!  So many choices!  

How does this fork differ from the main USB Bus Blaster v2?  Or the UniJtag?

http://blog.tkjelectronics.dk/2010/12/t ... e-unijtag/ (http://blog.tkjelectronics.dk/2010/12/the-story-about-the-unijtag/)

@brian - it was just rhetorical, not sure what buffer solution to use yet.

@enliteneer - there are dozens of ft2232 programmers, it's probably the most common USB JTAG debug solution. Not much difference between them except the buffer chip and price.

I looked at the unijtag, but they make no mention of the buffer type (the only important part). From the video it looks like they use the same 2bit buffer we used for inputs, but for all channels, so the programmer is unable to disconnect from the target. That's just a guess though.

Hi,

I've done a new version of schematics and pcb. The pcb again is quick&dirty.

My changes are:
I wanted to support the hopefully-soon-coming SWD support in OpenOCD. Especialy I'm interested in the SWO/SWV feature of the STM32. There is one SWO mode in which the output is in UART style - so I connected the BBUS RX pin to the CPLD.
Also I wanted to have support for a 10-Pin JTAG connector I use in some of my boards - it has all signals + UART RX/TX so I needed a UART port here, too.

All these things are going through buffers so I can enable/disable them by jumpers.
Also I have connected all CPLD JTAG pins to buffers - if I disable it there is absolutely no connection between the CPLD and the FT2232 BBUS. It's more a thing of "I think this may be safer..." than of real need :).

The target_present circuit had to go because there were a pin on the CPLD that was not really needed...

I chose the 74AC125SC buffer because it is cheap (~0,22 Euro @ 100) and it has an enable pin for each of the four channels separatly which enables me to use it in both directions with different enable/disable signals.

I think I will soon buy a PCB of this version - then I'll report :).

Nils

Nice work. It looks like the PCB is smaller and cleaner than before.

Watch your clearance, it can be hard to solder right up next to a chip like some of the passives (sorry if you are already a master solderer). Also, I try never to run a trace between the pads of a SMD passive, I noticed a few places where traces go under caps and resistors. Advise optional - I just wanted to share a few thoughts :)

Thanks,

actually the PCB is the same size.

Yah I know the thing with the clearance. I'm currently into some sort of "it has to be small, it has to be small" thinking because I spent to much time in the lower zoom factors of KiCad ;). I lost the feeling for the real size so I'm really impressed by the small size everytime I see a printing on paper ^^.

Thanks for the advice. I will look into this and clean it up :).

By the way why don't you run traces between the pads of a SMD passive? I've done this a few times with 1206 parts and never had a problem on boards which I etched by myself. But maybe it was luck - I'm just doing hardware stuff for 4 or 5 months now ^^.

Nils

Hi,

it's been a long time but I just wanted to give an update.

I had the PCB for my forked BusBlaster laying around for some months now - I just didn't have to time, money and motivation to buy the needed parts and solder it together - my Signalyzer Lite worked well for me.

But now I have done it :)

It works very well, all pins are available on pin headers and all pins of the FT2232H are available on the CPLD. I wrote two BufferLogics in Verilog: KT-Link and JTAGkey - both work very well.

The KT-Link logic has support for the SWO channel of SWD. Since you already have a Verilog version of JTAGKey I just appended the Verilog version of the KT-Link.

I had some errors on the PCB: Two power pins of the CPLD are not connected to the corresponding net since KiCad doesn't connect the power symbol with a net if you just drop it onto the net line -.-. These are things I learned with my other projects so I would have done this in an other way ^^

Also I wouldn't route the PCB with the freerouting autorouter now. It results in ugly traces and you won't see errors like the above.

One other failure: I connected all **BUS pins of the FT2232H to the CPLD. The CPLD uses the BDBUS1 pin for SWO when programmed with the KT-Link firmware. Sadly the same pin is the JTAG TDI pin when programming the CPLD via the second FT2232H port (there's a buffer which enables the JTAG signals for the CPLD). So if you program the CPLD with the KT-Link firmware JTAG will not work for the CPLD.

I fixed this by connecting a free IO pin of the CPLD with the "JTAG enable" jumper and modifying the KT-Link firmware so it sets the CPLD pin connected to BDBUS1 to 1'bz. This fixes the problem.

Don't ask how long it did take for me to find that problem oO. I thought it would be a defect buffer or something and even replaced it one time oO.

I attached a picture of the PCB (yes, I didn't clean it ;) ). I like it because it is a breakout board for both of the two chips and also a JTAG debugger...

Nils

PS: I couldn't upload the KT-Link Verilog file: 'Extension *.v is not allowed'. You can find it here: http://http://git.dyster.net/?p=JTAGTool.git;a=blob;f=BufferLogic/KTLink/ktlink.v

---

Nice work, thank you for sharing. There are lots of great ideas there :) I have also been hard at work on Bus Blaster v3 with will have some similar features.