嗨,对话框中,
现在我遇到了一个问题，起床后UART不起作用。
参考ble_app_sleepmode示例项目，我添加了UART接收中断处理程序。
作为示例项目，我写了如下唤醒回调。
静态孔隙enable_Wakeup_cb(空白)
｛
如果(GetBits16 (SYS_STAT_REG PER_IS_DOWN))
｛
GPIO_init ();
periph_init ();
｝
SetBits32 (GP_CONTROL_REG BLE_WAKEUP_REQ 1);
如果(arch_ble_ext_wakeup_get ())
｛
arch_set_sleep_mode (app_default_sleep_mode);
arch_ble_force_wakeup ();
arch_ble_ext_wakeup_off ();
app_easy_wakeup ();
｝
｝
但是UART接收中断有时不会发生。
唤醒中断和GPIO INT工作正常，但UART接收INT。
我觉得UART初始化比GPIO需要更多的时间，所以我插入了几秒钟的定时器等待和peripher_init()在等待之后再次。
但结果是一样的。
你能告诉我起床后UART正常启动的条件吗?
谢谢,
第欧根尼
设备:
嗨,第欧根尼,
在ble_app_sleep模式的示例中，设备在APP_ADV_DATA_UPDATE_TO到期后进入深度睡眠模式(默认值是10秒)，因此所有外设都关闭了电源。这意味着在设备唤醒时，您无法拥有UART活动。请确认一下，由于芯片已经唤醒，您是在尝试使用UART吗?此外，如果你试着多解释一下你想要完成的任务，那将是非常有帮助的。您是希望在UART中发送数据时唤醒设备，还是希望在芯片被唤醒后进行UART活动?如果您更喜欢实现第一种选择，请注意，为了唤醒，您应该激活WKUP控制器，否则芯片将继续保持在休眠模式。另外，能否请您说明一下您在为哪个UART工作?在ble_app_sleepmode示例中，只实现了UART2，您可以通过定义放置在da1458x_config_basic.h中的CFG_PRINTF宏来激活它
谢谢,PM_Dialog
嗨,对话框中,
谢谢你的评论。
对于APP_ADV_DATA_UPDATE_TO，我修改为1msec，我的程序是在唤醒后UART接收中断。
我用示波器测量了时间，我检查了UART接收的时间在唤醒后至少发生在10毫秒以上。
但是UART接收中断没有被检测到，我想象UART接收中断本身会工作，因为它在几秒钟后被检测到。
所以我知道启用UART接收中断需要多少秒。
当然UART接收中断和发送在我的程序中正常工作。
那么我应该怎样做才能在唤醒后启用UART接收中断?
谢谢,
第欧根尼
嗨,对话框中,
我能补充一些关于当前问题的信息吗?
首先，UART接收中断在wekeup后通常不会发生，我的程序有时会在rwble.c (ASSERT_WARNING(0);)中跳转到L.369。
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);/ / L.369
｝
但是接收中断本身没有被发现，我必须判断这不是处理者的问题。
然后我怀疑arch_system.c()中的L.400唤醒延迟时间。
/ /其他USE_POWER_OPTIMIZATIONS
｛
延迟= MINIMUM_SLEEP_DURATION;
//如果XTAL_TRIMMING_TIME_USEC发生变化(即变大)，那么这个
//将确保用户得到通知，将“延迟”增加1或更多
//插槽，这样XTAL有足够的时间来解决
# if ((3125 + (MINIMUM_SLEEP_DURATION + 625)) < (LP_ISR_TIME_USEC + 1100)) //1.1ms max power-up time // L.395
# error "Minimum sleep duration is too small for the 16MHz crystal used…"
# endif
｝
rwip_wakeup_delay_set(延迟);/ / L.400
但是考虑到L.395的限制，我理解将MINIMUM_SLEEP_DURATION更改为1slot是不可能的。
然后我认为这是一个问题从睡眠模式，我重写arch_set_deep_sleep();arch_set_extended_sleep ();在void user_app_adv_start(void)中，但结果相同。
不管怎样，现在我很迷茫。
请告诉我解决这个问题的有用信息。
谢谢,
第欧根尼
嗨,对话框中,
关于目前的情况，我必须补充一些。
我注意到在调试时mu程序不进入if(arch_ble_ext_wakeup_get())子句，尽管我在user_config.h, user_app_adv_start()和user_app_connection()中设置了EXT_SLEEP，如下所示。
//const static sleep_state_t app_default_sleep_mode = ARCH_DEEP_SLEEP_ON;
const static sleep_state_t app_default_sleep_mode = ARCH_EXT_SLEEP_ON;
/ / arch_set_deep_sleep ();
arch_set_extended_sleep ();
所以我注释掉了if(arch_ble_ext_wakeup_get())但是UART接收中断没有发生。
/ /如果(arch_ble_ext_wakeup_get ())
｛
arch_set_sleep_mode (app_default_sleep_mode);
arch_ble_force_wakeup ();
arch_ble_ext_wakeup_off ();
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
我想通知你，如果你发现任何上述答案有用，请标记其中一个为接受。
谢谢,PM_Dialog
嗨,对话框中,
谢谢你的回复。
>您是否希望通过接收UART的数据来唤醒DA14580 ?
正如我已经解释了两次“NO”，我只需要UART在WAKEUP INT唤醒后接收中断。
>如果您将APP_ADV_DATA_UPDATE_TO配置为1msec
我认为不可能配置APP_ADV_DATA_UPDATE_TO为1msec，因为APP_ADV_DATA_UPDATE_TO的最小量是10msec。
我使用APP_ADV_DATA_UPDATE_TO为1(10毫秒间隔)和1000(10秒)运行，但结果是相同的。
在这两个值下，UART在唤醒后接收中断正常工作。
请问APP_ADV_DATA_UPDATE_TO配置为1 (10msec interval)太短了吗?
我又问了一遍我在上一篇文章中提到的问题。
我重复我注释掉了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_set_sleep_mode (app_default_sleep_mode);
arch_ble_force_wakeup ();
arch_ble_ext_wakeup_off ();
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.
谢谢,PM_Dialog