Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length.

[FTDIUser81]

Hello, we've been having an ongoing issue with the FT601 wherein the chip randomly does not enumerate on power up. This occurs about every 10 or so power up cycles. The FT601 is connected to a CYUSB3314 hub on the same PCB as itself. The two parts are less than 2 inches apart. I've attached schematics for the interface between the two parts. There was a prior version of this board using a USB5744 hub instead of the CYUSB3314 hub but the FT601 also failed to enumerate reliably in that configuration also. There are two or three other devices on the USB hub aside from the FT601 but those always enumerate at power up without issue. I've reviewed power rail start up timing in relation to the FT601s reset signal and can see that the FT601 gets about 100 ms worth of reset after 3.3V / 2.5V / 1.0V stabilize. When I check the FT601s clock output I can see it is starting up but then shutting down. The same is true when viewing the crystal's pins. The clock runs for about 120 ms and then shuts down for 100 ms and then repeats. Previously asserting the FT601s reset alone was enough to get it to enumerate after a failed power up but it seems that solution isn't working on the present version of the PCB. As far as I can tell I've followed every recommendation in FTDI's PCB guidelines document as well as the data sheet for the part. Hopefully someone else has been through this already with the FT601 and can help out?
Thanks very much!
Rich

[FTDI Community]

Hi Rich,

i would recommend that you test with one of our FT601 modules. UMFT601X-B, UMFT601A-B. If there are no start up issues using the modules you can use them as a reference.

Best Regards,

FTDI Community

[FTDIUser81]

Hello,
   I have done so with the UMFT601 module and a development module for the CYUSB3314 hub. I did not see enumeration issues. One very big difference between my setup and the development modules is that the CYUSB module controls power to the UMFT601 module. My application is self powered hence the development module arrangement is not applicable. In addition, because the FT601 and USB hub are on the same PCB there is no USB cable between the devices.... they are connected through 90 ohm, impedance-controlled, length-matched tracking. There are 0.1uF caps on the TX pins at the USB hub chip and 0.1uF caps on the TX pins at the FT601. I've been assured by the PCB vendor that the board meets the impedance requirements. This very much seems to be an issue with the FT601 power up enumeration behaviour. For my board I'm now working on a solution involving monitoring the CYUSB3314 SS_LED pin for the port the FT601 is residing on. At power up the processor reads this pin and if it sees the FT601's port is not in superspeed mode it resets the FT601 and repeats. Often the FT601 comes right up on power up but occasionally it takes multiple resets to get it to enumerate. Once it is enumerated USB communication appears stable. Given the frustration we've experienced with this issue I would strongly caution against others using this part in this configuration (self-powered, with a USB hub chip onboard).

[FTDI Community]

Hi Rich,

Take a look at the self-powered section of the FT601 Datasheet, section 6.2. You need VBUS to connect to the USB host 5V supply for correct enumeration. The USB hub you are using may also provide signals for that purpose.

Best Regards

FTDI Community

[FTDIUser81]

Hi,
   Thanks. Could you let me know what the input voltage compatibility is for VBUS as well as the high/low switching thresholds? I can't seem to find that information in the data sheet. I am currently using the power enable signal from the hub IC to switch the FT601's VBUS signal on and off. The FT601 does enumerate using this scheme just not reliably. In prior versions of our board we have had VBUS connected to the USB connector on the product as well as to the power enable on the USB5744 (previous USB hub). In all cases the FT601 exhibited the same behaviour.
   Regarding the errata:  Erratum 0006 & 0007, concerning Clock On In Suspend. The behaviour listed for this errata appears to match what we're seeing. We reprogram the FT601 with our device information. We do this by using the EEPROM hex dump from the FTDI programming utility. Can you tell me which bit(s) in the hex dump enable/disable the previously removed Clock On In Suspend option as well as the bit for Disable Chip Power Down? We would like to confirm that we are not accidently enabling these options when we program the FT601.

Again thanks,
Rich

[FTDI Community]

Hi Rich,

The recommended way of connecting VBUS depends on your application:

 (a)  For self-power application, refer to the UMFT600x/UMFT601x datasheet;

(b)  For bus-power application, VBUS is the 5V power input for all circuits. If a 5V to 3.3V regulator is used, connect the 3.3V to the FT601 VBUS pin.

 Note, the voltage divider in the Development Module between the USB power and VBUS pin is used to lower the voltage level from 5V to 3.3V so that FT601 can take it as a 3.3V logic input for VBUS sensing purpose.

 If you haven’t already, please refer to AN_412 FT600/FT601 Bridge Chips Integration.. This application note is for designers who want to integrate the FT60x into new designs.

regarding the errata, we don't have access to the EEPROM contents/structure. Customers should only use the utility. This may help you:

common problem customers encounter is the clock not working. The reason for this is that the device will enter suspend mode 10 seconds after enumeration if there is no device activity. Entering suspend mode also turns off the clock.
 
This USB selective suspend can be turned off, or the idle interval at which suspend should occur can be controlled by the FT_SetSuspendTimeout API (detailed info can be found in the D3XX programmers guide), although basic info on the Set and Get APIs are detailed below:-
 
FT_SetSuspendTimeout
-          Takes handle and a timeout value in seconds as input.
-          When the timeout is set to zero, driver will disable the suspend feature.
 
FT_GetSuspendTimeout
-          Take handle and pointer to ULONG as inputs.
 
Note: The value for the idle timeout configured using FT_SetSuspendTimeout is valid only for the current instance of the driver. An unplug and re-plug will cause the driver to set the timeout to a default 10 seconds value.

Best Regards
FTDI Community