Sleep, Nap, DisableBOD

BCJKiwi

Senior Member
In the sleep command description, the use of disablebod is suggested for further power comsumption reduction.

However, for the NAP command disablebod is not mentioned.

Can disablebod provide the same benefits for NAP as for Sleep?
 

Haku

Senior Member
I've just tried using sleep & nap with and without disablebod on an 08m and an 18m2, only powered from two alkaline AA's and and no extra components connected (not even the download cable).

Strangely at most I could see around 1uA difference on both chips when disablebod was used compared to when it wasn't used, the code was 70 "nap 7" commands in a do...loop, and replaced "nap 7" with "sleep 3" for the sleep tests.

On all four tests on each chip, the 08m was using around 1.21uA-1.64uA and the 18m2 was using around 18.8uA-19.6uA.


Which makes me wonder what situation / chip acutally benefits from using disablebod in low power situations?
 

Dippy

Moderator
Generally speaking, you should look at the PIC data sheet specs to see the power consumption figures for Brownout Detection - the figures for that and other peripherals on the PIC are all there.

As the 18M2 is apparently a custom special PIC chip and no data sheet has been volunteered then I suspect you'll have to use the figures based on the PIC that it is apparently based upon (which I've forgotten).

Haku, you must have some really fancy/expensive meter that can measure to those levels. What is it? I want one.
My cheapo microamp meter is not as good as I originally thought, so I need one like yours. What make? Where did you get it from? And how much?
 

hippy

Senior Member
The electrical characteristics of the 18M2 will be the same as found in the Microchip 16F1827 datasheet, though after a cursory glance I couldn't see a current consumption rating for the brown-out circuitry when enabled.

Though the brown-out circuitry may use minimal current and DISABLEBOD may appear to have little effect, for ultra low-power operation every little helps, and to achieve the lowest possible consumption all internal circuitry which can be turned off should be, hence the suggestion to use DISABLEBOD. Even if just 1uA is saved from 20uA with BOD enabled , that's still an additional 5% reduction in consumption.
 

Dippy

Moderator
Absolutley.

Ah, yes, the 16F1827.
In my Data Sheet I see a BOR current of 8 to ~50 max microAmps - parameter D024.

Obviously I don't know the precise conditions used by Haku when testing, but something sounds a little wrong.
At 3V an 08M BOD peripheral uses 50 to 70 microAmps and Haku measured a difference of only 1 microAmp. :confused:

Perhaps I don't want the same DMM (Ebay?) as it sounds worse than mine (Maplin) :)

If you look through a PIC data sheet you can see a number of peripherals that use power. I can only assume that PICAXE BASIC allows you to control them with a POKE (?).
 

hippy

Senior Member
Thanks for the D024 reference, so yes it should be a difference of ~50uA at 3V, ~100uA at 5V. With ...

#Picaxe 18M2
Do
Pause 2000 : DisableBod
Pause 2000 : EnableBod
Loop

Serial In tied to 0V, all other pins floating, using my uncalibrated Maplin's Meter (PG10B) ...

5V5 : 1726uA and 1737uA ( 11uA )
5V0 : 1719uA and 1729uA ( 10uA )
4V5 : 1550uA and 1559uA ( 9uA )
4V0 : 1335uA and 1343uA ( 8uA )
3V5 : 1125uA and 1132uA ( 7uA )
3V3 : 1042uA and 1049uA ( 7uA )
3V0 : 215uA

So change observable at and above 3V3 but nothing changing or stable below. The sudden drop in current is just about 3V3. That's presumably BOR kicking in ( voltage seems a bit high for that to happen ) or the on-chip core voltage generator behaving differently, though I don't think that's described in the data sheets, something else - Or it could just be my meter doesn't work well :)

Yes, for turning other on-chip devices off it's necessary to find the corresponding SFR address then POKESFR the enable/disable bits.

Added : Dragged a possibly better but equally uncalibrated meter out ( Philips PM2522A ) and ...

5V : 1723uA and 1734uA (11uA)
4V : 1336uA and 1345 (9uA)
3V : 222uA

Interesting that it's the same behaviour, near same difference in readings and no difference at 3V0, and pretty close matches all round.
 
Last edited:

Dippy

Moderator
Good stuff. That step change @3V3 is odd.
it would be interesting to duplicate exp. with Sleep.

Any idea what Rev-Ed sets as the BOR voltage fuse threshold?
 

premelec

Senior Member
I recall something about internal voltage running at 3v3 and there being a regulator that kicks in above that - if this is indeed the case it's likely the regulator circuitry that accounts for the abrupt shift.
 

Haku

Senior Member
Dippy, I'm using a Metrix MTX3283.

I tried hooking it up to a bench PSU with the same voltages as hippy with the same code/setup and saw similar results, but didn't jot any down because the overall values were drifting by a few uA over the period of a couple of minutes I was testing each voltage, as the logging graph showed.
Capacitance/resistance of the long-ish cables I'm guessing, but I rarely do stuff that needs such low power or voltage measuring so the long cables haven't been an issue.
 

BCJKiwi

Senior Member
So, going back to the original Q and Haku's following post;

Can I assume
1. DisableBOD makes little difference so not worth the extra commands
2. The references to DisableBOD apply equally to SLEEP and NAP in which case the manual should be updated.

Thanks
 

BCJKiwi

Senior Member
OK, Have run some tests on the circuit involved.

08M running on 2 AA batteries ~ 2.9V at time of tests
5Hr timer which flashes a 3mm led once per minute, and beeps a Piezo after 5Hrs
All mounted in a 3 AA battery box with switch with one battery removed and strip board circuit in place of the 3rd battery.

Measurements done with a regular digital multimeter - uncalibrated of course!

Using Pause as the timing mechanism, current draw in the pause stage was 430 uA, with the LED on 2.84mA, while driving the Piezo (a small one using pwmout) 3.2mA

Using Sleep, 43.5uA , Led and Piezo the same - obviously not in sleep at that time!

Using Sleep AND Dis & EnableBOD, 1.0uA draw in the sleep loop.

Also tied NAP but was not able to achieve usable results - in the circuit that is, not the measurement. The Program just did not seem to work using NAP - it either ran straight through the the Piezo phase, or, never got to the Piezo Phase (DisableBOD).

So now testing to verify the timing accuracy. This may be a problem as Sleep has a granularity of 2.3Secs compared to Pause at ms. May need to reduce the sleep count to the highest I can get below 1 Min and add a pause count to get a more accurate time.

So, IN THIS CIRCUIT, Sleep reduces current by a factor of 10 (430uA to 43uA), Sleep AND DisableBOD reduces current by a further factor of 43! for 43 to 1, or an over all reduction of from 430 to 1! - This all assume the MM can be believed. However I feel it is probably a reasonable guide as the current started high and slowly decreased then stablised as the internal averaging circuits of the MM stablised.

Code:
;5 Hour Timer - utilises disableBOD and Sleep.
#PICAXE 08M
Setfreq M4
Symbol SetMins   = w0 ;b0, b1
Symbol SetHours  = w1 ;b2, b3
Symbol MinCount  = b4 ;W2
Symbol HourCount = b5 ;W2
Symbol LoopCount = b13 ;W6
;Leg5 Out2 Output to Piezo via pwmout2
;Leg7 Out0  Output for LED
Symbol LED = 0
 
SetMins   = 0
SetHours  = 5
MinCount  = 0
Hourcount = 0
 
Minutes:
For LoopCount = 1 to 60 ;Count 60 mins to get Hours
 If HourCount = SetHours AND MinCount = SetMins Then
  GoSub Piezo
 EndIf
 High LED
 ;pause 250   ;Flash Led for 1/4 sec
 DisableBOD
 SLEEP 1
 EnableBOD
 Low  LED
 ;pause 59595  ;60000 = 1 min - allow for cycle time 
 DisableBOD
 SLEEP 24
 EnableBOD
 MinCount = MinCount + 1
Next
Hours:
HourCount = HourCount + 1
MinCount = 0
Goto Minutes
Piezo:
For LoopCount = 1 to 15
 pwmout pwmdiv4, 2, 124, 250 ;2000 Hz 50:50 on/off
 pause 2000
 pwmout 2, off
 pause 1000
next
 
End
 

Dippy

Moderator
Interesting stuff.

I think if anyone is really interested then they should really study the actual PIC Data Sheet.

The PIC has some 'core' bits'n'pieces surrounded by 'peripheral' bits'n'pieces.
To keep it simple check the Data Sheet of the 12F683.

So, for a simple drop of code to run we are looking at the core part and minimal peripherals.
(Assuming nothing of significance in the external circuit and conditions as specified in the Notes).

If we look at Section 15.2 "DC Charactersitics" we can see the consumptions we can expect at various frquencies with internal or external oscillator.
And also an idea of how consumption changes with supply voltage.
If we then look at the second part of Section 15.2 the consumption figures for the peripherals can be seen.
(Note: Data Sheet DS41211B; this is SECTION 15.2 and NOT Table 15.2 - trust M'chip to confuse us :) )

Other Data Sheets will usually show similar tables though fancier PICs will have fancier peripherals and power control.

I assume that Microchip will be using a good healthy expensive DMM to produce these figures ?
One aspect which is a mystery to me is whether a low-cost DMM will affect PIC performance.
Micros tend to take power as a combo of continuous power with some brief transient lumps.
And a cheap DMM , for uAmps, will shove in a relatively high value resistive shunt to determine voltage drop to measure current.
Will that voltage drop affect the PIC? Are some DMMs worse than others?
I really don't know, probably not, but it's worth a thought or two as opposed to guessing/hoping :).


You'll never get really accurate values in 'Sleep' as you're relying on the internal LF osc. as the clock.
As many will be aware, there is a 'native' command SLEEP which puts PIC to sleep forever but the WDT int is used to pop it out and check and continue to provide your BASIC 'Sleep' command. And you will also know that the WDT time is adjustable.

If you study the Data Sheets you will see how to check peripheral status and see how some/all can be switched on/off with a suitable POKE.
With careful use of this and adjusting clock speeds where necessary you should be able to produce a reliable device using minimal power.

Apologies for too many lines of drivel above.
 
Top