TICC2540主从机频繁断开连接后不能正常建立连接

只看该作者 · 2015-3-17 15:16

本帖最后由 David~ 于 2015-3-17 18:00 编辑

各位朋友好！

我在做项目时，用的是TIcc2540和BLE协议栈，涉及到低功耗处理，项目的设想是：建立连接后，发送数据，然后再断开连接，进入低功耗模式，按键触发后唤醒然后再建立连接、发送数据、再断开连接，如此的往复处理。这些操作都是主机上面实现的。

现在发现个问题，如果按键触发唤醒的频率低，一秒按一下按键的情况下，主机处理完断开连接的命令后，从机能够马上接收到断开连接事件然后进行下一步的操作；

如果按键触发唤醒的频率高，一秒钟迅速按下按键好几次的情况下，主机处理完断开连接的命令后，主机这里收不到底层已经断开连接的事件GAP_LINK_TERMINATED_EVENT，从机也收不到断开连接的事件GAP_LINK_TERMINATED_EVENT，必须等待3到5秒等待从机timeout之后从机才会断开连接，进入发送广播的状态，然后主从机才能再次建立连接进行通信。
调试了很久，都不能解决这个问题，烦请各位朋友大神能帮忙分析下哪里出了问题，万分感谢！

只看该作者 · 2015-3-17 15:59

为什么休眠非要断开链接？

只看该作者 · 2015-3-17 17:58

罗菜鸟发表于 2015-3-17 15:59
为什么休眠非要断开链接？

进入休眠后主从机没有通讯后，就必须等到从机timeout才会断开连接，那timeout这段时间别的主机想连接到从机就连接不到了，所以需要个手动断开连接处理，只要当前连接的主机完成数据操作，就断开连接，让其他设备接入。

3万 · 2015-3-17 21:35

是不是按键处理代码干扰或者影响到了通讯？

只看该作者 · 2015-3-18 15:08

本帖最后由 David~ 于 2015-3-18 15:10 编辑

dirtwillfly 发表于 2015-3-17 21:35
是不是按键处理代码干扰或者影响到了通讯？

这个也已经考虑进去了，我在按键中断服务程序里面已经把按键的中断给屏蔽了，而且在主从机建立连接后让代码进入了临界区，等待“断开连接函数”执行后再退出临界区，并且在“断开连接成功的事件”处理代码中把按键中断再打开，这样就能保证再建立连接到成功断开连接这段时间里按键中断是不工作的，只能等完全断开连接才使能按键中断。

=================================================================

我现在调试代码，发现尽管CC2541跑BLE1.3.2的协议栈进入PM3的深度休眠后，还能收到主机断开连接的事件，再处理完断开连接的事件后，就不能再次进入休眠了，按照TI程序的定义，PM3所有的的时钟都是关闭的，只能外部IO唤醒，现在程序却能被事件唤醒，很奇怪啊！

通过调试，已经发现是主机这边协议栈处理断开连接的流程太慢了，虽然主从机已经断开连接，但是主机这边的协议栈底层还不能识别到已经断开连接，所以在GATT层还扫描不到从机，不知道为何底层会这么慢啊！

只看该作者 · 2015-3-18 15:27

这个问题是和BLE4.0的协议有关系的，server端主动断开的时候client端是不能马上判断为连接断开的，因为在BLE4.0的协议里面考虑的一个允许丢包数量和时间的问题，如果要达到这个马上响应的效果，那必须把协议里的允许丢包数量改为0，这样一旦有收不到server的数据包就马上判断为连接断开，这样client才能响应disconnet的函数。但是这样改动之后呢有一个稳定问题，因为BLE4.0的功耗很低，比较容易受到环境的影响，比如说距离，穿透能力等，改动之后一旦有收不到数据包就会断开的了，会很容易断开连接。

只看该作者 · 2015-3-18 15:39

黄微尘发表于 2015-3-18 15:27
这个问题是和BLE4.0的协议有关系的，server端主动断开的时候client端是不能马上判断为连接断开的，因为在BL ...

你说的那个允许丢包数量的事情是指的从机忽略主机通讯个数吧？就是SLAVE_LATENCY，我程序里面这个值是设置为0的，就是不允许有忽略。
另外断开连接是主机端主动断开连接的，（现在的情况是频繁的断开再建立连接）偶尔主机自己发送的断开连接请求，从机都能完全响应（断开连接再进入广播模式），主机自己却不能识别到已经完全断开连接了，要等几秒钟之后主机协议栈底层才处理完断开连接的流程，然后从底层返回到GATT层一个GAP_LINK_TERMINATED_EVENT，在收到这个事件之前，主机扫描不到任何的从机，因为底层还处于上次连接的状态之中！

不明白为何会这样啊！自己发送断开连接请，被断开的设备都能识别到已经断开，发送断开请求的一方自己却不能识别到已经断开连接，很荒唐啊！

只看该作者 · 2015-3-18 16:04

本帖最后由黄微尘于 2015-3-18 16:10 编辑

收数据的那端有三个参数的，connection interval \ slave latency \ supervision timeout ,应该就是这三个参数的问题了，你试试把supervision timeout 这个参数也设置成100ms看看。

只看该作者 · 2015-3-18 18:17

黄微尘发表于 2015-3-18 16:04
收数据的那端有三个参数的，connection interval \ slave latency \ supervision timeout ,应该就是这 ...

谢谢楼上的提醒，我没有进行连接参数的设置，用的是TI底层默认的参数进行连接，因为更新连接参数很耗时，我们希望每次建立连接到断开连接的过程足够短，所以就没有更新这些参数，不过通过Debugg看的出来这些参数的值分别是 80 0 和2000 单位都是ms。这些都是我的主机上面的信息，也就是出问题的那个设备上的信息。

只看该作者 · 2015-3-19 10:31

问题解决了吗？你是修改了那个参数呢？

只看该作者 · 2015-3-19 15:34

黄微尘发表于 2015-3-19 10:31
问题解决了吗？你是修改了那个参数呢？

参数没有修改，现在发现是TI的休眠和任务处理不同步造成的，系统还未处理完断开连接的事件（指的是还未收到GAP_LINK_TERMINATED_EVENT事件），就已经进入了PM3低功耗，现在同步之后就能正常了，但是让我纳闷的是，为何系统都进入了PM3低功耗了，还能被事件唤醒呢，而且唤醒后就再也进入不了低功耗了，但是此时程序并不是跑飞了，因为再次按按键再次触发连接、发数据、断开连接后，又能正常进入低功耗！

1万 · 2015-3-19 19:59

从低功耗的角度去考虑的话，，在休眠状态下，尽量断开所有的外设及通讯的。

3万 · 2015-3-19 20:33

David~ 发表于 2015-3-19 15:34
参数没有修改，现在发现是TI的休眠和任务处理不同步造成的，系统还未处理完断开连接的事件（指的是还未收 ...

从通讯的角度考虑，mcu就该被事件从低功耗状态唤醒。
可能有些程序的逻辑有些问题

只看该作者 · 2015-3-19 21:53

注意控制逻辑上的事情就好了。

只看该作者 · 2015-3-20 09:43

dirtwillfly 发表于 2015-3-19 20:33
从通讯的角度考虑，mcu就该被事件从低功耗状态唤醒。
可能有些程序的逻辑有些问题 ...

低功耗有不同的休眠深度，TI的这款芯片进入PM3的休眠深度后就已经把所有的时钟关闭了，只能外部IO口唤醒的，也已经和他们技术支持确认过PM3只能外部IO口唤醒，这个进入PM3能被底层事件唤醒的问题现在也没找到原因，估计是底层协议栈处理PM3的休眠等级的时候实际上并没有关闭RTC，不过上层看不到底层的处理过程，只能猜测了。TI的技术支持也搞不明白是咋回事。

只看该作者 · 2015-3-20 09:49

comeon201208 发表于 2015-3-19 19:59
从低功耗的角度去考虑的话，，在休眠状态下，尽量断开所有的外设及通讯的。 ...

恩，TI的进入休眠的流程也是这样的，等待所以任务处理完毕，然后关闭所有外设，进入休眠。不过还是没有想通TI的PM3休眠深度为何还能被底层事件唤醒，按照他们的定义PM3是关闭了所有时钟的，只能外部IO口硬件唤醒。

只看该作者 · 2015-9-11 13:43

你好，我好像也出现类似问题，后面你是怎么做到同步的？

只看该作者 · 2016-10-17 10:52

是否是你的程序实际上是進入了PM2

TICC2540主从机频繁断开连接后不能正常建立连接

相关下载

相关帖子

伴坛终老

技术奇才奖章

欢快之小溪

社区建设奖章

永恒之光奖章

坚毅之洋流

十世金身

技术领袖奖章

经常做客

技术新星奖章

突出贡献奖章

湍急之河流

常驻人口

技术高手奖章

偶尔光临