Fork me on GitHub
侧边栏

四、USB PD协议层之消息

先来看看协议层主要做什么事情:
本章描述了USB电源传输规范协议层的要求,包括:

  • 如何构建和使用消息的细节。
  • 计时器和超时值的使用。
  • 使用消息和重试计数器。
  • 复位操作。
  • 错误处理。
  • 状态下的行为。(状态机)

1、Message

先来了解一下Message,本规范定义了三种类型的Message:

  • 控制消息是比较短的并且用来管理两个端口之间的信息流或者不需要额外数据的信息交换,控制消息是16bit长度

  • 数据消息是用来在两个端口之间交换信息的,数据消息的长度范围在48-240bit

    • 有三种类型的数据消息
      • 用来展示能力和协商电力
      • 用来BIST
      • 供应商定义的
  • 扩展消息被用来在两个端口之间交换信息,数据长度最大为260bit

    • 有几种类型的扩展消息
      • 用于Source和电池信息
      • 用于安全
      • 用于固件更新
      • 用于供应商定义

2、Message构建

所有消息应由消息头可变长度(包括零)数据部分组成。消息源自协议层并传递到物理层,或者它由物理层接收并传递到协议层。
下图说明了一个控制消息作为一帧数据包的一部分,显示了由协议层和物理层提供的部分。

下图说明了一个数据消息作为一帧数据包的一部分,显示了由协议层和物理层提供的部分。

下图说明了一个扩展消息作为一帧数据包的一部分,显示了由协议层和物理层提供的部分。

3、Message Header

如下表“消息头”所定义。消息头包含有关消息和PD端口功能的基本信息。

1)Extended

1个bit,为1是扩展消息,为0是控制消息或者数据消息

2)Number of Data Objects

当Extended为0,此字段表示为32bit数据对象个数,此字段为0,消息是控制消息,非0,消息是数据消息。

当Extended和Chunked都为1,此字段表示包括扩展头在内的32bit数据对象个数。

当Extended为1,Chunked为0,此字段被保留,数据长度由扩展消息头中的Data size决定。

关于chunked字段和扩展头后面会说到。

3)Message ID

此字段的值由消息的发起者维护的一个滚动计数器生成,由于软复位或硬复位,消息计数器应在开机时初始化为零。MessageIDCounter应在成功接收到消息时递增,如收到GoodCRC消息。

4)Port Power Role / Cable Plug

此字段表示当前端口的电源角色
0b:sink
1b:source

在电源角色交换序列期间(PR_swap),对于初始Source端口,PS_RDY消息中的端口电源角色字段应设置为Sink,指示初始Source的电源已关闭

在电源角色交换序列期间,对于初始Sink端口,在接收到来自初始Source的PS_RDY消息后,策略引擎发送的消息的端口电源角色字段应设置为Source

在快速角色交换序列中(FR_swap),对于初始Source端口,在PS_RDY中消息端口电源角色字段应设置为Sink,表明VBUS不是由初始Source驱动的,并且在vSafe5V范围内。

在快速角色交换序列期间,对于初始Sink端口,策略引擎在从初始Source接收到PS_RDY消息后发送的消息,端口电源角色字段应设置为Source。

注意,由初始Sink发出的GoodCrC对初始Source发出的PS_RDY做出回复,将端口电源角色字段设置为Sink因为这是由协议层发起的,后续消息由策略引擎发起,例如发送来指示VBUS已经准备好的PS_RDY消息,将有端口电源角色字段设置为Source。

接收到的消息的端口电源角色字段不应由接收方验证,如果它不正确,也不应该导致软重置、硬重置或错误恢复。

5)Specification Revision

此字段的值应该是下列之一(11b除外):

  • 00b –Revision 1.0
  • 01b –Revision 2.0
  • 10b – Revision 3.0
  • 11b – _Reserved, Shall Not _be used.

在**GoodCRC消息中 此字段没有任何意义 **
在协商期间版本的协同可以参考下表:

6)Port Data Role

此字段表示端口的当前数据角色:
0b:UFP
1b:DFP

如果端口接收到的消息中的端口数据角色字段设置为与其当前数据角色相同的数据角色,除GoodCRC消息外,应执行错误恢复操作。

对于USBType-C®端口,端口数据角色在硬重置后的连接中,端口角色字段应设置的默认值:

Rd决定端口为0b,
Rp决定端口为1b。

如果端口支持USB通信,在连接Source端口默认为DFP,Sink端口默认为UFP。

7)Message Type

此字段表示为将要发送消息的类型,要完全解码消息类型,首先要检查并确定Number of Data Objects字段是控制消息还是数据消息。

4、Extended Message Header

每个扩展消息都应该包含一个跟在Message Header之后的扩展消息头。
扩展消息头用来支持包含Data Size大小的数据块的扩展消息,也可以作为单个消息或者一系列的块发送,当数据块作为一系列的块发送,系列中的每个块除了最后一个都应该包含块能承受的最大字节数,最后一个块应包含剩余数据部分并做4字节填充。

1)Chunked

在Source_Capabilities Message和Request_ _Message端口应该使用未分块的扩展消息支持的字段来决定在一条未分块的扩展消息中是否发Data Size>MaxExtendedMsgLegacyLen字节的消息

当任何一个端口仅支持分块扩展消息时:

  1. 每个扩展消息的Chunked字段设置为1
  2. Data Size > MaxExtendedMsgLegacyLen的扩展消息应在端口之间分组传输
  3. 消息头中的Number of Data Objects应表示消息中 填充到4字节边界并包含扩展头作为第一个数据对象的一部分 的数据对象的数量(也就是从扩展头开始,4字节作为一个数据对象)

当两个端口都支持未分块的扩展消息时:

  1. 每个扩展消息的Chunked字段设置为0
  2. 每个扩展消息应该在两个端口之间进行不分块的传输
  3. 消息头中的Number of Data Objects字段保留,不使用

向电缆插头发送扩展信息时,VCONN 信号源只能发送分块信息。电缆插头应始终以分块方式发送Data Size>MaxExtendedMsgLegacyLen 的扩展消息,并应在每个扩展消息中将Chunked设置为 1。

2)Chunked Number

只有当Chunked设置为 1 时,Chunked Number字段才在消息中有效。如果Chunked设置为 0,则Chunked Number字段也应设置为0。

根据消息是请求数据还是返回请求的数据块,Chunked Number字段的使用方式有所不同:

  1. 在数据请求中,Chunked Number字段表示所请求数据块的编号。请求方 只能将该字段设置为系列中下一个数据块的编号(上一个接收到的数据块之后的下一个数据块)。
  2. 在请求的数据块中,Chunked Number字段表示返回的数据块的编号。系列中每个数据块的数据块编号应从 0 开始,每个数据块递增 1 个,最多不超过 9 个,即总共 10 个数据块。最大为 9,即总共 10 个数据块。

3)Request Chunk

当Chunked为1,此字段仅被用作扩展消息的分块传输,对于扩展消息的未分块传输,应在没有请求/响应机制的情况下发送和接收消息

Request Chunk位应设置为1,以指示这是对数据块的请求,并且应设置为0以指示这是包含Chunk的Chunk响应。除了Chunk zero,请求的数据块只能作为块对该块的相应请求的块响应返回,块请求和块响应应该包含相同的Message Type字段值,当Request Chunk位设置为1时,Data Size字段应为零。

4)Data Size

此字段应指示返回的数据块中总共有多少字节的数据。总计消息中的数据字节数不得超MaxExtendedMsgLen。

如果Data Size字段 < MaxExtendedMsgLegacyLen并且设置了Chunked位,则数据包有效载荷应使用零(0x00)填充到下一个4字节的数据对象边界。(保证数据对象为4字节,不足4字节补0)

5)扩展消息示例

下面举例说明扩展消息分块和未分块的区别,示例使用数据大小为7字节的Security_Request消息,该消息
由数据大小为30字节的Security_Response消息响应
下图显示了总线上的字节顺序,以及此中没有填充的事实案例“Number of Data Objects”字段的值为0,因为它在Chunked为0时被保留。Data Size字段指示当Chunked位设置为0时扩展消息的长度,在这种情况下为7字节。这种为未分块传输

下面我们说明分块传输,下图为一个分块传输的块响应,可以看到Data size为30,已经超过MaxExtendedMsgLegacyLen(26字节),所以之传输最大26字节,剩余4个字节,下次传输

传输剩下的4个字节

posted @ 2024-12-29 14:06  yooooooo  阅读(189)  评论(0)    收藏  举报