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

admin

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

1 年多前

0 admin 1 年多前

TI__Guru**** 2502665 points

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

Luke、您好！

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

BR、

David。

0 admin 1 年多前

TI__Guru**** 2502665 points

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

尊敬的 Luke：

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

此致、

1月

0 admin 1 年多前

TI__Guru**** 2502665 points

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

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

0 admin 1 年多前

TI__Guru**** 2502665 points

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

尊敬的 Luke：

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

此致、

1月

0 admin 1 年多前

TI__Guru**** 2502665 points

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

嗨、Jan、

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

此致！

Luke

0 admin 1 年多前

TI__Guru**** 2502665 points

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

尊敬的 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月

0 admin 1 年多前

TI__Guru**** 2502665 points

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

1月、

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

感谢您的帮助！

Luke

Bluetooth®︎（参考译文帖）

Bluetooth®︎（参考译文帖）(Read Only)

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