FT2232H I2C frequency not set properly/reliably

[securelyfitz]

I'm testing out the FT2232H support in the latest release using stats.py (because I have lots of oled displays on hand)

With an Adafruit FT2232H breakout board, it works fine: BLINKA_FT232H=1 ./stats.py I can run, quit, and re-run the command over and over.

After swapping to FT2232H hardware and changing all the instances of SDA and SCL to SDA1 and SCL1 it works once: BLINKA_FT2232H=1 ./stats-2232.py I can run it once and sometimes a few times, but eventually it gets a NACK and can't see the display.

Observing with a logic analyzer shows I2C clock going at 400khz the first few times, but 4Mhz when it eventually fails because the oled display doesn't respond at such a high speed.

Things i've tried:

• I looked at how the 232H vs 2232H is treated in busio.py. frequency is not properly passed to the ft2232h on line 106, but that is not the cause of this issue (but might be worth fixing anyway)
• I thought there might be an off-by-one issue using interface 0 and 1 while pyFTDI URLs use 1 and 2, but that seems to be handled properly by mpsse/url.py line 34
• I dug into pyftdi's i2c.py to see how the frequency was assigned and added a few print statements, but that code seems to be doing the right thing as well.

Then, I changed stats.py to exit after running once, and running it in a bash loop. It works flawlessly. That leads me to believe there's something not getting cleaned up on exit from keyboard interrupt, or something not fully initialized in code that is properly cleared on power cycle.

At this point I can't be sure whether this is a Blinka, PyFTDI, or FTDI problem, but I figured I'd log it here until I figure out more.

[securelyfitz]

Had some time to revisit this:

• tested using @fharding1's initial ft2232h implementation - same behaviour
• tested blocking keyboard interrupt signals during i2c operations - same behaviour
• tested with a longer time.sleep - works more consistently
• tested with a 1s time.sleep inside the block with keyboard interrupt disabled - works 90% of the time
• tested with 3s inside block - works 100%

Going through these paces reminds me of some issues i had when building the tigard test flow - some tests would automatically fail if run too soon after the previous test.

Combined with the fact that this just works on the ft232h, I'm suspecting more that this is a pyftdi or FTDI problem and not due to blinka. I will investigate more.

[securelyfitz]

Tried to do a little more debugging by monitoring with i2cscan.py, and discovered

• i2cscan.py works fine, over and over again, interrupted or not
• i2cscan.py sees nothing (presumably running at 4mhz) after another script left i2c in a nonworking state
• i2cscan.py works properly the second time it's run after another script left it nonworking.

This reinforces my suspicion that there's a pyftdi issue where something is getting cleaned up that's not getting initialized. i2cscan should always work the first time.

However, I went back and tested the ft232h:

• running stats.py over and over again works, even with keyboard interrupt
• running stats.py, followed by keyboard interrupt, followed by i2cscan.py doesn't see the oled device.
• running stats.py, followed by keyboard interrupt, followed by i2cscan.py twice works properly.

So, there's magic block of code getting run during initialization or cleanup: i2cscan.py is doing magic during cleanup, but not doing it during initialization ft232h through blinka is doing magic during initialization but not during cleanup ft2232h through blinka is not doing magic in either initialization or cleanup

So, this is almost certainly a pyftdi issue, even if the magic initialization/cleanup could be added at the blinka layer.