sleep mode, current draw running internal RC osc.
dkemppai
Posts: 315
Ok,
I'm having trouble finding some information here. It appears that all pins set as outputs
are pulled low when the SX is put into sleep mode? This appears to happen even if the
output is set high.·For some reason, I'm having·information on this subject.
Also, what are the typical currrents when the SX is running on internal RC,
in sleep mode. I'm trying to measure this, but am not sure if it is correct.
At 4Mhz, I'm getting around 15uA when the osc is supplied from an external
clock. It appears that the current is around 7.7mA when running the internal
RC oscillator.
I'm running the thing·on a 5 volt supply.
-Dan
·
I'm having trouble finding some information here. It appears that all pins set as outputs
are pulled low when the SX is put into sleep mode? This appears to happen even if the
output is set high.·For some reason, I'm having·information on this subject.
Also, what are the typical currrents when the SX is running on internal RC,
in sleep mode. I'm trying to measure this, but am not sure if it is correct.
At 4Mhz, I'm getting around 15uA when the osc is supplied from an external
clock. It appears that the current is around 7.7mA when running the internal
RC oscillator.
I'm running the thing·on a 5 volt supply.
-Dan
·
Comments
Let's make this a little easier question.
Looking at the SX datasheet (page 21, march 2002) figure 9.1, the
documentation shows that sleep mode shuts down the feedback
to any external resonator/crystal. This in turn, should shut down
they crystal, and reduce current draw.
In sleep mode, the current draw due to the crystal/resonator
should be zero, leaving only the current draw from the WDT.
This should be the same as when an external clock is used
to supply the system clock.
The problem is that the system operates as expected with the
external clock, i.e. the current falls to near 15uA. With the ceramic
resonator attached, the current falls 6.8mA (or 450 times more
current) IN both cases, the current should be the same.
I'm confused, what am I missing here.
-Dan
Also, I cannot seem to figure out where in the documentation
it states what happens to the outputs when in sleep mode...
...any ideas?
·
To have the SX draw minimal current when in sleep mode, all I/O pins must be either configured as outputs, or tied high or low with a resistor (internal pull-ups work).
Nate
As for outputs going low on sleep, they should remain unchanged.· Suggest you step through debug and look closely.
Bongo
I did recall this being·an issue before. It did·seemed to help (all outputs, as opposed to inputs). I was around 150uA, and then·tried running it on a different protoboard, and that seemd to help. It's down to around 70uA at 3.3Volts.·(With the watchdog running).
This gets me into a more reasonable level of current. It's still not 10uA, but getting closer.
Bongo,
When debugging the code my outputs work as expected. But, when I turn on the watchdog option (running), they don't act as I expect they should.·Basically, all I do is toggle the output pin, and put the device to 'sleep' again...·· ...this should be a 50% duty cycle, but it's not.
I'm probably doing something goofy...·· ...I just can't put my finger on it...· ...yet...
-Dan
·
The outpus are maintained on sleep mode.
According to the ubixom SX reset app note (app note 18) the direction registers, and output registers are lost
on reset. So, what this means is that outputs, though maintained on sleep, will become inputs upon wakeup.
However, that appnote also states that the port data registers are maintained, however, they are read from voltage present on the pins, during the change of the direction registers.
Translation, the SX doesn't reset the data registers directly, but via the direction register they become undefined.
That Ubicom App note should be updated to include this information... ...or am I completely wrong on this issue...
-Dan
So I did the test. I would not trust my multimeter for an absolute value, but as a comparative indicator the results should be informative.
Where:
No external loads
Wake up enable is off
Sleep clock is off
Watchdog is off
Internal 4mhz running measured 7.6mA
Internal 4mhz sleeping measured 3.3mA
External 10mhz running measured 21mA
External 10mhz sleeping measured 2.3mA
If wake up enable is on, then you may not allow inputs to float, as they will keep waking the device. The internal pull-ups are very useful in holding disused inputs high. Anyhow, floating inputs can be very distracting during debug.
If the watchdog is on, it will wake the device on rollover.
The sleepclock is a new one to me, but as I don’t think I need a sleepclock whatever it is, I will probably forget that it is there.
Apart from that, I think you may be onto something there.............
Hope this is of some help.
bongo
Are all of your pins set to outputs or pullups??? (As per
Nate's suggestion)
I've got one running on the bench right now·at 3.3Volts.
In·sleep mode, with a 4Mhz external osc, the current draw
drops to 10uA. It wakes up long enough to toggle an output,
and go back to sleep again (10uA).
The weird thing is that it occasionally rises to 200uA to 300uA.
It stopped doing that after I cranked the voltage up to 5, and
back down to 3.3...··· ...this is just too weird for me.
The only thing I can think of is the high frequency current drawn
from the IC, is zero beating with the sample period of the Fluke 189
I'm using for the current measurement...·· ...or something like that...
...weird...
-Dan
·
Well, there is a few issues. I guess the first thing is that your original post made no mention of waking the device, so I had thought your question was around sleep only, with the running part of your project a calculatable current.
So I suggest that you check in a terminal sleep, as in :
clr ra
clr rb
clr rc
sleep
This way you know that all you are measuring is the sleep current, provided the device is set up as I have outlined. I would suspect that the fluctuating currents that you see are a result of something waking the device.
From my (questionable) memory, the sx draws less current at 3.3 volts than 5 volts.
As stated, I would not place too much on the absolute figures returned by my highly abused chinese mutimeter.
As you are undoubtably aware, measureing small currents is usually done across a shunt of some measurable resistance. 400 ohms being common. Personally I have never had a problem getting an SX running, but there are recomended maximum voltage rise times. So I guess in order of completeness, you need to establish (prove) that the Fluke's shunt is not interfering with the SX's start up.
For minimum current draw in sleep, the manuals recommend switching off the watchdog and comparitor. I did not have the disused inputs (all io) tied to a rail, or pullups enabled. Can't see it would make any difference if the device is asleep, there is no external load hooked up and wake up enable is off. But, I did not do the experement, and now I have put all my stuff back together. Meaning am not going to either, sorry.
I usually find these types of things end up being simple rather than complex. For example, have you tried running a small current through a resistor to prove the multimeter?
bongo
A quick point that has come up before in this forum regarding power draw during sleep etc.
If the pins of the SX are left to float, as in, not connected to a pull up, pull down or hard logic high or low, or are not outputs, the chip can draw lots o' current.·
This is due to the chip being CMOS, which means the logic gates, and specifically the input logic,·are made with a totem pole of two CMOS transistors stacked across the power supply.·
If the voltage on the inputs floats up, due to static electricity, the breeze, or whatever, both transistors can turn on partially when the input voltage is around the mid point of the supply. You normally don't see this because most input signals move pretty fast through that voltage on their way high or low.· But it does cause a current spike.· The longer a voltage lingers around half the supply voltage, the longer the duration of the higher current draw.
So you really need to do your test with all the pins of the chip either pulled high or low via resistors, or the internal 'weak' pullups, or have them set as outputs so the state is defined...
That's all.· I didn't go looking for the post, but I think the current swung over a pretty large range due to the floating inputs.
Mike C.
·
I have all of the pins defined as outputs, with nothing attached, and was still seeing
higher than expected currrent draws.
My origional question was really about·what happens to the outputs, upon reset.·It took·a little while to figure out that during a reset, ALL PINS are set as input. This causes the RA/RB/RC registers to record what ever they·happen to be floating at, and upon turning them to input·The pre-sleep states are potentially lost. That was a real head scratcher.
-Dan
·
I believe that after reset, only the direction registers of the ports are altered to contain 1's, making them all inputs. The port values are not read of course until a MOV W,PORT instruction is executed.
In restoring the port direction registers to their intended input/output states will also resore the output to the values prior to reset. That is to say, the content of the ports outputs are not affected by the reset.
On initial power up of course this is not the case.
Hope this explanation helps some.
Peter (pjv)
outputs to resume their current state is by storing the values to a shadow register, and setting them back again after waking up and changing dirs back to outputs.
Here's the code I'm running...·· ...and the output never goes high, unless the shadow register is used. (if shadow register is the right term...)
Anyway, by commenting out the first line of Main (MOV ·RB, SHADOW),
the output goes high on the first cycle, then never again.
I'm probably doing something dumb...·
-Dan
··NOCASE···;No Case Sensitive ASM
··DEVICE·SX28L··;28 pin chip
··DEVICE· OSCXT1
··DEVICE·BOR22··;Brownout at 2.2Volts
··IRC_CAL IRC_FAST·;(Faster programming)
··DEVICE·STACKX··;Use the Extended Stack.
··DEVICE· IFBD··;Disable Internal Feedback.
··DEVICE· TURBO··;Turbo Mode
··DEVICE·WATCHDOG·;Enable Watchdog timer.
··FREQ 4_000_000 ········ ;START WITH A XXMHz Clock
RESET Main
org $08
counter·DS ·3
SHADOW·DS·1
Main
··MOV ·RB, SHADOW
··MODE·$0F···;Mode for Direction Registers
··MOV ·!RA, #%0000··;0 = output, 1 = input
··MOV ·!RC, #%00000000
··MOV ·!RB, #%00000000
··MOV ·!option, #%11111111
··;Chec to see if Start is from WatchDog timeout.
··MOV·W,status
··AND·W,#%00011000 ·;Bits TO = 0 and PD = 0 on WDT reset.
··JZ·WDTStart··;Skip code on WatchDog Reset
··;Place code to be skipped on WDT reset here...
WDTStart·JB ·RB.0 ,:clrbit
··SETB ·rb.0
··jmp·:bitdne
:clrbit
··clrb ·rb.0
··nop
:bitdne
··CLR ·!WDT
··MOV·SHADOW, RB
··SLEEP
bongo
Actually, the prescaler is set as a post scaler to·the watchdog, providing about a 2 second delay between
waking states...
Dan