 Hello, everyone, and welcome to our Zephyr Development Summit presentation. Today we're going to be talking about USB Type-C and U, so turning your product concept into implementation necessities that you need to make it a reality. My name is Diana Zichterman. I'm our USBC lead on our embedded controller team working on our Chromebooks. I'm Sam Hurst, and I'm a software engineer working on embedded controller. Let's dive in. Today, we're going to cover a few different areas. We're going to do a recap of what the port rolls are for USBC and what they mean and what things those entail. They're going to go over requirements out of the specification that we get, and then we'll go into the practical details of how you take all that and you turn it into a device. First up is going to be a port roll recap. If you attended our USBC Power Delivery overview last year, this will be a review for you. If you didn't attend it, I highly encourage you to watch because that gives you a lot of the details on the technical part of USBC. But from where we're concerned for this presentation, we mostly need to review the rules because your roles are going to be one of the things that defines what you're doing with your port. First up, we've got the power roll. The power roll is going to be either a source, the one who supplies power, or the sink, the one who consumes power. This is the power that we talk about that goes over VBUS. It's the power that could range from five volts, a 100 milliamps or something like that, all the way up to 245 watts if you're talking about modern EPR chargers. Whether you're going to be supplying some degree of power to a port partner or always going to be consuming power. Up next to that is the data roll. You're either a DFP, you can act as a USB host or a hub downstream port, or you're going to be a USB device on the other side, something like a thumb drive, a mouse, that thing. Also for the data rolls to bear in mind, the DFP has more control over the connection and what's done on the connection. The DFP is the one that controls alternate mode entry. It's the one that controls whether we go into USB4 mode. If those are things that you need to control from your own device, then DFP is probably the data roll you need to be looking at for that. Then last up, we have the VECON roll. You're either supplying VECON or you're not supplying VECON. VECON is that little bit of power that you give to electronically marked cables to allow them to do their special cable thing. The VECON source is going to be the only one that's allowed to communicate with the electronically marked cable. If you need to probe the cable for any information, if you need to tell the cable to do anything, you have to be the VECON source in order to do that. Then as a reminder from our presentation last year, if you're just using a Type-C connection with no power delivery, then these rolls are going to be fixed for the lifetime of the duration of the connection once you've reached the attached state. If you're the source, you're going to be the DFP, the VECON source. If you're the sync, you're going to be the UFP and not the VECON source. But when you introduce power delivery messaging on top of the Type-C connection, then you're allowed to swap these rolls around as much as you need for whatever combination it is that you need for your specific use case. Now that we've arraigned into ourselves of what all the port rolls are, we're going to dive into the specification requirements that go with them. First up, you'll of course need to access the specifications. They're available freely on usb.org on their document library. Some of them have a static link like the power delivery specification, where you can just go to that link and it'll be whatever the most recent version is. The Type-C specification, the link will get stale over time, so you just go back to the document library and search for the most recent one. It's pretty simple. Basically, if you're thinking about anything that's about valid voltage ranges, connect disconnect timings, those things will be in the Type-C specification. Also, along with Thunderbolt alternate mode specifics, I'm not 100 percent certain why the power delivery messages for Thunderbolt or in the Type-C spec, but they are, so that's the place you'd go for those. On the power delivery side, it'll have your minimum PD requirements you need, the all the different features you can explore, and all those things, those will be what you find in your power delivery specification. I'll also note that there's compliance specifications available on usb.org, but between Type-C and power delivery, we've got 450 pages in the Type-C spec, another 750 in power delivery, so we're just going to talk about those today, because that's plenty of material for a talk. Now, you've gotten the specifications and you start taking a look at them. You might start wondering how these specifications apply to what it is that you want to do. We'll start with the Type-C specification since that's the base of the connection. If you open up Chapter 4, you start looking at the state diagrams. Those state diagrams will correspond with the states we have in our Type-C code, and you might notice there's actually a lot of state diagrams in there. There's seven possible sets of state diagrams you could be using for your connections. So you have to ask yourself, well, which of these states apply to me? What do I need to be looking at here? So the first thing you have to ask yourself is like, what is it that you're connecting to? What are you trying to do with your connection? Are you a little doodad that someone's going to plug a charger into? All you want to do is charge? Are you going to be hosting some kind of data connection? Are you going to have a combination of things going on that entail, perhaps like charging while also hosting something? Are you just going to be a source partner? Are you going to just be a charger? So just think through all the different things that your customer might be plugging in, and that should help you arrive at your source or sync designation that you want for your power role. Some devices like our Chromebooks that we work on end up being dual role, which means we kind of have to work with both. We have to be able to work with thumb drives as well as chargers. But for a lot of applications, you might find that you only need the one power role. You might only need syncing because you're just trying to charge yourself. So just think through the things your customer needs, and that helps get you source sync versus DRP, and that helps narrow down the guy who runs from there. But then there's still more states that you can look at. There's accessory states. Those accessory modes are primarily used for debug accessories and audio accessories. Neither is very common in the industry, so you probably don't need to worry about them for your specific application. So debug accessories are just if you have a specific debug partner that you'll be using with your device. We use those in Chrome OS, but as far as I can tell, it's very uncommon in the industry, so probably not something you need to worry about for your own application. Audio accessories are even more rarely used. Those are analog audio devices. Almost everyone uses digital converters, so you can probably just disregard any of those states when you're scoping out what it is that you want to cover support for. And then the last thing you might notice is in the dual role diagrams, there are tri-states. And you can ask yourself like whether the tri-states make sense or are something you need to use at all for your application. And the answer is probably not. It's mostly useful if you're a dual role port partner and you're interacting with things that don't use PD, which is very uncommon in the ecosystem nowadays. Nearly everything that uses USB-C will also be using power delivery. So now that we've got our power role settled, we're gonna talk about data roles. One question that comes up as you're filling out your capabilities, your source or your sync capabilities is am I dual role data? There's a flag you've got to set in there to say I'm a dual role data device. What does that mean? So it's a very easy answer. If you can act as both a host and a device, if you've got modes for both of those, that's a straightforward yes, I'm definitely dual role data. That's how I roll. But there's also some subtleties here. You're actually technically a dual role data device as long as you can use a data role swap message, which is one of our power delivery messages we use to change our data role with the port partner. So you can use data role swap messages because you like to be a non-default combination of things like if you're charging, but you also want to be the data host, you want to be sync DFP, you'll need a data role swap and that technically makes you a dual role data device. You can also encounter this if you have a preferred data role. So if you have a preferred role for UFP or for DFP and you're also dual role power, you end up needing to declare yourself as dual role data in order to get into your preferred data role. Though I will note, while we're talking about swapping around data roles to what role you want to have, partners are allowed to reject your proposal to data role swap into the role you want. So just be aware of that as you test and as you think through errors situations that can happen with customers plugging things in. Is that even though you want to be a sync DFP, you might not always get to be a sync DFP. And so just make sure you've got that thought through and supported however you need to. So we've covered power role, data role. Up next is VECON. And one of the questions is, do I need to source VECON? Do I even need to care about VECON? Like maybe what my application is, doesn't particularly need to rely on cables or consider cables. Like, do I actually have to do this? And the type C specification has an answer for you here. It has a table in chapter four that you can reference that just has a, it's called VECON requirement summary. And it's gonna let you know when it is that you're required to be able to source VECON. So if you can't supply more than three amps of current and you have no support for anything above USB 2.0 basically, then you don't have to source VECON. You're off the hook. If you're some kind of low power charger or well up to 60 watt charger, life can be good for you and you don't need to source VECON. If you support USB 3.0 and higher or if you need more than five amps that you're going to be sourcing out, then you are required to source VECON. And the ranges you need will be in the table. They're anywhere from 100 millivolts to one and a half watts depending on the applications you need to be supporting. And then syncs pretty much only need to source VECON if they need to probe the cable or if they need to tell the cable that it needs to enter a mode for complex mode entries like Thunderbolt, like USB 4. And then once you're sourcing VECON, you might ask yourself like, okay, I've probed the cable. Like can I just turn this off now? And the answer is yes. The spec does have allowances for you to not source VECON continuously. So if your eMarker reports that it doesn't need VECON, there's a specific little field within its discover identity response where it can say, hey, VECON is not something I really need. I can live without it. Then you're off the hook. You can turn VECON off after that point. If no RA is detected. So if you remember the presentation from last year, your cable is going to present an RA on it. If it has an eMark cable, if you don't detect that RA is there, you're allowed to turn VECON off as well. If the cable eMarker doesn't reply to discover identity VDMs, the power delivery specification defines a timer and a number of reattempts to discover the identity on the cable. If you exhaust those and absolutely nothing has come back, you're allowed to turn VECON off and just assume the cable has nothing to tell you about. I should note for all of these cases, you're still gonna be considered the VECON source if any swaps come up or if any other spec type things come up that require knowing who the VECON source is. So even if you have turned your VECON off, your role is still VECON source. So you should just always keep that in mind for interrupt issues with port partners. So we've covered all three of the roles and you're looking at your device and you're kind of asking yourself, do I need the power delivery part? Like this type C spec has a lot. Does it have everything that I need? Maybe I don't actually need the power delivery spec. And the answer is maybe. So if you're happy with your default roles, if you wanna be a source DFP or a sync UFP, if anything more than 15 Watts just sounds like an absurd amount of power to you, then you may not need power delivery support. You may actually just be fine running with type C support only. But you will want power delivery support if you want more than 15 Watts. If you want any kind of non-default role combinations, if you want alternate modes, really fun features like power button transmission, they have messages to allow docs to transmit their power button statuses up to the hosts. So all of those types of things, you will want power delivery support because it has a lot of features you can take advantage of. And then once you put in your power delivery support, you may be looking at the specification and say, okay, there's a lot here. There's control messages. There's data message. There are extended messages. And which of these do I actually need to worry about? And that's where you reference chapter six as a section called message applicability. And the message applicability table, they're gonna be what you really need for these things. So in it, it will have a series of tables just like this one that we've pulled a snippet out of that tell you what you need to be able to transmit and receive for your particular role. It separates it out by power role, but then also cables and VPDs, which are not super commonly used accessory that are defined in the type C specification. But so you can take a look at the message applicability table. These are for transmitted messages. And so you'll see we've got get country info, this sync capabilities, battery status. We'll use different symbols on the table to say things like we'll look at sync capabilities first. And then we need not applicable. So of course sources don't have to report a sync capability. The sync has N, which is normative. So syncs and dual role sources have to always report a sync capability. And then you're gonna notice a lot of these statuses have things like N footnote, ON footnote, or CN footnote. So O is optional, CN's conditional normative, N is normative, but then the footnote means there's tricky parts to it. And all of those, you just look at the bottom of the table and try and follow it as best as you can. So you'll notice here, like get country info is conditional normative, but it depends on the countries you're going to be selling in and interacting with. The BIST message makes you go to the subsection on BIST messages to understand it more. Battery status is only required if you contain a battery. So you can use these tables to kind of build up a sense of what the minimum things are that are expected from your product in order to interact well with other power delivery products. And so that brings us to the end of the specifications and I'll hand it over to Sam to talk about the practical applications. Hello everybody. Today I'll present how the Zephyr USB Type-C subsystem can be used to create a USB Type-C application. From the point of view of the subsystem, said application is considered a Device Policy Manager or DPM. There are only three steps needed to create a basic USB Type-C device. One, create a Device-Tree USB-C connector node. Two, create an application-specific data structure. And three, define a few policy callbacks. Each USB Type-C connector has many properties associated with it. And the properties are configured in a Device-Tree node. This is a logical view of how Zephyr views a USB Type-C port. The three main parts are the TCP-C, V-Bus and USB Type-C connector. Before a subsystem can be used, Zephyr must know the properties of each Type-C port. Here is the logical view of the USB Type-C port shown alongside its Device-Tree representation. The Device-Tree includes the minimum set of parameters needed to implement a seek device. I'll cover each parameter in the following slides. The compatible parameter informs Zephyr that this is a Type-C connector. Each USB Type-C port has a port controller associated with it. The TCP-C parameter in the Device-Tree points to a driver that Zephyr USB Type-C subsystem uses to interface with the port controller. The subsystem uses the TCP-C to get connection status, send messages and to receive messages. Each USB Type-C port syncs or sources V-Bus, and in our case, it syncs to V-Bus. The V-Bus parameter in the Device-Tree points to a driver that Zephyr USB Type-C subsystem uses to measure V-Bus. If this was a source port, the driver would also be used to control V-Bus. Now we move on to the application-specific data structure. Your application should check the Power-Row parameter in the Device-Tree to verify that this Type-C port is supported. In the code, this is done by comparing the Power-Row parameter to the TC-Row sync macro. The sync PDOs parameter in the Device-Tree should be extracted and saved in the data structure. It's used as covered in later slides. Because this is a sync device, the application, at some point, will receive the source capabilities, which should be stored in the data structure. This, too, is covered on later slides. Finally, we move on to the policy callbacks. These are the minimum policy callbacks needed to get a sync device up and running. I'll go over each in the following slides. First, I'll show a sequence diagram that demonstrates how Zephyr uses the callbacks and then I'll present code snippets to show how the callbacks are implemented. Power delivery negotiations start with the source sending its capabilities to the sync. In one, the source capabilities are sent to the Zephyr USB Type-C sync subsystem. In two, Zephyr sends them to the application via the policy callback setSourceCAP function. When the subsystem calls this function, the application should store the capabilities in the sourceCAP's variable of the data structure shown in the sample code. The source capabilities contain a list of power delivery objects, PDOs, that describe the power level supported by the source. The first PDO is always five votes and the following could be a combination of nine votes, 12 votes, 15 votes, or 20 votes. The negotiation continues when Zephyr requests one of the capabilities from the source. In four, the subsystem gets the requested data object, RDO, from the application via the policy callback getRDO function so that it can build a request message. And in five, the request message is sent to the source. The RDO indicates the current and which PDO the sync needs to operate correctly. In the sample code, the sync needs 100 milliamps and selects the PDO at object position one of the source capabilities, which is five votes. The subsystem uses this function to return the RDO. The source sends its response to the previous request. This could be an accept, reject, or wait message. At seven, in the diagram, the accept message is sent and at eight, the application is notified of the accept message. When the policy callback notified is called, the subsystem uses this function to notify the application of events occurring in the USB type C subsystem. In the code, the application is notified of the accept message. Finally, when the source has sent VBUS to the requested voltage, it sends the power supply ready message. In 10, PSReady message is sent and at 11, the USB type C subsystem notifies the application that the power supply is ready by calling the policy callback notify function. As stated earlier, this function is used to notify the application of events occurring in the USB type C subsystem. In the code, the application is notified of the reception of a PSReady message by sending a transition power supply message. At this point, the application can start operating at the requested power level. At some point after power negotiation, the source could send a get sync caps message. In the diagram at one, the get sync caps message is sent. In two, Zephyr gets the sync capabilities from the application. And at four, those capabilities are sent to the source. The subsystem uses this function to get the sync capabilities from the application, which were stored in the sync caps member of the data structure. Other messages could be sent from the source that requests the Zephyr USB type C subsystem to take a certain action. But Zephyr must check with the application before the action can be taken. In the diagram at one, the source sends a power row swap message. And at two, Zephyr checks if the application supports a power row swap by calling the policy callback check function. Since we are a sync only device, we can't swap to a source. So at four, Zephyr sends a reject message to the source. The code uses, sorry, the subsystem uses this function to check if certain actions can be performed. In the code, the power row swap message from the source is rejected when the function returns false. After the five callbacks are implemented, they must be registered with the USB type C subsystem by using the Listic API. The application data structure must be registered with the USB type C subsystem using the USB set DPM data API and the data structure can be retrieved from the subsystem by calling the USB set DPM, sorry, get DPM data API. Finally, USB C start must be called to start the USB type C subsystem. Zephyr currently provides two USB type C samples, a sync device and a source device. The sync device was outlined in this presentation, but the sample should be consulted for details. Two development boards are currently supported that can be used for testing. The B-G747E board can only be used for sync development, but the STM32G081B board can be used for sync and source development. See the Zephyr supported boards for details. And that concludes the presentation.