亲爱的技术支持，
我正在使用我们自己的定制板，当我尝试将其切入外部睡眠模式时，我有一些局部。
当我的板从外部睡眠中醒来时，它将执行以下代码：
if（（development_debug）&&（use_power_optimizations））
{
slp_period_retated = 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核心活动），并且它为BLE核心唤醒的时间唤醒，因此在禁用中断时的LP_Handler时的时间，因此ISR延迟执行（在某些时候，中断被启用，但处理程序未按时执行），这意味着设备睡眠时间长于定义的时间，并且发生断言。如果删除断言，如果设备已连接，则会松开活动，这可能是一个问题，因为它可以轻松地删除连接。
谢谢mt_dialog.
嗨mt_dialog，
感谢您的回复。
我确定我没有用ble_wakeup_lp_handler做出任何改变，没有延迟唤醒ble的唤醒（代码是dsps的例程，如果它不在上面提到的两个点上运行）
我不是很容易理解你的描述。这意味着我的设备睡到了很多时间？它会影响我的ISR？在我的理解中，内核定时器溢出将触发中断，我将一个计时器设置为系统时基础。所以每1秒钟将醒来，我不认为这是睡眠很长。我可以解决这个问题问题？
另一个问题是使用ISR.IS BLE_WAKEUP_LE_HANDLER函数在启用全局中断后使用？为什么不能使用其他中断，或者它无法执行ISR？（或因为睡眠时间太长了？）
我觉得很困惑。
谢谢杰里
嗨杰瑞，
从本质上说，这意味着LP\u handler花了太多的时间来执行，而您得到的警告意味着BLE core花了更多的时间来唤醒计算出的值。sleep\u lp\u cycles是ble核心睡眠前的编程睡眠量，slp\u period是设备最终醒来时测量的实际睡眠时间，因此如果实际睡眠时间大于编程睡眠时间，则存在问题（ble事件丢失）。
当涉及到BLE时，SDK是这样工作的，设备计算睡眠量，在这个睡眠量中，BLE\u LP\u处理程序应该被触发，现在，如果LP\u处理程序由于任何原因延迟执行，那么实际的睡眠时间将比计算的睡眠时间长，这意味着设备不会及时醒来以服务于BLE事件。您看到的内容与内核计时器或您指示设备睡眠的程度无关。
关于你如何解决问题，就像上面提到的那样，在设备唤醒时看到这种行为，并且中断被禁用但是
BLE Core正在睡觉，因此如果它的BLE核心唤醒的时间LP_Handler不会在那时执行，直到中断被重新启用，因此设备
自从BLE核心并没有及时醒来，将错过BLE活动。所以请检查您是否手动禁用代码的任何部分中的中断。
我不太得到最后一个问题，所以将解释唤醒如何发生唤醒，当设备跌至睡眠时，它会禁用中断的WFI（）（这意味着中断，但是处理程序不会被调用），因此，在BLE_LP中断中，M0将唤醒，并且它将执行的第一个命令是启用中断，以便为LP_Handler提供服务。
此外，在检查上述任何内容之前，请尝试此操作并检查此工作是否适用于将Bandgap_reg的LDO_RET_TRIM设置为在设备进入时循环之前的值9。
谢谢mt_dialog.
嗨mt_dialog，
我已经解决了我的问题。谢谢你的帮助。
断言警告的第一个问题（0）；在我把IIC设备的初始化放在periph_Init（）函数中之前，可能IIC操作花费了很多时间，这会产生一些问题。现在，我在while循环中设置了一个标志并初始化IIC设备，它可以正常工作。
ISR的另一个问题，即我没有做一些正确的设置，我找到并解决了它们。
再次感谢你的帮助。