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

Pages: [1] 2 3 ... 10
 on: July 06, 2020, 04:34:38 PM 
Started by krish_iyer - Last Post by FTDI Community

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

 on: July 02, 2020, 05:41:07 PM 
Started by stijn - Last Post by FTDI Community

Yes FT_IO_ERROR does point to a hardware issue.

D2XX functions are thread safe.

Best Regards,
FTDI Community

 on: July 01, 2020, 04:55:20 PM 
Started by krish_iyer - Last Post by 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

 on: June 29, 2020, 09:59:47 PM 
Started by activerfid - Last Post by activerfid
Thanks for the prompt feedback.

In this case it was easier to modify our application to look for USB Serial Port, in the hope that nothing else will be plugged in with the same converter in it.


 on: June 29, 2020, 05:26:02 PM 
Started by stijn - Last Post by stijn
Thanks for the reply!
We're already using FT_CyclePort and in the event of e.g. FT_IO_ERROR (which is indeed what we mostly get) after FT_Read or FT_Write we use it to succesfully reconnect.
However we can only do so when there's effectively an error, which isn't the case if FT_Purge never returns..

So is it correct that there's no way to keep FT_Purge from blocking? That would mean we cannot really use it, as it stalls the software in case something goes wrong; well, I guess unless we use a separate thread to measure how long it's been running and then call FT_CyclePort from the other thread but I'm not sure the FTDI functions are threadsafe for use like that?

 on: June 29, 2020, 04:31:34 PM 
Started by stijn - Last Post by FTDI Community

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

 on: June 29, 2020, 03:53:45 PM 
Started by activerfid - Last Post by 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

 on: June 29, 2020, 02:00:29 PM 
Started by activerfid - Last Post by activerfid
Using FT_Prog I am able to enter a new Manufacturer and Product Description and then I program the FT234XD (on a UMFT234XF Board)

Scan and Parse then confirms that the details have changed.

However, when viewed in Device Manager, under Ports (Windows OS) the Description still shows as ‘USB Serial Port’

Is there something different about the FT234XD on the UMFT234XF or is it locked in some way or is the description not the same as that shown in Device Manager?

I want to iterate through Device Manager in my application so I can find a particular USB device by name.


 on: June 27, 2020, 04:20:57 PM 
Started by krish_iyer - Last Post by krish_iyer
Ok, here's the issue.  imprint on my chip ends with 'D' hence I am actually using revision 'D' of the silicon. In windows with "FT prog" software, my chip version is detected as 'D' but in linux it's 'A'. Also, I am using latest Llibft4222(linux) version.

I am using Ubuntu 18.04 on 64bit machine.

am I missing something?

 on: June 26, 2020, 05:03:32 PM 
Started by krish_iyer - Last Post by 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

Pages: [1] 2 3 ... 10