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: Lib4222 I2C best practice: Detecting USB loss, I2C bus lock, etc. (Windows)  (Read 14143 times)

allenhuffman

  • Newbie
  • *
  • Posts: 49
  • Mostly harmless.
    • View Profile
    • Sub-Etha Software

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

allenhuffman

  • Newbie
  • *
  • Posts: 49
  • Mostly harmless.
    • View Profile
    • Sub-Etha Software

Sorry to bump such an old topic, but we'd still like to find examples of how to properly detect and recover from an I2C bus lock. There was an API call added that does appear to send the clock pulses, but we haven't found any examples of what process to follow to shut down/recover when issues happen.
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 896
    • View Profile

Hello,

Here is some information that should help you:

1.   USB cable disconnected.
FT_CyclePort() can re-initialise the USB port.

2.   I2C bus lock up.
This contains two situations. I2C clock lock up and I2C data lock up.
Please refer to the external link https://espace.cern.ch/CMS-MPA/SiteAssets/SitePages/Documents/I2C_bus_specifications_V2_0.pdf
Page 5 section 1.3.
 
a. FT4222_I2CMaster_ResetBus() only can solve the data line (SDA) being stuck LOW.
When SDA is stuck low, you can run following functions.
a.1 ft4222_status = FT4222_I2CMaster_Reset(i2cmHandle);
a.2 ft4222_status = FT4222_I2CMaster_ResetBus(i2cmHandle);
It can reset the i2c master state machine and unlock the SDA bus.

b. When the clock (SCL) is stuck LOW, we think a hardware reset is necessary.
You can run the following functions.
b.1 ft4222_status = FT4222_I2CMaster_Reset(i2cmHandle);
b.2 ft4222_status = FT4222_I2CMaster_ResetBus(i2cmHandle);
b.3 Use GPIO pin to signal the i2c slave and force it to perform a HW reset.

I hope this information is helpful to you.

Best Regards,
FTDI Community
Logged

allenhuffman

  • Newbie
  • *
  • Posts: 49
  • Mostly harmless.
    • View Profile
    • Sub-Etha Software

Hello,
Here is some information that should help you:

Thank you for this. I am about to do some updating to our I2C code and decided to look and see what new information I could find. I missed this reply when it was added last November. Good tips.
Logged