[参考译文] CC3220S：在 LPDS 模式下 CC3220S 的电流消耗更高

Sumit、

您是否通过调用 enablePolicy()来启用 TI-RTOS 电源策略？

BR、

Vince  

尊敬的 Vince：

是的、我们正在启用电源策略。

这里需要注意的一点是、我们已通过云 OTA 示例构建了代码。 在这里、我们还有另一个观察结果、即每个线程都需要单独休眠。 对吗？

此致

Ravija

尊敬的 Vince：

感谢您的快速回复。

因此、我们尝试将 OTA 线程置于睡眠状态、这确实为我们节省了大约5mA 的电流。

您能给我们更多的指示一下什么仍然会消耗电力吗？

在 LPDS 模式下、我们的器件仍消耗~14mA 电流。 即使在未连接任何器件的情况下在 launchpad 上测试代码、我们也会获得相同的结果、因此我们认为不应存在外设泄漏电流。

我们的 LPDS 设置如下：

• 电源

   
• 启用策略	N
  策略功能	PowerCC32XX_sleepPolicy
  策略初始化函数	PowerCC32XX_initPolicy
  进入 LPDS 挂钩函数	-
  恢复 LPDS 挂钩函数	-
  启用网络唤醒 LPDS	N
  在 LPDS 期间保持调试处于活动状态	N
  启用 GPIO 唤醒 LPDS	Y
  唤醒 GPIO 源 LPDS	GPIO4.
  唤醒 GPIO 类型 LPDS	RISE_EDGE
  唤醒 GPIO LPDS 功能	GPIO_callback
  唤醒 GPIO LPDS 功能 ARG	0
  使能 GPIO 唤醒关断	Y
  唤醒 GPIO 源关断	GPIO4.
  唤醒 GPIO 类型关断	RISE_EDGE
  RAM 保持屏蔽 LPDS	SRAM_COL_1、+3
  IO 保持关闭	GRP_1

  驻车引脚

  引脚停止状态

  更改所有引脚	默认值
  PIN01	weak 下拉_std
  PIN02	weak 下拉_std
  PIN03	不要停车
  PIN04	不要停车
  PIN05	weak 下拉_std
  PIN06	weak 下拉_std
  PIN07	weak 下拉_std
  PIN08	weak 下拉_std
  引脚13.	weak 下拉_std
  引脚15	不要停车
  引脚16	weak 下拉_std
  PIN17.	weak 下拉_std
  PIN18.	weak 下拉_std
  PIN19.	weak 下拉_std
  PIN20.	weak 下拉_std
  PIN21.	weak 下拉_std
  PIN29.	weak 下拉_std
  引脚30	weak 下拉_std
  PIN45.	weak 下拉_std
  PIN50.	DRIVE_HIGH
  PIN52.	weak 下拉_std
  PIN53.	weak 下拉_std
  PIN55	weak PULL_UP_STD
  PIN57.	weak PULL_UP_STD
  PIN58.	不要停车
  PIN59.	不要停车
  PIN60.	weak 下拉_std
  PIN61.	weak 下拉_std
  PIN62.	不要停车
  引脚63.	weak 下拉_std
  PIN64	weak 下拉_std

  我们尝试使用默认引脚配置(除引脚55和57向上拉外的所有引脚均已下拉)以及自定义引脚配置、在该配置中、我们根据其用例更改了一些引脚、并保留了许多其他引脚。

  根据您的建议、我们还可以检查哪些内容？

  此致

  Ravija

Ravija、

如果您使用的是 TI RTOS、则应该能够使用 RTOS 查看器来查看哪些任务处于活动状态以及哪些任务处于休眠状态。 我会检查每个任务并确保它们处于睡眠状态。 其次、当您使用 Uniflash 刷写器件时、您可以在设置中禁用 mdns 和内部 HTTP 服务器。 如果不需要这些功能、这将为您节省一些电量。

最后、如果您捕获了高功耗、我将通过查看配置文件来帮助进行诊断。 如果电流~50mA 的短尖峰、则 MCU 可能不处于 LPDS 状态、这就是进入接收模式-~150+mA 及其传输-~15mA。

BR、

Vince

您好、Vince、

我很抱歉答复迟了、因为我一直在处理一些紧急释放工作、无法更早地尝试您的建议。

我尝试使用以下命令来转动内部 httpserver：

SL_NetAppStop (SL_NetApp_HTTP_SERVER_ID)；

并在器件复位后配置开始之前重置服务器(我们的代码基于 Cloud_OTA 示例)

sl_NetAppStop (sl_NetApp_HTTP_SERVER_ID)；/*关闭内部服务器以节省功耗*/
SL_NetAppStart (SL_NetApp_HTTP_SERVER_ID)；

我不确定是否应在设置中禁用 MDNS。 它会影响配置过程吗？

因为当 http 服务器关闭时、配置命令会产生-2017错误、这就是我在电路板复位后立即重新启动服务器的原因。

我签出了 RTOS 任务查看器、下面是我在器件处于睡眠模式时看到的任务屏幕：

请建议我们缺少什么？

此致

Ravija

尊敬的 Ravija：

您为 NWP 设置了什么电源策略？ 通常、它处于正常模式。 您可以将其重新配置为 LSI、间隔为600ms、以查看这是否会降低电流。

当您想进入低功耗模式时，一个更快速的检查就是调用 sl_Stop()，以确保它不是将器件保持在更高功耗的 NWP。

BR、

Vince  

尊敬的 Vince：

感谢您的快速回复！

不过、我想问以下问题。

我们是否应该如下面所示在 SysConfig 的"常规"窗口中更改 LSI 间隔？

在我们进入睡眠状态之前、就会调用 sl_stop shoud、对吧？ 然后、当我们唤醒时、我们可以执行 sl_start？

此致

Ravija

尊敬的 Vince：

此外、由于我们使用 cloud_ota 示例来构建代码、OTA 线程在调用 sl_stop 时是否会产生任何问题。 这是否会触发任何不需要的回调，因为它可能与 AP 断开连接？

此致

Ravija

Ravija、

在这里设置 LSI 间隔，不用担心 sl_Stop()。 更改此参数时的功耗是多少？

BR、

Vince  

您好、Vince、

正如预期的那样、在进入睡眠模式之前调用 sl_stop (0)会导致器件在 OTA 线程上运行时出现错误、因此我们必须跳过此操作。

调用 LSI 间隔似乎会使当前值降低一个位。 将在明天对此进行更详细的检查。

此外、我们还观察到、不使用第二个 UART (配置用于 GPIO 11和12)会极大地降低 LaunchPad 上的功耗。 这里有一些捕获。 如果我们完全禁用外设并将器件置于睡眠模式、电流消耗会出乎意料地降至2mA 的平均值。

此致

Ravija

尊敬的 Ravija：

是的、这可能会导致问题。 在进入 LPDS 期间是否有 UART_READ()阻塞？

尊敬的 Vincent：

在阅读您之前的答复之后，我尝试在启用电源策略之前关闭 UART，方法是与 SEM_WAIT ()一起调用 powerenableepolicy()。 然后重新配置 UART、它调用了与我在代码开头配置 UART 所使用的函数相同的函数。

这有助于根据预期将电流消耗降至最低、代码似乎正在运行、但会导致 SPI 外设发生故障。

实际上、我们正在通过 SPI 将另一个控制器(TICC2642)作为从器件连接到我们的控制器、如果我们使用前面提到的 UART open 和 close、则会在 UART open 后立即调用的 SPI 命令上导致一些移位/错误。

这是非常奇怪的、我们需要了解这是如何相关的。  

[引用 user="Vincent Rodriguez ]/*从 LPDS 依赖项中删除 UART 接收*/
UART_CONTROL (uartHandle、UART_CMD_RXDISABLE、NULL)；[/引用]

如果我们使用它、这是否意味着我们将禁用 UART 接收？ 如果是、那么我们应该在唤醒后如何启用它、因为当器件处于唤醒状态时、我们需要在该特定 UART 上进行双向通信。

此致

Ravija

尊敬的 Ravija：

不、我认为这只是将 RX 从 LPDS 依赖中移除。 您应该能够添加它、并且仍然能够添加 Rx 数据。

BR、

Vince  

尊敬的 Vincent：

您上面提供的命令完全按照我所怀疑的那样禁用 UART Rx。  

因此、我尝试在器件进入睡眠模式之前禁用它、并在器件从睡眠模式唤醒后立即启用它、但它具有与睡眠前 UART 关闭以及器件唤醒后 UART_OPEN 和 CONFIG 相同的效果。

因此、正如我在上一篇文章中所述、我无法使用 SPI 外设。

"

这有助于根据预期将电流消耗降至最低、代码似乎正在运行、但会导致 SPI 外设发生故障。

实际上、我们正在通过 SPI 将另一个控制器(TICC2642)作为从器件连接到我们的控制器、如果我们使用前面提到的 UART open 和 close、则会在 UART open 后立即调用的 SPI 命令上导致一些移位/错误。     "

请帮助我们解决这个奇怪的问题、因为我们不希望一个外设对另一个外设产生影响。

此致

Ravija

尊敬的 Vince：

为了降低功耗、我们必须在器件进入睡眠模式之前立即关闭 UART。 此外、为了解决该 SPI 问题、我们还必须关闭 SPI、然后在器件唤醒后重新打开 UART。

我们仍然看到 SPI 上的一些问题、并正在努力解决这些问题。 如果您有任何想法、请告知我们。

此致

Ravija