亲爱的TechnicalSupport,
我用的是我们自己的定制板，当我尝试把它调到外部睡眠模式时，我遇到了一些问题。
我的董事会遵循代码，当它从外部睡眠醒来:
if ((DEVELOPMENT_DEBUG) && (USE_POWER_OPTIMIZATIONS))
｛
slp_period_retained = slp_period;
//如果这个断言命中，那么LP ISR持续的时间比时间长
//通过LP_ISR_TIME_XTAL32_CYCLES和LP_ISR_TIME_USEC被保留。
If (sleep_lp_cycles && (sleep_lp_cycles < slp_period))
｛
ASSERT_WARNING (0);/ /(这里进入)
｝
｝
我不知道它为什么会在这里，是我的中断功能占用了太多的时间吗?
我注释掉了宏DEVELOPMENT_DEBUG以跳出来。看起来没有问题，我不知道我是不是对的。
当系统运行一次唤醒后，不能触发中断。(它是一个来自GPIO脚的外部中断)，同时我的串行中断不能触发。
你能给我一些建议吗?
谢谢你杰里
设备:
嗨,杰瑞,
你是否改变了BLE_WAKEUP_LP_Handler或者通过禁用中断来延迟BLE的唤醒?如果你到达那里，这意味着你花了太多的时间睡觉，你不能按时醒来，所以SDK会警告你这一点。这也可能发生,如果580活跃(没有祝福核心活动)与禁用中断及其时间祝福核心醒来,所以在某些时候当以来时间LP_Handler执行中断禁用ISR延迟执行(在某种程度上启用中断,但处理程序没有执行时间),这意味着设备的睡眠时间超过了定义的时间，并且会发生ASSERTION。如果您删除断言，您将丢失事件，如果设备已连接，这可能是一个问题，因为它很容易删除连接。
由于MT_dialog
嗨MT_dialog,
谢谢你的回复。
我确信我没有对BLE_WAKEUP_LP_Handler做任何更改，也没有延迟BLE的唤醒(代码是基于dsp的例程，如果它不操作上面提到的两个点)
我不是很理解你的描述。这是否意味着我的设备睡眠时间很长?这会影响我的ISR吗?在我的理解中，内核计时器溢出将触发一个中断，我设置一个计时器作为系统时间基础。所以，它每一秒就会醒来，我不认为这是一个长时间的睡眠。我该如何解决这个问题?
另一个问题是ISR。启用全局中断后是否可以使用BLE_WAKEUP_LE_Handler函数?为什么不能使用其他中断或者不能执行ISR?(还是因为睡眠时间太长?)
我感到很困惑。
谢谢你杰里
嗨,杰瑞,
本质上，这意味着lp_handler花费了太多的时间来执行，而您得到的警告意味着BLE核心需要更多的时间来唤醒计算值。sleep_lp_cycles是ble核心睡眠之前的编程睡眠量，slp_period是设备最终醒来时测量的实际睡眠量，所以如果实际睡眠大于编程的睡眠量，那么就会出现问题(缺少ble事件)。
当涉及到BLE时，SDK是这样工作的，设备计算睡眠量，在睡眠量中BLE_LP_Handler应该被触发，现在，如果由于任何原因，LP_Handler延迟执行，实际的睡眠周期将比计算的长，这意味着设备不能及时唤醒以提供BLE事件。您看到的内容与内核计时器或您指示设备睡眠的程度无关。
关于如何解决这个问题，正如我上面提到的，这种行为是在设备是醒着的，并且中断是禁用的，但是
BLE核心处于睡眠状态，所以如果它是BLE核心的唤醒时间，LP_Handler将不会在此时执行，直到中断重新启用，所以设备
将错过BLE事件，因为BLE核心没有及时醒来。因此，请检查您是否在代码的任何部分手动禁用中断。
我不太明白最后一个问题，所以将解释如何唤醒发生，当设备陷入睡眠，它停留在WFI()与中断禁用(这意味着中断将发生，但处理程序不会被调用)，因此，在BLE_LP中断中，M0将被唤醒，它将执行的第一个命令是启用中断，以便为LP_Handler服务。
另外，在检查上述任何事情之前，请尝试这个方法，并检查它是否适用于您将BANDGAP_REG的LDO_RET_TRIM设置为9，就在设备进入while循环之前。
由于MT_dialog
嗨MT_dialog,
我已经解决了我的问题。谢谢你的帮助。
第一个ASSERT_WARNING(0)的警告问题;在我将IIC设备的Init()放到外围Init()函数中之前，可能IIC操作花费了很多时间，这会造成一些问题。现在，我设置了一个标志并在while循环中Init IIC设备，它可以正常工作。
isr的另一个问题是，我没有做一些正确的设置，我发现并解决了它们。
再次感谢你的帮助。