Hi - I received LibMPSSE 1.0.4 from US customer support, thanks Cameron!
After fixing some problems in LibMPSSE (see details below), the library no longer goes into an infinite loop.
Now works OK for both 32-bit and 64-bit builds.
The AdaFruit FT232H board https://www.adafruit.com/product/2264 has a tiny switch which must be ON to enable I2C; I missed this and wasted some time...
It would be great if FTDI would fix the problems in the library detailed below.
All my fixes are marked with my initials DRN in the source.
Thanks,
Best Regards, Dave

As forum attachment limit is tiny:
the complete test project (with LibMPSSE corrections) is here
See also http://www.ftdicommunity.com/index.php?topic=894.msg2591#new

Details
Note:
- the device and cable work fine with an MCP2221 (Microchip USB-to-I2C/Qwiic adapter).
- testing uses AdaFruit FT232H Breakout above and SparkFun Micro Magnetometer - MMC5983MA (Qwiic) SEN-19921

BUG: FTDI code goes into infinite-loop until (1) below is corrected.

Note: I set channelConf as follows:
    channelConf.ClockRate = I2C_CLOCK_STANDARD_MODE;
    channelConf.LatencyTimer = 100;
    channelConf.Options = 0
        | I2C_DISABLE_3PHASE_CLOCKING
        | I2C_ENABLE_DRIVE_ONLY_ZERO /* pull-up resistors are on SEN-19921 sensor Qwiic board. */
        ;
    channelConf.Pin = channelConf.currentPinState = 0;
I also tried different Options flag values; always same result.


====================  FTDI code problems  ====================

1) Version 1.0.4 ftdi_mid.h line 87 comments out FT_InitChannel without explanation:
//FT_STATUS FT_InitChannel(FT_LegacyProtocol Protocol, FT_HANDLE handle,...);
Lack of declaration causes a compile warning in ftdi_i2c.c and apparently runtime infinite-loop error:
ftdi_i2c.c(393,11): warning C4013: 'FT_InitChannel' undefined; assuming extern returning int
The routine is still provided and global in ftdi_mid.c but with a DIFFERENT function signature.
Adding current/correct declaration in ftdi_mid.h corrects infinite-loop bug.

2) Doesn't compile with C++:
2a) ftdi_infra.h line 192 doesn't compile with C++ because there's a typedef of bool:
    typedef BOOL   bool;
2b) all headers are missing extern "C" for C++

3) test.c sets channelConf.Options = 100; without explanation.
100 is an illegal value according to the recently-added header documentation

4) New channelConf fields channelConf.pin and channelConf.currentPinState:
4a) test.c does not initialize these
4b) there is no documentation about how these should be set for I2C

5) Building 64-bit version shows improper conversion between pointers and unsigned int:
QwiicFT.cpp(49,41): warning C4311: 'type cast': pointer truncation from 'FT_HANDLE' to 'unsigned int'
QwiicFT.cpp(49,41): warning C4302: 'type cast': truncation from 'FT_HANDLE' to 'unsigned int'
QwiicFT.cpp(134,64): warning C4311: 'type cast': pointer truncation from 'FT_HANDLE' to 'unsigned int'
QwiicFT.cpp(134,64): warning C4302: 'type cast': truncation from 'FT_HANDLE' to 'unsigned int'

6) Current 1.0.4 version is not on web site.
Web site still has versions for Windows 2000 and XP!


====================  Program Output  ====================

Hello World!
ftd2xx.dll loaded OK!
Found at least one channel on FT232H
Information on channel number 0:
                Flags=0x2
                Type=0x8
                ID=0x4036014
                LocId=0x23
                SerialNumber=FTP6SN3W
                Description=FT232H
                ftHandle=0x0 (0 unless channel is open)

Version Check
libmpsse: 00010001
libftd2xx: 00030216

handle=0xdc83a0 status=0
MMC5983MA_IO_WindowsQwiic_C::init opened and initialized channel AOK
set_reg 0a Control register 1 <= 80
Wait >10mSec after reset
get_reg 2f Product ID => 30
set_reg 0a Control register 1 <= 00
set_reg 09 Control register 0 <= 10
set_reg 09 Control register 0 <= 01
get_reg 08 Device status => 11
get_reg 00 Xout [17:10] => 80
get_reg 01 Xout [9:2] => bc
get_reg 02 Yout [17:10] => 7a
get_reg 03 Yout [9:2] => 48
get_reg 04 Zout [17:10] => 77
get_reg 05 Zout [9:2] => 33
get_reg 06 Xout[1:0],Yout[1:0],Zout[1:0] => 94
set_reg 09 Control register 0 <= 08
set_reg 09 Control register 0 <= 01
get_reg 08 Device status => 11
get_reg 00 Xout [17:10] => 80
get_reg 01 Xout [9:2] => b9
get_reg 02 Yout [17:10] => 83
get_reg 03 Yout [9:2] => 0f
get_reg 04 Zout [17:10] => 88
get_reg 05 Zout [9:2] => de
get_reg 06 Xout[1:0],Yout[1:0],Zout[1:0] => 44
Compass:   0.08
set_reg 09 Control register 0 <= 10
set_reg 09 Control register 0 <= 01
get_reg 08 Device status => 11
get_reg 00 Xout [17:10] => 84
get_reg 01 Xout [9:2] => 22
get_reg 02 Yout [17:10] => 7f
get_reg 03 Yout [9:2] => 21
get_reg 04 Zout [17:10] => 77
get_reg 05 Zout [9:2] => 31
get_reg 06 Xout[1:0],Yout[1:0],Zout[1:0] => 90
set_reg 09 Control register 0 <= 08
set_reg 09 Control register 0 <= 01
get_reg 08 Device status => 11
get_reg 00 Xout [17:10] => 7d
get_reg 01 Xout [9:2] => 47
get_reg 02 Yout [17:10] => 7e
get_reg 03 Yout [9:2] => 77
get_reg 04 Zout [17:10] => 88
get_reg 05 Zout [9:2] => e8
get_reg 06 Xout[1:0],Yout[1:0],Zout[1:0] => 5c
Compass:  95.53
set_reg 09 Control register 0 <= 10
set_reg 09 Control register 0 <= 01
get_reg 08 Device status => 11
get_reg 00 Xout [17:10] => 80
get_reg 01 Xout [9:2] => 01
get_reg 02 Yout [17:10] => 82
get_reg 03 Yout [9:2] => b3
get_reg 04 Zout [17:10] => 77
get_reg 05 Zout [9:2] => 6a
get_reg 06 Xout[1:0],Yout[1:0],Zout[1:0] => e0
set_reg 09 Control register 0 <= 08
set_reg 09 Control register 0 <= 01
get_reg 08 Device status => 11
get_reg 00 Xout [17:10] => 81
get_reg 01 Xout [9:2] => 92
get_reg 02 Yout [17:10] => 7b
get_reg 03 Yout [9:2] => 3c
get_reg 04 Zout [17:10] => 88
get_reg 05 Zout [9:2] => c4
get_reg 06 Xout[1:0],Yout[1:0],Zout[1:0] => 8c
Compass: 191.83
set_reg 09 Control register 0 <= 10
set_reg 09 Control register 0 <= 01
get_reg 08 Device status => 11
get_reg 00 Xout [17:10] => 7d
get_reg 01 Xout [9:2] => 14
get_reg 02 Yout [17:10] => 7e
get_reg 03 Yout [9:2] => b4
get_reg 04 Zout [17:10] => 77
get_reg 05 Zout [9:2] => 1c
get_reg 06 Xout[1:0],Yout[1:0],Zout[1:0] => 34
set_reg 09 Control register 0 <= 08
set_reg 09 Control register 0 <= 01
get_reg 08 Device status => 11
get_reg 00 Xout [17:10] => 84
get_reg 01 Xout [9:2] => 65
get_reg 02 Yout [17:10] => 7f
get_reg 03 Yout [9:2] => 29
get_reg 04 Zout [17:10] => 89
get_reg 05 Zout [9:2] => 15
get_reg 06 Xout[1:0],Yout[1:0],Zout[1:0] => 3c
Compass: 273.57

Hi!

FT600q.
By accident, during configuration, the Manufacturer, Description, Serial (via API function) fields were incorrectly set! From then on, the IC is not available, even the driver indicates an error (STATUS_DEVICE_DATA_ERROR)!

The factory configuration program can't open it either, so I can't rewrite these fields either.
How can I get it to work again?

Thanks,
Zoltan

Thanks, I have emailed US support.
It would be really great if you could put the updated library on the web site;
would spare all of us a lot of grief, thanks!

Hello All,

We have a beta version of libMPSSE 1.0.4 which fixes all known issues.

Please contact support1@ftdichip.com for this version before we release it to our website.

Let us know if you have any feedback please.

Best Regards,
FTDI Community

Hello,

We have a new libmpsse version that you can try (V1.0.4).

Please contact your local support team for this:

https://ftdichip.com/technical-support/

The alternative is not to use LibMPSSE library and use D2xx driver direct which will give you more control:

To use I2C/SPI as a master (no slave functionality), see AN_135 MPSSE Basics and our existing MPSSE Example projects:
 
https://ftdichip.com/software-examples/mpsse-projects/
 
There are two options to use I2C/SPI modes with the MPSSE engine:
 
a.   Use LibMPSSE libraries. Example code is provided with the download. Source code is also provided.
b.   Use D2XX drivers direct. Example code is shown at I2C / SPI. AN_108 Command Processor For MPSSE and MCU Host Bus Emulation Modes provides the necessary information.
 
Option b is the best option to use the D2XX drivers direct (no dependency on libMPSSE library).

Best Regards,
FTDI Community

As an update, the support people reviewed my schematic, and found an issue -- an EEPROM is actually required for the FT232H's self powered operation mode, because you have to configure the chip to self powered in the EEPROM.  Also, ACBUS7 should be set so that the pin is pulled up  to 3.3V when USB VBUS is active.

That said, this still doesn't explain why it wouldn't enumerate on my board after the reworks, and I think I may have to give up on this chip for now.

Hi Terry,

we see no issue with this.

if you are looking for more control, you can utilize the MPSSE engine using the D2XX drivers directly. This will mean you will not have to rely on LibMPSSE.

To use I2C/SPI as a master (no slave functionality), see AN_135 MPSSE Basics and our existing MPSSE Example projects:
 
https://ftdichip.com/software-examples/mpsse-projects/
 
There are two options to use I2C/SPI modes with the MPSSE engine:
 
a.   Use LibMPSSE libraries. Example code is provided with the download. Source code is also provided.
Note there is a known issue with this library with I2C. See LibMPSSE Beta 1.0.2 which shows the source code change to allow you to rebuild.
b.   Use D2XX drivers direct. Example code is shown at I2C / SPI. AN_108 Command Processor For MPSSE and MCU Host Bus Emulation Modes provides the necessary information.
 
Option b is the best option to use the D2XX drivers direct (no dependency on libMPSSE library).

Best Regards
FTDI Community

about SPI Interface Speed

Hello,

could you please email your schematic to support1@ftdichip.com? we can then review it for you to see if there is anything that could be causing your issue.

Best regards
FTDI Community

Hello all!  I am working on a PCB design (open source here, the FT232H is on page 3) which uses an FT232H to provide USB to SPI/I2C/UART conversion.  I've been testing the first board for some time, and have been unable to get any response out of the FT232H chip.  I see that it's outputting power on the VPHY and VPLL pins, but it has not been responsive over the USB interface -- both USB pins seem to be stuck floating.

The elephant in the room with my design is that I didn't provide an EEPROM for the FT232H, since the datasheet indicates it's not required (this board will only be used internally and I don't need to use a custom VID/PID or any permanent configuration).  However, I couldn't find any examples whatsoever of how to connect the EEPROM pins when there isn't an EEPROM on the board, so I wasn't entirely sure what to do.  Originally I tried pulling EEDATA low, and then I tried reworking the board to pull all three EEPROM pins high, but neither seemed to produce a response.

Things I have tried so far:

• Pulling pin 31 (ACBUS7/PWRSAV#) high in case the chip is in sleep mode (even though the datasheet indicates that this function is disabled without an EEPROM
• Replacing the chip on the board
• Pulling all the EEPROM pins high
• Cutting the traces from the internal USB hub and bodge soldering on a USB cable direct to my PC (so I can rule out the internal hub)
• Measuring voltages on every pin.  I don't remember the exact results but there was nothing that seemed abnormal (except that, when I had the pulldown on EEDATA, it was at like 0.4V
• Attaching a 1Ghz logic analyzer to the USB traces.  Did not observe any activity other than the host device trying fruitlessly to reset the FT232H

After all this, I'm about out of ideas.  Does anyone know if there's anything special I need to do to get the FT232H to work without an EEPROM attached?  Are there any other troubleshooting steps I can do to diagnose the issue?  I'm just about to give up and redesign with a competitor chip (CY7C65211), so any tips would be appreciated!