General Approach to Reducing Duty Cycle...

[jecottrell]

18F2525 @ 40MHz
3.236


Hello All,

I've ready many of the 'oscillator switching' threads and have tried to digest the datasheet....

I'm getting ready to attempt Oscillator switching and sleep or idle modes to reduce duty time. I have several questions I can't seem to find definitive answers on in the datasheet (I'm sure they're there, but I don't understand what's being said.)

General plan of attack for reducing duty cycle and power is...

Shut down all peripherals.
Switch from external 10MHz osc w/ PLL to internal RC @ 31khz.
Go to the lowest power mode possible that can be awoken by an internal interrupt (WDT, timer, counter....).
Wait for a fixed period of time (55 seconds for now).
Awake.
Switch to external oscillator @ 10MHz and PLL
Turn peripherals back on.

Questions:
What timer should I use to wake my processor? WDT or one of the system timers?
Which is the best Timer or scheme to do what I'd like?

Any information, wisdom, links to threads that may help would be greatly appreciated.

Thanks,

John

[PCM programmer]

AN606:
http://ww1.microchip.com/downloads/en/AppNotes/00606B.PDF

[jecottrell]

PCM,

Thanks for the link. I had seen that in days past (...ok, a long time ago.) It cleared things up a little but I think I may have confused the issue by saying 'internal RC' oscillator. Looking at the datasheet, I really mean my low power osc source will be INTIO2 and most of the appnote is concerning an external RC, no?

Am I interpreting the datasheet correctly in saying that the only internal event (WDT, Timer, or Counter) that can wake the part from sleep is the WDT?

...wait, I think I just caught something I missed before. Datasheet says Timer1 can be used. But that doesn't jibe with 'When a wake event occurs in Sleep mode (by interrupt, Reset or WDT time-out),....' later in the datasheet.

Reading further, (about the WDT), I see some more that I missed. The WDT uses the internal oscillator. So I don't necessarily have to explicitly swap to the internal oscillator prior to sleep. All I really need to do is enable the WDT with the settings I'd like prior to sleeping?

I'll have to search for info on the state of the processor when it is awoken from a WDT event.

Thanks again,

John

EDIT:

Can you preload the WDT to get a roughly accurate wake up?

[PCM programmer]

[Ttelmah]

The WDT, has it's _own_ oscillator.
No, you cannot 'preload' it, and it's timings are poor.
The point about "interrupt, Reset or WDT time-out", are these are the events that can wake the chip _when it's oscillator is not running_. You can wake the chip from any other interrupt source, _provided you leave the oscillator running, even at slow speed_.
So for an accurate timing, using a timer is better, but the chip will draw more power with the oscillator running, than without.

Best Wishes

[PCM programmer]

[jecottrell]

PCM & RJ,

Thanks. It's slowly getting clearer.

Am I correct in saying that the INTRC is 31kHz and any changes to clock speed when using the INTRC are through a divider/multiplier. So, changes in the INTRC clock setting don't change the period of the WDT. The only alteration I can make to the period of the WDT is to work with the post-scaler? (...and more for educational purposes, if an external clock source is used, does the WDT still use the INTRC?... i.e. SLEEP: WDT-->INTRC and RUN: WDT-->Current Clock?)

EDIT:

It also sounds like the hassles of dealing with waking from a WDT may be more than I'm willing to deal with at this point. I guess I'd have to save all the current variables, etc., to EEPROM prior to SLEEP and restore them upon waking? Or is there another approved solution?

John

[Ttelmah]

Lesson, always check the structure of the particular chip before posting.

The oscillator structure here is fairly complex. At heart, there is a RC oscillator, which then _feeds_ a variety of other objects. This 'core' oscillator, will need to run when the WDT is enabled, but the dividers from it, to feed the actual processor 'core' are disabled. Hence the WDT itself draws a little power, but less than if the processor is running.
Now this has implications for everything. The first is that the WDT on these chips, should be pretty accurate. A big improvement.
Now, the WDT, is still not accessible to change the current count, but this is not needed. Remember that it costs almost nothing to wake up, inrement/decrement a counter, and if it has not reached a target, go to sleep again. You talk about using a 40MHz clock. Is this the on-chip crystal oscillator, with PLL, or an external clock source?. The reason for this 'mattering', is that if it is the on chip oscillator, then it takes a long time to 'wake up', and therefore a reasonable amount of power. I'd suggest:
In the fuses, configure the watchdog postscale, to 256, and disable the watchdog (this leaves it under software control). The interval will be nominally 256/250 seconds.
Switch to internal oscillator, if the clock is a crystal.
Set a counter to 53
Enable the watchdog

Then simply sleep, decrement the counter, and if is not zero, loop back to sleep.

Set the oscillator back to 40MHz

This will give a total delay of 256/250*53, plus about 120 instructions at 30KHz, giving about 54.5 seconds.

Best Wishes

[jecottrell]

Thanks.

That makes perfect sense now. The timing isn't critical at this point. I'm turning the processor on to open a 'receive' window for some radio comms. I'll start with a pretty wide opening (5 seconds and try narrowing as much as possible later).

The last area I'm unsure of is the state of the processor when waking after WDT timeout. Threads here seem to indicate no extra effort is required. Registers are intact, variables are still valid, etc. But some info in the datasheet seems to indicate some registers are in an indeterminate state?

[jaymiller]

If the reason to reduce the duty cycle is to extend battery life, perhaps you could see about using more powerful batteries.Today's batteries have far more amphours for the size than 20 years ago when I buil remote comm.equip that drew 5mA during 'sleepmode'.Used Gates 5.2Ah batteries then,huge compared to today's offerings.
Just trying to put another perspective on this project.Sometimes bigger is better!

Jay
PCM V2.681
hey,it still works for me !

[Ttelmah]

The comment about checking the data sheet, was for me.
Everything that matters should be retained after sleep. There are some little 'caveats'. One is that the next instruction is 'prefetched' when the processor goes to sleep. This can give the wrong results from things like tests, or if an interrupt is called (it won't actually get called till the next instruction on waking). This is why adding a 'delay_cycles(1)' (a NOP), after the sleep instruction, can be worthwhile.

Best Wishes

[Mark]

[jecottrell]

Jay,

Thanks for the thoughts. I'm starting with 6 F (3/2 D cell) NiCads @ 7Ah. My first test was spectacular failure. 2 Hours 4x4 drive in, 2 more out and a low battery message 3 hours after installation! (Big shame on me for some really lousy/non-existant testing prior to op-test/deployment. I had a small solar panel attached that I thought would save my bacon... but it didn't. Learn the hard way once and never forget!) I think a combination of a poor charge/conditioning on the batteries or damaged batteries from the folks that soldered up the pack was the problem... I'm still trying to figure that one out. I think eventually I'll be able to go down to 6 D NiCads maybe even C's.

RJ,

That sounds great, I'll throw in a NOP for good measure.

Thanks again to all,

John

[Ttelmah]