This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
你(们)好
我在 CC3220S 的 LPDS 模式下面临高电流消耗问题。
在我们的定制固件上进入 LPDS 模式后、它将持续提供18~24mA 的电流、同时使用 TI LPDS 示例代码运行、仅消耗287uA 的电流。
我们在云 OTA 示例上构建了代码、并且只有一个线程与 cloud_ota 线程不同。
已在 TI Launchpad 上执行测试。 因此、在这里、我确信我们在 firware 中缺少一些东西。
您能不能帮助我我们缺少哪些设置或配置?
尊敬的 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:
此外、由于我们使用 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。 因此、UART 显然与电流消耗有关。
为了回答您的问题,我们在睡眠时没有启用 UART_READ()阻塞呼叫。
下面是我们的 UART 配置函数:
UART_INIT();
UART_Params uartParams;
/*创建一个数据处理关闭的 UART。 *
UART_PARAMS_INIT (uartParams);
uartParams.writeDataMode = UART_DATA_BINARY;
uartParams.readDataMode = UART_DATA_BINARY;
uartParams.readReturnMode = UART_return_full;
//uartParams.writeReturnMode = UART_return_full;
uartParams.readEcho = UART_ECHO_OFF;
uartParams.baudrate = 115200;
uartParams.readCallback = uart0ReadCallback;
uartParams.readMode = UART_MODE_CALLACK;
/*回叫定义*/
void uart0ReadCallback (UART_Handle UART、void * rxBuf、size_t size)
{
//不执行任何操作。
}
此致
Ravija
尊敬的 Ravija:
查看此处、了解有关我们的电源策略和管理的一些好信息- https://dev.ti.com/tirex/explore/node?node=ADkVaYJ0I8KyFtz16wdJ0A__fc2e6sr__LATEST
在配置 UART 时、需要禁用电源策略与 UART RX 的相关性。 我们在 SDK 中的 InitTerm()函数中执行此操作,但您只需添加到设置中,即可执行以下操作:
/*从 LPDS 依赖项中删除 UART 接收*/
UART_CONTROL (uartHandle、UART_CMD_RXDISABLE、空);
尝试一下、让我知道它是否有用。
BR、
Vince
尊敬的 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
尊敬的 Vincent:
您上面提供的命令完全按照我所怀疑的那样禁用 UART Rx。
因此、我尝试在器件进入睡眠模式之前禁用它、并在器件从睡眠模式唤醒后立即启用它、但它具有与睡眠前 UART 关闭以及器件唤醒后 UART_OPEN 和 CONFIG 相同的效果。
因此、正如我在上一篇文章中所述、我无法使用 SPI 外设。
"
这有助于根据预期将电流消耗降至最低、代码似乎正在运行、但会导致 SPI 外设发生故障。
实际上、我们正在通过 SPI 将另一个控制器(TICC2642)作为从器件连接到我们的控制器、如果我们使用前面提到的 UART open 和 close、则会在 UART open 后立即调用的 SPI 命令上导致一些移位/错误。 "
请帮助我们解决这个奇怪的问题、因为我们不希望一个外设对另一个外设产生影响。
此致
Ravija
Ravija、
回顾一下文档、我们无法通过 RX 来唤醒 UART 命令。 当您退出 LPDS 时、必须先关闭 UART、然后关闭 UART_Open。
您可以使用我们的唤醒 GPIO 让一个器件唤醒另一个器件。 因此、我的建议是您需要实现一种自定义流控制机制、该机制会在一侧将引脚设置为高电平以唤醒 CC32xx 器件、然后为其提供充足的时间来配置 UART 以接收。
当您执行 UART_CLOC()机制时,您是否仍然遇到 SPI 问题?
BR、
Vince
尊敬的 Ravija:
这似乎是您进入低功耗模式所需执行的操作。 如果您对 SPI 外设有其他问题、请随时打开另一个线程以获取帮助。
BR、
Vince