Searching \ for 'how to wake up a pic?' 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/microchip/devices.htm?key=pic
Search entire site for: 'how to wake up a pic?'.

Truncated match.
PICList Thread
'how to wake up a pic?'
1999\01\27@180233 by Alice Campbell

flavicon
face
hello all,
yes, im STILL trying to figure out watchdog timeouts and sleep.
can anyone tell me:
does _mclr and/or watchdog timeout clear the stack? they both seem to
return to the origin (reset pointer).
If a deliberate timeout loop triggers the dog,  how can i find out
whether a call to a timing loop has lost its return, and clear the
return if needed?

if the watchdog reset and mclr reset clear the stack, why does the
pic (16c84) lock up on the first subroutine it encounters?

and finally, why wont it wake up from sleep? i cant shout at it, the
rest of the family's asleep.

the timeout loop is to time the wdt period.  ive looked
at appnote tb004 but there seems to be a mistake in it.... they test
status for the sequence b'10100101',  but the wdt sequence is
b'10110101',  the one they use wont tell sleep from wdt.

and im nearly 46.  built timex z-80 from a kit.  also a ham (ka7dyq)
alice
alice

1999\01\27@183342 by Tony Nixon

flavicon
picon face
Alice Campbell wrote:

> does _mclr and/or watchdog timeout clear the stack? they both seem to
> return to the origin (reset pointer).

I'm not sure if the stack pointer is 'cleared' on any reset. It is just
a circular buffer and it is up to you to manage the pointer position.
ie, not too many returns from a subroutine etc. On powerup, it may be at
a random position, but I don't think it would change on a WDT reset.

> If a deliberate timeout loop triggers the dog,  how can i find out
> whether a call to a timing loop has lost its return, and clear the
> return if needed?

The PC will be at address 0000h after a WDT timeout. Test the status TO
bit for a '0' condition. If it is then try executing a return
instruction. You will need to write some code to let you know that the
correct code is executing. ie. turn a LED on after returning from your
timing loop.

> if the watchdog reset and mclr reset clear the stack, why does the
> pic (16c84) lock up on the first subroutine it encounters?

Maybe the stack isn't cleared. I have never had a PIC 'lock up' after
calling a 'first' subroutine. Maybe you are not coding correcly for the
type of reset you are using.

> and finally, why wont it wake up from sleep? i cant shout at it, the
> rest of the family's asleep.

Instead of using a crystal clock, use an alarm clock :-)

Sorry.  Perhaps it is waking up, but not responding to your code the way
you expect.

> status for the sequence b'10100101',  but the wdt sequence is
> b'10110101',  the one they use wont tell sleep from wdt.

The 'TO' bit in the status register will be set to '0' on a WDT wake up.
Test this bit.

org 0h

btfss status,TO
goto TimeOut

normal start up code


--
Best regards

Tony

Multimedia 16F84 Beginners PIC Tools.
** NEW PicNPro Programmer and Port Interface **

http://www.picnpoke.com
Email spam_OUTpicnpokeTakeThisOuTspamcdi.com.au

1999\01\27@185655 by Regulus Berdin

picon face
Hi,

There are two possibilities of watchdog timeout/wakeup (8.11).

1. The device was waken up from a SLEEP command.
2. The device was RESET due to a timeout occurring before a CLRWDT
command.

In case 1, if the device is waken up by the watchdog, the program
continues as if nothing happened (no stack reset). Take note also that
the next instruction after the SLEEP command will be considered as NOP
(8.12.3).

In case 2, the PIC treats it like an MCLR reset except for the STATUS
bits.  This will clear the stack and jumps to the RESET VECTOR.

regards,
Reggie


Alice Campbell wrote:
{Quote hidden}

1999\01\27@190933 by Alice Campbell

flavicon
face
thanks  Reggie,
>
> There are two possibilities of watchdog timeout/wakeup (8.11).
>
> 1. The device was waken up from a SLEEP command.
> 2. The device was RESET due to a timeout occurring before a CLRWDT
> command.
>
> In case 1, if the device is waken up by the watchdog, the program
> continues as if nothing happened (no stack reset). Take note also that
> the next instruction after the SLEEP command will be considered as NOP

> (8.12.3).<---i will reread this.

!!!!!!!!!!!!!!!!!!!!!  this alone explains a lot.

> In case 2, the PIC treats it like an MCLR reset except for the STATUS
> bits.  This will clear the stack and jumps to the RESET VECTOR.
>
tonight i will recheck the routine that looks at timeout and
powerdown bits.  the btfss things make me dizzy at night...

thanks,
alice

1999\01\27@192723 by Tony Nixon

flavicon
picon face
> Take note also that the next instruction after the SLEEP command will be consi
dered as NOP

This is not exactly true.

The next instruction following the SLEEP command is prefetched while the
SLEEP instruction is executing.

You may elect to have a NOP there if you don't want any other
instruction to execute.

If the GIE bit = 0, then normal code execution continues after the SLEEP
instruction.

If the GIE bit = 1, then the instruction following the SLEEP command is
executed, which may or may not be a NOP, then the PC is set to 0004h.

--
Best regards

Tony

Multimedia 16F84 Beginners PIC Tools.
** NEW PicNPro Programmer and Port Interface **

http://www.picnpoke.com
Email .....picnpokeKILLspamspam@spam@cdi.com.au

1999\01\27@202216 by Mike Keitz

picon face
On Thu, 28 Jan 1999 10:31:51 +1100 Tony Nixon
<Tony.NixonspamKILLspamENG.MONASH.EDU.AU> writes:

>I'm not sure if the stack pointer is 'cleared' on any reset. It is
>just
>a circular buffer and it is up to you to manage the pointer position.
>ie, not too many returns from a subroutine etc. On powerup, it may be
>at
>a random position, but I don't think it would change on a WDT reset.

There is no need to clear it.  I don't think the PIC logic ever clears
it.  It should hold the same data after a reset, but that is definitely
something you try only when you really *have* to.  There is certainly no
guarantee that anything in particular will remain in the stack after a
reset.


>Sorry.  Perhaps it is waking up, but not responding to your code the
>way
>you expect.

I would agree, perhaps Alice is misdiagnosing the problems.  Don't worry
about the stack, where ever you CALL, so the PIC will RETURN, up to 8
levels anyway.

If you're using an xtal oscillator instead of RC, try removing the
crystal circuit and supplying an external clock to X1.  If the PIC is
asleep, nothing should come out X2.  If awake (and/or held in MCLR
reset), the clock frequency will appear.  If everything seems to work
now, the oscillator may have been dodgy and not restarting after wakeup.

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1999\01\28@022929 by Dr. Imre Bartfai

flavicon
face
Hi,

I disagree. My experience shows, that !MCLR completely resets also the
stack pointer. I suspect WDT does also as if experienced some unintended
WDT reset then the program ran w/o any problem and it would not do it if
the stack would not be clear.

This is my 2cent.
Imre

On Thu, 28 Jan 1999, Tony Nixon wrote:

{Quote hidden}


'how to wake up a pic?'
1999\02\01@110958 by Alice Campbell
flavicon
face
Hello all,

> Alice Campbell wrote:
> >
> > hello all,
> > yes, im STILL trying to figure out watchdog timeouts and sleep.


> > can anyone tell me:
> > does _mclr and/or watchdog timeout clear the stack? they both seem to
> > return to the origin (reset pointer).

no, but it resets the tris and option registers to ones.


> > If a deliberate timeout loop triggers the dog,  how can i find out
> > whether a call to a timing loop has lost its return, and clear the
> > return if needed?
you cant unless you reinitialize the ports



> >
> > if the watchdog reset and mclr reset clear the stack, why does the
> > pic (16c84) lock up on the first subroutine it encounters?

because you didnt reinitialize theports


> >
> > and finally, why wont it wake up from sleep? i cant shout at it, the
> > rest of the family's asleep.

because you didint reinitialize the ports

> >
> >  the timeout loop is to time the wdt period.  ive looked
> > at appnote tb004 but there seems to be a mistake in it.... they test
> > status for the sequence b'10100101',  but the wdt sequence is
> > b'10110101',  the one they use wont tell sleep from wdt.

it is more subltle than even that.  if wdt is set on _mclr, then it
will think its powerup reset. you have to set a flag on powerup and
read that to distinguish a true powerup from a _mclr   or clrwdt
trigger.


> >
> > and im nearly 46.  built timex z-80 from a kit.  also a ham (ka7dyq)

and can hardly wait to finish the project that ate my brain and go
back to knitting.

>
alice, 46, ka7dyq aka 'mom' de los angeles
hydrogeology & hydrogeochemistry, groundwater modeling,
data analysis, knitting, spinning, homemade marmalade, chutney, beer, &
horehound cough-drops, plein-air paintings (any planet), woodcuts, new at microp
rocessors
'what century IS this, anyway?'

1999\02\04@202440 by Tony Nixon

flavicon
picon face
Alice Campbell wrote:

> no, but it resets the tris and option registers to ones.

This should not occur for a WDT or MCLR reset. The TRIS registers should
remain as they were. The OPTION register does change to all 1's though.

> it is more subltle than even that.  if wdt is set on _mclr, then it
> will think its powerup reset. you have to set a flag on powerup and
> read that to distinguish a true powerup from a _mclr   or clrwdt
> trigger.

If a MCLR reset occurs then the status bits TO and PD will not change.
If these bits were altered by some other event, eg. WDT timeout, then on
reset you may missinterpret these bits.

I don't know how you can distinguish a MCLR reset.

On a true power up, you cannot guarantee that the powerup flag is not
set by a random number appearing in RAM.

--
Best regards

Tony

Multimedia 16F84 Beginners PIC Tools.
** NEW PicNPro Programmer and Port Interface **

http://www.picnpoke.com
Email EraseMEpicnpokespam_OUTspamTakeThisOuTcdi.com.au

1999\02\04@215509 by paulb

flavicon
face
Tony Nixon wrote, quoting Alice Campbell:

>> no, but it resets the tris and option registers to ones.
> This should not occur for a WDT or MCLR reset. The TRIS registers
> should remain as they were.  The OPTION register does change to all
> 1's though.

 Eh?  Where do you make that out?  We are talking 16C84 (or close
enough) and table 4-1, page 13 of DS30081E gives a column for "Value on
all other resets (Note 3)" which Note 3 indicates includes ~MCLR and WDR
which is exactly the same for PCLATH, PCL, OPTION, TRIS as for POR.

 For the 12C5XX, same table, same page, document DS40139B.

 In fact, the only differences at all, are the ~TO, ~PD, and values
which are "Undefined" on power-up are merely "Unchanged" on other
resets.

> If a MCLR reset occurs then the status bits TO and PD will not change.
> If these bits were altered by some other event, eg. WDT timeout, then
> on reset you may missinterpret these bits.

> I don't know how you can distinguish a MCLR reset.

 It seems you can't unless you were asleep at the time.

 Am I right here?:

 ~TO ~PD
  1   1  Power up; or CLRWDT then MCLR
  1   0  Sleep was terminated by interrupt; MCLR then preceeded another
           CLRWDT (X84 only)
  0   1  Code was interrupted by WDT
  0   0  Sleep was interrupted by WDT
--
 Cheers,
       Paul B.

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