[参考译文] LAUNCHXL-CC3235SF：功耗和传输问题

你（们）好  

添加更多信息、我们遇到了最坏的情况、即空闲连接电流（无数据传输）超过 10mA。

从下图可以看出、在前 14 秒内、CC3235 会在预期的 LSI 间隔 (1200mS) 期间唤醒、平均电流约为 865uA。 但是、在接下来的 10 秒内、3235 几乎始终处于唤醒状态、平均电流约为 10mA。 此外、我们还会放大这个 10 秒数据以供您参考。 如果传输数据、这种情况将更加严重。 我们还将此 NWP 日志附加在以下链接中、3235 与 AP 之间的距离约为 0.5 米。

NWP 日志

https://drive.google.com/file/d/1R_YBf7Nz_u5hWDwmAU46KqmV9Nrj4xsP/view?usp=sharing

BR

Trevor

您好、

乍一看、似乎连续错过了信标、因此信标跟踪机制被触发并移动到完全唤醒状态、以恢复信标接收。

最好是在空中查看信标（如果有监听器，则使用监听器）和/或获取 MAC 日志、而不是此处效率较低的 NWP 日志。

MAC 日志的记录方式与 NWP 日志的记录方式相同、只需使用另一个引脚 (PIN_60 而不是 PIN_62)。

此致、

Shlomi

尊敬的  Shlomi：  

我们还认为这与连续的信标丢失类似。  但我们不知道确切的原因。 我们尝试了三个 AP (D-Link、ASUS、TP-Link)、当 AP 的 DHCP 关闭时、也会出现同样的问题。

我们尝试检索 MAC 日志、但当前无法输出日志。 您能帮助我们检查以下设置是否有任何问题吗？  

下面的链接是 监听器 日志 (wlan.addr == 34：03：de：10：c0：b4)、您还能帮助检查吗？

https://drive.google.com/file/d/1LDu0Hi5NtQHiWZywI0LYU2vk0jpFCshj/view?usp=sharing

Trevor

BR

Trevor

您好、

观察监听器、AP 为其信标传输使用模式、这意味着它不是每 102.4mSec 传输一个稳定的信标、而是在+8mSec 传输、然后在–4mSec 和–4mSec 返回到电网。 这是循环的。

这种情况不太常见、但跟踪机制也应该处理它。

对于 MAC 记录器、您需要一些 ECO、因为 P60 记录器引脚与其中一个运算放大器相冲突。 您可以在原理图中看到。

因此、您需要执行以下操作：

• 断开 R111 和 C72
• 连接 R108

请参阅一些图片进行说明。

此致、

Shlomi

尊敬的  Shlomi：  

感谢您提供信息；我们现在可以检索 MAG 日志。 请参阅随附的文档。 您能帮助分析这个日志吗？ 此外、还会附加相应的电流图以供您参考。

e2e.ti.com/.../ti_2D00_switch.log

BR

Trevor

您好、

连接的日志似乎已损坏。

我只是想确保程序正常。

您需要按原样从 PIN_60 捕获二进制流、不做任何更改。

我使用 TeraTerm 的方式如下：

1. 打开终端仿真并配置以下各项：
   1. 波特率：921,600bps
   2. 8 位
   3. 无奇偶校验
   4. 1 个停止位
   5. 无流量控制
2. 将终端仿真配置为在二进制模式下工作

请查看一些捕获内容、这些捕获内容显示了如何使用 TeraTerm 仿真执行此操作。

此外、您使用的是哪个 SP 版本？

此致、

Shlomi

尊敬的  Shlomi：  

我们根据您的建议配置再次检索 MAG 日志；请参阅随附的文件。 但是、这并没有捕获最坏情况的示例、但我们可以首先验证是否可以成功打开日志。 另外还附加了一个电流图、其中黄色圆圈表示更正常的唤醒电流、绿色圆圈表示更大的唤醒电流。

e2e.ti.com/.../teraterm_2D00_1023_2D00_switch.log

谢谢。

BR

Trevor

添加更多信息：

芯片：0x31100019

MAC：3.7.0.1
PHY：3.1.0.26
NWP：4.13.0.2
ROM: 8738
主办：3.0.1.71

您好、

是的、我可以对其进行解码、这样过程就可以了。

此致、

Shlomi

尊敬的  Shlomi：  

我很高兴您能在您的端成功解码它 请问您是否分析过上述日志文件？ （您可以参考上面的当前图形对其进行分析）

谢谢。

BR

Trevor

尊敬的  Shlomi：  

 您是否有关于 Mac 日志的任何更新？

谢谢。

BR

Trevor

尊敬的 Trevor：

这不是一个示例、看看您是否可以捕获日志？ 我可以验证日志是否正常、因此请继续捕获完整日志。

捕获的日志非常短、显示正常状态。 我看不到其中有问题的部分。

此致、

Shlomi

尊敬的  Shlomi：  

我们为误解而道歉。 以下是我们希望您帮助分析的日志（少于 10 分钟）。 您可以从上面的当前图中观察 NWP 唤醒状态。 当前 LSI 设置为 1200 毫秒、所有唤醒间隔看起来都正确。

但是、每次唤醒后的处理时间各不相同。 以黄色圈出的区域表示最小唤醒电流、这正是我们预期的结果。 启用 DHCP 后、即可轻松实现这一结果；其他唤醒事件的处理时间都大于用黄色圈出的时间、用绿色圈出的区域表示最大唤醒电流。

谢谢。

BR

Trevor

尊敬的 Trevor：

我看不到任何附件。

Shlomi

尊敬的  Shlomi：  

好的、我将再次上传并提供更清晰的解释。

捕获随附的日志时、我们还连接了 Power Debugger 套件来监测电流、如下图所示。

执行 LSI（1200 毫秒）后、下图显示系统每 1200 毫秒唤醒一次、但每个唤醒事件的处理时间似乎有所不同。 您可以首先查看以黄色圈出的唤醒事件、我们认为这些事件相对正常（当启用 DHCP 时，我们一直观察到这种现象）。 然而、除了这个唤醒事件外、其他唤醒事件的处理时间会更长、尤其是用绿色圆圈标明的时间、这段时间特别长。 您能帮助我们分析这个问题吗？

e2e.ti.com/.../3005.teraterm_2D00_1023_2D00_switch.log

谢谢。

BR

Trevor

尊敬的 Trevor：

这与之前的日志相同。

无论如何、我更深入地研究了它、从我所见、似乎您在此 AP 上有许多广播。

为了说明一下、当您连接到 Wi-Fi 时、AP 只能在信标之后发送广播/多播帧、它应该在称为 DTIM 的特殊信标上发出信号。

发生的情况是、器件会按预期唤醒以获得信标、并会看到 DTIM 标记有广播、因此它会保持唤醒状态、以根据规范要求获得信标。

然后、由于 AP 有很多这样的帧、它会继续发送设置了更多标志的帧以保持器件唤醒、从而获得所有缓冲的广播/多播帧。 只有 AP 传输完所有帧后、器件才可能恢复睡眠状态。

这就是为什么您会看到功率变化的原因、因为有时 AP 会 长时间保持基站唤醒状态。

在日志中我不能看到它运行更长时间（绿色圆圈）的情况。

Shlomi  

嗨、 Shlomi  

我想先与您澄清几个问题：
1.您可以从日志中看到设备何时开始连接和断开连接?
2.您能从日志中看到设备每次唤醒 1200ms 进行处理时的时间差吗?

BR

Trevor

尊敬的 Trevor：

是的、我可以看到器件何时处于睡眠状态并唤醒。

基本上、当它连接时、它开始以学习算法跟踪信标接收、持续 18 个信标（每个信标为 102.4mSec 分隔）。 每个信标都会完成此操作、因此它会唤醒每个信标并打开更大的窗口来捕获信标并校准唤醒时间。

这是在连接到 AP 后立即进行的一次性操作、除非出于某种原因松开信标、然后重复该过程。 在您的情况下、我按预期看到过一次。

大多数情况下、它会按预期休眠近 1.2 秒、但正如我提到的、此 BSS 中有许多多播帧、因此器件在接收到信标后会保持更长的时间以获取这些帧、因此消耗的功率更大。

此致、

Shlomi

尊敬的  Shlomi：  

您能给我们一些提示或信息什么 是“多播帧“吗？

我们将捕获更多日志以供您参考、一旦捕获完成、我们将在稍后将其上载给您。

谢谢。

BR

Trevor

您好、

多播帧很常见、问题在于它们的节奏。 有多种类型、如 mDNS 帧、IGMP 帧、生成树帧等

此外、广播帧也很常见、就像存在许多 ARP 广播帧一样。

不确定您的环境中有什么、但嗅探器会告诉您。

此致、

Shlomi

尊敬的  Shlomi：  

我又收集了日志。 下面有两个日志、几个时间戳似乎存在问题。 您能帮助检查和分析这些问题吗？

对于 teraterm-1205-01.log：  

1.在 LPDS 模式下的第 11 次间隔事件发生后、似乎出现了问题。

2.进入 LPDS 模式后,在 1 分钟 45 秒后,似乎出现了一些问题

e2e.ti.com/.../teraterm_2D00_1205_2D00_01.log

对于 teraterm-1205-02.log：  

1.退出 LPDS 模式后、大约在第 11 个间隔事件发生前、似乎发生了一些问题。

e2e.ti.com/.../teraterm_2D00_1205_2D00_02.log

谢谢。

BR

Trevor

尊敬的  Shlomi：  

添加第三个日志、您还可以检查 LSI 1200mS 配置下的平均电流消耗是否达到 2.5mA 左右。

e2e.ti.com/.../teraterm_2D00_1205_2D00_05.log

BR

Trevor

尊敬的 Trevor：

跟踪和对齐时间戳非常困难/无法实现。 我可以在日志中看到实际连接、但我没有完整视图、因为 NWP 处理器也起着作用、我假设您的应用处理器也计入其中？

因此、当您提到 LPDS 模式下的第 11 个间隔时、不清楚要计数的位置。

我在第一次捕获中看到的是、器件通常按预期每 1.2 秒唤醒一次、正如我提到的、有许多多播/广播、但它正在从一个唤醒切换到另一个唤醒（但我假设这不是主要困扰）、在某些情况下、信标连续缺失、这会导致器件每 102 毫秒唤醒一次以跟踪信标并获得回来。 这看起来像是每~100mSec 唤醒一次、因此我假设情况并非如此。

第二次捕获与第一次捕获类似。

您能否说明第 1 步和第 2 步（您分别称为进入 LPDS 和退出 LPDS）的步骤？ 从用户的角度来看、您要做什么？ 当您连接/断开 AP 时、是否会发生这种情况？ 其他？

至于 第 5 次捕获、我可以看到：

• 有两次连接尝试。 您是否断开连接并重新连接？ 这是预料之中的吗？
• 它丢失信标的时间比第 1 次和第 2 次捕获的时间长、因此它将进入 OOS（不同步）事件、从而使其在信标上从头开始重新同步。 这意味着它每 100 毫秒唤醒 18 个信标,并且由于你有多个多播,它可能看起来非常繁忙的时间表（再次,近 2 秒）。 这可能会解释您在第 1 次和第 2 次捕获中看到的繁忙~2 秒
• 另一个有趣的观察,在第一次试验,需要时间,直到键被设置到固件. 在此期间、NWP 处理器使系统保持唤醒状态。 这可能是因为 AP 的身份验证帧未到达或关联未到达。 同样、在这种情况下、只有嗅探器才能知道、我需要使用空气嗅探器。 BTW、它持续高电流的持续时间约为 3 秒

此致、

Shlomi

尊敬的  Shlomi：  

实验步骤都是相同的。 我们使用“network_terminal"示“示例（添加 LPDS 指令）来执行实验、

步骤 1： wlanconnect  

步骤 2：启用

步骤 3： 按用户按钮离开 LPDS

步骤 4：wlandisconnect  

第 5 个 日志中的唯一区别是记录时间更长。

BR

Trevor

您好、

这很明显。

根据到目前为止的分析、我可以说：

• 多个多播/广播每个 DTIM 都会导致高功耗、因为器件需要更多的时间来获取这些数据。 它因 DTIM 而异、因为它取决于环境、并且持续时间为 30-40mSec
• OOS 事件使信标丢失。 原因不清楚、因为我没有空气嗅探器
• NWP 处理器可使系统保持唤醒状态。 这可能是因为 AP 的身份验证帧未到达或关联未到达。 再说一次,只有一个嗅探器可以告诉我一个空气嗅探器

Shlomi

尊敬的  Shlomi：  

感谢您的帮助和分析。

您能帮助再次分析此日志 (1222) 吗? 查看与上面的日志 (LOG_1205-01' LOG_1205_2 和 LOG_1205_5) 相比是否有任何差异？ 测试步骤和器件环境（相同的距离）与之前的实验相同。 唯一的区别是 AP 的 DHCP 已打开。

e2e.ti.com/.../teraterm_5F00_1222.log

BR

Trevor

您好、

这应该是一个好的情况吗?

日志非常短、但我可以看到、由于没有多播/广播帧、该器件几乎立即进入睡眠状态。

Shlomi

尊敬的  Shlomi：  

是的、很好的情况、根据您的分析、这是一个非常大的差异。  所有实验步骤和条件都完全相同；主要区别在于 AP 配置

在好的情况下、我们已启用 DHCP、连接方法如下图所示。

关于上一个坏情况、我们已禁用 DHCP、连接方法如下图所示。

根据当前的实验结果、在良好的配置条件下、AP 似乎能够阻止您之前观察到的多播/广播帧。

在许多实验结果中,我们观察到了另一种现象:在坏的情况下 ,很容易与 AP 断开连接（这种情况每天可能发生数次,最短间隔可能小于 1 小时,最长不超过 7 小时）,原因代码为 109。 然而、在一个良好的情况下、 我们仍然保持连接 5 天、没有任何连接。

请问、根据你过去的经验、这个问题的可能原因是什么？ 在未来的产品使用环境中、我们可能无法完全控制、并且可能无法在每个环境中启用 DHCP。 对于某些用户情况、为了使所有 AP 都处于同一网络中、它们的 AP 路由器可以设置为无线接入点模式（禁用 DHCP）。

谢谢。

BR

Trevor

尊敬的 Shlomi：  

感谢您的解释。

BR

Trevor