#8 Exception "not MPSSE capable" at FT232H

[Oliver Lenz]

Hi Stephen

I've got an IllegalArgumentException which I don't understand:

Exception in thread "main" java.lang.IllegalArgumentException: Supplied device is not MPSSE capable.
at net.sf.yad2xx.mpsse.Mpsse.<init>(Mpsse.java:87)
at net.sf.yad2xx.mpsse.Mpsse.<init>(Mpsse.java:74)
at net.sf.yad2xx.mpsse.Spi.<init>(Spi.java:96)
at hardwaretests.SpiDiagnostics.main(SpiDiagnostics.java:71)

The only device I have connected is a FT232H which provides MPSSE-mode definitly.

Its occuded during a small test programm which I have carelessly shit together and I don't wonder to get an exception but only what the exception suggets. The most probably reason could be a bad closed Spi-object. I try to reproduce them, but can't promise any results.

[Stephen Davies]

Hi Oliver,
agreed, that doesn't sound right.

MPSSE capability is hardcoded into the DeviceType class. With an FT232H attached device.getType() should return DeviceType.FT_DEVICE_232H.

If you are able to debug, what is returned when device.getType() is called? I suspect it may be DeviceType.FT_DEVICE_UNKNOWN.

[Stephen Davies]

Also,
I would be interested in the output of the ListDevices sample program.

Instructions on how to run it can be found under 'First Steps' in
https://sourceforge.net/p/yad2xx/wiki/BinaryInstallation/

[Oliver Lenz]

Hi Stephen

Unfourtanly I'm not able to reproduce the issue. But here is the output from the ListDevice sample:

---

Got 1 devices
Dev 0:
Flags=1 (isOpen: true isHighSpeed: false)
Type=3 (FT_DEVICE_UNKNOWN)
ID=0
locID=0
SerialNumber=
Description=
ftHandle=0

At Least, here is the output from my first test with yad2xx, I tried to repeat the ListDevices sample to get familiar with the methods:

Device 0:
Beschreibung: Single RS232-HS //description
Seriennummer: //serial number
Bitmode: -1
Typ: 232H //type
Treiber-Version: 2.18.40 //driver version
Device open: true
High Speed: true
Queue-Status: 0

I also have an other issue for you, but I think this would be stuff for a new ticket.

[Stephen Davies]

Ok,
seems to me that the VCP driver is being selected, rather the the D2XX driver.

Try this:
1) Open the Windows Device Manager
2) Expand Universal Serial Bus Controllers
3) There should be an entry for the FT232H, probably named USB Serial Converter
4) Select the device and open its Properties
5) Open the Advanced tab

If the Load VCP box is checked this means the VCP driver has control. Your device is operating as a COM port and is not available to D2XX (or yad2xx). Uncheck the box, then unplug and reattach the device.

Let me know how this goes.

[Oliver Lenz]

Hi Stephen

Well, the VCP was selected in usb properties, I've it checked and changed it now.

Yesterday, the problem does not occur after a simple program restart. Is there any possibility to check the driver mode before device access?
After all, the FTDIInterface.getDevices-method seems to recognize the device as an D2XX-device. In other cases, I would not be able to get access the device. And therefore I can't do anything what provokes this exception (exclude other reasons then wrong driver mode).

[Stephen Davies]

Hi Oliver,
this is not an issue with yad2xx, it is an FTDI 'feature'.

See FTDI's AN232R-04 Windows Combined Driver Model pg 5 for information.

[Oliver Lenz]

Well, I know the double driver mode with D2XX and VCP.
Is switching between the different modes completly automaticly? It would be nice if I could prevent and handle such exceptions, unexpected behavior is, in special if software user see only a crashing programm with confusing error message, unfortunate.

Well, this happens the first time after many tests, so I don't expect this often. But handling would be better. Cause, if it occures, then it occures during presentation of "ready programm".

[Stephen Davies]

My experience with FTDI drivers is that they are more complicated and less documented than I would like, both macOS and Windows.

My understanding of the current Windows CDM is that there is a bit in the devices EEPROM that can be set to indicate VCP/D2XX driver preference. The FTProg utility fom FTDI lets you mess with the EEPROM settings.

Another issue that used to be a problem (haven't tested this in a while) is that changing the USB port (i.e. moving) would create a new COM port. Under certain conditions simply plugging back into the SAME USB port would create a new COM port.

I added support for FT_Rescan() and FT_Reload() in 1.0, perhaps they can help?

You are probably best to pursue this with FTDI support.

[Oliver Lenz]

I added support for FT_Rescan() and FT_Reload() in 1.0, perhaps they can help?

Really nice...this will be really helpfull.

[Stephen Davies]

Oliver,
are you still having driver issues?