嗨
we are following the same application(proximity reporter_fh) in the daughter board in boost mode as mention in the application note ANB-011 -Cold boot timing. In the application note it was explained that the total charge required for the cold boot sequence is 54.7 uC and the time needed is 146 ms. But while measuring in Power profiling tool the total charge is about 162 uC for 140 seconds ! Why the charge is more here ? Is operating under boost mode consumes more charge ??
星期二,2014-09-09 04:57
#1
子卡冷靴电流
亲爱的HRG，你的意思是140msor 140 seconds ?
虽然峰值电流总体上升到1.5V在增强中，但平均能量应该非常相似。如果你可以给你的意思是140ms，我会调查一下。Alwasy可以预计某些MS的启动时间略有变化。
BR JE_Dialog
嗨je_dialog
sorry it is 140 msec! but the charge consumed in boost mode is 3 times more than you mention in that application note!
Waiitng为您的回复。
Thankyou
Hello HRG，什么都没有obvious that springs to mind : can you confirm your HW & SW set-up and verify modifications made to the daughtercard for boost mode ?
BR JE_Dialog
嗨je_dialog
The HW set up is according to the User manual --Jumper J13 connected as 3-4 for Power supply of the measurement circuit . Jumper J14 as 1-2 for Boost Configuration.The software is Proximity reporter_fh with no modification!. For Boost mode Hw setup-as per in the schematic .And the supply voltage is 1.5 volt.
嗨Hrq，
要确定，您没有提到J23：应删除1.5V电源的此一个。
虽然我最终不认为这是您测量的高耗电费用。
Boost模式不应使用比降压模式更多的充电。
只有在冷启动期间的升压模式下，DCDC转换器必须为电容器充电，导致高初始峰值电流，但这不应贡献超过几μc。
In your advertising event, are the Rx/Tx peak currents around 10mA?
If so, it indicates proper functioning of the boost mode board.
最好的问候，bb_dialog。
Hi
BB_Dialog
1)
For your referrence J23 is open.The advertising peaks are approx 10 mA as you mentioned .
proximtiy_reporter_fh进入深度睡眠模式呈现3分钟。所以当中断时，它会用冰靴醒来时醒来吗？
But the cold boot after interrupt seems to be very high(as i mentioned before (162 uC - 150 uC ) when compared to the power on cold boot (125uC)!
There is difference in timing also !
由于没有选项在对话框论坛中附加文件，因此您的参考我已附加到Dropbox中共享的文件链接。
在电力期间
https://www.dropbox.com/s/b1rrk73p3d690jg/poweron.png?dl=0
During Interrupt
https://www.dropbox.com/s/ob83u162r05ss8j/interrupt.png?dl=0.
2）我还有一个问题所以我添加了这些。
Proximity_Reporter_FH程序被修改，使其执行一个广告事件并在中断（按钮）后，它确实一个广告事件并再次睡眠。
so while testing in debugging mode both power on and during interrupt was perfect . the the programmed is burned to OTP. But now during poweron ,the first advertising is done and it takes some 75 msec to go to sleep mode. But this doesnt happen during interrupt wakeup . I have shared the snapshot here,you can find the difference between them . (Note: it also suffers the same problem as i mentioned in 1) question).
在Poweron期间
https://www.dropbox.com/s/2b9aj3eg2ayne29/power%20on.png?dl=0
在中断期间：
https://www.dropbox.com/s/3h0cuxkga4w79jy/interrupt.png?dl=0
3)
Also one more doubt within these .whenever the switch K1 is pressed after one advertising event there is also an unknown peak .! (note: This peak you can observe keenly in normal Proximity_reporter_fh program when you press K1 !) Here is the snapshot of these
https://www.dropbox.com/s/8qt913jtlm9bn42/switch.png?dl=0
https://www.dropbox.com/s/4ycd4nrl6l85ug4/unknown%20peak.png?dl=0
Thankyou
HRG.
嗨Hrq，
谢谢你的详细快照。
We will have a look into these.
最好的问候，bb_dialog。
Update 14h30:
我可以确认正常的冷启动时间和消耗充电：
Buck mode: 124 msec - 67 µC.
Boost mode: 124 msec - 128 µC.
由于电流越高，可以解释升压模式中的较高消耗电荷@ 1.5V：大约在降压模式@ 3V时高约两倍。
从电池中消耗的能量（J）虽然将大致相同（3 x 67 = 1.5 x 128）。
I'm still trying to reproduce your interrupt case.
Best regards, BB_Dialog
嗨Hrq，
我讨论了一些同事的第二个案例（中断），
通常在从睡眠中醒来时，没有预期冷靴。
我们预计大约10毫秒Upto Provert广告，并且消耗电荷约为10μC（降压）或20μC（升压）。
此帐户占用初始化的额外时间和充电等。我们没有看到屏幕捕获中的RF校准。
在真正的冷启动中，实际上，RF-CAL被执行：在22,100秒后的PowerOn图片中。
第一advertisi(在正常的广告时间ng takes about 7.5 msec and a charge of 3.5 or 7 µC is consumed).
几个问题要进一步帮助您：
您的DA14580是DA14580-01（ES5）？
您使用的是哪个SDK版本？您是否修改了邻近代码？
Which key/which GPIO are you using to wake up the BLE chip?
We used one of the keys on he motherboard.
Best regards, BB_Dialog
嗨bb_dialog谢谢你reply
是的，它是DA14580_CB_PXI_WLCSP 078-05-C ES5。
SDK版本3.0.4.0。
我们在母板中使用K1（默认在Proximity_reporter_FH中）。
冷靴似乎在正常的邻近应用程序中发生（即3分钟后它会睡觉，然后按下按钮，唤醒一些RF校准。）。
（您在另一个帖子中提到的，在使用Deepsleep模式时，SRAM将在睡眠期间转换！）
Please respond to the 2) & 3) questions also asap.
嗨Hrq，
Item 2) I tried to reproduce your observations for Power-On and Interrupt:
Power-On: I see a total activity of 2seconds from the power-on moment. This is known: it's to allow the 32KHz Xtal oscillator to become stable before going into sleep mode.
To me it looks your board isn't running on 32KHz Xtal, but on RCX clock. Is that corrrect? Using the RCX the time is much shorter.
If not, the cause has to be found elsewhere.
但请注意，在Boost模式下使用RCX未经验证且不允许。由于用于HE RCX振荡器的稳定内部电压，因此不能使用它。
在Boost模式中，必须使用32kHz Xtal振荡器进行睡眠时钟。
Interrupt: in this case we also see a shorter activity time like you did.
Please confirm whether your board is running on Xtal32K or RCX.
best regards, BB_Dialog.
嗨Hrq，
第3项）抱歉，我们没有看到屏幕中的峰值捕获：
我们尝试了使用32kHz XTAL振荡器的升压模式，并启用RCX的降压模式。
这两种模式都没有显示额外的峰值。
根据您的第2项的答案）：可能与升压模式中的RCX-振荡器的使用可能相关。
Please let us know.
最好的问候，bb_dialog。
Hi BB_Dialog
2）使用32kHz XTAL，但稳定时间减少到至少测试目的（默认情况下，它是3200对应于RWIP.C文件中的2秒），因此在总时间的电源期间为126毫秒，直到第一广告和它应该去睡觉，但仍然需要大约77毫秒前睡觉。所以额外的时间可能是由于xtal ??
请在深度睡眠中唤醒唤醒期间的1）。我们在使用默认Proximity_reporter_FH唤醒后唤醒唤醒后的RF校准，在OTP中没有修改。
Thankyou
对话团队请尽快给出回复！
嗨Hrq，
2) yes, that extra time might be caused by the required 32K crystal starting time.
1）在图片中的RF-Cal活动上。
We see this RF-cal being executed during the cold-boot when powering up, but not when coming from deep sleep.
As said before, we don't expect a cold-boot here.
The RF-cal only would be executed when e.g the chip's temperaure would have changed 5 degrees Celsius or more.
最好的问候，bb_dialog。
更新：对您的请求。
could you load the same project in your device, but instead of using deep sleep, use extended sleep mode?
无需在OTP中刻录此功能，只需将其加载在Sysram中使用Connection Manager或Smart Spippets。
我们想知道的是：在按下中断按钮时，你也看到了rf-cal吗？
This would be helpful for us.
Hi Dialog Team
在SRAM中调试模式期间，从深睡眠中醒来时没有RF-CAL（甚至在延长睡眠中也是如此）。编程OTP后，从深睡眠唤醒时，冷启动时有RF-CAL。因此，在SRAM模式下按下中断时，我们无法找到RF-CAL！。
Please ack about this issue after programming OTP.
嗨Hrq，
having the program in OTP, we indeed expect a RF-cal when having a cold boot.
However, it's not expected to see this when coming from deep sleep, unless the temperature changes (>= 5°C).
最好的问候，bb_dialog。