Searching \ for 'Example C code for using Sleep and WDT?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/language/index.htm?key=c
Search entire site for: 'Example C code for using Sleep and WDT?'.

Truncated match.
PICList Thread
'Example C code for using Sleep and WDT?'
1998\10\11@154144 by Paul Gaastra

flavicon
face
I'm still stuck on the problem with my 16C63 resetting itself after
waking up from sleep.  I know it's the watch dog timer resetting it
but why doesn't it carry on with the code from where it left off?

Can anyone point to some sample code on how one runs a PIC
asleep most of the time and wakes up on a Port B change?

What I don't like is the way I have to put some inline assembler in
my C code so that the instruction after the Sleep command is not
corrupted. In other words I do it like this

        sleep();
        #asm
          NOP
        #endasm

Is that what other people do?


Paul Gaastra                              spam_OUTpgaastraTakeThisOuTspamhort.cri.nz
Technology Development Group, Hort Research
Private Bag 3123            phone +64 7 8584745
Hamilton, NEW ZEALAND         fax +64 7 8584705

1998\10\11@201142 by James Cameron

flavicon
face
Paul Gaastra wrote:
> I'm still stuck on the problem with my 16C63 resetting itself after
> waking up from sleep.  I know it's the watch dog timer resetting it
> but why doesn't it carry on with the code from where it left off?

I learned something about this yesterday ... some PICs behave
differently with respect to WDT wake from SLEEP.  On the 16F84 the code
continues on the line afterwards.  On the 12C509, and presumably others,
execution begins at the reset vector.

At least it sets STATUS flags accordingly.  It was all in the data
sheets.

Why don't you save the STATUS flags on your reset vector and have a look
at them?  Ah, you might already be doing this.

C code on a PIC?  Wow.  Where can I get a free compiler?

--
James Cameron                                    (.....cameronKILLspamspam@spam@stl.dec.com)
Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800

1998\10\12@152814 by Paul Gaastra

flavicon
face
>
> Paul Gaastra wrote:
> > I'm still stuck on the problem with my 16C63 resetting itself after
> > waking up from sleep.  I know it's the watch dog timer resetting it
> > but why doesn't it carry on with the code from where it left off?
>

James Wrote:
> I learned something about this yesterday ... some PICs behave
> differently with respect to WDT wake from SLEEP.  On the 16F84 the code
> continues on the line afterwards.  On the 12C509, and presumably others,
> execution begins at the reset vector.

To quote from the data sheet for the 16C63  :  "During normal
operation, a WDT time-out generates a device reset.  If the device
is in SLEEP mode, a WDT time-our cause the device to wake-up
and continue with normal operation (WDT Wake-up)"

I use these facts in my code.  In the code after a wake up from
sleep I test the restart cause and if it was only the watch dog timer
waking it up I tell it to go back to sleep.

My problem is that on my EPROM PIC16C63, after the first time it
goes to sleep after power on, when the thing is woken up by an
RB0  or RB port change it just hangs for the duration of the WDT
timeout and does the WDT reset INSTEAD of carrying on with
normal operation.  After doing that once it behaves correctly.  That
is the next time it goes to sleep and is woken, it carries on with the
code as it's supposed to instead of doing a WDT reset.

Anybody else got any ideas.  I think it's some kind of silicon
problem.  I mean a Power on reset should be the same as a Watch
Dog reset as far as my program is concerned since I don't do
anything with the STATUS flags.

>
> At least it sets STATUS flags accordingly.  It was all in the data
> sheets.
>
> Why don't you save the STATUS flags on your reset vector and have a look
> at them?  Ah, you might already be doing this.

I don't recall seeing a reset vector anywhere.

> C code on a PIC?  Wow.  Where can I get a free compiler?

I've seen some around I think but we're using the $US99 PIC C
compiler by CCS.
{Quote hidden}

Paul Gaastra                              .....pgaastraKILLspamspam.....hort.cri.nz
Technology Development Group, Hort Research
Private Bag 3123            phone +64 7 8584745
Hamilton, NEW ZEALAND         fax +64 7 8584705

1998\10\12@211104 by James Cameron

flavicon
face
Paul Gaastra wrote:
> James Wrote:
> > Why don't you save the STATUS flags on your reset vector and have a
> > look at them?  [...]
>
> I don't recall seeing a reset vector anywhere.

If the device can reset, it has a reset vector.  At 0x0000?  ;-)

But yes, I agree, the symptom you express doesn't seem right.  Check
that the data sheet doesn't show certain bits being set or reset in
registers as a result of wake from sleep?

Think I'll take a look at the data sheet.  Ahh, here we go.

Okay, a series of questions ...
       a) do you have the interrupt enable set for port b change?
       b) do you have GIE enabled?
       c) do you have code at 0x0004 to handle an interrupt, and is
       it being executed?
       d) does your oscillator restart properly?

Table 18-11 on the data sheet (page 131) describes the changes to
registers as a result of an interrupt wake from sleep.  Nothing obvious
there, but the status register does show bits that you can test to
determine the cause of a reset or wake.  Check PCON as well, in case you
have some pathological condition like a short to the supply that happens
to trigger the brown-out reset.

It only happens the first time.  Hmm.  Got another chip to try?

No other ideas, sorry.

--
James Cameron                                    (EraseMEcameronspam_OUTspamTakeThisOuTstl.dec.com)
Digital Equipment Corporation (Australia) Pty. Ltd. A.C.N. 000 446 800

1998\10\13@162225 by Paul Gaastra

flavicon
face
------------------------------
This is the problem with the uP that doesn't continue after wake up
from sleep after the power is first applied but works perfectly on
subseqent sleep/wakeups.

Can anyone who uses the CCS compiler who puts their uP to
sleep and wakes it using RB change email me an example of their
code?  Just the relevant lines?

Anyway to answer those questions James.
>
> Paul Gaastra wrote:
> > James Wrote:
> > > Why don't you save the STATUS flags on your reset vector and have a
> > > look at them?  [...]
> >
> > I don't recall seeing a reset vector anywhere.
>
> If the device can reset, it has a reset vector.  At 0x0000?  ;-)
OK   I see what you mean, I just call that the start of the code.

>
> But yes, I agree, the symptom you express doesn't seem right.  Check
> that the data sheet doesn't show certain bits being set or reset in
> registers as a result of wake from sleep?
I've read the relevant sections through and through.

>
> Think I'll take a look at the data sheet.  Ahh, here we go.
>
> Okay, a series of questions ...
>         a) do you have the interrupt enable set for port b change?
Yes that's what I'm using to wake up the uP.

>         b) do you have GIE enabled?
Yes but interrupts shouldn't have anything to do with it because
they should just complete and return.  However that's the only place
I can see where code could be executed for 2.4 seconds (the
duration of the watch dog timer) without issuing a restart watchdog.

>         c) do you have code at 0x0004 to handle an interrupt, and is
>         it being executed?
Yes, the PIC C compiler takes care of that.

>         d) does your oscillator restart properly?
Yes
>
> Table 18-11 on the data sheet (page 131) describes the changes to
> registers as a result of an interrupt wake from sleep.  Nothing obvious
> there, but the status register does show bits that you can test to
> determine the cause of a reset or wake.  Check PCON as well, in case you
> have some pathological condition like a short to the supply that happens
> to trigger the brown-out reset.
I had a look at the supply and there's no glitches.  Yes I'll have to
print out the contents of the registers on power up and the second
time it goes through after the WDT reset and see if anything helps
there.

>
> It only happens the first time.  Hmm.  Got another chip to try?

Tried it with a couple of other chips and it does the same thing.




Paul Gaastra                              pgaastraspamspam_OUThort.cri.nz
Technology Development Group, Hort Research
Private Bag 3123            phone +64 7 8584745
Hamilton, NEW ZEALAND         fax +64 7 8584705

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...