Forked Bus Blaster FT2232H + CPLD JTAG programmer

irrenhaus finished his forked Bus Blaster v2 design. Like the BBv2, this board has a FT2232 USB->JTAG chip and a CPLD buffer. It uses a bigger 100pin CPLD, with enough IO to connect to every pin of the FT2232. The extra connections are used to supports the SWO feature of the new 2-wire SWD JTAG protocol, the Bus Blaster v2 can’t do that.

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.

Supporting SWO isn’t that hard. The FT2232 has 2 serial/JTAG modules, most programmers just use one. KT-Link SWD design uses the second module to support the SWO debug option. An extra pin connection is all it takes.

The difficulty comes because we already use the second serial/JTAG module to program the logic into the CPLD. This awesome feature lets the Bus Blaster imitate just about any FT2232-based JTAG programmer with a simple USB upgrade. However for SWO we also need to use that module for normal IO too.

A buffer that selects between programming mode and normal mode is key to this design, and has slowed the development of Bus Blaster v3. Here’s irrenhaus’ experience:

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.

The current plan for Bus Blaster v3 is to use a 4066 as a bi-directional buffer between the FT2232 and CPLD IO pins, and a second 4066 (or 245) between the FT2232 and CPLD programming pins. Program or normal mode will be selected with a jumper.

You can get a Bus Blaster v2 for $34.95.

Join the Conversation

10 Comments

  1. Ian,
    They’ve done something similar to this
    with on single _tiny_ STG3693 on
    LatticeSemi’s “$29” MachXO2 Pico Board.

    When pins 3 and 10 of the G3693QTR are driven high,
    the four low bits of the FT2232’s ADBUS become “JTAG” signals.

    When pins 3 and 10 are driven low, they instead become “I2C” signals.

    You can see what they’ve done
    on sheet three of the schematics,
    which you can download from
    http://www.latticesemi.com/dynamic/index.cfm?fuseaction=view_documents&document_type=175&sloc=01-01-09-00-19&source=sidebar

    BCBill

  2. > The current plan for Bus Blaster v3 is to use a 4066 as a bi-directional buffer between the FT2232
    > and CPLD IO pins, and a second 4066 (or 245) between the FT2232 and CPLD programming pins.
    > Program or normal mode will be selected with a jumper.

    Please also consider selecting between normal operation and programming the CPLD by program and not only by jumper. This makes it much more easy to automate stuff. If you leave out the jumper altogether, you save one THT-part which is expensive in production.

    The FTDI chips all have multiple auxilary outputs called CBUS. They can be switched to different modes, like activity led and so on. But they can also be selected in the EEPROM to be user programmable i/o with low speed and a special commandset for io. You could switch between the two modes with the 4066 controlled by one of those CBUS pins.

    1. All great points, I would like to see it automated too. However, the Bus Blaster is compatible with a bunch of JTAG apps, and we have no way to control what many of them do with the lower CBUS pins. My concern would be flipping on programming mode when it is unwanted, with no way to override it. There may be a v3 with jumper, and later version with a well-tested automated switch.

      The through-hole parts aren’t a big concern because we already have to solder the PTH header, and many of our things are wave-soldered I guess and they do SMD and PTH parts at the same time (could be wrong about that, just want I was told).

      1. You can’t literally do SMD and PTH at the same time, at least not according to any house I’ve interviewed, but they’re compatible if your SMD and PTH parts are only on the top. SMD uses solder paste, PTH uses wave soldering. They might have a way to place both parts with the pick-and-place, but the SMD solder paste would need to be baked in an oven and the PTH would need to be wave-soldered. One key that I recall is that the per-part charge for PTH is maybe ten time greater than SMD. All of this is from very rough memory, though.

      2. I don’t think other programs accidently toggle the CBUS pins. Because you need an extra command in D2XX or libftdi to change them. And you can’t use them practically in any kind of JTAG setup because they are WAY to slow to toggle and there is no way to synchronise them with the regular io. But they are perfect for an application like this where you switch something once and then leave it that way for some time.

      3. Each buffer types uses different pins for the various reset inpus and outputs, as well as buffer enables (usually 3 or 4 of them). None currently use the lower 8 of the MPSSE2, that I know of, but there could be in the future.

        The reason we have to consider the v3 at all is that the new KTlink buffer needs an extra pin we currently use to program the CPLD on BBv2. I don’t want to have the same problem on a future design with a cool new features that happens to use the pin we chose for programming mode.

        Worse, since we clone so many manufacturer’s programmers in one open source device, I don’t want anyone to get the wise idea they can break compatibility by twiddling that pin ;)

  3. You might consider discrete FET parts instead of a couple of 4066 chips. Depending upon the size, you could make the routing simpler and use smaller area.

    robberknight, there are SMD jumper pins available, and I assume those would not cost extra like a through-hole part. Haven’t used them myself, yet, but I’m strongly considering them for JTAG ports and other necessary headers.

    1. Yes, I know. Just one friday my manufacturer told me about just another technique: Through-hole-reflow or Pin-in-paste.

      There are classic dip switches available in SMT also.

      This may fix the extra cost of adding a THT part and replaces them with a SMT part. But it does not allow to automate reprogramming the CPLD just from software.

Leave a comment

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.