jitlim

Type-C Fundamentals: Get This Wrong and Very Bad Things Happen

Blog Post created by jitlim Employee on Oct 21, 2016

 

By now, we all know how cool the Type-C connector is. Unfortunately, you have also heard about the very serious consequences of non-compliant USB Type-C designs destroying very expensive products. In this blog, we will review some fundamentals of the Type-C architecture that you must get right.

 

The first step to correctly designing a USB Type-C connection is to acquire and review a copy of the Type-C “Universal Serial Bus Type-C Cable and Connector Specification” from www.usb.org. You will notice is this is not a generic Type-C device specification, but that the device must adhere to the USB Type-C requirements. The next thing you will notice, is the specification does not include details for the USB speed or USB-PD. USB speed and USB-PD capabilities are documented in the “Universal Serial Bus 3.1 Specification” and “Universal Serial Bus Power Delivery Specification”. These are separate specifications and can be independent of Type-C.  For example, your Type-C design implementation may not include USB3.1 or USB-PD. Sometimes, there is a misconception by engineers that Type-C is synonymous with USB 3.1 and also USB-PD.

 

Let’s now review Figure 1 below. The topology highlighted in yellow is the most basic Type-C implementation and it must be incorporated independent of USB speeds and USB-PD.

 

Depending on whether you are designing a DFP (power source), or a UFP (power sink) the correct implementation of the Rd network and the Rp value is required. The reason for including the second Rp or Rd pair is that the cable can be flipped, and the cable’s capabilities must be present on the other CC connection.  Also note, that there are separate voltages for Vbus, 5V for Rp, and Vconn.

 

Reviewing the cable portion of Figure 1, you will see that there is only 1 CC wire, and the other CC wire is used as Ra for the cable power. Also, the Vbus is a separate connection. In your cable design, ensure that 2 CC wires are not implemented, and do not connect the CC wire to Vbus. The Rp/Rd implementation is part of the UFP/DFP and should not be added to the cable design!

 Figure 1. USB-PD Full Feature Implementation. (Courtesy of USB-IF)

Figure 1. USB-PD Full Feature Implementation. (Courtesy of USB-IF)

 

Let’s review the Type-C implementation from the connector pin-out perspective in Figure 2. The cable/product plug only sends 1 D+/D- pair so the product receptacle side must have D+/D- connections for both the CC1 and CC2 orientations.  The cable/product plug has only 1 CC line and the other CC line is used to sink Vconn.

 

A potential source of confusion is the way the cable/plug pin-outs are defined. For example, let’s pick A2/A3 defined as TX1+/TX1-. One could reasonably assume that these are the TX1+/TX1- signals that are coming from the cable/plug. That would be incorrect. The cable/plug pin-outs are defined relative to the receptacle pin-outs. So, A2/A3 for the cable/plug are the TX pairs coming from the A2/A3 pins of the receptacle and actually go to the RX pins of the device at the other end of the cable/plug.

 

If your product is a device, or charger with a tethered or captive cable, you have more flexibility in your design. In this case, you would be less concerned about presenting the product receptacle pinouts. Your product will simply look like the product cable/plug pin-outs and will present only 1 CC wire in the plug/cable.

If your product is a Type-C legacy adapter, it must also adhere to the Rp/Rd requirements show in Figure 1. For example, a legacy device adapter must implement the correct Rd network and Rd value.

Figure 2. Type-C receptacle and cable/plug pin-outs. (Diagram courtesy of USB-IF)

Figure 2. Type-C receptacle and cable/plug pin-outs. (Diagram courtesy of USB-IF)

 

There are a number of actions being taken by the USB-IF to protect your product from being damaged by non-compliant connections. For example, requiring major retailers to sell only compliant Type-C cables. In addition, the USB-IF is adding an optional Authentication Specification so you can check for compliant device and chargers before power and data are connected.

 

So, you have studied the specs rigorously, and have implemented the design exactly as defined. But, nothing prevents a user from connecting a non-compliant cable or device to your product. What happens when a user connects a non-compliant 20V Vbus directly to your CC line, or tries to draw 100W directly from your 5V Vbus? Your design cannot rely on only compliant product connections for protection and must deal with the possibility that customers will connect a non-compliant product. For example, you must design for source and/or sink overcurrent and overvoltage protection.

 

One important step you should take before your device or charger goes into production, is to take your product to a USB workshop for FYI testing or compliance certification. These workshops are held approximately once per quarter, and where numerous physical and interoperability tests can be performed to help ensure your design is meeting the requirements per the specification.

 

We hope this blog has been helpful for you to understand the fundamentals of Type-C, non USB-PD implementations. If your USB product does not exceed 5V/3A, and does not include Alternate modes, you do not need to implement USB-PD.

 

In a future blog, we will talk about how the USB-PD spec can be used to expand the capability of the Type-C connector beyond 5V/3A. Also, how to add features like hosts/DFPs that can be power sinks, and devices/UFP, that can source power, as well as power role swap, data role swap, and Alternate mode.

Outcomes