Searching \ for '[PIC]: software reset' 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: 'software reset'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: software reset'
2001\06\22@115355 by Mike Mansheim

flavicon
face
> One question only.
> Why do you need the software interrupt?
> I can't see a task, in which it's necessary.

Assuming the question is actually asking why a software "reset" might
be useful (I don't think "interrupt" was the intent):
My programs all end up divided into an init section, which is executed
once at boot, and the main running section, which is an endless loop, or
set of state machines, or whatever.
I have an application that reads several "calibration constants" from
eeprom as part of the init.  One of the things that can be done from
the main running section is a user can adjust some of these constants.
To have the changes take effect, it seemed cleaner in this case to
reset the processor, and have the init section execute again and read
the new values.
I used the watchdog to accomplish this, and it worked quite well.  If
you speed up the time-out, the re-boot can appear instantaneous.  I
also took advantage of the POR status bit to distinguish between a
watchdog reset and the initial power-up.

--
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


2001\06\22@133949 by Byron A Jeff

face picon face
On Fri, Jun 22, 2001 at 10:51:28AM -0500, Mike Mansheim wrote:
> > One question only.
> > Why do you need the software interrupt?
> > I can't see a task, in which it's necessary.
>
> Assuming the question is actually asking why a software "reset" might
> be useful (I don't think "interrupt" was the intent):
> My programs all end up divided into an init section, which is executed
> once at boot, and the main running section, which is an endless loop, or
> set of state machines, or whatever.
> I have an application that reads several "calibration constants" from
> eeprom as part of the init.  One of the things that can be done from
> the main running section is a user can adjust some of these constants.
> To have the changes take effect, it seemed cleaner in this case to
> reset the processor, and have the init section execute again and read
> the new values.
> I used the watchdog to accomplish this, and it worked quite well.  If
> you speed up the time-out, the re-boot can appear instantaneous.  I
> also took advantage of the POR status bit to distinguish between a
> watchdog reset and the initial power-up.

But of course this beg the obvious question: Why not simply jump to to the
reset vector? Any robust code will actually set any register values the
applications needs instead of depending on the reset to do so?

The question on the table is what benefit does a full reset give over a
simple jump to the initialization code?

BAJ

--
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


2001\06\22@144650 by Olin Lathrop

face picon face
> My programs all end up divided into an init section, which is executed
> once at boot, and the main running section, which is an endless loop, or
> set of state machines, or whatever.
> I have an application that reads several "calibration constants" from
> eeprom as part of the init.  One of the things that can be done from
> the main running section is a user can adjust some of these constants.
> To have the changes take effect, it seemed cleaner in this case to
> reset the processor, and have the init section execute again and read
> the new values.
> I used the watchdog to accomplish this, and it worked quite well.  If
> you speed up the time-out, the re-boot can appear instantaneous.

Why not just

   clrf  pclath
   goto  0

This will essentially BE instantaneous.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, spam_OUTolinTakeThisOuTspamembedinc.com, http://www.embedinc.com

--
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


2001\06\22@154055 by Walter Banks

picon face
Byron A Jeff wrote:
>
> On Fri, Jun 22, 2001 at 10:51:28AM -0500, Mike Mansheim wrote:
> > I used the watchdog to accomplish this, and it worked quite well.  If
> > you speed up the time-out, the re-boot can appear instantaneous.  I
> > also took advantage of the POR status bit to distinguish between a
> > watchdog reset and the initial power-up.

> The question on the table is what benefit does a full reset give over a
> simple jump to the initialization code?

The advantages to a full reset is the processor internal registers in
exactly the same way each time. Jumping to the reset code requires the
application developer duplicate what the processor is doing internally.
This may not always be possible.

My vote is the watchdog

w..

--
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


2001\06\22@232154 by M. Adam Davis

flavicon
face
Actually, the majority of the registers are left untouched during a
watchdog.  The dog is meant to be a "Your program messed up, here's the
last state it was in", and leaves everything substantially similar so
your program can have a clue about what went wrong.

A robust program always resets or clears every register it uses upon
initialization, anyway, so it's a moot point.  The end justifies the
means.  Assuming, however, that the watchdog will leave you in a
specific state, however, is just as bad as assuming the processor will
start up in a specific state under other circumstances.

-Adam

Walter Banks wrote:

{Quote hidden}

--
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


2001\06\23@064519 by Bob Ammerman

picon face
----- Original Message -----
From: "M. Adam Davis" <.....adampicKILLspamspam@spam@UBASICS.COM>

<snip>
> A robust program always resets or clears every register it uses upon
> initialization, anyway, so it's a moot point.
<snip>

This has been stated before on Piclist, but I am not so sure it is true. If
you cannot trust the chip to initialize itself the way it is supposed to why
should trust it to, say, get 4 when adding 2+2.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\06\23@101643 by Olin Lathrop

face picon face
> > A robust program always resets or clears every register it uses upon
> > initialization, anyway, so it's a moot point.
>
> This has been stated before on Piclist, but I am not so sure it is true.
If
> you cannot trust the chip to initialize itself the way it is supposed to
why
> should trust it to, say, get 4 when adding 2+2.

I don't see the point to resetting or clearing every register either, but I
do initialize all special function registers for modules that I use.  In
other words, my code at 0 assumes the machine is in an unknown state.  The
advantages I see for this are:

1  -  The initialization routines document what hardware is used and how it
is set up.

2  -  Some bits really are undefined, even on a power up reset.  These bits,
plus the ones that I want different from the default would have to be set at
a minimum.  Setting all remaining control bits for the modules used takes
little, if any, additional instructions.

3  -  Microchip has never promised that the wake up state will be the same
on future machines.  Assuming everything wakes up unknown doesn't guarantee
portability to different or future PICs, but it does make it more likely.

4  -  There are various reasons why execution could end up at 0, like power
up, MCLR reset, brown out reset, watchdog reset, accidental GOTO 0, or
deliberate GOTO 0.  These have different guarantees (or not) about the state
of the machine.  I like to have my code do a complete clean "reboot" when
execution gets to 0 regardless of the reason.  I don't use deliberate GOTO 0
much, but one example is when an unexpected interrupt occurs.  That can only
happen do to a firmware bug which somehow enabled an interrupt condition
that it wasn't supposed to.  There is no good answer at this point.
Resetting everything, including the interrupt system, is probably the least
of the evils.

I've also used a deliberate GOTO 0 after configuration changes were made by
the user and stored in EEPROM.  It was simpler to restart the system which
then had to configure to the EEPROM setting anyway than to change
configuration on the fly.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinspamKILLspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\06\23@104139 by Dan Michaels

flavicon
face
Olin.L wrote:

 I don't use deliberate GOTO 0
>much, but one example is when an unexpected interrupt occurs.  That can only
>happen do to a firmware bug which somehow enabled an interrupt condition
>that it wasn't supposed to.  There is no good answer at this point.
>Resetting everything, including the interrupt system, is probably the least
>of the evils.
>


GOTO 0 [or somewhere near 0] is also a good way to break out
of an infinite loop [planned or accidental] in your firmware,
provided you have interrupts available. Send an escape character
[not necessarily 1Bh] to the unit, and you are back to full ops.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\06\25@040602 by Vasile Surducan

flavicon
face
On Fri, 22 Jun 2001, Mike Mansheim wrote:

> > One question only.
> > Why do you need the software interrupt?
> > I can't see a task, in which it's necessary.
>
> Assuming the question is actually asking why a software "reset" might
> be useful (I don't think "interrupt" was the intent):
> My programs all end up divided into an init section, which is executed
> once at boot, and the main running section, which is an endless loop, or
> set of state machines, or whatever.
> I have an application that reads several "calibration constants" from
> eeprom as part of the init.  One of the things that can be done from
> the main running section is a user can adjust some of these constants.
> To have the changes take effect, it seemed cleaner in this case to
> reset the processor, and have the init section execute again and read
> the new values.
> I used the watchdog to accomplish this, and it worked quite well.  If
> you speed up the time-out, the re-boot can appear instantaneous.  I
> also took advantage of the POR status bit to distinguish between a
> watchdog reset and the initial power-up.

This is exactly what I indend to do ! Till now I never use the watchdog, I
know the prescaler could be assigned to watchdog, if the init section of
the program takes more than watchdog period. But after the init sequence,
I've guess is possible to switch off the watchdog isn't it ? ( must be ! )
Thanks, Vasile

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu


2001\06\25@070954 by Alan B. Pearce

face picon face
> > A robust program always resets or clears every register it uses upon
> > initialization, anyway, so it's a moot point.
>
> This has been stated before on Piclist, but I am not so sure it is true.
>If you cannot trust the chip to initialize itself the way it is supposed
>to why should trust it to, say, get 4 when adding 2+2.

Should you not be treating this as a  case of the chip initialising to a
safe state on reset? I would hate to think what sort of external circuitry
would need to be fitted to make sure that some motor driver was not turned
on while the PIC did its internal reset code, and then enabled the driver if
the PIC was not set to a known state on power up, and then the protection
for the enable circuit to ensure that it was not accidentally fired off by
another init state.....

big problems have little problems upon their backs to try us
and little problems have littler problems
and so ad infinitus

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


2001\06\25@082731 by Mark Newland

flavicon
face
Once you turn on a watchdog, it is always on!

Vasile Surducan wrote:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\06\25@091003 by Bob Ammerman

picon face
> > This is exactly what I indend to do ! Till now I never use the watchdog,
I
> > know the prescaler could be assigned to watchdog, if the init section of
> > the program takes more than watchdog period. But after the init
sequence,
> > I've guess is possible to switch off the watchdog isn't it ? ( must be
! )
> > Thanks, Vasile

Nope, once the watchdog is turned on (in the CONFIG setting, btw). It
_cannot_ be turned off in software, although its period can be changed via
prescaler setting. This is deliberate so that errorneous code can't turn off
the watchdog.

I believe some of the future PICS (dsPIC?) are going to have a much more
elaborate watchdog with not  only a maximum but also a minimum refresh rate.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


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