嗨正如应用程序注释ANB-011 -冷启动定时中提到的，我们在子板的boost模式下遵循相同的应用程序(接近reporter_fh)。在应用说明中解释了冷启动序列所需的总费用是54.7 uC，所需的时间是146 ms。但在功率分析工具测量时，总电荷约为162 uC，持续140秒!为什么这里收费更高?在助推模式下运行是否消耗更多费用??
亲爱的hrg，你是说140毫秒还是140秒?
虽然升压时峰值电流总体高于1.5V，但平均能量应该非常相似。如果你能确定你的意思是140毫秒，我会调查的。人们可能会期望一些毫秒的启动时间会有轻微的变化。
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电源，应该删除这个。虽然我不认为这最终是你测量的高消耗电荷的原因。
升压模式不应比降压模式消耗更多的电量。仅在冷启动期间的升压模式下，DCDC转换器必须对电容器充电，这会导致高初始峰值电流，但其贡献不应超过几µC。
在你的广告活动中，Rx/Tx的峰值电流是否在10mA左右?如果是，则表示升压模式板功能正常。
向你问好，BB_对话。
嗨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） 我还有一个问题，所以我要补充这些。修改接近报告程序，使其执行一个广告事件并进入深度睡眠，在中断（按钮）时执行一个广告事件并再次进入睡眠。因此，在调试模式下测试时，通电和中断都是完美的。程序被烧成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消耗的电荷较高，这可以解释为电流较高：大约是降压模式下@3V消耗电荷的两倍。不过，电池消耗的能量（J）将大致相同（3 x 67=1.5 x 128）。
我还在尝试重现你的中断情况。
最好的问候,BB_Dialog
我和一些同事讨论了第二个案例（中断），
通常情况下，从睡眠中醒来时，不需要冷启动。我们预计在第一次发布广告前约10毫秒，消费费用约为10µC（buck）或20µC（boost）。这需要额外的初始化时间和费用等。我们在屏幕截图中没有看到射频校准。在真正的冷启动中，RF cal确实被执行：在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（接近报告器中的默认值）。即使在正常的近距离应用程序中，冷启动似乎也会发生（即3分钟后，它将进入睡眠状态，然后按下按钮，通过一些射频校准将其唤醒）。（您在另一篇文章中提到，在使用深度睡眠模式时，SRAM将在睡眠期间关闭！）
也请尽快回复2)& 3)问题。
项目2)我试图重现您对Power-On和Interrupt的观察:
开机:我看到从开机时刻开始的总活动时间为2秒。这是众所周知的:这是为了让32KHz的Xtal振荡器在进入睡眠模式之前变得稳定。在我看来，你的主板不是在32KHz Xtal上运行，而是在RCX时钟上运行。这是corrrect吗?使用RCX的时间更短。如果没有，就必须从别处寻找原因。但请注意，在boost模式下使用RCX是不被验证的，也是不允许的。由于用于RCX振荡器的内部电压不太稳定，因此不能使用。在升压模式下，必须使用32KHz Xtal振荡器作为睡眠时钟。
中断:在这种情况下，我们也看到更短的活动时间，就像你做的。
请确认你的板是在Xtal32K还是RCX上运行。
最好的问候,BB_Dialog。
第3项）很抱歉，我们没有在您的屏幕截图中看到峰值：
我们在32KHz Xtal振荡器的升压模式和RCX启用的降压模式下进行了尝试。两种模式均未显示额外峰值。
根据您对第2项的回答）：这可能与在升压模式下使用RCX振荡器有关。请让我们知道。
2） 虽然使用了32KHz XTAL，但出于测试目的，稳定时间减少到最少（默认情况下，稳定时间为3200，相当于rwip.c文件中的2秒），因此在通电期间，到第一次播发的总时间为126ms，并且应进入睡眠状态，但仍然需要77毫秒才能入睡。所以额外的时间可能是因为xtal？？
请确认1）关于从深度睡眠中醒来时的冷启动。我们在从深度睡眠中醒来后使用默认的接近报告器fh进行射频校准，没有在OTP中进行任何修改。谢谢
对话小组请尽快回复！
2)是的，额外的时间可能是由于所需的32K晶体启动时间造成的。
1） 在您的图片中显示RF cal事件。我们看到这个RF-cal在启动时冷启动时执行，但从深度睡眠中醒来时不会执行。就像之前说的，我们不认为这里会冷靴。RF-cal只会在芯片温度变化5摄氏度或更多的情况下执行。
更新：给你的请求。你可以在你的设备上加载相同的项目，但是使用扩展睡眠模式而不是深度睡眠模式吗?无需在OTP中烧录，只需使用连接管理器或智能代码段将其加载到系统内存中即可。我们想知道的是：按下中断按钮时，您是否也看到RF cal？这对我们很有帮助。
嗨对话小组
在SRam的调试模式下，从深度睡眠中醒来（即使是在长时间睡眠中），也没有RF cal。编程OTP后，从深度睡眠中醒来时，冷启动中有RF cal。因此，在SRAM模式下按中断键时，我们无法找到RF cal！。请在OTP编程后确认此问题。
有了OTP程序，我们确实希望在冷启动时使用RF-cal。然而，从深度睡眠中醒来时不会出现这种情况，除非温度发生变化(>= 5°C)。
亲爱的hrg，你是说140毫秒还是140秒?
虽然升压时峰值电流总体高于1.5V，但平均能量应该非常相似。如果你能确定你的意思是140毫秒，我会调查的。人们可能会期望一些毫秒的启动时间会有轻微的变化。
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电源，应该删除这个。
虽然我不认为这最终是你测量的高消耗电荷的原因。
升压模式不应比降压模式消耗更多的电量。
仅在冷启动期间的升压模式下，DCDC转换器必须对电容器充电，这会导致高初始峰值电流，但其贡献不应超过几µC。
在你的广告活动中，Rx/Tx的峰值电流是否在10mA左右?
如果是，则表示升压模式板功能正常。
向你问好，BB_对话。
嗨
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） 我还有一个问题，所以我要补充这些。
修改接近报告程序，使其执行一个广告事件并进入深度睡眠，在中断（按钮）时执行一个广告事件并再次进入睡眠。
因此，在调试模式下测试时，通电和中断都是完美的。程序被烧成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_对话。
更新14 h30:
我可以确认正常的冷启动时间和消耗的费用：
Buck模式:124毫秒- 67µC。
Boost模式:124 msec - 128µ
升压模式下@1.5V消耗的电荷较高，这可以解释为电流较高：大约是降压模式下@3V消耗电荷的两倍。
不过，电池消耗的能量（J）将大致相同（3 x 67=1.5 x 128）。
我还在尝试重现你的中断情况。
最好的问候,BB_Dialog
你好，hrq，
我和一些同事讨论了第二个案例（中断），
通常情况下，从睡眠中醒来时，不需要冷启动。
我们预计在第一次发布广告前约10毫秒，消费费用约为10µC（buck）或20µC（boost）。
这需要额外的初始化时间和费用等。我们在屏幕截图中没有看到射频校准。
在真正的冷启动中，RF cal确实被执行：在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（接近报告器中的默认值）。
即使在正常的近距离应用程序中，冷启动似乎也会发生（即3分钟后，它将进入睡眠状态，然后按下按钮，通过一些射频校准将其唤醒）。
（您在另一篇文章中提到，在使用深度睡眠模式时，SRAM将在睡眠期间关闭！）
也请尽快回复2)& 3)问题。
你好，hrq，
项目2)我试图重现您对Power-On和Interrupt的观察:
开机:我看到从开机时刻开始的总活动时间为2秒。这是众所周知的:这是为了让32KHz的Xtal振荡器在进入睡眠模式之前变得稳定。
在我看来，你的主板不是在32KHz Xtal上运行，而是在RCX时钟上运行。这是corrrect吗?使用RCX的时间更短。
如果没有，就必须从别处寻找原因。
但请注意，在boost模式下使用RCX是不被验证的，也是不允许的。由于用于RCX振荡器的内部电压不太稳定，因此不能使用。
在升压模式下，必须使用32KHz Xtal振荡器作为睡眠时钟。
中断:在这种情况下，我们也看到更短的活动时间，就像你做的。
请确认你的板是在Xtal32K还是RCX上运行。
最好的问候,BB_Dialog。
你好，hrq，
第3项）很抱歉，我们没有在您的屏幕截图中看到峰值：
我们在32KHz Xtal振荡器的升压模式和RCX启用的降压模式下进行了尝试。
两种模式均未显示额外峰值。
根据您对第2项的回答）：这可能与在升压模式下使用RCX振荡器有关。
请让我们知道。
向你问好，BB_对话。
嗨BB_Dialog
2） 虽然使用了32KHz XTAL，但出于测试目的，稳定时间减少到最少（默认情况下，稳定时间为3200，相当于rwip.c文件中的2秒），因此在通电期间，到第一次播发的总时间为126ms，并且应进入睡眠状态，但仍然需要77毫秒才能入睡。所以额外的时间可能是因为xtal？？
请确认1）关于从深度睡眠中醒来时的冷启动。我们在从深度睡眠中醒来后使用默认的接近报告器fh进行射频校准，没有在OTP中进行任何修改。
谢谢
对话小组请尽快回复！
你好，hrq，
2)是的，额外的时间可能是由于所需的32K晶体启动时间造成的。
1） 在您的图片中显示RF cal事件。
我们看到这个RF-cal在启动时冷启动时执行，但从深度睡眠中醒来时不会执行。
就像之前说的，我们不认为这里会冷靴。
RF-cal只会在芯片温度变化5摄氏度或更多的情况下执行。
向你问好，BB_对话。
更新：给你的请求。
你可以在你的设备上加载相同的项目，但是使用扩展睡眠模式而不是深度睡眠模式吗?
无需在OTP中烧录，只需使用连接管理器或智能代码段将其加载到系统内存中即可。
我们想知道的是：按下中断按钮时，您是否也看到RF cal？
这对我们很有帮助。
嗨对话小组
在SRam的调试模式下，从深度睡眠中醒来（即使是在长时间睡眠中），也没有RF cal。编程OTP后，从深度睡眠中醒来时，冷启动中有RF cal。因此，在SRAM模式下按中断键时，我们无法找到RF cal！。
请在OTP编程后确认此问题。
你好，hrq，
有了OTP程序，我们确实希望在冷启动时使用RF-cal。
然而，从深度睡眠中醒来时不会出现这种情况，除非温度发生变化(>= 5°C)。
向你问好，BB_对话。