Hello Dialog,
I have configured UART2 for serial communication in BLE SleepMode example as per UART2 peripheral sample example.
On observing the communication data, there is erroneous transmission.
一个类似的讨论论坛recommends calling "arch_ble_force_wakeup()" API to make clock switch to XTAL16M and have reliable UART transfers.
The switch is successful but once the transfers are complete, it would be necessary to turn off the BLE radio.
我可否知道，
1. If there is a way to turn off BLE radio after UART transfers.
2. If there is a way to switch to XTAL16M on wakeup from sleep without "arch_ble_force_wakeup()" API call.
Regards
raju.
Device:
Hi Raj,
1. By "turning off BLE radio after UART transfers" I suppose you mean stops BLE advertising,
Yes you can do this by callingapp_easy_gap_advertise_stop.with the callback of UART writing operation
2. arch_ble_force_wakeup() is the most recommended way to wake up the BLE core and operate with XTAL16M. If there's BLE activity the device works with XTAL16M automatically. There's also some low lever way to switch the clock e.g:
if ((GetWord16(CLK_CTRL_REG) & RUNNING_AT_XTAL16M) == 0)
{
while( (GetWord16(SYS_STAT_REG) & XTAL16_SETTLED) == 0 ); // wait for XTAL16 settle
SetBits16(CLK_CTRL_REG , SYS_CLK_SEL ,0); // switch to XTAL16
while( (GetWord16(CLK_CTRL_REG) & RUNNING_AT_XTAL16M) == 0 ); // wait for actual switch
}
}
I'm really not sure if there's any reason to use this, or there's any concequences using this though.
Hello Dialog,
I am switching Data transfers between UART and BLE. Both transfers are mutually exlusive.
Using arch_ble_force_wakeup() is causing an increase in current consumption which is not viable for the solution implemented.
Hence, if it is the recommended way, then turning off the radio is to be initiated by a call to which easy API ?
Regards
raju
Hi rajucoolsuraj,
In your initial post you mentioned that you are working on the ble_app_sleepmode example of the SDK, aren’t you? This example puts the device into sleep mode. To do so, all peripheral blocks including the Radio and the UART are powered down. Can you please clarify if you have the sleep mode disable? Any other clarification would be very helpful.
Thanks, PM_Dialog
Hello Dialog,
I have used ble_app_sleepmode sample example to setup sleepmode feature in the application.
There is no BLE advertisements. Upon initialization, user_app_adv_start( ) is never called.
Using Wakeup interrupt from button, I perform UART transfers.
Data is sent reliably over UART only if XTAL16M clock is enabled through, arch_force_ble_wakeup( ) is called.
Upon UART transfer termination, BLE radio turned ON via arch_force_ble_wakeup( ) will need to be turned off. Hence, arch_ble_ext_wakeup( ) API is being used to accomplish it.
Is it the right way of implementation or is there a simple substitute for switching clocks to XTAL16M and back to low power clocks upon sleep resumption ?
Regards
raju.
Hi Raju,
If I understood correctly, as soon as the device boots, you put it in sleep mode and you configured the wake up controller to detect the GPIO interrupt. When the button is pressed, the device will print data through UART2. As soon as the 585 wakes up, the BLE_WAKEUP_LP_Handler will be executed. The crystal 16MHz is being used when the system is in active mode and the crystal 32KHz when it is in sleep mode. In sleep mode all the peripheral blocks are powered off. Upon UART transfer termination, I need some clarifications on that. When interacting with UART2, that radio is ON or OF? Or is ON but you don’t advertise? The radio will be powered on when the chip wakes up.
Thanks, PM_Dialog
After boot up, system initialization will not allow for the start of advertisement. The system is allowed to go into "Extended Sleep Mode without OTP copy".
On button press, Wakeup handler is called to initiate UART2 transfers. (This needs XTAL16M for reliable transfers).
On wakeup, the clocks are switched back to XTAL16M only if BLE_WAKEUP_LP_HANDLER is executed. (It does not if advertisement is not initiated).
要实现到XTAL16M的时钟切换，ARCH_BLE_FORCE_WAKUP（）API将根据论坛讨论执行。
1. Is there a simpler way to switch clocks without calling arch_ble_force_wakup( ) API?
2. Once the clocks are switched via arch_ble_force_wakup( ) API, does the next sleep phase in the main loop turn off the BLE radio that was turned ON with call to arch_ble_force_wakup( ) API ?
If you are yet unable to follow, I shall make suitable arrangements to elucidate further.
regards
raju
Hi rajucoolsuraj,
The BLE_WAKEUP_LP_HANDLER is triggered every time the system wakes up. The device is running with the 32K clock when in sleep mode, so as soon as it wakes up, the clock is switched to 16MHz. When pressing the button to wake up, the app_button_press_cb() callaback function will be executed in order to initiate the peripherals block and the BLE. I cannot get why you would like to switch clocks. If the chip is in active mode, you could use UART in order to print data – it doesn’t matter if the chip is advertising or not. Be aware that the peripherals blocks are using the 16Mhz clock and they are shut down when in sleep mode. Can you please indicate if you have any issue with UART2? Also, can you please indicate if you are using any of the sleep modes between advertising intervals?
Thanks, PM_Dialog
Hello Dialog,
I request to follow the below statements exactly as stated.
After boot up, system initialization will not allow for the start of advertisement (user_app_adv_startAPI.is not called). The system is allowed to go into "Extended Sleep Mode without OTP copy" (arch_set_extended_sleepAPI.).
Wakeup controller is initialized to handle button interrupts and the device is allowed to sleep (this switches the clocks from XTAL16M to RC32K).
On button press, Wakeup interrupt handler is called to initiate UART2 transfers. (UART/UART2 needs XTAL16M for reliable transfers).
On wakeup, the clocks are switched back to XTAL16M only if BLE_WAKEUP_LP_HANDLER is executed. (It does not if advertisement is not initiated through user_app_adv_start API).
I hope you have understood my setting from the above abstract.
I shall continue if only the above is clear.
Thanks
Regards
raju.
Hi Raju,
The wake up procedure is independent from the advertising procedure. This means that as soon as you press the button for waking up the DA14586, the BLE_WAKEUP_LP_HANDLER is always executed. The user_app_adv_start() API is only for advertising! To do so, you can use UART2 hardware block even if the device is not advertising.
Thanks, PM_Dialog
Hello Dialog,
To address the claim - "This means that as soon as you press the button for waking up the DA14586, the BLE_WAKEUP_LP_HANDLER is always executed."
If something is configured as per my setting, It will never execute BLE_WAKEUP_LP_HANDLER on wakeup from button interrupt.
A simple experiment is sufficient to provide the evidence for the claim.
Request to validate the setting as the same was not the case on my end.
THanks
Regards
raju.
Hi Raju,
The BLE_WAKEUP_LP_HANDLER will be executed in every wake up and the LP clock will be swathed to 16MHz clock in every wake up.
Thanks, PM_Dialog
Hello Dialog,
What happens, if
1. "arch_ble_ext_wakup_on( )" API is called.
2. "app_easy_gap_undirected_advertise_start( )" API is never called.
在唤醒通过唤醒中断控制器上，（在睡觉前关闭BLE收音机），
BLE_WAKEUP_LP_HANDLER is never executed, and no clock switch shall happen.
Regards
raju.
Hi rajucoolsuraj,
请看看ble_app_sleepmode example of the SDK6.0.10. When the undirect advertising is completed the user_app_adv_undirect_complete() callback function is triggered and if you check the source code the arch_ble_ext_wakeup_on() is executed in order to disable wakeup for BLE and timer events. Only external (GPIO) wakeup events can wakeup the processor through the wake up controller. To do so, in this stage the device is in permanent sleep mode but the wake up controller is configured ad it is ready to detect an external wake up event (app_button_enable()). When a wake up event is detected the app_button_press_cb() is triggered, it checks whether the BLE core is in permanent sleep mode or not. If yes, it takes the BLE core out of the permanent sleep mode.
Thanks, PM_Dialog