你好，
我们每长时间睡眠（深睡眠）每〜13.4秒都有意外的唤醒。
We are not sure if this is an error in our code or in the SDK.
http://i.imgur.com/EJzs4sp.png
我们用#undef CFG_WDOG在我们的da1458x_config_basic.h中，我不相信它是看门狗。
有什么建议么？
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).
谢谢mt_dialog.
我们已将cfg_max_sleep_duration_external_wakeup_ms更改为更大的值：23小时。
我们还尝试过1小时，1分钟....唤醒仍然遇到每〜13.4秒。
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.
谢谢mt_dialog.
你好，
您能否检查是否将CFG_MAX_SLEEP_DOURATION_EXTERNAL_WAKEUP_MS的值增加到180万（即30分钟）实际上是有效的？
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))，因为23小时乘以1000的值将为82800000000> MAX整数（0x7FFFFFFF）提供。请参阅：https：//support.dialog-semicondiondiondum/forums/post/dialog-smartbond-da ...
使用大值对校准唤醒的副作用是什么？为什么默认这么小？
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.
谢谢mt_dialog.
你好，
如果我用
arch_ext_wakeup_on()那么其他计时器就无法工作，对吧？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.
谢谢mt_dialog.
你好，
Great to hear arch_ext_wakeup_on() should eliminate this annoying power consumption.
你究竟是什么意思是“gtl模式”？我们不需要与外部处理器通信。
它是否必须使用深睡眠？arch_ext_wakeup_on（）与深睡眠vs延长睡眠？
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
你好，
我们已添加通话
ARC_BLE_EXT_WAKEUP_ON（）at the initialization, but the wakeup still happens.我们会尝试睡眠计划。
Regards,
Oren
Hi oren,
无论使用GTL模式是否使用GTL模式，都从RW内核中剩下此定期唤醒，您将能够通过使用上述建议来摆脱它。
定期唤醒与任何特定类型的睡眠无关，如果您不调用Arch_ble_ext_WakeUp_on（），设备将唤醒每个CFG_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.
谢谢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,
请检查您的其他帖子的评论，关于深度睡眠配置，我会尝试使用深睡眠（如您了解这是非常困难的，因为在深入睡眠时运行时，您应该让OTP烧焦虽然我不认为这不刻将改变我发布的行为作为一个事实，我不认为在深睡眠中时，你就可以醒来，不确定，我将不得不在提到的那样检查它）。至少在延长睡眠时，Pro套件上提到的，定期睡眠/唤醒的值取决于CFG_MAX_SLEEP_DOURINGE_EXTERNAL_WAKEUP的值，所以如果设备仍然每13.4秒仍然唤醒延长睡眠模式，请检查是否每13.4秒cfg_max_sleep_duration_external_wakeup的值具有。
谢谢mt_dialog.
你好，
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.
我们有基本套件，我们使用它来调试代码，但为了测量电源使用，我们将在真实模块上刻录代码。
我们使用lp_clk_rcx20而不是lp_clk_xtal32，因为我们的一些真实模块没有水晶。
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.
这可能是一个水晶问题吗？或cfg_lp_clk配置为错误的值？
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.
你好，
我们发现，仅当CFG_LP_CLK = LP_CLK_RCX20而不是当CFG_LP_CLK = LP_CLK_XXTAL32时发生问题。
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.
如果您可以重新检查我的结果，我会感谢。CFG_LP_CLK = LP_CLK_RCX20时是否有可能避免13.4秒唤醒？我们确实希望将来使用没有水晶的模块。
Best Regards,
Oren Zomer
Hi oren,
我可以验证LP时钟的计算，当使用RCX时未正确计算，我在延长睡眠中运行一些测试，我可以验证您的报告，设备确实每13.5秒唤醒。似乎存在RWIP_SLOT_2_LPCYCLES_RCX（UINT32_T SLOT_CNT）中的投射错误，返回的睡眠值是错误的。我在SDK团队中打开了一个内部门票，以检查。同时，您可以替换下面的功能和检查所提到的功能并检查。
静态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);
}
谢谢mt_dialog.
听到的救济，
I started thinking that my code has some memory overflow that might make my program go berserk.
我认为一行也可以做这个技巧：
lpcycles = (uint32_t)(((uint64_t)slot_cnt * (uint64_t)rcx_slot_duration_num) / (uint64_t)rcx_slot_duration_den);
代替：
LPCYCLES =（UINT32_T）（（uint64_t）slot_cnt * rcx_slot_duration_num）/ rcx_slot_duration_den;
请注意，在原始代码中，在划分之前发生到uint32_t。
Regards,
Oren
Hi oren,
一条线很好，额外的变量和计算是为了让我检查从操作返回的值以找到问题。
谢谢mt_dialog.