Skip to main content
Topic: Bus Blaster testing (Read 2575 times) previous topic - next topic

Bus Blaster testing

Did some more testing today, looks like everything is going to work 'out of the box' after all. Will do some real world test and post screenshots tomorrow.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster testing

Reply #1

Looks like we won't have the same issues as with the buspirate (avrdude)

Re: Bus Blaster testing

Reply #2
I updated the wiki with a bunch of testing stuff:
*Logic captures from the chain scan
*OpenOCD config files that work with the Bus Blaster
*Screen captures

Current status:
OpenOCD sees the programmer and attempts the JTAG device chain scan twice. I can see the output at my target on the logic analyzer (see the wiki). The target does not respond.

I loaded a Bus Pirate with an old version of the firmware (v4.5) that still has the JTAG terminal mode. I did a chain scan macro and saw the two Xilinx FPGAs on my target board (a digident dev board). I know the devices are alive an responding.

The chain scan used by the Bus Pirate looks different than the one used by OpenOCD. I'm not sure exactly what OpenOCD is doing, and if maybe there is a hardware problem with it. Tomorrow I will try OpenOCD with the Bus Pirate under Linux and see if it work/doesn't work.

One thing that concerns me is this:
One important IR value is the "all-ones" value. For the CPU that would be 11111 and for the FPGA, that's 1111111111. This value corresponds to the mandatory IR instruction called BYPASS. In bypass mode, the TAP controller DR register is always a single flip-flop which does nothing besides delaying the TDI input by one clock cycle before outputting to TDO.

Maybe OpenOCD isn't supporting FPGA. The documentation briefly covers it, but I can't find any modern examples. Maybe I just need to set it up right and don't know how yet...
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster testing

Reply #3
OpenOCD does not understand FPGA programming, but it does understand Jtag, so you should see some information comming out of the fpga (device ID probably).

I have the "arm-usb-ocd" jtag adapter from olimex. And if i create openocd.cfg with one line inside:

Code: [Select]
source [find interface/arm-usb-ocd.cfg]

I get autoprobe result like:
Code: [Select]
bla bla ....
Warn : There are no enabled taps.  AUTO PROBING MIGHT NOT WORK!!
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x41c22093 ..."
Warn : AUTO auto0.tap - use "... -irlen 4"
Error: IR capture error at bit 4, saw 0x3FFFFFFFFFFFFFD1 not 0x...3
bla bla ....

So the ID does get transfered. The device is Spartan XC3S500E. I think you might have problem with pin io configuration on ft2232.

Re: Bus Blaster testing

Reply #4
I did get it. It was a bad footprint, the pinout was switched, I just had to inverse TDI and TMS and it worked the first time :)
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster testing

Reply #5
So you got it working. Good job :-)