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.

Could someone enlighten me on the purpose of the different clock speeds provided by:

FT4222_SetClock()
The manual explains:

Set the system clock rate. The FT4222H supports 4 clock rates: 80MHz, 60MHz, 48MHz, or 24MHz. By default, the FT4222H runs at 60MHz clock rate.

From the specs:

https://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT4222H.pdf

It appears this may just be for SPI to get different speeds. Is it used at all for I2C?

We have had some interesting I2C challenges lately, and one of them may have been resolved by changing from the default 60MHz to 24MHz (it ran over a million packets overnight successfully, which we haven't been able to do previously).

NOTE: We also see that when we specify 1000 (kbps) our scope measures around 750mhz.

Thanks...

How can the I2C "bus clear" be done using the Windows API? See 3.1.16 in the I2C specification:

https://www.nxp.com/docs/en/user-guide/UM10204.pdf

3.1.16 Bus clear

In the unlikely event where the clock (SCL) is stuck LOW, the preferential procedure is to
reset the bus using the HW reset signal if your I2C devices have HW reset inputs. If the
I2C devices do not have HW reset inputs, cycle power to the devices to activate the
mandatory internal Power-On Reset (POR) circuit.

If the data line (SDA) is stuck LOW, the master should send nine clock pulses. The device
that held the bus LOW should release it sometime within those nine clocks. If not, then
use the HW reset or cycle power to clear the bus.

This is needed for situations when the i2c hangs or has a lockup. I find many examples of how to do this on ST, Arduino, Raspberry Pi, etc. and want to replicate that on FTDI Windows code.

Thanks for any pointers.