One day when playing with the CPLD board I accidentally shorted out two pins on the on-board FT2232 and – unfortunately – the magic smoke escaped! It was very clear that the FT2232 failed because it got very warm when plugging in the USB cable. Luckily the dev kit includes a 0.1″ header landing to connect an external JTAG probe.

Wanting to get a Dangerous Prototypes Bus Blaster JTAG programmer anyway, this was the perfect excuse.

This entry was posted
on Wednesday, January 29th, 2014 at 1:00 pm and is filed under Bus Blaster, CPLD.
You can follow any responses to this entry through the RSS 2.0 feed.
You can skip to the end and leave a response. Pinging is currently not allowed.

2 Responses to “Using the Bus Blaster to program Lattice CPLDs”

I own a couple BPs and have used it for the same thing, however you have to convert to SWF and that disturbs your workflow if you are doing iterative development. A cheaper option than BP is to get another Lattice breakout board and use it as a programmer. You can put the CPLD in JTAGENB mode and pass through the JTAG signals from FTDI to any pin on the PLD at any voltage level. A $30 alternative to the $35 BP and $190 Lattice programmer that still works with built-in IDE tools.

From the link:
“I opened the demo application provided by Lattice and after generating the bitstream I programmed it [via the BBv3] using the Lattice Diamond software in the same way I would have done it if the dev kit’s FT2232 was still working.”

The Bus Blaster (not Pirate) is an FT2232H, just like the on-board “programmer” on the dev board. The BB also has a CPLD which can be reprogrammed to setup and buffer the FT2232H->JTAG pin mapping anyway you need, mainly for emulating other FT2232H-based JTAG programmers. The link describes setting the CPLD to just pass the FT2232H pins straight-through to the JTAG header to emulate the dev-board’s on-board FT2232H.

It boils down to basically replacing the fried FT2232H with another one on a daughter board, connected to the same JTAG traces (via the JTAG header) that the fried FT2232H is connected to. Except the Bus Blaster is much more flexible and self-contained if you want to do other things with it later.

The Bus Blaster also provides some amount of access to the FT2232H’s second channel (I don’t recall how much of it is hardwired for reprogramming the BB’s own CPLD), which Lattice just left unused in the on-board programmer’s chip. Lattice does a really nice job of leaving the power rails very flexibly reconfigurable on their dev boards, which is a common gotcha on dev boards, but then they forgot to break out the FT2232H’s unused IO, or at the very least have a pair of jumpered traces wiring it up to the CPLD for a UART.