PIC Self Hard Reset

[hantto]

Hi, would this kind of reset circuitry work?

By taking RE0 low it would trigger the 555 and give a 1second pulse to Q5 wich in turn pulls MCLR to GND.

 

[checkmate]

The circuit looks fine. But the question is what is the purpose of resetting the pic in intervals? If you are worried that the pic may hang after some time, there is always the watchdog timer.

 

[Nigel Goodwin]

Hi, would this kind of reset circuitry work?

By taking RE0 low it would trigger the 555 and give a 1second pulse to Q5 wich in turn pulls MCLR to GND.

I've not studied your exact circuit, so can't comment on that, but certainly the principle is fine.

You could use a similar technique as an external watchdog timer?, by wiring the 555 as a one-shot monostable, and using a transistor connected to an I/O pin (via a capacitor) to discharge the timing capacitor. The PIC has to output a pulse to the transistor BEFORE the 555 times out and resets it, if the PIC is locked up in some way it won't supply the pulse and the 555 will timeout reseting the PIC.

This technique is quite common in TV's and VCR's! - although not usually using a 555 or a PIC!.

 

[hantto]

I've got my reasons.

I have always found the WDT to be a strange thing and have not completely understood what it is for. And the datasheet doesn't give much information about it (under a page). Where could I find aditional information about the WDT?

 

[Nigel Goodwin]

I have always found the WDT to be a strange thing and have not completely understood what it is for. And the datasheet doesn't give much information about it (under a page). Where could I find aditional information about the WDT?

There's not much information to worry about!.

The WDT is quite simple, it's an internal circuit which will reset the PIC after a certain time (maximum about 2.3 seconds if I remember correctly?). So in your program you insert 'CLRWDT' instructions that reset the WDT and prevent it timing out. The idea being that if the PIC gets locked in an endless loop then the WDT will reset it and restart the program. This obviously depends on there NOT being a CLRWDT in the endless loop it's stuck in, or it won't ever time out - you need to consider this in the writing of your program.

For a simple example, something like this:

Main
    call Subroutine1
    clrwdt
    call Subroutine2
    clrwdt
    call Subroutine3
    clrwdt
goto Main

If either of the three subroutines take longer then the WDT timeout, then the PIC will reset - obviously you need to ensure that this is not normally the case!.

 

[hantto]

Ok! Thanks. I think that's about enough to get me started :lol:

 

[hantto]

One question tough, if the WDT resets the PIC, does it have EXACTLY the same effect as externaly reseting the PIC would have?

 

[Exo]

why do you need the 555? You can use RE0 to pull MCLR down directly...
If you need a 1second delay or something just do that in software...

 

[Exo]

One question tough, if the WDT resets the PIC, does it have EXACTLY the same effect as externaly reseting the PIC would have?

Yes, except for a couple of flags (check datasheer). There's a register that your program can use to determine the pic was reset normally or by watchdog...

 

[Nigel Goodwin]

why do you need the 555? You can use RE0 to pull MCLR down directly...
If you need a 1second delay or something just do that in software...

You can't do a 1 second delay in software, as soon as MCLR goes LOW the PIC stops running, then as it goes high again it starts running from a full hardware reset.

For Hanto:

A WDT reset isn't EXACTLY the same as a full hardware reset, you have the option of detecting which it was and acting accordingly. You should also be aware of different actions following a WDT reset after a SLEEP instruction, some more modern PIC's carry on from where the SLEEP was initiated, older PIC's do a standard WDT reset.

 

[checkmate]

Mind sharing your reasons?
Because for whatever reason you have, chances are that there are betters ways to achieve the same effect.

 

[Exo]

why do you need the 555? You can use RE0 to pull MCLR down directly...
If you need a 1second delay or something just do that in software...

You can't do a 1 second delay in software, as soon as MCLR goes LOW the PIC stops running, then as it goes high again it starts running from a full hardware reset.

I know that...
What i mean is whatever you want to do with that external 1second delay reset, you can do it in software too...

program a timer delay to set a flag (or interrupts) after 1 second, once that flag is set pull MCLR low directly with RE0...
while the timer is running you can still do processing ...

perhaps more information about what this supposed to be doing in the context of the project could come in handy...

 

[Nigel Goodwin]

What i mean is whatever you want to do with that external 1second delay reset, you can do it in software too...

I presumed that the delay was to initiate a clean reset?, although a full 1 second isn't required - and personally I'd probably try just a simple capacitor from I/O pin to MCLR, rather than the complexity of a 555.

 

[Exo]

It doesnt really matter what he had in mind does it?

Eighter he wants a 1 second delay between the point in the program where the reset is triggered and the actual reset - wich can be handled in software like i explained above.

Or he wants to use the 555 to extend his reset pulse to be 1second long - This isnt required, just connecting an output pin right to MCLR is enough to pull it low and do a reset.

You can all do it directly...

 

[hantto]

My reasons are many small ones that merge into a bigger picture that makes me want to use a 555 :lol:

Thanks for all help.

 

[GraveYard_Killer]

before i had done something like that the pic will go a hard reset. i used a simple transistor switching on the MCLR pin with base of transistor in one of PICs pin.