TI中文支持网最近在做项目的时候，出现一个很诡异的问题，用CC2541 做BLE的时候，偶发出现不广播的现象，一旦出现不广播，必须要通过重新上电才能恢复，蓝牙协议版本是1.4的，而且在不广播的时候，CC2541的其他功能是可以正常工作的。跪求高手出现，帮助解答。
Susan Yang：
您是不是设置了广播的参数（受限的广播）？一直广播的话功耗会很高
Bernie hou：
回复 Susan Yang:
我们的设置的广播间隔是5S一次，在我们的应用层，没有主动广闭广播的操作。您说的受限的广播是指什么？
Bernie hou：
回复 Susan Yang:
我们没有设置受限广播，就是一直广播的#define DEFAULT_DISCOVERABLE_MODE GAP_ADTYPE_FLAGS_GENERAL
shen renren：
遇到过类似的问题，查找原因是 因为程序中存在软延时，软延时的时间大于广播间隔引起的。由于CC2541是51内核，处理能力有限，所以项目中尽量使用定时器延时，建议不要使用软延时。还有，建议你查一下有没有子程序耗时很长，也会引起广播稳定性。
Bernie hou：
回复 shen renren:
如果是因为延迟造成的，在延迟结束后，应该会重新开始广播吧，协议里面，会存在一次广播不成功后，进入一个永远不广播的状态吗？
shen renren：
回复 Bernie hou:
软延时结束后不会重新关闭，会出现永远不广播的状态。软延时会严重影响广播的稳定性，这个我们在做项目的时候遇见过。建议您尽量少用软延时，并减少子进程消耗的时间，优化好的程序 也会增强系统的稳定性
Bernie hou：
回复 shen renren:
感谢您的回复。这个重新关闭的过程是在底层实现的么，上层能控制吗？如果是因为在广播的时候有软延迟，导致不能关闭，那么即使不用软延迟，其他子进程也能干扰广播吧，也就是说这是一个无法完全避免的问题，只能减小发生的概率么？
ziliang xu：
你好，我也有遇到这种情况，你解决了吗？
ziliang xu：
回复 Susan Yang:
广播类型是GAP_ADTYPE_ADV_IND，注释上面也有写General discoverable mode advertises indefinitely，但是我这边也出现了显示是广播状态，但是实际上外部设备再也搜不到这个设备了，需要重启
cedar_xuesong：
回复 shen renren:
学习ing
