I'm developing USB Hibernation feature on on of the platform which use Synopsis DWC3 USB controller. When USB alone resumes from suspend state there is no issue.

But I'm facing an issue while my device is resuming from deep sleep. While resuming the Link state comes as 4 (Disconnected) which leads to USB re-enumeration.

From hardware team there is a query regarding this issue which i'm not able to understand. Please see below,

In deep sleep we observed:

  1. a micro-frame peak signal amplitude much grater than expected (almost the double);
  2. an undesired zero-level offset before the micro-frame.

These misbehaviors matches the hypothesis of a missing Single-Ended 0 (SE0) termination on one of the stream facing ends. Since the host is the Suspend/Resume master that works correctly with any other USB 2.0 device, we should suppose that device end misses its High Speed (HS) 45 ohm (namely) termination connection at end of Resume phase.

By specification device must connect HS termination within 1.33 us since Resume end (USB D- falling edge), so this is normally done by the USB 2.0 PHY hardware ready to react in advance since Resume state started. We observed that the device detects Resume state start correctly, by increasing power consumption in few milliseconds, indicating a prompt reaction to exit deep sleep state. Resume will last not less than 20 ms that is largely enough to prepare USB 2.0 PHY to be ready to answer to Resume end detection and relevant SE0 termination required by HS communication link.

If device SE0 misses, then the host-monitored increased signal amplitude occurring at first micro-frame causes the host to enter an High-Speed Disconnect state, followed by USB reset, FS to HS negotiation, re-enumeration, etc.

Could anybody explain what is the above query?

  • 1
    \$\begingroup\$ I see that you were recommended to ask the question here, when you posted the same question on Stack Overflow. In that case, you should delete the question on Stack Overflow, since having duplicate questions on different parts of Stack Exchange/Stack Overflow is generally discouraged, as it can duplicate effort and so waste people's time. \$\endgroup\$
    – SamGibson
    Commented Feb 23, 2018 at 17:07
  • \$\begingroup\$ What do you mean under "deep sleep" as compared to "USB suspend"? USB framework doesn't define a concept of any "deep" or "light" sleep. If you mean that your MCU can't properly end the USB suspend state if it is in "MCU deep sleep state", then your problem is in power management of your MCU. \$\endgroup\$ Commented Mar 2, 2018 at 16:17

1 Answer 1


we should suppose that device end misses its High Speed (HS) 45 ohm (namely) termination connection at end of Resume phase.

From the "hardware team" description, your device failed to restore the HS termination after the end of RESUME, which results in HS disconnect (micro-frame amplitude doubles due to absence of termination in your device design).

Please keep in mind that one important part of RESUME protocol is missing in the description: in host-initiated RESUME (K-state), the device must RETURN the SAME line state (K-state) back as a signal of recognition. Host recognizes this two-way driven state when the host-side 20 ms timeout expires, but the bus stays in K-state. Then the host waits for the device to end the K-state, and proceeds with resume of HS idle traffic (SOFs).

So this is the device responsibility to finish the RESUME condition and assert HS termination in timely (1.33us) manner. So it looks like the entire protocol response form your device is missing. Your device receives the RESUME correctly, but fails to respond properly. Some hooks (maybe to power-management part of device software) are missing.

  • \$\begingroup\$ Thanks for your response. I will have discussion internally about your answer. \$\endgroup\$ Commented Feb 25, 2018 at 18:46
  • \$\begingroup\$ By comparing registers i see in success scenario connection speed detects as HS whereas in failure case speed detection is FS. Does it has anything to do with above query? If yes, which module is responsible for HS/FS speed detection? \$\endgroup\$ Commented Mar 2, 2018 at 14:19
  • \$\begingroup\$ @user3267021, comparing registers after the failure doesn't tell you much. The process is dynamic, all at hardware level. You need to acquire long (300-400 ms) scope traces of D+ and D-, with deep sub-microsecond resolution to ensure correct RESUME exit. I repeat, the process of exit from SUSPEND state is described/understood incorrectly in the "query" - proper completion of the RESUME protocol is missing. But if you want a brief explanation on how the FS/HS detection works, see superuser.com/a/1130446/620011 \$\endgroup\$ Commented Mar 2, 2018 at 16:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.