Daughter Card cold boot current

17 posts / 0 new
Last post
hrg
Offline
Last seen: 4 years 1 week ago
Guru
Joined: 2014-08-05 13:37
Daughter Card cold boot current

HI
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 ??

JE_Dialog
Offline
Last seen: 1 year 1 month ago
Staff
Joined: 2013-12-05 14:02
Dear hrg, do you mean 140mS

Dear hrg, 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

 

hrg
Offline
Last seen: 4 years 1 week ago
Guru
Joined: 2014-08-05 13:37
Hi 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

JE_Dialog
Offline
Last seen: 1 year 1 month ago
Staff
Joined: 2013-12-05 14:02
Hello hrg, there is nothing

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

hrg
Offline
Last seen: 4 years 1 week ago
Guru
Joined: 2014-08-05 13:37
Hi 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.

BB_Dialog
Offline
Last seen: 2 years 3 months ago
Staff
Joined: 2013-12-05 14:44
Hi hrq,

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.

 

 

 

hrg
Offline
Last seen: 4 years 1 week ago
Guru
Joined: 2014-08-05 13:37
Hi

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

BB_Dialog
Offline
Last seen: 2 years 3 months ago
Staff
Joined: 2013-12-05 14:44
Hi hrq,

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

 

BB_Dialog
Offline
Last seen: 2 years 3 months ago
Staff
Joined: 2013-12-05 14:44
Hi hrq,

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.
(in normal advertising the time to first advertising 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

hrg
Offline
Last seen: 4 years 1 week ago
Guru
Joined: 2014-08-05 13:37
Hi BB_Dialog thankyou for the

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.

BB_Dialog
Offline
Last seen: 2 years 3 months ago
Staff
Joined: 2013-12-05 14:44
Hi hrq,

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.

 

BB_Dialog
Offline
Last seen: 2 years 3 months ago
Staff
Joined: 2013-12-05 14:44
Hi hrq,

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.

hrg
Offline
Last seen: 4 years 1 week ago
Guru
Joined: 2014-08-05 13:37
Hi 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

hrg
Offline
Last seen: 4 years 1 week ago
Guru
Joined: 2014-08-05 13:37
Dialog team please give a

Dialog team please give a response asap !

BB_Dialog
Offline
Last seen: 2 years 3 months ago
Staff
Joined: 2013-12-05 14:44
Hi hrq,

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.
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.

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.

hrg
Offline
Last seen: 4 years 1 week ago
Guru
Joined: 2014-08-05 13:37
Hi Dialog Team

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.

BB_Dialog
Offline
Last seen: 2 years 3 months ago
Staff
Joined: 2013-12-05 14:44
Hi hrq,

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.