Flashing KT-Link buffer to the Bus Blaster v3
Today I flashed the KT-Link compatible buffer onto my Bus Blaster JTAG adapter from Dangerous Prototypes. DP and the Bus Blaster seem to have gone a bit quiet of late (it's a "mature" design), and there wasn't quite as much documentation on how to flash the SWD-capable, KT-Link-compatible buffer into the Xilinx CPLD on the Bus Blaster v3 as I'd have liked.
I found Benjamin Gamari's instructions to work perfectly, but I'll reproduce the commands/process here for posterity and clarity, now that there are no patches required.
At the time of writing, it's coming up for 7 years since that article, and there is a lot to be said for the KT-Link buffer and SWD support in general, under OpenOCD. I can't find any of the rough edges Benjamin mentioned in his article, so perhaps time (and patches accepted) has healed them.
Step 1: Download the bitstream
The Verilog source is available from Ben Harris's repo, as well as a prebuilt SVF file. I opted not to build from source and flash the prebuilt SVF.
% wget https://github.com/bharrisau/busblaster/raw/master/synthesis/system.svf
Step 2: Flash the bitstream
Step 2.1: Background on the Bus Blaster
This sub-step is just me gushing for a couple of paragraphs, and is completely optional to read. Skip to 2.2 if you want to save us both the embarrassment.
The Bus Blaster is actually incredibly cleverly designed. More than I gave it credit for when I purchased it. At its heart, it's just a regular FTDI USB to JTAG (and other serial protocols...) chip breakout. Whack on a bus transceiver so you can translate between the FTDI's 3.3 V logic and whatever voltage the target uses (up to 3.3 V) and bish bash bosh you have a JTAG dongle.
After learning some lessons in version 1 of the adapter, the clever folks at DP placed a Xilinx CPLD on the board as the buffer/transceiver instead of hardwired logic. Not only this, they also used a dual-channel FT2232. This means they can dedicate a JTAG channel to the 20-pin target JTAG connector and still have a JTAG interface left over to plumb straight into the Xilinx CPLD itself. This allows for seamless field upgrades of the CPLD bitstream in order to fix bugs, and so on. This also allows for custom buffer logic to be flashed by the user in order to emulate any FTDI family JTAG adapter they want.
Step 2.2: Flash the thing
Modern builds of OpenOCD ship with the configuration files required to flash the buffer/CPLD on the Bus Blaster, as well as use it with the KT-Link-compatible buffer:
% # e.g. % pacman -Ql openocd | grep busblaster openocd-git /usr/share/openocd/scripts/board/dp_busblaster_v3.cfg openocd-git /usr/share/openocd/scripts/board/dp_busblaster_v4.cfg openocd-git /usr/share/openocd/scripts/interface/ftdi/dp_busblaster.cfg openocd-git /usr/share/openocd/scripts/interface/ftdi/dp_busblaster_kt-link.cfg
This means we can flash the bitstream straight in:
% openocd -f board/dp_busblaster_v3.cfg -c "adapter_khz 1000; init; svf system.svf; shutdown"
Step 3: Profit!
Connect to something that supports SWD and play with it.
My aim for the day was to debug a program running on an STM32F030 board.
% openocd -f interface/ftdi/dp_busblaster_kt-link.cfg -c "transport select swd" -f target/stm32f0x.cfg Open On-Chip Debugger 0.11.0+dev-00160-g936cff887-dirty (2021-05-22-14:24) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : FTDI SWD mode enabled swd Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : clock speed 1000 kHz Info : SWD DPIDR 0x0bb11477 Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints Error: stm32f0x.cpu—clearing lockup after double fault Polling target stm32f0x.cpu failed, trying to reexamine Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints Info : starting gdb server for stm32f0x.cpu on 3333 Info : Listening on port 3333 for gdb connections
Of course the adapter still works for regular JTAG if you don't explicitly select the SWD transport. My experience so far using SWD with OpenOCD and this adapter has only been positive. In my view there's no reason anyone should not be using the KT-Link-compatible buffer logic on their Bus Blaster in 2021.