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.

TUSB8042A: PWRON1_BATEN1,PWRON1_BATEN2 act low

Part Number: TUSB8042A
Other Parts Discussed in Thread: TPS2066, TUSB8020BEVM

Hi,

Please find the schematic in the link below. 

https://e2e.ti.com/support/interface/f/138/t/895306

Issue: 

PWRON1_BATEN1,PWRON1_BATEN2 act as low level  and  can't enable the  power switch TPS2066 to support SVCC1,SVCC2 for downstream port USB2A and USB2B.  Please also find the result through serial port in the below. 

[    2.954795] hub 1-0:1.0: USB hub found

[    2.958546] hub 1-0:1.0: 1 port detected

[    2.962625] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller

[    2.968114] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2

[    2.975792] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.

[    2.984124] hub 2-0:1.0: USB hub found

[    2.987878] hub 2-0:1.0: 1 port detected

[    2.991966] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller

[    2.997454] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 3

[    3.005292] xhci-hcd xhci-hcd.1.auto: hcc params 0x0220f66d hci version 0x100 quirks 0x02010010

[    3.014006] xhci-hcd xhci-hcd.1.auto: irq 46, io mem 0x03000000

[    3.020174] hub 3-0:1.0: USB hub found

[    3.023929] hub 3-0:1.0: 1 port detected

[    3.027991] xhci-hcd xhci-hcd.1.auto: xHCI Host Controller

[    3.033476] xhci-hcd xhci-hcd.1.auto: new USB bus registered, assigned bus number 4

[    3.041155] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.

[    3.049483] hub 4-0:1.0: USB hub found

[    3.053239] hub 4-0:1.0: 1 port detected

[    3.057326] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller

[    3.062857] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 5

[    3.070698] xhci-hcd xhci-hcd.2.auto: hcc params 0x0220f66d hci version 0x100 quirks 0x02010010

[    3.079407] xhci-hcd xhci-hcd.2.auto: irq 47, io mem 0x03100000

[    3.085574] hub 5-0:1.0: USB hub found

[    3.089328] hub 5-0:1.0: 1 port detected

[    3.093409] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller

[    3.098930] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 6

[    3.106610] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.

[    3.114940] hub 6-0:1.0: USB hub found

[    3.118698] hub 6-0:1.0: 1 port detected

Questions:


1. REG_6h(batEn[3:0])  should be configured manually or are active 1 by default for all ports?

2. Does there any other suggestion to solve PWRON1_BATEN1,PWRON1_BATEN2 low output issue? 

Best  Regards,

Tess 

  • Hi Tess,

    The USB host will send the command to the hub to turn on port power.  This cannot be done manually.  From the debug output shared it does not appear that the hub is being enumerated by the host which is why the port power command is not being sent.    I only see the host ports in the debug log, the hub being referred to is the root hub, not the TI hub.  Please use lsusb command to get additional debug statements.

    Regards,

    JMMN

  • Hi JMMN,

    Thanks for your quickly reply.  Please find the lsusb command in the capture below:

    And we find that PWRON1_BATEN1,PWRON1_BATEN2 issue may caused by the power reset timing.  On our board, VDD is provided through LDO from VDD33A. 

    In initial schematic, there is 1uF capactitor on GRSTN pin, form description above that we remove the cap and left the pin float.  Then PWRON1_BATEN1,PWRON1_BATEN2 could work normal as high level. Please find the capture for VDD(blue),VDD33(yellow), and GRSTz(pink) in the below:

    And if the GRSTz is connected a 200ms reset signal, PWRON1_BATEN1,PWRON1_BATEN2 is wrong as low again. Please find the capture for VDD(yellow),VDD33(blue), and GRSTz(pink) in the below:


    Questions:

    1. As datasheet is mentioned that if VDD33 supply is stable before VDD there need a active reset which need at least 3ms delay between power supplies and de-assertion of GRSTz.  I'm confusing about how to ensure the 3ms limit. It seems that 3ms is achieved by the RC, R is Rpu and does the C is referring to the cap at pin GRSTz? But as mentioned above, this cap shouldn't be placed?

    2. If a cap need, does 1uF is the suitable value for the application?

    3. From the power on sequence that  we got, it seems that long time rather than short of reset could cause wrong state? This phenomena violate the requirements for minimal 3ms delay requirement?

    4. Now even as the good result of high state  PWRON1_BATEN1,PWRON1_BATEN2, the device could not be found through serial port.  What's about your comment on the lsusb command result? Thanks.

    Best Regards,

    Tess Chen

  • Hi Tess,

    The lsusb output shows that the hub is not being enumerated.  This is the reason the PWRONx outputs are not being driven as expected.  Removing the capacitor on GRSTz caused the hub to power up without a reset and enter an undefined state where the PWRONx outputs can be high or low.  The capacitor must be placed on the GRSTz pin to complete the passive reset circuit.  1uF looks acceptable or you could increase it to 2 uF.  

    To investigate why the hub is not being enumerated, please check voltage on USB_VBUS (~500 mV), USB_R1, and SMBUSz (should be high).  Also please confirm there are no blank EEPROMs attached to the hub.

    Regards,

    JMMN

  • Hi JMMN,

    Please find the result for USB_VBUS , USB_R1, and SMBUSz with GRSTz float from figure 1-3 

    Figure1: Yellow-SMBUSz, Blue-VDD, Pink-VDD33

    Figure 2: Yellow-USB_R1, Blue-VDD, Pink-VDD33

    Figure 3: Yellow-USB_BUS, Blue-VDD, Pink-VDD33

     

    Figure 4: Pink-GRSTz, Blue-VDD33, Yellow-VDD with 2.2uF capacitor at GRSTz Pin

    Question:

    1. The description below in datasheet claim that if the VDD33 is stable before VDD11, there shouldn't have cap on the GRSTN? Could you explain about it?

    2. What could cause the host don't enumerate the hub referring to the result through  USB_VBUS , USB_R1, and SMBUSz voltage?

    Thanks a lot for the support.

    Best Regards,

    Tess 

  • Hi Tess,

    If GRSTz is left floating, the hub will not enumerate.  The note in the datasheet references that if VDD33 is ramped before VDD11 then an active reset circuit should be used since the internal pullup to 3.3V is part of the passive reset circuit.  VDD33 and VDD11 ramp together in your system so this is not an issue.

    Can you check the DP/DM lines between the host and the hub?  Also, can you confirm that the thermal pad underneath the hub is connected to ground?

    Regards,

    JMMN

  • Hi JMMN,

    The DP is 3.3V and DM is 0V  and work as normal.  Thermal Pad check suggestion is ongoing. 

    Power on sequence comparasion, it seems different with TUSB8020BEVM behavior :

    1uF cap: VDD33-Yellow, VDD-Blue, GRSTz-Pink with 10ms scale 

      1uF cap: VDD33-Yellow, VDD-Blue, GRSTz-Pink with 2ms scale 

     TUSB8020BEVM  power sequence : VDD33-Yellow, VDD-Blue, GRSTz-Pink with 10ms scale 

    Questions:

    1. Enumeration for upstream USB port is through super speed port (USB_SSTXP_UP and USB_SSTXM_UP) or high speed port (USB_DP_UP and USB_DM_UP) ? 

    2.  Could you please accept the E2E friendship request? I want to get the TUSB8020BEVM PCB layout files from you. Allegro (brd) type is ok for me.

    3.  Another phenomena is found that with 1uF GRSTz cap, the oscillator can not work but without cap could. Could you please help on review the schematic that I will send through the friendship chat?

    Thanks a lot.

    Best Regards,

    Tess Chen

  • Hi Tess,

    Enumeration should occur on both USB 2.0 bus and USB 3.0 bus.  

    Please try increasing the capacitor on GRSTz to 2 uF or 4.7 uF since the voltage rails ramp slower in your system.

    Also, as a test can you try manually shorting GRSTz to ground briefly and see if the hub enumerates?

    Regards,

    JMMN