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

Re: Bus Blaster update

Reply #15
SOIC is my favorite too.

All outputs need to be enable-able to remove the programmer from the target. They can't be combined because there are 4 groups that need to be controlled separately. Each chip has one enable switch, and 4 of these chips are larger than the rest of the board :)
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster update

Reply #16
I think Ian, more dislikes the only one OE..

Like ian just said :D

Re: Bus Blaster update

Reply #17
*The xtal should be changed to the same package as the Bus Pirate v4 (or vise versa)
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster update

Reply #18
Which thread has the BP v4 schematics, PCB, and BoM?


Re: Bus Blaster update

Reply #20
Thanks for the link!  I failed to look past the heading, which still says "v0a, v1a, v2 & v3."

Re: Bus Blaster update

Reply #21
[quote author="ian"]
SOIC is my favorite too.

All outputs need to be enable-able to remove the programmer from the target. They can't be combined because there are 4 groups that need to be controlled separately. Each chip has one enable switch, and 4 of these chips are larger than the rest of the board :)[/quote]Ah, now I'm finally on the same page.  I grabbed the latest Eagle files from the thread (thanks to IPenguin's link) and those SOIC chips are huge in comparison to everything else.

I'm wondering if there is some way to break the problem down into subsets that all work together.  Instead of analog switches, perhaps individual FET switches could be used.  Then the variable logic voltage could somehow be controlled by a separate circuit feeding a common voltage to all I/O header pins.  I think the challenge is that FET gate voltages only work to turn on the FET if the signal voltages passing through the FET (source-drain) are not close to the gate voltage.  If you're changing the logic level for each attached device, the gate voltages have to change as appropriate - or you could just pick a voltage large enough in magnitude that it would work in all situations.

Sorry I don't have more specific suggestions.  Maybe I can look into this again later.

Re: Bus Blaster update

Reply #22
[quote author="rsdio"]
Thanks for the link!  I failed to look past the heading, which still says "v0a, v1a, v2 & v3."
[/quote]

You are welcome, Ian may want to change the headline to "v0a, v1a, v2, v3 & v4" and just move the "Bus Pirate v4 (private)" child board there, too ;)

For the main subject (Bus Blaster update) I must admit that I don't see a way to solve all of Ian's problems without adding a CPLD/FPGA between the FT2232H and the actual JTAG interface ... what I am missing, too is the optional UART interface that should be available via the FT2232. The design has advanced well but got stuck at the point now where more complexity is required to keep it universal (supporting all voltage levels from 1,5V to 5V and the different interface implementations) or restrict it to support specific devices/families only. I am sorry but I don't have the time and the free mind to think up a (simple) solution right now ... still have to get to set up the FT2232H on a breadboard and check the behaviour of the MPSSE when switching pins from input to output and vice versa ... one problem is that the FT2232H mini module brings the pins out to two double-row headers ... so you can't plug it directly into a breadboard ... and I don't like to perform a "flying test" as I have one module only ...

Re: Bus Blaster update

Reply #23
[quote author="IPenguin"]For the main subject (Bus Blaster update) I must admit that I don't see a way to solve all of Ian's problems without adding a CPLD/FPGA between the FT2232H and the actual JTAG interface ... what I am missing, too is the optional UART interface that should be available via the FT2232. The design has advanced well but got stuck at the point now where more complexity is required to keep it universal (supporting all voltage levels from 1,5V to 5V and the different interface implementations) or restrict it to support specific devices/families only. I am sorry but I don't have the time and the free mind to think up a (simple) solution right now ...[/quote]Very interesting that you should say this, because when I first looked at the "open" JTAG design from Texas Instruments, they invited people to alter the circuit, but warned that it would probably be a waste of time to attempt to remove the CPLD/FPGA from their design.  The verdict with their design team was that the logic was just too complex to manage discretely.

This also has me wondering how they solved the multiple logic level problem - but I seem to recall that they have limited support there rather than a fancy solution.

Re: Bus Blaster update

Reply #24
I like the idea of a CPLD too. Especially with the secondary MPSSE module it can be used to program/update the CPLD directly from the USB connection. One issue might be finding readily-available 5V cplds. Mouser stocks a ton of Lattice chips I'd like to check out, since the mini-multi programmer can program them :)

The H chip has a secondary UART channel and a secondary MPSSE module. They _must_ be broken out on a future design :)

Right now though, we're just determined to prove the concept on an actual PCB. That usually stimulates a ton of ideas, and unveils numerous problems with our initial assumptions.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster update

Reply #25
[quote author="IPenguin"]
You are welcome, Ian may want to change the headline to "v0a, v1a, v2, v3 & v4" and just move the "Bus Pirate v4 (private)" child board there, too ;)
[/quote]

I guess it is not accessable for everyone ;)

Ontopic: Something that comes to my mind is that voltage divider that is used for that logic analyzer that could be easily upgraded to the double amount of channels. It would only solve the input or use a simular thingg on the output?

the (original) article is here (couldn't find it fast on DP forums): http://openschemes.com/2010/03/27/zerop ... ication/2/

I would like a small cpld board too

Re: Bus Blaster update

Reply #26
Yeah, a CPLD might be the solution maybe. FTDI chip might use one of its ports to send messages to CPLD to enable, disable pins. But it might be left to v2, v1 might be used as a proof of concept or maybe just as a prototype for developers only. This might be a good place for me to start with CPLD's :D

Re: Bus Blaster update

Reply #27
I hear you all on the "let's get something done as a proof of concept" ... but here's a wild idea: How workable is the existing Openbench Logic Sniffer as a way to test some JTAG ideas, assuming that you'll need some kind of FPGA anyway.  There are 16 outputs available, right?  Perhaps the OLS v2 would be better, unless the v1 is already communicating SPI direct between the PIC and FPGA.

Sorry - my ideas have been all over the place lately!

Re: Bus Blaster update

Reply #28
rsdio, your idea is not far off at all! I have been talking of designing a dual purpose LA/JTAG-adapter before and it makes complete sense.
When we looked at the USB MCU/controller for the OLS it came down to two options - a) FT2232D/H or b) PIC18F USB MCU. If we would
have chosen a FT2232, we would have ended up with a dual-purpose board or very close.

However, since most JTAG applications support FT2232 based (and proprietary) JTAG adapters only - actually they rely on the FTDI D2xx driver
and the FTDI JTAG DLL - using an OLS with a PIC USB MCU would not work for most applications or make it necessary to implement support
for the PIC based JTAG interface in the application (besides all the coding required on the PIC side, not to speak of all the details and information
that would be required and may not be readily available). Btw, on the OLS v1 the FPGA and the PIC already "talk" via SPI! But then speed is
important but not the only/real issue.

Re: Bus Blaster update

Reply #29
[quote author="IPenguin"]However, since most JTAG applications support FT2232 based (and proprietary) JTAG adapters only - actually they rely on the FTDI D2xx driver and the FTDI JTAG DLL - using an OLS with a PIC USB MCU would not work for most applications or make it necessary to implement support for the PIC based JTAG interface in the application.[/quote]If the FTDI drivers were open, then alternate drivers could be written to interface to the OLS.  But that would require application support for selecting which driver is used.  As you say, that would require details and information that may not be readily available.

Are there any tutorials on JTAG, especially the "standard" applications that are based on the FTDI driver and DLL?

On that note, is the FTDI JTAG DLL available on OSX?  The driver is on OSX, but I don't see any documentation of the JTAG DLL on the FTDIChip site.