Searching \ for 'Application controlled 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/index.htm?key=application+controlled
Search entire site for: 'Application controlled reset ???'.

Truncated match.
PICList Thread
'Application controlled reset ???'
1997\02\17@182140 by Bob Segrest

picon face
Greetings,

I am writing code to use the PIC chip as a classic embedded controller.
One of the commands I would like to implement is a remote reset.  This
would allow the controlling system to issue a command that would tell the
PIC to restart and re initialize itself.

Is there an easy way to reset the PIC processor from a running application ???

The PIC in this particular endeavor is a 16C73A...

Bob Segrest

1997\02\17@182942 by Antti Lukats

flavicon
face
At 06:19 PM 17/2/97 -0500, you wrote:
>Greetings,
>
>I am writing code to use the PIC chip as a classic embedded controller.
>One of the commands I would like to implement is a remote reset.  This
>would allow the controlling system to issue a command that would tell the
>PIC to restart and re initialize itself.
>
>Is there an easy way to reset the PIC processor from a running application ???
>
>The PIC in this particular endeavor is a 16C73A...

you could just fall into loop and wait for Watchdog reset to happen.
(you must have Watchdog enabled)

there is no direct commands to implement reset in software.

antti

-- Silicon Studio Ltd.
-- http://www.sistudio.com

1997\02\17@185022 by Miller, Steve

flavicon
face
What about just a GOTO to address 00 ?  This will restart the code as if
a power-on reset occurred.  In your initilization routine, you will have
to set all the flags and options to known states.  But, I do not see why
it would not work.  Have I overlooked something?

---- Steve


----------
From:  pic microcontroller discussion [SMTP:spam_OUTPICLISTTakeThisOuTspamMITVMA.MIT.EDU]
Sent:  Monday, February 17, 1997 6:19 PM
To:  PICLIST
Subject:  Application controlled reset ???


Greetings,

I am writing code to use the PIC chip as a classic embedded controller.
One of the commands I would like to implement is a remote reset.  This
would allow the controlling system to issue a command that would tell the
PIC to restart and re initialize itself.

Is there an easy way to reset the PIC processor from a running
application ???

The PIC in this particular endeavor is a 16C73A...

Bob Segrest

1997\02\17@185607 by Antti Lukats

flavicon
face
At 05:50 PM 17/2/97 -0600, you wrote:
> What about just a GOTO to address 00 ?  This will restart the code as if
>a power-on reset occurred.  In your initilization routine, you will have
>to set all the flags and options to known states.  But, I do not see why
>it would not work.  Have I overlooked something?
>
> ---- Steve

GOTO 00 is not same as (COLD)reset. It depends on application program
what happends by GOTO 00, if the program expect to be running after
reset, ie expect some re-gisters have "reset" value, then GOTO 00
might just hang your program.

antti

-- Silicon Studio Ltd.
-- http://www.sistudio.com

1997\02\17@191027 by ONY NIXON 54964

flavicon
face
If your application originally began from a 'START' address, then if
a reset condition occurred you could GOTO a 'STARTB' address which
can leave some flags in a known state.

If an input pin going low will cause the reset condition then a flag
could be set indicating the reset. The 'STARTB' address does not
clear this flag, so the normal programs execution will ignore the low input
and clear the flag when this input goes high again.

Tony


Just when I thought I knew it all,
I learned that I didn't.

1997\02\17@192241 by myke predko

flavicon
face
An enhancement to what Tony says:

If you had an extra I/O pin, how about tying it directly to Reset like so:

                   Vdd
         |          |
         |          >
 PIC     |          <  Reset Pull-Up
         |          >
         |          |
    _MCLR|----------+
         |          |
      Pin|----------+
         |

Now, When you wanted to reset the device, enable the Pin to be low and the
PIC will reset itself.  When the PIC resets, all the I/O Ports go back to
Input and the _MCLR line goes back up high and you can start executing from
the beginning with a reset PIC again.

The reset code would be:

 bcf    PORTn, Pin             ;  Make Sure the Pin is Low
 bsf    STATUS, RP0
 bcf    TRISn, Pin             ;  Enable the Pin
 bcf    STATUS, RP0
 goto   $

The last two instructions would be for "safety", but probably wouldn't be
executed.  If an open collector (RA4) Pin was used, then the move to Bank1
wouldn't be required and the code would simply be:

 bcf    PORTA, 4

If it's an 18 Pin device, this really gets easy because RA4 is beside _MCLR.

myke

{Quote hidden}

"I don't do anything that anybody else in good physical condition and
unlimited funds couldn't do" - Bruce Wayne

1997\02\17@232133 by tjaart

flavicon
face
Bob Segrest wrote:
>
> Greetings,
>
> I am writing code to use the PIC chip as a classic embedded controller.
> One of the commands I would like to implement is a remote reset.  This
> would allow the controlling system to issue a command that would tell the
> PIC to restart and re initialize itself.
>
> Is there an easy way to reset the PIC processor from a running application ???
>
> The PIC in this particular endeavor is a 16C73A...
>
> Bob Segrest

I use a similar command. Clear PCLATH and PCL. It works fine for me,
because
I save the output states in EEPROM, so when the PIC starts up, its loads
all
the default output values.

The stack overflows badly when you do this, so the emulator doesn't like
the
command, but it works well in the OTP parts.

--
Friendly Regards

Tjaart van der Walt
.....tjaartKILLspamspam@spam@wasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
|             ASP International  http://wasp.co.za            |
|             GSM and GPS value-added applications            |
|  Voice : +27-(0)11-622-8686   |   Fax : +27-(0)11-622-8686  |
|_____________________________________________________________|

1997\02\18@004346 by David W. Duley

picon face
In a message dated 97-02-17 18:30:14 EST, you write:

<<
At 06:19 PM 17/2/97 -0500, you wrote:
>Greetings,
>
>I am writing code to use the PIC chip as a classic embedded controller.
>One of the commands I would like to implement is a remote reset.  This
>would allow the controlling system to issue a command that would tell the
>PIC to restart and re initialize itself.
>
>Is there an easy way to reset the PIC processor from a running application
???
>
>The PIC in this particular endeavor is a 16C73A...

you could just fall into loop and wait for Watchdog reset to happen.
(you must have Watchdog enabled)

there is no direct commands to implement reset in software.

antti
 >>
Now for my 2 cents worth.
One way that I have implemented this sort of thing is to use the Watchdog
timer to automatically reset the chip if it does not recieve a signal from
the host etc.
A periodic signal generated from a host computer prevents the remote
controllers from resetting.  If the signal is not there the remote will
reset.

If there is no host computer you could implement a reset instruction using
the watch dog timer by simply jumping to a tight loop that does not clear the
WDT. The net result will be a reset in a few milliseconds.
Hope this helps
Dave Duley
V.P. DreiTek Inc.

1997\02\18@023219 by John Dammeyer

flavicon
face
At 11:57 AM 17/02/1997 -0400, you wrote:
>At 05:50 PM 17/2/97 -0600, you wrote:
>> What about just a GOTO to address 00 ?  This will restart the code as if
>>a power-on reset occurred.  In your initilization routine, you will have
>>to set all the flags and options to known states.  But, I do not see why
>>it would not work.  Have I overlooked something?
>>
>> ---- Steve
>
>GOTO 00 is not same as (COLD)reset. It depends on application program
>what happends by GOTO 00, if the program expect to be running after
>reset, ie expect some re-gisters have "reset" value, then GOTO 00
>might just hang your program.
>
>antti
Personally I have never considered it wise to rely on what state the
hardware might be in after a cold start.  I believe robust programming means
initializing every thing to the state you want it right after power up and
before you use those peripherals.

So having said that I would jump t a routine that would a) disable all
interrupts if your flavour of the PIC has them and b) GOTO zero.  If that
hangs your program you probably deserve it. <grin>

John
Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc.      Ph. 1-250-544-4950
PO Box 20002                  Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9

1997\02\18@083200 by Kalle Pihlajasaari

flavicon
face
Hi Bob,

> I am writing code to use the PIC chip as a classic embedded controller.
> One of the commands I would like to implement is a remote reset.  This
> would allow the controlling system to issue a command that would tell the
> PIC to restart and re initialize itself.
>
> Is there an easy way to reset the PIC processor from a running application ???
>
> The PIC in this particular endeavor is a 16C73A...

I have used a I/O pin in the past to reset PICs and Parallax Stamps.

Just connect your remaining pin to the _MCLR pin and when you want
to reset you just drive the pin to an output and then write a
zero to it.  This is very effective and clears the condition on the
pin when the chip has reset as the pins all change to inputs
after the reset.

The other alternative of letting the watchdog run-out by turning
off interrupts and running in a tight loop would cause a reset
from about 20 ms to 2 seconds later (depending on the watchdog
prescaler).  This requires you to have the watchdog fuse enabled
and also the reset will not be exactly the same as a MCLR reset.
You also need to service the watchdog in the rest of your code.
This option is not available with most of the preprogrammed interpreter
chips like the Stamps which is why I used the first method above.

Perhaps better yet is to use a pin to short the supply rail to ground
with the help of an external transistor that will cause a genuine
cold reset.  This might be requiired by some of the periferals
on some of the early silicon that had some quirks where a WD
or MCLR reset were nor enough to clear a stuck periferal (UART
I think was the problem one)

Cheers
--
Kalle Pihlajasaari   kallespamKILLspamip.co.za   http://www.ip.co.za/ip
Interface Products   P O Box 15775, DOORNFONTEIN, 2028, South Africa
+ 27 (11) 402-7750   Fax: 402-7751    http://www.ip.co.za/people/kalle

DonTronics, Silicon Studio and Wirz Electronics uP Product Dealer

1997\02\18@190733 by Steve Hardy

flavicon
face
> From: John Dammeyer <.....johndKILLspamspam.....ISLANDNET.COM>
>
> >
> >GOTO 00 is not same as (COLD)reset. It depends on application program
> >what happends by GOTO 00, if the program expect to be running after
> >reset, ie expect some re-gisters have "reset" value, then GOTO 00
> >might just hang your program.
> >
> >antti
> Personally I have never considered it wise to rely on what state the
> hardware might be in after a cold start.  I believe robust programming means
> initializing every thing to the state you want it right after power up and
> before you use those peripherals.
>
> So having said that I would jump t a routine that would a) disable all
> interrupts if your flavour of the PIC has them and b) GOTO zero.  If that
> hangs your program you probably deserve it. <grin>

It's no _less_ wise to rely on the published reset state than to rely
on the machine's correct execution of your initialisation code.

Really, in a small ram machine you shouldn't be wasting space doing
something which the manufacturer has guaranteed will be done for
you.  I will concede, however, that you should document any reliance
on reset state.

In the case of the original posting, where it is desired to simulate
a reset, then the above paragraph is not entirely true.  Nevertheless
one cannot truly simulate a reset by executing instructions from location
zero.  For a start, assertion of !MCLR immediately puts all port pins
in a high impedance state.  This cannot be done by sequential instructions
since only one port can be hi-Z'd(*) at once.  Also, are you _really_
going to go to the trouble of randomising your file registers?

Regards,
SJH
Canberra, Australia

(*) Some times I envy the American pronunciation of 'Z' (zee) since
it is much easier to say 'hi-zeed' than 'hi-zeded'.  Also the
American use of 'EZ' (easy) looks all wrong in the English speaking
world - eezed?

1997\02\19@030423 by lmclaren

flavicon
face
Bob Segrest wrote:
>
> Greetings,
>
> I am writing code to use the PIC chip as a classic embedded controller.
> One of the commands I would like to implement is a remote reset.  This
> would allow the controlling system to issue a command that would tell the
> PIC to restart and re initialize itself.
>
> Is there an easy way to reset the PIC processor from a running application ???
>
> The PIC in this particular endeavor is a 16C73A...
>
> Bob Segrest

The way I normaly do it is to use the watchdog timer in the program as
normal.
when I want a reset I go into a loop eg:

wait    goto wait

This will stop your clrwdt intruction from happening and cause a reset.
regards
--
Lee McLaren                          EraseMElmclarenspam_OUTspamTakeThisOuTtrumpet.com.au
Comstra pty. ltd.                    lmclarenspamspam_OUTcomstra.com.au
2 Kirksway place                     phone       03 62244488
Hobart Tasmania                      fax         03 62244601
Australia 7000                       mobil       018 138682

'It was five hours of Boggs's "channelling". After three hours
I asked him to summon up the soul of Jimi Hendrix and requested
All Along the Watchtower. You know, the guy's been dead
twenty years but he still hasn't lost his edge'
Mulder

1997\02\19@031454 by John Dammeyer

flavicon
face
At 11:16 AM 19/02/1997 EST, you wrote:
{Quote hidden}

If you never change what was done by the manufacturer after a power on reset
I suppose it will still be the same after a 'warm' start.  However relying
on that can be catastrophic if the manufacturer changes something in a chip
revision that is perhaps not fundamental to the operation of the of the
processor but convenient for manufacturing.

>I will concede, however, that you should document any reliance
>on reset state.

I agree.

>
>In the case of the original posting, where it is desired to simulate
>a reset, then the above paragraph is not entirely true.  Nevertheless
>one cannot truly simulate a reset by executing instructions from location
>zero.  For a start, assertion of !MCLR immediately puts all port pins
>in a high impedance state.  This cannot be done by sequential instructions
>since only one port can be hi-Z'd(*) at once.

If the ports are required to be in a HiZ state for some type of operation
and you cannot do that explicitly then perhaps we are discussing poor
programming or design  practices and insisting that we be able to practice
them.

>Also, are you _really_
>going to go to the trouble of randomising your file registers?

Why on earth would you want to do that?  I have seen C programmers get into
trouble by using auto-initialization for their variables and then when they
emulate a soft reset wonder why programs blow up.   Relying on random
variable values is even more dangerous.

int i = 5; is a perfect example of a variable that is initialized by startup
code.

Unless that re-startup is emulated perfectly, relying on i == 5 is
dangerous.  If there is a _need_ for a system initiated restart -
non-watchdog - then the initialization of i belongs in an init function.
When Pascal was developed auto init was not included; I believe for a good
reason.  By forcing a programmer to deliberately set variables to what they
must be,  there is an element of repeatability in the application.

In an embedded system, that can be as explicit as copying a series of values
contained in ROM into the variables;  but then it's controlled.

As I recall a Redstone missle went splashdown because a variable was named
starting with an I,J or K rather than an R or S.  For non Fortran
programmers,  variables defined starting with an I,J, or K were
automatically Integers and those starting with an R or S were automatically
floating point.  We have come a long way since then with proper typing and
compilers complaining about mixing types.  Relying on reset values is taking
a step backwards in time and has the _potential_ of subtle bugs in code.

I realize I won't get consensis with this but it's my opinion.



Regards,

John
Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc.      Ph. 1-250-544-4950
PO Box 20002                  Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9

1997\02\19@091926 by mike

flavicon
picon face
In message  <m0vx6Nu-0006beC@mail> KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU writes:
> At 11:16 AM 19/02/1997 EST, you wrote:
> >> From: John Dammeyer <RemoveMEjohndTakeThisOuTspamISLANDNET.COM>
> >>
> >> >

[snips]

{Quote hidden}

Excuse me for butting in here, but I think you missed the point.
All ports are set to HiZ by a /MCLR or POR at the same time. I
think the point that was being made is that it is not possible
to do that in software as you can only change one tris reg at
a time. So truly simulating a reset in software is not possible.

>
> >Also, are you _really_
> >going to go to the trouble of randomising your file registers?
>
> Why on earth would you want to do that?

No-one would want to do that, but after a POR, all ram is in a
random state. IFF you wanted to truly simulate POR in software, you
would have to randomise the ram contents or it wouldn't be
a true simultaion.

Regards,


Mike Watson

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