Hi,
We have an unexpected wakeup every ~13.4 seconds in long sleeps (deep-sleep).
We are not sure if this is an error in our code or in the SDK.
http://i.imgur.com/EJzs4sp.png
We use#undef CFG_WDOGin our da1458x_config_basic.h so I don't believe it's the watchdog.
Any suggestions?
Thanks,
Oren
Keywords:
Device:
Hi oren,
有一个从设备时自动唤醒there is no BLE activity for 10 seconds if you set the device in permanent sleep (no BLE activity) and you haven't invoked the arch_ble_ext_wakeup_on(). Regarding the 13 seconds that you observe perhaps you have changed the CFG_MAX_SLEEP_DURATION_EXTERNAL_WAKEUP_MS from 10 seconds which is the default to 13 seconds. Other than that the device could be awaken either via a kernel timer or something triggering your wakeup pin (in case that you have set it).
Thanks MT_dialog
We have changed CFG_MAX_SLEEP_DURATION_EXTERNAL_WAKEUP_MS to a much larger value: 23 hours.
We also tried with 1 hour, 1 minute.... wakeup still happens every ~13.4 seconds.
Hi oren,
If that is the case then something is wrong with the fw (as mentioned above either a timer or if the wakeup controller is enabled something is waking up the device externaly), the SDK doesn't wake on the timer period that you mention, you can test that by using one of the examples that are available on the SDK, for example the ble_app_sleepmode (the example advertises and then falls in sleep until a button is pressed). Regarding the watchdog, even if it is defined it is stopped when the device goes to sleep.
Thanks MT_dialog
Hi,
Can you please check if increasing the value of CFG_MAX_SLEEP_DURATION_EXTERNAL_WAKEUP_MS to 1800000 (i.e. 30 minutes) actually works?
I noticed before that there was an error with the MS_TO_SLOTS_CONVERT macro - should be
((int)((1000 *(很久)x) / 625))instead of((int)((1000 * x) / 625)), because a value of 23 hours multiplied by 1000 would give 82800000000 > max integer (0x7FFFFFFF).Please see:https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-da...
What are the side effects of using a large value for the calibration wakeup? Why is the default so small?
Thanks,
Oren
Hi oren,
In order to prevent that periodical wake up you can use the arch_ext_wakeup_on() that will prevent the device to wakeup regardless the value that you have placed in the CFG_MAX_SLEEP_DURATION_EXTERNAL_WAKEUP. The periodical wakeup its not exaclty for calibration purposes, what you observe is a leftover from the RW kernel when operating in GTL mode. Regarding the maximum value, you are right, but as i ve mentioned if you would like to device not to wakeup you will have to invoke the previously mentioned function and not extend the the CFG_MAX_SLEEP_DURATION_EXTERNAL_WAKEUP (i suppose that the SDK didn't forsee that someone would like to do this and place such a large value). I tested the 30 minutes value and also placed the value directly in the MAX_SLEEP_DURATION_EXTERNAL_WAKEUP (without using the macro) i couldn't see the device waking up every 13 seconds.
Thanks MT_dialog
Hi,
If I use
arch_ext_wakeup_on()then other timers will not work, right?We will test the sleepmode program.
Thanks,
Oren
Hi oren,
No, you will be able to wake up via a BLE timer if you invoke the arch_ext_wakeup_on() function, the arch_ext_wakeup_on() just supresses the periodic wakeup.
Thanks MT_dialog
Hi,
Great to hear arch_ext_wakeup_on() should eliminate this annoying power consumption.
What exactly did you mean by "GTL mode"? We do not need to communicate with an external processor.
Does it have to do with using deep-sleep? Is arch_ext_wakeup_on() related to deep-sleep vs extended-sleep?
How often do we need to call arch_ext_wakeup_on()? Is calling it once at the initialization enough? Or do we need to call it every time we go to sleep?
Thanks,
Oren
Hi,
We have added a call to
arc_ble_ext_wakeup_on()at the initialization, but the wakeup still happens.We will try the sleep program.
Regards,
Oren
Hi oren,
Regardless if you use GTL mode or not, this periodic wake up is leftover from the RW kernel, and you will be able to get rid of it by using the above mentioned suggestions.
The periodic wake up isn't related to any specific kind of sleep, if you dont invoke the arch_ble_ext_wakeup_on() the device is going to wake up everyCFG_MAX_SLEEP_DURATION_EXTERNAL_WAKEUP. Regarding the how often you should invoke the function, usualy this function is invoked when the device is going to stay in sleep mode for a large period of time, so i suppose every time that you would like to sleep for quite some time that exceeds the CFG_MAX_SLEEP_DURATION_EXTERNAL_WAKEUP you should invoke that function, but after waking up you should invoke the arch_ble_ext_sleep_off() function.
Thanks MT_dialog
I could not fix the problem.
My module still wakes up after 13.4 seconds when the value of CFG_MAX_SLEEP_DURATION_EXTERNAL_WAKEUP is high - tested with 0x7FFFFFF and 0x7FFF (which should give at least 20 seconds of continuous sleep).
I'm using deep sleep. Please see my comment in:
https://support.dialog-semiconductor.com/fixed-da14580-must-automaticall...
I would very appreciate if you test it with your equipment - increase the value of CFG_MAX_SLEEP_DURATION_EXTERNAL_WAKEUP and use Deep Sleep in a program that uses a timer (for example, in a simple peripheral program that would advertise for 1 minute, sleep for 1 minute, advertise for 1 minute, sleep for 1 minute, etc.). Then look with a scope on the power consumption - do you get a continuous sleep or a peak every ~13.4 seconds?
Regards,
Oren
Hi Oren,
Please check the comment on your other post, regarding the deep sleep configuration, i will try to check with deep sleep (as you understand this is quite difficult since to operate properly with deep sleep you should have the OTP burned although i dont think that this will change the behaviour of what i ve posted as a matter a fact i dont think when in deep sleep you will be able to wake up at all, not sure about that, i will have to check it as i ve mentioned). At least on extended sleep as allready mentioned on the pro kit the value of the periodic sleep / wake up depends on the value that the CFG_MAX_SLEEP_DURATION_EXTERNAL_WAKEUP has, so please check if with the extended sleep mode if the device still wakes up every 13.4 seconds regardless of the value that the CFG_MAX_SLEEP_DURATION_EXTERNAL_WAKEUP has.
Thanks MT_dialog
Hi,
We are using deep sleep (CFG_MEM_MAP_DEEP_SLEEP defined and CFG_MEM_MAP_EXT_SLEEP undefined) and CFG_LP_CLK defined to LP_CLK_RCX20, with SDK 5.0.4.
We have the basic kit and we use it for debugging the code, but in order to measure power usage we burn the code on real modules.
We use LP_CLK_RCX20 and not LP_CLK_XTAL32 because some of our real modules do not have a crystal.
However, my team told me that they burned the version with CFG_LP_CLK=LP_CLK_RCX20 also on the modules that do contain a crystal.
Could it be a crystal problem? Or CFG_LP_CLK being configured to the wrong value?
Regards,
Oren
P.S.
Switching to Extended Sleep is not an option for us, because we do long periods of sleep and our module has a tiny unremovable battery. We really need Deep Sleep, and prefer to use modules without a crystal to reduce costs.
Hi,
We found that the problem happens only when CFG_LP_CLK=LP_CLK_RCX20 and not when CFG_LP_CLK=LP_CLK_XTAL32.
When CFG_LP_CLK=LP_CLK_RCX20 the wakeups happen every ~13.4 seconds even though CFG_MAX_SLEEP_DURATION_EXTERNAL_WAKEUP is much higher.
Changing CFG_LP_CLK changes a lot of places in the code, so I could not trace the problem exactly. I still don't know where the 13.4 value is taken from - or maybe this value is created from some calibration calculations...
We have tried only deep-sleep because extended-sleep is not relevant for our product.
I would appreciate if you could re-check my results. Is it possible to avoid the 13.4 sec wakeups when CFG_LP_CLK=LP_CLK_RCX20? We do want in the future to use modules without a crystal.
Best Regards,
Oren Zomer
Hi oren,
I can verify that the calculation of the lp clock when the RCX is used is not properly calculated, i ve run some tests in extended sleep and i can verify what you are reporting, the device indeed wakes up every 13.5 seconds. Seems that there is a cast error in the rwip_slot_2_lpcycles_rcx(uint32_t slot_cnt) and the sleep value that returns is wrong. I ve open an internal ticket for this at the SDK team for checking that. Meanwhile, you can replace the function that i ve mentioned with the below function and check.
static uint32_t rwip_slot_2_lpcycles_rcx(uint32_t slot_cnt)
{
volatile uint32_t lpcycles;
uint64_t temp;
// Sanity check: The number of slots should not be too high to avoid overflow
//ASSERT_ERR(slot_cnt < 1000000);
temp = (uint64_t)((uint64_t)slot_cnt * (uint64_t)rcx_slot_duration_num);
temp = (uint64_t)(temp / rcx_slot_duration_den);
lpcycles = (uint32_t)(temp) ;
return(lpcycles);
}
Thanks MT_dialog
That's a relief to hear,
I started thinking that my code has some memory overflow that might make my program go berserk.
I think a one-line can also do the trick:
lpcycles = (uint32_t)(((uint64_t)slot_cnt * (uint64_t)rcx_slot_duration_num) / (uint64_t)rcx_slot_duration_den);
Instead of:
lpcycles = (uint32_t)((uint64_t)slot_cnt * rcx_slot_duration_num) / rcx_slot_duration_den;
Notice that in the original code, the casting to uint32_t happened before the division.
Regards,
Oren
Hi oren,
One line will be fine, the additional variables and calculations are in place in order for me to check the values returned from the operations to find the issue.
Thanks MT_dialog