This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

HD3SS3220: How could we control ENn_CC via EC to ensure proper re-enablement without causing issues?

Part Number: HD3SS3220

Tool/software:

Hi, Sir,
We have a motherboard design that uses the HD3SS3220 for the USB Type-C port, and the schematic is as below:


To save power, the system disables the VBUS power after the OS enters shutdown.
However, we encountered a problem where USB3 functionality becomes unavailable after the system powers on again.
It seems the USB3 failure is related to the lack of CC re-negotiation after VBUS is re-applied.
We conducted an experiment where re-enabling the ENn_CC (pin 29) signal resolved the USB3 issue. Therefore, we are considering using a GPIO to control ENn_CC.

However, the datasheet does not provide detailed timing requirements or behavior for ENn_CC control. We are concerned that improper ENn_CC control may introduce side effects.
Could you please provide timing guidelines or recommendations for controlling ENn_CC via EC to ensure proper re-enablement without causing issues?


Below is actions of our re-enable experiment using a button connected pin 29 and GND:


Step 1: When the system shuts down, the EC disables the load switch and VBUS = 0 V.
   At this point, the button is not pressed, so ENn_CC is floating.

Step 2: When the system powers on, the button is pressed, pulling ENn_CC low.
   This enables ENn_CC, and pin 27 (ID) is pulled low.
   The EC detects ID = 0 and turns on the load switch, restoring VBUS to 5 V.

  • Hi Cho,

    ENn_CC does have some power-on timings listed on the datasheet, as well as some example diagrams:

    Generally, you'll want to wait for the 5V rail to be stable before controlling ENn_CC, with about 2ms between the 5V rail being stable and pulling the ENn_CC pin low.

    If the 5V rail on the HD3SS3220 tied to VBUS, or is it a separate 5V rail?

    You are correct that if you pull VBUS low, you will need to re-negotiate the CC connection, as VBUS is tied to the CC negotiation process.

    I would recommend either controlling the pin externally via GPIO from a MCU or the SOC, or using something similar to a switch like you are now.

    Thanks,

    Ryan

  • VDD5 (Pin30) of the HD3SS3220 is a separate 5V rail on our system, is not tied to VBUS.

    After the system shuts down, 5 V rail and 3.3 V rail on HD3SS3220 remain always on. We only use EC to turn off the VBUS power (please refer to U34 load switch in the schematic, where VBUS = +V5_USBC1).
    Therefore, both the 5 V and 3.3 V rails stay in a stable state after shutdown. It is different from the condition shown in Figure 7-3 of the datasheet.

    Below is the currently proposed timing diagram.
    Since both 5 V and 3.3 V rail on the HD3SS3220 remain powered (unless the system adapter is removed), we would like to ask:
    How should the EC control the ENn_CC pin during the yellow highlighted area below? Are there any specific timing requirements?

  • Hi Cho,

    How should the EC control the ENn_CC pin during the yellow highlighted area below? Are there any specific timing requirements?

    I don't believe there is any specific timing requirement for the ENn_CC pin outside timing for when the 5V and 3.3V Rails are powered.

    If you were to pull ENn_CC high at the same time VBUS is disabled, this would cause the CC connection to completely break, which combined with VBUS being removed would cause the entire USB3 signal to disconnect. Then, you can pull ENn_CC back low once PS_ON# goes low, that way the CC lines can renegotiate the USB3 connection, and the EC can control when VBUS is sent after the CC negotiation pulls the ID pin low.

    I would say you can either pull ENn_CC high at the same time PS_ON# goes high or VBUS is disabled, and then can be pulled high either at the same time or a small time after the system power is turned back on, that way there is time for the system to be powered before USB communication takes place again.

    Thanks,

    Ryan

  • Hi, Ryan,

    Thank you for your assistance.