Hello,

When FT_SetTimeouts() is not used, standard d2xx read and write API's would not return as they are blocking calls.

When FT_SetTimeouts() is set to say 5 seconds, that would give plenty time for Read and Write API calls and it would return if there were any issues with the Read or Write.

Best Regards,
FTDI Community

Hello,

When using our products in electrically noisy environments, you can try in section 5.1 Adjusting the Reset Pipe Retry Count of AN_107 Advanced Driver Options.

You can also edit the registry, opposed from editing the INF files which breaks driver signing.

Note that registry entry may need to be created:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FTDIBUS\Parameters\RetryResetCount
The default value is 50 so you can try increasing to see if it has an effect.
This can stop USB disconnects in electrically noisy environments.

The above might be something additional to try to see if it helps, otherwise modify your hardware to cope in electrically noisy environments might be the best way forward and check if you are using a USB certified and shielded cable.

Best Regards,
FTDI Community

I posted another topic specifically about detecting FT_SetTimeouts() timeouts in a write/read, but wanted to update this one.

On the system I am working with, I have seen it successfully write/read over 41 million messages (7-112 bytes in length) with zero errors. It's field proven and works well. When we introduced some RF (or possibly power line noise, unclear), the whole communications layer will start having problems. Often, when one of these READ errors is seen, the comms are done until the program is restarted. I am testing just Closing and Re-opening the FTDI connection to see if that is enough. BUT, if a slave device got stuck while clock stretching, I suppose that wouldn't help. FTDI did add a "bus reset" function in one of the recent DLL versions and this sends the clock pulses to try to un-stick a slave, so I have put that in to.

I hope there is a best practices list somewhere rather than "throw stuff at the wall and see if it sticks" like I am doing.

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)