FT4222 device info correct under Windows, incorrect under Linux?

Question

I am trying to communicate with an FT4222 chip using libft4222. When I run the following example code provided by FTDI, I receive different responses between Windows and Linux platforms.

Sample code:

FT_STATUS ftStatus;
FT_DEVICE_LIST_INFO_NODE *devInfo;
DWORD numDevs;
// create the device information list
ftStatus = FT_CreateDeviceInfoList(&numDevs);
if (ftStatus == FT_OK) {
    printf("Number of devices is %d\n",numDevs);
}
if (numDevs > 0) {
    // allocate storage for list based on numDevs
    devInfo =
    (FT_DEVICE_LIST_INFO_NODE*)malloc(sizeof(FT_DEVICE_LIST_INFO_NODE)*numDevs);
    // get the device information list
    ftStatus = FT_GetDeviceInfoList(devInfo,&numDevs);
    if (ftStatus == FT_OK) {
        for (int i = 0; i < numDevs; i++) {
            printf("Dev %d:\n",i);
            printf(" Flags=0x%x\n",devInfo[i].Flags);
            printf(" Type=0x%x\n",devInfo[i].Type);
            printf(" ID=0x%x\n",devInfo[i].ID);
            printf(" LocId=0x%x\n",devInfo[i].LocId);
            printf(" SerialNumber=%s\n",devInfo[i].SerialNumber);
            printf(" Description=%s\n",devInfo[i].Description);
            printf(" ftHandle=0x%x\n",devInfo[i].ftHandle);
        }
    }
}

On Windows I receive the following output, which looks correct:

Dev 0:
Flags= 0x2, (CLOSE-HS)
Type= 0xa
ID= 0x403601c
LocId= 0x1131
SerialNumber= A
Description= FT4222 A
ftHandle= 0x0
Dev 1:
Flags= 0x0, (CLOSE-FS)
Type= 0xa
ID= 0x403601c
LocId= 0x1132
SerialNumber= B
Description= FT4222 B
ftHandle= 0x0

On Linux (x64 Ubuntu, running i386 version of libft4222 and my test application) I receive the following output, which looks incorrect:

Dev 0:
Flags= 0x1, (OPEN-FS)
Type= 0x3
ID= 0x0
LocId= 0x0
SerialNumber=
Description=
ftHandle= 0x0
Dev 1:
Flags= 0x1, (OPEN-FS)
Type= 0x3
ID= 0x0
LocId= 0x0
SerialNumber=
Description=
ftHandle= 0x0

I'm curious why the difference between systems? Why is one showing as Closed while the other shows as Open?

EDIT: lsusb -v displays the following for this device:

Bus 001 Device 015: ID 0403:601c Future Technology Devices International, Ltd 
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0403 Future Technology Devices International, Ltd
  idProduct          0x601c 
  bcdDevice           18.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           55
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              2 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              2 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               0

Any reason you added the C++ tag? A a quick glance, the code looks like pure C. Do you use a C or C++ compiler? — too honest for this site, Sep 28 '16 at 21:06
I'm using a C++ compiler. I'm originally writing a C++ application, but reduced it down to the test code for now to ensure I wasn't causing this issue. I suppose the C++ tag should be removed, sorry. — schumacher574, Sep 28 '16 at 21:07
I'm not familar with that device. Verify the fields yourself. And maybe you try the open source driver, if there is any. Those closed-source drivers may be outdated, or whatever. — too honest for this site, Sep 28 '16 at 21:07
If you compile as C++, the C tag is incorrect! C and C++ are different languages. Identical syntax does not imply identical semantics! — too honest for this site, Sep 28 '16 at 21:08
@Olaf I tagged as such because those are the two languages that members of the community might be using with the libft4222 library I'm using and was hoping someone from either would share a common experience. — schumacher574, Sep 28 '16 at 21:10
Questions have to be tagged with the language they use, not what the asker **thinks** will attract the most attention! Any maybe using the wrong compiler is the reason for the fishy results you get. — too honest for this site, Sep 28 '16 at 21:12
@Olaf OK. If I run with a C compiler as well, same issue. Why not tag under both??? It affects both. — schumacher574, Sep 28 '16 at 21:14
Possible duplicate of [Undefined reference to mempcy@GLIBC\_2.14 when compiling on Linux](https://stackoverflow.com/q/12286460/608639) — jww, Feb 22 '19 at 01:08

schumacher574 · Accepted Answer · 2016-09-30T16:48:09.493

After trying with Kali i386, everything worked fine. I thought this meant the library didn't work well with amd64 OS flavors, so I tried with Ubuntu i386. Same problem as before - incorrect device info.

Found that the real issue was with Kali I was logging in under the root account. With Ubuntu, root account login is unavailable. After executing my test application with sudo, the information retrieved from the FT4222 chip was correct.

Proper solution is likely to use a udev rule to modify permissions for the FT4222 device.

score 0 · Answer 2 · answered May 20 '18 at 10:50

under debian this udev rule helped me to avoid sudo rights:

 ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", MODE="0666",  RUN+="/bin/sh -c 'rmmod ftdi_sio && rmmod usbserial'

also it might be important that your $USER is part of the group dialout

FT4222 device info correct under Windows, incorrect under Linux?

2 Answers2