Searching \ for '[PIC]:Fast way of forcing master 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: 'Fast way of forcing master Reset?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:Fast way of forcing master Reset?'
2000\11\10@081903 by Morgan Olsson

picon face
If I implement a "system health scanner", and it detects a corrupted register, a routine finding an anomalyty, strange error, or something... Then i want to reboot the system immediately rather than wait for watchdog.

So I want to effectively assert a hardware reset signal, that is guaranteed to reset every pheripheral, also any state that is not writeable as register.

(I can make a startup routine that initializes every writeable register but... reset seem more confident.)

Is there a way to force true reset, other than connecting reset pin to an output pin or wait for watchdog?  Can the Wdog be deliberately triggered?

/Morgan
Morgan Olsson                   spam_OUTmorgans.rtTakeThisOuTspamtelia.com
Morgans Reglerteknik, Hällekås, 277 35 KIVIK, SWEDEN
   tel +46(0)414-446620, fax +46(0)414-672324

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




2000\11\10@085042 by Simon Nield

flavicon
face
check 26.3 of the Mid-range manual.
it highlights the need for caution when changing the assignment of the prescaler from TMR0 to WDT in
order to avoid reseting the device...
you should therefor be able to get the WDT to time out immediately by loading TMR0 with 0xF? and
then switching the prescaler over to WDT.
do let us know if you think this one thorough and work out how exactly to do this.

Regards,
Simon

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




2000\11\10@100629 by Morgan Olsson

picon face
Good idea Simon, thanks.

I´ll check out the details when the prototype is working, probably in january.

/Morgan

Hej Simon Nield. Tack för ditt meddelande 14:51 2000-11-10 enligt nedan:
{Quote hidden}

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




2000\11\10@102705 by mike

flavicon
face
On Fri, 10 Nov 2000 14:15:50 +0100, you wrote:

>If I implement a "system health scanner", and it detects a corrupted register, a routine finding an anomalyty, strange error, or something... Then i want to reboot the system immediately rather than wait for watchdog.
>
>So I want to effectively assert a hardware reset signal, that is guaranteed to reset every pheripheral, also any state that is not writeable as register.
>
>(I can make a startup routine that initializes every writeable register but... reset seem more confident.)
>
>Is there a way to force true reset, other than connecting reset pin to an output pin or wait for watchdog?  Can the Wdog be deliberately triggered?
The only way to guarantee a WDT reset is to wait for it. However in
some circumstances you can reduce the _avarage_ WDT reset time. If the
normal WDT prescale is 1, switching to a higher prescale can cause an
immediate WDT reset if the corresponding bit of the prescaler is set.
Setting the WDT prescale value to each value in turn would have a
fairly high probability of causing an immediate WDT reset.
ALternatively, you could probably force the prescaler by assigning to
TMR0 with internal clock, waiting until it will have incremented and
then re-assigning it to the WDT.  
--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\11\10@102708 by Bob Ammerman

picon face
>check 26.3 of the Mid-range manual.
>it highlights the need for caution when changing the assignment of the
prescaler from TMR0 to WDT in
>order to avoid reseting the device...
>you should therefor be able to get the WDT to time out immediately by
loading TMR0 with 0xF? and
>then switching the prescaler over to WDT.
>do let us know if you think this one thorough and work out how exactly to
do this.
>
>Regards,
>Simon

I get the feeling that the manual is warning about something that could
happen, depending on who knows what factors, not on something that _will_
happen every time.

However, if this could be made to work -- pretty neat!

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.




2000\11\10@102913 by mike

flavicon
face
On Fri, 10 Nov 2000 13:51:19 +0000, you wrote:

>check 26.3 of the Mid-range manual.
>it highlights the need for caution when changing the assignment of the prescaler from TMR0 to WDT in
>order to avoid reseting the device...
>you should therefor be able to get the WDT to time out immediately by loading TMR0 with 0xF? and
>then switching the prescaler over to WDT.
Not quite - you are loading the timer with 0f, not the prescaler.
--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.




2000\11\10@105410 by Simon Nield

flavicon
face
mike:
>Not quite - you are loading the timer with 0f, not the prescaler.
bob:
>I get the feeling that the manual is warning about something that could
>happen, depending on who knows what factors, not on something that _will_
>happen every time.


by '0xf?' i meant some number from 0xf0 to 0xff. i realise that the number will be assigned to tmr0
not the
prescaler, but if the clock is set to internal then by the next instruction the lsb of the prescale
counter should be set (assuming for now that it wasn't already).
the way i read 26.3 and deciphered fig 26.1 suggests that the postscaler becomes slaved to whichever
peripheral it is assigned to. thus clearing tmr0 will clear the prescaler if it is assignet to tmr0,
and similarly clearing wdt will clear the prescaler if it is assigned.
26.3 suggests that the prescaler is not automatically cleared when its assignment changes... as bob
is suggesting however this is not garanteed to be the case.

something along the lines of the following (hacked from example 26.1) might/should therefor do the
trick:

clrf INTCON              ; disable interrupts otherwise they could ruin everything
bsf  STATUS, RP0         ; bank1
movlw     B'11010000'
andwf     OPTION_REG, F       ; internal clock, assign to tmr0, prescaler on lowest setting
bcf  STATUS, RP0         ; bank0
clrf TMR0           ; clear tmr0 and prescaler
comf TMR0, F        ; set tmr0
bsf  STATUS, RP0         ; bank1
bsf  OPTION_REG, PSA     ; assign to wdt... by which time bit0 of the prescaler should be set


worth a try anyway... at worst you end up waiting as long as normal.

Regards,
Simon

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




2000\11\10@113255 by Bob Ammerman

picon face
I am beginning to like this devious thinking. I'll bet you guys are on to
something.



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

{Original Message removed}

2000\11\10@113915 by Morgan Olsson

picon face
I wrote:
>I´ll check out the details when the prototype is working, probably in january.

Time go fast...

Looking in F877 manual fig 5-1, it seem possible we can force a reset guaranteed in short time by:

1) Switch the prescaler to the timer, set it to low prescale value, and feed it with Fosc/4.

2) clrf TMRO ;This will also clear the prescaler, which we are interested in

3) Wait the number of cycles that make the prescaler output go "1"

4) toggle PreScaler Asignment bit in order to put that "1" into "WDT Time-out" line.  Done!  :)


Remarks:
In 3) If selected prescaler rate 2:1 then just a NOP is sufficient? or nothing?

In 4) there is the risk of the prescaler output already gone low if using prescaler 2:1.  I wonder about precise timing between clocking in prescaler and operation of PSA bit...  I know BSF/BCF executes write in Q4.  Hmmm... Maybe safer to use 4:1 prescaler and 3 cycles delay in 3) ?

Have no time to experiment now, if somebody does, please report.
Regards
/Morgan

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




2000\11\10@113918 by Morgan Olsson

picon face
Simon Nield wrote:

>clrf INTCON              ; disable interrupts otherwise they could ruin everything
>bsf  STATUS, RP0         ; bank1
>movlw     B'11010000'
>andwf     OPTION_REG, F       ; internal clock, assign to tmr0, prescaler on lowest setting
>bcf  STATUS, RP0         ; bank0
>clrf TMR0           ; clear tmr0 and prescaler

Right, but why do you want to

>comf TMR0, F        ; set tmr0

?  The contents of TMR0 is irrelevent to the following.
BTW I believe any kind of write to TIMER0 clears the prescaler? (also comf)

>bsf  STATUS, RP0         ; bank1
>bsf  OPTION_REG, PSA     ; assign to wdt... by which time bit0 of the prescaler should be set

I believe so, details see my other mail a couple minutes ago...  :)
(I forgot to include "clrf INTCON" but of course that should be done.

For security, if the above scheme should fail for unknown reason, we ought to add a couple of lines that rearranges the Wdog without prescaler, then "goto $" to wait for it to trigger.

/Morgan

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




2000\11\10@115405 by Simon Nield

flavicon
face
morgan:
>Right, but why do you want to
>comf TMR0, F        ; set tmr0
>?  The contents of TMR0 is irrelevent to the following.
>BTW I believe any kind of write to TIMER0 clears the prescaler? (also comf)

according to the manual the comf will indeed clear the prescaler, however the plan is that it also
effectively sets the lsb of the prescaler on the next clock edge. i guess i could have done movlw
0xff / movwf tmr0... same thing.


Regards,
Simon

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




2000\11\10@122017 by Morgan Olsson

picon face
Simon Nield wrote:
>according to the manual the comf will indeed clear the prescaler, however the plan is that it also
>effectively sets the lsb of the prescaler on the next clock edge. i guess i could have done movlw 0xff / movwf tmr0... same thing.

Yes, but the same thing, from prescaler point of view, is already accomplished by the comf TMR0 instruction, as you described, on the foregoing line?

/Morgan

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




2000\11\10@123713 by Simon Nield

flavicon
face
morgan:
>Yes, but the same thing, from prescaler point of view, is already accomplished by the comf TMR0
instruction, >as you described, on the foregoing line?

exactly. 'clrf tmr0 / comf tmr0, F' does the same job as 'movlw 0xff / movwf tmr0' would do here (it
doesn't change W, but who cares?).
by making tmr0 0xff and clearing the prescaler, on the next clock you get tmr0=0x00 and prescaler =
0x01.
flip the PSA bit and the wdt should fire off straight away.

i'm not sure if you are asking me a question about my code or suggesting there's a problem with
it... could you clarify ?

Regards,
Simon

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




2000\11\10@162804 by Morgan Olsson

picon face
Simon Nield wrote:

>i'm not sure if you are asking me a question about my code or suggesting there's a problem with
>it... could you clarify ?

Well, it is just nit-picking...  (right word, BTW?)

You earlier posted the proposed solution:

clrf INTCON              ; disable interrupts otherwise they could ruin everything
bsf  STATUS, RP0         ; bank1
movlw     B'11010000'
andwf     OPTION_REG, F       ; internal clock, assign to tmr0, prescaler on lowest setting
bcf  STATUS, RP0         ; bank0
clrf TMR0           ; clear tmr0 and prescaler
comf TMR0, F        ; set tmr0
bsf  STATUS, RP0         ; bank1
bsf  OPTION_REG, PSA     ; assign to wdt... by which time bit0 of the prescaler should be set

And I said, in other words, that the line "comf TMR0, F" is not needed.
(AFAIK)

Regards
/Morgan

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




2000\11\11@105502 by J Nagy

flavicon
face
Morgan Olsson wrote:
<snip>
>
>So I want to effectively assert a hardware reset signal, that is
>guaranteed to >reset every pheripheral, also any state that is not
>writeable as register.
>
>(I can make a startup routine that initializes every writeable register
>but... >reset seem more confident.)
>

       If you are implementing a system that doesn't initialize all during
a normal power up, you are only asking for trouble.


>Is there a way to force true reset, other than connecting reset pin to an
>>output pin or wait for watchdog?  Can the Wdog be deliberately triggered?
>

       Why don't you just jump (GOTO) your initialization code. As above,
properly written code will assume nothing (other than what Microchip
guarantees) on startup and will initialize *everything*. The only addition
you may want to make is a CLRWDT instruction if you haven't already got one.
       As to the hardware reset, I wasn't aware of any Microchip product
that *outputs* a reset signal. I thought this was unique to Motorola.
Haven't been able to keep up like I used to though (and didn't receive any
notice of this years seminars!).




       Jim

 Elm Electronics
 ICs for Experimenters
http://www.elmelectronics.com/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use .....listservKILLspamspam@spam@mitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\11@125727 by Morgan Olsson

picon face
Have done some testing now, but no sucess so far, and i am out of ideas...

Simon Nield posted the code below
(which is corresponding to a description I posted at about the same time)

{Quote hidden}

I have tested with and without that line

Also tried different prescale settings and experimented different number of NOPs before the line bsf OPTION_REG, PSA in order to tune it in time so we would output the "1" to Wdog reset output.  (see my description in beginning of thread)

What happens is I have an "goto $" line after the code above where it so far always hangs until the watchdog bites, and the time untl reset is always as if we have just reset the prescaler and wdog and get a normal wdog timeout according to prescaler setting.

Strange is, that it is always the same time, even if i change the prescaler ratio and experiment with different number of NOPs as described above.  If following the schamatic in the doc the prescaler should get clocked by one pulse for each nop (prescaler is fed with clk/4) thus preloading the prescaler with a value by which the number of wdog periods diminishes before the watchdog should bite.  But the number of NOPs seem not to matter.

Ome possible explanation I get to think of is the line "bsf OPTION_REG, PSA" also clears the prescaler.  But that seem crazy.
Do really reading or writing the OPTION reg, or at least setting the PSA bit clear the prescaler?  Nah...
Is that in the docs somewhere?

Is there something else I might be doing wrong/forgot or something?

According to the schematic in the doc the presented routine should reset the controller regardles of the Watchdog Enable configuration bit  (that bit only stops the Wog oscillator)  I have tested with that bit both on and off.  Difference is that if enbled the wdog triggeres while looping on the goto $ line, otherwise it never triggers.  The routine never manage to reset the PIC.

Testing is performed on an PIC16F877 datecode 9921BSL.

It would be good if somebody could try on an old C84 or something.
Or have another idea.

A quick reset function may get handy one day.

Regards
/Morgan

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use listservspamKILLspammitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\11@133517 by Morgan Olsson

picon face
J Nagy wrote:

-snip-

>       If you are implementing a system that doesn't initialize all during
>a normal power up, you are only asking for trouble.

..But how do i for example reset the internal state machine of the I2C interface?

That one might not be very important, but thera are certainly some internal state registers in the pheripherals that are not accessible, nor documented, so I would feel more safe if i could asert a reset.

(Although it is not guaranteed to reset every undocumented thingy, either...)


>>Is there a way to force true reset, other than connecting reset pin to an
>>>output pin or wait for watchdog?  Can the Wdog be deliberately triggered?
>>
>
>        Why don't you just jump (GOTO) your initialization code. As above,
>properly written code will assume nothing (other than what Microchip
>guarantees)

Not needing to have the software reset everything make it faster and the reset "glitch" less noticeable, when we can get back on track faster.  A plus if we can detect why we got into reset.

If we can force Wdog reset we can also do some tricks:
There are in the PIC status bits that can tell wether it was a Watchdog reset. So the boot rotine checks that, and if it finds it was a watchdog reset it continues by reading a special flag that we keep clear always except we set it just before we force a watchdog reset.  That flag might even be a whole register loaded with a message code from the routine that triggered the reset, and the boot routine may then report or log the specific error, or decide to do a special fastboot or whatever.

Full control to do what we want, sort of.

BTW, what is the state of W register during different sorts of resets... unaffected?

Well, we have to think carefully when designing hose routines of course; easy to make bugs ther that are hard to detect, maybe.

But all this is just a dream so far.

Regards
/Morgan

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use .....listservKILLspamspam.....mitvma.mit.edu?body=SET%20PICList%20DIGEST




2000\11\11@180727 by mike

flavicon
face
On Sat, 11 Nov 2000 19:21:45 +0100, you wrote:

>J Nagy wrote:
>
>-snip-
>
>>       If you are implementing a system that doesn't initialize all during
>>a normal power up, you are only asking for trouble.
>
>..But how do i for example reset the internal state machine of the I2C interface?
>
>That one might not be very important, but thera are certainly some internal state registers in the pheripherals that are not accessible, nor documented, so I would feel more safe if i could asert a reset.
>
In many cases like this you can force resets by switching the
peripheral off & onn. For example clearing overrun errors on the UART

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu?bodyT%20PICList%20DIGEST




2000\11\13@060440 by Simon Nield

flavicon
face
morgan:
wow i am very impressed with your enthusiam! i suspect you are right when you say that it looks like
toggling the PSA bit is reseting the prescaler... it could be that microchip do not conscider this
part of the design to be reliable - prehaps it fails setup times at high clock rates or something?
could also be that the prescaler reset was not implemented on earlier chips. doesn't really matter
though i guess - the end result is still the same; this little scheme doesn't appear to work.

>If following the schamatic in the doc the prescaler should get clocked by one pulse for each nop
(prescaler is
> fed with clk/4) thus preloading the prescaler with a value by which the number of wdog periods
diminishes before >the watchdog should bite.  But the number of NOPs seem not to matter.

ah... i think i see why you were saying that the comf line is not needed now. the eight bit counter
is a prescaler when used with tmr0 and a postscaler when used with wdt... i clearly didn't look at
the tmr0 block diagram. you are quite right, the comf will make no difference at all... silly me.

>Strange is, that it is always the same time, even if i change the prescaler ratio and experiment
with

very odd... changing the prescaler ratio should at least cause the delay to change.

>Ome possible explanation I get to think of is the line "bsf OPTION_REG, PSA" also clears the
prescaler.

if you are still feeling keen you could check the reset on PSA toggle theory by flipping the bit
twice and seeing if it affects the operation of T0IF ?



....

i just read the comment on example 26.1 again, and i am starting to think that there may be
something odd happening with the prescaler/postscaler... what if the 'unused bits' of the scaler
were held low ? this would save power and would mean that in 1:1(wdt)1:2(tmr0) mode almost all the
bits would be zero.
i wonder if having the tmr0 prescaler set to, say, 1:256 and then swapping over the scaler to be the
wdt prescaler with a ratio of 1:1 would be any different?

clrf   INTCON              ; disable interrupts otherwise they could ruin everything
bsf    STATUS, RP0         ; bank1
movlw  B'11010111'
movwf  OPTION_REG          ; internal clock, assign to tmr0, prescaler on highest setting
bcf    STATUS, RP0         ; bank0
clrf   TMR0                ; clear tmr0 and prescaler to give a known state
bsf    STATUS, RP0         ; bank1
movlw  B'11011001'
bsf    OPTION_REG, PSA     ; assign to wdt and change postscale to 1:2


made the first change to the OPTION_REG a movwf as i want to set as well as clear some bits. changed
postscale to 1:2 as i am not sure if 1:1 even goes via the postscaler... wouldn't going by the
postscaler automatically mean the minimum ratio is 1:2 ? this could be the main problem actually...
who knows?


apologies for the long rambling post.

Simon

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads




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