你好，
我们每长时间睡眠（深睡眠）每〜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.
关键词：
设备：
嗨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秒。
嗨oren，
如果是这种情况，那么FW有问题（如上所述，或者唤醒控制器被启用了一些东西，那么唤醒设备外部的东西），那么SDK就不会在你提到的定时器时段唤醒可以使用SDK上可用的一个示例测试，例如BLE_APP_SLEEPMODE（示例通告，然后在按下按钮之前跌落）。关于看门狗，即使它被定义，当设备睡眠时，它就会停止。
谢谢mt_dialog.
你好，
您能否检查是否将CFG_MAX_SLEEP_DOURATION_EXTERNAL_WAKEUP_MS的值增加到180万（即30分钟）实际上是有效的？
我之前注意到MS_TO_SLOTS_CONVERT宏的错误 - 应该是
（（int）（（1000 *（长长）x）/ 625））代替（（int）（（1000 * x）/ 625）））），因为23小时乘以1000的值将为82800000000> MAX整数（0x7FFFFFFF）提供。请参阅：https：//support.dialog-semicondiondiondum/forums/post/dialog-smartbond-da ...
使用大值对校准唤醒的副作用是什么？为什么默认这么小？
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秒醒来的设备。
谢谢mt_dialog.
你好，
如果我用
arch_ext_wakeup_on()那么其他计时器就无法工作，对吧？我们将测试SleepMode程序。
Thanks,
oren.
嗨oren，
不，如果您调用Arch_ext_WakeUp_On（）函数，则可以通过BLE定时器唤醒，Arch_ext_WakeUp_on（）只是扫描定期唤醒。
谢谢mt_dialog.
你好，
很高兴听到Arch_ext_WakeUp_on（）应该消除这种令人讨厌的功耗。
你究竟是什么意思是“gtl模式”？我们不需要与外部处理器通信。
它是否必须使用深睡眠？arch_ext_wakeup_on（）与深睡眠vs延长睡眠？
我们多久需要一次调用ARCH_EXT_WAKEUP_ON（）？在初始化足够一次呼叫它一次？或者我们每次睡觉时都需要打电话吗？
Thanks,
oren.
你好，
我们已添加通话
ARC_BLE_EXT_WAKEUP_ON（）在初始化，但唤醒仍然发生。我们会尝试睡眠计划。
Regards,
oren.
嗨oren，
无论使用GTL模式是否使用GTL模式，都从RW内核中剩下此定期唤醒，您将能够通过使用上述建议来摆脱它。
定期唤醒与任何特定类型的睡眠无关，如果您不调用Arch_ble_ext_WakeUp_on（），设备将唤醒每个cfg_max_sleep_duration_external_wakeup。关于你应该多久调用函数的频率，当设备将在大休眠模式下留在睡眠模式时，我会调用这种功能，所以每次你想睡一段时间超过一段时间cfg_max_sleep_duration_external_wakeup您应该调用该函数，但在唤醒后，您应该调用Arch_ble_ext_sleep_off（）函数。
谢谢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,
请检查您的其他帖子的评论，关于深度睡眠配置，我会尝试使用深睡眠（如您了解这是非常困难的，因为在深入睡眠时运行时，您应该让OTP烧焦虽然我不认为这不刻将改变我发布的行为作为一个事实，我不认为在深睡眠中时，你就可以醒来，不确定，我将不得不在提到的那样检查它）。至少在延长睡眠时，Pro套件上提到的，定期睡眠/唤醒的值取决于CFG_MAX_SLEEP_DOURINGE_EXTERNAL_WAKEUP的值，所以如果设备仍然每13.4秒仍然唤醒延长睡眠模式，请检查是否每13.4秒cfg_max_sleep_duration_external_wakeup的值具有。
谢谢mt_dialog.
你好，
我们正在使用深度睡眠（cfg_mem_map_deep_sleep定义和cfg_mem_map_ext_sleep未定义）和定义为lp_clk_rcx20的cfg_lp_clk，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.
更改CFG_LP_CLK在代码中更改了大量的位置，因此我无法完全跟踪问题。我仍然不知道从某种校准计算中取出13.4值的位置 - 或者可能会创建此值......
我们只尝试了深度睡眠，因为延长睡眠与我们的产品无关。
如果您可以重新检查我的结果，我会感谢。CFG_LP_CLK = LP_CLK_RCX20时是否有可能避免13.4秒唤醒？我们确实希望将来使用没有水晶的模块。
此致，
oren zomer.
嗨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）
{
挥发性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);
}
谢谢mt_dialog.
听到的救济，
我开始认为我的代码有一些内存溢出，可能会使我的程序成为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.
嗨oren，
一条线很好，额外的变量和计算是为了让我检查从操作返回的值以找到问题。
谢谢mt_dialog.