What is the purpose of arch_ble_ext_wakeup_on?

Hi,
We are using SDK 5.0.4 and I was looking at the user_sleepmode example.
It looks like the program listens to button-click interrupts in two cases.

The first case is during a connection. To begin listening,user_app_set_button_eventis called and executes:

wkupct_register_callback(user_app_button_press_cb);
wkupct_enable_irq(WKUPCT_PIN_SELECT(GPIO_BUTTON_PORT, GPIO_BUTTON_PIN),
WKUPCT_PIN_POLARITY(GPIO_BUTTON_PORT, GPIO_BUTTON_PIN, next_event), // polarity
1, // 1 event
10);

and the listening is stopped byuser_app_disable_buttonwhich callswkupct_disable_irq();.
The listening callback (user_app_button_press_cb) also callsuser_app_set_button_eventto keep listening to button clicks (actually it listens to switches in the button-mode, by choosing the right "next_event").

The second case is when the program stops advertising (after 10 seconds). Whenuser_app_adv_undirect_complete调用的状态为GAP_ERR_CANCELED(i.e. it's a deliberate adv-stop) it calls:

arch_ble_ext_wakeup_on();
// Configure wakeup button
app_button_enable();


The purpose ofarch_ble_ext_wakeup_onis:"Puts the BLE core to permanent sleep. Only an external event can wake it up.". It simply sets an internal flag to true.
Then,app_button_enablecalls:

app_easy_wakeup_set(app_wakeup_cb);
wkupct_register_callback(app_button_press_cb);
wkupct_enable_irq(WKUPCT_PIN_SELECT(GPIO_BUTTON_PORT, GPIO_BUTTON_PIN), // select pin (GPIO_BUTTON_PORT, GPIO_BUTTON_PIN)
WKUPCT_PIN_POLARITY(GPIO_BUTTON_PORT, GPIO_BUTTON_PIN, WKUPCT_PIN_POLARITY_LOW), // polarity low
1, // 1 event
40);


i.e. it savesapp_wakeup_cbaside to be called in the future byapp_easy_wakeup，并运行与第一种情况类似的代码，以便开始侦听按钮中断。
When the interrupt occurs,app_button_press_cbis called and executes:

if (GetBits16(SYS_STAT_REG, PER_IS_DOWN))
{
periph_init();
}
...

If I understand correctly, this code must be called in external wakeup during deep-sleep (Is it harmful to call it when using extended sleep?).
Then, the app_button_press_cb continues by calling:

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();
}

i.e. it checks that the external-wakeup-flag is on, initializes the sleep-mode (app_default_sleep_mode is deep-sleep), wakes up the BLE, turn off the external-wakeup flag (i.e. timers and BLE events can now wake up too) and callsapp_easy_wakeup()(which callsapp_wakeup_cbas I explained before).

What are the advantages of the mechanism in the second case? We could avoid callingarch_ble_ext_wakeup_on()and then we won't have to re-configure the sleep mode and re-wake the BLE. What's the point of callingarch_ble_ext_wakeup_on()if the program doesn't have any timers and doesn't advertise (i.e. timers and BLE events cannot wake up the programanyways- so only an external-wakeup can).

Will the program consume less power during deep-sleep if we usearch_ble_ext_wakeup_on?

How comes the second case never callswkupct_disable_irq()? Does going to sleep afterarch_ble_ext_wakeup_onmeans that you don't have to callwkupct_disable_irq()after you wake up?

Thanks,
Oren Zomer