FT232 USB tests fail if no iProduct field set.

[DaveBerkeley]

I'm trying to use a standard FT232H breakout board as a JTAG programmer.

It uses the same FTDI device as my jtag-hs3. However, the open device fails with an error trying to read the iProduct field. The call to libusb_get_string_descriptor_ascii() fails.

Not sure why this test was added to FTDIpp_MPSSE().

Would a clearer error message help?

Is there a way of programming the FTDI device so that iProduct has a value?

Can this behaviour be (optionally?) disabled so that off-the-shelf FT232H devices can be used?

[trabucayre]

Which version you use for openFPGALoader, libftdi and libusb? Which cable/board you use? It's weird this is just an info. Could you paste error message? It's possible to comment this block of code to test if rest of the procedure is working.

[DaveBerkeley]

I'm using a recent git commit d7365495aa

$ uname -a Linux via 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

$ dpkg -l | grep libftdi ii libftdi1:amd64 0.20-4build8 amd64 Library to control and program the FTDI USB controller ii libftdi1-2:amd64 1.4-2build2 amd64 Library to control and program the FTDI USB controllers ii libftdi1-dev 1.4-2build2 amd64 Development files for libftdi1 ii libftdi1-doc 1.4-2build2 all Documentation for libftdi1 $ dpkg -l | grep libusb ii libgusb2:amd64 0.3.4-0.1 amd64 GLib wrapper around libusb1 ii libhidapi-libusb0:amd64 0.9.0+dfsg-1 amd64 Multi-Platform library for communication with HID devices (libusb backend) ii libusb-0.1-4:amd64 2:0.1.12-32 amd64 userspace USB programming library ii libusb-1.0-0:amd64 2:1.0.23-2build1 amd64 userspace USB programming library ii libusb-1.0-0-dev:amd64 2:1.0.23-2build1 amd64 userspace USB programming library development files ii libusb-1.0-doc 2:1.0.23-2build1 all documentation for userspace USB programming ii libusb-dev 2:0.1.12-32 amd64 userspace USB programming library development files ii libusbmuxd6:amd64 2.0.1-2 amd64 USB multiplexor daemon for iPhone and iPod Touch devices - library

I have a JTAG-HS3 which works fine. But if I use an Adafruit FT232H breakout board, which uses the same FTDI part https://www.adafruit.com/product/2264 I get an error.

lsusb -v for the 2 devices shows :

Bus 001 Device 050: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC Device Descriptor: ... iManufacturer 1 Digilent iProduct 2 Digilent USB Device iSerial 3 210299B3975A ...

And .... Device Descriptor: idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6014 FT232H Single HS USB-UART/FIFO IC bcdDevice 9.00 iManufacturer 1 (error) iProduct 2 (error) iSerial 3 (error) bNumConfigurations 1

So the libusb_get_string_descriptor_ascii() call is returning an error code, even in lsusb.

If I simply turn off this check, by commenting out the call to libusb_get_string_descriptor_ascii(), it works fine.

The current code prevents you from using a part that does not have the iProduct string set in the FTDI ROM. Would it be better to print a warning rather than throwing an exception?

[trabucayre]

In my mind a check of return code is required to see if it's a real error (access) or if it's only because this field is empty. Thanks to point that!

[DaveBerkeley]

It looks like it is returning an error code (ret < 0), not bytes_read==0. So I don't think the call can distinguish between an error and a string that has not been set. "lsusb -v" also says (error) for the field. It would be good to be able to use cheap FT232H adapters, but perhaps they should have the data set? I'm not sure how to do this. I've always been wary of reprogramming the ROM on FTDI devices.

[trabucayre]

Same conclusion. I have updated ftdipp_mpsse: now a warning is displayed and _iproduct is set as an empty string. No more exception. In fact this attribute is used for digilent probe and ch552 clone for Workarounds. It's just weird, usually with adapters a custom iProduct is configured or default one is left unchanged, it's the first time I see that. It's always possible to rewrite eeprom with ftdi_eeprom or a code like this

[DaveBerkeley]

That works fine, thanks.