嗨正如应用程序注释ANB-011 -冷启动定时中提到的，我们在子板的boost模式下遵循相同的应用程序(接近reporter_fh)。在应用说明中解释了冷启动序列所需的总费用是54.7 uC，所需的时间是146 ms。但在功率分析工具测量时，总电荷约为162 uC，持续140秒!为什么这里收费更高?在助推模式下运行是否消耗更多费用??
亲爱的hrg，你是说140毫秒还是140秒?
虽然峰值电流总体上高于1.5V升压，但平均能量应该相当相似。如果你能确认你指的是140mS，我会考虑的。人们总是可以期待一些mS引导时间的细微变化。
BR JE_Dialog
嗨JE_Dialog
抱歉是140毫秒!但是在boost模式下消耗的电量比你在应用笔记中提到的要多3倍!
等待你的回复。
谢谢
你好，hrg，没有什么明显的想法:你能确认一下你的HW和SW设置，并确认一下对boost模式的子卡所做的修改吗?
嗨JE_DialogHW的设置是根据用户手册-跳线J13连接为3-4测量电路的电源。跳线J14作为1-2 Boost配置。软件是Proximity reporter_fh，没有修改!升压模式Hw设置-如原理图所示，电源电压为1.5伏。
嗨hrq,
可以肯定的是，你没有提到J23:这一个应该被删除为1.5V电源。虽然我不认为这最终是你测量高消耗电荷的原因。
升压模式不应比降压模式消耗更多的电量。只有在升压模式下，在冷启动期间，ddc -转换器不得不充电电容器，这导致一个高的初始峰值电流，但这应该不会贡献超过几个µC。
在你的广告活动中，Rx/Tx的峰值电流是否在10mA左右?如果是，则表示升压模式板功能正常。
最好的问候,BB_Dialog。
嗨BB_Dialog
1）对于您的推荐，J23是开放的。广告峰值如您所提到的约10 mA。proximtiy_reporter_fh在3分钟后进入深度睡眠模式，所以当中断被给予时，它会用冷启动唤醒，对吗?但是中断后的冷启动似乎非常高(正如我之前提到的(162 uC - 150 uC)相比于冷启动(125uC)!时间上也有区别!
由于在对话框中没有附加文件的选项，为了供您参考，我在dropbox中附加了共享的文件链接。
在上电https://www.dropbox.com/s/b1rrk73p3d690jg/poweron.png?dl=0
在中断
https://www.dropbox.com/s/ob83u162r05ss8j/interrupt.png?dl=0
2)我还有一个问题，所以我添加与这些。proximity_reporter_fh程序被修改，以便它执行一个广告事件并进入深度睡眠，在中断(按按钮)时，它执行一个广告事件并再次进入睡眠。因此，在调试模式下测试时，通电和中断都是完美的。程序被烧成OTP。但现在在开机时，第一个广告已经完成，进入睡眠模式需要大约75毫秒。但这在中断唤醒时不会发生。我在这里分享了快照，你可以发现它们之间的区别。(注:它也有我在1)问题中提到的同样的问题)。
在集成软件包
https://www.dropbox.com/s/2b9aj3eg2ayne29/power%20on.png?dl=0
在中断:https://www.dropbox.com/s/3h0cuxkga4w79jy/interrupt.png?dl=0
3）还有一个疑问。每当开关K1在一个广告事件后被按下时，也有一个未知的峰值。(注意:当您按K1时，您可以在正常的Proximity_reporter_fh程序中敏锐地观察到这个峰值!)这是它们的快照
https://www.dropbox.com/s/8qt913jtlm9bn42/switch.png?dl=0
https://www.dropbox.com/s/4ycd4nrl6l85ug4/unknown%20peak.png?dl=0
谢谢hrg
感谢详细的快照。我们将对这些进行调查。
更新14 h30:
我可以确认正常的冷启动时间和消耗的费用:
Buck模式:124毫秒- 67µC。Boost模式:124 msec - 128µ
在升压模式@ 1.5V时消耗的电荷更高，可以解释为更高的电流:大约是buck模式@ 3V时的两倍高。从电池消耗的能量(J)将是相同的(3 x 67 = 1.5 x 128)。
我还在尝试重现你的中断情况。
最好的问候,BB_Dialog
我和一些同事讨论了第二种情况(中断)，
正常情况下，当从睡眠中醒来时，不需要冷启动。我们预计到第一次广告时约10毫秒，耗电量约10µC (buck)或20µC (boost)。这包括额外的时间和费用的初始化等。我们在屏幕截图中看不到rf校准。在真正的冷启动中，RF-cal确实被执行了:在PowerOn图片中，仅在22100秒之后。（在正常的广告中，首次广告的时间大约需要7.5毫秒，并且消耗了3.5或7μc的电荷）。
以下几个问题可以进一步帮助你:您的DA14580是DA14580-01 (ES5)吗?您使用的是哪个SDK版本?你修改接近码了吗?您使用哪个键/哪个GPIO来唤醒BLE芯片?我们用了主板上的一把钥匙。
你好BB_Dialog谢谢你的回复
是DA14580_CB_PXI_WLCSP 078-05-C ES5。SDK版本3.0.4.0。我们在主板上使用K1(默认在proximity_reporter_fh中)。冷启动似乎发生了，甚至在正常的接近应用(即3分钟后，它将进入睡眠，然后按下按钮，它醒来与一些射频校准。)(你在另一篇文章中提到，当使用深度睡眠模式时，SRAM将在睡眠期间打开!)
也请尽快回复2)& 3)问题。
项目2)我试图重现您对Power-On和Interrupt的观察:
开机:我看到从开机时刻开始的总活动时间为2秒。这是众所周知的:这是为了让32KHz的Xtal振荡器在进入睡眠模式之前变得稳定。在我看来，你的主板不是在32KHz Xtal上运行，而是在RCX时钟上运行。这是corrrect吗?使用RCX的时间更短。如果没有，就必须从别处寻找原因。但是请注意，在boost模式下使用RCX是不被验证和不被允许的。它不能使用，因为不稳定的内部电压是用于RCX振荡器。在boost模式下，必须使用32KHz Xtal振荡器用于睡眠时钟。
中断:在这种情况下，我们也看到更短的活动时间，就像你做的。
请确认你的板是在Xtal32K还是RCX上运行。
抱歉，我们没有看到您的屏幕截图中的峰值:
我们尝试了32KHz Xtal振荡器的boost模式，以及启用RCX的buck模式。两种模式都没有额外的峰值。
取决于你对第2项的回答:这可能与在boost模式下使用rcx振荡器有关。请让我们知道。
2)使用32KHz的XTAL，但稳定时间被减少到最少的测试目的(默认为3200对应2秒在rwip.c文件)，所以在电源上的总时间是126毫秒，直到第一次广告，它应该去睡觉，但是在入睡之前仍然需要大约77毫秒，所以额外的时间可能是由于xtal ??
请确认1)关于从深度睡眠中唤醒时的冷启动，我们使用默认的proximity_reporter_fh在OTP中没有修改，从深度睡眠中唤醒后，我们将获得射频校准。谢谢
对话团队请尽快回复!
2)是的，额外的时间可能是由于所需的32K晶体启动时间造成的。
1)在RF-cal事件在你的照片。我们看到这个RF-cal在启动时冷启动时执行，但从深度睡眠中醒来时不会执行。就像之前说的，我们不认为这里会冷靴。RF-cal只会在芯片温度变化5摄氏度或更多的情况下执行。
更新:给你的请求。你可以在你的设备上加载相同的项目，但是使用扩展睡眠模式而不是深度睡眠模式吗?没有必要在OTP中刻录它，只是使用连接管理器或智能片段在系统ram中加载它。我们想知道的是:当按下中断按钮时，你是否也看到RF-cal ?这对我们很有帮助。
嗨对话小组
在SRam的调试模式中，从深度睡眠(甚至在延长睡眠)中醒来时没有RF-cal。在编程OTP之后，从深度睡眠中唤醒的冷启动中有RF-cal。因此，当在SRAM模式下按下中断时，我们无法找到RF-cal !请在OTP编程后确认此问题。
有了OTP程序，我们确实希望在冷启动时使用RF-cal。然而，从深度睡眠中醒来时不会出现这种情况，除非温度发生变化(>= 5°C)。
亲爱的hrg，你是说140毫秒还是140秒?
虽然峰值电流总体上高于1.5V升压，但平均能量应该相当相似。如果你能确认你指的是140mS，我会考虑的。人们总是可以期待一些mS引导时间的细微变化。
BR JE_Dialog
嗨JE_Dialog
抱歉是140毫秒!但是在boost模式下消耗的电量比你在应用笔记中提到的要多3倍!
等待你的回复。
谢谢
你好，hrg，没有什么明显的想法:你能确认一下你的HW和SW设置，并确认一下对boost模式的子卡所做的修改吗?
BR JE_Dialog
嗨JE_Dialog
HW的设置是根据用户手册-跳线J13连接为3-4测量电路的电源。跳线J14作为1-2 Boost配置。软件是Proximity reporter_fh，没有修改!升压模式Hw设置-如原理图所示，电源电压为1.5伏。
嗨hrq,
可以肯定的是，你没有提到J23:这一个应该被删除为1.5V电源。
虽然我不认为这最终是你测量高消耗电荷的原因。
升压模式不应比降压模式消耗更多的电量。
只有在升压模式下，在冷启动期间，ddc -转换器不得不充电电容器，这导致一个高的初始峰值电流，但这应该不会贡献超过几个µC。
在你的广告活动中，Rx/Tx的峰值电流是否在10mA左右?
如果是，则表示升压模式板功能正常。
最好的问候,BB_Dialog。
嗨
BB_Dialog
1）
对于您的推荐，J23是开放的。广告峰值如您所提到的约10 mA。
proximtiy_reporter_fh在3分钟后进入深度睡眠模式，所以当中断被给予时，它会用冷启动唤醒，对吗?
但是中断后的冷启动似乎非常高(正如我之前提到的(162 uC - 150 uC)相比于冷启动(125uC)!
时间上也有区别!
由于在对话框中没有附加文件的选项，为了供您参考，我在dropbox中附加了共享的文件链接。
在上电
https://www.dropbox.com/s/b1rrk73p3d690jg/poweron.png?dl=0
在中断
https://www.dropbox.com/s/ob83u162r05ss8j/interrupt.png?dl=0
2)我还有一个问题，所以我添加与这些。
proximity_reporter_fh程序被修改，以便它执行一个广告事件并进入深度睡眠，在中断(按按钮)时，它执行一个广告事件并再次进入睡眠。
因此，在调试模式下测试时，通电和中断都是完美的。程序被烧成OTP。但现在在开机时，第一个广告已经完成，进入睡眠模式需要大约75毫秒。但这在中断唤醒时不会发生。我在这里分享了快照，你可以发现它们之间的区别。(注:它也有我在1)问题中提到的同样的问题)。
在集成软件包
https://www.dropbox.com/s/2b9aj3eg2ayne29/power%20on.png?dl=0
在中断:
https://www.dropbox.com/s/3h0cuxkga4w79jy/interrupt.png?dl=0
3）
还有一个疑问。每当开关K1在一个广告事件后被按下时，也有一个未知的峰值。(注意:当您按K1时，您可以在正常的Proximity_reporter_fh程序中敏锐地观察到这个峰值!)这是它们的快照
https://www.dropbox.com/s/8qt913jtlm9bn42/switch.png?dl=0
https://www.dropbox.com/s/4ycd4nrl6l85ug4/unknown%20peak.png?dl=0
谢谢
hrg
嗨hrq,
感谢详细的快照。
我们将对这些进行调查。
最好的问候,BB_Dialog。
更新14 h30:
我可以确认正常的冷启动时间和消耗的费用:
Buck模式:124毫秒- 67µC。
Boost模式:124 msec - 128µ
在升压模式@ 1.5V时消耗的电荷更高，可以解释为更高的电流:大约是buck模式@ 3V时的两倍高。
从电池消耗的能量(J)将是相同的(3 x 67 = 1.5 x 128)。
我还在尝试重现你的中断情况。
最好的问候,BB_Dialog
嗨hrq,
我和一些同事讨论了第二种情况(中断)，
正常情况下，当从睡眠中醒来时，不需要冷启动。
我们预计到第一次广告时约10毫秒，耗电量约10µC (buck)或20µC (boost)。
这包括额外的时间和费用的初始化等。我们在屏幕截图中看不到rf校准。
在真正的冷启动中，RF-cal确实被执行了:在PowerOn图片中，仅在22100秒之后。
（在正常的广告中，首次广告的时间大约需要7.5毫秒，并且消耗了3.5或7μc的电荷）。
以下几个问题可以进一步帮助你:
您的DA14580是DA14580-01 (ES5)吗?
您使用的是哪个SDK版本?你修改接近码了吗?
您使用哪个键/哪个GPIO来唤醒BLE芯片?
我们用了主板上的一把钥匙。
最好的问候,BB_Dialog
你好BB_Dialog谢谢你的回复
是DA14580_CB_PXI_WLCSP 078-05-C ES5。
SDK版本3.0.4.0。
我们在主板上使用K1(默认在proximity_reporter_fh中)。
冷启动似乎发生了，甚至在正常的接近应用(即3分钟后，它将进入睡眠，然后按下按钮，它醒来与一些射频校准。)
(你在另一篇文章中提到，当使用深度睡眠模式时，SRAM将在睡眠期间打开!)
也请尽快回复2)& 3)问题。
嗨hrq,
项目2)我试图重现您对Power-On和Interrupt的观察:
开机:我看到从开机时刻开始的总活动时间为2秒。这是众所周知的:这是为了让32KHz的Xtal振荡器在进入睡眠模式之前变得稳定。
在我看来，你的主板不是在32KHz Xtal上运行，而是在RCX时钟上运行。这是corrrect吗?使用RCX的时间更短。
如果没有，就必须从别处寻找原因。
但是请注意，在boost模式下使用RCX是不被验证和不被允许的。它不能使用，因为不稳定的内部电压是用于RCX振荡器。
在boost模式下，必须使用32KHz Xtal振荡器用于睡眠时钟。
中断:在这种情况下，我们也看到更短的活动时间，就像你做的。
请确认你的板是在Xtal32K还是RCX上运行。
最好的问候,BB_Dialog。
嗨hrq,
抱歉，我们没有看到您的屏幕截图中的峰值:
我们尝试了32KHz Xtal振荡器的boost模式，以及启用RCX的buck模式。
两种模式都没有额外的峰值。
取决于你对第2项的回答:这可能与在boost模式下使用rcx振荡器有关。
请让我们知道。
最好的问候,BB_Dialog。
嗨BB_Dialog
2)使用32KHz的XTAL，但稳定时间被减少到最少的测试目的(默认为3200对应2秒在rwip.c文件)，所以在电源上的总时间是126毫秒，直到第一次广告，它应该去睡觉，但是在入睡之前仍然需要大约77毫秒，所以额外的时间可能是由于xtal ??
请确认1)关于从深度睡眠中唤醒时的冷启动，我们使用默认的proximity_reporter_fh在OTP中没有修改，从深度睡眠中唤醒后，我们将获得射频校准。
谢谢
对话团队请尽快回复!
嗨hrq,
2)是的，额外的时间可能是由于所需的32K晶体启动时间造成的。
1)在RF-cal事件在你的照片。
我们看到这个RF-cal在启动时冷启动时执行，但从深度睡眠中醒来时不会执行。
就像之前说的，我们不认为这里会冷靴。
RF-cal只会在芯片温度变化5摄氏度或更多的情况下执行。
最好的问候,BB_Dialog。
更新:给你的请求。
你可以在你的设备上加载相同的项目，但是使用扩展睡眠模式而不是深度睡眠模式吗?
没有必要在OTP中刻录它，只是使用连接管理器或智能片段在系统ram中加载它。
我们想知道的是:当按下中断按钮时，你是否也看到RF-cal ?
这对我们很有帮助。
嗨对话小组
在SRam的调试模式中，从深度睡眠(甚至在延长睡眠)中醒来时没有RF-cal。在编程OTP之后，从深度睡眠中唤醒的冷启动中有RF-cal。因此，当在SRAM模式下按下中断时，我们无法找到RF-cal !
请在OTP编程后确认此问题。
嗨hrq,
有了OTP程序，我们确实希望在冷启动时使用RF-cal。
然而，从深度睡眠中醒来时不会出现这种情况，除非温度发生变化(>= 5°C)。
最好的问候,BB_Dialog。