Write before read & transfer required, Transfer broken with FT232H

[GoogleCodeExporter]

What steps will reproduce the problem?
1. run the attached file with an FT232H attached
2. notice how everything works
3. comment out the WRITE_BEFORE_READ macro to disable the write command

What is the expected output? What do you see instead?
I would expect the read command to work without a preceding write command. 
Instead, the kernel detaches the device with the following message in the dmesg 
output, while the cable is still plugged in and connected to the USB port:

[37074.838315] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now 
disconnected from ttyUSB0
[37074.838335] ftdi_sio 2-1.5:1.0: device disconnected

The read command only works if I write at least 1 byte before. 

What version of the product are you using? On what operating system?
libmpsse-1.2, ubuntu 11.04 amd64 compiled as 32bit

Please provide any additional information below.
I'm using the readymade MPSSE cable from FTDI, only connected to a scope. 

I am also seeing that replacing the Read/Wrie combination with a call to 
"Transfer" causes the kernel to detach the device in a similar fashion.

When plugging in the cable, the usb connection sequence logs as follows:

[37069.942923] usb 2-1.5: new high speed USB device number 16 using ehci_hcd
[37070.040969] ftdi_sio 2-1.5:1.0: FTDI USB Serial Device converter detected
[37070.041014] usb 2-1.5: Detected FT232H
[37070.041017] usb 2-1.5: Number of endpoints 2
[37070.041020] usb 2-1.5: Endpoint 1 MaxPacketSize 512
[37070.041024] usb 2-1.5: Endpoint 2 MaxPacketSize 512
[37070.041027] usb 2-1.5: Setting MaxPacketSize 512
[37070.041340] usb 2-1.5: FTDI USB Serial Device converter now attached to 
ttyUSB0

Original issue reported on code.google.com by zieg...@einklickdruck.de on 18 Jul 2012 at 6:42

Attachments:

• b.c

[GoogleCodeExporter]

I have an FT232H as well and your code runs fine for me, with or without the 
Write (Ubuntu 10.04, 32-bit). Since you say Read doesn't work without a Write, 
please define "not working", and describe how do you know it's not working. 

I've attached a modified version of your code that completely comments out the 
Write and adds a printf to display the first byte of data read for each 
iteration of your loop. Running this on my machine results in the following 
output (I didn't have anything connected to the FT232H):

Read OK [ 0xFF ]
Read OK [ 0xFF ]
Read OK [ 0xFF ]
Read OK [ 0xFF ]
Read OK [ 0xFF ]
Read OK [ 0xFF ]
Read OK [ 0xFF ]
Read OK [ 0xFF ]
Read OK [ 0xFF ]
Read OK [ 0xFF ]
Read OK [ 0xFF ]
Read OK [ 0xFF ]
Read OK [ 0xFF ]
...

I further confirmed that the clock line was active during these reads by 
attaching a 'scope to it.

As for the detaching of the device, I expect this is normal behavior for your 
machine. The Linux 3.0 kernel (IIRC, 11.04 uses one of the 3.x kernels), added 
support for the FT232H in the ftdi_sio driver. In order for libftdi (which 
libmpsse uses) to take control of the device, it must detach the ftdi_sio 
driver (the device can't be a serial port and an SPI interface at the same 
time). So as soon as you call MPSSE, you should see it detach; it should have 
nothing to do with Read/Write/Transfer.

Original comment by heffne...@gmail.com on 19 Jul 2012 at 3:23

Attachments:

• b.c

[GoogleCodeExporter]

Any word on this?

Original comment by heffne...@gmail.com on 25 Jul 2012 at 12:13

[GoogleCodeExporter]

thanks for the reply and apologies for the delay. I just started to work on the 
issue again. 

In short, The issue is not reproducible. Before reporting it, I tried to reboot 
the machine and restarting the slave, also verified the wiring multiple times. 
The effect that I was seeing, is that the code would hang and output nothing, 
the last that I'd see would be the unregister message in the kernellog. To get 
it back to run again I would have to replug the usb cable.

I'm seeing another issue but I'll open a different ticket for that. thanks 
again.

Original comment by zieg...@einklickdruck.de on 25 Jul 2012 at 3:51

[GoogleCodeExporter]

Was your b.c code hanging with no output, or was my modified version hanging 
with no output? You wouldn't get any output from your code, as it wasn't 
printing anything to screen. Your code reads quite a lot of data (734MB), so if 
you weren't printing anything to screen it would appear to 'hang' for some time 
even if it was functioning properly.

Original comment by heffne...@gmail.com on 25 Jul 2012 at 8:44

[GoogleCodeExporter]

Original comment by heffne...@gmail.com on 20 Aug 2012 at 11:53

• Changed state: Invalid