![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
jaikumar
Joined: 15 Dec 2006 Posts: 109
|
Supervisory circuit question |
Posted: Sat Jan 10, 2015 4:49 am |
|
|
Hi,
This is the CAT706 micro supervisor ic.
Datasheet
http://pdf1.alldatasheet.com/datasheet-pdf/view/529110/ONSEMI/CAT706RVI-GT3.html
I would like to know if it would be alright to connect active low WDO to active low MR pin.
So that to create a reset when watchdog is not triggered.
I would like to have one active low reset pin for both voltage det and watchdog.
Thanks,
Jai. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19378
|
|
Posted: Sat Jan 10, 2015 5:16 am |
|
|
Just use the WDO pin.
The watchdog output _also goes low_, when the supply is low.
Quote from page 7 of the data sheet:
"When the VCC supply drops below the reset threshold, the
WDO output becomes active and goes low independently of
the watchdog timing stage."
You will also see that lot of the example circuits only connect to the WDO output.
The reason it is separate, is that in many cases, you would not want to reset on a watchdog. Instead tidying up the variables, and 're-launching' the software, for a quicker restart than from a full reset. |
|
![](templates/subSilver/images/spacer.gif) |
jaikumar
Joined: 15 Dec 2006 Posts: 109
|
|
Posted: Sat Jan 10, 2015 5:27 am |
|
|
Thanks Ttelmah,
I should have read the datasheet well. Thanks. |
|
![](templates/subSilver/images/spacer.gif) |
jaikumar
Joined: 15 Dec 2006 Posts: 109
|
|
Posted: Sat Jan 10, 2015 5:32 am |
|
|
Ttelmah,
Could you please clarify
Quote: |
The reason it is separate, is that in many cases, you would not want to reset on a watchdog. Instead tidying up the variables, and 're-launching' the software, for a quicker restart than from a full reset.
|
Sometimes when the uC freezes or gets stuck in a loop the Watchdog times out and should it not reset the uC. When the uC freezes it cannot execute or properly function
to do tidying up the variables. |
|
![](templates/subSilver/images/spacer.gif) |
drh
Joined: 12 Jul 2004 Posts: 192 Location: Hemet, California USA
|
|
Posted: Mon Jan 12, 2015 9:20 am |
|
|
Keep in mind that if you connect /WDO to the PIC /MCLR pin -AND- you program the PIC with ICSP, the Vpp voltage will exceed the /WDO maximum. _________________ David |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19378
|
|
Posted: Mon Jan 12, 2015 10:14 am |
|
|
jaikumar wrote: | Ttelmah,
Could you please clarify
Quote: |
The reason it is separate, is that in many cases, you would not want to reset on a watchdog. Instead tidying up the variables, and 're-launching' the software, for a quicker restart than from a full reset.
|
Sometimes when the uC freezes or gets stuck in a loop the Watchdog times out and should it not reset the uC. When the uC freezes it cannot execute or properly function
to do tidying up the variables. |
Chips don't basically stop. The normal failures when running are with cosmic ray hits, or EMI, leading to a random memory content, or jump, which breaks the program flow (or a program error with the same result), or ending up in an unexpected 'sleep' state. So long as the clock is executing, the chip will physically run.
The watchdog, can recover this situation, by calling a NMI routine, which if it is called, assumes the worst, clears the stack, verifies all variables do contain 'legal' values (substituting defaults if they don't), and jumps to the start of the main code loop.
If the routine that actually clears the watchdog, is prevented from ever executing when the code is not following the normal path (so for example, there is a blocking 'return' instruction the instruction in front of the start of the routine, so code cannot 'walk' into the watchdog restart, and then the restart code tests status bits from throughout the normal code execution, before it executes the physical 'restart'), then the watchdog ensures that code is executing as it should. Mine typically is called on a timer basis, and has to see that characters have been received on the serial, have similarly been transmitted, data counts have updated, and all buffer pointers etc., are 'within bounds', before the actual watchdog reset occurs. I've now got some systems now that have been running continuously for over 20 years (I'm waiting for the Flash failures that must occur soon...). |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|