Flashing the Bus Blaster's CPLD buffer with OpenOCD

| tagged with
  • openocd
  • busblaster
  • jtag
  • cpld

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.

New Approach

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 PaulFertser of #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.

Old OpenOCD

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

Connecting with 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!

  1. At first glance, the filename board/dp_busblaster_v3.cfg is 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_channel and defines the TAP parameters for the buffer CPLD.↩︎