*** UPDATE ***

I switched over to GPIO mode and notice I can toggle the data line, but not clock.  At this point, I believe one of the devices on my bus is holding it low and this "unstick trick" will not work for me.

I have learned about FT4222_UnInitialize() which lets me open the device, initialize it for GPIO, unitialize it, the initialize it for I2C. I did not know about that, back then, or I would have tried this trick before the library had ResetBus.

My test code:

    FT_HANDLE ftHandle = NULL;
   
    ftStatus = FT_OpenEx ("PrecisePower B", FT_OPEN_BY_DESCRIPTION,
                          &ftHandle);
   
    if (ftStatus == FT_OK)
    {
         GPIO_Dir gpioDir[4] = { GPIO_OUTPUT, GPIO_OUTPUT, GPIO_OUTPUT, GPIO_OUTPUT };
         
         ft4222Status = FT4222_GPIO_Init(ftHandle, gpioDir);

         //disable suspend out , enable gpio 2
         //ft4222Status = FT4222_SetSuspendOut(ftdiInfoPtr->ftHandle, false);
         
         //disable interrupt , enable gpio 3
         //ft4222Status = FT4222_SetWakeUpInterrupt(ftdiInfoPtr->ftHandle, false);
         
         // set gpio0/gpio1/gpio2/gpio3 output level high
         for (int pulse=0; pulse<9; pulse++)
         {
            ft4222Status = FT4222_GPIO_Write(ftHandle, GPIO_PORT0, 1); // Clock pin
            Sleep (1);
            ft4222Status = FT4222_GPIO_Write(ftHandle, GPIO_PORT0, 0); // Clock pin
            Sleep (1);
         }
         Sleep (1);
         
         FT4222_UnInitialize(ftHandle);           
    }
    FT_Close (ftHandle);

I do not think it was actually resolved in 1.4.3, but it definitely works in 1.4.4.

I have a C# wrapper for the LibFT4222 and D2XX DLLs. The PC is acting as an I2C slave, and we have another project where the PC is the master.

I am trying to add recovery code to detect if the I2C connection is lost due to a USB cable unplug. Currently, we have close/reopen manually.

I have a loop that checks for data using FT4222_I2CSlave_GetRxStatus() and does a read if the expected bytes are available, then I do a FT4222_I2CSlave_Read().

I have noticed that the status returned from FT4222_I2CSlave_GetRxStatus continues to be FT4222_OK even if I unplug the USB cable.

I am trying to find a clue in these two manuals for how to detect a lost connection:

https://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf
https://www.ftdichip.com/Support/Documents/AppNotes/AN_329_User_Guide_for_LibFT4222.pdf

My app also talks to a GPIB interface to a signal generator and have detection code for that working as expected. It returns an error when the device is turned off or unplugged.

Thanks for any pointers to what I need to be looking for in the manual.

I have two UMFT4222EV modules that used to work great, but now I can't get either to receive or send I2C using the same code that worked great a few months ago.

The only thing I can think that changed was a fresh reinstall of Windows since then.

My test app lists all the FTDI devices (FT4222 A and B, twice, since I tried plugging both in to make them talk). It can get clock speed and address and everything looks fine.

But nothing is coming out -- I've hooked it up to a logical analyzer and also a scope. Nothing on Clock/Data.

I've tried removing the driver and reinstalling. It's bound to be a "strange windows thing."

Anyone encountered this?

We use FTDI I2C Master in a PC host program, but today I am trying to get a PC program to act as a slave so our embedded device can send some status information.

I am using a custom C# wrapper I wrote for the FT4222 I2C things. We use it successfully in an application running as a Master.

We are using the previous 1.4.2 release of the DLL package (I just noticed the 1.4.3 release today, which fixes a bug we'd encountered).

My code loop is very simple, but I get nothing back from it. I have used an analyzer and seen that there is I2C traffic with the correct address, but nothing makes it to my program. I expect I am missing something simple. My loop looks like this:

I2C i2c = new I2C(); // my wrapper

i2c.OpenByName("FT4222 A");

i2c.SlaveInit();
i2c.SlaveSetAddress((byte)0x40); // let's hard-code 40, which is the default.

Console.WriteLine("Slave address: 0x{0:x2} ({0})", i2c.SlaveGetAddress());

do
{
if (i2c.SlaveGetRxStatus() == 0) continue;

messageBuffer = i2c.SlaveRead(4);

for (int idx = 0; idx < 4; idx++)
{
Console.Write("{0:x2} ", messageBuffer[idx]);
}
Console.WriteLine();

} while (true);

GetRxStatus() always returns 0, but I do see my embedded device is writing out an I2C sequence to address 0x40 with four bytes after it. They are not being ACKed, so I don't think I have things set up properly for Slave.

Based on the examples in the PDF manual, and the i2c_slave.cpp sample code, it seems pretty straight forward.

Am I missing a step?

Thanks to whoever has the eyes to spot my mistake.

 For FT4222_I2CMaster_Init(), it says:

This parameter is used to configure the FT4222H to be either SM, FB, FM+ or HS mode.

…and in the API docs:

Common I²C bus speeds are the 100 kbit/s standard mode (SM), 400 kbit/s fast mode (FM), 1 Mbit/s Fast mode plus (FM+), and 3.4 Mbit/s High Speed mode (HS)

At which kbps values does it switch to the different modes?

When we use 1000 (kbps), our scope shows it's actually running around 750mhz.

I see many programs that require me to unplug my device, click a button, then plug it back in, and they just look for what changed. Now that I've worked with the FTDI stuff a bit, I have a better understanding of the problem they face -- trying to figure out which of the eight FTDI-based devices is the one you mean ;-) If you cannot customize the ID in each device (unique), this might be an option to look into.