AVR-Chat

OK

That makes sense.  So really, there is an 'early strobe' exception by way of the WDT expecting a periodic reset.

The WDT must then measure the time between resets.

So the WDT causes a reset for two conditions:
1.  Not being reset before his timeout
2.  Having a non-periodic time between resets.

Thanks Jim.


--- In AVR-Chat@yahoogroups.com, Jim Wagner  wrote:

>
> This is exactly the same. The code has to periodically reset the WDT when it is running. If your code DOES NOT reset it, the WDT will eventually time out. You do not have to reset it to start it. 
> 
> You can enable/disable the WDT and you can set the time in large increments. Enable/disable is fairly complex to keep from accidentally resetting it in "runaway" code. You can read the MCUSR on startup to see if that was the cause of the reset, though that is a bit tricky in C. Rhe avrlibc manual may describe how to do that.
> 
> Jim Wagner
> Oregon Research Electronics
> 
> On Jan 12, 2013, at 8:55 AM, englsprogeny1 wrote:
> 
> > Thanks Jim.
> > 
> > Using an endless loop is sufficient for verifying my WDT implementation.
> > 
> > A follow on question. 
> > 
> > I just read the ATMega16 datasheet to see that the WDT has to be serviced before it times out. OK, of course...
> > 
> > On other WD Timers that I've worked with, there was also an 'early strobe' error. So, if you didn't service the WDT ONCE within a certain window you would get an exception. 
> > 
> > Know what I mean?
> > 
> > So you service (reset) the WDT. This resets the timer. The timer starts counting. There is a +- window around the WDT timeout where you must reset the WDT. If you service outside of this window (early or late) you get an exception.
> > 
> > Is it OK to reset the WDT early? The datasheet says nothing about early strobes.
> > 
> > Thanks!
> > 
> > --- In AVR-Chat@yahoogroups.com, Jim Wagner wrote:
> > >
> > > The only "crash" of any significance is the endless loop. You look for an I2C peripheral thats not there? That is just an error and the code flows on. Same with virtually everything else. So why not a simple endless loop? 
> > > 
> > > You COULD call a function and purposefully corrupt the stack so that it does not return properly. Might crash or might not. Why not endless loop?
> > > 
> > > Jim Wagner
> > > Oregon Research Electronics
> > > 
> > > On Jan 12, 2013, at 7:35 AM, englsprogeny1 wrote:
> > > 
> > > > Using an AtMega16, I am going to make use of the watchdog Timer.
> > > > 
> > > > I want to cause a crash to verify that the WDT brings us back to life.
> > > > 
> > > > Instead of going into an infinite loop "crash" I'd like to cause something more catastrophic. I tried a divide by zero scenario but we don't crash (even without the WDT implemented). It is as if the compiler 'optimized' this (divide by zero) line out.
> > > > 
> > > > How can I cause a good catastrophic crash (like divide by zero)?
> > > > 
> > > > Keep in mind that I don't want cause the catastrophic crash by using 300VDC for my source voltage, as this is very difficult to recover from.
> > > > 
> > > > :)
> > > > 
> > > > Thanks Guys!
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > > [Non-text portions of this message have been removed]
> > >
> > 
> > 
> 
> 
> 
> [Non-text portions of this message have been removed]
>

Nothing about "non-periodic". Here is how it works:

1. WDT timer is reset
2. WDT timer counts
If the WDt timer is reset before the count overflows, go back to 2. If the timer overflows, it resets. 

So the ONLY criterion is that the timer is reset before it overflows from the previous reset.

Jim Wagner

On Jan 12, 2013, at 9:19 AM, englsprogeny1 wrote:

> 
> OK
> 
> That makes sense. So really, there is an 'early strobe' exception by way of the WDT expecting a periodic reset.
> 
> The WDT must then measure the time between resets.
> 
> So the WDT causes a reset for two conditions:
> 1. Not being reset before his timeout
> 2. Having a non-periodic time between resets.
> 
> Thanks Jim.
> 
> --- In AVR-Chat@yahoogroups.com, Jim Wagner wrote:
> >
> > This is exactly the same. The code has to periodically reset the WDT when it is running. If your code DOES NOT reset it, the WDT will eventually time out. You do not have to reset it to start it. 
> > 
> > You can enable/disable the WDT and you can set the time in large increments. Enable/disable is fairly complex to keep from accidentally resetting it in "runaway" code. You can read the MCUSR on startup to see if that was the cause of the reset, though that is a bit tricky in C. Rhe avrlibc manual may describe how to do that.
> > 
> > Jim Wagner
> > Oregon Research Electronics
> > 
> > On Jan 12, 2013, at 8:55 AM, englsprogeny1 wrote:
> > 
> > > Thanks Jim.
> > > 
> > > Using an endless loop is sufficient for verifying my WDT implementation.
> > > 
> > > A follow on question. 
> > > 
> > > I just read the ATMega16 datasheet to see that the WDT has to be serviced before it times out. OK, of course...
> > > 
> > > On other WD Timers that I've worked with, there was also an 'early strobe' error. So, if you didn't service the WDT ONCE within a certain window you would get an exception. 
> > > 
> > > Know what I mean?
> > > 
> > > So you service (reset) the WDT. This resets the timer. The timer starts counting. There is a +- window around the WDT timeout where you must reset the WDT. If you service outside of this window (early or late) you get an exception.
> > > 
> > > Is it OK to reset the WDT early? The datasheet says nothing about early strobes.
> > > 
> > > Thanks!
> > > 
> > > --- In AVR-Chat@yahoogroups.com, Jim Wagner wrote:
> > > >
> > > > The only "crash" of any significance is the endless loop. You look for an I2C peripheral thats not there? That is just an error and the code flows on. Same with virtually everything else. So why not a simple endless loop? 
> > > > 
> > > > You COULD call a function and purposefully corrupt the stack so that it does not return properly. Might crash or might not. Why not endless loop?
> > > > 
> > > > Jim Wagner
> > > > Oregon Research Electronics
> > > > 
> > > > On Jan 12, 2013, at 7:35 AM, englsprogeny1 wrote:
> > > > 
> > > > > Using an AtMega16, I am going to make use of the watchdog Timer.
> > > > > 
> > > > > I want to cause a crash to verify that the WDT brings us back to life.
> > > > > 
> > > > > Instead of going into an infinite loop "crash" I'd like to cause something more catastrophic. I tried a divide by zero scenario but we don't crash (even without the WDT implemented). It is as if the compiler 'optimized' this (divide by zero) line out.
> > > > > 
> > > > > How can I cause a good catastrophic crash (like divide by zero)?
> > > > > 
> > > > > Keep in mind that I don't want cause the catastrophic crash by using 300VDC for my source voltage, as this is very difficult to recover from.
> > > > > 
> > > > > :)
> > > > > 
> > > > > Thanks Guys!
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > [Non-text portions of this message have been removed]
> > > >
> > > 
> > > 
> > 
> > 
> > 
> > [Non-text portions of this message have been removed]
> >
> 
> 



[Non-text portions of this message have been removed]