FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

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.

Topics - allenhuffman

Pages: [1]
1
Discussion - Software / msvcp100.dll and msvcr100.dll dependencies?
« on: March 29, 2022, 03:04:51 PM »
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!

2
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.

3
We use Windows and the FT4222 driver to talk to a variety of boards over I2C. Over the years, we have seen many issues with I2C bus locks and have tried to mitigate them in software/firmware.

I thought I'd ask here if folks had any elegant solutions for detecting an I2C bus lock and attempting recovery.

The last release of the library (1.4.4) added FT4222_I2CMaster_ResetBus(); and finally allowed sending the 9 clock pulses to try to unstick a stuck I2C slave device. Before this function was added, we tried doing it manually but found you could not access the GPIO pins when in I2C mode.

I believe we may have been able to just uninitialized from I2C and initialize in GPIO mode to do this:

Code: [Select]
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
        ft4222Status = FT4222_GPIO_Write(ftHandle, GPIO_PORT0, 0); // Clock pin
     }
     Sleep (1);
     
     FT4222_UnInitialize(ftHandle);

    // Re-init as I2C and use it...           
}
FT_Close (ftHandle);

(Untested; not sure the timing from within Windows toggling that pin on/off would do the trick.)

I wondered if anyone had any clever ways of detecting an I2C stuck bus condition (like when a slave device is using clock stretching, and the master doesn't do a read).

I'll do another post about our experiments with ACK/NACK.

Cheers.

4
FTDI added FT4222_I2CMaster_ResetBus() in the 1.4.4 release (I believe).  It is supposed to send 9 I2C clock pulses to unstick the I2C bus. I recall testing this when I first received this version, and saw it work.

But today, I am noticing it is not sending clock pulses.  Attached is a screen shot of the Saleae capture.

To verify my Saleae was working, I swapped my two input probes and saw the pulses move to the other input.

My code is very simple and is doing this:

Code: [Select]
    ftStatus = FT_OpenEx ("MyDeviceNameHere", FT_OPEN_BY_DESCRIPTION,
                          &ftdiInfoPtr->ftHandle);
   
    if (ftStatus == FT_OK)
    {
        ResetDevice ();
        // Need to wait for the FTDI device to complete the reset.
        Sleep (ONE_THOUSAND);

        // Set the device timeouts.
        ftStatus = FT_SetTimeouts (ftdiInfoPtr->ftHandle,
                                   FT_DEFAULT_RX_TIMEOUT,
                                   FT_DEFAULT_TX_TIMEOUT);

        // Initialize the I2C master.
        if (ftStatus == FT_OK)
        {
            // Initialize the FTDI device chosen.
            ft4222Status = I2CMasterInit (ftdiInfoPtr->ftHandle, I2C_SPECIAL_FAST_CLK);

            // Initialization is done.
            if (ft4222Status == FT4222_OK)
            {
                for (int idx=0; idx < 10; idx++)
                {
                    // Send nine clock pulses to reset a stuck Slave device.
                    ft4222Status = I2CMasterResetBus (ftdiInfoPtr->ftHandle);
                    Sleep (1);
                }

We have wrappers for the different functions, so I2CMasterResetBus is just:

Code: [Select]
FT4222_STATUS I2CMasterResetBus (FT_HANDLE ftHandle)
{
    return FT4222_I2CMaster_ResetBus (ftHandle);
}

And ResetDevice() is just calling FT_ResetDevice ();

Anyone used this? It's new, and wasn't even documented at first (beyond header file entries).

Thanks, much.

5
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.

6
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?

7
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?



8
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.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.

9
 For FT4222_I2CMaster_Init(), it says:

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

…and in the API docs:

Quote
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.

10
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]
FT4222_SetClock()
The manual explains:

Quote
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...

11
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?

12
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

Quote
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.

Pages: [1]