Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Thread

Cause a crash

Cause a crash

2013-01-12 by englsprogeny1

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!

Re: Cause a crash

2013-01-12 by englsprogeny1

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:
Show quoted textHide quoted text
>
> 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]
>

Re: [AVR-Chat] Cause a crash

2013-01-12 by Jim Wagner

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]

Re: [AVR-Chat] Cause a crash

2013-01-12 by Jim Wagner

It can be argued, quite strongly, actually, that an endless loop is the ONLY error that the WDT handles. Nothing else "triggers" the WDT.

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]

Re: [AVR-Chat] Re: Cause a crash

2013-01-12 by Jim Wagner

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]

RE: [AVR-Chat] Re: Cause a crash

2013-01-29 by Phillip Vogel

Just to satisfy my curiosity, what chip has a watchdog timer with an "early strobe" exception? I've never encountered that in my (possibly flawed) recollection of my past 35 years of doing this stuff. It would be pretty annoying to have to keep track of the more-or-less time since the last WDT strobe, and to do so from a timer interrupt service is a bad idea, since even if your main code has run amuck, the interrupts may be working fine.

So that raises the question: "When do YOU service the WDT?" I'm sure there are plenty of opinions on the subject, and it's more than likely that some are better than mine. 

For the record, I wrote code that never crashes :-) But seriously, folks, I generally service the WDT as part of the main loop, and set the WDT timeout to the longest value practicable depending on the application. For a non-critical, hand-held instrument, nobody's gonna die if the thing hangs for half a second. On the other hand, a machine tool controller that's gone to sleep for that same half-second may have done thousands of dollars' worth of damage. So, it depends...

But of course, all this is moot since my stuff never, ever crashes.
Show quoted textHide quoted text
> -----Original Message-----
> From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
> Of englsprogeny1
> Sent: Saturday, January 12, 2013 11:55 AM
> To: AVR-Chat@yahoogroups.com
> Subject: [AVR-Chat] Re: Cause a crash
> 
> 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]
> >
> 
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>

Re: [AVR-Chat] Re: Cause a crash

2013-01-29 by Philippe Habib

I can't answer about the early strobe, never having seen that either, but on some medical stuff that I've worked on the FDA did not allow the WDT to be part of the micro.  They demanded an external WDT wired to the reset line. 

Of course, mine never triggered either.
Show quoted textHide quoted text
----- Original Message -----
From: "Phillip Vogel" <phillip@bartal.com>
To: AVR-Chat@yahoogroups.com
Sent: Monday, January 28, 2013 10:16:00 PM
Subject: RE: [AVR-Chat] Re: Cause a crash

Just to satisfy my curiosity, what chip has a watchdog timer with an "early strobe" exception? I've never encountered that in my (possibly flawed) recollection of my past 35 years of doing this stuff. It would be pretty annoying to have to keep track of the more-or-less time since the last WDT strobe, and to do so from a timer interrupt service is a bad idea, since even if your main code has run amuck, the interrupts may be working fine.

So that raises the question: "When do YOU service the WDT?" I'm sure there are plenty of opinions on the subject, and it's more than likely that some are better than mine. 

For the record, I wrote code that never crashes :-) But seriously, folks, I generally service the WDT as part of the main loop, and set the WDT timeout to the longest value practicable depending on the application. For a non-critical, hand-held instrument, nobody's gonna die if the thing hangs for half a second. On the other hand, a machine tool controller that's gone to sleep for that same half-second may have done thousands of dollars' worth of damage. So, it depends...

But of course, all this is moot since my stuff never, ever crashes.

> -----Original Message-----
> From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
> Of englsprogeny1
> Sent: Saturday, January 12, 2013 11:55 AM
> To: AVR-Chat@yahoogroups.com
> Subject: [AVR-Chat] Re: Cause a crash
> 
> 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]
> >
> 
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 




------------------------------------

Yahoo! Groups Links

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.