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.

[参考译文] CC2541:新堆栈中的 BLE 时序问题

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1433600/cc2541-issue-with-ble-timing-in-new-stack

器件型号:CC2541

工具与软件:

嗨、团队:

我遇到一些与在 电路板上使用2个 CC2541芯片(一个主器件和另一个从器件)的客户的时序问题。 他们在将堆栈更新为主芯片上的 BLE 1.5.2时没有问题。 然而、当他们将从芯片从1.3.1升级到1.4.1甚至是1.5.2时、就会遇到同样的问题、即不再获得任何 SYS_EVENT_MSG。 他们还在从器件上将最小和最大连接间隔更新到了8和10、但根本没有任何帮助。  

感谢您可以就此问题提供任何建议。

在 SimpleBLECentral 中、

 if ( events & SYS_EVENT_MSG )
    {
        uint8 *pMsg;
        if ( (pMsg = osal_msg_receive( ALPReceiverSlaveBLETaskId )) != NULL )
        {
            simpleBLECentral_ProcessOSALMsg( (osal_event_hdr_t *)pMsg );
           
            // Release the OSAL message
            VOID osal_msg_deallocate( pMsg );
        }
        // return unprocessed events
        return (events ^ SYS_EVENT_MSG);

我还有一个问题来自 gap.h 它看起来像结构 gapEstLinkReqEvent_t 有一个被定义为 connRole 的新变量、说明中说连接形成为主器件或从器件。  此变量除了定义角色之外还有什么其他目的、因为它未包括在以前的版本中、但仍能按预期工作?

谢谢!

Luke

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

    Luke、您好!

    感谢您的咨询。 我们会尽快解答您的问题。

    BR、

    David。

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

    尊敬的 Luke:

    缺少的 SYS_EVENT_MSG 和未更新的连接间隔是否出现在定制工程或未修改的 SDK 示例中? 如果是在自定义工程中、那么您能否检查 SDK 示例中是否发生了同样的情况?

    此致、

    1月

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

    1月、

    它们有2个中央(均来自 simpleBleCentral 示例)、但只有第2个 中央存在此问题。  

    我们在 osal.c 中查看了函数 osal_run_system()、并在其索引任务中看到了 SYS_EVENT_MSG 事件0x8000、因此不明白为什么 SimpleB38nm Central_Process 不看到事件 SYS_EVENT_MSG。

    他们也不存在旧版 BLE 堆栈1.31的此问题。

    tasksEvents [idx]|=事件;  

    此致!

    Luke

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

    尊敬的 Luke:

    明白了、您能分享它们中间位置之间的主要差异吗? 也许了解它们之间的区别可以帮助我们找到可能发生的情况。

    此致、

    1月

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

    嗨、Jan、

    主中央设备执行所有处理和执行任务。 它通过 I2C 连接到次级中央。 次级中央将尝试与外设配对。 他们的配对没有问题、但是配对后、他们只从外设接收到1个或2个数据包、而在很长的时间内没有接收到更多数据包。 他们应该会以40ms 的间隔获得一个数据包。 他们想知道 BLE 1.5.2是否对主/从中央的行为进行了任何改变。  

    此致!

    Luke

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

    尊敬的 Luke:

    1.5.2版本中引入的唯一更改是与配对相关的修复、似乎与观察到的行为无关。 但是、1.3.1和以后的版本都包含许多变化。 所有这些资源的列表可在以下位置找到: https://software-dl.ti.com/simplelink/esd/ble_stack_1_x/1.05.02.00/exports/README.txt

    退后一步、您能否分享客户希望迁移的原因? 如果他们在原始 SDK 中具有稳定的解决方案、则可以保留以前的版本。

    此致、

    1月

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

    1月、

    客户最终自己找到了问题的原因。  他们 发现问题的原因是没有为其中一个句柄值发送 ATT 句柄确认。 添加代码以发送确认后、现在会看到数据包以40ms 的间隔传入。

    感谢您的帮助!

    Luke