Since the bug in the FTDI I2C chip presents using FT4222_I2CMaster_GetStatus() after a write (unless you can wait long enough to know the write has completed), I came up with a workaround.

We blindly write our our message (without knowing if anything saw it and ACK'd it), then we go to read our special protocol.

We read the first two bytes (a start code, and number of data bytes) like this:

// Read two bytes (Start Code, Number of Data Bytes).
ft4222Status = FT4222_I2CMaster_ReadEx (ftHandle, deviceAddress, START, buffer, 2, &sizeTransferred);
Initially, I thought we might be able to use GetStatus() hear and see if the READ was ACK'd, but it will return a BUS_BUSY due to the ReadEx being in the middle (no STOP bit yet). At least that's what it looks like -- always BUS_BUSY until I do the second ReadEx.

I do a check like this:

// Fake it. Reads from non-responding devices will return FFs.
if ((buffer[0] == 0xff) && (buffer[1] == 0xff))
{
    // Nothing responded, or other issue.
}
...BUT, this means I never got to the second half of the ReadEx that completes it, with the STOP:

ft4222Status = FT4222_I2CMaster_ReadEx (ftHandle, deviceAddress, STOP, &buffer[2], messageSize-2, &sizeTransferred);
/code]

How can I just send the "STOP"? I tried this (ReadEx with 0 bytes) and that doesn't do it:

[code]// Fake it. Reads from non-responding devices will return FFs.
if ((buffer[0] == 0xff) && (buffer[1] == 0xff))
{
    // Nothing responded, or other issue.
    FT4222_I2CMaster_ReadEx (ftHandle, deviceAddress, STOP, buffer, 0, &sizeTransferred);
}
Looking at the I2C line in my Saleae analyzer, I see no STOP bit, though the next write/read is still able to happen.

How can I send a STOP without reading data? Is that possible?

As has been reported elsewhere in this forum...

https://www.ftdicommunity.com/index.php?topic=822

...problems can happen if you try to use FT4222_I2CMaster_GetStatus() after a Write operation if the Write has not completed.

See: https://ftdichip.com/wp-content/uploads/2022/03/TN_161_FT4222H-Errata-Technical-Note.pdf
Section 3.4.2

FT4222_I2CMaster_GetStatus() is used to determine if the I2C write was ACK'd by a device. But, you are told to only use it AFTER transmisson is complete:

Read the status of the I2C master controller. This can be used to poll a slave after i2c transmission is complete.

One of the GetStatus bits is "BUS BUSY" and it seems you could have used it to determine when a write was complete, but due to the problem in the FTDI chip, you cannot. I suspect something like this was the intent:

// This WILL NOT WORK. See:
//
// TTN_161 FT422H Errate Technical Note
// Version 1.5
// Document Reference No.: FT_001198
//
// Section 3.4.2
// 'I2C data is corrupt when FT4222_I2CMaster_GetStatus" is being called'
//

// Write message.
ft4222Status = FT4222_I2CMaster_Write(ftHandle, deviceAddress,
&msg[0], sizeof(msg), &sizeTransferred);

if (ft4222Status == FT4222_OK)
{
// Wait for it to be sent so we can check status.
unsigned char controllerStatus;
NAKSeen = false;

// Deadlock prevention. Try up to 10 times...
for (int tries = 0; tries < 10; tries++)
{
ft4222Status = FT4222_I2CMaster_GetStatus (ftHandle,
&controllerStatus);

if (ft4222Status == FT4222_OK) // We have a status.
{
// If CONTROLLER BUSY, no status bits are valid.
if (I2CM_CONTROLLER_BUSY(controllerStatus)==1)
{
// controller busy: all other status bits invalid
continue;
}

// If here, status bits are valid.

// If BUS BUSY, we are still writing.
if (I2CM_BUS_BUSY(controllerStatus))
{
continue;
}

// Check to see if ADDR was ACK'd.
if (I2CM_ADDRESS_NACK(controllerStatus))
{
NAKSeen = true;
}
// If here, we were NACK'd or ACK'd.
break;
}
else // ft4222Status NOT OK
{
// Considered.
}
} // end of for.

if (NAKSeen == true)
{
printf ("NAK\n");

// Handle...
}
else // ACK'd
{
// Write was okay.
printf ("Wrote %u bytes.\n", sizeTransferred);

// Handle...

} // end of if (NAKSeen == true) else

} // end of if (ft4222Status == FT4222_OK)

If FTDI releases a fixed chip in the future, that code could be enhanced to check for other error conditions as well.

Currently, if you want to use it to see if your write was received (ACK), you have to wait until transmission is complete then use GetStatus. For casual hobby projects, it may be fine to just blindly write to non-existent (or locked up) devices, but if the project is important knowing is a device is present (and has received the message) may be required.

Since FT4222_I2CMaster_Write() is non-blocking, the call returns immediately, and the write is handled in the background. This means if you do a Write and follow it with a GetStatus, problems may occur. The above-linked post demonstrates data corruption as one such problem.

I am not sure what happens if you try doing a Write while a previous Write is still in progress, but I *assume* it may also be bad. It is unfortunate this defect exists.

FTDI Workaround

The FTDI response is to wait before calling GetStatus, so I thought I'd provide details in one post (which I will edit with corrections/updates if needed) for others who have run in to this.

The delay can be calculated by knowing the baud rate -- the kbps used in FT4222_I2CMaster_Init() -- and the number of bytes written.

Keep in mind that each byte has an ACK/NAK bit added, so calculate 9 bits per byte rather than 8.

Also, if you look at the output of the I2C write under a logic analyzer (such as a Saleae), you will see there are also gaps between bytes (see attached screenshot). These gaps are not consistent. In my example, I see sending a byte took about 10 uS, with a gap afterwards that ranged from 7 uS to more than 60 uS.

To use the following workaround, you need to use a worst-case "gap time" and add it to the calculation. I am unsure. I am going to *assume* that this gap time can vary -- on a busy Windows machine I expect they could be much larger in time.

Calculating

The FTDI part can operate from 60 kbps to 3400 kbps. Since the Sleep resolution may be limited to milliseconds, a Sleep(1) is the minimal time. This may be long enough to cover writing 128 bytes of I2C data at high baud rates (1000 or faster). But, at slower speeds, you will see the calculated write time needs to be much longer. Just doing a Sleep(1) is not enough if you plan to use a lower baud rate.

The wait time formula is basically something like:"

ms = (9 * (1000/(kbps)) * (sizeTransferred+1)) / 1000;
The 9 is for the 9 clock pulses to send a byte (8 pulses for the 8 bits, plus 1 pulse for ack/nak).

The sizeTransferred (bytes sent) has 1 added to it to round up.

Unfortunately, this does not take in to consideration the gaps between bytes.  If I knew that it took 10 uS to send a byte, and then there was a 7 uS gap after, I could tweak this time by adding extra bits. Say, 7 bits of overhead (worth of time):  "(9+7) * ..."

BUT, since I see that sometimes the gap might be closer to 70 uS (7 times as long as it took to send the byte), I might just want to use "9" there, and multiply the "sizeTransferred" by 7. Worst case.

This produces much longer waits than are needing, slowing down the I2C system considerably. But, if you really need to use GetStatus, this may be the only option.

Here is a C program to print out an example table. You can see the formula I was using added 6 extra bits, but I have since found this is not long enough:

#include <stdio.h>  // for printf
#include <stdint.h> // for uint16_t
#include <stdlib.h> // for EXIT_SUCCESS

// Table of I2C baud rates.
uint16_t kbps[] = { 60, 100, 300, 500, 1000, 3400 };

int main()
{
    // Print header.
    printf ("bytes  ");

    for (int idx=0; idx<sizeof(kbps)/sizeof(kbps[0]); idx++)
    {
        printf ("%4u  ", kbps[idx]);
    }
    printf ("\n");

    // Print table entries.
    for (uint16_t sizeTransferred=0; sizeTransferred<=128; sizeTransferred++)
    {
        printf ("%5u  ", sizeTransferred); // Bytes written.

        for (int speed=0; speed<sizeof(kbps)/sizeof(kbps[0]); speed++)
        {
            // "Since there is a separate byte for the address, and since
    // there are 9 pulses for each byte (ack/nak bit), a formula
    // probably needs to take that in to consideration."
    //
    // "When looking at the FTDI Master (Windows 11) in a Saleae capture,
    // I also see gaps between each byte that range from 10us to 14us, so
    // I added some worst-case extra bits (6 for my case) to that to cover
    // it:"
    //
    //             (bits ) * (         uS       ) * (      bytes      )
        uint32_t ms = ((8+1+6) * (1000/(kbps[speed])) * (sizeTransferred+1)) / 1000;
        if (ms < 1)
        {
        ms = 1;
        }

            printf ("%4u  ", ms);
        }
        printf ("\n");
    }

    return EXIT_SUCCESS;
}

And here is the output:

bytes    60   100   300   500  1000  3400
    0     1     1     1     1     1     1
    1     1     1     1     1     1     1
    2     1     1     1     1     1     1
    3     1     1     1     1     1     1
    4     1     1     1     1     1     1
    5     1     1     1     1     1     1
    6     1     1     1     1     1     1
    7     1     1     1     1     1     1
    8     2     1     1     1     1     1
    9     2     1     1     1     1     1
   10     2     1     1     1     1     1
   11     2     1     1     1     1     1
   12     3     1     1     1     1     1
   13     3     2     1     1     1     1
   14     3     2     1     1     1     1
   15     3     2     1     1     1     1
   16     4     2     1     1     1     1
   17     4     2     1     1     1     1
   18     4     2     1     1     1     1
   19     4     3     1     1     1     1
   20     5     3     1     1     1     1
   21     5     3     1     1     1     1
   22     5     3     1     1     1     1
   23     5     3     1     1     1     1
   24     6     3     1     1     1     1
   25     6     3     1     1     1     1
   26     6     4     1     1     1     1
   27     6     4     1     1     1     1
   28     6     4     1     1     1     1
   29     7     4     1     1     1     1
   30     7     4     1     1     1     1
   31     7     4     1     1     1     1
   32     7     4     1     1     1     1
   33     8     5     1     1     1     1
   34     8     5     1     1     1     1
   35     8     5     1     1     1     1
   36     8     5     1     1     1     1
   37     9     5     1     1     1     1
   38     9     5     1     1     1     1
   39     9     6     1     1     1     1
   40     9     6     1     1     1     1
   41    10     6     1     1     1     1
   42    10     6     1     1     1     1
   43    10     6     1     1     1     1
   44    10     6     2     1     1     1
   45    11     6     2     1     1     1
   46    11     7     2     1     1     1
   47    11     7     2     1     1     1
   48    11     7     2     1     1     1
   49    12     7     2     1     1     1
   50    12     7     2     1     1     1
   51    12     7     2     1     1     1
   52    12     7     2     1     1     1
   53    12     8     2     1     1     1
   54    13     8     2     1     1     1
   55    13     8     2     1     1     1
   56    13     8     2     1     1     1
   57    13     8     2     1     1     1
   58    14     8     2     1     1     1
   59    14     9     2     1     1     1
   60    14     9     2     1     1     1
   61    14     9     2     1     1     1
   62    15     9     2     1     1     1
   63    15     9     2     1     1     1
   64    15     9     2     1     1     1
   65    15     9     2     1     1     1
   66    16    10     3     2     1     1
   67    16    10     3     2     1     1
   68    16    10     3     2     1     1
   69    16    10     3     2     1     1
   70    17    10     3     2     1     1
   71    17    10     3     2     1     1
   72    17    10     3     2     1     1
   73    17    11     3     2     1     1
   74    18    11     3     2     1     1
   75    18    11     3     2     1     1
   76    18    11     3     2     1     1
   77    18    11     3     2     1     1
   78    18    11     3     2     1     1
   79    19    12     3     2     1     1
   80    19    12     3     2     1     1
   81    19    12     3     2     1     1
   82    19    12     3     2     1     1
   83    20    12     3     2     1     1
   84    20    12     3     2     1     1
   85    20    12     3     2     1     1
   86    20    13     3     2     1     1
   87    21    13     3     2     1     1
   88    21    13     4     2     1     1
   89    21    13     4     2     1     1
   90    21    13     4     2     1     1
   91    22    13     4     2     1     1
   92    22    13     4     2     1     1
   93    22    14     4     2     1     1
   94    22    14     4     2     1     1
   95    23    14     4     2     1     1
   96    23    14     4     2     1     1
   97    23    14     4     2     1     1
   98    23    14     4     2     1     1
   99    24    15     4     3     1     1
  100    24    15     4     3     1     1
  101    24    15     4     3     1     1
  102    24    15     4     3     1     1
  103    24    15     4     3     1     1
  104    25    15     4     3     1     1
  105    25    15     4     3     1     1
  106    25    16     4     3     1     1
  107    25    16     4     3     1     1
  108    26    16     4     3     1     1
  109    26    16     4     3     1     1
  110    26    16     4     3     1     1
  111    26    16     5     3     1     1
  112    27    16     5     3     1     1
  113    27    17     5     3     1     1
  114    27    17     5     3     1     1
  115    27    17     5     3     1     1
  116    28    17     5     3     1     1
  117    28    17     5     3     1     1
  118    28    17     5     3     1     1
  119    28    18     5     3     1     1
  120    29    18     5     3     1     1
  121    29    18     5     3     1     1
  122    29    18     5     3     1     1
  123    29    18     5     3     1     1
  124    30    18     5     3     1     1
  125    30    18     5     3     1     1
  126    30    19     5     3     1     1
  127    30    19     5     3     1     1
  128    30    19     5     3     1     1
You will see that at the lowest baud rate, writing out 128 bytes is calculated to take around 30 ms. If you actually test this in a logic analyzer, you will see it's not very accurate. See my second screen shot and you will see that when writing 128 bytes, the gaps between the bytes vary - some are 7 uS, some are 13 uS, some are 51 uS (!), even 63 uS. There is overhead on the Windows system and other things are happening.

My table claims that 128 bytes at 1000 kbps should need a 1ms delay. BUT, when I actually look at the time it took, it was OVER 3ms. I was off by a factor of 3! Using my formula to calculate wait time could have led to reading corrupt data (per the poster in the other topic).

Because of this, the formula I was using will not work. As far as I know, currently, you just have to make sure you always wait a worst-worst case amount of time before trying to use GetStatus. And since I don't know how fast the PC will be that runs my I2C code, whatever timing I come up with may not be long enough.

That's the problem.

Ever since we tried to implement ACK/NAK detection (probing for devices), we've had occasional problems, and it seems this is the culprit.

I hope this information helps others who run in to this. What we really need is a way to determine if a Write is busy, but at least when I asked last year, the only option was "Sleep". But...how long?

Cheers!

Update: I have done tests, and verified under a Saleae logic analyzer, that this does work. There's just a huge gap between the reads on my Windows system.

Without full error checking (because this is bad code you shouldn't use for production):

uint8_t buffer[128];
memset (buffer, 0x0, sizeof(buffer));

ft4222Status = FT4222_I2CMaster_ReadEx (ftHandle, UNIVERSAL_BOARD_ADDRESS, START, &buffer[0], 2, &sizeTransferred);

if (ft4222Status == FT4222_OK)
{
    uint16_t numDataBytes = 0;

    printf ("Read %d bytes.\n", sizeTransferred);

    // buffer[0] is our Start Code, and we'd error check that here.

    // buffer[1] is the number of data bytes in our payload (if any)

    numDataBytes = buffer[1];

    printf ("Repsonse num data bytes %d.\n", numDataBytes);

    ft4222Status = FT4222_I2CMaster_ReadEx (ftHandle, UNIVERSAL_BOARD_ADDRESS, STOP, &buffer[2], 3+numDataBytes+2, &sizeTransferred);

In our case, our message format is a 5-byte header (starting with a Star Code, # of PayLoad Data Byters, and three other items), then payload bytes (if any), then a 2-byte CRC.

In testing, we took out all error checking and just did the two reads back to back.  This works, but will have a 150uS-300uS gap between reading the first two bytes and reading the rest, due to overhead of Windows and such. We haven't benchmarked it under Linux yet, but that's on the list.

Hope this helps others.

Sorry to bump such an old topic, but we'd still like to find examples of how to properly detect and recover from an I2C bus lock. There was an API call added that does appear to send the clock pulses, but we haven't found any examples of what process to follow to shut down/recover when issues happen.

Since there is a separate byte for the address, and since there are 9 pulses for each byte (ack/nak bit), a formula probably needs to take that in to consideration. Something like:

#define I2C_KHZ 400

ms = ((8+1) /*bits*/ * (1000/(I2C_KHZ)) /*us*/ * (bytesTransferred+1)) / 1000;

if (ms < 1) ms = 1;

Sleep (ms);

When looking at the FTDI Master (Windows 11) in a Salae capture, I also see gaps between each byte that range from 10us to 14us, so I added some worst-case extra bits (6 for my case) to that to cover it:

ms = ((8+1+6) ....etc...

I am not sure what the FTDI driver does that causes those gaps, but I expect the reason they vary in length is due to Windows not being a realtime OS.  Perhaps the gaps are even larger when using more CPU time or running more stuff.  That would throw all these calculations off.

There really should be a way to query the driver and find out if it's done writing.

We have a large LabWindows program and the only external component it uses is the FTDI drivers:

ftd2xx.lib
LibFT4222-64.lib and LibFT4222-64.dll

When we first ran it under Windows 10 LTSC, it complained about missing msvcp100.dll and msvcr100.dll. These come from the Visual C++ 2010 redistributable. These files are included with Windows 10, but are not part of LTSC and have to be installed separately.

Are these FTDI files what is needing them? A simple LabWindows U.I. program that does not use the FTDI code seems to work.

It appears the dependency is either in the FTDI software, or some library item that LabWindows is pulling in for our product (FTDI is the only component we use that is not built-in to LabWindows).

Hopefully someone can confirm whether or not these DLLs are used by FTDI. That would greatly help me know where to focus my research in to this issue.

Thanks, much!

We make use of LibFT4222.dll for I2C Master communication on a Windows PC.

I would like to make our error detection much more robust. For example, I want to be able to detect issues such as:

• USB cable disconnected.
• I2C bus lock up.
• ? ? ?

I get back an FT4222_STATUS from all read/write operations, but I am not real sure which errors are "best practice" to try to detect and handle.  I expect we can put in things like:

If we think I2C bus is locked, try an FT4222_I2CMaster_ResetBus().

If we think the USB connection is bad, un-init, close and try to re-open and init.

Library functions such as FT_CyclePort() may also be useful.

Could someone point me to some documention on "best practices" for a robust I2C system?

Thanks, much.

During some early testing, I noticed that Write worked even if nothing was on the other side (no address ACK). Today, I am doing the write, and if it returns OK, I am checking controller status looking to see if the write was acknowledged.

But, I also saw the errata saying reading that register while a write was in progress could corrupt data.