pyftdi icon indicating copy to clipboard operation
pyftdi copied to clipboard

I2C frequency not set properly/reliably

Open securelyfitz opened this issue 4 years ago • 3 comments

I opened an issue on blinka that appears to be due at least in part to pyftdi.

See the steps in the other issue but to summarize:

  • on an FT2232H, i2c works fine (400khz) when the board is powered on
  • sometimes, but most frequently when a script is stopped via keyboard interrupt, the device is left in an bad state
  • the next script to interface to the device runs i2c at 4Mhz, devices do not respond in time
  • power cycling the FT232H restores proper operation.

i2scan.py is a good reference. It can be run over and over again and stopped via keyboard interrupt without any issues, indicating it either 1) properly initialized or 2)properly cleans up the ftdi state. To show it's the latter:

  • run and keyboard-interrupt a blinka script to enter corrupt state
  • run i2cscan.py. It scans at 4Mhz and returns no devices
  • run i2cscan.py again. it scans at 400khz and shows devices
  • run blinka script again, and it works properly

This indicates to me that i2cscan is not fully initializing the ftdi device, but is properly cleaning it up on exit.

Some more data points:

  • the issue does not show up on the ft232 because it seems to properly initialize the device, but does not cleanup since it's possible to keyboard interrupt and get a corrupt i2cscan.py.
  • the issue does show up on the ft2232h because it doesn't seem to properly initialize or clean up.

I haven't looked into the pyftdi code yet, but am filing this issue because I'm 1) pretty sure that's where the issue lies and 2) i'm hoping someone already familiar with the code might know right were to look to either fix this or point me in the right direction.

securelyfitz avatar Jul 13 '21 19:07 securelyfitz

I have found that this seems to happen on some FT2232H hardware that I built, but, oddly, not on Tigard! Resetting the entire USB device gets the device back into a working state, but that is a little less granular than I would like.

jwise avatar Jul 15 '24 08:07 jwise

A little more diagnostics: I don't have a properly minimal repro yet, but it seems to happen when I .close the I2C (and, indeed, the Ftdi). When I nopped out release_interface with i2c._ftdi._usb_dev._ctx.managed_release_interface = lambda a,b: print("MANAGED_RELEASE_INTERFACE"), a subsequent attempt to speak I2C without restarting the program worked out just fine. This is running on Linux 4.19.111; I wonder if there is a kernel version difference at play (4.19.111 is on an IoT device, my laptop that had the Tigard is 6.5.0-41-generic).

jwise avatar Jul 15 '24 08:07 jwise