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.

[参考译文] CC2340R5:通知时运行至 iCall_abort ()

Guru**** 2589300 points
Other Parts Discussed in Thread: LP-EM-CC2340R5

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1366686/cc2340r5-run-into-icall_abort-when-notifying

器件型号:CC2340R5

工具与软件:

您好!

环境:

硬件 LP-EM-CC2340R5
代码编写器 12.7.1.00001
SDK

开启时出现相同现象

SIMPLELINK-LOWPOWER-F3-SDK

7.40.00.64

8.10.00.55

我正在使用 CC2340进行 MCU (UART 已连接)和手机之间的通信。

最大消息大小约为2058字节。

作为标题,在通知时 CC2340可能会运行到 iCall_abort ()。

我通过修改数据流简化了问题示例:

1.用户连接到数据流并请求 MTU 517

2.在用户写入回声特性时,CC2340开始每秒通知2058个字节。 但即使将周期延长至2秒、也会发生相同的问题。

3.在200~400 μ s 通知后,CC2340运行到 iCall_abort ()中,调用 stack :

PDU 配置:

连接参数:

当然,响应反大小写字符的原始示例代码被调用 start_tx_test()以开始通知测试所取代。

主函数如下所示:

#define TX_LEN_  (2058)
static uint8_t tx_data[TX_LEN_];

static sem_t sem_start_tx;
static sem_t sem_tx_done;

void start_tx_test()
{
    sem_post(&sem_start_tx);
}

static void VNG_UART_to_BLE(char *pData)
{
    DSP_sendData(tx_data, TX_LEN_);
    sem_post(&sem_tx_done);
}

static void *UART_tx_Thread(void *arg0)
{
    sem_wait(&sem_start_tx);
    uint8_t cnt = 0;
    while(1)
    {
        memset(tx_data, cnt, TX_LEN_);

        if(BLEAppUtil_invokeFunctionNoData(VNG_UART_to_BLE) != SUCCESS)
        {
            while(1){}
        }
        sem_wait(&sem_tx_done);

        cnt += 1;

        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

void start_thread()
{
    if(sem_init(&sem_start_tx, 0, 0))
    {
        while(1){}
    }
    if(sem_init(&sem_tx_done, 0, 0))
    {
        while(1){}
    }

    pthread_t thread;
    pthread_attr_t attrs;
    struct sched_param priParam;
    int retc;

    /* Initialize the attributes structure with default values */
    pthread_attr_init(&attrs);

    /* Set priority, detach state, and stack size attributes */
    priParam.sched_priority = 1;
    retc  = pthread_attr_setschedparam(&attrs, &priParam);
    retc |= pthread_attr_setdetachstate(&attrs, PTHREAD_CREATE_DETACHED);
    retc |= pthread_attr_setstacksize(&attrs, 1024);
    if (retc != 0)
    {
        /* failed to set attributes */
        while (1) {}
    }

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

有人可以告诉我为什么 iCall_abort ()会被触发只是为了连续通知吗?

非常感谢

春民

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Chunmin:

    感谢您与我们联系。

    我是否可以要求您指定使用的连接间隔? (问这个问题、因为很遗憾、您分享的屏幕截图没有显示实际使用的连接间隔)。
    为了检查连接间隔、可以遵循以下两种方法之一:

    我希望这将有所帮助、

    此致、

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    高克莱门特

    当仅与手机连接时、无线电 TX 引脚具有最大135ms 周期活动、无线电 RX 引脚具有持续45ms 的周期活动。

    当 CC2340开始连续通知时、无线电 TX 具有最大135ms 周期活动、无线电 RX 具有恒定的45ms 周期活动。

    在无线电 TX 引脚上有一些活动集群、看起来像是 CC2340正在通知。

    这些是否会意外出现并导致 CC2340运行到 iCall_abort ()中?

    谢谢

    春民

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的  Chunmin:

    感谢您进行检查、我在这里没有看到任何可能导致 ICall_abort 的意外行为。

    您能否检查变量  l2capNumDataPkts 并确保没有溢出、正如我在该线程 (+) CC2340R5中所述:CC2340充当中心角色、并且遇到数据传输故障问题。 -蓝牙论坛- BluetoothRegistered︎ 支持论坛- TI E2E 支持论坛

    为了加快调试速度、您还可以提供蓝牙监听器日志吗?

    此致、
    丹桂语

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Tanguy:

    当 CC2340开始运行且无连接时、它为0x3FFFF0C。

    在 连续通知期间、我可以看到该值不断升高并绕回为0x3FFFF00、然后再次不断升高。

    当 CC2340在 l2capNumDataPkts 绕回某些轮之后运行到 iCall_abort ()中时、它为0x3FFFF00。

    谢谢!

    春民

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的  Chunmin:

    感谢您测试溢出、我想检查是否可以 通过减少发送的片段数量来防止溢出。 首先、您能否使用蓝牙监听器检查在一次通知中发送了多少个 LL 数据包?

    此致、
    丹桂语

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Tanguy:

    我没有嗅探器。

    尝试了不同长度的通知数据:

    • 10:l2capNumDataPkts 保持 0x3FFFF0C、在连续通知期间不会绕回
    • 100:l2capNumDataPkts 不会环绕
    • 200:l2capNumDataPkts 不会环绕
    • 300:l2capNumDataPkts 不会环绕
    • 400:l2capNumDataPkts 不会环绕
    • 500:l2capNumDataPkts 不会环绕
    • 1000:l2capNumDataPkts 不会环绕
    • 1500:l2capNumDataPkts 在通知时绕回、当0x3FFFF00时运行到 iCall_abort
    • 1400:l2capNumDataPkts 在通知时绕回、当0x3FFFF00时运行到 iCall_abort
    • 1300:l2capNumDataPkts 在通知时绕回、当0x3FFFF00时运行到 iCall_abort
    • 1200:l2capNumDataPkts 不会环绕

    如果 l2capNumDataPkts 未回绕、CC2340可以在不运行到 iCall_abort 的情况下通知超过1000次。

    谢谢

    春民

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Chunmin:

    对于测试,您是否可以尝试将 PDU 的数量增加到13并检查您是否可以通知1300字节的数据?

    此致、
    丹桂语

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Tanguy:

    将最大 PDU 数量扩大到13个或32个甚至200个后、l2capNumDataPkts 仍会绕回并在连续通知1300字节时运行到 iCall_abort。

    谢谢

    春民

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    感谢您的测试、就我们而言、我们设法重现了错误、并且我们正在努力寻找解决方法。

    我会随时向大家介绍我们取得的最新进展、

    此致、
    丹桂语

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Tanguy:

    谢谢你。

    我们期待着解决这个问题。

    春民

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    大家好、  

    请帮助更新此问题的状态。

    谢谢。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    我们已本地化问题、并正在解决问题、有关更多详细信息、请联系您当地的 FAE 或支持团队。

    此致、
    丹桂语

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    此问题应在 F3 SDK 的8.10.01.02版本中修复、是否可以将您的 SDK 版本升级到此版本并报告此问题是否仍然可重现?

    下载链接: SIMPLELINK-LOWPOWER-F3-SDK 软件开发套件(SDK)| TI.com

    此致、
    丹桂语

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Tanguy:

    现在它可以在超过30分钟的时间内通知2058字节每秒,而不会 出现 iCall_abort ()和 l2capNumDataPkts 溢出。

    谢谢!

    春民