FT2232HL JTAG Interface w/ UART?

[langwadt]

you config doesn't make sense because JTAG is done with MPSSE (but that can always be enabled via software)

245 FIFO is an 8bit parallel interface, that can be enabled via software but only after it has been enabled in eeprom

It's 100% guaranteed to work. I would almost bet 1 million dollars on it.

The configuration of those chips is a bit confusing. Enabling "245 FIFO" in the EEPROM configuration actually makes the chip usable for many other modes, including MPSSE.
The available "hardware" config in FT_Prog are the following: "RS232 UART", "245 FIFO", "CPU FIFO" and "OPTO Isolate". Now what would make you think any of the other modes would make more sense for MPSSE? And AFAIR, if you set the chip for "RS232 UART" (which I think is default?), I'm not at all sure you can use MPSSE. To be confirmed.

And anyway, as I showed above but NorthGuy confirmed, I don't think you can use MPSSE with the VCP driver anyway - which, again, I think is default (TBC as well). So...

I don't doubt that it works, I think MPSEE can always be enabled. Setting 245 fifo mode might just be a way of avoiding the OS loading the VCP driver

[SiliconWizard]

you config doesn't make sense because JTAG is done with MPSSE (but that can always be enabled via software)

245 FIFO is an 8bit parallel interface, that can be enabled via software but only after it has been enabled in eeprom

It's 100% guaranteed to work. I would almost bet 1 million dollars on it.

The configuration of those chips is a bit confusing. Enabling "245 FIFO" in the EEPROM configuration actually makes the chip usable for many other modes, including MPSSE.
The available "hardware" config in FT_Prog are the following: "RS232 UART", "245 FIFO", "CPU FIFO" and "OPTO Isolate". Now what would make you think any of the other modes would make more sense for MPSSE? And AFAIR, if you set the chip for "RS232 UART" (which I think is default?), I'm not at all sure you can use MPSSE. To be confirmed.

And anyway, as I showed above but NorthGuy confirmed, I don't think you can use MPSSE with the VCP driver anyway - which, again, I think is default (TBC as well). So...

I don't doubt that it works, I think MPSEE can always be enabled. Setting 245 fifo mode might just be a way of avoiding the OS loading the VCP driver

No, this last point is handled separately in the EEPROM config, as I showed above. There is a specific setting for the driver you want the OS to load, for each channel: D2XX or VCP. This is completely separate. For instance, you can use the chip in FT245 async FIFO mode (parallel bus) with the VCP driver. Conversely, you can use it in UART mode with the D2XX driver. But for special modes such as MPSSE or synchronous FIFO, you can't use the VCP driver AFAIK.

Maybe MPSSE can be used if the channel is set as RS232 UART and D2XX as well, I don't know, haven't tried. But you'd still need to configure the driver option using an EEPROM.

[NorthGuy]

From FTDI programming manual:

"For Linux, Mac OS X (10.4 and later) and Windows CE (4.2 and later) the D2XX driver and VCP driver are
mutually exclusive options as only one driver type may be installed at a given time for a given device ID. 
In the case of a Windows system running the CDM driver, applications may use either the D2XX or VCP
interface without installing a different driver but may not use both interfaces at the same time."

[SiliconWizard]

From FTDI programming manual:

"For Linux, Mac OS X (10.4 and later) and Windows CE (4.2 and later) the D2XX driver and VCP driver are
mutually exclusive options as only one driver type may be installed at a given time for a given device ID. 
In the case of a Windows system running the CDM driver, applications may use either the D2XX or VCP
interface without installing a different driver but may not use both interfaces at the same time."

I was going to talk about Linux, and this statement is not as easy to understand as it looks.
I have some experience with FTDI devices on Linux, and there is actually no specific driver for them. Not in the true sense. FTDI parts are accessed through libusb on Linux.

The Linux "driver" provided by FTDI is actually just a user-mode library giving D2XX functionality to applications using itself libusb to access the device. This is not really a driver per se.
Then, the equivalent of "VCP" on Linux is also built in the Linux kernel. There's nothing to do or to install for this. You plug the device, and virtual serial port(s) are created. You don't need any software from FTDI for serial port-only functionality. As to the equivalent of D2XX access, there is an open-source alternative called libftdi. It has a slightly different API, but basically gives the same functionality - although I don't know how much of MPSSE it provides.

The headache is that, on Linux, the EEPROM configuration for drivers is IGNORED (as opposed to Windows). So by default, any FTDI device will be enumerated on Linux as a USB serial device.
AND, yes, once they are tied to serial ports, you cannot use the D2XX access (which is the only way to get access to any other mode than UART). Which is really annoying. The solution is to add a udev rule to automatically detach the device from the created serial port(s) so you can use D2XX on it. If the device has an EEPROM with a specific USB VID/PID, then it's annoying, but just requires this specific rule. If the device OTOH has the standard FTDI VID/PID, then it becomes intractable: if you add such a rule, it will apply to ANY device with the default VID/PID. Which may not be what you want.

AFAIK, the same applies to MacOS, as last time I checked, it was also based on libusb on it.

On Windows, the driver selection in EEPROM is used, and thus you can choose which will be loaded, even per channel!

So on Linux(/MacOS), the only solution if you want D2XX access, and not infuriate your customers by blocking all other devices they might use that are FTDI-based with the default IDs, is to program your own VID/PID. Assuming you have a VID. Which is costly. A free option is that FTDI can give you a few dedicated PIDs, and you can still use FTDI's VID. A few years ago, that was a free service, and I made the query. I got 8 dedicated PIDs. But given the scarcity of PIDs (they are only on 16 bits!), I don't know if FTDI still provides this service.

[djacobow]

The headache is that, on Linux, the EEPROM configuration for drivers is IGNORED (as opposed to Windows). So by default, any FTDI device will be enumerated on Linux as a USB serial device.
AND, yes, once they are tied to serial ports, you cannot use the D2XX access (which is the only way to get access to any other mode than UART). Which is really annoying. The solution is to add a udev rule to automatically detach the device from the created serial port(s) so you can use D2XX on it. If the device has an EEPROM with a specific USB VID/PID, then it's annoying, but just requires this specific rule. If the device OTOH has the standard FTDI VID/PID, then it becomes intractable: if you add such a rule, it will apply to ANY device with the default VID/PID. Which may not be what you want.

It just so happens that I've been up to my eyeballs in the FT232H and the FT4232H, on linux, for the past few weeks, and this does not match my experience. What I observe happening on ubuntu is that the devices enumerate into serial ports, but that any software that wants to put them into MPSSE mode just does that and the serial port disappears at that instant.

I've been working with the PyFtdi drivers, which put a python wrapper around libusb and which generally use MPSSE and provide functionality for JTAG, SWD, I2C, and SPI. Oh, and simple bitbang GPIO. The only udev rule I have is one that sets the permissions for the devices to 0777 based on the VID/PID. My programs can then open the ports in whatever mode I want. I can attest that SWD, I2C, SPI, and GPIO all work. I haven't tried regular JTAG. This is all using custom python code except for SWD, which we're using with OpenOCD. My company has a design where we use the 4232 (a four port chip) to do SWD, SPI, I2C, and UART all at once. On the 4232 only the first two ports can do MPSSE, so the I2C is bit-banged.

The chip, in many ways, is magic for us. (If only it supported 1.8V IO) It costs about $8-10 bucks in single-digit quantities (we use it in program/test fixtures) so it's not cheap, and in theory, and microcontroller could do what it does, but I guess you're paying for the libraries.

The EEPROM is optional, by the way. If present, you can use it to set a different VID:PID, serial number, and default modes, but the operating modes can be overridden at runtime, and if you don't have the EEPOM, it just shows up as four serial ports first, but then you can switch things up as you need.

[gnuarm]

Wow, this thread got a lot of action today.

Sorry if I've missed it, but what's the chip you want to access through JTAG? As said above, the FT2232HL can be used as a JTAG adapter (and it's very common in many JTAG adapters actually), but of course, software support must exist for the particular chip you're using. Else you may have to implement that yourself, doable, but which may not be what you intended. So knowing what chip it is is definitely required.

The whole reason for putting this chip on the board is because we want to avoid having to buy programming cables for the Gowin FPGA at $80 each, plus all the extra costs in the EU/UK.  The design was lifted from a Gowin eval board for their device. 

There is a second FPGA board design from Trenz which is very similar, but they appear to support the UART by tying six signals from the B port to the FPGA and adding the EEPROM.  One of the FPGA designers is using a UART, so nice if we can get it all over one USB cable.

Since the JTAG support in on the board, the MCU guy wants to be able to use it as well.  He also wants a UART for the MCU, so why not this one?  It is doubtful both FPGA and MCU will be debugged together much.  Well, in my experience FPGAs require a lot less debugging on the bench because of the extensive simulation. 

Connectors will be added to support direct connection of cables in place of this chip because we don't plan to add the chip for production.

Then a couple remarks: yes the FT2232HL will require an external EEPROM - configured with the FT_Prog utility. The default behavior for the FT2232H, without EEPROM (or blank EEPROM) is, IIRC, two serial ports? To be able to use it in other modes, you need to configure it. Again IIRC, The port you want to use for JTAG must be configured as "FT245" (and then the software takes care of the rest). If it's not in FT245 mode, I don't think software can program it for JTAG. I may have mixed up the default settings though (from bad memory), but either way, I'm pretty sure you'll need to configure the EEPROM for a combination of 1 channel JTAG and the other UART.

Looking at the manual, the EEPROM is needed for ASYNC Serial UART mode.  The EEPROM is not needed for the MPSSE mode.

The other related note is that of course you can absolutely have UART plus JTAG. The FT2232H has two ports. One can be used as JTAG, the other as UART. That again must be configured properly (once) with FT_Prog. This combination is again pretty common in JTAG probes, and even more so on FPGA dev boards. For a simple schematic of that, you can take a look at the schematic of the breakout board for the Lattice MachXO2 for instance.

Good to know.  Thanks  I see the XO2 schematic shows what pin is what serial port function.   I needed that!

[gnuarm]

We are adding a FT2232HL JTAG interface chip to a board being designed to program the FPGA.  It will only be added on the prototypes and not assembled for production saving the cost of the programming cables for every developer which are not cheap. 

The guy programming the MCU has asked to share the JTAG interface, so it will use a buffer chip and a jumper to select which device the four JTAG pins connect to. 

The software guy has also asked to use the serial port that the FTDI chip may or may not have.  I'm not familiar with this JTAG device at all.  Just as important is the driving software.  Does anyone know if this chip can be used for both JTAG and serial port operation without a lot of hassle, like switching between drivers or what ever?  Is this a reasonable goal?

You could also use the FT4232HL (which has the same pinout and is only a little more expensive), connect Port A to the FPGA JTAG port, Port B to the uC JTAG Port and still have Port C and D free as UART ports. I've done just that in one of my recent designs. OpenOCD works just fine, and also the Lattice Standalone Programming tool works with this setup.

Another way is daisy-chaining the JTAG devices (programmer TDO to the TDI of the first device, TDO of the first device to TDI of the second device, TDO of the second device to TDI of the programmer), if the software supports this.

I would love to use a 4 port device, but we are trying to develop a ventilator with a diverse team who have varying skill sets.  Heck, one guy they picked for FPGA work can't get the Lattice tools licensed!  So it will be better to use a design known to work since the big wildcard in all this is the Gowin software.

For the same reason, no chaining of JTAG devices.  Keep it simple and get the job done.

[gnuarm]

As I said, I was challenging my memory on this, but I still thought you needed an EEPROM for having both an UART AND MPSSE, and after re-reading the datasheet, it sounds right.
- You're right, MPSSE itself doesn't need an EEPROM and can be software configured without one.
- BUT as far as I got it, getting a port in UART mode requires an EEPROM. All you can do in software is to set the baudrate, but software only can't configure a port in UART mode without an EEPROM.

The table from the DS can be found in "4.12.1  Do I need an EEPROM?"

the table must be wrong or confusing

https://www.ftdichip.com/Support/Knowledgebase/index.html?98installingft2232cdevices.htm

" If no EEPROM is fitted, the device will default to both channels configured as USB to UART interfaces using VCP drivers. "

Perhaps the key there is "using VCP drivers"?  Is the MPSSE mode compatible with the VCP drivers?

[SiliconWizard]

Again, I told you what I know works. Now do as you wish if saving the cost of a very small EEPROM is worth any potential future trouble. If anything, give provision for the footprint on your PCB, and if after good testing you realize you can do without it, just don't populate it. As I said, I think the VCP driver is default on Windows - to be checked, but it would make sense - and I don't think you can use JTAG with the VCP driver, so that would be end of the story. The the only way to circumvent that would be to bug your users with annoying hand-installing of drivers to replace the VCP one. Very annoying.

The MachXO2 board I mentioned has an EEPROM too. They probably wouldn't have bothered if it was not needed, it was a very cheap (at the time) board. (And no, they don't use any specific VID/PID, and the device string doesn't matter for Lattice tools as far as I've tested, so that was not the reason either.)

As I think someone suggested, if you really want to be sure and make the right decisions for your needs, just buy a breakout board for the FT2232H (there are a handful of them available for cheap), experiment, then decide.

[SiliconWizard]

The headache is that, on Linux, the EEPROM configuration for drivers is IGNORED (as opposed to Windows). So by default, any FTDI device will be enumerated on Linux as a USB serial device.
AND, yes, once they are tied to serial ports, you cannot use the D2XX access (which is the only way to get access to any other mode than UART). Which is really annoying. The solution is to add a udev rule to automatically detach the device from the created serial port(s) so you can use D2XX on it. If the device has an EEPROM with a specific USB VID/PID, then it's annoying, but just requires this specific rule. If the device OTOH has the standard FTDI VID/PID, then it becomes intractable: if you add such a rule, it will apply to ANY device with the default VID/PID. Which may not be what you want.

It just so happens that I've been up to my eyeballs in the FT232H and the FT4232H, on linux, for the past few weeks, and this does not match my experience. What I observe happening on ubuntu is that the devices enumerate into serial ports, but that any software that wants to put them into MPSSE mode just does that and the serial port disappears at that instant.

It's impossible to do this without the appropriate rights on Linux. So the program doing this would need elevated rights. Maybe that's what Ubuntu does with the tools you're using, although I consider this bad practice for security reasons. The simplest and safest way is to use a udev rule.

But yes, you can detach the device from the serial ports "manually" (so any program could do this as well) - I don't remember the exact procedure, but you need to send a specific value to a specific dev path, and again, with the appropriate rights. With basic user rights, that won't work.

Since that was a long-time problem with FTDI devices, maybe FTDI has added this feature in recent versions of their Linux "driver" (but I insist, tha would require to give the program proper rights.)

There are a lot of articles on this issue over there. One of them: https://stackoverflow.com/questions/33649296/how-can-i-get-linux-device-with-ftdi-d2xx-driver-api

[djacobow]

It's impossible to do this without the appropriate rights on Linux. So the program doing this would need elevated rights. Maybe that's what Ubuntu does with the tools you're using, although I consider this bad practice for security reasons. The simplest and safest way is to use a udev rule.

This is the only FTDI-specific udev rule I have added to my system:

Code: [Select]

ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6011",MODE="0777",GROUP="dialout"
ATTRS{idVendor}=="0403",ATTRS{idProduct}=="6001",MODE="0777",GROUP="dialout"

With these rules I can open the devices serial ports as a regular user member of the dialout group, and I can also use them in MPSSE or GPIO mode using OpenOCD and PyFTDI.

I guess other users could do the same, so I suppose that is a security issue if you have other users.

By the way, I don't have EEPROMS on any of my boards. The EEPROM is really just a convenience, nothing more. You just don't need it. I would say, however, that it would be convenient to have serial numbers and a few other EEPROM features, and for that reasons I have designed in the EEPROM for the next rev of our board.