FT232RL gets disconnected after sometime - Page 1
Forum section: electronics / general

author: msngupta
author_rank: Contributor
timestamp: September 14, 2016, 07:23:04 pm
content: Hi,I am using the famous FT232RL IC for USB communication between the computer and a FPGA. I made a custom circuit (schematic attached), following the circuit provided on the datasheet. I have bought these ICs from 2 reliable sources (element14 and another vendor). I then assembled the circuit and connected the board to the computer (Windows 7), everything works fine for some time (I am able to talk to the FPGA via FT232RL) but after some time (~5 min) the board gets disconnected and the computer doesn't detect the FTDI chip. This persists for a long time (a day or so) untill the computer detects it back. The IC doesn't seam to be heated up. I changed the FT232 IC, all the components (resistors, capacitors, the cable) but the behaviour is still the same. I used the same circuit in 2 diff. boards with a different layout, but both of them show the same behaviour.Then I bought a FT232 board fromhttp://www.ebay.in/itm/FTDI-FT232RL-FT232-USB-TO-TTL-5V-3-3V-SERIAL-ADAPTOR-FOR-ARDUINO-BE0027-/252048060798?ssPageName=ADME:X:EAC:IN:3160This board almost has the same circuit but seams to have a fake IC (I am unable to change its name using FTPROG), but this works fine without getting disconnected from the computer. I am able to make communication between the computer and the FPGA.So, I am unable to understand if I am doing anything fundamentally wrongthat my simple circuit is not working. Can anyone please help me? Did anyone face a similar problem before?Thanks for your patience,Sainath.

author: tatus1969
author_rank: Super Contributor
timestamp: September 14, 2016, 08:50:39 pm
content: dont see anything obvious...Where is 3V3OUT going?Is L1 a ferrite bead? Dont use an inductor there. If that is the case, test shorting it out.How is the USB signal layout,can you post it?

author: msngupta
author_rank: Contributor
timestamp: September 14, 2016, 09:49:50 pm
content: 3V3OUT is connected to the 3V3OUT of FT232 IC (not explicitly shown in the schematic)Yes, I used a ferrite bead, I also tested shorting it using a 0ohm resistor but the behaviour still persists.What do u mean by USB signal layout? you mean PCB layout ?

author: tatus1969
author_rank: Super Contributor
timestamp: September 15, 2016, 12:20:43 am
content: Quote from: msngupta on September 14, 2016, 09:49:50 pmdont do that, you are destroying the chip! you have it connected to the 5V from USB. Remove R3.(yes, PCB layout)

author: Jeff_Birt
author_rank: Regular Contributor
timestamp: September 15, 2016, 12:40:18 am
content: Also check and see if your USB ports on PC are set to automatically power down.

author: Monkeh
author_rank: Super Contributor
timestamp: September 15, 2016, 03:56:53 pm
content: Quote from: tatus1969 on September 15, 2016, 12:20:43 amWell obviously you don't populate both...

author: tatus1969
author_rank: Super Contributor
timestamp: September 15, 2016, 08:27:59 pm
content: Quote from: Monkeh on September 15, 2016, 03:56:53 pmsure, just responding to what is shown in the schematic

author: msngupta
author_rank: Contributor
timestamp: September 19, 2016, 04:12:50 am
content: Quote from: tatus1969 on September 15, 2016, 08:27:59 pmYes, I did not connect R4, I used R3 and R4 as jumpers to select between 3V3 and 5V. Please find the screenshots of the layout attached.

author: Jeroen3
author_rank: Super Contributor
timestamp: September 19, 2016, 07:18:58 am
content: You could be overloading Vccio with the LED's.You could be coupling noise into the floating reset pin. (Pro tip:never have resets floating)You might want to reprogram the CBUS inputs to not have sleep and enable.Vbus could be noisy / not high enough for the internal oscillator.

author: tatus1969
author_rank: Super Contributor
timestamp: September 19, 2016, 07:50:11 am
content: Quote from: Jeroen3 on September 19, 2016, 07:18:58 amIt is only 5mA per LED, the output can deliver 50. But: when your problem happens, what is connected to TXD? Could that be drawing too much current?Quote from: Jeroen3 on September 19, 2016, 07:18:58 amThat is actually a very good hint. Did you use FT_PROG to configure these pins into a safe state (make all of them outputs)? Default for CBUS3 is PRWEN#. They write in the datasheet "If using PWREN# (available using the CBUS) the pin should be pulled to VCCIO using a 10k? resistor."But I cannot see how this could cause this effect, all of the CBUS default options are outputs if I read it correctly. But worth trying anyway.Another possibility: have you designed the USB signal lines for the correct common mode and differential wave impedances? If not, you are likely to cause communication problems on the bus. Remember USB2 runs at 480MHz, proper transmission line design is key here. If you haven't done that, you may try using a very short USB cable for a test, and/or snap on some ferrites on both ends. If that improves stability, then you'd probably have to redesign your board. Onboard common mode chokes also help to some degree.

author: bktemp
author_rank: Super Contributor
timestamp: September 19, 2016, 09:23:33 am
content: Quote from: tatus1969 on September 19, 2016, 07:50:11 amPWREN is an output, so if unused it can be left unconnected. The pullup is probably necessary to set this pin to a known state until the FT232 is powered up an has initialized the IO states according to the configuration in its EEPROM. All input pins also should have internal pullups, that's why they can be left unconnected when unused.QuoteFT232RL only uses Full-Speed. At 12MBit/s the signal lines are not critical unless you add some metres of wrong cable or have some other emc problems (I can crash almost any USB connection by switching of my soldering iron).Did you try a different USB port on your computer?

author: andersm
author_rank: Super Contributor
timestamp: September 19, 2016, 01:33:23 pm
content: Quote from: Jeroen3 on September 19, 2016, 07:18:58 amFTDI's own datasheet say the pin can be left floating if not used.

author: Jeroen3
author_rank: Super Contributor
timestamp: September 19, 2016, 02:23:35 pm
content: CanandShouldare two different things.

author: Jeff_Birt
author_rank: Regular Contributor
timestamp: September 19, 2016, 02:37:22 pm
content: Quote from: bktemp on September 19, 2016, 09:23:33 amMore importantly have you checked the Power Options of the PCs root hubs? I mentioned this before and it got ignored. Windows, by default, will power down the USB bus controllers to save power if it thinks they are not being 'used', i.e. Selective Suspend. I don't recall off the top of my head what the criteria used to decide to selectively suspend a USB device but it does/can/will happen. Take a look at page 5 here:http://www.soigeneris.com/Document/Warp9/Installing_and_Configuring_the_SmoothStepper.pdf(I wrote the PDF and don't want to copy all the pics etc. over here.) I also seem to recall that on the FTDI devices there is a pin to setting to twiddle to send the correct data to the PC to keep the port from being suspended.

author: tatus1969
author_rank: Super Contributor
timestamp: September 19, 2016, 03:00:37 pm
content: Quote from: Jeff_Birt on September 19, 2016, 02:37:22 pmAre you sure about this? AFAIK this is only relevant for STR suspend. MS writes this about it:A USB device driver can send a message to windows telling it to idle the device. This puts the device in a low-power state (the suspend state). When a USB device is suspended, windows does not wait for it to respond before entering a sleep or hibernate mode. If you disable this feature, the system will simply return a failure to the driver when the driver attempts to enter suspend state. If the driver complies with Microsoft guidelines, it will simply retry the idle request at every expiration of its idle timer.

author: Jeff_Birt
author_rank: Regular Contributor
timestamp: September 19, 2016, 03:14:49 pm
content: Yes, I am quite positive. The reason I wrote the instructions to turn off selective suspend is because it causes problem with the USB SmoothStepper. I have also heard about it with other USB devices.

author: msngupta
author_rank: Contributor
timestamp: September 19, 2016, 04:09:47 pm
content: Quote from: tatus1969 on September 19, 2016, 07:50:11 amI removed the LEDs, still the problem persists.I also thought that my other part of the board might be drawing a lot of current from the TXD, so I disconnected both TX and RX. But no luckQuote from: Jeroen3 on September 19, 2016, 07:18:58 amI will try connecting the reset* pin to the VCC.Quote from: Jeff_Birt on September 19, 2016, 02:37:22 pmI tried a different port and even a different computer.If this USB shutdown might be the reason, then the computer should detect the board once I disconnect and reconnect the USB cable.The problem is that, once it gets disconnected no USB port recognises it. The computer says its an unrecognised USB device, this persists for a long time. Yeah, it's weird

author: PA0PBZ
author_rank: Super Contributor
timestamp: September 19, 2016, 06:29:21 pm
content: Quote from: msngupta on September 19, 2016, 04:09:47 pmDid you check the VID/PID first when working and then after you get the 'unrecognized' message?

author: Jeff_Birt
author_rank: Regular Contributor
timestamp: September 19, 2016, 06:58:15 pm
content: QuoteHaving come up as unrecognized is a big clue. That means it is not related to selective suspend but is most likely related to the FTDI chip getting into an unknown state. I did not go back all the way in this thread to find out - do you have the reset pin connected? Can you reset the FTDI chip and see if it is then recognized?It is relatively easy to stop an FTDI chip in its tracks with common mode noise (or any other USB interface for that matter); USB communications are allergic to common mode noise. I have a 24" florescent light above my workbench in the garage/shop. If I turn it on/off it will generate enough noise to kill every USB device on my shop PC. I had the scope on the USB 5V line and watched it as I turned the light on and the +5V drop below ground by a few tens of millivolts for a brief period! I put a line filter in a 4" square electrical box with a dual outlet on it, with the PC plugged in to the filter box things are OK when the light is turned on.When all of the USB isolators came on the market a few years ago I tested several and only found a couple that were worth a hoot. B&B Electronics and Phidgets. Both of them had common mode filters before the isolator chip which made all of the difference in the world.

author: tatus1969
author_rank: Super Contributor
timestamp: September 19, 2016, 07:11:29 pm
content: bktemp is right we only have a full speed device here, but I still would be interested in what happens if you try a different, short, high quality USB cable. If the problem occurs less frequently that would be another clue. Be careful with ceapish Chinese stuff, they are shameless in cost cutting. I already had on my desk- aluminium litz with copper plating- steel litz ""- AWG32 instead of AWG28- way off wave impedance- untwisted data pair- "eco" shield

author: John_ITIC
author_rank: Frequent Contributor
timestamp: September 19, 2016, 08:31:09 pm
content: A USB Protocol Analyzer will tell you what goes wrong on the link. Then you know which side (computer or device) is to blame. You will also know exactly what goes wrong (which would give you clues why it happens).

author: tatus1969
author_rank: Super Contributor
timestamp: September 20, 2016, 05:25:28 am
content: Quote from: John_ITIC on September 19, 2016, 08:31:09 pmI can recommend Wireshark for this. (there is a USB plugin available).

author: perieanuo
author_rank: Frequent Contributor
timestamp: September 20, 2016, 05:41:42 pm
content: Interference from neon light and other similar it's not the explanation.ok you got interference,romove the adapter,cut the lamp and reinsert,you'll find your answer.put a scope to see the signals and you'll see if the chip is alive.verify of course first the quartz operation,that's the first thing to do.please give us the feedback.best regards,ovidiuEnvoyé de mon iPad en utilisant Tapatalk

author: John_ITIC
author_rank: Frequent Contributor
timestamp: September 20, 2016, 09:40:13 pm
content: Quote from: tatus1969 on September 20, 2016, 05:25:28 amWireshark only snoops on the call interface to the PCs Host controller driver? This is not USB protocol analysis. Real USB protocol analysis shows the actual protocol exchange on the physical bus.

author: tatus1969
author_rank: Super Contributor
timestamp: September 21, 2016, 06:33:21 am
content: Quote from: John_ITIC on September 20, 2016, 09:40:13 pmYes, but that was enough recectly to debug a USB problem. Which actually turned out to be a hardware problem, data interruption due to excessive inrush current of an embedded hub.