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_wdog.in our da1458x_config_basic.h so I don't believe it's the watchdog.
Any suggestions?
Thanks,
oren.
关键词：
设备：
嗨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.
嗨oren，
如果是这种情况，那么FW有问题（如上所述，或者唤醒控制器被启用了一些东西，那么唤醒设备外部的东西），那么SDK就不会在你提到的定时器时段唤醒可以使用SDK上可用的一个示例测试，例如BLE_APP_SLEEPMODE（示例通告，然后在按下按钮之前跌落）。关于看门狗，即使它被定义，当设备睡眠时，它就会停止。
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?
我之前注意到MS_TO_SLOTS_CONVERT宏的错误 - 应该是
((int)((1000 *(很久)x) / 625))代替（（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.
嗨oren，
为了防止该期刊唤醒，您可以使用将阻止设备唤醒的Arch_ext_WakeUp_on（），而无论您在CFG_MAX_SLEEP_DOURATION_EXTERNAL_WAKEUP中放置的值。期刊唤醒它不会因校准目的而加重，在GTL模式下操作时，您观察到的是从RW内核的剩余。关于最大值，你是对的，但我提到的是，如果你想用设备不唤醒，你必须要调用前面提到的函数，而不是扩展cfg_max_sleep_duration_external_wakeup（我想SDK没有忘记某人想做这个并放置如此大的价值）。我测试了30分钟的值，也直接在max_sleep_duration_external_wakeup（不使用宏）中放置了值，我无法看到每13秒醒来的设备。
Thanks MT_dialog
Hi,
If I use
arch_ext_wakeup_on()then other timers will not work, right?我们将测试SleepMode程序。
Thanks,
oren.
嗨oren，
不，如果您调用Arch_ext_WakeUp_On（）函数，则可以通过BLE定时器唤醒，Arch_ext_WakeUp_on（）只是扫描定期唤醒。
Thanks MT_dialog
Hi,
很高兴听到Arch_ext_WakeUp_on（）应该消除这种令人讨厌的功耗。
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?
我们多久需要一次调用ARCH_EXT_WAKEUP_ON（）？在初始化足够一次呼叫它一次？或者我们每次睡觉时都需要打电话吗？
Thanks,
oren.
Hi,
We have added a call to
arc_ble_ext_wakeup_on()在初始化，但唤醒仍然发生。We will try the sleep program.
Regards,
oren.
嗨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。关于你应该多久调用函数的频率，当设备将在大休眠模式下留在睡眠模式时，我会调用这种功能，所以每次你想睡一段时间超过一段时间cfg_max_sleep_duration_external_wakeup您应该调用该函数，但在唤醒后，您应该调用Arch_ble_ext_sleep_off（）函数。
Thanks MT_dialog
我无法解决问题。
当CFG_MAX_SLEEP_DOURINGS_EXTERNAL_WAKEUP的值高 - 使用0x7FFFFFF和0x7FFF进行高度测试时，我的模块仍在唤醒13.4秒后醒来。
我正在使用深睡眠。请看我的评论：
https：//support.dialog-semicondiondiondum/fixed-da14580-must-automaticall ...
如果您将非常欣赏，如果您使用设备测试它 - 增加CFG_MAX_SLEEP_DOURATION_EXTERNAL_WAKEUP的值，并在使用计时器的程序中使用深睡眠（例如，在一个简单的外围程序中，将宣传1分钟，睡眠1分钟，宣传1分钟，睡眠1分钟）。然后看看功耗的范围 - 你是否每次〜13.4秒持续睡眠或峰值？
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,
我们正在使用深度睡眠（cfg_mem_map_deep_sleep定义和cfg_mem_map_ext_sleep未定义）和定义为lp_clk_rcx20的cfg_lp_clk，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.
更改CFG_LP_CLK在代码中更改了大量的位置，因此我无法完全跟踪问题。我仍然不知道从某种校准计算中取出13.4值的位置 - 或者可能会创建此值......
我们只尝试了深度睡眠，因为延长睡眠与我们的产品无关。
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.
此致，
oren zomer.
嗨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)
{
挥发性UINT32_T LPCYCLES;
uint64_t temp;
// Sanity检查：插槽的数量不应该太高，无法避免溢出
// 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,
我开始认为我的代码有一些内存溢出，可能会使我的程序成为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.
嗨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