FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  


Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support

New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - FTDI Community

Pages: [1] 2 3 ... 29

We have measured i2c write/read on Windows and Linux platform.

The test consists of:
1.            Read / Write 10 bytes
2.            Using different frequency 500Kbps/1000Kbps/3400Kbps

The difference is very small:

Linux i2c write                                 
500Kbps  1000Kbps   3400Kbps
305us      206us        250us

Windows i2c write                                         
500Kbps  1000Kbps   3400Kbps
309us      170us        250us

Linux i2c read                                   
500Kbps  1000Kbps   3400Kbps
818us      760us        577us

Windows i2c read                                           
500Kbps  1000Kbps  3400Kbps
712us      660us       652us

So this shouldn't cause an issue of data within 10ms of data available.

You are also in contact with our support team via email. Please work with the support person and post any resolution here to help other community users.

Best Regards,
FTDI Community

General Discussion / Re: Can a timeout be set on FT_purge?
« on: July 02, 2020, 05:41:07 PM »

Yes FT_IO_ERROR does point to a hardware issue.

D2XX functions are thread safe.

Best Regards,
FTDI Community


In Linux, 'FT4222 A' is the interface 0 description of device. Not the chip code of the device.
See code output below:

Code: [Select]
cc get-version.c -lft4222 -WI,-path,/usr/local/lib

Device 0: 'FT4222 A'
  Chip version: 42220400, LibFT4222 version: 01040409

I have requested support from our R&D engineers to see if there are any known issues with LibFT4222 which could cause issues like you are seeing. Please expect significant delays in the process.

Best Regards,
FTDI Community

General Discussion / Re: Can a timeout be set on FT_purge?
« on: June 29, 2020, 04:31:34 PM »

It sounds like some sort of hardware issue has occurred as you have suggested.

FT_SetTimeouts sets the read and write timeouts for the device. It won't have any effect on the other functions.

You could test out some of the other available commands to see if they would help reconnect with the failing hardware:


FT_CyclePort could be the best option, this is like a physical unplug/replug.

Also check the API function return codes which might give you more information on the failure mode.
For example, FT_IO_ERROR usually points to an issue with the hardware.

Best Regards,
FTDI Community


The description in the chip will be shown when the device is initially connected but in device manager Windows will replace the name with those taken from the inf files of the driver (e.g. USB Serial Port). This will happen for other USB devices too including our other USB-serial chips.

To change the string, you would need to edit the inf files but the latest versions of Windows have these digitally signed and so if you edit these you would not be able to install the driver in normal user mode on Windows. If your device was to be distributed to customers you would normally get a custom PID and program the device with this and have a driver edited to match your PID along with the new strings. You would then get reseller rights from Microsoft to re-sign your driver. Microsoft require you to purchase an EV certificate and so this would involve costs.

An alternative is to keep the VID/PID and the inf file as default, but to open the device using our D2xx driver as you can open by description. This means your application can find the device with no effort by the user. As a trade-off you would not get your device name in the device manager but on the other hand it saves cost and time. But if your main objective is to make the device easy to find and open with minimal hassle to users then this might be a good solution.

If you already have an application on Windows that uses VCP, you can even open the device by description in D2xx, check the COM port number via FT_GetCOMPortNumber and then close it and pass this to your VCP program.

Best Regards, FTDI Community


You are using a very old revision of silicon.
Please test with the latest revision of FT4222H silicon which is Rev D.

You can find the chip errata here:

FT4222H Errata Technical Note
FT4222H Rev.D Technical Note

Also ensure that you are using the latest versions of LibFT4222 found here:


Best Regards,
FTDI Community


The libMPSSE uses separate FT_Write commands to send each part of the SPI transaction and so there will be a delay between the data and the CS operations as each FT_Write will be a new request to the host controller and will be at least on the next USB uframe (could be longer depending how the host schedules it). This is to make the library more generic as SPI peripherals have many different requirements.

As you mentioned, you can use D2xx and you can send the chip select GPIO command and the clocking command and data and the CS de-assert GPIO command all in one buffer with one FT_Write. If you add all these into one data array and pass to FT_Write, there will be much less delay between them (almost no delay between CS and data if you only clock in/out a few bytes).

When you have a known peripheral which needs a certain sequence, optimising the code like this will make a big improvement.

We also have the source code of libMPSSE and you can make the same change there.

Best Regards, FTDI Community


It sounds like your external EEPROM is not being recognised.

Please email your local support team with your schematics for review:


Add an external 93C46 (93C56 or 93C66) EEPROM is recommended.

The EEPROM must be a 16 bit wide configuration such as a Microchip 93LC46B or equivalent capable of a 1Mbit/s clock rate at VCC = +3.00V to 3.6V.
If no EEPROM is connected (or the EEPROM is blank), the FT4232H will default to serial ports, which is what is shown in your post.

Please see our Development Modules for reference:

FT4232H Mini-Module
FT4232H-56 Mini-Module

We have used a 93LC56B external EEPROM.

Please check compatibility of 93LC66D. It seems to have an ORG pin to select 8 or 16 bit wide configuration.
Also from Microchip website: Status: Not Recommended for new designs.

Best Regards,
FTDI Community


I have no knowledge of the Al Thinker ESP32-CAM or the ESP32 Wrover Module, do these include FTDI ICs?

Can you take some screenshots of the devices in the hardware monitor similar to the attached screenshot?

Best Regards,
FTDI Community

Discussion - Software / Re: FT_Prog on Windows 10
« on: June 18, 2020, 05:11:07 PM »

Which error are you seeing in this case? If you use the GUI version below can you successfully scan the devices or do you get an error?


Best Regards, FTDI Community


Which revision of silicon are you using?

Erratum 0005 only applies to RevA silicon so if you are using that, please use the latest revision of silicon (Rev B).

See the following PCNs for more information:


Best Regards,
FTDI Community

Discussion - Software / Re: D2XX Write Problem
« on: June 01, 2020, 04:31:43 PM »

This sounds like a issue with your custom application rather than the FT9xx.
Maybe others in the community will be able to help with your issue, but please note there is a Bridgetek forum available for our MCU products. Please see the link at the top of the page.

Have you tried outputting debug on UART while not in debug mode to help resolve your issue?

Please see our software examples for reference for outputting debug text via the UART interface:

AN_360 FT9xx Example Applications

The difference between debug and release is that the debug build contains debug symbols used by the debugger.

Best Regards,
FTDI Community


The application code on the PC would enter MPSSE mode then I2C can be configured.

External pullups are required.

The pins required are clear in the documentation:


Note that from AN_135, DO must be connected to DI externally as well.

Best Regards,
FTDI Community

Discussion - Software / Re: FT232H GPIO use as I2C SDA
« on: May 28, 2020, 02:51:45 PM »

It is possible to use AC0-AC7 as GPIO but AC8/9 are not controllable in MPSSE mode.

You can use MPSSE bit-bang to implement I2C although it will be slower than the usual MPSSE-assisted I2C as it is entirely bit-banged.

We have a small example below which was originally for FT2232H/FT4232H where users wanted open-drain but as it uses MPSSE bit-bang it may be a starting point. it uses the default I2C pins but you could re-code the values so that it drives other pins instead. if using multiple sets of SDA and SCL you would need to implement the I/O writes as mask values so that using one set of pins does not affect to the others (or have a copy of the functions for each pair of I2C pins and just make all other lines an input in each function and call only one at a time). Note that this is just an unofficial example and is not guaranteed or fully evaluated,

BitBang Example

Alternatively, you can get I2C muxes which allow you to have more than one device of the same address, such as

Hope one of these help,

Best Regards, FTDI Community

Discussion - Drivers / Re: FTDI VCP driver on macOS Catalina
« on: May 27, 2020, 03:44:29 PM »

Please see the following post for a resigned version of the driver:

Best Regards,
FTDI Community

Pages: [1] 2 3 ... 29