FTDI FT232H Non responsive

[sbar5781]

Hi There!
This forum was so helpful with my first small problem that I thought it cannot hurt to ask about my latest currrent issue.

I have a custom board using a FTDI FT232H USB Controller as part of a PCB design. A schematic of the controller supporting circuitry is shown below, setup from the datasheet for external source power. I want to use it in asynchronous FIFO mode.

From probing measurement I can confirm the input voltages are all 3.3V (VPHY, PLL, VCCIO, VREGIN, VCCD) and the onboard voltage regulators are operational, outputting 1.8V for VCCA, VCCCORE. The XO is operating at 12MHZ, XO+ up to 3V AC and XO- to 3.3V on oscilloscope (same signal as on a different correctly operating board).

The problem is while all this indicates the controller is operating as expected, it does not respond when connected to any PC. FTPROG does not detect a board for programming (the EEPROM is not programmed), Computer itself not not acknowledge anything is connected (no change in device manager). V++ of the usb connection is measured as 5V power, and using the same cable on a different board (with a FT2232 USB controller) is detected, so the issue must be board related.

I have tested two identical boards so it is less likely the issue is related to a specific bad chip, unless somehow having a 8MHz XO would cause damage (the incorrect XO was initially installed, but since replaced).

I looked through the troubleshooting documentation and nothing seemed relevant;most of their FAQ refers to the 232BM design and talks about extra resistors that were not mentioned in the 232H datasheet. Maybe this is an important oversight?

Could R4 R5 pull-up resistors be an issue, or perhaps the ESD protection? Need extra caps on the data lines? Could there be something non hardware related that I am missing that would prevent communication?

Any suggestions would be greatly appreciated. I am at wits end.

[Macbeth]

FTDI you say? 

   

Most likely it's deliberately bricked or newer Windows drivers are ignoring it.

FTDIs shenanigans are world famous by now surely?

 

[Monkeh]

FTDI you say? 

   

Most likely it's deliberately bricked or newer Windows drivers are ignoring it.

FTDIs shenanigans are world famous by now surely?

 

It's an FT232H....



And now, after that phobic interlude: Is it my imagination, or is the ground pin of your USB connector not actually connected?

[sbar5781]

Thanks for the swift replies.

I'll admit and FTDI infamous issues are news to me, however I would presume that parts purchased off digikey within the last 3 months would not have any potential legitimacy or locking issues?

As for the schematic check, greatly appreciated! But yes the GND pin of the USB controller is connected, can confirm this on the layout. Looking at the screenshot i can see the tiny gap, must be a visual glitch.

Edit: looking again there are plenty of tiny visual gaps and even some offsets on the schematic image. Assume all the connections are solid as intended (though i will personally double check these).

[Monkeh]

There should be no concerns with the FT232H, it's never to my knowledge been 'cloned'.

Do not try and apply any FT232B/R advice to the H, their USB interfaces are totally unrelated. No series resistance should be required on the data lines, and absolutely not any extra capacitance.

Verify it's nothing to do with the EEPROM by removing it and its pullup resistors.

[sbar5781]

Ok thanks, I Will try this and update how it goes. Will take off the two pull-up resistors that are indicated as optional(?)/N.C. on the FT232H layout first.


Before removing these parts though, is there any rational behind why the EEPROM could be blocking any FTDI communcation to be possible over USB? It is an un-programmed EEPROM so I know it has not been configured yet for correct operation. Also it is worth commenting that the EECLK signal is currently 0V, as is EECS (EEDATA is 3.3V). I'll admit i found these values curious initially. That being said, Id've thought that any EEPROM issues should not be manifesting as complete Chip silence.

[Monkeh]

I honestly don't know how the chip works internally, but it's possible it's, well, stuck. When you've got no other ideas.. eliminate anything you can.

It could be layout issues, but you do have to get things fairly grossly wrong before they stop working entirely.

[hans]

Before removing these parts though, is there any rational behind why the EEPROM could be blocking any FTDI communcation to be possible over USB? It is an un-programmed EEPROM so I know it has not been configured yet for correct operation. Also it is worth commenting that the EECLK signal is currently 0V, as is EECS (EEDATA is 3.3V). I'll admit i found these values curious initially. That being said, Id've thought that any EEPROM issues should not be manifesting as complete Chip silence.

From my knowledge no. Even if the chip would try to use a totally irrelevant USB VID/PID, it should come up at USB devices.

I would check:
- All solder joints
- USB cabling and pinouts
- Check if USB D+ is pulled to 3.3V; if not try to do it manually via 1.5k

Note that this is a USB2.0 High Speed chip, which USB connections are lot more dicky than USB2.0 Full Speed like the popular FT232RL.

I do remember seeing series resistors on the USB lines as suggested for the FT4232H, which is also a High Speed chip.

[wraper]

FTDI you say? 

   

Most likely it's deliberately bricked or newer Windows drivers are ignoring it.

FTDIs shenanigans are world famous by now surely?

 

But more ridiculous are those outcries every time FTDI is mentioned  .

[sd]

You could try the following:
-remove ESD1 and ESD2
-remove anything connected to EECS, EECLK, EEDATA(EEPROM, pull-ups)
-check the RESET line
-use the datasheet(ABMM2-12.000MHZ-E2-T) recommended values for C5,C6.

Maybe some pictures of the assembled board would help.

[Monkeh]

I'll admit and FTDI infamous issues are news to me, however I would presume that parts purchased off digikey within the last 3 months would not have any potential legitimacy or locking issues?

Someone on this forum bought a reel of FT232RL from Farnell and these chips turn out to be fake.

FT232R != FT232H.

This has nothing to do with this thread.

[wraper]

Someone on this forum bought a reel of FT232RL from Farnell and these chips turn out to be fake.

Turned out that nothing turned out because that someone didn't even bother to download fresh drivers and install them or do any checks at all. Was like - it is outputting zeroes with prehistoric drivers installed, must be fake, 100%  . Why bother to spend 10-20 minutes to make any additional checks. Not even a picture of the ICs.

FT232R != FT232H.

This has nothing to do with this thread.

exactly

[nctnico]

Use an oscilloscope to check whether the crystal oscillator is running by probing the crystal pins. If the oscillator is running there should be a sine wave at least a couple of 100mV. If not: make the crystal loading capacitors smaller. 27pf seems on the high side.
If the oscillator works then remove the ESD diodes. Maybe they are mounted in reverse or load the USB lines too much.

And how about the TEST pin? Must it be connected to ground?

@Wraper: where there is smoke there is fire so it doesn't surprise me FTDI devices in general are now suspicious to many people whether it is justified or not.

[wraper]

@Wraper: where there is smoke there is fire so it doesn't surprise me FTDI devices in general are now suspicious to many people whether it is justified or not.

But claiming that major distributor supplied counterfeit parts needs some good evidence. If those were bought from ebay, yeah, sure, go on, call them counterfeit because most likely they are. Farnell is authorized distributor http://www.ftdichip.com/SalesNetwork/GlobalSuppliers.htm so claiming and believing they were fake without any good evidence is foolish as minimum, and claiming this without any (widely available) checks don't stand the ground at all. That easily might be as well bug in the old driver because of which it don't like new serial numbers, corrupted driver installation or something like this.

[timofonic]

I would NEVER buy FTDI chips.

That company deserves go bankrupt and their big bosses being slowly killed in a very tortured way.

[Monkeh]

I would NEVER buy FTDI chips.

That company deserves go bankrupt and their big bosses being slowly killed in a very tortured way.

Please take it to the giant 'shit on FTDI' thread instead of polluting every unrelated thread you see. It's really not in any way useful to the OP.

[timofonic]

I would NEVER buy FTDI chips.

That company deserves go bankrupt and their big bosses being slowly killed in a very tortured way.

Please take it to the giant 'shit on FTDI' thread instead of polluting every unrelated thread you see. It's really not in any way useful to the OP.

I disagree.

[wraper]

Please take it to the giant 'shit on FTDI' thread instead of polluting every unrelated thread you see. It's really not in any way useful to the OP.

I disagree.

Disagree to respect topic starter (who needs his problem fixed), and that tread should not be derailed with BS not related to this particular chip?

[sbar5781]

Thanks again for all the replies, even the FTDI rant ones have some use (in small moderation ). A lot of the advice here since my last post was things i had already checked but still very useful steps (checking TEST, the XO etc)

To give a current update it appeared the problem was related to the ESD Diodes which were not behaving correctly, instead causing a short from the D+ and D- lines to ground. Once they were removed the chip began communicating with the computer and was able to no fuss program the EEPROM through FTPROG. Hooray!

I am not completely out of the woodwork, with debugging the entire system so I would ask; should I anticipate any serious problems if I continue without replacing the ESD diodes?
Of course I understand they provide line protection, and possibly data stability to an apparently sensitive FTDI controller but how critical are they really?

For reference my current debugging status is not being able to loop a data stream through the CPU->FT232H->FPGA Board (xcm110z-lx150) and back again using testing software previously built by my colleague which worked for a similar process on the Saturn 6 Development board (which includes a FT2232H). Plenty of points of failure at this point (checking new UCF mapping, PCB routing, FTDI config mode, etc) but being able to eliminate input into the FTDI controller as an issue would be ideal.

May have to (learn to) use a signal analyser if the fault cannot be pin pointed.

Thanks again.

[nctnico]

I strongly advice to draw ESD diodes as diodes so you are not inclined to reverse them. I'm always using Wurth 824011 as a TVS diode for USB lines (it has been designed for use on high speed digital line).

[wraper]

I am not completely out of the woodwork, with debugging the entire system so I would ask; should I anticipate any serious problems if I continue without replacing the ESD diodes?
Of course I understand they provide line protection, and possibly data stability to an apparently sensitive FTDI controller but how critical are they really?

I had a thought that might be an issue with ESD protection but then checked part number on the schematic and they are specially designed for high speed interfaces like USB 2.0 High Speed. Guess you used some different ESD protection devices. You cannot use whatever you want, those need to be very low capacitance, preferably below 1 pF.