FTDI device shows up in windows, not in linux

c2hollow · 2014-06-19 20:19:52

I have an FPGA development board with an FTDI chip for usb communication. I have downloaded the windows and linux sample code and drivers, and installed them according to FTDI's instructions.

In Windows, my dev board shows up when I run the FTDI sample code for listing devices, but not in Arch Linux.

In Arch Linux, the device shows up in lsusb and I am able to program the FPGA over the usb connection, so it seems odd to me that the FTDI sample application is not seeing it.

I'm not really familiar with how usb interfaces work, so any suggestions for how to proceed or debug this would be appreciated.

c2hollow · 2014-06-19 20:43:04

When I plug it in, all that shows up in dmesg is:

[  337.086902] usb 3-1.2: new full-speed USB device number 6 using ehci-pci

Should I see the FTDI driver recognizing this device?

c2hollow · 2014-06-19 20:49:23

I was reading the FTDI installation guide, and it said that the VCP modules are incompatible with this module. However, neither of these modules were loaded in my system, so that's not it.

[c2hollow@bluerocket Downloads]$ sudo rmmod usbserial ftdi_sio
rmmod: ERROR: Module usbserial is not currently loaded
rmmod: ERROR: Module ftdi_sio is not currently loaded

ewaller · 2014-06-19 20:53:37

Did you look in /dev for something of the form /dev/ttyUSBx when you attach it?
Almost every FTDI device I've ever hooked to my box works. Even one that my dad bought that was apparently built using a counterfeit chip. The Windows driver on his Windows box refused to use it, It worked swimmingly in Linux.

One other thing to check. Ensure that your running kernel (uname -a) is the same version as the one that is installed (pacman -Qi linux). It won't work if your kernel cannot find its modules.

c2hollow · 2014-06-19 21:05:35

My running kernel is the same that is installed. Nothing shows up for /dev/ttyUSB

it's weird, a different ftdi device runs perfectly fine:

[c2hollow@bluerocket read]$ dmesg | grep ftdi
[ 2252.656305] usbcore: registered new interface driver ftdi_sio
[ 2252.656680] ftdi_sio 3-1.2:1.0: FTDI USB Serial Device converter detected
[ 2276.238394] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 2276.238424] ftdi_sio 3-1.2:1.0: device disconnected

Trilby · 2014-06-19 21:06:31

Every FTDI I've used also works well in archlinux - but they usually show up as /dev/ttyACMx (eg /dev/ttyACM0). But regardless of what it displays as, just check /dev/ before and after plugging it in and look for anything different. You can save each listing to a file then diff the "pre" and "post" files.

From the information provided so far, it sounds like the device is fine and linux is fine - but you got some sample code that doesn't work. The problem is likely in the sample code. If you post (or link to) it, we can see if anything jumps out.

Also, if you haven't done any configuration of groups or user permissions, you'd need to run that example code as root. It's definitely safer and better to set up permissions well, but one or the other will be needed for the sample code to use the FTDI.

Last edited by Trilby (2014-06-19 21:07:32)

c2hollow · 2014-06-19 21:15:42

Okay, here's the sample code:

/*
	Simple example to open a maximum of 4 devices - write some data then read it back.
	Shows one method of using list devices also.
	Assumes the devices have a loopback connector on them and they also have a serial number

	To build use the following gcc statement 
	(assuming you have the d2xx library in the /usr/local/lib directory).
	gcc -o simple main.c -L. -lftd2xx -Wl,-rpath /usr/local/lib
*/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include "../ftd2xx.h"

#define BUF_SIZE 0x10

#define MAX_DEVICES		5



static void dumpBuffer(unsigned char *buffer, int elements)
{
	int j;

	printf(" [");
	for (j = 0; j < elements; j++)
	{
		if (j > 0)
			printf(", ");
		printf("0x%02X", (unsigned int)buffer[j]);
	}
	printf("]\n");
}



int main()
{
	unsigned char 	cBufWrite[BUF_SIZE];
	unsigned char * pcBufRead = NULL;
	char * 	pcBufLD[MAX_DEVICES + 1];
	char 	cBufLD[MAX_DEVICES][64];
	DWORD	dwRxSize = 0;
	DWORD 	dwBytesWritten, dwBytesRead;
	FT_STATUS	ftStatus;
	FT_HANDLE	ftHandle[MAX_DEVICES];
	int	iNumDevs = 0;
	int	i, j;
	int	iDevicesOpen;	
	for(i = 0; i < MAX_DEVICES; i++) {
		pcBufLD[i] = cBufLD[i];
	}
	pcBufLD[MAX_DEVICES] = NULL;
	
	ftStatus = FT_ListDevices(pcBufLD, &iNumDevs, FT_LIST_ALL | FT_OPEN_BY_SERIAL_NUMBER);
	
	if(ftStatus != FT_OK) {
		printf("Error: FT_ListDevices(%d)\n", (int)ftStatus);
		return 1;
	}

	for(i = 0; ( (i <MAX_DEVICES) && (i < iNumDevs) ); i++) {
		printf("Device %d Serial Number - %s\n", i, cBufLD[i]);
	}

	for(j = 0; j < BUF_SIZE; j++) {
		cBufWrite[j] = j;
	}
	
	for(i = 0; ( (i <MAX_DEVICES) && (i < iNumDevs) ) ; i++) {
		/* Setup */
		if((ftStatus = FT_OpenEx(cBufLD[i], FT_OPEN_BY_SERIAL_NUMBER, &ftHandle[i])) != FT_OK){
			/* 
				This can fail if the ftdi_sio driver is loaded
		 		use lsmod to check this and rmmod ftdi_sio to remove
				also rmmod usbserial
		 	*/
			printf("Error FT_OpenEx(%d), device %d\n", (int)ftStatus, i);
			printf("Use lsmod to check if ftdi_sio (and usbserial) are present.\n");
			printf("If so, unload them using rmmod, as they conflict with ftd2xx.\n");
			return 1;
		}
	
		printf("Opened device %s\n", cBufLD[i]);

		iDevicesOpen++;
		if((ftStatus = FT_SetBaudRate(ftHandle[i], 9600)) != FT_OK) {
			printf("Error FT_SetBaudRate(%d), cBufLD[i] = %s\n", (int)ftStatus, cBufLD[i]);
			break;
		}

		printf("Calling FT_Write with this write-buffer:\n");
		dumpBuffer(cBufWrite, BUF_SIZE);
		
		/* Write */
		ftStatus = FT_Write(ftHandle[i], cBufWrite, BUF_SIZE, &dwBytesWritten);
		if (ftStatus != FT_OK) {
			printf("Error FT_Write(%d)\n", (int)ftStatus);
			break;
		}
		if (dwBytesWritten != (DWORD)BUF_SIZE) {
			printf("FT_Write only wrote %d (of %d) bytes\n", 
			       (int)dwBytesWritten, 
			       BUF_SIZE);
			break;
		}
		sleep(1);
		
		/* Read */
		dwRxSize = 0;			
		while ((dwRxSize < BUF_SIZE) && (ftStatus == FT_OK)) {
			ftStatus = FT_GetQueueStatus(ftHandle[i], &dwRxSize);
		}
		if(ftStatus == FT_OK) {
			pcBufRead = realloc(pcBufRead, dwRxSize);
			memset(pcBufRead, 0xFF, dwRxSize);
			printf("Calling FT_Read with this read-buffer:\n");
			dumpBuffer(pcBufRead, dwRxSize);
			ftStatus = FT_Read(ftHandle[i], pcBufRead, dwRxSize, &dwBytesRead);
			if (ftStatus != FT_OK) {
				printf("Error FT_Read(%d)\n", (int)ftStatus);
				break;
			}
			if (dwBytesRead != dwRxSize) {
				printf("FT_Read only read %d (of %d) bytes\n",
				       (int)dwBytesRead,
				       (int)dwRxSize);
				break;
			}
			printf("FT_Read read %d bytes.  Read-buffer is now:\n",
			       (int)dwBytesRead);
			dumpBuffer(pcBufRead, (int)dwBytesRead);
			if (0 != memcmp(cBufWrite, pcBufRead, BUF_SIZE)) {
				printf("Error: read-buffer does not match write-buffer.\n");
				break;
			}
			printf("%s test passed.\n", cBufLD[i]);
		}
		else {
			printf("Error FT_GetQueueStatus(%d)\n", (int)ftStatus);	
		}

	}

	iDevicesOpen = i;
	/* Cleanup */
	for(i = 0; i < iDevicesOpen; i++) {
		FT_Close(ftHandle[i]);
		printf("Closed device %s\n", cBufLD[i]);
	}

	if(pcBufRead)
		free(pcBufRead);
	return 0;
}

For the FTDI device that does work, I get this output:

[c2hollow@bluerocket Simple]$ sudo ./simple
Device 0 Serial Number - A9005Y0i
Opened device A9005Y0i
Calling FT_Write with this write-buffer:
 [0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F]

for the other device, nothing gets printed, however it does show up in Windows.

ewaller · 2014-06-19 21:19:59

Okay... When the device is attached, please post the output of lsusb -v.

Trilby · 2014-06-19 21:22:54

c2hollow wrote:

For the FTDI device that does work ... for the other device...

I've been rereading this thread as I think I may completely misunderstand. But after rereading this is not becoming more clear. I thought you had one device that worked in windows, but doesn't in arch. But now it seems a FTDI device works in linux (good, same here) but there is some "other device" that doesn't. I'm confused on what this other device is. Do you have more than one FTDI?

Thanks for the code, but it seems a lot of the interesting stuff is handled by other code. There is a reference to a header file ... is there somewhere you downloaded this code from where we could also get it?

c2hollow · 2014-06-19 21:23:55

here's the output of the device that is giving me trouble:

Bus 003 Device 013: ID 09fb:6001 Altera Blaster
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x09fb Altera
  idProduct          0x6001 Blaster
  bcdDevice            4.00
  iManufacturer           1 Altera
  iProduct                2 USB-Blaster
  iSerial                 3 91d28408
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              150mA
    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 USB-Blaster
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 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     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

ewaller · 2014-06-19 21:26:34

Doing some FPGA development, are we?

I'm looking that over

c2hollow · 2014-06-19 21:26:55

I've been rereading this thread as I think I may completely misunderstand. But after rereading this is not becoming more clear. I thought you had one device that worked in windows, but doesn't in arch. But now it seems a FTDI device works in linux (good, same here) but there is some "other device" that doesn't. I'm confused on what this other device is. Do you have more than one FTDI?

I have an FPGA dev board with an FTDI usb interface. The FTDI sample code works on windows but not in linux, however the programming software that is supposed to be used with the dev board works in linux.

As a check that the sample code works in linux, I've shown the output of a different FTDI device that does appear to be working with the FTDI driver to compare.

c2hollow · 2014-06-19 21:29:00

I'm wondering if the problem is that linux is picking up that it's an altera device, not an FTDI device?

Windows also sees the device as an altera device though.

Trilby · 2014-06-19 21:29:42

Thanks for the clarification - that makes a lot more sense now. Unfortunately that also now puts it outside my current experience.

ewaller · 2014-06-19 21:34:11

Yeah, I don't think the Blaster uses an FTDI chip. Your target might, but not the programmer. It definitely shows up as with the Vendor being Altera.

A quick look indicates that the device requires the usbfs module <ewaller trots off to look at the kernel configuration>

c2hollow · 2014-06-19 21:54:50

When I plug in the device, it automatically loads the ehci_pci module, but I don't think I want it to load that module, I want it to use this FTDI module.

With the other (working) FTDI device, the sample code does not work until I unload the ftdi_serial module... I'm wondering if the same thing happens.

Is there a way to unload a module only for a specific port? If I unload ehci_pci, bad things will happen.

ewaller · 2014-06-19 22:23:03

When you attach the device, does /proc/bus/usb appear?
My concern is that usbfs seems to have been deprecated, and that device uses that driver

Edit, BTW I am looking at http://www.altera.com/literature/ug/ug_usb_blstr.pdf

For Red Hat Enterprise 5
1. Create a file named
/etc/udev/rules.d/51-usbblaster.rules
and add the following
lines to it. Take note that after
#USB-Blaster
, all code must be in one line.
# USB-Blaster
BUS=="usb", SYSFS{idVendor}=="09fb", SYSFS{idProduct}=="6001",
MODE="0666", PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf
/proc/bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", RUN+="/bin/chmod 0666
%c"

Give that a try

Edit 2:
Also, when you attach the device, does /dev/bus/usb materialize? If so, and if the /proc entry does not show up, try (as root)

mount --bind /dev/bus/usb /proc/bus/usb
Then try your Quartus software

Last edited by ewaller (2014-06-19 22:33:07)

c2hollow · 2014-06-19 23:08:56

if usbfs was the problem, you would expect it to show up in lsmod whenever the device is plugged in, right? At the moment it does not.

Also, I've already run through the process and gotten the USB blaster set up in linux. That's not my problem. My problem is talking to the FTDI chip. In Windows, I can talk to either the FTDI chip or the usb-blaster simultaneously without issue.

c2hollow · 2014-06-19 23:12:24

FYI, I'm trying to access the system level debug information without using the Altera software, so that I can get data off of my FPGA dev board on any computer, even if the 2 Gb of altera software is not installed.

But I'm starting to wonder if this is a fool's errand, because it seems like you have to install the 2Gb of software just to get the usb drivers working on any OS.

Arch Linux

#1 2014-06-19 20:19:52

FTDI device shows up in windows, not in linux

#2 2014-06-19 20:43:04

Re: FTDI device shows up in windows, not in linux

#3 2014-06-19 20:49:23

Re: FTDI device shows up in windows, not in linux

#4 2014-06-19 20:53:37

Re: FTDI device shows up in windows, not in linux

#5 2014-06-19 21:05:35

Re: FTDI device shows up in windows, not in linux

#6 2014-06-19 21:06:31

Re: FTDI device shows up in windows, not in linux

#7 2014-06-19 21:15:42

Re: FTDI device shows up in windows, not in linux

#8 2014-06-19 21:19:59

Re: FTDI device shows up in windows, not in linux

#9 2014-06-19 21:22:54

Re: FTDI device shows up in windows, not in linux

#10 2014-06-19 21:23:55

Re: FTDI device shows up in windows, not in linux

#11 2014-06-19 21:26:34

Re: FTDI device shows up in windows, not in linux

#12 2014-06-19 21:26:55

Re: FTDI device shows up in windows, not in linux

#13 2014-06-19 21:29:00

Re: FTDI device shows up in windows, not in linux

#14 2014-06-19 21:29:42

Re: FTDI device shows up in windows, not in linux

#15 2014-06-19 21:34:11

Re: FTDI device shows up in windows, not in linux

#16 2014-06-19 21:54:50

Re: FTDI device shows up in windows, not in linux

#17 2014-06-19 22:23:03

Re: FTDI device shows up in windows, not in linux

#18 2014-06-19 23:08:56

Re: FTDI device shows up in windows, not in linux

#19 2014-06-19 23:12:24

Re: FTDI device shows up in windows, not in linux

Board footer