Hi Dialog,
Now I'm encountering a problem that UART doesn't work after wake-up.
参考BLE_APP_SLEEPMODE示例项目，我添加了UART接收中断处理程序。
As the sample project I wrote Wakeup callback like following.
静态void enable_wakeup_cb（void）
{
if（getBits16（sys_stat_reg，per_is_down））
{
gpio_init（）;
periph_init（）;
}
SetBits32(GP_CONTROL_REG, BLE_WAKEUP_REQ, 1);
if（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（）;
}
}
But UART receive interrupt sometimes doesn't occurs.
WAKE-UP interrupt and GPIO INT work normally but UART receive INT.
我觉得比GPIO年代UART初始化需要更多的时间o I inserted few seconds timer wait and periph_init() again after the wait.
But result was same.
Could you tell me the conditions to start UART noramally after wakeup?
谢谢，
diogenes
嗨Diogenes，
In the ble_app_sleep mode example, the device goes into deep sleep mode after the expiration of APP_ADV_DATA_UPDATE_TO (default value is 10 sec), so the all peripherals are power off. This means that you are not able to have UART activity by the time the device wakes up. Could you please make sure that you are trying to use UART since the chip is woken up? Also, it would be very helpful if you try to explain a bit more what you are trying to accomplish. Would you like to wake your device up when you send data in UART or would you like to have UART activity since the chip is woken up? If you would prefer to implement the first option, be aware that in order to wake up, you should activate the WKUP controller, otherwise the chip will continue staying into the sleep mode. Also, could you please clarify which UART are you working on? In ble_app_sleepmode example, only the UART2 is implemented and you can activated by defining the CFG_PRINTF macro that is placed into da1458x_config_basic.h
谢谢，PM_Dialog
Hi Dialog,
Thank you for your comment.
至于app_adv_data_update_to，我更改为1毫秒，我的程序是唤醒后接收中断。
I measured the timing by oscilloscope and I checked the timing of UART receive occurs at least more than 10msec after wake-up.
But UART receive interrupt is not detected and I imagine UART receive interrupt itself will work, since it is detected after few seconds.
所以我知道需要多少秒以启用UART接收中断。
Of course UART receive interrupt and send in my program normally works.
那么我应该如何在唤醒后启用UART接收中断？
谢谢，
diogenes
Hi Dialog,
我可以添加有关当前问题的一些信息。
首先，对于UART接收中断，在Weke-Up和我的程序之后通常不会在Rwble.cn中跳转到L.369（Assert_Warning（0）;）。
if ((DEVELOPMENT_DEBUG) && (USE_POWER_OPTIMIZATIONS))
{
slp_period_retained = slp_period;
// if this Assertion hits then the LP ISR lasts longer than the time
// that has been reserved via LP_ISR_TIME_XTAL32_CYCLES and LP_ISR_TIME_USEC.
if (sleep_lp_cycles && (sleep_lp_cycles < slp_period))
ASSERT_WARNING(0); // L.369
}
但接收中断本身并没有被抓住，我必须判断它不是处理程序的问题。
然后我怀疑arch_system.c（）中L.400的唤醒延迟时间。
否则//使用_power_optimizations.
{
delay = 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
But considering the constrain of L.395, I understood it's impossible to alter MINIMUM_SLEEP_DURATION to 1slot.
Then I thought it's a problem from sleep mode and I rewrote arch_set_deep_sleep(); to arch_set_extended_sleep(); in void user_app_adv_start(void), but result was same.
无论如何，现在我正在损失。
Please tell me useful information to solve it.
谢谢，
diogenes
Hi Dialog,
I must add more about current situation.
我注意到调试MU程序不会进入（Arch_ble_ext_wakeup_get（））子句虽然我在user_config.h中设置了ext_sleep，user_app_adv_start（）和user_app_connection（），如folllowings。
//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();
So I commented out if(arch_ble_ext_wakeup_get()) but UART receive interrupt didn't occur.
// if（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（）。
Then UART receive interrupt occurred but I doubted if the program really enter sleep mode or not.
至少在调试中，程序进入Arch_Goto_Sleep（Sleep_Mode）。
我认为延长睡眠是真的进入了Arch_ble_force_wakeUp（）后插入Arch_Force_Active_Mode（）吗？
请告诉我更多信息。
谢谢，
diogenes
Hi Diogenes,
如果将app_add_data_update_to配置为1毫秒，这意味着该设备将仅从1毫秒宣传，这太短了广告时间。在1毫秒到期后，设备将转到永久睡眠模式，唤醒它的唯一方法来自唤醒控制器，作为您正在处理的BLE_APP_SLEEP_MODE示例中的按钮的实现。在此之后，所有外围设备模块都将被供电（包括UART外围模块），因此您无法接收任何UART中断。尽管如此，我无法理解你试图与UART完成的事情。您想通过从UART接收数据来唤醒DA14580吗？您能否将App_add_data_update_to更改为更长的时间，并尝试运行项目而不启用睡眠模式？
关于您的第二个帖子，此断言可能意味着LP_Hanlder花费太多时间来执行和警告，您得到的意味着它需要更多时间才能唤醒计算值。请检查以前的线程：
https://support.dialog-seminile.com/forums/post/dialog-smartbond-bluetooth-low-energy-%2%80%93-software/some- tormal-sleep-mode.
I would like to inform you that if you found any of the above answers useful please mark one of them as accepted.
谢谢，PM_Dialog
Hi Dialog,
感谢你的回复。
> Would you like to wake the DA14580 up by receiving data from UART?
As I already explained twice "NO", I just need UART receive interrupt after wake-up by WAKEUP INT.
>如果将app_add_data_update_to配置为1毫秒
我认为将App_Adv_Data_update_to配置为1毫秒是不可能的，因为app_adv_data_update_to的最小量子是10msec。
I run with the APP_ADV_DATA_UPDATE_TO is 1 (10msec interval) and 1000 (10sec), but result was same.
在唤醒正常工作后，uart uart会接收中断。
Could I ask you about it, configuring APP_ADV_DATA_UPDATE_TO as 1 (10msec interval) is too short?
我再次问我在前一篇文章中写道的问题。
我重复我注释了（ARCH_BLE_EXT_WAKEUP_GET（）和插入ACH_BLE_FORCE_WAKESUP（）之后插入ARCH_FORCE_ACTION_MODE（）。
我认为延长睡眠是真的进入了Arch_ble_force_wakeUp（）后插入Arch_Force_Active_Mode（）吗？
// if（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（）;
}
It's just the question I wanted to ask in previous post.
谢谢，
diogenes
Hi Diogenes,
所以你的意思是，“我只需要UART在Wakeup int唤醒后接受中断”？如果您有数据要么发送或接收，您将收到中断。对不起，但我无法理解你试图与UART完成的事情。如果将App_add_data_update_to配置为1（10msec），则UART将仅适用于10毫秒。ARCH_BLE_EXT_WAKEUP_GET（）函数检查BLE核心是否处于永久睡眠模式。让我试着更好地解释BLE_APP_SLEEP模式示例的更好。该设备将在广告或连接间隔之间输入睡眠模式。但是，在该示例中，存在进入永久睡眠的实现，并且只能从唤醒控制器唤醒设备。即使我在Arch_ble_Force_WakeUp（）之后，睡眠模式也是如此插入Arch_Force_Active_Mode（）。请检查user_app_adv_start（）函数，您将看到计时器的到期后（app_add_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