[参考译文] TPS25750：在不同的无电池模式后应用低二进制贴片

尊敬的 Martin：

请查看我对您的问题的回答：

1.)  HighVoltageNegotiation 指出不建议将其用于能够以5V 电压启动的系统-为什么会这样？ 在此模式下发送补丁后、重新协商是否会降低电压？

- NegotiateHighVoltage 是一种电量耗尽的电池 PD 启动模式、此模式允许从 Type-C 端口向系统提供20V 电压、而无需从外部加载任何固件。 这是为了允许系统只能从高压启动、因为在电池电量耗尽的情况下、系统在 PD 启动之前没有电源。 如果系统可以从5V 启动、则不需要此模式、而且如果系统不能正常承受20V 电压、系统可能会因在断电时接收到20V 输入而损坏。

2.)  AlwaysEnableSink -发送补丁后是否缺少不重新协商指定功率级别的内容？

-当 PD 从 AlwaysEnableSink 模式在电池电量耗尽时引导时, PD 将始终为初始5V 隐式非 PD 合约启用受电路径。  我需要向我的团队核实加载配置后会发生什么情况。 加载配置后、PD 合约应能够在不断开的情况下协商。

3.)   如何配置 TPS 固件(在在线 GUI 上)以执行以下操作：拉电流：固定15W、灌电流：任何功率级别/电压、优先选择尽可能高的功率？ 我已经连接了我们的当前配置、该配置尝试通过添加多个灌电流 PDO 来实现它-那是办法吗？

-我没有看到你的附加项目配置文件,只有 Linux 驱动程序。 如果您有多个灌电流 PDO、则 PD 应始终请求拉电流侧和灌电流侧之间匹配的最高 PDO。 在这种情况下、如果电源侧固定为15W、则可以协商的唯一 PDO 为5V。 此 PDO 的最大电流将为3A、因此总电流为15W。 如果供电方广播15W PDO 和27W PDO、则受电方侧的 TPS25750在具有9V 受电 PDO 的情况下将请求27W PDO。 如果接收端没有9V 接收端 PDO、则它仍将请求15W 协议。

-如果你给我发送你的项目 json 文件,我可以检查配置。

此致！

亚历克斯

你好、Alex。

感谢您的响应-因此我认为 AlwaysEnableSink 可能是我们的最佳选择、因为这不会导致加载补丁后复位。

在 AlwaysEnableSink 下、我们遇到了与以下内容类似的问题： https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1237206/tps25750-pd-negotiation-not-triggered-after-loading-low-region-binary

我们加载以下补丁(或任何其他补丁、例如简单的45W)、但充电器不会使电压/功率达到45W、直到插拔 USB-C (或多次重新加载内核驱动程序-在工作时似乎是随机的/零星的)。

你有什么想法吗？ 在加载补丁后是否有任何其他情况通知 TPS 以执行后续的 PD？

我在下面附上了.json。 来澄清我的3。) 问题：我想构建一个 FW、该 FW 在用作电源时可提供15W (5Vx3A)、在灌电流时应"获取充电器可提供的最高功率"。 以下配置适合吗？

{"questionnaire":{"version":"7.0.4.5","answers":[1,0,0,1,3,3,1,null,1,null,null,null,null,null,null],"options":{},"configID":"0000","vendorID":"0000"},"configuration":{"data":{"selected_ace":[{"register":6,"data":[0,0,0,0,0,0,0,0]},{"register":22,"data":[10,48,48,77,0,0,0,0,0,0,3]},{"register":50,"data":[1,168,42,44,145,1,38,44,209,2,0,44,177,4,0,244,65,6,0,0,0,0,0,0,0,0,0,0,0,0,0]},{"register":51,"data":[4,44,145,1,0,44,209,2,0,180,176,4,0,225,64,6,0,69,65,6,0,0,0,0,0,0,0,0,0]},{"register":92,"data":[0,12,0,0,0,0,0,0,0,16,0,0,0,4,0,0,0,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,8,0,0,0,0,0,0,0,0,0,0,0,0,0,3,0]},{"register":117,"data":[0,0,0,0]}]}}}

此致、

马丁·彼得林

尊敬的 Martin：

TPS25750在电池电量耗尽时从 AlwaysEnableSink 模式启动后、连接到充电器以广播其 PD 供电能力并开始协商。 PD 合约中的初始 PD 协商始终来自供电方、在本例中即充电器。 初始启动后不应断开并重新连接。 如果您有 PD 分析器(如 EZ-TotalPhase 或 PD)，则可以读取 PD 流量并查看正在进行什么消息传送。

如果充电器在连接后不够长的时间内未发送其供电能力、则可能会在引导后导致此问题。 如果您可以获得任何类型的 PD 分析器、这将帮助我们了解这是否确实发生了情况。 要解决此问题、您需要向 PD 发送 I2C 命令以向发送"Get Source Capabilities "消息并将其发送到远端充电器、从而手动重新触发 PD 协商。

您的项目配置看起来正常。 PD 将始终从与其配置的受电方 PDO 功能相匹配的充电器请求最高广播拉电流 PDO 能力。 您还可以将灌电流 PDO 2-4替换为单个可变灌电流 PDO。 但是、这不允许您为每个电压电平设置不同的工作电流。

此致！

亚历克斯

你好、Alex。

感谢您提供的所有信息-我们已经查看并确定了 TPS (接收器)<-> PD 砖型(SRC)通信(使用 Power-Z 分析器)的问题。

如果我们为固件添加补丁(使用前面提到的驱动程序： https://www.uwsg.indiana.edu/hypermail/linux/kernel/2309.3/06930.html)、在 PD 砖型(SRC)开始发送其功能的7秒之前、它就成功地握手、一切正常。

如果我们修补 FW、7秒后 PD 砖型(SRC)开始发送其功能、则无法正常工作-发出"Receive Hard Reset"(接收硬复位)消息、此时 PD 砖型(SRC)似乎掉电且/或直到重新连接事件后才进行协商。

(请注意、图像来自不同的 PD 砖型、但以相同的方式重新测试了这两个模块、结果是相同的)

关于如何处理此问题、Alex 是否有任何想法/想法？

此致、

马丁·彼得林

尊敬的 Martin：

PD 充电器模块(SRC)可能具有一个用于发送源功能的计时器和计数器、远端没有响应、之后它会退出并硬复位以重新启动连接。  

我相信在你们用例中发生的情况是、系统板和 PD 充电器砖之间的 Type-C 隐式连接会在连接时立即建立、之后会启用电源路径、并且您的系统引导以添加 TPS25750。 同时、PD 充电器模块会尝试通过发送供电方能力消息来与系统板上的 TPS25750建立 PD 显式连接。 但是、在 TPS25750能够打补丁并加载配置之前、PD 充电器砖会停止尝试获取供电能力消息、因此从 TPS2552的角度来看、不会重新协商电源合约。 在修补配置之前、PD 只能执行 Type-C 隐式合约、此时尚未启用 PD。

这是一个时序问题、因此当您在7秒之前修补 TPS25750时就没有问题、但是如果您在7秒之后修补 TPS25750、配置加载太晚并且 TPS25750永远无法看到 PD 充电器模块的供电能力。 根据 PD 规范、PD 电源充电器需要在连接时发送至少50条电源能力消息、每个消息的间隔为100-200ms。 在低端、这将是总共5s、在高端、这将是总共10s。 从这些计算来看、PD 充电器似乎准确地遵循了规范。

我建议在系统启动后尽快为 TPS25750添加补丁。 如果可能、我建议尝试在连接的5s 内打补丁。

此致！

亚历克斯

您好，Alex

>但是、在 TPS25750能够修补并加载配置之前、PD 充电器砖将停止尝试供电能力消息、从而不会从 TPS25sco 的角度重新协商电源协议。 在修补配置之前、PD 只能执行 Type-C 隐式合约、此时尚未启用 PD。

只有一件事、砖型(或笔记本电脑等) 请勿"超时并导致重置"。 我们也执行了这些测试、其中驱动程序从未加载(TPS 未打补丁)的时间更长(例如几分钟)、而砖型继续供电、而不做任何更改。

因此、它只是在驱动程序执行并加载补丁(或者可能是驱动程序稍后执行的其他一些 OP)之后才会发生这种"接收硬复位"

>我建议在系统启动后尽快为 TPS25750打补丁。 如果可能、我建议尝试在连接的5s 内打补丁。

同意、但由于系统启动所需的时间、我们不太可能很快就能做到这一点。 我们将尝试此作为第一次尝试、但不确定届时我们是否能够做到。 我们将在没有 EEPROM 的情况下运行。 如果这成为实际问题、我们也许能够重新设计/w EEPROM、然后在首次引导时执行 EEPROM 闪存或者类似的操作。 但是、如果可能、我们最好解决它。

如果我们有一个"显式开机按钮"来引导系统、也会出现同样的问题。 在这种情况下、USB-C 供电"电池电量耗尽"与系统启动和修补 TPS 之间可能需要几分钟的时间。

>根据 PD 规范、PD 电源充电器需要在连接时发送至少50条电源能力消息、每个消息的间隔为100-200ms。 在低端、这将是总共5s、在高端、这将是总共10s。 从这些计算来看、PD 充电器似乎准确地遵循了规范。

这是伟大的知道的根本原因,这种时间-谢谢!

——

因此,从我们的角度来看,我们在想什么可能是"重新请求"发送 SRC 功能的最佳方式,这样加载补丁后,TPS 可以做正确的事情。
我们尝试了以下方法：
```

```

在加载补丁之前和/或之后、但我们得到 TPS 的`EPERM -1`"Task Rejected"响应。

对于如何处理此问题还有其他想法吗？

尊敬的 Martin：

如果充电器不发送、这种情况下的硬复位来自 TPS25750。 如果远端端口伙伴没有收到来自远端源的可启动 PD 协商的供电方能力广播消息、TPS25750将硬复位远端端口伙伴。 硬复位是一条 PD 消息、只有支持 PD 的器件才能理解该消息以复位连接。 这种情况下硬复位的目标是重新尝试 PD 协商过程。  

获取供电方能力 GSrC 是发送至 TPS25750以从连接的充电器请求供电方能力的正确命令。 使用您拥有的 PD 分析仪、您是否可以看到 TPS25750向充电器发送 Get_Source_Capabilities PD 消息？ 还是根本没有发送任何内容？ 如果您拥有此 GSrC 事务的 PD 日志并可以将其发送给我、我可以看一下。

将 Get_Source_Capabilities PD 消息发送到远端时、只要它支持供电方电源角色、就会使用其供电方能力进行响应。

此致！

亚历克斯

您好，Alex

>如果充电器不发送、这种情况下的硬复位来自 TPS25750。 如果远端端口伙伴没有收到来自远端源的可启动 PD 协商的供电方能力广播消息、TPS25750将硬复位远端端口伙伴。 硬复位是一条 PD 消息、只有支持 PD 的器件才能理解该消息以复位连接。 这种情况下硬复位的目标是重新尝试 PD 协商过程。  

我明白了、这是很好的做法-我们可以调整这种与 TPS 的交互/修补、因为我们以某种方式使其首先重新请求来自充电器(SRC)的广播功能、而不是发送复位？ 或者、如果它发送了复位、以便实际响应新消息呢？

就像现在一样,它似乎发送了这个复位,充电器确实开始再次广播,但 TPS 似乎忽略了这些消息(+有一个功率损耗的问题,在这种情况下)。

>获取供电方能力 GSrC 是发送到 TPS25750以从连接的充电器请求供电方能力的正确命令。 使用您拥有的 PD 分析仪、您是否可以看到 TPS25750向充电器发送 Get_Source_Capabilities PD 消息？ 还是根本没有发送任何内容？ 如果您拥有此 GSrC 事务的 PD 日志并可以将其发送给我、我可以看一下。

我们将重试执行此操作、然后查看 PD 日志端是否有任何内容(例如、它被发送)。 如果没有发送到总线、需要查看的指针是什么？

此外、GSrC 是否是"重新请求能力广播"的正确命令？ 是否还有其他东西(除了硬复位被发送为植入性-似乎效果不佳)

此致、

马丁·彼得林

尊敬的 Martin：

如果在连接后未收到源电容器、则灌电流 PD 需要向远端源发送硬复位。PD 规范要求将硬复位发送到远端源。 由于规格中的定义、我们无法更改此值。

通过硬复位可以预期掉电。 硬复位将重新启动连接、这意味着远端源将被指示掉 VBUS、然后将其恢复。 这会导致灌电流侧的 TPS25750重新启动、因为系统处于无电池状态。 我认为、此处的问题似乎是为 TPS25750打补丁所需的时间。 每次 PD 启动时都会执行此修补、即在初始连接和每次后续硬复位时。 如果可以缩短修补前的时间，则可以解决此问题。

是的、GSrC 命令是请求重新广播远端源能力的正确命令。 此命令提示 TPS25750向远端发送 Get_Source_Capabilities PD 消息、该消息指示远端发送其供电方能力。 此序列完全是 CC 线路上的 PD 消息传递。

如果 TPS25750未将 Get_Source_Capabilities 消息发送到远端、请告诉我、我可以查看我们的代码以了解在哪些情况下会在内部拒绝该命令。

此致！

亚历克斯