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

Re: Bus Blaster v2

Reply #45
[quote author="robots"]
OK so here it comes again....

TDI/DO line on FT2232 is connected to TDO. Which is wrong.  (As TDO is data output on CPLD)
Also for TDO/DI, which is connected to TDI on CPLD. 

[/quote]

Are youbsure? I could totally have messed up, but I interfaced it withn bbv1 and drew a sketch of the pins and it checked out ok. I'll upload the sketch tomorrow morning, but I'm 99%  sure that the connections are ok.

 I wrote the urjtag mailing list, and the reply I got was that libftdi might not even support mpsse2.

Like I said, you're much more in tune with all this yuan me, so you're probably right, but I did due  diligence and thing the internal connection is ok.  I also did logic analysis of the connection and I can't see any active on the ftdi->cpld connection at all, even clk and tms.

I'll do a little more checking tomorrow and also upload that sketch.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #46
Here's the drawing. I'm going to retrace it now and test it again, just to be sure. The top set is the internal connection on bbv2, the bottom is the external connections I made with bbv1.

The successful chain scan is on the wiki (using v1 and v2 FTDI in reset):
http://dangerousprototypes.com/docs/Fil ... bybbv1.png
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #47
Thanks for your attention to details :) I found a couple issues, but mostly happy things.

The final version of the schematic (not the wiki) did actually swap the TDO and TDI pins. We did NOT swap the pin labels, so that led to some confusion...

This sketch shows the actual connections (TDI>TDI, TDO:) I also included a portion of the updated schematic for verification.

I'm going to retest now with BBv1 to be sure this is correct.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #48
I verified the above connections with BBv1, the connection is OK on the PCB.

If you can get the MPSSE2 going (or are willing to work on it), I'll put together a fed-ex worthy order this weekend with some ft2232Hs and try to build you up a BBV2 next week.

One nice thing is that we can always use the BBv1 to program the CPLD with a jtagkey compatible bitstream at the factory, and eventually someone will buy one and get the secondary programming channel working :)

The urjtag mailing list reply:

Quote
does libftdi even support MPSSE2 ?  if not, there isnt anything we can do
about it in urjtag.
-mike

Here's a picture of the current debug situation. The bbv1 (currently in production) is used to chain scan the CPLD on the BBv2. BBv2 is powered by the Bus Pirate v4 because urJTAG latches onto the first FTDI chip it finds, which might be BBv2 or BPv3 if they are on the same PC. Yesterday I just soldered the FT2232 reset pin to ground to hold it in reset, but I didn't want to get the iron out today.

You might notice one problem with the PCB that I corrected: The CPLD 1.8v core supply wasn't connected to the FT2232 1.8v regulator because of a net name problem on the schematic. I used a copper wire to tap the 1.8v supply at C1 and bring it to the CPLD at C19. This is an easy enough issue to fix without a whole PCB revision.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #49
[quote author="ian"]One nice thing is that we can always use the BBv1 to program the CPLD with a jtagkey compatible bitstream at the factory, and eventually someone will buy one and get the secondary programming channel working :)[/quote]Ideally, someone could test secondary programming before you produce a whole run for sale, because there's always the chance you'll discover that a trace needs to change.  ... but that's what little copper wires are for ...

Re: Bus Blaster v2

Reply #50
What is MPSSE2 anyway ? All I see is MPSSE without the "2"  in the datasheet.
My guess is that the program you are using wants the Jtag on port A instead on B.  So it should be a matter of changing one value.

I have just quickly checked the sources, and there is no call to the "ftdi_set_interface" function. So i guess that urjtag uses "default" interface A.

OpenOCD does have few "dongles" defined that use B port. You should give it and let OpenOCD scan the chain at least. (dongle is called redbee-usb)

Re: Bus Blaster v2

Reply #51
Sorry, you're correct. it is JTAG A (ADBUS and ACBUS) and JTAG B (BDBUS and BCBUS). JTAG B connects to the CPLD JTAG. I've been saying MPSSE0/1 or 1/2.

JTAG A is what urjtag seems to use by default. I checked the urjtag source for the cable options, and there are options for specifying vid/pid/desc, but no A/B selection. I thought I could uninstall/disable the driver for JTAG A under windows and it would hit JTAG B by default, but it doesn't seem to work that way.

Good idea to try openOCD, I'll do that now.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #52
I found the addition of the redbee-usb here: http://lists.berlios.de/pipermail/openo ... 14972.html

I think it is a few days after the compiled version I have (0.4.0 for windows). I checked the v4 source, and I couldn't even find the structs this diff refers to in ft2232.c. I'll keep looking for another dongle that uses JTAGB.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #53
Yup, the struct is a different format, maybe it was rearranged shortly after the v4 release. I don't see the possibility of using interface_b in this version. I'll jump over to the Linux box and try, or continue trying to compile OpenOCD under Win32.

Code: [Select]
static const struct ft2232_layout  ft2232_layouts[] =
{
{ "usbjtag",              usbjtag_init,              usbjtag_reset,      NULL                    },
{ "jtagkey",              jtagkey_init,              jtagkey_reset,      NULL                    },
{ "jtagkey_prototype_v1", jtagkey_init,              jtagkey_reset,      NULL                    },
{ "oocdlink",             jtagkey_init,              jtagkey_reset,      NULL                    },
{ "signalyzer",           usbjtag_init,              usbjtag_reset,      NULL                    },
{ "evb_lm3s811",          usbjtag_init,              usbjtag_reset,      NULL                    },
{ "luminary_icdi",        usbjtag_init,              usbjtag_reset,      NULL                    },
{ "olimex-jtag",          olimex_jtag_init,          olimex_jtag_reset,  olimex_jtag_blink       },
{ "flyswatter",           flyswatter_init,           flyswatter_reset,   flyswatter_jtag_blink   },
{ "turtelizer2",          turtle_init,               turtle_reset,       turtle_jtag_blink       },
{ "comstick",             comstick_init,             comstick_reset,     NULL                    },
{ "stm32stick",           stm32stick_init,           stm32stick_reset,   NULL                    },
{ "axm0432_jtag",         axm0432_jtag_init,         axm0432_jtag_reset, NULL                    },
{ "sheevaplug",           sheevaplug_init,           sheevaplug_reset,   NULL                    },
{ "icebear",              icebear_jtag_init,         icebear_jtag_reset, NULL                    },
{ "cortino",              cortino_jtag_init,         comstick_reset, NULL                        },
{ "signalyzer-h",         signalyzer_h_init,         signalyzer_h_reset, signalyzer_h_blink      },
{ "ktlink",               ktlink_init,               ktlink_reset,       ktlink_blink            },
{ NULL,                   NULL,                      NULL,               NULL                    },
};
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #54
Could you ask at the Urjtag mailinglist about the Interface_B ? :-)

I have been looking at the source, it looks doable but would need a major change in the source as changing interface means sending the data to different endpoint and definitely need to be changed at the very beginning of the driver initialization.

Re: Bus Blaster v2

Reply #55
Just a friendly note if you're following this topic...

I split the monster Bus Blaster v2 thread into several small parts that should be easier to surf, but you will not get more notifications until you comment or click 'notify' on the new threads.

Bus Blaster v2 design thread http://dangerousprototypes.com/forum/in ... pic=1490.0
BBv2 CPLD design and implementation http://dangerousprototypes.com/forum/in ... pic=1659.0
urJTAG for BBv2 JTAG B http://dangerousprototypes.com/forum/in ... pic=1655.0
UART on BBv2 MSSPE2? http://dangerousprototypes.com/forum/in ... pic=1656.0
FT2232H EEPROM discussion http://dangerousprototypes.com/forum/in ... pic=1658.0
Got a question? Please ask in the forum for the fastest answers.