嗨
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
Daughter Card cold boot current
亲爱的人力资源g, do you mean 140mS or 140 seconds ?
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
Hi 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 for your response.
Thankyou
Hello hrg, there is nothing 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
Hi 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.
Hi 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.
In your advertising event, are the Rx/Tx peak currents around 10mA?
If so, it indicates proper functioning of the boost mode board.
Best regards, BB_Dialog.
Hi
BB_Dialog
1)
For your referrence J23 is open.The advertising peaks are approx 10 mA as you mentioned .
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 ?
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 !
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
During Interrupt
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.
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).
During Poweron
https://www.dropbox.com/s/2b9aj3eg2ayne29/power%20on.png?dl=0
During Interrupt:
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
Hi hrq,
thanks for the detailed snapshots.
We will have a look into these.
Best regards, BB_Dialog.
Update 14h30:
I can confirm the normal cold-boot timing and consumed charge:
Buck mode: 124 msec - 67 µC.
Boost mode: 124 msec - 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'm still trying to reproduce your interrupt case.
Best regards, BB_Dialog
Hi 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.
第一advertisi(在正常的广告时间ng takes about 7.5 msec and a charge of 3.5 or 7 µC is consumed).
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?
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
Hi BB_Dialog thankyou for the reply
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 !)
Please respond to the 2) & 3) questions also asap.
Hi 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.
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.
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.
Hi 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.
Please let us know.
Best regards, BB_Dialog.
Hi 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.
Thankyou
Dialog team please give a response asap !
Hi hrq,
2) yes, that extra time might be caused by the required 32K crystal starting time.
1) On the RF-cal event in your pictures.
We see this RF-cal being executed during the cold-boot when powering up, but not when coming from deep sleep.
像之前所说的,我们不期望一个冷启动。
The RF-cal only would be executed when e.g the chip's temperaure would have changed 5 degrees Celsius or more.
Best regards, BB_Dialog.
Update: a request to you.
could you load the same project in your device, but instead of using deep sleep, use extended sleep mode?
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?
This would be helpful for us.
Hi Dialog Team
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 !.
Please ack about this issue after programming OTP.
Hi 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).
Best regards, BB_Dialog.