Searching \ for 'Where to put CRLWDT?' 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=where+put+crlwdt
Search entire site for: 'Where to put CRLWDT?'.

Truncated match.
PICList Thread
'Where to put CRLWDT?'
1998\09\29@192228 by Douglas Reid

flavicon
face
Following on from my thread entitled: "PIC being reset by spikes from motors
- any ideas?" of a few weeks ago (relating to an automatic gate system)...

Firstly, I should like to thank the many people who contributed useful ideas.
I have now built a revised relay board incorporating C-R snubber components.
I shall be visiting the site later this week to fit this and, hopefully, it
will solve my problem.

I am now looking at tidying up the software to make it more resilient to
brown-out problems.  The question arises as to where best to put the CLRWDT
instruction.

My code is perhaps a little unusual in that the "main" programme does
nothing (apart from, at the moment, clearing the WDT).  All the work is done
in tmr0 and tmr1 ISRs using state machines.  The reason that I wrote the
software like this was so that everything happens at well defined intervals
- eg. debouncing of the inputs, sequencing of the gate motor drives (eg.
drive open for 10 seconds), etc.

Thus, the software can be crudely described as follows:

tmr1_isr  ; this ISR is run every 20msec (it takes about 1.56msec to execute)
         Code to run various state machine
         (eg. to check input switches/ look at infra-red safety beams/ etc.)

         When appropriate starts a gate motion by enabling motor
         and putting desired motor on duration (in seconds) into a register
         then enabling tmr0 ISRs.
         return


tmr0_isr  ; this ISR is run every 16.384msec (when enabled)
         ; doesn't take long to execute (a few 100 usec)
         Counts ISR ticks and increments seconds counter.
         Compares seconds count with desired motor on duration
         and, when matches, stops motor.
         return


main      clrwdt
         goto   main


As explained in my previous post, I have had a lot of trouble with
interference from the motors.  Of course, this results in registers being
corrupted in unpredictable ways.  The worrying aspect is that having CLRWDT
in "main" (as above) doesn't always result in the system being reset by the
WDT when corruption occurs.  For example, motors have been observed to run
continuously, etc.
This is understandable in that if - to give just one example - the OPTION
register were to get corrupted, the tmr0 source could be reassigned in error
to the RA4 pin.  In this way, the timer would not get incremented.

Having CLRWDT in main doesn't solve such a problem!

If instead CLRWDT is put in both of the ISRs, the WDT would get reset even
if only one of the ISRs was being executed.  (Memory corruption could result
in an interrupt being disabled in error.)

My question is: what is the recommended strategy for location of the CLRWDT
instruction(s)?

Actually, as I write this, I am thinking that I could probably eliminate use
of tmr0 and put everything into tmr1_isr.  It appears that that would solve
my own problem!  However, the question still arises as to the general
strategy should we need to use several different interrupts in a particular
future project.

I have another question.  The system at present has a Dallas DS1233D-15
reset controller fitted.  I left it with this thinking that, until I sorted
the interference problem, the system would at least predictably reset and
properly reinitialise itself.  However, my customer informs me that it
behaving strangely (ignoring inputs, etc.), leading me to believe that the
DS1233 isn't doing it's job.  So my second question is: why can I not rely
on the DS1233 to reset the system?  By the way, the PIC is a 16C73 (not A
version).  (I have yet to witness this behaviour with my own eyes - I shall
have the chance when I go to the site this Friday!)

Best Regards,
Doug Reid

Liverpool, England

1998\09\29@224127 by Sean Breheny

face picon face
Hi Doug,

At 12:17 AM 9/30/98 +0100, you wrote:
>This is understandable in that if - to give just one example - the OPTION
>register were to get corrupted, the tmr0 source could be reassigned in error
>to the RA4 pin.  In this way, the timer would not get incremented.
>
>Having CLRWDT in main doesn't solve such a problem!
>
>If instead CLRWDT is put in both of the ISRs, the WDT would get reset even
>if only one of the ISRs was being executed.  (Memory corruption could result
>in an interrupt being disabled in error.)
>
>My question is: what is the recommended strategy for location of the CLRWDT
>instruction(s)?

There are probably more clever solutions, but what about reserving a file
register. Have each of your ISRs clear a bit of this F. Your main routine
would then do the folowing:

main:
if F=0 CLRWDT and set the two bits of F
goto main


Therefore, if one of the two ISRs never executed, CLRWDT would never get
executed.


Good Luck,

Sean



+--------------------------------+
| Sean Breheny                   |
| Amateur Radio Callsign: KA3YXM |
| Electrical Engineering Student |
+--------------------------------+
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
spam_OUTshb7TakeThisOuTspamcornell.edu  Phone(USA): (607) 253-0315 ICQ #: 3329174

1998\09\30@001427 by Mike Keitz

picon face
On Wed, 30 Sep 1998 00:17:45 +0100 Douglas Reid
<.....Douglas.ReidKILLspamspam@spam@BTINTERNET.COM> writes:

>My code is perhaps a little unusual in that the "main" programme does
>nothing (apart from, at the moment, clearing the WDT).  All the work
>is done
>in tmr0 and tmr1 ISRs using state machines.  The reason that I wrote
>the
>software like this was so that everything happens at well defined
>intervals
>- eg. debouncing of the inputs, sequencing of the gate motor drives
>(eg.
>drive open for 10 seconds), etc.

I'd have the two timer routines set flags in RAM when the execute.  The
main program would wait until both flags are set, then execute a CLRWDT,
clear both flags and wait again.  If something happens to one of the
timers or the interrupt logic, a flag won't get set, the main program
will hang up waiting, and the WDT will time out.  If everything goes
according to plan, that is.



___________________________________________________________________
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
Or call Juno at (800) 654-JUNO [654-5866]

1998\09\30@025520 by Sean Breheny

face picon face
One additional possibility:

Under certain circumstances, it may be permissible to allow the WDT to
reset your code periodically. Once I made a remote door-lock transmitter
that was supposed to send an activation code at a long periodic interval,
the exact timing of which didn't matter (something around 1 to 2 seconds).
So, instead of iimplementing a software timer and then a WDT to ensure
reliability, I just used the WDT as the main timer. It is important to note
that the WDT is temperature/manufacturing tolerance unstable, so you can't
depend on it for high accuracy, but if your device only needs to, say,
detect the presence of a person standing on a pressure sensor and perform
an operation based upon that, it would not matter if it reset every half
second or so.

Sean

At 11:16 PM 9/29/98 -0400, you wrote:
{Quote hidden}

+--------------------------------+
| Sean Breheny                   |
| Amateur Radio Callsign: KA3YXM |
| Electrical Engineering Student |
+--------------------------------+
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
.....shb7KILLspamspam.....cornell.edu  Phone(USA): (607) 253-0315 ICQ #: 3329174

1998\09\30@081224 by Chip Weller

flavicon
face
Douglas Reid wrote:

<snipped>

>I am now looking at tidying up the software to make it more resilient to
>brown-out problems.  The question arises as to where best to put the CLRWDT
>instruction.
>
>My code is perhaps a little unusual in that the "main" programme does
>nothing (apart from, at the moment, clearing the WDT).  All the work is
done
>in tmr0 and tmr1 ISRs using state machines.  The reason that I wrote the
>software like this was so that everything happens at well defined intervals
>- eg. debouncing of the inputs, sequencing of the gate motor drives (eg.
>drive open for 10 seconds), etc.

A couple of comments.

First a brown-out condition can lead to a completely invalid internal state
which cannot be recovered by software. Make sure you have a hardware
brown-out reset on the system.

One noise problem which can occur is having output port data bits getting
corrupt. I have learned to never directly set and clear bits on the I/O port
map, instead I set and clear in a image byte which I then write out to the
port. Two problems can occur: the read-modify-write sequence can pick up a
bad data input from a pin, or the noise can directly corrupt the data in the
PORTx output bit (Yes this can happen). The first line of defense is
limiting impedance on all I/O pins. It is also possible for the TRISx
registers to become corrupt, you may want to reload these periodicly also.


Other replies have mentioned using flags set from the interrupts and
clearing in the main only if the main line sees those flags. This is a good
overall method. The clrwdt instruction could be in any location in that
case.

Since you are using TMR0 at 16.384ms I suspect you have the prescaler
selected on that device. If this is the case then the watchdog timer could
time out in as short of a time as 7 milliseconds, which is shorter that the
interrupt rates. You could program the main task to loop, clearing the
watchdog timer for about 13 to 20 milliseconds and then enter a loop to test
your flags. If and when flags are set clear them and re-enter the clear
watchdog loop.

Good luck,
Chip.


'Where to put CRLWDT?'
1998\10\01@114808 by John Payson
flavicon
face
|Under certain circumstances, it may be permissible to allow the WDT to
|reset your code periodically.

If periodic forced resets are acceptable, it may be useful to
have external hardware to enforce them.  For top reliability,
you may want to have an external device control the PIC's power
so that even if it goes into CMOS latch-up, it will come out of
that condition "guaranteed".  If your code is supposed to do a
tiny bit of work once per second, you could use a simple timer
circuit to turn the PIC on for 3/4 second and off for 1/4 second
or somesuch.  As a slightly-related alternative, you could have
your external hardware pull down on MCLR briefly while discon-
necting the supply to the PIC's bypass/filter caps; if the PIC is
not in CMOS latchup, decent-sized caps may keep it powered enough
to maintain RAM contents, but if it goes into CMOS latchup the
caps would drain out and the device would get a true power-down,
thereby ending the latch-up condition (internal RAM contents would
be hosed in such a case, naturally, but the device would still be
operable).

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