嗨，对话，
现在我遇到了一个问题，UART在唤醒后无法工作。
参考ble_app_sleepmode示例项目，我添加了UART接收中断处理程序。
作为示例项目，我编写了如下唤醒回调。
静态孔隙enable_Wakeup_cb(空白)
{
如果(GetBits16 (SYS_STAT_REG PER_IS_DOWN))
{
GPIO_init ();
periph_init ();
}
SetBits32（GP_控制_注册，BLE_唤醒_需求，1）；
如果(arch_ble_ext_wakeup_get ())
{
拱设置睡眠模式（应用默认睡眠模式）；
arch_ble_force_wakeup ();
拱门可外接唤醒关闭（）；
app_easy_wakeup ();
}
}
但UART接收中断有时不会发生。
唤醒中断和GPIO INT正常工作，但UART接收INT。
我觉得UART初始化需要比GPIO更多的时间，所以我插入了几秒钟的定时器等待，并在等待后再次插入periph_init（）。
但结果是一样的。
你能告诉我起床后启动UART noramally的条件吗？
谢谢,
提奥奇尼斯
设备:
嗨,第欧根尼,
在ble_app_睡眠模式示例中，设备在app_ADV_DATA_UPDATE_TO（默认值为10秒）过期后进入深度睡眠模式，因此所有外围设备均断电。这意味着您无法在设备唤醒时进行UART活动。既然芯片被唤醒了，请确保您正在尝试使用UART，好吗？另外，如果你能多解释一点你想要实现的目标，这将是非常有帮助的。您希望在UART中发送数据时唤醒设备，还是希望在芯片唤醒后启动UART活动？如果您希望实现第一个选项，请注意，为了唤醒，您应该激活WKUP控制器，否则芯片将继续保持睡眠模式。另外，您能澄清一下您正在使用哪种UART吗？在ble_app_sleepmode示例中，仅实现UART2，您可以通过定义放置在da1458x_config_basic.h中的CFG_PRINTF宏来激活它
谢谢，下午好
嗨，对话，
谢谢你的评论。
对于APP_ADV_DATA_UPDATE_TO，我修改为1msec，我的程序是在唤醒后UART接收中断。
我用示波器测量了定时，并检查了UART接收的定时在唤醒后至少超过10秒。
但并没有检测到UART接收中断，我想UART接收中断本身也会工作，因为它是在几秒钟后检测到的。
所以我知道启用UART接收中断需要多少秒。
当然，UART接收中断和发送在我的程序正常工作。
那么我应该怎样做才能在唤醒后启用UART接收中断?
谢谢,
提奥奇尼斯
嗨，对话，
我能补充一些关于当前问题的信息吗?
首先，UART接收中断在wekeup后通常不会发生，我的程序有时会在rwble.c (ASSERT_WARNING(0);)中跳转到L.369。
如果（（开发调试）&（使用电源优化））断言警告（0）；//L.369
{
slp_期_保留=slp_期；
//如果此断言命中，则LP ISR的持续时间将长于此时间
//已通过LP_ISR_TIME_XTAL32_循环和LP_ISR_TIME_USEC保留。
if（睡眠周期&（睡眠周期
}
但是接收中断本身没有被发现，我必须判断这不是处理者的问题。
然后我怀疑arch_system.c()中的L.400唤醒延迟时间。
/ /其他USE_POWER_OPTIMIZATIONS
{
延迟=最小睡眠时间；
//如果XTAL_TRIMMING_TIME_USEC发生变化(即变大)，那么这个
//将确保用户得到通知，将“延迟”增加1或更多
//插槽，这样XTAL有足够的时间来解决
#如果（（3125+（最小睡眠时间+625））<（LP\U ISR\U时间\U USEC+1100））//1.1ms最大通电时间//L.395
#错误“对于使用的16MHz晶体，最小睡眠时间太小…”
#恩迪夫
}
rwip_wakeup_delay_set(延迟);/ / L.400
但考虑到L.395的限制，我明白不可能将最小睡眠时间改为1秒。
然后我认为这是睡眠模式的问题，于是我重写了arch_set_deep_sleep（）；到拱_集_延长_睡眠（）；在void user\u app\u adv\u start（void）中，结果相同。
不管怎样，现在我很迷茫。
请告诉我有用的信息来解决它。
谢谢,
提奥奇尼斯
嗨，对话，
我必须补充更多关于当前情况的信息。
我注意到在调试时mu程序不进入if(arch_ble_ext_wakeup_get())子句，尽管我在user_config.h, user_app_adv_start()和user_app_connection()中设置了EXT_SLEEP，如下所示。
//const static sleep\u state\u t app\u default\u sleep\u mode=ARCH\u DEEP\u sleep\u ON；
const static sleep\u state\u t app\u default\u sleep\u mode=ARCH\u EXT\u sleep\u ON；
//足弓设置深睡眠（）；
拱门设置延长睡眠（）；
所以我注释掉了if（arch_ble_ext_wakeup_get（）），但UART接收中断没有发生。
/ /如果(arch_ble_ext_wakeup_get ())
{
拱设置睡眠模式（应用默认睡眠模式）；
arch_ble_force_wakeup ();
拱门可外接唤醒关闭（）；
app_easy_wakeup ();
}
接下来，我在arch_ble_force_wakeup()之后强行插入arch_force_active_mode()。
然后UART接收中断发生，但我怀疑程序是否真的进入睡眠模式。
至少在调试时，程序进入arch_goto_sleep(sleep_mode)。
我是否可以认为扩展睡眠真的进入了，即使我插入arch_force_active_mode()仅仅在arch_ble_force_wakeup()之后?
请告诉我更多情况。
谢谢,
提奥奇尼斯
嗨，提奥奇尼斯，
如果您将APP_ADV_DATA_UPDATE_TO配置为1msec，这意味着设备将仅从1msec开始发布，这是太短的发布时间。在1msec到期后，设备将进入永久休眠模式，唤醒它的唯一方法是从唤醒控制器，正如您正在处理的ble_app_sleep_mode示例中的按钮实现。在此之后，所有外设模块都将通电(包括UART外设模块)，因此您将无法接收任何UART中断。但是，我还是不能理解你想用UART完成什么。您想通过接收来自UART的数据来唤醒DA14580吗?请更改APP_ADV_DATA_UPDATE_TO的时间长度，并尝试在不启用休眠模式的情况下运行项目。
对于您的第二篇文章，这个断言可能意味着lp_handder花费了太多的时间来执行，而您得到的警告意味着BLE核心唤醒计算值需要更多的时间。请查看之前的帖子:
https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bluetooth-low-energy-%E2%80%93-software/some-porblem-sleep-mode
我想通知您，如果您发现上述任何答案有用，请将其中一个标记为已接受。
谢谢，下午好
嗨，对话，
谢谢你的回复。
>您想通过从UART接收数据来唤醒DA14580吗？
正如我已经解释过两次“否”一样，我只需要在WAKEUP INT唤醒后使用UART接收中断。
>如果您将APP_ADV_DATA_UPDATE_TO配置为1msec
我认为不可能配置APP_ADV_DATA_UPDATE_TO为1msec，因为APP_ADV_DATA_UPDATE_TO的最小量是10msec。
我运行APP_ADV_DATA_UPDATE_时的间隔是1（10秒）和1000（10秒），但结果是一样的。
在这两个值下，UART在唤醒后接收中断正常工作。
我可以问一下吗，将APP_ADV_DATA_UPDATE_配置为1（10毫秒间隔）太短了？
我又问了一遍我在上一篇文章中提到的问题。
我重复我注释掉了if(arch_ble_ext_wakeup_get())，并在arch_ble_force_wakeup()之后插入了arch_force_active_mode()。
我是否可以认为扩展睡眠真的进入了，即使我插入arch_force_active_mode()仅仅在arch_ble_force_wakeup()之后?
/ /如果(arch_ble_ext_wakeup_get ())
{
拱设置睡眠模式（应用默认睡眠模式）；
arch_ble_force_wakeup ();
拱门可外接唤醒关闭（）；
app_easy_wakeup ();
}
这正是我在上一篇文章中想问的问题。
谢谢,
提奥奇尼斯
嗨，提奥奇尼斯，
你的意思是“我只需要UART接收中断后醒来由WAKEUP INT”?如果你有数据要发送或接收，你就会得到一个中断。抱歉，我不明白你想用UART完成什么。如果将APP_ADV_DATA_UPDATE_TO配置为1 (10msec)，则UART只会启动10msec。arch_ble_ext_wakeup_get()函数的作用是:检查BLE核心是否处于永久休眠模式。让我试着更好地解释一下ble_app_sleep模式示例是如何工作的。该设备将进入睡眠模式之间的广告或连接间隔。但是，在这个例子中，有一个进入永久休眠的实现，设备只能从唤醒控制器中被唤醒。即使我在arch_ble_force_wakeup()之后插入arch_force_active_mode()，睡眠模式也确实进入了。请检查user_app_adv_start()函数，你会看到在计时器到期(APP_ADV_DATA_UPDATE_TO)后adv_data_update_timer_cb()将被触发。 This function calls the app_easy_gap_advertise_stop() which send a GAPM_CANCEL_CMD message by executing the app_gapm_cancel_msg_create(). The response of the GAPM_CANCEL_CMD, is a GAPM_CMP_EVT, so the gapm_cmp_evt_handler() will be triggered from the app_task.c. If you check this function, in case of undirected connectable advertising that the example uses, app_on_adv_undirect_complete callback function will be triggered. Please check the .app_on_adv_undirect_complete callback from the user_callback_config.h header file and you will see that the user_app_adv_undirect_complete() is registered. This means that after the expiration of the timer the user_app_adv_undirect_complete() will be executed and it calls the arch_ble_ext_wakeup_on() which puts the BLE core to permanent sleep. Only an external event can wake it up.
谢谢，下午好