After some editing of the CP210x.c file to get it to build on the Linux 3.5.0-28-generic Kernel I am getting an error during the device installation. I have an MEI Cashflow 7000 Coin Changer device attached to USB.
Within the CP210x.c file, I had to add the VID&PID for the new MEI device (VID 0x0BED, and PID=0x0400) to the list of supported devices. The good news is this change now detects the device when I plug it in and I have a /dev/ttyUSB0, but I get this output when I run dmesg:
[ 6230.860153] usb 2-2: new full-speed USB device number 7 using ohci_hcd
[ 6231.330652] usb 2-2: New USB device found, idVendor=0bed, idProduct=0400
[ 6231.330655] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6231.330657] usb 2-2: Product: CF7xxx-USB Coin Changer
[ 6231.330658] usb 2-2: Manufacturer: MEI
[ 6231.330660] usb 2-2: SerialNumber: 000000000001
[ 6231.332643] cp210x 2-2:1.0: cp210x converter detected
[ 6231.528185] usb 2-2: reset full-speed USB device number 7 using ohci_hcd
[ 6231.805404] usb 2-2: cp210x converter now attached to ttyUSB0
[ 6231.834662] cp210x ttyUSB0: cp210x_open - Unable to enable UART (error code -32)
[ 6231.841140] cp210x ttyUSB0: cp210x_open - Unable to enable UART (error code -32)
[66026.077996] cp210x ttyUSB0: cp210x_open - Unable to enable UART (error code -32)
The device driver fails in the cp210x_open() method. I added an extra bit of debugging to the CP210x.c file to show the error code -32. Any idea what this error means, and how can I fix it? I did follow one person's suggestion and increase the USB timeouts from 300ms to 3000ms but this had no effect.
Any help would be much appreciated, or if anyone is using this Cashflow 7000 device on Linux successfully I would really like to know how you got it working!
result = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
request, requestType, value,
port_priv->bInterfaceNumber, buf, size, 3000);
I am experiencing the same issue with a kernel 126.96.36.199. The manufacturer of a product that embeds a Silicon Labs chip sent me this forum thread.
The source code of that kernel version shows that the timeouts are set to 5s, so that is not the root of the issue, as was said on the very first post.
Any update on this subject ?