1
\$\begingroup\$

I have the following setup with two scenarios I will describe underneath. The more I think about it and the more I look up the spec I get more confused and frustrated.

A USB 3.X host connected over a Type-A to Type-C cable to a USB 2 or 3 device (even though I only need the USB 2 speeds, I still don't know if I need 2 or 3 for USB DEFAULT POWER; more underneath).

Scenario 1: Connecting a laptop to it, I want the laptop to power the device which needs around 5W. This way I can power it and configure it.

Scenario 2: The same device previously being a sink and a UFD is powered through an alternate source. Now, it should work when I connect a flash drive to it, so the system can copy the config file from it without me needing a laptop.

And now the confusion which is torturing me for days now:

Question 1, Power: Constellation of Type-A USB 3 host to Type-C USB 2 host via USB Legacy Type-A to Type-C cable. What exactly is the maximum power my sink will be able to draw here and why? For me, there are multiple factors here. According to Section 3.5 of the Type-C spec, the necessary Rp resistors, pulled up to VBUS, are advertising the Default USB Power capabilities of the source. Meaning a USB 3 host would source 5 V @ 100 mA, because

  1. unconfigured and
  2. no SS-lanes and their RC termination are detected (Sink is not USB 3)? Or
  3. WITH detectable SS-lanes it would source 150/250 mA before configured state and up to 900/1500 mA after configuration and enumeration??

Question 2, sink requesting power: On the sink side the CC terminal, VBUS and GND of the Type-C Cable are like this enter image description here

Rd is chosen to request USB Default power. Could it be chosen to request 5 V @ 1.5 or even 3 A, like in Table 4-38 with a USB3 Type-A on Source side?

Question 3: I think I understood the negotiation, enumeration of the individual protocols, interface specs. But I am having a hard time seeing the overall big picture. How does the enumeration work with USB3, Type-C (CC channels) and USB PD?

with USB2, the speed for the enumeration is set with pullups/pulldowns on D+/D-. Until configured the device may not draw more than 1 unit load (USB2: 100 mA, 5 V). When does the host check if the sink/device hast SS-lanes and proper termination? Is the sink/device requesting more power and telling the host it can do SuperSpeed through the descriptors? If yes, how does that translate to USB Type-C and USB PD? How does it work when the device told the host via descriptors how much power it wants but could also request that power through CC lines?

Question 4: Connecting USB Flash drive (Accessory) to device The specification talks about VCONN-Powered USB Devices (VPDs) which implement a UFP. Can a device without a USB PD controller even work with such a USB flash drive? I mean without the role swap functionalities. Is there NO WAY for a sink to work with a attached flash drive?

\$\endgroup\$
2
  • \$\begingroup\$ "Scenario 2: The same device previously being a sink and a UFD should work when I connect a flash drive to it, so the system can copy the config file from it without me needing a laptop." What sort of flash drive? This will be fine if it's got a Type C plug on it, but if it has a Type A plug the adaptor should be responsible for activating the power. \$\endgroup\$
    – Finbarr
    Commented Jan 20, 2023 at 15:55
  • \$\begingroup\$ Hi @Finbarr, thanks for the comment. Of course I will assume a Type-C USB flash drive when the device doesn't have a Type-A interface. And at this point the device is operational powered by an alternate source. I have learned about special FSMs the specification describes. DRP devices which opt to beeing a sink/UFP when connected to a DRP (a laptop). This perfectly covers my case. Ill edit my question to make this more clear. \$\endgroup\$
    – MichaelZ
    Commented Jan 21, 2023 at 9:09

1 Answer 1

0
\$\begingroup\$

As a practical matter, if you use a PD controller, it will implement BC 1.2 spec and the 5V 3A may be available if the host provides it. Many or even most hosts support battery charging and data, so the 100mA limitation is a legacy thing only. If you want to interoperate with legacy cables and need a couple of watts of power in all situations, a PD controller is a must whether you buy it or make your own - not for USB-C BMC signaling, but for dealing with layers of legacy crud on D+/D-

Not using a PD controller has you implement all the spec and the oddball corners of it manually, and it’s hard work. Especially considering BC and potential proprietary “extensions” that PD controllers can support (like the “Apple” resistor scheme, 5V QuickCharge, Samsung, etc.) Been there, done it, in the end it was only worth it because the PD controller availability was iffy or nil for what we needed. “Plugfest”-style testing was a pain but very revealing.

You have a simple application it seems and any PD 3 controller will tell you how much power is available so you don’t need to learn the full spec that way. Not using a PD controller essentially means you will have to pass certification tests (whether formal or informal) just to be sure you didn’t mess up in your own implementation.

This way I can power it and configure it.

No USB device can just power up chugging 5W. It doesn’t matter what connector it uses. Enumeration and configuration must be possible down to 5V 100mA even if your device has a USB-C connector - precisely for full legacy compatibility. If you can’t do it, you won’t pass compliance tests IIRC. The device doesn’t have to be fully functional at such power levels of course. But it must accept that not enough power is provided and stay safe.

What exactly is the maximum power my sink will be able to draw here and why?

If you plug it into a legacy USB 2 hub that doesn’t support BC nor proprietary charging extensions, you get 100mA at 5V until enumerated.

If you plug into any modern USB 2 type A port, you’ll have at least some BC power levels available, potentially Apple proprietary power levels if it’s a hub made to play ball in the Apple ecosystem, Samsung proprietary is possible too, etc. A competent PD controller will handle all that.

Rd is chosen to request USB Default power. Could it be chosen to request 5 V @ 1.5 or even 3 A, like in Table 4-38 with a USB3 Type-A on Source side?

You can request what you want but you may not get it. There is no mechanism in a dumb Type-A to Type-C cable to make much use of the CC channel. All you basically get on the USB-C side is an indication that the cable is there - the cable side CC termination - and VBUS goes up immediately. That indicates that no CC signaling is possible and there’s nothing listening to your requests or denying them. Whatever you connect to the CC line on such a cable is immaterial. You can leave it open and it’ll work (but of course not be in spec!).

Re 3: In practice if your device is not a USB 3 device then anything USB-3 is irrelevant. And even if it was, it must operate to the lowest denominator of USB-2 legacy with no BC, think a USB 1.1 host pretty much. Sensible power levels from Type A to Type C over passive cables are a matter of battery charging protocols that work over D+/D- lines for modern hosts, and USB 2 configuration if no BC or proprietary charging is detected. None of that other stuff you worry about matters much. If BC or proprietary charging is available then USB 2 enumeration and configuration doesn’t figure in power levels. It only really is a thing if no other way of establishing the host’s power supply capacity is possible.

Re 4: If a port is a sink only, then that’s what it is. To power anything at all you will need a source port. It doesn’t need a full featured PD controller for that. Role swap is not necessary since that’s only when a port has to reverse power flow. When you have a flash drive, it is always a sink, so no role swapping involved. But USB-C flash drives can be either vconn powered or vbus powered IIRC, so having a minimal controller is in practice the simplest way to do it. Vconn has to be protected from reverse current flow and overcurrent. With a competent PD chip it comes built-in.

If your own device is Vconn-powered, it still can be a source for low power sinks. Those are orthogonal concerns. If the USB2 flash drive has a configuration that fits within vconn power budget available to you, you can power it even though you only got vconn coming in.

Finally, the CC channel signaling is only a tiny part of a PD controller. You still need power path protection to be in spec. Basically, and USB-C device should survive a hard always on 20V on VBUS or you’re not compliant IIRC. There needs to be overcurrent protection and reverse current protection on both VBUS and Vconn. There must be proper discharging to VSafe5 or Vsafe0 as prescribed. And that’s just the start. So, in practice, a PD controller is useful also because it has a protected, compliant power path, and because it can advertise and accept battery charging “negotiated” over D+/D-, even if the CC signaling is not a big deal to “homebrew”.

That’s also why there are rather few “CC PHY” solutions out there and most are not recommended for new designs or are obsolete. The signaling part of PD is not too hard, there’s at least two major open source firmware libraries implementing the policy magic (from ST and Google), but everything else will consume BOM allowance rather quickly if you’re not seasoned in power path design.

TL;DR Connecting to Type A ports is a worst case of 100mA on unpowered hubs and 500mA on powered hubs and legacy hosts, iff USB 2 configuration is successful. USB 2 sleep handling is also required for devices with a USB 2 data path (so anything with USB-C connector with data). You must accept it and deal with it. If your device is non-functional without say 5W of power, then it won’t work with some Type A ports and there’s nothing anyone can do about it. USB-C doesn’t even figure in any of it - you’d have the same problem had you used a Type-A to Type-B cable.

TL;TL;DR: A full featured PD 3 controller will let you get most power anyone else could get from a given connection without you worrying how it happens for the most part. QuickCharge 3 is not always supported but if the firmware is editable then you can add that in with existing analog circuits the PD already has.

\$\endgroup\$
1
  • \$\begingroup\$ Thanks for the reply. I see some of my original doubts being answered. Proprietary solutions and protocols were never in the scope of my question and neither were power path considerations, but i blame my badly phrased question. I did find an answer to my question, tho. In summation, USB PD is not necessary if my device a DRP needs to be powerd by a host laptop, also a DRP and to a later point in time act as a host for when a flash drive is inserted into my application. Page 166 in the Type-C spec under "USB Type-C State-Machine-Based Role Swapping". \$\endgroup\$
    – MichaelZ
    Commented Jan 21, 2023 at 9:24

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.