Whilst peak current is overall higher from 1.5V in boost, the average energy should be quite similar. If you can confrim you mean 140mS i will look into that. One could alwasy expect a slight variation in boot timing of some mS.
to be sure, you did not mention J23: this one should be removed for 1.5V supply. Although I don't think this eventually is the cause for your measured high consumed charge.
Boost mode should not consume more charge than in buck mode. Only in boost mode during cold boot the DCDC-converter has to charge a capacitor, which causes a high initial peak current, but this should not contribute more than a few µC.
1） 对于您的推荐，J23是开放的。广告峰值如您所提到的约10 mA。 The proximtiy_reporter_fh goes to deep sleep mode afer 3 minutes .So when interrupt is given it wakes up with a cold boot right ? 但是中断后的冷启动似乎非常高（如前所述（162 UC - 150 UC）与冷靴（125UC）相比！ 同时也有差异！
Since there is no option to attach files in Dialog forum ,For your reference i have attached the file link shared in the dropbox .
2) Also i have one more question so am adding wiith these. The proximity_reporter_fh program is modified such that it performs one advertising event and goes to deep sleep ,upon the interrupt (push button) it does one advertising event and again goes to sleep. 因此，在调试模式下测试时，中断期间的电源都是完美的。编程被烧毁到OTP。但现在在PowerOn期间，第一个广告已经完成，需要约75毫秒即可进入睡眠模式。但是在中断唤醒期间不会发生这种情况。我在这里分享了快照，可以找到它们之间的差异。（注意：它也遭受了与1）问题中提到的同样的问题）。
I can confirm the normal cold-boot timing and consumed charge:
降压模式：124毫秒 - 67μC。 升压模式：124毫秒 - 128μc。
The higher consumed charge in boost mode @ 1.5V can be explained because of the higher current: about twice as high as when in buck-mode @ 3V. The consumed energy (J) from the battery though will be about the same (3 x 67 = 1.5 x 128).
I discussed the 2nd case (interrupt) with some colleagues,
normally when waking up from sleep, no cold-boot is expected. We expect about 10 msec upto first advertisement, and consumed charge about 10 µC (buck) or 20 µC (boost). This accounts for additional time and charge for initialisation etc. We don't see the RF-calibration as in your screen-captures. In a real cold-boot indeed the RF-cal is executed: in your PowerOn picture just after 22,100 sec. （在正常的广告中，首次广告的时间大约需要7.5毫秒，并且消耗了3.5或7μc的电荷）。
A few questions to help you further: your DA14580 is the DA14580-01 (ES5)? Which SDK version are you using? Did you modify the proximity code? 您使用哪个键/哪个GPIO唤醒BLE芯片？ 我们使用了主板上的一个钥匙。
Yea it is DA14580_CB_PXI_WLCSP 078-05-C ES5 . the SDK version 3.0.4.0 . we are using K1 (default in the proximity_reporter_fh) in the mother board. The cold boot seems to be happen even in normal proximity application (ie after 3 minutes it will go to sleep , then push button is pressed it wakes up with some rf calibration.). (You have mentioned in another post that while using deepsleep mode the SRAM will turned of during sleep !)
上电：我看到电源时刻2秒的总活动。众所周知：允许32kHz XTAL振荡器在进入睡眠模式之前变得稳定。 对我来说，它看起来你的电路板在32khz xtal上没有运行，而是在rcx时钟上运行。这是correct吗？使用RCX时间更短。 如果没有，必须在其他地方找到原因。 But please note that using RCX in boost mode is not validated and not allowed. It cannot be used because of a less stable internal voltage which is used for he RCX oscillator. In boost mode one must use the 32KHz Xtal oscillator for sleep clock.
2) The 32KHz XTAL is used but the stabilisation time is reduced to least for testing purpose (by default it was 3200 which corresponds to 2 sec in rwip.c file) ,so during power on the total time is 126msec till first advertisement and it should go to sleep, but still it takes some 77 msec before goin to sleep .so the extra time maybe due to the xtal ??
And please confirm about the 1) regarding the coldboot during wakeup from deep sleep .we are getting the RF calibration after wakeup from deep sleep using default proximity_reporter_fh with no modification burned in OTP. 谢谢
1）On the RF-cal event in your pictures. 我们看到在电动时在冷启动期间执行此RF-CAL，但不会在深度睡眠时执行。 如前所述，我们不期望这里冷却。 只有在芯片的温度会发生5摄氏度或更多时，才会执行RF-CAL。
最好的问候，bb_dialog.
Update: a request to you. 你可以在你的设备中加载相同的项目，但不是使用深睡眠，使用扩展睡眠模式？ There is no need to burn this in OTP, just load it in SysRam using Connection Manager or Smart Snippets. What we like to know: are you seeing the RF-cal then too when pressng the interrupt button? 这对我们有所帮助。
During debugging mode in SRam there is no RF-cal upon wake up from Deep sleep (even also in extended sleep ). After Programming OTP there is RF-cal in COLD boot upon wakeup from deep sleep. Hence we couldnt find RF-cal when pressing interrupt during SRAM mode !. 在编程OTP后，请咨询此问题。
亲爱的HRG，你的意思是140ms或140秒？
Whilst peak current is overall higher from 1.5V in boost, the average energy should be quite similar. If you can confrim you mean 140mS i will look into that. One could alwasy expect a slight variation in boot timing of some mS.
BR JE_DIALOG.
嗨JE_Dialog
对不起，它是140毫秒！但升压模式中消耗的电荷比在该应用笔记中提到的3倍！
Waiitng for your response.
谢谢
Hello HRG，没有什么明显的，斯普林斯想：你可以确认你的HW和SW设置并验证对女子卡进行升压模式的修改吗？
BR JE_DIALOG.
嗨JE_Dialog
HW设置根据用户手册 - J13连接为3-4，用于测量电路的电源。跳线J14为1-2，用于增压配置。软件是Proximity Reporter_FH，没有修改！对于升压模式HW设置 - 根据示意图。电源电压为1.5伏。
你好hrq,
to be sure, you did not mention J23: this one should be removed for 1.5V supply.
Although I don't think this eventually is the cause for your measured high consumed charge.
Boost mode should not consume more charge than in buck mode.
Only in boost mode during cold boot the DCDC-converter has to charge a capacitor, which causes a high initial peak current, but this should not contribute more than a few µC.
在您的广告活动中，RX / TX峰值电流约为10mA？
如果是，它表示升压模式板的正常运行。
最好的问候，bb_dialog.
你好
bb_dialog.
1）
对于您的推荐，J23是开放的。广告峰值如您所提到的约10 mA。
The proximtiy_reporter_fh goes to deep sleep mode afer 3 minutes .So when interrupt is given it wakes up with a cold boot right ?
但是中断后的冷启动似乎非常高（如前所述（162 UC - 150 UC）与冷靴（125UC）相比！
同时也有差异！
Since there is no option to attach files in Dialog forum ,For your reference i have attached the file link shared in the dropbox .
During Power on
https://www.dropbox.com/s/b1rrk73p3d690jg/poweron.png?dl=0
在中断期间
https://www.dropbox.com/s/ob83u162r05ss8j/interrupt.png?dl=0
2) Also i have one more question so am adding wiith these.
The proximity_reporter_fh program is modified such that it performs one advertising event and goes to deep sleep ,upon the interrupt (push button) it does one advertising event and again goes to sleep.
因此，在调试模式下测试时，中断期间的电源都是完美的。编程被烧毁到OTP。但现在在PowerOn期间，第一个广告已经完成，需要约75毫秒即可进入睡眠模式。但是在中断唤醒期间不会发生这种情况。我在这里分享了快照，可以找到它们之间的差异。（注意：它也遭受了与1）问题中提到的同样的问题）。
During Poweron
https://www.dropbox.com/s/2b9aj3eg2ayne29/power%20on.png?dl=0
在中断:
https://www.dropbox.com/s/3h0cuxkga4w79jy/interrupt.png?dl=0.
3）
还有一个疑问。无论何时在一个广告活动后按下交换机K1，也有一个未知的峰值。（注意：此峰值您可以在正常的Proximity_reporter_FH程序中敏锐地观察K1！）以下是这些的快照
https://www.dropbox.com/s/8qt913jtlm9bn42/switch.png?dl=0.
https://www.dropbox.com/s/4ycd4nrl6l85ug4/unknown%20peak.png?dl=0.
谢谢
hrg
你好hrq,
thanks for the detailed snapshots.
我们将介绍一下这些。
最好的问候，bb_dialog.
更新14H30：
I can confirm the normal cold-boot timing and consumed charge:
降压模式：124毫秒 - 67μC。
升压模式：124毫秒 - 128μc。
The higher consumed charge in boost mode @ 1.5V can be explained because of the higher current: about twice as high as when in buck-mode @ 3V.
The consumed energy (J) from the battery though will be about the same (3 x 67 = 1.5 x 128).
我还在努力重现你的中断情况。
最好的问候，bb_dialog
你好hrq,
I discussed the 2nd case (interrupt) with some colleagues,
normally when waking up from sleep, no cold-boot is expected.
We expect about 10 msec upto first advertisement, and consumed charge about 10 µC (buck) or 20 µC (boost).
This accounts for additional time and charge for initialisation etc. We don't see the RF-calibration as in your screen-captures.
In a real cold-boot indeed the RF-cal is executed: in your PowerOn picture just after 22,100 sec.
（在正常的广告中，首次广告的时间大约需要7.5毫秒，并且消耗了3.5或7μc的电荷）。
A few questions to help you further:
your DA14580 is the DA14580-01 (ES5)?
Which SDK version are you using? Did you modify the proximity code?
您使用哪个键/哪个GPIO唤醒BLE芯片？
我们使用了主板上的一个钥匙。
最好的问候，bb_dialog
嗨bb_dialog谢谢你的回复
Yea it is DA14580_CB_PXI_WLCSP 078-05-C ES5 .
the SDK version 3.0.4.0 .
we are using K1 (default in the proximity_reporter_fh) in the mother board.
The cold boot seems to be happen even in normal proximity application (ie after 3 minutes it will go to sleep , then push button is pressed it wakes up with some rf calibration.).
(You have mentioned in another post that while using deepsleep mode the SRAM will turned of during sleep !)
请尽快回复2）和3）问题。
你好hrq,
第2项）我试图重现您的上电和中断的观察：
上电：我看到电源时刻2秒的总活动。众所周知：允许32kHz XTAL振荡器在进入睡眠模式之前变得稳定。
对我来说，它看起来你的电路板在32khz xtal上没有运行，而是在rcx时钟上运行。这是correct吗？使用RCX时间更短。
如果没有，必须在其他地方找到原因。
But please note that using RCX in boost mode is not validated and not allowed. It cannot be used because of a less stable internal voltage which is used for he RCX oscillator.
In boost mode one must use the 32KHz Xtal oscillator for sleep clock.
中断：在这种情况下，我们还看到了像你这样做的较短活动时间。
请确认您的电路板是否正在XTAL32K或RCX上运行。
最好的问候，bb_dialog。
你好hrq,
item 3) sorry, we do not see the peak as in your screen captures:
we tried this for Boost-mode with 32KHz Xtal oscillator, and for Buck-mode with RCX enabled.
Both modes do not show an additional peak.
Depending on your answer for item 2): it could maybe related to the usage of the RCX-oscillator in Boost-mode.
请告诉我们。
最好的问候，bb_dialog.
嗨bb_dialog.
2) The 32KHz XTAL is used but the stabilisation time is reduced to least for testing purpose (by default it was 3200 which corresponds to 2 sec in rwip.c file) ,so during power on the total time is 126msec till first advertisement and it should go to sleep, but still it takes some 77 msec before goin to sleep .so the extra time maybe due to the xtal ??
And please confirm about the 1) regarding the coldboot during wakeup from deep sleep .we are getting the RF calibration after wakeup from deep sleep using default proximity_reporter_fh with no modification burned in OTP.
谢谢
对话团队请给出response asap !
你好hrq,
2）是的，可能是由所需的32K晶体开始时间引起的额外时间。
1）On the RF-cal event in your pictures.
我们看到在电动时在冷启动期间执行此RF-CAL，但不会在深度睡眠时执行。
如前所述，我们不期望这里冷却。
只有在芯片的温度会发生5摄氏度或更多时，才会执行RF-CAL。
最好的问候，bb_dialog.
Update: a request to you.
你可以在你的设备中加载相同的项目，但不是使用深睡眠，使用扩展睡眠模式？
There is no need to burn this in OTP, just load it in SysRam using Connection Manager or Smart Snippets.
What we like to know: are you seeing the RF-cal then too when pressng the interrupt button?
这对我们有所帮助。
嗨对话小组
During debugging mode in SRam there is no RF-cal upon wake up from Deep sleep (even also in extended sleep ). After Programming OTP there is RF-cal in COLD boot upon wakeup from deep sleep. Hence we couldnt find RF-cal when pressing interrupt during SRAM mode !.
在编程OTP后，请咨询此问题。
你好hrq,
在OTP中具有程序，我们确实期待有冷启动时的RF-CAL。
但是，除非温度变化（> = 5°C），否则预计不会看到这一点。
最好的问候，bb_dialog.