UPDATE: Next post has confirmation this works, with a Saleae capture showing the start and stop bits are handled properly.

We use a custom protocol over I2C that embeds message length in our messages. In our PIC24 firmware, we have one board that will read the first two bytes (to get our protocol start code, and the number of data bytes in the message) and then it will read only the expected number of bytes. (Our actual protocol does more - having CRC and other things we validate, but I am simplyfing it here for example and removing most error checking.)

i2c_start (I2C_SUBNET_BUS);

i2c_write (I2C_SUBNET_BUS, I2CSlaveAddress + 1);

// Read the message on the I2C bus.
startCode = i2c_read (I2C_SUBNET_BUS, 1); // Start Code

numDataBytes = i2c_read (I2C_SUBNET_BUS, 1); // Num Data Bytes

for (int idx = 0; idx<(numDataBytes-1); idx++)
{
    RXBuffer[idx] = i2c_read (I2C_SUBNET_BUS, 1);
}

// Read the last byte, but don't ACK.
RXBuffer[idx] = i2c_read (I2C_SUBNET_BUS, ZERO);

i2c_stop (I2C_SUBNET_BUS);

Our system is fairly complex with as many as 27 different boards in communication over I2C.

On our FTDI Windows host program side, we hard code the expected response message size. We do something like:

FT4222_I2CMaster_Write(ftHandle, slaveAddress, buffer, bytesToWrite, &sizeTransferred);
...
FT4222_I2CMaster_Read(ftHandle, slaveAddress, responseBufferPtr, ExpectedResponseSizeForThatMessage, &sizeTransferred);

This is fine, but if we are writing something that has a large message expected, and there is a problem, the slave board will return a NACK message (7 bytes in our case) and the Master reads that and keeps reading up to the expected size.

No big deal, since our firmware zeros out the response buffer so if the Master reads 10 bytes at any time, it just gets back 10 0s.

BUT, I wanted to make our messages more flexible and maybe speeds things up. It looks like I could recreate what I want using ReadEx(), since I see:

The I2C condition will be sent with this I2C transaction
 START = 0x02
 Repeated_START = 0x03
 Repeated_START will not send master code in HS mode
 STOP = 0x04
 START_AND_STOP = 0x06

It looks like I would do a ReadEx of 2 bytes, with the flag set to START, then I can error check our start code (byte 0) and number of data bytes (byte 1) and then issue a ReadEx of that many bytes with flag set to Repeated_Start (for one less byte) then read the final byte using STOP.

I thought I'd ask if this was worth trying, or if there was a better way. Perhaps the driver handles doing a read with just STOP and I can save a step.

I plan to experiment on this before the end of the year, but thought I'd ask in case I couldn't even do this.

Thanks, much.

Hello,

This will be included in the LibFT422 release notes in future releases.

I will also check if anything can be done in the driver or library to help improve this.

Best Regards,
FTDI Community

Thank you. A simple blocking option (don't return until all bytes have been sent) would be great.

Thank you for the reply. Please consider to update the wording in the errata sheet and mention the affected libFT4222 APIs explicitly.

Having just ran in to this on our project, yes, please.

This may not help, but...

Using the FT4222, we noticed timing gaps between groups of data (I seem to recall odd spacing every 3 bytes).

Somewhere (support? random internet searching?) we were told to look at the SetClock speed and set it to SYS_CLK_24.

FT4222_SetClock (ftHandle, clock);

I do not know if this changed anything.

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:

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.

Thanks. I am still trying to work through best practices. In this case, nothing could be done, but I often find the
c program gets stuck doing an FTDI library call. You can’t kill it with task manager, and have to reboot Windows, or unplug the USB cable. It releases when that is done.

How can I detect if a bus is stuck?

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:

    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:

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.