亲爱的技术支持者，
我正在使用自己的自定义板，当我尝试进入外部睡眠模式时，我会有一些问题。
我的董事会从外部睡眠醒来时遵循代码：
if（（（开发_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
assert_warning（0）;//（在这里输入）
}
}
我不知道为什么它会来到这里，这是我的中断功能占用太多时间吗？
我评论了development_debug的宏来跳出。看起来没问题，我不知道我是否对。
当系统一次唤醒后运行时，它不会触发中断。（它是一个GPIO引脚的外部中断），同时我的串行中断无法触发。
你能给我一些建议吗？
谢谢杰里
设备：
嗨，杰里，
您是否完全更改了ble_wakeup_lp_handler或通过禁用中断来延迟BLE的唤醒？如果您到达那里，则意味着您花了太多时间睡觉，并且您将无法按时醒来，因此SDK警告您这一点。如果580处于活动状态（没有BLE核心活动），则可能会发生这种情况，并且在禁用了中断的时间以及BLE核心醒来的时间，因此在某些时候，当它用于LP_HANDLER的时间时，由于破坏了ISR延迟执行，因此LP_HANDLER的执行时间（在某个时候，中断已启用，但处理程序未按时执行），这意味着设备的睡眠时间比定义的时间更长，并且会发生断言。如果您删除断言，则会松动事件，如果设备连接，则可能会出现问题，因为它可以轻松删除连接。
谢谢mt_dialog
嗨mt_dialog，
感谢您的回复。
我敢肯定，我没有对BLE_WAKEUP_LP_HANDLER进行任何更改，也没有延迟BLE的唤醒（如果该代码不在DSP的例程上，则该代码在上面提到的两个点上没有操作）
我无法很好地理解您的描述。这意味着我的设备会睡很多时间吗？这会影响我的ISR吗？在我的理解中，内核计时器溢出会触发中断，我将计时器设置为系统时间群。问题？
在启用全局中断之后，使用ISR.IS ble_wakeup_le_handler函数的另一个问题是？为什么它不能使用其他中断或无法执行ISR？（或者因为睡眠时间太长？）
我感到非常困惑。
谢谢杰里
嗨，杰里，
从本质上讲，这意味着LP_HANLDER花了太多时间来执行，并且警告您获得的警告意味着BLE核心花费了更多的时间才能唤醒该计算值。Sleep_lp_cycles是在BLE核心睡眠之前的编程睡眠量，SLP_Period是设备最终醒来时测量的实际睡眠，因此，如果实际睡眠大于编程的实际睡眠，那么我们就会出现问题（缺少BLE事件）。
当涉及到这样的工作时，设备计算睡眠量，在该睡眠金额中，应触发ble_lp_handler，现在，如果出于任何原因，LP_Handler延迟执行的情况将比计算出的一个且而不是意味着该设备不会及时醒来以服务BLE事件。您所看到的与内核计时器或指导设备入睡的程度无关。
关于如何解决问题，正如我上面提到的那样
BLE Core正在睡觉，因此，如果它的时间唤醒了BLE核心，则LP_HANDLER不会在当时执行，直到重新启用中断为止，设备
由于BLE核心没有及时醒来，因此会错过BLE活动。因此，请检查您是否在代码的任何部分中手动禁用中断。
我不太了解最后一个问题，因此可以解释如何发生唤醒，当设备落入睡眠时，它将停留在WFI（）中，而中断会被禁用（这意味着中断会发生，但不会调用处理人员），因此，在BLE_LP中断中，M0将唤醒，并且它将执行的第一个命令是启用中断，以便为LP_HANDLER服务。
同样，在检查上述任何内容之前，请尝试此操作，并检查此功能是否适合您将bandgap_reg的ldo_ret_trim设置为“值9”。
谢谢mt_dialog
嗨mt_dialog，
我解决了我的问题。谢谢您的帮助。
警告Assert_warning的第一个问题（0）;在将IIC设备的初始设备放在periph_init（）的Function中之前，也许IIC操作花费大量时间，它使一些Proble M.现在，我设置了一个标志，并在while循环中启动了IIC Devie，它可以正常工作。
ISR的另一个问题，那是我没有做一些正确的设置，我发现并解决了这些设置。
再次感谢你的帮助。