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

Author Topic: I2C lockup/hang and "bus clear" using FT4222 Windows API? (I2C spec 3.1.16)  (Read 90 times)

allenhuffman

  • Newbie
  • *
  • Posts: 9
    • View Profile

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.
« Last Edit: August 26, 2019, 04:27:07 PM by allenhuffman »
Logged

allenhuffman

  • Newbie
  • *
  • Posts: 9
    • View Profile

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

allenhuffman

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: I2C lockup/hang and "bus clear" using FT4222 Windows API? (I2C spec 3.1.16)
« Reply #2 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.
Logged