watchdog timer

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I'm trying to implement an interrupt-based watchdog timeout on a mega2560, and I've read the datasheet watchdog section three times and am not sure what I'm doing wrong.

(I'm a relative rookie, so please don't waste any time crafting an answer based on the assumption that I wouldn't have done something obvious and dumb. I have read the datasheet and I am sure I am consistent with it, and when that doesn't work I don't know what else to do but ask you guys the question.)

(Also this might all be 2560 specific -- I don't want you to do any research, just looking for brainstorming ideas from similar efforts on your favorite targets.)

How the watchdog behaves appears to depend on the WDTCSR register and WDTON. In main(), before my infinite loop starts, I've confirmed that I've successfully set

WDTCSR = 0x61 = 0b01100001
= interrupt enabled, system reset disabled
(and others setting the timeout period to a few seconds)

using this code before infinite loop starts (which is cribbed from codewizard)

  // Watchdog Timer initialization
  // Watchdog Timer Prescaler: OSC/1024k
  // Watchdog Timer interrupt: On
  #pragma optsize-
  #asm("wdr")
  //WDTCSR=0x39;
  //WDTCSR=0x69;

  WDTCSR=0x39;
  WDTCSR=0x61;

  #ifdef _OPTIMIZE_SIZE_
  #pragma optsize+
  #endif

and I have an interrupt handler to put the device in a safe state.

but the WDTON fuse has to be 1 for any of this to work. However, as soon as I turn on WDTON, the device seems to seize up, and JTAGing in seems to indicate that it is continually rebooting.

Apparently there is some subtlety to this I'm not getting. Does WDTON interfere with JTAG mode? Even if reset mode is somehow left on (counter to my 0x61 above) shouldn't I get my several seconds rather than an immediate reboot?

Thanks, any thoughts are appreciated.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[full disclsure: I haven't used this particular part but have used the watchdog interrupt on Mega48 & 88]

First, I don't think that you need (or even want?) WDTON to be programmed.

There was a fairly extensive thread on this (again, perhaps not this particular model) a few months ago--try searching it out. IIRC it was in the GCC forum.

Make sure that you have the ISR to catch the event.

For Mega48/88 apps, I ended up just like you--Wizard says 0x39/0x69; I ended up with 0x39/0x61.

[edited to change 0x49 typo to 0x39 above]

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Wed. Sep 3, 2008 - 11:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks.

Really? The datasheet includes WDTON in the table, but will re-read it from that perspective. My interrupt didn't seem to fire w/o it, but will explore that assumption.

Also, why 0x49 instead of 0x39, how did you end up there? As you see I used the same setup value as the wizard. I'll try changing that up...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Also, why 0x49 instead of 0x39,

Because I mis-typed and did not proofread--sorry. :oops: I'll edit the post.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps a cascade as in this thread?
https://www.avrfreaks.net/index.p...

CV prologue turns off the watchdog; I'd need to examine the standard prologue to see how it deals with WDRF.

https://www.avrfreaks.net/index.p...
This is the thread I was thinking of, which has a link to a prior discussion where I posted the 0x39/0x61 code that I know works on Mega48/88. I do not remember how I finally ended up there.
https://www.avrfreaks.net/index.p...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
but the WDTON fuse has to be 1 for any of this to work. However, as soon as I turn on WDTON
If you have WDTON fused on (0), you can't use the wdt irq as it will always be in System Reset Mode (in that table, WDTON-> 1 = off = unprogrammed, 0 = on = programmed). It seems we have 1'/0's/on/off mixed up. I think.

You have ~16ms from reset/power up to change the watchdog, if it takes longer than that to get to that code, you will have to move it so it runs sooner.

You should also clear WDRF on startup (otherwise you may end up in irq+reset mode when you only wanted irq mode). If you are not even using the watchdog, still clear WDRF then turn off the watchdog on startup.

Just a trivia item, but the code generated by the compiler-
WDTCSR=0x39;
is fine, but touching those prescaler bits does nothing, as they cannot change until after WDCE and WDE are set. The actual effect of that instructions is-
WDTCSR=0x18;

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Got it. Agree the prescaler bits are irrelevant on the 0x39 and that it should work. I see my mistake on the WDTON, I should leave that unprogrammed...

However, now simply can't get the interrupt to fire, even though I don't pet the watchdog and the 0x61 is indeed the value of WDTSCR. Reading those threads you guys have provided...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sei ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, they're enabled. This evening was weird, I gave my software to a coworker to work with, with the watchdog pet commented out (which was not a problem because the interrupt wasn't working), and he called me and I walked over and lo and behold his screen said FAULT, WATCHDOG TIMEOUT. Then I went back to my desk to start to figure out the differences between the fuses between the boards and a few minutes later mine was firing too.

All very weird, since I hadn't done a *thing* that could have fixed the problem. I wonder if one of my fuses got out of whack and connecting straightened it out (although WDTON was unprogrammed). Of if there is some interaction between debug mode and this interrupt, and goint *out* of debug mode somehow cleared the problem.

Anyway, it's fixed. Sorry for the anticlimactic resolution. The first half of the problem was WDTON anyway, and you guys straightened me out on that.