Exact match. Not showing close matches.
PICList
Thread
'[PIC]:What is the best way to end a program'
2002\02\07@155920
by
WEBB,TIM (A-Sonoma,ex1)
For development purposes, I have tried two different approaches to ending a
program
Run the program to "end" or create an endless loop like "stop goto
stop"
I have noticed that sometimes my 16F877 will just suddenly re-boot or reset
and re-run the program after it has
been sitting in either a endless loop or sent to end.
There are not any voltage spikes present on the circuit at the time of
reset.
Has anybody experienced this before?
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2002\02\07@161622
by
Andrew Warren
|
WEBB,TIM (A-Sonoma,ex1) <spam_OUTPICLISTTakeThisOuT
mitvma.mit.edu> wrote:
> For development purposes, I have tried two different approaches to
> ending a program
>
> Run the program to "end" or create an endless loop like "stop goto
> stop"
>
> I have noticed that sometimes my 16F877 will just suddenly re-boot or
> reset and re-run the program after it has been sitting in either a
> endless loop or sent to end.
Tim:
What, exactly, does "run the program to 'end'" mean?
If you're writing in assembly language, there's no such thing as an
"end" instruction; the "end" line in your source code is used only be
your assembler. Allowing your program to just run into it will cause
the symptom you're seeing, since the PIC will keep executing the code
in the "empty" code memory locations beyond the last location used by
your code, until its program counter wraps around to the reset vector
at 0000.
If you want to terminate your program with "stop: goto stop", you'll
need to ensure that the watchdog timer is disabled (or clear the
watchdog timer inside the loop). This code will work:
STOP:
CLRWDT
GOTO STOP
-Andy
=== Andrew Warren -- .....aiwKILLspam
@spam@cypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2002\02\07@162500
by
WEBB,TIM (A-Sonoma,ex1)
I have the watchdog timer set to OFF
And my program is terminated using the following:
stop goto stop
{Original Message removed}
2002\02\07@162909
by
Shawn Yates
I don't know why you would ever want the PIC to stop running, but you may
want to look into SLEEP mode.
Shawn
{Original Message removed}
2002\02\07@164235
by
Andrew Warren
WEBB,TIM (A-Sonoma,ex1) <PICLIST
KILLspammitvma.mit.edu> wrote:
> I have the watchdog timer set to OFF
>
> And my program is terminated using the following:
>
> stop goto stop
If your previous statements about the stability of MCLR and Vdd
are true, and PCLATH is set correctly for the "goto stop" (it
probably is, especially if you got to the "stop" label via a
goto in the first place), then the PIC will only execute code
outside the "stop" loop if an interrupt occurs.
Are interrupts disabled (or guaranteed to return)?
-Andy
=== Andrew Warren -- .....aiwKILLspam
.....cypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2002\02\07@164650
by
WEBB,TIM (A-Sonoma,ex1)
|
I am not using any interupts yet
-----Original Message-----
From: Andrew Warren [EraseMEaiwspam_OUT
TakeThisOuTCYPRESS.COM]
Sent: Thursday, February 07, 2002 1:42 PM
To: PICLIST
spam_OUTMITVMA.MIT.EDU
Subject: Re: [PIC]:What is the best way to end a program
WEBB,TIM (A-Sonoma,ex1) <@spam@PICLISTKILLspam
mitvma.mit.edu> wrote:
> I have the watchdog timer set to OFF
>
> And my program is terminated using the following:
>
> stop goto stop
If your previous statements about the stability of MCLR and Vdd
are true, and PCLATH is set correctly for the "goto stop" (it
probably is, especially if you got to the "stop" label via a
goto in the first place), then the PIC will only execute code
outside the "stop" loop if an interrupt occurs.
Are interrupts disabled (or guaranteed to return)?
-Andy
=== Andrew Warren -- KILLspamaiwKILLspam
cypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2002\02\07@174219
by
Tony Nixon
2002\02\07@193559
by
Andrew Warren
WEBB,TIM (A-Sonoma,ex1) <spamBeGonePICLISTspamBeGone
mitvma.mit.edu> wrote:
> > the PIC will only execute code outside the "stop" loop if an
> > interrupt occurs.
> >
> > Are interrupts disabled (or guaranteed to return)?
>
> I am not using any interupts yet
I believe you... But are interrupts disabled?
-Andy
=== Andrew Warren -- TakeThisOuTaiwEraseME
spam_OUTcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2002\02\07@195318
by
WEBB,TIM (A-Sonoma,ex1)
2002\02\07@201630
by
Andrew Warren
|
WEBB,TIM (A-Sonoma,ex1) <RemoveMEPICLISTspam_OUT
KILLspammitvma.mit.edu> wrote:
> How do you disable interupts?
Make your "stop" code look like this:
STOP:
CLRWDT
BCF INTCON,GIE
GOTO STOP
It's a good idea to keep the BCF inside the "stop" loop, as shown
above, to help avoid the race condition that occurs if an
interrupt is triggered while the BCF instruction is being
executed. To avoid that potential problem entirely, do the
above and also add the following code at the interrupt vector
(address 0x04):
ORG 0x04
RETURN
If this doesn't solve your problem, you may have to go back and
re-check your cornerstone assumptions (e.g., MCLR is high and
stable, Vdd is high and stable, the PIC is actually getting to
the "stop" code, etc.).
-Andy
=== Andrew Warren -- RemoveMEaiwTakeThisOuT
spamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics
2002\02\08@080513
by
Drew Vassallo
For endless loops at the end of a program, or if I want an "infinite" delay
during an interrupt-driven program, I use:
goto $
at the end of my functional program.
Note that you cannot use the assembler "END" statement as a program
terminator. It's only used for the assembler itself to let it know there
are no more instructions to process. If you do not REALLY terminate your
program prior to this (with a SLEEP, for example), or keep it looping, it
will act as a reset and start over at ORG 0x000.
--Andrew
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2002\02\08@102123
by
Peter L. Peres
If you want to stop the pic dead issue a sleep instruction as the last
instruction in the program, and maybe add a goto to this sleep instruction
after it (in case there is a pending interrupt you do not expect).
Peter
--
http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
2002\02\08@135045
by
gacrowell
About the only sure way I've found to end a program consists of the
following procedure:
1. Delete all files concerning it from your hard disk.
2. Use a program to wipe the disk to ensure they're gone.
3. Do the same with any floppies that ever may have held the code.
4. Shred all printed copies.
5. Burn the shredded paper.
6. Crush all devices into which the code may have been programmed.
7. Witness the crushed remains buried in landfill.
8. Change your name.
9. Move.
Anything less and it will surely find you again.
Gary Crowell
> {Original Message removed}
More... (looser matching)
- Last day of these posts
- In 2002
, 2003 only
- Today
- New search...