I’m trying to connect to an FTDI USB-Serial chip using their ftd2xx library. The installation information is here:
http://www.ftdichip.com/Support/Documents/AppNotes/AN_220_FTDI_Drivers_Installation_Guide_for_Linux.pdf
When I try to issue the rmmod terminal commands outlined in section 1.1 I get the following errors:
sudo rmmod ftdi_sio
rmmod: ERROR: Module ftdi_sio is builtin.
sudo rmmod usbserial
rmmod: ERROR: Module ftdi_sio is builtin.
How can I safely complete the rmmod calls? Is the ARM v8 1.4.6 driver the right choice for the TX1?
Thank you.
The driver is already built in kernel:
gunzip -c /proc/config.gz | grep FTDI_SIO
CONFIG_USB_SERIAL_FTDI_SIO=y
so you cannot use module commands for it.
Probably you don’t have more to do, it should be ready, unless you need to use the mentioned library, but for this I cannot say more.
I just tried the same ‘gunzip’ call you show, and I get the same result. However, I’m still unable to run any of the demo applications included in the FTDI bundle.
Is there a way to override the kernel-version of the driver?
It’s possible to build your own kernel with CONFIG_USB_SERIAL_FTDI_SIO=m to get it as a module and use the installation procedure, but I’m not sure it will improve. What are the failing commands and errors ? Not sure I can help, but someone else may help if there is some information to figure out.
That sounds like it may be out of my pay grade, but I’ll look into it. Thanks.
I’m unable to open a connection to the device. FT_Open() fails.
With a built in driver there won’t be any need to insmod or rmmod. I am curious what error you get from FT_Open()? I am thinking it is a permissions issue or an invalid argument. FTDI USB serial UART cables work on R28.1, so perhaps the cause is unrelated to the actual function.
I don’t think it’s an invalid argument, because I encounter the problem when I try to run FTDI’s example apps. And it’s not an error per se. I try to open a connection to the device and the operation fails. I don’t get an error message or anything.
How could I test the permissions issue? I tried running the demo app as sudo and there was no change.
I’d run it in gdb and set a break point at the call. See what shows up before and after. Verify the arguments.
You could then see what strace shows. This produces an enormous log, but you could grep for the key words (e.g., the function name or something related to the arguments you looked at when in gdb).
sudo -oTraceLog.txt ./whatever_program_it_is
Mostly what you’ll be interested in will be the last 100 lines or so. You might use whatever is
What should I be looking for in the strace output? And to be clear, this isn’t a USB-UART cable, it’s a USB-Serial chip on an FPGA board. I’m trying to talk to the FPGA, but can’t establish a connection with the FTDI chip. The same test programs run fine on Windows (with the same hardware), so I’m pretty confident that the problem is somewhere between my code and the USB cable.
A USB serial UART uses the same chip. The driver will be the same, though I suppose the means of the system learning of the driver might be different. How is the chip wired to the Jetson? Is it a custom carrier board? Is it going to a header pin on the regular dev board?
The chip is connected to the Jetson with a USB cable. The FPGA is on a custom carrier board, but I spoke with our EE and he assured me that the USB interface on the FPGA board is totally standard/unremarkable. We’re using an FT245R chip, which is a USB-FIFO chip rather than a USB-UART.
Does this chip show up under “lsusb”? If it does, then the ID can be used to limit a verbose query. For example, if lsusb shows an ID of 0955:7721, then you could do this:
sudo lsusb -d 0955:7721 -vvv
Verbose lsusb might provide clues as to what chip is actually being announced for drivers to claim.
I didn’t know how to do a verbose lsusb, thank you for showing me how to do that. Here is the output:
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 FT232 USB-Serial (UART) IC
bcdDevice 6.00
iManufacturer 1 FTDI
iProduct 2 Mercury FPGA
iSerial 3 241JL90G
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 90mA
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 Mercury FPGA
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)
This uses a standard FTDI serial UART, but also includes a custom interface:
.
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
Part of this should function with just the FTDI driver, but it won’t do much good unless something else talks to it with a custom driver. Does the FPGA vendor provide a driver specific to this FPGA?
I think that’s why you typically have to unload/remove the stock USB modules, which is the root of my whole problem. I think the built in Virtual Comm Port driver that Linux has is incompatible with these libraries.
I think that’s why you typically have to unload/remove the stock USB modules, which is the root of my whole problem. I think the built in Virtual Comm Port driver that Linux has is incompatible with these libraries.
That is possible, but seems overly invasive. The trouble is that I don’t know what this FPGA needs…I am thinking something like a udev rule might get around all of the issues by a simple rename. I have no idea though what a working FPGA of this sort actually wants. In theory the FTDI driver would not care who provides it, the only difference would be in the driver of the underlying FPGA that USB talks to through FTDI…and thus needs a means know to load the driver and attach it to this particular FTDI character stream. Perhaps the only reason the current FTDI driver isn’t doing what you want is because the FPGA driver wants a different device special file name (you could hard code this into a driver and break lots of things…or use udev to custom name the file when a given vendor and product ID are found).
You could recompile the kernel and make FTDI a module so it can be rmmod’d.
So, for reference, I just tested the FTDI sample code on a stock Ubuntu 14.04 machine and it worked fine. I unpacked the FTDI bundle, copied the libraries, built the samples, made the rmmod calls, and it the demo application worked on the first try.
I agree that it’s invasive, and I’m going to address that problem when I get to it. For the present it really seems like I just need to figure out how to get “rmmod ftdi_sio” and “rmmod usbserial” to work.
As long as those features are built and installed as modules, and so long as no hardware is currently using those modules, rmmod should work. If the module is not already installed, and if all prerequisite features are present (one module can depend on another module or integrated feature), then insmod should work (modprobe does some dependency checking, insmod does not…“depmod -a” will do some updates of the information which modprobe uses).
Is there a way to tell how the features are installed? When I try to call rmmod on the TX1 I get an error saying the module is “builtin (sic)”. Do you know what that means?
sudo rmmod ftdi_sio
rmmod: ERROR: Module ftdi_sio is builtin.
sudo rmmod usbserial
rmmod: ERROR: Module ftdi_sio is builtin.