FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  


Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support

New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - allenhuffman

Pages: [1] 2
I do not think it was actually resolved in 1.4.3, but it definitely works in 1.4.4.

Discussion - Software / Re: FT4222 and PC as an I2C slave example?
« on: April 30, 2020, 04:35:47 PM »
This problem went away after two days of messing with it. Even using the default address of 0x40 was not working. Then it started. "SWT" (Strange Windows Thing?). An I have a fairly clean fresh install of Windows 10 from about a month ago, and I reboot my system every morning at the start of the day. Dunno!

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:


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 am using a C# wrapper for the FTDI I2C DLL. My program is acting as a Slave device. I have noticed that when the screen saver kicks in, I stop getting data.

The other DLL I am using (GPIB interface to a signal generator) keeps chugging along just fine. Only the I2C stops reading. The reads from the I2C is based on a Windows 10 timer. The control on the GPIB device is based on another timer. Since I can tell the GPIB timer is still working, I don't think it's a timer issue.

Has anyone else encountered this?

Discussion - Hardware / UMFT4222EV not sending/received I2C (Win 10)
« on: April 24, 2020, 12:41:27 AM »
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?

Looks like this is fixed in 1.4.3 (but we haven't tried it yet):

Release version
1.4.3 (Mar 19, 2020)
Maintenance release.

Release Fixes

•   Support Chip version “A”, “B”, “C” and “D”.
o   Fix issue. FT4222_I2CMaster_WriteEx does not return correct sizeTransferred.

Discussion - Software / FT4222 and PC as an I2C slave example?
« on: April 23, 2020, 05:46:21 PM »
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:

Code: [Select]
I2C i2c = new I2C(); // my wrapper

i2c.OpenByName("FT4222 A");

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

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

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

messageBuffer = i2c.SlaveRead(4);

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

} 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 our particular situation, the ChipReset seems to let us recover.

We have captured abnormalities in the I2C clock signal that starts happening before our hang. There will be an extra gap between the first clock pulse, and the repeats for the following bytes until it hangs. We've also been experimenting with different SetClock() values and see how the gaps change between bytes. We seem to have better luck at 24MHz.

 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.

Discussion - Drivers / Purpose of FT4222_SetClock()
« on: September 10, 2019, 03:41:40 PM »
Could someone enlighten me on the purpose of the different clock speeds provided by:

Code: [Select]
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:


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.


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.

Awesome! Thanks for the confirmation.

FTDI support suggests “FT4222_ChipReset”. I will investigate and report my findings.

Which version of LibFT4222 are you using? Which version of the D2XX driver are you using?
The latest are v1.4.2 and 2.12.28 respectively (for Windows).

I am using the latest ZIP, downloaded recently:


Which FT4222H IC revision are you using?


Have you tested out the I2C examples provided with LibFT4222?

I am currently using a modified example, yes.

When I use FT4222_I2CMaster_Write() and tell it to write 7 bytes, the value returns with 11. I've tested it with other numbers, and see it returns 4 higher than what I passed in. Here's a slightly edited snippet:

Code: [Select]
sizeTransferred = 0;
ft42Status = FT4222_I2CMaster_Write(FTDIHandle, slaveAddress, writeBuf, (ushort)sizeToWrite, &sizeTransferred);

Writing 7 bytes...
11 SENT: aa 00 06 00 02 4e ff

As you see, I clear sizeTransferred before I pass it in.

Somewhere I read that FTDI added some header bytes that needed to be accounted for. I cannot find where I saw this, but maybe this is what I am seeing.

Per the App Note 329, I am using FT4222_I2CMaster_Write() and passing in a value of 8 for "bytesToWrite", and a zeroed out sizeTransferred before passing it in. "sizeTransferred" returns as 12 rather than the 8 I expected. (Verifying with a line analyzer shows the 8 bytes we went without extras.)

What are the extra 4 bytes?

Pages: [1] 2