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] 4 5 ... 56
Discussion - Hardware / Re: VNC2 à la place de VNC1L
« on: December 01, 2022, 10:09:36 AM »

You can have a look at VNC2 UART to USB Memory Bridge. This project uses V2DAP firmware and also provides sample code. You can change the Baud rate using FT_PROG. This is shown on page 7 of the pdf.

VNC2 does work differently from VNC1L. Vinculum II User Guide will be able to help you with using the command set. It provides descriptions and examples of the different commands you can use.

Best Regards
FTDI Community


You can have a look at Establishing Synchronous 245 FIFO Communications using a Morph-IC-II. This gives an example utility you can try, along with some sample code. The sample code can be found here: https://ftdichip.com/wp-content/uploads/2020/12/Synchronous%20245%20Morph-IC-II%20Application.zip.

Best Regards
FTDI Community

Discussion - Hardware / Re: FT231X vs. USB-C - doesn't work!
« on: November 29, 2022, 05:00:18 PM »

Please see TN_181 Type-C USB Connectors with FTDI Products which should help you.

You are missing 5K1 resistors on the CC1 (A5) and CC2 (B5) lines which are required.

You may have got these mixed up with A8 and B8.

Also there should be 27ohm an 47pF on the USB data lines. I can see 22ohm in your design which is incorrect.
See AN_146 USB Hardware Design Guidelines for FTDI ICs for more details.

Best Regards,
FTDI Community

Hi Yvonne,

This can happen when the HID device is toggling DATA0/DATA1 without handshakes from the host. HID devices can do that sometimes, it’s even mentioned in the USB spec. You need to do a ClearFeature endpoint halt on the interrupt endpoint before reading it again.

In the code you are using to clear the halt state, the endpoint should be the interrupt endpoint instead of epCtrl in line 2. If you change this, it should clear the halted endpoint.

Best Regards

FTDI Community

Discussion - Software / Re: FT260 changing Baud rate
« on: November 24, 2022, 04:33:42 PM »

you need to change the Baud rate in the sample code and then rebuild it.

ULONG ulBaudrate = 115200;
    if (FT260_UART_SetBaudRate(handle, ulBaudrate) != FT260_OK) {
        printf("UART Set baud NG : %d\n", ftStatus);

So change 115200 to 9600 and then rebuild the example.

Best Regards

FTDI Community

Discussion - Software / Re: FT260 changing Baud rate
« on: November 23, 2022, 03:12:38 PM »

Have a look at FT260 User Guide. This shows how to set the buad rate on FT260.

Best Regards

FTDI Community

Discussion - Software / Re: Regarding use of FT260 librabry examples
« on: November 16, 2022, 01:45:27 PM »

The examples given for LibFT260 are intended to be used with visual studio. you can use the community version, which is free.

Best Regards

FTDI Community

Discussion - Drivers / Re: FT_GetDeviceInfoList non-ASCII serial problem
« on: November 15, 2022, 04:35:59 PM »

The solution would be to only use Serial Number or Description with ASCII characters.

You can use D2xx Programming functions in Linux to reprogram or you can use FT_PROG on Windows.

The alternative driver that you can try is LibFTDI which is an open source library/driver but is not created/supported by FTDI:


This third party solution includes the source so may suit you if you need to make changes to the source.

Best Regards,
FTDI Community

Discussion - Software / Re: SPI read delay in FT2232H with libMPSSE
« on: November 14, 2022, 04:08:47 PM »

There may be a number of factors due to the nature of USB to take into consideration. 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.
FTDI devices use USB Bulk transfers and those are designed to transfer large amounts of data with error-free delivery, but with no guarantee of bandwidth.
You could try disconnecting all other USB device to see if it has an effect.

You may also want to try and reduce the latency timer.
The default latency timer is 16ms when using the FTDI drivers.
The latency timer can only be set to 1ms for our USB High Speed products (like FT2232H).

You can read more about this in Data Throughput, Latency & Handshaking.

The other option that you might want to explore is by not using LibMPSSE.
You could try using the D2xx drivers direct and implement your own SPI communication.
See AN_108 Command Processor For MPSSE and MCU Host Bus Emulation Modes which should help.

Also there may be other FTDI Community users who might be able to help you further.

Best Regards,
FTDI Community

Hi Suman,
As you have already contacted us via email on this subject and we have an ongoing discussion there i will continue with the email rather than posting here

FTDI Community


Here is some information that should help you:

1.   USB cable disconnected.
FT_CyclePort() can re-initialise the USB port.

2.   I2C bus lock up.
This contains two situations. I2C clock lock up and I2C data lock up.
Please refer to the external link https://espace.cern.ch/CMS-MPA/SiteAssets/SitePages/Documents/I2C_bus_specifications_V2_0.pdf
Page 5 section 1.3.
a. FT4222_I2CMaster_ResetBus() only can solve the data line (SDA) being stuck LOW.
When SDA is stuck low, you can run following functions.
a.1 ft4222_status = FT4222_I2CMaster_Reset(i2cmHandle);
a.2 ft4222_status = FT4222_I2CMaster_ResetBus(i2cmHandle);
It can reset the i2c master state machine and unlock the SDA bus.

b. When the clock (SCL) is stuck LOW, we think a hardware reset is necessary.
You can run the following functions.
b.1 ft4222_status = FT4222_I2CMaster_Reset(i2cmHandle);
b.2 ft4222_status = FT4222_I2CMaster_ResetBus(i2cmHandle);
b.3 Use GPIO pin to signal the i2c slave and force it to perform a HW reset.

I hope this information is helpful to you.

Best Regards,
FTDI Community

Hi Yvonne,

The 1MHz clock should be theoretically possible. It states in section of the VNC2 user guide that The SPI Slave and SPI Master can operate at frequencies up to one quarter of the CPU clock frequency. The SPI Master can go as low as 1/256th of the CPU clock frequency.

You should have a look at section 6 of Vinculum II User Guide, this goes over the interrupt library available on VNC2. The sample code you have modified had interrupts disabled, but you can enable them. you can try to use the function attachInterrupt() on vos_dev_write to see if this fixes your issue.


Hi Yvonne,

Does this happen when you use the example code unmodified?

What SPI mode are you using? Have a look at section 6.2 of the Vinculum-II Datasheet. This goes over the different SPI modes available and the following sections give timing diagrams.

Best Regards
FTDI Community 


The feedback from our R&D team is that there is nothing that can be done with the library.

The issue is not related to the driver but the I2C IP.

Adding a delay is the only solution.

Best Regards,
FTDI Community


This will be included in the LibFT422 release notes in future releases.

I will also check if anything can be done in the driver or library to help improve this.

Best Regards,
FTDI Community

Pages: 1 2 [3] 4 5 ... 56