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.

TPS2546: Wake on USB (wireless mouse) fail issue

Part Number: TPS2546

Hi team, 

My customer design the TPS2546 to work under below 2 cases and reported "wake on USB" by mouse feature is abnormal sometimes with some mice.

CTL1 CTL2 CTL3 ILIM_SEL
system S0: CDP 1 1 1 1
system S3: DCP Auto 0 1 1 1

The customer did not involve the D+/D- capture yet while regarding the CTL1 and Vbus waveform I have some questions.

1. S0 sleep to S3 and Vbus discharge appears. Can NOT wake on USB (wireless mouse)

2. Sleep from S0 to S3 and no Vbus discharge appeared. Wake on USB function is normal in this case.

Also fail waveform from S3 to S0 (can't wake up from mouse)

waveform from S3 to S0 (can wake up from mouse)

Could you please review and suggest if the Vbus discharge is related to the issue? Usually from CDP to DCP auto and also backward there should be a Vbus discharge expected. While seems it's different on the wake on usb case. Is this expected? And what is the expected waveform/workflow?

Thanks

Max

  • And what could be the reasons that causing the issue?

  • Hi Max,

    Wake on USB can only work for a low-speed and high-speed devices. Wireless mice and keyboards are typically full-speed devices, which are not supported by Wake on USB

    Regards,

    Emma

  • Hi Emma,

    Thanks for your update. May I know why we don't support full-speed wake up function? And also the wireless mouse seems not always fail but with a percentage fail rate. Why did that happen?

    Thanks

    Max

  • Hi Emma,

    I noticed below claim from datasheet (3 Description section on the 1st page claiming a support for full speed). 

    And also below part in the wake on USB section that claims a wake-up capability for full speed device with a 60s window.

    Could you please double confirm whether full-speed wake up is supported by TPS2546 by some method please?

    With the same wireless mouse, no issue reported on 2546 in previous generation projects so I consider there maybe some host behavior related.

    Thanks

    Max

  • Hi Max,

    Apologies, it does appear that full speed devices are supported. Can you post scope captures of a successful wake up? Also, being able to see if DP/DM stay connected during the VBUS discharge will be helpful to see if the VBUS discharge will actually cut the dataline communication and have the port transfer into DCP_auto. In a normal wake scenario, the DP/DM will override the host signal to move into DCP_auto and remain connected in order to see the wake command come from the mouse/keyboard.

    Thanks,

    Emma

  • Hi Emma,

    S0-S3 OK,

    S0-S3 fail,

    S3-S0 OK,

    S3-S0 fail,

    Please help to review and let me know if you notice any abnormal behaviors or need some more capture.

    Thanks

    Max

  • Hi Max, 

    What is the timing? Are you putting the host to sleep within 60 seconds of wake up? Or are these tests performed while the host has been awake for 60+ seconds?

    Regards,

    Emma

  • Hi Emma,

    Yes it has last for 60+s but we could still see fail occurs. 

    Could you help to list the formal test procedure on that?

    And any more waveforms we could check to fix the issue?

    As mentioned the issue seems to be host/platform/bios related as the TPS2546 schematic not changed between generations and previous generation don't have the issue. 

    Thanks

    Max

  • Hi Max,

    Is the VBUS discharge happening on the system side or the connector side of the TPS2546? This issue does seem to be caused by the VBUS discharge.  

    If you could perform the same tests (fail and pass) with VBUS on both sides of the TPS2546, that could give us an answer as to what is happening to VBUS. 

    Thanks,

    Emma

  • Hi Emma,

    Unfortunately I think it is not the system side 5V problem as it is enabled in the whole process.

    S0-S3 fail

    S3-S0

    It seems related to TPS2546 behavior and detection on the signal. Need your help to further review and analyze the issue.

    Thanks

    Max

  • Hi Max,

    Can you double confirm the CTL pins that are used for the wake up? 

    Regards,

    Emma

  • Hi Emma,

    I'm not quite following your idea. The CTL pins are indicating the wakeup. The CTL1 shuold be pulled by system EC when doing system states transimission.

    A correction that the issue seems not to be host related. As cross checking on the previous platform gives the Mode did not change at all and toggling CTL1 will also lead to the same issue on previous generation products.

    Max

  • Hi Max,

    I wanted to confirm the other two CTL values. Can you elaborate more on your cross checking? 

    One thing we can look at is if the wireless mouse falls into the category of low/full speed. Can you look into the model and make of the wireless mouse to see what the speed the mouse is? A low-speed device will be 1.5 Mbps and a full-speed device will be 12 Mbps, with a high-speed device being 480 Mbps.  

    Are you able to use other wireless mouse/keyboards for wakeup that are not of this manufacturer?

    Thanks,

    Emma

  • Hi Emma,

    Yes I confirmed the 2 other CTL pins did not toggle ( from hardware design they are tied to +5V_S5 (system side of TPS2546) and the waveforms were attached previously. 

    Customer checked in a "USB Viewer" tool in windows OS and confirmed to me the mouse is full-speed device. I didn't record the manufacture but customer did provide a few mice that produced from different vendors and the issue could be reproduced. 

    The wired mouse and keyboard could always wake the system while it seems a problem for the wireless ones.

    What's the factors that could influence TPS2546's wake on usb function? I think it's better to make clear all the factors and review one by one to see if we missed any or the device violate any of the requirements.

    Thanks

    Max

  • Hi Max, 

    I will follow up via email.

    Regards,

    Emma