[参考译文] CC2340R5：CC2340R5：传感器 SPI 上的高电流消耗+自动关断放大器；BLE 错误问题

感谢您的详细答复

是的、中已进行了更新bleapputiltask.c。
具体而言、广播停止、重新初始化和启动序列在BLEAPPUTIL_EVT_APPLICATION事件上下文中进行处理。

这是否应用于 Tarek 的建议以绕回  BLEAppUtil_invokeFunction 和 BLEAppUtil_invokeFunctionNoData？

[引述 userid=“680243" url="“ url="~“~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1603770/cc2340r5-cc2340r5-high-current-consumption-on-sensor-spi-auto-shutdown-ble-error-issue/6182181

• 响应 严重 BLE 错误 (0x13) 、如果尝试进行 Sub-1（基于 SPI）传输、则主板 关断

• IF 无 SPI 事务 在 BLE 错误后触发、器件继续运行

[/报价]

错误 0x13 是否在运行时期间解决过、如果是这样、之后 SPI 是否成功？

[引述 userid=“680243" url="“ url="~“~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1603770/cc2340r5-cc2340r5-high-current-consumption-on-sensor-spi-auto-shutdown-ble-error-issue/6182181

不同应用 定制硬件 、而不是 LP-EM-CC2340R53 EVM。

SysConfig 文件最初是使用 LaunchPad 模板生成的、但所有引脚分配都已手动重新映射以匹配定制板。

[/报价]

尽管它与这个问题并不相关、但最佳实践是切换到具有“SysConfig 电路板“视图中的“使用定制电路板“的定制设计。

[引述 userid=“680243" url="“ url="~“~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1603770/cc2340r5-cc2340r5-high-current-consumption-on-sensor-spi-auto-shutdown-ble-error-issue/6182181

我们通过将相同的 SPI 信号从外部 Sub-1 (S2LP) 电路板连接到 LaunchPad、尝试在 LP-EM-CC2340R53 上进行 Sub-1 测试。

不过：

• SPI 初始化成功

• 我们是 无法在 Sub-1 对讲机上启动 TX

• 因此、定制电路板上出现的完整故障场景可能会发生 不可转载 LED 闪烁

在此阶段、出现问题 特定于自定义硬件+固件交互 。

[/报价]

在 TX 无法实现 Sub-1 无线电之前、这不一定排除 LP-EM-CC2340R53 上的可重现性。  这是否使用提供的完整应用工程？

[引述 userid=“680243" url="“ url="~“~/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1603770/cc2340r5-cc2340r5-high-current-consumption-on-sensor-spi-auto-shutdown-ble-error-issue/6182181

可捕获逻辑分析仪的数据；不过：

• 一次 严重 BLE 错误 (0x13) 发生时、系统卡在 BLE 错误状态

• 在此之后不会发生其他 SPI 事务

• 因此、在故障时刻没有可准确捕获的 SPI 活动

我们可以捕获 SPI 活动 更正此项 （如果有用）。

[/报价]

这意味着、如果在错误 0x13 期间调用 SPI、则 S2LP_CORE_SPI.c 绝不会使其通过 S2LPSpiInit 到实际使用 S2LPSpiTransfer 的点 ？  使用 CCS 调试器断点来发现问题恰好在 SPI 驱动程序中的哪个位置会很有趣、请参阅 中的 SPILPF3DMA_OPEN  \source\ti\drivers\spi\SPILPF3DMA.c 以了解详细信息。  鉴于 BLE 栈已经暗示了内存分配问题、额外的初始化会导致器件故障。

我要求执行内存评估和跟踪。  以下是 调试内存问题 的指南和涵盖 调试运行时问题的 SLA。  在查看 main_freertos.c 时、我注意到每个线程都是使用相同的优先级 (priParam.sched_priority = 1) 和栈大小 (#define THREADSTACKSIZE 3072) 创建的、这可能会进行优化以减少每个线程的内存分配（以便更多地针对 BLE 栈）并允许不同的调度优先级。  我注意到在 SysConfig 文件中、FreeRTOS 堆大小已增加到 0xA000、它远大于默认的 basic_ble_oad_dual_image 工程 0x4D50、这是什么原因？  

此致、
Ryan

我还在 LaunchPad 上进行了简单的 SPI 控制器演示、并确认了 LP-EM-CC2340R5 上每 5 秒发送 128 个字节时的平均电流消耗为 11uA、而无需关闭 SPI 驱动器

/*
 * Copyright (c) 2018-2024, Texas Instruments Incorporated
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * *  Redistributions of source code must retain the above copyright
 *     notice, this list of conditions and the following disclaimer.
 *
 * *  Redistributions in binary form must reproduce the above copyright
 *     notice, this list of conditions and the following disclaimer in the
 *     documentation and/or other materials provided with the distribution.
 *
 * *  Neither the name of Texas Instruments Incorporated nor the names of
 *     its contributors may be used to endorse or promote products derived
 *     from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
 * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
 * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

/*
 *  ======== spicontroller.c ========
 */
#include <stddef.h>
#include <stdint.h>
#include <string.h>

/* POSIX Header files */
#include <pthread.h>
#include <semaphore.h>
#include <unistd.h>

/* Driver Header files */
#include <ti/drivers/GPIO.h>
#include <ti/drivers/SPI.h>
#include <ti/drivers/spi/SPILPF3DMA.h>
#include <ti/display/Display.h>

/* Driver configuration */
#include "ti_drivers_config.h"

#define THREADSTACKSIZE (1024)

#define SPI_MSG_LENGTH (128)
#define CONTROLLER_MSG ("Hello from controller, msg#: ")

#define MAX_LOOP (100)

#ifdef DeviceFamily_CC35XX
    #define CONFIG_GPIO_LED_0 GPIO_INVALID_INDEX
    #define CONFIG_GPIO_LED_1 GPIO_INVALID_INDEX
#endif

unsigned char controllerRxBuffer[SPI_MSG_LENGTH];
unsigned char controllerTxBuffer[SPI_MSG_LENGTH];

/* Semaphore to block controller until peripheral is ready for transfer */
sem_t controllerSem;

/*
 *  ======== controllerThread ========
 *  Controller SPI sends a message to peripheral while simultaneously receiving a
 *  message from the peripheral.
 */
void *controllerThread(void *arg0)
{
    SPI_Handle controllerSpi;
    SPI_Params spiParams;
    SPI_Transaction transaction;
    uint32_t i;
    bool transferOK;
    int32_t status;
        
    /* Open SPI as controller (default) */
    SPI_Params_init(&spiParams);
    spiParams.frameFormat = SPI_POL0_PHA1;
    /* See device-specific technical reference manual for supported speeds */
    spiParams.bitRate     = 1000000;
    controllerSpi         = SPI_open(CONFIG_SPI_CONTROLLER, &spiParams);

    /* Copy message to transmit buffer */
    strncpy((char *)controllerTxBuffer, CONTROLLER_MSG, SPI_MSG_LENGTH);

    for (i = 0; i < MAX_LOOP; i++)
    {
        /* Initialize controller SPI transaction structure */
        controllerTxBuffer[sizeof(CONTROLLER_MSG) - 1] = (i % 10) + '0';
        memset((void *)controllerRxBuffer, 0, SPI_MSG_LENGTH);
        transaction.count = SPI_MSG_LENGTH;
        transaction.txBuf = (void *)controllerTxBuffer;
        transaction.rxBuf = (void *)controllerRxBuffer;

        /* Toggle user LED, indicating a SPI transfer is in progress */
        //GPIO_toggle(CONFIG_GPIO_LED_1);

        /* Perform SPI transfer */
        transferOK = SPI_transfer(controllerSpi, &transaction);

        /* Sleep for a bit before starting the next SPI transfer  */
        sleep(5);
    }

    SPI_close(controllerSpi);

    return (NULL);
}

/*
 *  ======== mainThread ========
 */
void *mainThread(void *arg0)
{
    pthread_t thread0;
    pthread_attr_t attrs;
    struct sched_param priParam;
    int retc;
    int detachState;

    /* Call driver init functions. */
    GPIO_init();
    SPI_init();

    /* Configure the LED pins */
    GPIO_setConfig(CONFIG_GPIO_LED_0, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);
    GPIO_setConfig(CONFIG_GPIO_LED_1, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);

    /* Turn on user LED */
    //GPIO_write(CONFIG_GPIO_LED_0, CONFIG_GPIO_LED_ON);

    /* Create application threads */
    pthread_attr_init(&attrs);

    detachState = PTHREAD_CREATE_DETACHED;
    /* Set priority and stack size attributes */
    retc        = pthread_attr_setdetachstate(&attrs, detachState);
    if (retc != 0)
    {
        /* pthread_attr_setdetachstate() failed */
        while (1) {}
    }

    retc |= pthread_attr_setstacksize(&attrs, THREADSTACKSIZE);
    if (retc != 0)
    {
        /* pthread_attr_setstacksize() failed */
        while (1) {}
    }

    /* Create controller thread */
    priParam.sched_priority = 1;
    pthread_attr_setschedparam(&attrs, &priParam);

    retc = pthread_create(&thread0, &attrs, controllerThread, NULL);
    if (retc != 0)
    {
        /* pthread_create() failed */
        while (1) {}
    }

    return (NULL);
}

我注意到、您的 SysConfig 文件配置为“四引脚 CS 低电平有效“、但在您的应用中是手动控制 CS 引脚  

void SPI_CSN_LOW()  {
  GPIO_write(S2LP_SPI_CS_PIN, 0);
} 

void SPI_CSN_HIGH() {
  GPIO_write(S2LP_SPI_CS_PIN, 1);
}     

如果要通过软件控制此 IO、则需要将 SysConfig 设置为“三引脚“模式、因为这可能会导致 GPIO 冲突、从而增加电流消耗。  您还应该确认您的 SPI 引脚在定制硬件上没有冲突或泄漏、因为预计 SPI 控制器初始化且开路时会产生高电流消耗。  您可以将设计提交到 SIMPLELINK-2-4GH-DESIGN-REPONS 以供进一步审查。

此致、
Ryan

您好、Ryan、

感谢您提供详细的跟进和指导。 请在下面找到我们的答复和最新观察结果。

---

1. BLEAppUtil 调用包装（Tarek 的建议）

是的、我们现在应用了 Tarek 的建议并验证了这两种包装机制。

我们重构了要通过执行的广播停止/初始化/启动序列
BLEAppUtil_invokeFunctionNoData()使用所需的回调签名：

static void BLE_UpdateAdvertising(char *data)
{
    (void)data;

    bStatus_t status;

    status = BLEAppUtil_advStop(peripheralAdvHandle_1);
    printf("BLEAppUtil_advStop Error Code: %d\n", status);

    advSetInitParamsSet_1.advData = advData2;
    advSetInitParamsSet_1.advDataLen = sizeof(advData2);

    advSetInitParamsSet_1.scanRespData = scanData2;
    advSetInitParamsSet_1.scanRespDataLen = sizeof(scanData2);

    status = BLEAppUtil_initAdvSet(&peripheralAdvHandle_1,
                                   &advSetInitParamsSet_1);
    printf("BLEAppUtil_initAdvSet Error Code: %d\n", status);

    status = BLEAppUtil_advStart(peripheralAdvHandle_1,
                                 &advSetStartParamsSet_1);
    printf("BLEAppUtil_advStart Error Code: %d\n", status);
}

并从 BLEAppUtil 任务上下文调用：

case BLEAPPUTIL_EVT_APPLICATION:
{
    BLEAppUtil_invokeFunctionNoData(BLE_UpdateAdvertising);
    break;
}

尽管发生了这种变化、但行为保持不变：

BLEAppUtil_advStop Error Code: 0
BLEAppUtil_initAdvSet Error Code: 19
BLEAppUtil_advStart Error Code: 0

2.运行时 BLE 错误 0x13 的行为

一旦BLEAppUtil_initAdvSet()返回错误 0x13 (bleMemAllocError) ：

• 会发生错误 不会 在运行时解决

• 任何后续重新初始化广播的尝试都会失败

• IF 无 SPI 事务 在此错误后触发、器件继续运行

• 如果是 Sub-1（基于 SPI）传输 尝试低功耗、因此器件会关断
  
  

  3. SPI 芯片选择处理说明

  关于 SPI 芯片选择处理：

  • SysConfig 当前已配置用于 “四引脚 CS 低电平有效“

  • 应用的工作方式 不会 在运行时手动切换 SPI CS 线路

  尽管代码库中存在辅助函数：
  
  

  void SPI_CSN_LOW(void)
  {
      GPIO_write(S2LP_SPI_CS_PIN, 0);
  }
  
  void SPI_CSN_HIGH(void)
  {
      GPIO_write(S2LP_SPI_CS_PIN, 1);
  }
  

  
  这些功能是什么 不能在应用程序中的任何位置调用 和表示 仅无效代码 。 所有活动的 SPI 事务都依赖于 SPI 驱动器的 CS 处理、而不是软件控制的 CS 切换。
  
  

  此时、我们看到 两个明显分开的问题 ：

  1. 主要问题：
     BLE 内存分配失败bleMemAllocError / 0x13 ()、由广播集的重复运行时重新初始化引起。

  2. 次要问题：
     在 BLE 进入错误状态后、任何后续 SPI 活动都可能触发器件关断和高电流、这可能是由于系统不稳定和/或 SPI CS 配置冲突。
     
     

     首先、我们需要解决 BLE 内存分配错误 (bleMemAllocError / 0x13) 。
     此问题解决后、我们将重新测试并确认是否存在 与 SPI 事务相关的关断和电流消耗问题 仍然存在。

     要对此提供帮助、请告知我们 您希望我们分享或查看哪些具体项目 义务。 我们可以根据需要提供以下任何一项：

     • 相关 之前执行的 ROM 与 BLE 广播生命周期（初始化和运行时更新）相关

     • BLEAppUtil 和 FreeRTOS 任务配置 、包括任务优先级和栈大小

     • SysConfig 设置 （BLE、FreeRTOS、SPI，电源）

     • 存储器使用情况详细信息 、如堆/栈分配和运行时统计信息

     • 减少测试应用 如果需要、仅关注 BLE（无 SPI）

     根据您的指导、我们将分享所请求的详细信息、并继续分步操作、在解决 SPI 和电流消耗问题之前首先稳定 BLE 堆栈。
     
     

     此致、
     海伦·M·帕尔马

您好 、Hiren、

我对延迟的答复表示歉意。 我对这个问题有很好的理解。 请允许我在几天内复制我的问题

此致、

Tarek D

尊敬的 Terek：

感谢您的答复。 如果您需要我们这边的任何额外代码或需要我们随时分享的任何 SysConfig 设置、

作为更新、我们已经返工了 BLE 广播生命周期以解决该bleMemAllocError (0x13)问题。

广播集现在在 BLE 栈初始化后立即创建：

void *BLEAppUtil_Task(void *arg)
{
    BLEAppUtil_stackRegister();
    BLEAppUtil_stackInit();

    bStatus_t status = SUCCESS;

    status = BLEAppUtil_initAdvSet(&peripheralAdvHandle_1,
                                   &advSetInitParamsSet_1);
    printf("BLEAppUtil_initAdvSet Error Code: %d\n", status);

    for (;;)
    {
        BLEAppUtil_appEvt_t pAppEvt;

        if (mq_receive(BLEAppUtil_theardEntity.queueHandle,
                       (char *)&pAppEvt,
                       sizeof(pAppEvt), NULL) > 0)
        {
            switch (pAppEvt.event)
            {
                case BLEAPPUTIL_EVT_APPLICATION:
                {
                    bStatus_t status = SUCCESS;

                    status = BLEAppUtil_advStop(peripheralAdvHandle_1);
                    printf("BLEAppUtil_advStop Error Code: %d\n", status);

                    vTaskDelay(pdMS_TO_TICKS(10));

                    /* Update advertising data */
                    status = GapAdv_loadByHandle(peripheralAdvHandle_1,
                                                 GAP_ADV_DATA_TYPE_ADV,
                                                 sizeof(advData2),
                                                 advData2);
                    printf("GapAdv_load ADV = %d\n", status);

                    /* Update scan response data */
                    status = GapAdv_loadByHandle(peripheralAdvHandle_1,
                                                 GAP_ADV_DATA_TYPE_SCAN_RSP,
                                                 sizeof(scanData2),
                                                 scanData2);
                    printf("GapAdv_load SCAN_RSP = %d\n", status);

                    status = BLEAppUtil_advStart(peripheralAdvHandle_1,
                                                 &advSetStartParamsSet_1);
                    printf("BLEAppUtil_advStart Error Code: %d\n", status);

                    break;
                }
            }
        }
    }
}

采用这种方法：

• bleMemAllocError (0x13)是 不再观察到

• 广播数据更新GapAdv_loadByHandle()仅使用执行

• 已完全删除运行时的广播集重新初始化

 

MCUBoot +应用程序映像出现新问题

解决 BLE 内存分配问题后、我们现在可以观察到 A 另一个问题 与 MCUBoot 和 GATT 服务相关：

• 何时 MCUBoot 和应用程序映像一起刷写

• 设备从移动应用程序广播并成功连接

• 不过、 看不到 GATT 服务 和 固件更新 (OAD/DFU) 选项不可用 移动应用程序
  
  此致、
  海伦·M·帕尔马

您好、Hiren、

这是非常奇怪的。 您是否能够连接到设备？ 您正在使用哪些 GATT 服务并希望看到这些服务？

固件更新服务仅在设备具有具有相同服务 UUID 的 GATT 服务时在移动应用中可用、因此似乎没有该服务。  如果您能分享一些代码片段、 我可以看一下。

另外、如果有一个小提示、我建议查看 basic_ble 示例中找到的 simple_GATT 配置文件 (common -> profiles -> simple_GATT)。 这是关于如何设置 GATT 服务的一个很好的示例。 我还建议查看 basic_ble SimpleLink Academy 以获得 GATT 协助、以及 如何将 BLE OAD 添加到基本示例  SimpleLink Academy 中、以帮助实现 OAD。

我希望这对您有所帮助！

此致、

Tarek D

您好 Tarek、

感谢您的澄清和建议。

若要更新您的信息、请参阅 GATT/固件更新服务可见性问题已解决 我们这边。 我们现在可以连接到器件、并在移动应用中看到预期的 GATT 服务、包括固件更新服务。

在这一点上、我们要重新将讨论的重点放在这一问题上 原始问题 在该主题中、即：

• 提供的 BLE 内存分配错误 (bleMemAllocError / 0x13) ,我们通过修改广告生命周期来解决（一次初始化广告集并在运行时更新广告数据而不重新初始化）。

• 后续的 与 SPI 相关的关断和高电流消耗行为 在 BLE 错误后观察到的、仍在调查中。

GATT/OAD 问题现已解决、因此我们将继续调试其余的 SPI 和电流消耗问题、并在进度中分享更新或特定问题。

再次感谢您的支持和指导。

此致、
海伦·M·帕尔马

您好、Hiren、

很抱歉、您给我们带来了延迟的响应。  

我很高兴听到您的大多数问题都已得到解决。 现在、关于与 SPI 相关的关断、我很惊讶地看到这个问题仍然存在、因为您提到这个问题只是在发生 bleMemAllocError 问题（已解决）时才会发生。

您能否详细说明如何使用 SPI、以及在什么条件下发生（如果不是在 bleMemAllocError 之后）？ 我再次查看了上一个线程中 Sulay 提供的代码、似乎 SPI API 被正确调用、因此我认为调用它们的环境就是问题所在。

此致、

Tarek D

您好 Tarek、

感谢您的澄清和再次查看。

正确 — 解决 BLE 存储器分配问题后、与 SPI 相关的关断为 不再连接到 bleMemAllocError (0x13)。 下面详细介绍了发生了哪些变化以及我们目前正在观察的情况。

更新了 BLE 处理：

case BLEAPPUTIL_EVT_APPLICATION:
{
    bStatus_t status = SUCCESS;

    status = BLEAppUtil_advStop(peripheralAdvHandle_1);
    printf("BLEAppUtil_advStop Error Code: %d\n", status);

    /* Update advertising data */
    status = GapAdv_loadByHandle(peripheralAdvHandle_1,
                                 GAP_ADV_DATA_TYPE_ADV,
                                 sizeof(advData2),
                                 advData2);
    printf("GapAdv_load ADV = %d\n", status);

    /* Update scan response data */
    status = GapAdv_loadByHandle(peripheralAdvHandle_1,
                                 GAP_ADV_DATA_TYPE_SCAN_RSP,
                                 sizeof(scanData2),
                                 scanData2);
    printf("GapAdv_load SCAN_RSP = %d\n", status);

    status = BLEAppUtil_advStart(peripheralAdvHandle_1,
                                 &advSetStartParamsSet_1);
    printf("BLEAppUtil_advStart Error Code: %d\n", status);

    break;
}

通过此更改：

• bleMemAllocError (0x13)是 不再观察到

• BLE 运行在较长运行时间内保持稳定
  
  

SUB-1/SPI 更改（当前问题正在调查中）

我们还更新了 Sub-1 流程以明确管理 唤醒和睡眠时序控制 、包括 SPI GPIO 方向控制。

子 1 工作线程

void* Sub1GWorkerThread(void* arg)
{
    SPI_init();
    S2LPSpiInit();
    Sub1G_NW_Init();

    while (1)
    {
        sem_wait(&sem_sub1gTrigger);   // Event-driven

        if (S2LP_Radio_Ok && Radio_state)
        {
            Sub1G_Wakeup();
            S1_Radio_Activity();
            Sub1G_NW_Process();
        }
    }
    return NULL;
}

Sub-1 唤醒处理

void Sub1G_Wakeup(void)
{
    GPIO_setConfig(CONFIG_GPIO_SPI_0_PICO, GPIO_CFG_OUT_STD);
    GPIO_setConfig(CONFIG_GPIO_SPI_0_SCLK, GPIO_CFG_OUT_STD);
    GPIO_setConfig(CONFIG_GPIO_SPI_0_CSN,  GPIO_CFG_OUT_STD);
    GPIO_setConfig(CONFIG_GPIO_SPI_0_POCI, GPIO_CFG_IN_PD);
}

Sub-1 睡眠处理

void Sub1G_Sleep(void)
{
    GPIO_setConfig(CONFIG_GPIO_SPI_0_PICO, GPIO_CFG_INPUT);
    GPIO_setConfig(CONFIG_GPIO_SPI_0_POCI, GPIO_CFG_INPUT);
    GPIO_setConfig(CONFIG_GPIO_SPI_0_SCLK, GPIO_CFG_INPUT);
    GPIO_setConfig(CONFIG_GPIO_SPI_0_CSN,  GPIO_CFG_INPUT);
}

Sub-1 状态机（睡眠/唤醒集成）

case SM_STATE_SLEEP_IN:
{
    S2LPGpioIrqDeInit(NULL);
    S2LPTimerSleepB(S_ENABLE);
    S2LPCmdStrobeSleep();
    GPIO_write(S2LP_SHDN, 0);
    Sub1G_Sleep();

    printf("SLEEP IN.......................\n");
    S2LP_Update_state(DEFAULT);
}
break;

case SM_STATE_SLEEP_OUT:
{
    S2LP_h_Reset_Cycle();
    printf("SLEEP OUT.......................\n");

    S2LP_Normal_mode_init();
    S2LP_Update_state(SM_STATE_SEND_DATA);
}
break;

此时、 没有关断、没有 BLE 错误 。

但是、我们看到了 显著的电流差 ：

• 未启用 Sub-1 线程时： ~16–17µA 平均电流

• 启用 Sub-1 线程时（即使在空闲时）： ~μ A 150µA 平均电流

为帮助进行分析、我附上了我们的S2LP_CORE_SPI.c文件及以上相关 operations.e2e.ti.com/.../S2LP_5F00_CORE_5F00_SPI.c

我们现在的目标是 将 Sub-1 的空闲电流减小回仅 BLE 基线 同时保持正确的 Sub-1 操作。

感谢您的持续支持。

此致、
海伦·M·帕尔马

嗨、Hiren、

上一个主题中提到、当 SPI 事务绕回重新打开和关闭 SPI 外设时、功耗降至 35uA。  这是否仍然正确？ 我认为剩余电流可以通过 GPIO 引脚的漏电流来解释。  首先、调用 Sub1G_sleep 不会删除到 SPI 外设的 GPIO 多路复用。  考虑中的最终 IO /source/ti/drivers/spi/SPILPF3DMA.c、每个 spi_Close 都调用该函数。  您将看到 每个 SPI GPIO 上都使用了 GPIO_resetconfig、以将其复位为 ti_drivers_config.c 的 gpioPinConfigs 中确定的 SysConfig 设置    、其中 SCLK 和 PICO 为“GPIO_CFG_OUTPUT_INTERNAL    | GPIO_CFG_OUT_STR_MED | GPIO_CFG_OUT_OUT_LOW“、而 POCI 为“GPIO_CFG_INPUT_INTERNE_| GPIO_PULL_CFG_NONE_“。   我不会考虑将通常预期的输出引脚设置为 Sub1G_SLEEP 内部的输入、并建议在待机状态期间为 SPI 引脚使用相同的 ti_drivers_config.c 设置。  对于 SPILPF3DMA.c 中的 SPI_open 调用初始化也是如此、请注意  GPIO_setConfigAndMux 如何为每个 SPI 引脚设置 IO 配置和外设多路复用。  如果您选择不重复打开/关闭 SPI、则需要复制类似的模式。

这会忽略这样一个事实、即我已经确认 CC2340R5 SPI 控制器模式不会消耗额外的基线电流、否则使用外部闪存器件的片外 OTA 示例在休眠节点中会表现不佳。  在“待机“状态下、SPI 引脚的一个电平 (SCLK、PICO、POCI、CSn) 可能不正确、这可能会导致 CC2340R5 和 Sub1G 器件之间出现额外的泄漏。  仔细查看 Sub1G 数据表、并筛选 SPI 引脚以确定最佳引脚电平、从而优化功耗。

此致、
Ryan