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 ... 44

Have you unloaded the VCP driver? You need to in order to use the D2xx drivers.
See the Mac OS X Installation Guide for more information.

Best Regards
FTDI Community


You should try uninstalling the drivers using our CDM uninstaller utility. Then install our windows driver:


However Device Descriptor Request Failed usually points to a hardware issue. Please contact your local support team and include your schematics:


Section 3.2.2 of the device datasheet describes the pin configuration to use the device asynchronous mode.

Best Regards,
FTDI Community

Discussion - Drivers / Re: VCP driver on macOS 11
« on: September 20, 2021, 02:12:53 PM »
Hello Scott,

Thank you for the details.
The Latency timer and buffer settings are the correct settings to alter in this case.

However as I'm sure you have noticed performance on different machines can vary, this is due to the inherent nature of USB.

USB products can’t reliably be used in real-time applications with time interval resolution guarantees.

Sometimes the behaviour of USB can be a problem and applications cannot be guaranteed throughput.
If there is more USB traffic then the OS and USB have to schedule the communication with each of the USB devices.
It’s highly dependent on the OS and USB Host and is out with our control.

You could take a look at the following App notes:

Data Throughput, Latency & Handshaking
Optimising D2XX Data Throughput

These apply to all of our USB products.

The latency timer can only be set to 1ms minimum for our High Speed USB products and nothing less, and 2ms for our Full Speed USB products (like FT232R inside the USB-RS485-WE cable).

Best Regards.
FTDI Community

Discussion - Drivers / Re: VCP driver on macOS 11
« on: September 17, 2021, 02:50:05 PM »
Hello Scott,

Thank you for your question.

I would like to apologise that you haven't be able to contact any via phone in the UK office, unfortunately we are still working form home currently.

We are currently investigating how to generate a codeless .dext wrapper for any Info.plist modifications which might be required by an end user.
Is this what you are trying to achieve?

Could you describe the latency issues you are seeing?

Hello.  My name is Scott Miller and I am a BCI researcher.  I too am experiencing severe latency issues with the VCP driver on macOS 11.  I am using a MacBook Pro M1 running the latest version of Big Sur.

I read this entire thread and several others blog threads across the internet.  I emailed and spoke with Cameron from FTDI tech support in Oregon.  Cameron was very helpful.  He let me know that the latest 1.4.7 driver runs on both x86_64 and arm64.  I tried modding the 1.4.7 driver on my M1 but ran into the same code signing issues described by others in this thread.

Cameron also reached out to the FTDI team in the UK on my behalf.  That team replied with some links which talk about how to build my own driver, but that's not very useful to me at this point in time.

I also tried calling tech support in Glasgow, during normal working hours in GMT, but was unable to reach anyone at all.  The voice mailboxes are all full, and not even an operator answered my calls.  I tried repeatedly.

I suspect that FTDI is for some reason unable to obtain a DriverKit entitlement from Apple.  Is that the case?  Has FTDI made any progress on this issue?

Best Regards,
FTDI Community.

Discussion - Hardware / Re: VCN1L Bootloader wiped/corrupted
« on: September 03, 2021, 03:51:55 PM »

Please work with your local support team on this issue and post any resolution here to help other community users.

Best Regards,
FTDI Community

Discussion - Software / Re: FT260 - Pauses in I2C comunication.
« on: August 31, 2021, 01:32:11 PM »

Glad it helped,

Yes, the FT4222H offers one SPI Master (SCK/MOSI/MISO) with up to four chip selects,  or one Quad SPI (this uses four bi-directional data lines and is used by some devices such as flash chips or Bridgetek EVE chips) or one I2C Master or one SPI slave (MOSI/MISO/SCK).

It uses hi-speed USB and bulk transfers and so offers quite a lot more throughput,

Best Regards, FTDI Community

Discussion - Software / Re: FT260 - Pauses in I2C comunication.
« on: August 31, 2021, 11:11:39 AM »

The FT200XD and FT201X are only I2C slaves and cannot act as a host to a sensor etc. and so if you need the FTDI device to be a master, I'm afraid this isn't suitable.

FT4222H or FT232H would be possible options,

The FT232H MPSSE is more generic and so needs to talk back to the PC for each byte so your code can check ack/nak and so if you need to check these per byte before proceeding to the next, and so the rate might not be enough unless you can do a burst without checking ack/nak (for write) or deciding ack/nak (for read) in real time.

The FT4222H might be the fastest device if you need to determine or check ack/nak in real time or features like clock stretch etc.

Best Regards, FTDI Community

Discussion - Software / Re: FT260 - Pauses in I2C comunication.
« on: August 31, 2021, 09:56:43 AM »

Thanks for your updates and for your inputs too Allen,

Yes unfortunately the USB transfers are limited to 64K on the interrupt endpoints and so although the device can run at 12Mbaud and 3.4M I2C, the actual throughput will not match these.

We specify this on page 12 of the datasheet but it is in amongst the text and is also not directly referring to the baud and I2C rates. We can look at improving the datasheet to make sure that this limitation is clear and stated explicitly as you suggested,

Sorry to hear the FT260 is not suitable. The FT260 is ideal for many uses as it uses HID class but the throughput is limited by this. We have other hi-speed USB devices which use bulk transfers such as the FT4222H which might be an option for you,
Bulk transfers don't offer guaranteed bandwidth at any instant as the bandwidth is shared with other devices and so can depend what other devices you have connected to the PC, but the overall bandwidth is usually much higher than this 64K interrupt transfer on the FT260.

Best Regards, FTDI Community

Hi Radka,
How the parts enumerate could change depending on what other devices maybe connected to the system, if the connections were consistent the enumeration could be the same but couldn’t be guaranteed.

With regard to your comment "I tried uninstalling the driver and installing a new one ( No success."  Do you mean  you had issues installing the 36.4 driver or that it just didn't help in stabilising the enumeration of the connected devices?

FTDI Community 

Discussion - Software / Re: Another bug found in the Vinc compiler.
« on: August 26, 2021, 03:36:42 PM »
Hi Willy,
We have replicated the observed issue and are working on it.
If/When a fix is in place i will follow up with you. 

FTDI Community

Discussion - Software / Re: BUG found in the VinAsm tool ?
« on: August 23, 2021, 05:19:29 PM »
Hi Willy,
It maybe a bug, but not a known one.   
We have been unable to replicate the issue you observed here .  It might be due to the level of optimisations? What optimisation level are you working at?   

FTDI Community


You are already in contact with our technical support team on this matter.

Please feel free to post any resolution here to help other community users.

There may also be other FTDI Community users who will be able to help you.

Best Regards,
FTDI Community

Discussion - Hardware / Re: FT260 GPIO initial output state
« on: August 20, 2021, 01:07:08 PM »

have a look at https://ftdichip.com/wp-content/uploads/2020/08/AN_184-FTDI-Device-Input-Output-Pin-States.pdf. This application note goes over the I/O pin states of our devices, section 22 is for the FT260.

we also have a couple of software examples for the FT260 that may be able to help you. The folder for the code examples can be found here: https://ftdichip.com/products/ft260q/ under the downloads tab, you should have a look at the GPIO and GPIO_OpenDrain examples.

Please let me know if you have any more questions





One thing to check is that you have set timeouts to a finite value (e.g. 5000ms) which will avoid the read and writes hanging if they are unable to complete. You should check the status value once a call returns as well as comparing the sizeTransferred, which is provided by the read and write functions, to what you had requested, to see if all data was written/read.

Best Regards, FTDI Community


Thanks for your update,

Yes it sounds like another device may be holding the clock low and so it depends if this other device can release the clock or if it has locked up and may need reset. You could try disconnecting the I2C lines for each device on the bus to check if the other device has got the line held low,

Best Regards, FTDI Community

Pages: [1] 2 3 ... 44