Flashing the Bus Blaster's CPLD buffer with OpenOCD
Flashing the Bus Blaster JTAG adapter’s CPLD buffer with OpenOCD
Recently an unfortunate incident involving 20V and a slipped probe resulted in a small plume of smoke rising from my Bus Blaster, followed by the smell of burnt electronics. After examining the wreckage, it seemed likely that the CPLD took most, if not all, of the damage. Not wanting to wait another month for Seeed to send a whole new device, I ordered some XC2C32A CPLD’s and replaced the burnt part. This, however, requires that the new part if FLASHed with the appropriate buffer logic. Below I describe how this can be accomplished using OpenOCD.
With sufficiently recent OpenOCD releases (
ae806d8f4, included in the 0.8.0 release), this process is much simpler than it used to be as the package now ships with a board file for the Bus Blaster1. Simply download the desired SVF and run,
$ openocd -f board/dp_busblaster_v3.cfg -c "adapter_khz 1000; init; svf <path_to_svf>; shutdown"
This one-liner is due to
#openocd on Freenode (a lovely place to be if you have OpenOCD-related questions). Below the old procedure is reproduced for those not fortunate enough to have a recent OpenOCD installation.
The Bus Blaster’s documentation provides instructions for reflashing the CPLD with
urjag. Sadly, urJTAG refused to acknowledge the existence of the device, despite having gone through USB enumeration. Having recalled having similar problems while trying to use urJTAG in the past, I set out to use openocd instead. I was pleasantly surprised by how easy this was.
First, we’ll need to define an interface script to configure openocd’s
ftdi driver to use the second MPSSE channel, to which the CPLD is attached. For this I started with the
openocd/tcl/interface/ftdi/dp_busblaster.cfg and added the appropriate
ftdi_channel directive (I intend on proposing this for merge upstream),
interface ftdi ftdi_device_desc "Dual RS232-HS" ftdi_vid_pid 0x0403 0x6010 ftdi_channel 1 ftdi_layout_init 0x0c08 0x0f1b ftdi_layout_signal nTRST -data 0x0100 -noe 0x0400 ftdi_layout_signal nSRST -data 0x0200 -noe 0x0800 adapter_khz 1000
Starting openocd things don’t look too promising but we persevere nevertheless,
$ openocd -f bb-cpld.cfg Open On-Chip Debugger 0.8.0-dev-00043-gf550277 (2013-06-26-19:43) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' adapter speed: 1000 kHz Info : clock speed 1000 kHz Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!! Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x06e1c093 ..." Warn : AUTO auto0.tap - use "... -irlen 2" Error: IR capture error at bit 2, saw 0x3FFFFFFFFFFFFF05 not 0x...3 Warn : Bypassing JTAG setup events due to errors Warn : gdb services need one or more targets defined
nc, we attempt to run the SVF for the JTAGkey buffer,
$ nc localhost 4444 Open On-Chip Debugger > svf BBv2-JTAGkey-v1.4-verilog.svf.txt ... Time used: 0m0s767ms svf file programmed successfully for 579 commands
Well, that doesn’t look so bad and indeed attempting to debug a target works as expected. Yay!
At first glance, the filename
board/dp_busblaster_v3.cfgis a bit confusing as there is nothing to directly suggest that this will flash the buffer instead of the target device. However, if we look more carefully we notice that this is a board file, not to be confused with
interface/ftdi/dp_busblaster.cfg, the interface file describing the Bus Blaster.
In fact, if we examine the board file, we’ll notice that it simply
source’s the interface file, sets the
ftdi_channeland defines the TAP parameters for the buffer CPLD.↩