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

We have been using these chips for years along with a Windows host program. We start getting FTDI errors when we are doing PWM pulsing of an RF signal in our product. In my system logs, I start seeing read errors from one of our boards, and then all the rest (as if the FTDI driver itself is messed up; inspecting the I2C line with a Saleae logic analyzer shows it is not locked):

20230724 092734.302 FTDI Read 100 (Exc): Status 1011 (FT4222_FAILED_TO_READ_DEVICE).
Restarting our Windows host resumes, so I expect we should be able to recover in software. I've tried doing Bus resets, Master resets and other things, and can make it continue, but there is usually a hang long enough that it shuts down our boards (for safety, they shut down if they don't hear from Master Control Program ;-).

Does anyone have any tips on what can be done with an I2C read or write returns one of these errors? One it happens, our system is basically a brick until I restart the Windows host program.

Thanks, much.