Dangerous Prototypes

This project idea stems from this thread:
http://dangerousprototypes.com/forum/in ... 86#msg3386 (http://dangerousprototypes.com/forum/index.php?topic=298.msg3386#msg3386)

The goal is to make a high-speed programmer debugger for JTAG and ROM chips (and other buses) using the MPSSE module of the FTDI 2232H chip:
http://www.ftdichip.com/Products/FT2232H.htm (http://www.ftdichip.com/Products/FT2232H.htm)
http://www.ftdichip.com/Documents/DataS ... T2232H.pdf (http://www.ftdichip.com/Documents/DataSheets/DS_FT2232H.pdf)

The H chip has two MPSSE's so JTAG and SPI ROM programming are possible from the same device at the same time.

Here are some ideas:
*Compatible with existing well-supported 2232 JTAG programmer for instant support in OpenOCD, etc.
--Question: what is the best supported device? What can be reversed from the OpenOCD source, what's open source?
*Compatible with existing well-supported 2232 SPI FLASH programmer (flashrom, OpenOCD also programs ROM?)
--Question: Separate pinout or adapter from JTAG cable? What's the overlap?

JTAG devices
USB ARM JTAG Debugger at Olimex (http://http://www.olimex.com/dev/arm-usb-ocd.html) (seems to work with a ton of stuff)
JTAG USB OCD Tiny (http://http://www.sparkfun.com/commerce/product_info.php?products_id=8278)
OOCDlinkh (http://http://www.joernonline.de/contrexx2/cms/index.php?page=126) (open source, but I don't see a license)

ROM programmers
Flashrom 2232 programmer (http://http://www.flashrom.org/FT2232SPI_Programmer)

Utilities
OpenOCD
Flashrom

Key chip points:
# +3.3V I/O interfacing (+5V Tolerant).
# Extended -40°C to 85°C industrial operating temperature range.
# Compact 64-LD Lead Free LQFP or LQFN package.
# +3.3V single supply operating voltage range.
2 MPSSE modules, both support JTAG/SPI, UART is separate mode (see pin table page 8)
MPSSE JTAG pins (page 15)
H version supports JTAG adaptive clocking (datasheet page 30)
May or may not need an eeprom (page 20, 42, etc)
Needs a 12MHz crystal (27pf load caps) (page 51)

I attached some schematics and tables. The big questions is which pins (besides the default JTAG pins) are used for what in an existing programmer. Which pin has adaptive clocking, which is NRST, etc. This can be reversed from the OpenOCD and flashrom code.

The pinout table shows that most of the common IO pins are shared (TX/MOSI/SDO/etc), just like the Bus Pirate, so the JTAG interface pins can be adapted to do SPI or UART (won't require routing separate headers).

---

Other stuff: price goal is $30, shipped.
Would like to name it in after the Bus Pirate line, like (JTAG) Bus Blaster or something (amazingly enough this isn't used in a quick google, and I was able to buy the domain, but I'm open to other suggestions).
ETD: Available in May?

It seems that OpenOCD will be the "ultimate" tool for the FT2232 adapters (and other multi-interface adapters like BP). With recent development on the mailing list, they have started to add abstraction for other transport protocols like SPI, UART, I2C, etc. The main use for these protocols is ability to program various processors either through embedded bootloader (stm32 bootloader), or through programing interface (like AVR ISP, jtag, SWD, ...).

found a suppler  for the 100ask.net openjtag thats outside of china http://www.micro4you.com/store/Open-ARM ... d_100.html (http://www.micro4you.com/store/Open-ARM-USB-JTAG/prod_100.html)
as this is the type of device i had in mind when i started this and built mine, tho i see no dedicated spi header on that, they will be there but dedicated pins would be nice, cost more i guess. but i'd lose the com port and just put another header (cost reduction)
anyways i like it has both 20pin header and 10

Bus Blaster sounds good ;)

@drewmerc From what i can see in the data sheets and other devices the jtag and spi interface pins are in a fixed position on the chip.
afaics ChanA pins 16-19, ChanB pins 38-41, are the jtag and spi ports, and whilst it would be nice to have dedicated headers you would only be duplicating pins because you cannot use jtag and spi on the same channel at same time.

i cannot make my mind up on the pin layout i suppose it depends on what we would consider the main function of the adapter,
i think a breakout similar to the bus pirate is the way i would go, but possibly keeping the jtag pins in a standard layout,

for the uses i have for it, its quite irrelevant what the layout is because none of the hardware i need to jtag uses standard headers or layout,
so i would be either looking at a lead similar to the seeed one for the bus pirate, or maybe a 1:1 lead and have a breakout board with separate leads/test clips/pinouts, i would rather have the ability to use all the functionality and have to rewire leads than increase costs/loose functionality

also if possible as with the olimex include level shifters to allow rs232 directly without extra interface boards needed, but maybe add a tap to the main uart, because i beleive it will run at higher speeds than the level shifter will?

i think we could end up designing a bus pirate on steroids lol

yes i have a problem, i do tend to dupe header's in my own designs, guess i should start buying crimp instead of idc for my cables
a super breakout cable like the bus pirate one would be great

tap and level shifters all sound good

a new one to look at http://www.freddiechopin.info/index.php ... -lock-pick (http://www.freddiechopin.info/index.php/pl/projekty/64-jtag-lock-pick)

this site has a diagram showing the jtagkey buffering design
http://www.hs-augsburg.de/~hhoegl/proj/ ... bjtag.html (http://www.hs-augsburg.de/~hhoegl/proj/usbjtag/usbjtag.html)
specifically
http://www.hs-augsburg.de/~hhoegl/proj/ ... schema.jpg (http://www.hs-augsburg.de/~hhoegl/proj/usbjtag/img/jtagkey-schema.jpg)

it shows the io buffering portion. but also the ports used on the ft2232

also here shows a "clones" of the jtagkey

http://circuitben.net/usb_jtag/index.php (http://circuitben.net/usb_jtag/index.php)

http://www.geektalks.cn/mediagallery/me ... myjtag.jpg (http://www.geektalks.cn/mediagallery/mediaobjects/orig/7/7_myjtag.jpg)

http://modularcircuits.com/usb_programmer.htm (http://modularcircuits.com/usb_programmer.htm)

last one is non-commercial licence according to site, but seeing as we are only looking at who uses what pins to make it as compatible as possible and not using his design im guessing its ok?

i am looking for more info on ft2232 based spi/i2c devices atm and will post any info i find. as all above dont implement the spi.

some target's i use are BCM334X,BCM3350, and spi mx25l1605,mx25l8005

Great resources, thank you. It looks like post-C revision includes the adaptive clocking features. These also almost all have buffers - I'm pretty torn if a buffer is a good idea on the first revision, might be a lot easier to get it working without.

I'm also uncertain of the EEPROM, I'm leaning towards not needing it. I don't think it's needed if OpenOCD (etc) send the right configuration commands at initialization, but I don;t know if this happens yet. Can always place it but not populate it.

[quote author="ian"]
Great resources, thank you. It looks like post-C revision includes the adaptive clocking features. These also almost all have buffers - I'm pretty torn if a buffer is a good idea on the first revision, might be a lot easier to get it working without.

I'm also uncertain of the EEPROM, I'm leaning towards not needing it. I don't think it's needed if OpenOCD (etc) send the right configuration commands at initialization, but I don;t know if this happens yet. Can always place it but not populate it.
[/quote]

reading the section 4.13.1 in the datasheet i come to the conclusion that modes

ASYNC Serial UART,
ASYNC 245 FIFO,
Fast Serial interface,
CPU-Style FIFO
Are configurable using the eeprom

SYNC 245 FIFO
ASYNC Bit-bang
SYNC Bit-bang
MPSSE
FIFO Host Bus Emulation
are configurable using the software

but as you say is it needed or just an option that can be used to auto configure the chip on powerup. ie auto setup as a jtag.

but the eeprom also allows custom pid/vid and custom device names ect so i think unless cost is too much then it be better to have it show in controlpanel etc as Bus Blaster,

edit:

here is the datasheet explaining "user area"
http://www.ftdichip.com/Documents/AppNo ... _Usage.pdf (http://www.ftdichip.com/Documents/AppNotes/AN_121_FTDI_Device_EEPROM_User_Area_Usage.pdf)
"FT2232H and FT4232H do not have any internal EEPROM. These need to be
connected to an external EEPROM such as the 93C46, 93C56 or 93C66 to configure device’s setting.
Note. The EEPROM used must be of a type with a 16-bit width."

heres a  another datasheet regarding the recovery of bricked ft2232 modules.
http://www.ftdichip.com/Documents/AppNo ... covery.pdf (http://www.ftdichip.com/Documents/AppNotes/AN_136%20Hi%20Speed%20Mini%20Module%20EEPROM%20Disaster%20Recovery.pdf)

"3.1 What the EEPROM Contains
The EEPROM contains standard descriptors to allow for unique identification of the device e.g. VID, PID, Serial number and strings such as manufacturer and product name.
In addition to the descriptors there are functional parameters that allow the device to be configured into different modes e.g. UART or FIFO."

edit:::

i take it back, re reading the datasheet it seems as if the module will function with a blank eeprom attached but not a corrupted one.
so back to square 1 lol is it needed? well hopefully we will find out soon.. i have just emailed the support team and asked them ;)

ok found more info on a different site.

"Do I need to fit the EEPROM?
The chip has in-built default parameters in silicon but if you need to change any of the following you will definately need to fit the EEPROM to be able to store your preferences: USB Power draw, Product ID, Serial number or the plug-and-play flag.
Additionaly the following requirements would necessitate updating (and therefore fitting) the EEPROM:
- If more than one of your device needs to be plugged into the same PC at any one time.
- If you require only one driver installation per PC, fix the serial number to be the same on all devices.
- If you need to set the PID as provided by AMC or the USB Forum to work with your drivers."

so dont look like we need it unless we use custom parameters or pid/vid, i personally would say to use one, but dependsing on costs ect then placing the pads on the pcb but leaving the chip off would allow people who wanted that facility to add the eeprom later on.

ive just finished editing the inf's and  eeprom on the buspirate, looks so much cooler having buspirate (com) instead of usb serial comport in the comport enumerations.

had a reply to my email

Hello,

 

It is not essential to use an EEPROM for MPSSE or UART mode.

 

You may want to add one to change device descriptors to customize the appearance of the design.

 

Regards,

 

Gordon Lunn

Senior Applications Engineer

 

Speaking with my flashrom hat on, I do welcome such ideas.
After all, it means flashrom can probably support this new device with maybe two lines of code (or even without any changes at all).

A few words of advice:

• SPI on the FTDI devices with MPSSE is easy. There's an opensource libftdi which works pretty well (if you have a current libftdi, libusb and kernel). Older libusb/libftdi/kernel combinations may cause transactions longer than 32 bytes to become corrupted (incorrect USB packet separation, some status codes end up being interpreted as data)
• We've had reports that interface A on either the FT2232H or FT4232H is somewhat busted, but others have been unable to confirm that.
• If you keep a few things in mind, you can make the FT2232 with MPSSE into an all-purpose flash programmer (sort of like the Willem, but without the slowness and without the high price. Right now flashrom only supports SPI with the FT2232H/FT4232H, but it is pretty doable to add bitbanging/MPSSE LPC/FWH flash support (unfinished patch available) and it might even be possible to target old parallel flash chips which are appearing again in laptops. Flash interface requirements:
  
  • SPI needs 4 lines including clock (well, you can speed up accesses with a 5th line). Having SOIC8/SOIC8W pads and a DIP8 socket would be cool.
  • FWH/LPC can be done with 7 lines AFAIR. Most common form factor is PLCC32. One common PLCC32 socket for FWH/LPC is possible (same pinout). Rarely used alternative form factors are TSOP32 and TSOP40.
  • Parallel needs n address lines (usually 17-22), 8 or 16 data lines, and two control lines. Getting 32 lines coordinated can be tricky, so this may actually use two interfaces in lockstep (if possible) or some sort of buffer. Various form factors, among them half a dozen DIP variants and a PLCC32 socket (which has an incompatible pinout to the LPC/FWH PLCC32 socket and will fry the chip if you confuse the sockets). Usually handled by one large DIP socket where you left-align (or right-align) all chips, and one PLCC32 socket.
[/li]

• Clock rate is variable, but I don't know if anything faster than 12 MHz works reliably. The variable clock rate is helpful for chips which max out at 20 MHz (some chips can take 150 MHz).
• Some chips want 5 V, others 3.3 V, others 2.8 V. Voltage selection would be cool (some FTDI chips can use a reference voltage for all I/O.

some encouraging info there biosflasher,

i especially like the following.
[quote author="biosflasher"]
If you keep a few things in mind, you can make the FT2232 with MPSSE into an all-purpose flash programmer (sort of like the Willem, but without the slowness and without the high price. Right now flashrom only supports SPI with the FT2232H/FT4232H, but it is pretty doable to add bitbanging/MPSSE LPC/FWH flash support (unfinished patch available) and it might even be possible to target old parallel flash chips which are appearing again in laptops.
[/quote]

if we could get the project to that point it would be amazing

looking at the datasheet (page 8) the spi is only available on channel b.

Thanks for your experienced input. This is really gelling. I'd really like it to work out-of-the-box with OpenOCD and flashrom. Since it's a hardware module with fixed pins, I think it will be easy to make it compatible with existing supported tools.

I think an EEPROM footprint should be included, with the intent of it being available but not populated. A custom VID/PID is $4000 from the USB forum, so that's probably out of reach :)

SPI looks like it comes from the MPSSE module on both channels (ganged with the JTAG pins). The FSI (only on B) is a custom interface protocol - I got hung up on that at first.

[quote author="ian"]I think an EEPROM footprint should be included, with the intent of it being available but not populated. A custom VID/PID is $4000 from the USB forum, so that's probably out of reach :) [/quote]
Just for your information, you don't need to pay the USB forum for a custom VID/PID if you'd like one, FTDI offers to give you your own PID for free (yes, they actually do, we tried it...), see here at the bottom: http://www.ftdichip.com/FTDrivers.htm (http://www.ftdichip.com/FTDrivers.htm)

"For customers wishing to create their own driver release, FTDI can issue you with a block of 8 product IDs (PIDs) for use with FTDI's vendor ID (VID) if you do not have your own vendor ID.  This service is free of charge, but the issued PIDs must only be used with FTDI's VID (0x0403)."

The bad news is, however, that you no longer are "FTDI-plug-and-play-everybody-recognizes-you-instantly" - you need customized INF files/linux driver package since obviously nobody knows what exactly you just plugged in anymore. :)

[quote author="EasyRider"]
[quote author="ian"]I think an EEPROM footprint should be included, with the intent of it being available but not populated. A custom VID/PID is $4000 from the USB forum, so that's probably out of reach :) [/quote]
Just for your information, you don't need to pay the USB forum for a custom VID/PID if you'd like one, FTDI offers to give you your own PID for free (yes, they actually do, we tried it...), see here at the bottom: http://www.ftdichip.com/FTDrivers.htm (http://www.ftdichip.com/FTDrivers.htm)

"For customers wishing to create their own driver release, FTDI can issue you with a block of 8 product IDs (PIDs) for use with FTDI's vendor ID (VID) if you do not have your own vendor ID.  This service is free of charge, but the issued PIDs must only be used with FTDI's VID (0x0403)."

The bad news is, however, that you no longer are "FTDI-plug-and-play-everybody-recognizes-you-instantly" - you need customized INF files/linux driver package since obviously nobody knows what exactly you just plugged in anymore. :)
[/quote]

exactly what i did with my bus pirate ;) but as its only for me i have just edited the eeprom to a random pid and edited the inf file to match. (no point wasting an allocation)
where as it would be nice to have it auto install using ftdi standard drivers, i see no problem in having to download a small driver file when it allows total customisation of the pid and device descriptors, i have a few devices now that are ftdi based that all need custom drivers, including, bus pirate,infinity unlimited usb, and various others with built in usb/serial converters, all have custom names ect which makes it very easy to pick the right one when using more than one at a time. i have even renamed some myself just to get friendlier names in device manager,

being able to alter the pid/vid i beleive is a good thing as it will allow those who chouse to, to change the pid/vid to match other compatible devices and use software that allows only those devices also the ft2232 will function perfectly with a blank eeprom just as well as no eeprom, so doesn't have to be programmed at factory,

but i would be happy with the eeprom footprint being placed, atleast then we have a choice to add our own, or even have it added at production if needed without redesigning the pcb layout, measure twice cut once.

There is a device released under a free license that is very similar to what has been discussed here. It is called Floss-JTAG:
http://randomprojects.org/wiki/Floss-JTAG (http://randomprojects.org/wiki/Floss-JTAG)

It is also being used by the Openpilot project as their main device JTAG interface:
http://wiki.openpilot.org/Floss-JTAG (http://wiki.openpilot.org/Floss-JTAG)

They are already compatible with OpenOCD, and the second interface is wired as a high-speed serial port. I'm using it at 4Mbps to communicate with some
sensors we are developing at the University where I work.

The board was designed in EAGLE and it is also available here:
  $ git clone git://github.com/esden/floss-jtag.git (http://git://github.com/esden/floss-jtag.git)

It might be worth looking at it for ideas, or to extend it to become the Bus-Buster.

Hi Ian,
it would be cool if you could post your design before it enters manufacturing so I can point other flashrom developers to this project. Creating programmers seems to be a hobby of many people, and I'm aware of 4 designs by other flashrom developers. Maybe there's interest to reuse some of these designs. OTOH, those who already designed their own programmers would probably good reviewers of a new high-speed design.

Regardless of what you end up with, it is 100% sure that flashrom will support that programmer. Heck, flashrom supports one AVR-based programmer which existed exactly once in the world (and has since been dismantled). Adding support for your new programmer design will be easy.

In other news, flashrom is starting to add support for chips with non-power-of-two sector sizes (IIRC you need that for one of your projects). Expect some (hopefully working) code in ~5 weeks or so (design is still unfinished).

Thanks for the extra info. I'm going to start drafting this board soon. I think this should be a public domain project like the Bus Pirate because it fits in the tool category and I like tools to be in the public domain. There's also a lot of stuff already out there under a mix of licenses, I think going public domain would give this project an advantage as a reference design.

Here's the 20pin header I'm planning to use. I'll post a base schematic and then start working on which signals go to which FT2232 pins.

---

Looking at the Floss-JTAG, it seems that it would probably fit most (if not all) requirements. Given that it has been posted under a very free license (and you want the same as well), maybe you can contact its author directly. Not sure if he already knows about the Bus Blaster.

Hi! I just got pointed to this thread. It really seems that you are trying to do a similar thing I did with Floss-JTAG.

I see that you would like the design to be public domain? I could change the license of Floss-JTAG to PD-0 (http://creativecommons.org/publicdomain/zero/1.0/ (http://creativecommons.org/publicdomain/zero/1.0/)) but I am not sure that it is really necessary. I think CC-BY-SA is really free (as in freedom) license and I like when people have to release what they do based on open projects to the public, just like GPL does. An example of such usage is the OpenPilot version of Floss-JTAG (http://openpilot.org/Floss-JTAG (http://openpilot.org/Floss-JTAG)). Still you can convince me if you want to. :)

I am currently working on a new version of Floss-JTAG which uses pretty eagle libs (http://github.com/esden/pretty-eagle-libs (http://github.com/esden/pretty-eagle-libs)) to have proper footprint sizes as stated by the standards and a consistent look and feel of them. :) Also that version will include an optional eprom. So I think all requirements you stated before should be covered by Floss-JTAG 0.3 version. I have built 10 of Floss-JTAG version 0.2 and several people are using it by now, so I consider it tested and working well.

Cheers Esden

hi esden, I can't open the eagle files from github, may I asked the eagle version you used?

I used version 5.7.0. Did you download the eagle files one by one from the interface? If yes then it won't work (I already heard about the problem). Either download the whole source (http://github.com/esden/floss-jtag/zipball/master (http://github.com/esden/floss-jtag/zipball/master)) or clone the repository: git clone http://github.com/esden/floss-jtag.git (http://github.com/esden/floss-jtag.git)

Then you should be able to open the files.

Cheers Esden

I downloaded the file one by one, I downloaded the whole source and I can now open them, thank you

Yes that is a problem that I already know about github, I think I should finally report it. :)

Eagle schematic of the reference design is attached.

Need to determine: INTRST, RTCK, NRST, DBGRQ, DBGACK

---

Here's the OpenOCD ft2232 support source. One file supports a ton of slightly different connections. I'm starting with the idea to clone the olimex version because it seems to be well supported in a lot of apps already, but I haven't done a lot of research. I need to google the major names and see who supports what. Then it's just a matter of reversing the source to see which pins connect to the INTRST, RTCK, NRST, DBGRQ, DBGACK singals.

http://openocd.git.sourceforge.net/git/ ... 3f;hb=HEAD (http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/drivers/ft2232.c;h=93d1c4a809ba07716ab2914d43a58ba51f9a2f3f;hb=HEAD)

The 4 main JTAG pins are fixed by the MPSSE module (see my previous cct).

The H version supports adaptive clocking. I haven't figured out if this is a specific pin or not, the Open OCD code is here:
http://openocd.git.sourceforge.net/git/ ... =HEAD#l560 (http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/drivers/ft2232.c;h=93d1c4a809ba07716ab2914d43a58ba51f9a2f3f;hb=HEAD#l560)

LED blink for various setups:
http://openocd.git.sourceforge.net/git/ ... HEAD#l3058 (http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/drivers/ft2232.c;h=93d1c4a809ba07716ab2914d43a58ba51f9a2f3f;hb=HEAD#l3058)

JTAG reset:
http://openocd.git.sourceforge.net/git/ ... HEAD#l1355 (http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/drivers/ft2232.c;h=93d1c4a809ba07716ab2914d43a58ba51f9a2f3f;hb=HEAD#l1355)

hardware init
http://openocd.git.sourceforge.net/git/ ... HEAD#l2506 (http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=blob;f=src/jtag/drivers/ft2232.c;h=93d1c4a809ba07716ab2914d43a58ba51f9a2f3f;hb=HEAD#l2506)

Some nice work there Ian, 

I will have a look at the source and see if i can compile a list of any other common pins between the various suported interfaces.

as an idea
how much of a nightmare would it be to breakout all the io pins on the ft2232?, not all pins, just the ones not being used in the initial design
as you say layout the pcb so it would emulate the olimex pinouts. but then have an extra header for unused bus pins.
this would then allow those so inclined to build there own interface leads to emulate any ft2232 based device.

i think what im describing is a tweaked version of the mini module produced by ftdi.

This PDF shows the Olimex pin connection, no need to reverse the code:

http://www.olimex.com/dev/pdf/ARM-USB-OCD.pdf (http://www.olimex.com/dev/pdf/ARM-USB-OCD.pdf)

The next question is what type of buffer to use (if any) on the first model.

Connection table is attached. I need to see if the pinout is the same as the one I proposed earlier.

---

Here's some research on common connections for FT2232 programmers from notes, schematics, and the OpenOCD source code. It's not 100% finished or reliable, but it's a starting point for a compatible design.

At the moment the buffer is holding things up. The buffers are mostly to let the chip work with targets below 3.3volts, so the FT2232 outputs don't cause problems for low voltage targets.  The buffers used in most of the designs I looked at are pretty pricey and not highly-available. I'd like to figure out something though, because I think the buffers are important. It has to be a tri-state buffer, but the pin layout is for a unidirectional buffer so that opens up more options.

Some of the signals are open drain outputs and won't need to be buffered because the FT2232 pins will never output high levels. I have some info on that that I need to add to this table.

A few of the pins might actually have different connections and configurations between different programmers. nTRST and TSRST need some more investigation.

TCK (JTAG pin #9)
*JTAG clock signal from programmer to target
*Output from programmer to target
*FT2232H pin 16 (ADBUS0/MPSSE #1)
*Output enable controlled by FT2232 pin 21 (JTAG_BUFFER_EN)

TMS(7)
*Determines the state of the TAP controller
*Output from programmer to target
*FT2232 pin 19 (ADBUS3/MPSSE #4)
*Output enable controlled by FT2232 pin 21 (JTAG_BUFFER_EN)

TDI(5)
*Serial data feed to test data register or instruction register
*Input to programmer from target
*Output from programmer to target
*FT2232 pin 17(ADBUS1/MPSSE #2)
*Output enable controlled by FT2232 pin 21 (JTAG_BUFFER_EN)

TDO(13)
*Receives serial data from test data registers or instruction register
*Input to programmer from target
*FT2232 pin 18(ADBUS2/MPSSE #3)
*Unbuffered

RTCK(11)
*JTAG retimed clock, adjusts the JTAG programmer clock for low speed and sleep modes on some chips.
*Input to programmer from target
*FT2232 pin24 (ADBUS7/MPSSE #8)
*Unbuffered

Not 100% sure about these pins-----------
nTRST(3)
*Asynchronously reset the TAP controller
*Output from programmer to target
*FT2232 pin 26(MPSSE #9)
*Output enable controlled by FT2232 pin28 (TRST_BUF_EN)

TSRST(15)
*System reset, Target detect
*Bidirectional
*FT2232 pin 27 (MPSSE #10)
*Output is controlled by FT2232 pin 22/ (TARGET_PRESENT) and fed back to FT2232 pin 23/ADBUS6 (TSRST_IN)

These pins still need to be assigned----------------

DBGRQ(17)
*Asynchronous debug request. DBGRQ allows an external signal to force the ARM core into debug mode
*Output from programmer to target
*FT2232 pin ?

DBGACK(19)
*Debug acknowledge
*Input to programmer from target
*FT2232 pin ?
---------------------------------
JTAG_BUFFER_EN
*Enable JTAG buffers for TMS/TDI/TCK lines
*ADBUS4/FT2232 pin21

TARGET_PRESENT
*ADBUS5/FT2232 pin22

TRST_BUF_EN
*Controls TRST buffer enable for TAP controller reset
*ACBUS2/FT2232 pin 28

I may have missed it but I think it wasn't mentioned yet: Mark Whitis has done a very thorough survey of the various JTAG interfaces/pinouts used by the different manufacturers (the pinouts with pin descriptions start at about 1/5th down the page) and published to my knowledge the by far most complete (public) compendium on JTAG interfaces: http://www.freelabs.com/~whitis/electronics/jtag/ (http://www.freelabs.com/~whitis/electronics/jtag/)

An open source JTAG Interface, so based on the slower FTDI 2232L, that a) is fully supported by OpenOCD and YAGARTO and b) has all JTAG lines buffered by LCX type single logic gates, which are powered by the JTAG VTref line (thus being automatically adjusted to different target voltage levels from 5.5V down to 1.65V) is the Turtelizer 2 by Harald Kipp!

Schematics, layout and a detailed description including the pinout of the 3 most commonly used JTAG connectors can be found here: http://www.ethernut.de/en/hardware/turt ... index.html (http://www.ethernut.de/en/hardware/turtelizer/index.html) (The server was not accessible this night - try the google cache)

Another neat feature is the MAX 3243 buffer for a RS232 compatible Interface on the 2nd channel of the FT2232.

In my opinion it would be nice if the design would have pinouts for the 3 most common JTAG connectors (20-pin, 14-pin and 10-pin) despite the extra board space needed. Only the 20-pin connector would have to be populated but it would allow users to add the other connectors ... I hate nothing more than searching for the various JTAG cable adapters ... in most cases the one I need has ended up in a drawer of one of my colleagues while 20, 14 and 10 pin 1:1 flat ribbon cables are all over the place. :D

[quote author="IPenguin"]In my opinion it would be nice if the design would have pinouts for the 3 most common JTAG connectors (20-pin, 14-pin and 10-pin) despite the extra board space needed.[/quote]
I second this suggestion, although I would be using the 14-pin.
I recently designed a TMS320VC5506 board with USB, 24 analog inputs, 32 analog outputs, and capacitive sensors.  I had to use the following documents (SPDU079A, SPRU655D) to design the board to be compatible with Texas Instruments' JTAG debugger/programmer standards. I think you'll find that if you read through them, you might understand more about what your design should support.
http://focus.ti.com/lit/ug/spdu079a/spdu079a.pdf (http://focus.ti.com/lit/ug/spdu079a/spdu079a.pdf)
http://focus.ti.com/general/docs/litabs ... r=spru655e (http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spru655e)

... however, I note that some of the advanced, high-speed JTAG ports would suffer if multiple pinouts were on the PCB.  Texas Instruments actually suggests designing for a single connector. I suppose that recommendation may really only be necessary for the super high speed versions, but I only scanned the updated file.

[quote author="ian"]
...
These pins still need to be assigned----------------

DBGRQ(17)
*Asynchronous debug request. DBGRQ allows an external signal to force the ARM core into debug mode
...
DBGACK(19)
*Debug acknowledge
...
[/quote]

I believe that these do not need to be assigned, and that the same effect can be achieved using the jtag TAP port.

Thanks for the links, they are all really interesting. I'll review them now and update the table.

Not sure if this is a dumb question:  Will the functionality for this device be a superset of the bus pirate?    Or will people potentially need both a bus pirate and a bus blaster?

buspirate is the "smart device", all you need is a terminal to control it.

Bus blaster is "dumb device", you are probably going to need some kind of SW to operate it. Eg. OpenOCD or UrJTAG to use jtag.
Or you could write your own, using the FDxxxx lib (dont really know the name).
This device is also unbrickable :)), no FW flashing, nothing to go wrong.

If you need precise timing, i think that Buspirate will beat Bus blaster. There is no way you are going to get realtime performance on Win32 with USB :)

as robots said.

the bus pirate is the superior device in terms of "smarts" by being able to interface with most devices using standard protocols.
and doing it at human pace so you have control over the entire process from start to finish and all you need is terminal software

the bus blaster is aimed to be a device that only uses specific protocols (JTAG/SPI/I2C/UART) but will do them at high speed and hopefully be fully compatible with the majority of usbjtag / usbspi software already available, so a more automated process.

For those who are interested in application development for the FT2232D/FT2232H/FT4323H devices, here are the Programming Guides for the FTD DLLs, JTAG - FTCJTAG.DLL, SPI - FTCSPI.DLL, I²C - FTCI2C.DLL (http://http://www.ftdichip.com/Documents/ProgramGuides.htm). FTDI provides the source code for the DLLs as well as examples for different programming languages.

... I'd call the Bus Blaster (aka FT2232D/FT2232H/FT4232H) a "black box" with very powerful Multi-Protocol Synchronous Serial Engines (MPSSEs) you can only access via the USB interface while the Bus Pirate (aka PICF24FJ64GA02) makes use of the MCUs Enhanced USART and Master Synchronous Serial Port (MSSPs) modules which provide pretty much the same functionality as the FT2232Hs MPSSEs. For those users who will not program/modify firmware for the Bus Pirate the real big difference is that they can access the functions of the Bus Pirate with direct commands from their PC keyboard via a terminal emulation (among other ways) while there is to my knowledge no similar (simple and versatile) user interface available for the Bus Blaster/FT2232 based JTAG/SPI/I²C/UART adapters ... so far.

The FT2232H (and it's predecessor FT2232D) has mainly been used in fairly closed (proprietary) or vertical open source applications (dedicated to narrow fields of applications like programming, debugging and testing via the JTAG interface) eventhough it's comparable in versatility with the Bus Pirate in my opinion and could outperform the Bus Pirate by a factor of up to 100 in some applications.

 ... it would be interesting to see if this project will trigger some initiative that will lead to the developement of open source applications that will make the JTAG, SPI, I²C and UART functions of the FT2232H available to the user's fingertips in a Bus Pirate fashion style ... ;)

I am coming in late to this topic, so I don't know whether the following has been mentioned already.

Texas Instruments offers their XDS100 schematic as open hardware. It uses the same FTDI2232H JTAG chip, so you could potentially learn a lot from their design.

Their FAQ is here: http://processors.wiki.ti.com/index.php/XDS100 (http://processors.wiki.ti.com/index.php/XDS100)

The schematic and BoM are here: http://software-dl.ti.com/dsps/dsps_reg ... up_1_0.zip (http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_ccstudio/XDS/XDS100v2_design_setup_1_0.zip)

The latter is Windows-specific, so I haven't taken a look yet. TI requires registration, but since I was already registered on their forum I did not have to do anything extra. In other words, the registration is more of a general download requirement and not really specific to their open hardware. I recommend taking a look, since they're already on a second generation design, and surely they learned a few lessons along the way. I believe that the older hardware design is also available for comparison.

I like the idea of having CPLD on board :) Even though it contains almost no logic.

They even use it as Level shifter .

I like the way the FAQ warns those of us who are cheap to resist removing the CPLD because the replacement logic will cost more anyway. Sounds like a challenge!

I recently designed a board that needed 4 logic chips for glue, but their total price is still well under $1, and I couldn't find a CPLD with the necessary gates for any less than $8. I should look at the XDS100 schematic because now I'm curious.

One problem with the schematic is the license :)

It mentions "licensed material may be used for applications generating tools to be used exclusively with TI devices." Or something like that.

BTW the cpld they are using costs ~1usd at digikey.
I guess that some CPLD could be added to this project, to allow some simple logic to be written by users. Eg some protocol accelerator or counter, quadrature decoder ....

There is a trend in the industry to use CPLDs and FPGAs in their low-cost debuggers/programmers. An other example is the WIZnet W7100 debugger for their new W7100 Internet MCU ... it uses a Spartan-3(E?) in combination with a FTDI FT232 ...

The advantages of having a CPLD or FPGA on the JTAG adapter is that you can easily reassign signals to any pin on the JTAG header, even adapt signals and implement specific "JTAG functions/extensions/implementations" - "JTAG intelligence" right on the adapter, like the Xilinx JTAG ACE placer that would allow the JTAG adapter to act as a direct replacement for the Xilinx Platform Cable USB II for direct download and testing of HDL designs from iMPACT to all Xilinx FPGAs and CPLDs devices - and even use the CPLD/FPGA for level shifting as robots pointed out.  

I agree with robots that it would be nice to have a CPLD or even a "small" FPGA on this design ... like a Xilinx Coolrunner II. Coolrunner II CPLDs provide LVTTL and LVCMOS compatibility, support 1.5V, 1.8V, 2.5V and 3.3V voltage levels and tri-state options for the I/O cells when in output mode ... exactly what is required for a flexible JTAG adapter. 

Coolrunner II can be used as jtag programmer  but you still need a link with usb so again you want some ftdi there, and with 2232H you can not only implement jtag, you can also have a real-time 8bit 60MHz logic analyzer or real-time 16bit 30MHz logic analyzer... How many times you cursed OLS for not having enough ram to hold big enough sample and your scanning rate was way below 30MHz ? I know I did ... most often the scanning rate of OLS I use are 5 and 10MHz and below 16 bits ... so 2232H would get the job better then fpga in this case ....

now, imagine combination of 2232H + CPLD where you can put triggering into CPLD so you can have triggering don on device instead on host...

anyhow, where are we on this project? stalled? noone to do the ftdi programming?

It's funny that you posted on this project today. The first PCB had mask over the buffer pads, so I sent back a revision. That board came in last week and I built and tested it yesterday.

It works (power up), and is detected by OpenOCD. I'm having a minor issue though. The BB is designed to be out-of-the-box compatible with OpenOCD by having the same pinout used by lots of ft2232 programmers. I know that most existing Ft2232 devices used the D and E chips. We're using H (first 3.3volt chip I guess?). I didn't think OpenOCD would care about the chip version, but it expects the specific revision too. If I try openOCD with the olimex or jtagkey .cfg file, it is not detected (ft2232D devices), but it is detected fine with the flyswatter and floss .cfg (H chips). Problem is, none of the supported H chips seem to have the same buffer we used (still checking...).

This is a pretty easy fix, just tweak one of the compatible drivers to accept the H chip ID too. Getting OpenOCD to compile under windows will be the hard part probably, but it's been on my to do list (to test for robots) for a while.

It looks pretty promising, and I hope to order a first batch within the month.

Do you know of any LA software that already supports the FT2232? That's a great idea.

[quote author="ian"]
It's funny that you posted on this project today. The first PCB had mask over the buffer pads, so I sent back a revision. That board came in last week and I built and tested it yesterday.

It works (power up), and is detected by OpenOCD. I'm having a minor issue though. The BB is designed to be out-of-the-box compatible with OpenOCD by having the same pinout used by lots of ft2232 programmers. I know that most existing Ft2232 devices used the D and E chips. We're using H (first 3.3volt chip I guess?). I didn't think OpenOCD would care about the chip version, but it expects the specific revision too. If I try openOCD with the olimex or jtagkey .cfg file, it is not detected (ft2232D devices), but it is detected fine with the flyswatter and floss .cfg (H chips). Problem is, none of the supported H chips seem to have the same buffer we used (still checking...).

This is a pretty easy fix, just tweak one of the compatible drivers to accept the H chip ID too. Getting OpenOCD to compile under windows will be the hard part probably, but it's been on my to do list (to test for robots) for a while.

It looks pretty promising, and I hope to order a first batch within the month.
[/quote]

NIIIIIIIIIIICE :D ... I had a feeling this thread needed a bump :D

Do you know of any LA software that already supports the FT2232? That's a great idea.

actually - no :(
I ordered 2232H breakout board (arrived recently) and I plan to make a simple real-time ftdi -> bin file application just to test how it works.... I suck big time when G is the important part of Gui :( and this would require some nicely thought off gui... who knows maybe I come up with something, anyhow I'm on linux so first I need to check out how well ftdi is supported and I will most probably make a kernel module that will make 2232H act like source for 16bit stream and then some app that will actually connect to the stream and maybe display that data in real time ... we'll see .. still working on another project so this is just idea that will for now have to wait a bit. I'd like to be able to make it work somehow on mac and windoze too so maybe if jawi can adapt his java client of obls to accept another type of devices so he can read fast real-time stream it might be cool then only on windoze we'd have to make some driver that will allow similar source to exist on windows and gui that works everywhere ... need to think about it more .. but .. you are already talking to ftdi on blaster? or you are just making blaster "recognizable" for openOCD and letting openOCD talk to ftdi any way it know how?

you are already talking to ftdi on blaster? or you are just making blaster "recognizable" for openOCD and letting openOCD talk to ftdi any way it know how?

It's all up to OpenOCD and lib_usb/ftdi right now. I'm not planning to write any software from scratch.

you are already talking to ftdi on blaster? or you are just making blaster "recognizable" for openOCD and letting openOCD talk to ftdi any way it know how?

Adding A)USB device options, and B) real-time data sampling triggers and sampling depth to the alternative client would be my approach too. Then it would be ready for something like the FT2232 usb logger LA type, and also the OLS HID/bulk continuous sampling mode.

the question is if jawi can make his client do that / if java is fast enough to fetch 60MHz stream

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.

Here's a picture of the test bed, powered down unfortunately. Debugging is on hold until I have a known-working target to debug (IP is mailing it today).

---

I really like your rj12 to screw terminal adapter ;)

The best for programming PICs with the ICD2 :) You can have any pinout you want...

[quote author="ian"]
The best for programming PICs with the ICD2 :) You can have any pinout you want...
[/quote]

Well, I would say its the ICD3.  Though you can probably pick up an old ICD2 a lot cheaper now.

-Eric

Does the ICD3 also have the rj12 jack? I still have v2.

[quote author="ian"]
Does the ICD3 also have the rj12 jack? I still have v2.
[/quote]

Yes, it is physically similar (except for the color and no more serial port) but has significant internal upgrades.

I found this comparison (http://http://cms.diodenring.de/de/electronic/microcontroller/86-icd2-vs-icd3).

I think one other advantage that was not mentioned is that once a new version of a Microchip tool comes out support for the previous version will start to fade.  As new chips come out it is likely that at some point they will no longer be added to the ICD2.  This is what happened to my ICD1, then support for it was dropped from MPLAB.  You probably have quite a while till this starts to happen though.  I got mine when they first came out and Microchip had a trade-up program.  If you donated your ICD2 to one of their educational charities (such as FIRST (http://http://www.usfirst.org/)) you got a discount on a new ICD3.

See also www.microchip.com/icd3/ (http://http://www.microchip.com/icd3/)

-Eric

I have a ICD3 and I like it much better than the ICD2.  Besides not having RS232 it also does not need an external power supply.  I still have a ICD2 and a couple of the old ICD1's.

McZ

[quote author="Eric"]
[quote author="ian"]
Does the ICD3 also have the rj12 jack? I still have v2.
[/quote]

Yes, it is physically similar (except for the color and no more serial port) but has significant internal upgrades.

I found this comparison (http://http://cms.diodenring.de/de/electronic/microcontroller/86-icd2-vs-icd3).

I think one other advantage that was not mentioned is that once a new version of a Microchip tool comes out support for the previous version will start to fade.  As new chips come out it is likely that at some point they will no longer be added to the ICD2.  This is what happened to my ICD1, then support for it was dropped from MPLAB.  You probably have quite a while till this starts to happen though.  I got mine when they first came out and Microchip had a trade-up program.  If you donated your ICD2 to one of their educational charities (such as FIRST (http://http://www.usfirst.org/)) you got a discount on a new ICD3.

See also www.microchip.com/icd3/ (http://http://www.microchip.com/icd3/)

-Eric
[/quote]

BTW I ran across this website, dont know if it has been posted before.

Modular Circuits USB JTAG-Programmer (http://http://www.modularcircuits.com/usb_programmer.htm)

Schematic (http://http://www.modularcircuits.com/download/usb_programmer_sch_pcb.pdf)

On a related project I need to use one half of a FT2232H for interface to a Xilinx CPLD and the other half of the FT2232H for JTAG for the Xilinx CPLD.

Thoughts?

McZ

The H as two serial modules, one for JTAG and one for COMs is a very typical configuration for ARM boards. BUT - my experience has been that openocd doesn't support CPLDs/FPGAs, though I'm testing unknown hardware so who knows... I'll know for sure when IP's reference hardware arrives for testing.

If it's supported, just install the libFTDIUSB (or whatever) drivers for both modules and you should be good to go. You can mix and match - one serial, one SPI, or both SPI, etc.

[quote author="MichaelZ"]
BTW I ran across this website, dont know if it has been posted before.

Modular Circuits USB JTAG-Programmer (http://http://www.modularcircuits.com/usb_programmer.htm)

Schematic (http://http://www.modularcircuits.com/download/usb_programmer_sch_pcb.pdf)

On a related project I need to use one half of a FT2232H for interface to a Xilinx CPLD and the other half of the FT2232H for JTAG for the Xilinx CPLD.

Thoughts?

McZ
[/quote]

I have been looking at openocd and they only mention CPLD/FPGA's in one section of the manual. 

Amontec (http://http://www.amontec.com/jtagkey.shtml) claims that their jtag programmer is based on the FT2232L and can program CPLD/FPGA's  They have open source.  Slurp slurp.  They also support openocd. 

I will post what I am working on.

McZ

As I recall, Amontec has a separate (non open?) utility to play SVF and XSVF for CPLD/FPGA with their Key programmers.

The OpenOCD manual does mention one FPGA type and setting, which initially gave me hope. There are no examples in the .cfg files though, and my googling only turned up people asking 'I saw it in the manual, does it actually existing?'.

I use a lot of Xilinx CPLD/FPGA's and the the PODS cost an arm and a leg.  Dont they all.  I have a Platform Cable USB but it would be nice to have something open source.  Wonder what Jack uses.

I believe he uses a FT2232-based loader (some of his board have them built in) with J-link (there is a popular app I forget the exact name).

For real JTAG debugging stuff (chipscope, etc) I think I remember he had to buy a parallel PCI card to use an old wiggler.

[quote author="MichaelZ"]
I use a lot of Xilinx CPLD/FPGA's and the the PODS cost an arm and a leg.  Dont they all.  I have a Platform Cable USB but it would be nice to have something open source.  Wonder what Jack uses.
[/quote]

there was recently a whole schematic for the platform cable published in one of xilinx documents .. CY7C68013A+XC2C256+24LC00T-SN+DS2411 and few resistors and leds and there you have usb platform cable :) The best of all is that (if I understood the text correctly) you only need to start the webpack (free from xilinx) and tell it you have usb platform cable it will automatically put the proper code in the i2c eeprom via CY mcu and program cpld too so you just need to splat all the components like they are on the schematic (pages 15,16 (http://http://www.xilinx.com/support/answers/33028.htm)) and it should work. I never worked with CY mcu's but from what I gathered they have some "initial" usb enumeration embedded in them and then you shoot firmware in them via usb so your mcu firmware is actually in the usb driver... so this is how webpack will make your "few parts together on a pcb" to a xilinx platform cable... donno about licences wrt this, but this would be a cool pcb seeed could make :D

[quote author="MichaelZ"]
I use a lot of Xilinx CPLD/FPGA's and the the PODS cost an arm and a leg.  Dont they all.  I have a Platform Cable USB but it would be nice to have something open source.  Wonder what Jack uses.
[/quote]

I think that Jack uses FT2232 with UrJTAG.

That looks right. I'm going to give this a shot now with my CPLDs:
http://urjtag.svn.sourceforge.net/viewv ... o_the_part (http://urjtag.svn.sourceforge.net/viewvc/urjtag/tags/URJTAG_0_10/web/htdocs/book/_usage.html#_burn_flash_connected_to_the_part)

Did another test of this today with UrJTAG. Now I see lots of activity from the CPLDs on the logic analyzer, but UrJTAG isn't reporting any devices.

I'll test again with the known-working examples from IP. I also have a plain FT2232 breakout-board now, I'll build it and try that too in case it is a buffer problem.

i tested my ft2232 jtag with toms jtag utility 1.3 (a simple freeware program for backing up cable modem firmware)

It's working :)

The pins on the buffer footprint were swapped, flipping the TMS and TDI cables made it work :) Took a week to figure it out, but there you go.

Some notes:
*UrJTAG seems to like the real FTDI drivers best
*OpenOCD only like libftdi, which can be installed with this package: http://sourceforge.net/apps/trac/libusb-win32/wiki (http://sourceforge.net/apps/trac/libusb-win32/wiki)
*OpenOCD will detect CPLDs in a chain scan, if the programmer works :)

I'll clean up the schematic and order an initial 20 Bus Blasters today. The cost is a little more than I'd like, mostly due to the buffers. Please weigh in if you plan to buy one:
*As robots noted earlier in this thread, DBGACK and DBGRQ are rarely used, and they aren't even really connected correctly for hi-z output, if needed. We can leave off IC8 (DBGRQ output buffer) because it won't really work in some situations, it should be a tri-state output like the resets.
*I don't think the JTAGkey layout we're using actually supports adaptive clocking, so IC6 can be left out too.
*Best practice is to use pullups to keep the outputs hi-z at chip start. This won't go on the first 20 test boards, but should be on the first large production batch
*according to the buffer datasheet, the inputs should always be loaded to prevent excessive current flow. There should be pullups on inputs, at minimum, and unused pins should be tied to ground. I'll fix as much of this as I can prior to the first 20units (without major changes to the PCB), but an overall revision and re-test is needed before the first large batch.

Next step:
*Fix the footprint
*add pullups
*get quote without IC6, IC8, C18, C25, with pullups

Screenshot of the first successful connection is attached.

---

If it can talk to a Xilinx CPLD I want one.

McZ

That's what I tested it with in the screenshot. I believe UrJTAG will program CPLD and FPGAs with SVF/XSVF, but you might want to check to be sure. It is the utility used with a ton of FPGA boards with FT2232x chips, like Jack's platform.

Here's a picture of the PCB after I figured out the issue. IC 6 and 8 have been removed. IC4 has been hard-wired enabled by soldering pin 14 and 15 to the ground of C21.

Another note:
I'm not planning to populate the EEPROM, and it was not included in the initial quote because it's not needed and to help keep the cost down. The footprint is there is you want to add it.

---

After a minor touch up to the silk we will start manufacturing this.

It's far from ideal, and I've already started a v2 that integrates a CPLD. The logic chips do add too much to the cost, and need further updates. I think it will be easier to use TI's approach with the CPLD, but implement the logic equivalent of the JTAGkey for wide compatibility. If we connect enough pins to thh CPLD and add an EEPROM, v2 can probably pretend to be just about any programmer with any pinout :)

While the first batch of v1 is at manufacturing, we're designing a v2 with a CPLD. If anyone is interested in that project the development is going on here:
http://dangerousprototypes.com/forum/in ... pic=1490.0 (http://dangerousprototypes.com/forum/index.php?topic=1490.0)