USB Power Delivery === ![image](https://hackmd.io/_uploads/H1zVTR57kx.png) ### USB PD1.0(typeA/B) 使用VBUS傳輸PD protocol, 不影響 D+/D-的傳輸 ### USB PD2.0(type C) VBUS support 5/9/15/20V type C 透過 CC (Channel Configure) 傳輸PD protocol, 支持 `DRP (dual role port)` ### USB PD3.0(type C) Added PPS(programmable power supply) ``` USB Type-C(Data、Power) Data: DFP, DownStream Facing Port -相當於Host UFP, UpStream Facing Port -相當於Device DRD, Dual Role Data -兩者可切換 Power: Source -提供電 Sink -接收電 DRP -兩者可切換 ``` PD protocol --- ![image](https://hackmd.io/_uploads/H1KTaxiQkx.png =90%x) #### Source 行為 1. CC Pin 偵測 * Source 會在其 CC 引腳上監測電壓,尋找 Rd(下拉電阻)的存在,如果偵測到 Rd,表示連接到一個 Sink。 2. VBUS 輸出 * 當 CC 偵測到 Sink 後,Source 在 VBUS 引腳上輸出 5V。 3. 當 Source 偵測到 Rd 後,它會將自己預設為 DFP。 #### Sink 行為 1. Sink 會檢測其 VBUS 是否有 5V * 如果有 5V,表示已經連接到一個 Source 3. 偵測到 VBUS 後,Sink 預設為 UFP 接著Source 會開始第一次的PD協議,直至Sink收到`PS_Ready`後,Source 和 Sink 即完成初步的PD協議 ``` DRP會有Rd,Rp電阻, 一直切換 ``` ### SOP* Communication ![image](https://hackmd.io/_uploads/HyQZ-giXJl.png =50%x) 透過 CC 線溝通,都會使用CRC來驗證 #### SOP * 用於 Source 和 Sink 之間的基本溝通 * 主要承載電力協商和狀態報告 * 常見消息包括: * Source Capabilities:Source 向 Sink 宣告可提供的電壓/電流。 * Request:Sink 向 Source 請求所需的電壓/電流。 * Accept/Reject:Source 是否接受 Sink 的請求。 #### SOP' * 用於與電纜插頭(Cable Plug)的溝通。 * 目的: * 驗證電纜的類型和能力(例如支持的電流和速率)。 * 協調帶有電子標籤的電纜進行角色切換。 * 常見消息: * Discover Identity:檢測電纜是否支持 USB PD 和其他協議。 #### SOP'' * 用途類似 SOP’,但針對另一側的插頭 ### Power Role Swap(VBus) ![image](https://hackmd.io/_uploads/r1zEwWimyx.png =60%x) * 如果雙方都是 DRP 且不具備 Try.SRC 或 Try.SNK 的特性,`隨機一方成為 Source`,另一方則為 Sink。 * 可能 Source 和 Sink 角色並不符合設備的偏好或需求,通常會根據當前的電力狀態(如Source/Sink Capability或有無External Power)來決定要不要發起 Power Role Swap(雙方皆可)。 * Power Role Swap 只改變誰提供 VBus的方向,不會改變 Data 和 VCONN 的方向。 ### VCONN Swap(Cable Power) ![image](https://hackmd.io/_uploads/B1lKvZjmyl.png =60%x) * VCONN(Cable Power) 是 USB Type-C 規範中為 電子標籤電纜(e-Marker Cable) 提供電力的專用通道。 * 它利用 USB Type-C 的 `未使用的 CC Pin` 傳輸電力,為電纜內部的電子元件供電。 * ### Data Role Swap ![image](https://hackmd.io/_uploads/r18ZZMjm1l.png =60%x) * DFP 和 UFP 可以通過 Data Role Swap 交換角色 * 若收到DR_Swap Requst的當下,DFP/UFP已進入任一Active Mode,需先執行Hard Reset,使雙方離開Active Mode,再重新PD 協議,若Cable也在Active Mode時,則Cable也需先離開Active Mode。 * 對於VBus、VCONN的影響 * 若雙方已進入Active Mode 所以在DR Swap前需要進行Hard Reset 的動作。 * 否則,VBus 、VCONN在DR Swap的過程中是不會中斷的,亦即VBus 會維持供電,CC上的Rp、Rd也不會調動。 ### Fast Role Swap ![image](https://hackmd.io/_uploads/ByONmMo7Jx.png =50%x) Host、Dock、Device的連接狀態,Dock作為Host 和Device一開始的Source供電來源(Initial Source),但Dock本身的電源突然斷了,此時為了維持Device的連接及資料的傳輸,Host和dock之間便會進行FR Swap的動作,使Host快速地成為Source。 * 只會從Sink發出,可以透過 ==Fixed Supply PDO – Sink== 來確認有沒有support FRSwap --- Protocol Layer --- > refer 6.2.1 Message Construction > 定義了三種類型的消息: <details> <summary>Control Messages </summary> ``` 短消息,主要用於管理消息流或交換不需要附加數據的消息。 ex: GoodCRC Reject Accept Ping Soft Reset ``` </details> <details> <summary>Data Messages </summary> ``` 用於在 Port Partners 之間交換信息的消息。 包含數據部分,數據長度從 48 位(6 字節) 到 240 位(30 字節) 不等。 ex: Source Capabilities Request Battery Status Alert ``` </details> <details> <summary>Extended Message </summary> ``` 用於交換大於數據消息所允許的信息,支持更高數據量的通信。 消息長度最多為 MaxExtendedMsgLen(通常為 260 字節)。 ex: Battery Capabilities Security Request Firmware Update Request ``` </details> ### Message Construction USB PD Message composed of a `Message Header` and a variable length (including zero) `data portion` * Control Messages ![image](https://hackmd.io/_uploads/r1k8Ol271g.png =80%x) * Data Messages ![image](https://hackmd.io/_uploads/SyxMFehQ1g.png =80%x) * Extended Message ![image](https://hackmd.io/_uploads/HJrNtxn7Jg.png =80%x) #### Message Header refer 6.2.1.1 Message Header 6.3, 6.4, 6.5, ![image](https://hackmd.io/_uploads/ByISCghX1e.png =80%x) ![image](https://hackmd.io/_uploads/H1-Ny-3Xye.png =80%x) ![image](https://hackmd.io/_uploads/rJ04MBGaxe.png) ![image](https://hackmd.io/_uploads/SktfzBfTxe.png) ![image](https://hackmd.io/_uploads/Hy4qGrMagg.png) Physical Layer --- ![image](https://hackmd.io/_uploads/H1fRYG27kx.png =80%x) 將Protocol Layer中的Message 轉為可以通過 CC(Configuration Channel)Pin 傳輸的信號 * Data -> CC * CC -> Data * CRC 校驗 #### Packet Format > ref 5.6 Packet Format ![image](https://hackmd.io/_uploads/Byw2nMnm1l.png =80%x) * SOP*決定是不是跟Cable溝通 * SOP * SOP' * SOP'' --- Display Port --- 在Alternate Mode(Alt Mode) 下,USB-C 的 RX/TX 可以輸出 DisplayPort信號 | 功能 | Type-C 規範 | PD 規範 | |------------------|----------------------------------------------------------------------------|----------------------------------------------------------------------------------------| | Alt Mode 定義 | 定義 Alternate Mode 的框架和信號分配方式。 | 不涉及框架定義,但負責啟動和管理模式進入。 | | 信號通路 | 規範如何重新分配 USB-C 的 RX/TX 通道。 | 不涉及信號線分配。 | | 模式協商與啟用 | 不定義模式協商過程。 | 定義使用 USB PD 消息協商模式(如 Discover Modes)。 | ### 進入Alt Mode (USB PD spec) > ref > 6.4.4 Vendor Defined Message >C. VDM Command Examples ![image](https://hackmd.io/_uploads/By8simh7Je.png=80%x) 1. DFP會先發出`Discover Identity` Request訊息來確認UFP的身份和能力,在UFP回覆的Discover Identity ACK訊息中有個Modal Operation Supported的欄位,用來表示UFP是否支援Alternate Modes。 2. Discover階段可以分成兩部分,第一階段DFP會先發出`Discover SVID` Request訊息來確認UFP支援多少Alternate Modes。SVID包含由協會制定的SID和協會所提供各家廠商的VID,常見的SVID有0x8087 (Thunderbolt mode)、0xFF01 (Displayport mode)。確認UFP回覆的SVID後,第二階段DFP會發出`Discover Modes`訊息,其中包含DFP支援的SVID,目的是為了確認雙方都有支援這些Mode,UFP會以Discover Modes Ack訊息來表示有支援。 3. DFP發出`Enter Mode`來告知UFP要切換的Mode,確認到UFP的Enter Modes Ack訊息後,雙方切換成溝通好的Mode。直到要結束工作模式,DFP會以`Exit Mode`訊息來告知UFP。 --- Ref --- https://www.graniteriverlabs.com/zh-tw/technical-blog/application-notes-usbc-role-swap