I am trying t devlop an SPI interface for the FT2232H on a windows7 64Bit system. I successfully created the VI to get Get the high speed device name info however when I try to OPEN it, i get a error code of 27. I have tried the SPI samples provided from FTDI website and get "device not found" , however when I try the FTD2xx VIs It seems to work. I have included screen shots of the Front panel and block diagram.
Anyone have/had similar issues?
So are you refering to the with the D2XX functions from the FTDI website? You mentioned that these specific functions work, but are they not completely functional? I just don't have a full understanding of the situation at hand and need a little more detail to see what direction we need to head in.
It is the FTCSPI.DLL funtions that are giving me the issue. The latest revison(2.0) causes the error when trying to OPEN the device. I get the error code and no handle. However when I try an older release of the DLL it works. I am going to try and contact FTDI with the issue. I'll post when I know more.
Hi went through quite a bit of grief likewise when trying to use the SPI dll. Does your system have a USB 3.0 port? Per FTDI Tech Support, there is a known problem with select USB hub vendors not somehow properly populating the USB registry fields under Windows 7 (only) with USB 3.0 ports. This confuses or breaks the FTDI interface, specifically the the LocID field. They recommend using the rudimentary FT commands instead of the FTSPI commands. This is what I am proceeding with. Questiongs still linger over this description, but moving forward.
The exact tech description provided was:
The NEC/Renesas card loaned to us would not install on our Win 7 machine but we did get it installed on XP and were able to do some tests. Plugging one device in and installing operated OK despite the registry not appearing as expected.
Plugging 2 devices in failed. Pre-installing on USB 2.0 host (installed on same PC) and then moving the devices to the 3.0 ports is OK.
Obviously Microsoft have not provided 3.0 support yet which is why you need to install the drivers supplied with the card.
This is where things go wrong.
In the registry you see
And would then expect
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ROOT_HUB30 to follow on for 3.0.
This is the first place to look for the host, but because it is not supported by MS and NEC/Renesas have provided their own driver, they have not created this key. It then follows on that all existing host ports on a Windows machine are given a name in the format: \device\usbfdo-# where # is a number.
The USB 3.0 card provided is known as a \device\device# where # is a number.
Because this host port is not following the standard naming convention on a windows machine we do not attempt to open this port to send device ID to when enumerating and trying to load drivers.
As we expect Microsoft to follow convention when they add support for 3.0, we expect the problem to go away from our point of view. As such we are still of the opinion the problem lies with the 3.0 host and not our drivers.
Even if it was possible to make changes to support this host controller it is highly probable that the next host device you try (different manufacturer) will have another variant requiring a different modification. This would not be a sustainable model and goes against the PnP ethos of USB.