在进入深度睡眠之前需要检查BLE堆栈吗

如果在单核心上实现BLE，BLE中断可以唤醒设备从深度睡眠。你能给我指一个确切的例子吗？
如果您已经在双核上实现了BLE，请参考KBA：将核心设置为深度休眠模式，同时在PSoC®6上启用BLE功能-KBA223
谢谢，
希马



     以下为原文
  In case of BLE implemented on single core the BLE interrupts can wake the device from deep sleep. Can you point me to the exact example project?
In case you have implemented BLE on dual core please refer to the KBA: Setting Cores to Deep Sleep Mode while BLE Function is Enabled on PSoC® 6 – KBA223291
 
Thanks,
Hima

我们提到的例子项目AN219528 - PSoC（R）6 MCU低功耗模式和功率降低技术，使用双核。但我们只使用单核实现，不确定是否使用单核和双核之间存在深度差异。然而，你提供的链接回答了我们的很多问题。
但是我们仍然不确定为什么（1）中描述的行为仍然在发生。在情况（1）中，当BLE没有广告/连接时，祝福中断永远不会触发，所以我们认为系统应该仍然能够成功地进入深度睡眠。然而，在我们按下开关重新启动广告之后，系统可以再次成功地进入深度睡眠。
谢谢，
史蒂夫



     以下为原文
  We were referring to the example project AN219528 - PSoC(R) 6 MCU Low-Power Modes and Power Reduction Techniques which uses dual cores. But we are only implementing with single core and weren't sure if there were differences between deep sleep using single and dual core. However the link you provided answers a lot of our questions.
 
But we're still unsure why the behavior described in (1) is occurring still. In case (1), the bless interrupt is never triggering when ble is not advertising/connected so we are thinking the system should still be able to successfully enter deep sleep. However after we restart advertisement by a switch press, the system can enter deep sleep successfully again.
 
Thanks,
Steve

我们已经解决了（1）中所描述的问题。结果是，我们只调用了一个回调函数中的CythBuriPraseSeVScript（），它没有被调用，因为如果蓝牙没有广告，没有设备连接，则祝福中断不会触发。事实证明，即使没有广告/设备连接，也应该调用CyBLyPrExeSeVScript（）。
这就引出了我们的后续问题：在祝福中断旁边是否存在另一个内部中断？我们注意到，当蓝牙不是广告，没有设备连接时，系统成功地进入睡眠状态。但是，经过一段时间后，它醒来，并要求调用CYBLYPROCESSEVSEN（）调用API，才能成功恢复睡眠。我们知道这不是祝福中断唤醒系统，因为我们已经注册了一个回调函数到祝福中断，该函数没有被调用。
我们附上了我们目前正在测试的代码，如果它能帮助我们更好地理解上面所描述的内容。排除和包含第102行，我们在这里评论“在这里”看到UART中打印出来的不同结果。在排除，系统成功进入深睡眠开始后但未在其上。
最好的，
史蒂夫
深度睡眠模式
11.7兆字节



     以下为原文
  We've fixed the issue described in (1). In turns out because we were only calling Cy_BLE_ProcessEvents() in a callback function attached to the bless interrupt, the API was never getting called because the bless interrupt doesn't trigger if bluetooth is not advertising and no device is connected. It turns out Cy_BLE_ProcessEvents() should still be called even if there is no advertisement/device connection.
 
That leads to our follow up question: is there another internal interrupt beside the bless interrupt? We notice that when bluetooth is not advertising and no device is connected, the system successfully goes to sleep. However, after a little while it wakes up and requires API call of Cy_BLE_ProcessEvents() before it can successfully return to sleep. We know it's not the bless interrupt waking up the system since we've registered a callback function to the bless interrupt and that function does not get called.
 
We've attached the code that we are currently testing if it helps to get a better context of what we've described above. Exclude and include line 102 where we've commented "Here" to see the different results printed out in UART. On exclusion, the system successfully goes into deep sleep initially but fails thereon after.
 
Best,
Steve

•   DeepSleepMode01.cydsn.zip 11.7 MB