创建了一个蓝牙任务 和 一个功能任务.

休眠等级是sleep.  休眠唤醒为 上升沿.

唤醒后,     整个系统卡死, 无法运行了.

如果在休眠前, 将蓝牙断开 ,关闭广播.  唤醒后,系统是正常运行的..

正常运行后,, 尝试再次启动蓝牙广播. 系统再次卡死

工程使用了 固定LIB.  0x50000位置 . APP工程编译大小如下.

麻烦帮忙分析一下.

在蓝牙程序中不要自己调用sleep，将HAL_SLEEP设置为TRUE，睡眠由协议栈控制就行。

tmos自己休眠的话, 只要有事件周期到了, 系统就会被唤醒, 我有好几个周期只有10ms的任务,功耗扛不住.

. 休眠前把事件全部停掉,只留一个长周期的监控唤醒事件,这样可以降低功耗,但有点麻烦,功耗还是比手动休眠的高.

产品在休眠的时候, 不需要蓝牙功能.  

如果休眠前 不对蓝牙进行任何处理,休眠唤醒后,系统会卡死.

休眠前断开蓝牙链接,并且关闭蓝牙广播,唤醒后可以正常运行, 一旦重新启动蓝牙广播, 系统依旧会卡死.

怎么解决这个情况呀.

不要在蓝牙工程中自己调用睡眠函数，

调用协议栈睡眠，只留一个周期长的任务和直接调用睡眠的功耗相差不大的。

@TECH_Hy 你好，想问一下，蓝牙程序中将HAL_SLEEP设置为TRUE，睡眠由协议栈控制，我里面有两个80和100ms用户程序不断在跑，这样怎么处理好

您好，使能了HAL_SLEEP后，只需关心何时唤醒执行事件即可；协议栈会根据当前的TMOS事件安排情况，在需要执行事件时唤醒MCU；协议栈判断两个事件之间的间隔大于预期（1ms），会自动安排休眠。

配置循环事件的方式①调用一次tmos_set_event立即执行一次事件，或调用tmos_start_task，在一定时长后延迟执行一次事件；事件处理函数（XXX_ProcessEvent）中，在事件逻辑执行完毕，return（return (events ^ XXX)）之前，再调用一次tmos_start_task，预先安排下一次调用该事件的时间点来形成循环。

方式②调用tmos_start_reload_task接口即可配置事件循环；调用tmos_stop_task停止事件循环。

类似的问题我之前也遇到过，我觉得官方人员不是应该建议使用HAL_SLEEP，而是应该解决楼主所说的唤醒后开启广播卡住的问题，这似乎是协议栈内部的处理存在未能预测的条件分支，因为协议栈不是开源的，所以工程师无法通过检查协议栈实现代码来测试程序。

虽然可以使用ida pro直接查看协议栈汇编代码，但是这很显然需要消耗很多精力来调试。即便是使用调试器调试，大量的代码显然也不如官方开发人员更为熟悉。

个人建议官方对协议栈进行优化处理。

对于楼主的问题，我提供的建议是，如果在常规方式不能被解决的时候，可以考虑使用data flash缓存必要的数据，然后直接执行软复位，然后读取data flash进行处理，空间充裕的前提下，可以使用多分区数据缓存，以实现磨损均衡。或在链接脚本设置相应的noinit，修改RAM范围，使软复位可以保留ram数据再进行处理。