It is my understanding that FT_SetTimeouts() will cause a Read/Write to timeout. How can you tell if this happened? I did not see an obvious return code.

ftStatus = FT_SetTimeouts (ftHandle, 5000, 5000);

...

ft4222Status = FT4222_I2CMaster_Read (ftHandle, address, buffer, bufferSize, &sizeTransferred);

In this I2C example, suppose the slave device invoked clock stretching and held it longer than 5000ms. I would expect the Read call to return due to the SetTimeouts.

We sometimes see unexpected FT4222_FAILED_TO_READ_DEVICE errors, so I added code to print any time "bufferSize" and "sizeTransferred" do not match (and did the same in the Master_Write. I am not seeing those print, but I do see the program hang for 5 seconds from time to time, which makes me think it's being stuck in I/O then timing out.

Thanks, much. I am working on a project that uses FTDI I2C to communicate between a host PC and almost 30 boards using a write/read protocol. While it's been proven very solid (I've personally tested it with over 41 million messages with 0 errors), if/when a line glitch does happen, I want to make the master code robust.

Hi,

Thanks for the information. I will pass this on to the developers and raise a bug. It will be fixed in the next release of the library. 

Best regards

FTDI Community

There were 3 errors in the FTDI LibMPSEE.dll source code.

This is library release 1.0.3, in file LibMPSSE_1.0.3.zip found at https://ftdichip.com/software-examples/mpsse-projects/libmpsse-i2c-examples/


1.  See http://www.ftdicommunity.com/index.php?topic=644.0 - post made August 16, 2022, 10:48:47 AM

I2C_Read8bitsAndGiveAck(...) function, in $\LibMPSSE_1.0.3\source\ftdi_i2c.c, around line 941 - change:

buffer[noOfBytes++] = DIRECTION_SCLOUT_SDAOUT;  // was DIRECTION_SCLOUT_SDAIN; make SDA output to provide read ACK

2. Related to #1:

I2C_FastRead(...) function, in $\LibMPSSE_1.0.3\source\ftdi_i2c.c, around line 1314 - change:

outBuffer[i++] = DIRECTION_SCLOUT_SDAOUT;   // was DIRECTION_SCLOUT_SDAIN; make SDA output to provide read ACK

3. I2C_FastRead(...) returns number of bits read always, not bytes

I2C_FastRead(...) function, in $\LibMPSSE_1.0.3\source\ftdi_i2c.c, around line 1324:

In the released code, it has the statement:  *sizeTransferred = j;where 'j' is the number of bits to be read.  However, this only is correct for option flag I2C_TRANSFER_OPTIONS_FAST_TRANSFER_BITS if the actual bits read match the requested bits to read (this statement may be premature - may be better to wait for actual read), as I read the manual and the code comments.

(A) Put this statement behind something like: 

if (options & I2C_TRANSFER_OPTIONS_FAST_TRANSFER_BITS)
(B) Below this code, towards the bottom of the function, there is released code:

if (options & I2C_TRANSFER_OPTIONS_FAST_TRANSFER_BYTES)
    status = FT_Channel_Read(I2C, handle, bytesToTransfer, buffer, &bytesRead);

Replace this with something like:

if (options & I2C_TRANSFER_OPTIONS_FAST_TRANSFER_BYTES)
{
    status = FT_Channel_Read(I2C, handle, bytesToTransfer, buffer, &bytesRead);
    *sizeTransferred = bytesRead;
}


My second question still stands:

    Is there an API that I can use to ensure that the previous transmission finished?

I have been down this rabbit hole. There is not. You just know the data has been handed out to the FTDI driver.

This is a problem, because there is a get status call that should tell you if it is busy, but due to a hardware issue in the FTDI chip, if you call that while data transfer is in progress, it can corrupt that data.

It appears the change also needs to happen in I2C_FastRead(...)

BTW - this happens at every speed I've tried - 100kHz, 400kHz, 1Mhz.

I'm using LibMPSSE_1.0.3 and encountered a problem doing multi-byte reads using I2C_DeviceRead on an FT2232H (FTDI-Click board).  The FT2232H reads the first byte (from an EEPROM) correctly, but shows a NACK.  This causes the following bytes to be read as 0xFF, 0xFF, etc. which also have NACKs.

I'm using the command:

      FtStatus = I2C_DeviceRead(FtHandle, SlaveAddress, sizeof(ReadData), ReadData, &SizeXferred,
                     I2C_TRANSFER_OPTIONS_START_BIT |        // Give repeated start after address write
                     I2C_TRANSFER_OPTIONS_STOP_BIT |
                                I2C_TRANSFER_OPTIONS_FAST_TRANSFER_BYTES );

I also tried:

      FtStatus = I2C_DeviceRead(FtHandle, SlaveAddress, sizeof(ReadData), ReadData, &SizeXferred,
                     I2C_TRANSFER_OPTIONS_START_BIT |        // Give repeated start
                     I2C_TRANSFER_OPTIONS_STOP_BIT |
                     I2C_TRANSFER_OPTIONS_NACK_LAST_BYTE);

This also reads the data back as <correct 1st byte>, 0xFF, 0xFF...

This appears to be related to an older post: http://www.ftdicommunity.com/index.php?topic=241.msg741#msg741

Given the age of the previous post, and that it refers to lib SW which I can no longer find (for example, the poster refers to changing an "if 1" statement to an "if 0" statement on line 1400 of ftdi_i2c.c - and there's no statement anything like that in the latest ftdi_i2c.c), I'm wondering the following:

• Did this bug get fixed going from previous version (0.6?) to 1.0.3?
• If not fixed, is anyone acquainted with this problem and have a solution?
• If fixed, what settings in the function call will properly read multiple bytes?

Thanks,
Bryant (just getting started with FTDI devices, appreciate the help)

Hi Scott,

The only vendor class devices supported by VNC2 are FTDI vendor class devices.

You should have a look at the FT90x series that is made by our sister company Bridgetek. FT90x is a programmable host controller, like VNC2, however it is open source so you can create your own software.

Best Regards
FTDI Community

Hello,
Is it possible to connect a vendor-specific device to the V2DIP2 module? I want to use VNC2 as the host to communicate with a WinUSB device. Is there an example available to demonstrate how to write the firmware driver?

Hello,

You can use the MPSSE Engine to control those pins as GPIO.

See AN_108 Command Processor For MPSSE and MCU Host Bus Emulation Modes for more details.

Alternatively you can use bit bang mode but you will be limited to 8 pins on the D bus and 4 pins on the ACBUS (9, 8, 6 and 5).
See the following documents for more information about bit bang mode:

AN232R-01 Bit Bang Modes for the FT232R and FT245R
AN_373 Bit-Bang Modes for the FT-X Series

These are for a different products but same principles apply.

Best Regards,
FTDI Community