FTDI Community

General Category => Discussion - Drivers => Topic started by: allenhuffman on August 26, 2019, 02:39:12 PM

Title: I2C lockup/hang and "bus clear" using FT4222 Windows API? (I2C spec 3.1.16)
Post by: allenhuffman on August 26, 2019, 02:39:12 PM
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.
Title: Re: I2C lockup/hang and "bus clear" using FT4222 Windows API? (I2C spec 3.1.16)
Post by: allenhuffman on August 30, 2019, 03:11:43 PM
FTDI support suggests “FT4222_ChipReset”. I will investigate and report my findings.
Title: Re: I2C lockup/hang and "bus clear" using FT4222 Windows API? (I2C spec 3.1.16)
Post by: allenhuffman on September 11, 2019, 03:20:10 PM
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.