astrapotro wrote:Hi,
I'm fighting with a FTDI-serial cable in raspberry for several months and still having troubles with it
paolom65 : Last firmware from next branch, 4C SD card, your kernel parameters in cmdline.txt, but still the serialport hangs !!
What's the solution for that? I've to terminate with this problem cause my project is stopped thanks to this issue.
Today i'll try with arch linux, and otherwise i'll migrate to Beaglebone Black.
I need help with this, please.

Hi
Which chip is embedded from in you cable? What is the name of the cable? Some work better than others. If you don't know you can try running this command:
dmesg | grep -iE "ftdi|ft23"
/Ronny Nilsson

astrapotro wrote:Hi,
I'm fighting with a FTDI-serial cable in raspberry for several months and still having troubles with it
paolom65 : Last firmware from next branch, 4C SD card, your kernel parameters in cmdline.txt, but still the serialport hangs !!
What's the solution for that? I've to terminate with this problem cause my project is stopped thanks to this issue.
Today i'll try with arch linux, and otherwise i'll migrate to Beaglebone Black.
I need help with this, please.

Hi
Which chip is embedded from in you cable? What is the name of the cable? Some work better than others. If you don't know you can try running this command:
dmesg | grep -iE "ftdi|ft23"
/Ronny Nilsson

Hi , the chip is the FT232RL one , and the exact name of the cable is USB-RS485-WE-1800-BT
Thanks

astrapotro wrote:
Hi , the chip is the FT232RL one , and the exact name of the cable is USB-RS485-WE-1800-BT
Thanks

Hi
My systems use the same chip and is working flawlessy... (with speed 115,200 haven't tried any faster). Before you migrate to BeagleBone I could send you an SD-card image to try out if you like, for ruling things out?
/Ronny

astrapotro wrote:
Hi , the chip is the FT232RL one , and the exact name of the cable is USB-RS485-WE-1800-BT
Thanks

Hi
My systems use the same chip and is working flawlessy... (with speed 115,200 haven't tried any faster). Before you migrate to BeagleBone I could send you an SD-card image to try out if you like, for ruling things out?
/Ronny

You're lucky i think
Three questions: Do you keep the port opened or for each query to the port do you open and close?
How many often do you query the ftdi port? Which language do yo use to acces the ftdi ??

Many thanks for the offering of the image. I'll ask you if my solutions don't work.

astrapotro wrote:
Three questions: Do you keep the port opened or for each query to the port do you open and close?
How many often do you query the ftdi port? Which language do yo use to acces the ftdi ??

Weel this weekend i've tested my java program in the beagleboneblack with the same fuc* results that i've gotten with the raspi.
My installation: The raspi attached to a 7 port usb-hub (2A) , with a 3G modem and two or more ftdi-serial cables attached to some boards via the usb-hub. The problem is still there and i don know what i'm doing wrong. Today i'll try to open and close the port each time that i've to query or send a command to the ftdi's boards.
This is a nightmare

We are using a 4-port "USB2-H-1004" device from easysync (which uses the ftdi FT4232H chip) with the Raspbian virtual com driver, at 115.2k baud, but only open once and close once over days or weeks of the program running.

However, we have not been successful in opening the port at higher speeds, like 230.4k. Any suggestions, please?

I've been struggling with this issue for months now after deploying a handful of RPis (v2) to monitor APC UPSes. I am currently using the SIIG Serial to USB adapter which has a FTDI FT232BM chip. I noticed, using FTDI's programming software, that the chip has attributes to use USB 1.1 and USB 2.0. Of course the RPi will opt for the faster speed by default.

I can confirm that adding dwc_otg.speed=1 to the cmdline.txt does indeed allow the chip to work flawlessly. However, in my case, once I add that attribute to the cmdline.txt it also doesn't allow me to plug in a usb and keyboard since these are high-speed USB devices.

I haven't tried using a USB 1.1 hub (I don't have one handy), but I assume that this should work since it would force the FT232BM chip to work at the 1.1 speed rather than 2.0.

This was driving me crazy for a long time and what I have found has given me a little piece of mind, but it still bothers the h$#% out of me. My last idea is to be able to program the chip to only use USB 1.1, but I am just barely reading up engineering manuals on how to do that and will post if it's even remotely possible to do this...

iggynach wrote:I've been struggling with this issue for months now after deploying a handful of RPis (v2) to monitor APC UPSes. I am currently using the SIIG Serial to USB adapter which has a FTDI FT232BM chip.

You shouldn't need the dwc_otg.speed hack any more. It was an issue that went away in 2013 or so with the Raspberry Pi kernel.

Notice the iProduct and iSerial entries, where yours reported (error)? The two known-counterfeit ones that I have (bought from dx.com and ebay very cheaply) give the same error as yours.

When you plug your serial adapter in, does the dmesg output include SerialNumber: DDDDDDDD, with a unique identifier? Counterfeit ones return zero. Another clue might be if you bought FT232BM adapters recently. FTDI discontinued the BM variant some time ago. Yet another clue is how much you paid for the adapter: real FTDI chips are quite expensive - around US $4 each in quantity - so if you paid less than say US $15 for the cable, it's probably fake. It might not even be a real SIIG cable you have; counterfeit electronics are a big problem.

‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.

Interesting, I would never have thought counterfeit chips to be the problem. I must note though that I get different information when I run lsusb -v and sudo lsusb -v. Also, the errors are sporadic and usually occur when serial communication is attempted. When I run sudo lsusb -v before the cable gets all screwy, I get this output:

I also would like to note that I downloaded the FTDI programming utility for FTDI chips http://www.ftdichip.com/Support/Utilities.htm#FT_PROG (for Windows) and the chip is read perfectly. Can this be done with counterfeits as well? I am able to flash it and change attributes using the utility very easily...

Notice the iProduct and iSerial entries, where yours reported (error)? The two known-counterfeit ones that I have (bought from dx.com and ebay very cheaply) give the same error as yours.

When you plug your serial adapter in, does the dmesg output include SerialNumber: DDDDDDDD, with a unique identifier? Counterfeit ones return zero. Another clue might be if you bought FT232BM adapters recently. FTDI discontinued the BM variant some time ago. Yet another clue is how much you paid for the adapter: real FTDI chips are quite expensive - around US $4 each in quantity - so if you paid less than say US $15 for the cable, it's probably fake. It might not even be a real SIIG cable you have; counterfeit electronics are a big problem.

For the dmesg output, again before the cable gets all weird, I get this output:

I mean if these cables are counterfeit, they are pretty darn good counterfeits. The cables have zero problems on Windows (haven't tried them on a Mac). It's only when I try to use them in Linux that they give me problems... Thank you for the info, though. I'll need to continue digging to confirm that indeed these are counterfeit...

PS: I registered the cables with SIIG and the serial numbers were valid... Again, it amazes me if they are still counterfeit after all of this

scruss wrote:Okay, probably not counterfeit, then. Your output just matched what I get out of counterfeit ones.

This has been a real problem for FTDI: the counterfeit chips are very hard to detect, and are actually pretty okay usb→serial interfaces.

Hey scruss,

I've tried these cables on a multitude of RPi distros (Kali Linux, ArchLinux, FedBerry, etc...) and the same result occurs! I'm pretty frustrated now. The problem seems to stem from the the otg device used in the RPi because in depth research shows many people having issues with other USB devices not just USB-Serial adapters... Using the cables on a Centos 6.8 i386 (Kernel 2.6) seems to work flawlessly...

Would you be able to provide me a list USB-Serial cables that have functioned perfectly for you? (i.e. cables not using FTDI FT232BM, or any other discontinued device for that matter...) I would really appreciate it...

I had the same problem and spent many hours reading forum messages and trying different approaches without any success.
I had cascaded hubs and what finally helped: rearranging the same hubs physically using another cable.
So you might want to check cables, shielding and power supply, avoid ground loops etc.