cancel
Showing results for 
Search instead for 
Did you mean: 

USB Hosts Hubs Transceivers

New Contributor

I'm working on a battery powered system with the following overall architecture...

Capture.PNG

The MCU is very competent one with two USB interfaces.  The MCU manages power consumption of the entire system by turning off power to many of the system components.

The MCU and its LDO run continuously albeit in deep power down when the system is idle. The MCU enables and disables all of the high current regulators in the system to manage power.  A timer in the MCU wakes up the system from a deep power down. 

The downstream hub ports are all non-removable.  The upstream port is connected to the host with a cable.  Due to the (massive) amount of power required by the FPGA, the entire system will be "self powered" not "bus powered".

I have a number of questions:

1.  Should the CY7C65642 be powered from +5V from the USB bus or from the switched +3.3V supply?

2.  Many tears fall (without careful thought) when powered portions of a system drive sections that are not powered.  Are there any concerns about a powered MCU driving the un-powered CY7C65642 through the USB signals? The USB_VBUS signal will be 0V on both MCU's USB ports when the CY7C65642 is powered off.  Given that USB is inherently "hot swapped", I don't think this will be a problem.  Preventing tears is always a good thing.

3. I want to use the CY7C65642in the 28 pin QFN package.  I believe a EEPROM will be required to configure all of the down stream ports as "non removable".  Does this matter?  My understanding (from reading a post here) is that configuring a port as "non removable" is only required for strict USB compliance testing.  This application does not need that.  Any other to prefer using a EEPROM? (trying to space PCB area)

4. Can the MCU be used to configure the CY7C65642 via the I2C port in lieu of a EEPROM?

5. If a EEPROM is required to configure CY7C65642, can you recommend a USB tool that will program the EEPROM.  I'm thinking TotalPhase's Aardvark might work.

Thanks for your help; it's much appreciated!

Wayne

0 Likes
Reply
1 Solution
Moderator
Moderator

Hi Wayne,

1. Since the system is self-powered, I would recommend making the hub purely self-powered as well by powering it from the 3.3V supply. Please ensure that the hub is held in reset till VBUS is present from the host. This can be done by connecting the RESET pin to VBUS from host with a RC circuit as done in our CY4608 DVK​.

2. No, it shouldn't be a problem if the VBUS for the MCU ports is disabled till the hub is powered on since D+/D- terminations won't be presented till VBUS is detected. The PWR# pin could be used for power control for the ports if possible.

3. Yes, your understanding is correct. The EEPROM with the 28-pin package will allow you to set the values to "Non removable" which will be reported in the Hub Descriptor. If you don't require compliance testing and any other configuration options, you may eliminate the EEPROM and use the default descriptor values.

4. No, since HX2VL can only act as an I2C master and the default EEPROM address of 0x50 is used for reading the configuration during boot up. Please refer to the App Note for compatible I2C EEPROMs- https://www.cypress.com/file/122726/download

5. Yes, that would work but we recommend using our Blaster utility, which can be installed with the CY4608 DVK files from the above link, and will allow the EEPROM configuration through the hub by binding to the provided vendor driver.

Best Regards,
Sananya

View solution in original post

0 Likes
Reply
5 Replies
Moderator
Moderator

Hi Wayne,

1. Since the system is self-powered, I would recommend making the hub purely self-powered as well by powering it from the 3.3V supply. Please ensure that the hub is held in reset till VBUS is present from the host. This can be done by connecting the RESET pin to VBUS from host with a RC circuit as done in our CY4608 DVK​.

2. No, it shouldn't be a problem if the VBUS for the MCU ports is disabled till the hub is powered on since D+/D- terminations won't be presented till VBUS is detected. The PWR# pin could be used for power control for the ports if possible.

3. Yes, your understanding is correct. The EEPROM with the 28-pin package will allow you to set the values to "Non removable" which will be reported in the Hub Descriptor. If you don't require compliance testing and any other configuration options, you may eliminate the EEPROM and use the default descriptor values.

4. No, since HX2VL can only act as an I2C master and the default EEPROM address of 0x50 is used for reading the configuration during boot up. Please refer to the App Note for compatible I2C EEPROMs- https://www.cypress.com/file/122726/download

5. Yes, that would work but we recommend using our Blaster utility, which can be installed with the CY4608 DVK files from the above link, and will allow the EEPROM configuration through the hub by binding to the provided vendor driver.

Best Regards,
Sananya

View solution in original post

0 Likes
Reply
New Contributor

Thanks for your very prompt response. I will need some time to digest all of the details. Nevertheless, I appreciate the thoroughness of your reply.

Wayne

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

0 Likes
Reply
New Contributor

Sananya

Please refer to the schematic below.  This hub design is "embedded"; it

uses the CY7C65642 in the QFN28 package.  The upstream port is attached

by a cable but all of the downstream ports are non removable.   I

incorporated your suggestion of using VBUS to hold the CY7C65642 in

reset until the host is powered.  The ridiculously large reference

designators (U6000, etc.) are an artifact of doing the schematic

additions without driving the PCB layout person mad.  The reference

designators will get re-sequenced later.

I also used the following power connection from AN72332 "Guidelines on

System Design Using Cypress’USB2.0 Hub (HX2VL)" as appropriate for the

QFN28 package.

I have a few questions:

1. Since this hub is "embedded", I wasn't quite sure what to do with the

"GANG" pin.  It's asserted, specifying gang operation.  There is no

reason to power manage individual ports and no chance for an over

current as this embedded hub is self-powered.  Correct?

2. The "GANG" pin is tied high, so the "OVR_N[0..3]" pins are left as no

connects; they apparently are not used when the "GANG" operation is

configured.  Correct?

3. The "SELFPWR" is also tied high to specify self powered operation. 

Correct? Is a pull up resistor required or preferred?

4.  Cypress provides the "Blaster" configuration utility to write the

CY7C65642's configuration EEPROMs. Programming is done through the USB

upstream port, so no additional test points or headers are necessary to

program the EEPROM in situ.  Correct?

5. The I2C EEPROM has its "WP" pin negated to allow the USB Blaster

software to write the contents of the I2C EEPROM.  During manufacturing,

blank EEPROMs will be soldered on the PCB.  The "Blaster" utility will

allow these I2C EEPROMs to written, if they are not write protected (WP

pin negated).  Correct?

6. There is only one 10K pull up on the CY7C65642's I2C SDA signal. None

of the reference schematics show a pull up on the CY7C65642's I2C SCL

signal.  Given that this single master, single slave i2C bus, is the I2C

SCL signal actively driven without an open drain output?

7. If you see any errors on the schematic please let me know.

Thanks so much for your kind assistance ensuring first pass success on

this PCB!

Wayne

SananyaM_56 wrote on 12/10/2020 10:44 PM:

Cypress Semiconductor logo <http://www.cypress.com>

>

Cypress Developer Community

<https://community.cypress.com/?et=watches.email.thread>

>

Power Management of CY7C65642

reply from SananyaM_56

<https://community.cypress.com/people/SananyaM_56?et=watches.email.thread>

in /USB Hosts, Hubs, Transceivers/ - View the full discussion

<https://community.cypress.com/message/269033?et=watches.email.thread#269033>

>

0 Likes
Reply
Moderator
Moderator

Hi Wayne,

Thanks for the update.

1. Even if the hub is self-powered, you could have port power control based on device requirements in either Individual or Gang mode. USB spec recommends having overcurrent protection with a preset current limit on self-powered hubs as well for safety reasons. If you use Gang mode, you would have to use a single polyfuse for all the ports while in Individual mode, you could have a separate polyfuse for each port.

2. Yes, in Gang mode, only the OVR[1]# pin will be used and the other OVR# pins can be left unconnected.

3. Yes, that is correct and we recommend connecting the SELFPWR using a 100K pull up resistor.

4. Yes, that is correct as the programming will be done through USB port and HX2VL I2C lines.

5. Yes, the WP pin should be de-asserted to allow programming through Blaster utility.

6. Since the I2C SCL pin also acts as the TEST pin, external pull up shouldnt be connected as it would put the hub in test mode. When the pin operates as I2C SCL, internal circuitry allows the hub to drive it to logic high.

7. It is recommended to use a crystal with drive level that exceeds the power consumption, please check that as per the App Note. Other than that, the schematic looks fine to me and I have no other comments.

Best Regards,
Sananya

0 Likes
Reply
New Contributor

Sananya

Thanks for your help.  Please mark this discussion closed.

Wayne

SananyaM_56 wrote on 12/16/2020 11:34 PM:

Cypress Semiconductor logo <http://www.cypress.com>

>

Cypress Developer Community

<https://community.cypress.com/?et=watches.email.thread>

>

Power Management of CY7C65642

reply from SananyaM_56

<https://community.cypress.com/people/SananyaM_56?et=watches.email.thread>

in /USB Hosts, Hubs, Transceivers/ - View the full discussion

<https://community.cypress.com/message/269559?et=watches.email.thread#269559>

>

0 Likes
Reply