Cannot Set Watchdog Timer WDP Bits

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

I wanted a longer delay (4 or 8 s) for the Watchdog, using a ISR but with no reset.

The WDTON fuse is cleared on the ATMega328p.

 

Following the 328p datasheet example (p 53) for altering the prescaler just does not work. I've tried many other combinations without success. The WDP bits remain cleared, and the timeout remains at 16ms.

 

The commented out line, which includes

0<<WDCE 

was due to the advice on p51 of the datasheet:

The sequence for clearing WDE and
changing time-out configuration is as follows:
1. In the same operation, write a logic one to the Watchdog change enable bit (WDCE) and
WDE. A logic one must be written to WDE regardless of the previous value of the WDE
bit.
2. Within the next four clock cycles, write the WDE and Watchdog prescaler bits (WDP) as
desired, but with the WDCE bit cleared. This must be done in one operation.

 

However Atmels code example did not explicitly clear WDCE, and it makes no difference anyway. The WDP bits remain cleared, regardless.

 

 sei(); // enable interrupts

 MCUSR &= ~(1<<WDRF);// Clear WDRF in MCUSR
 cli(); // disable interrupts

 wdt_reset();

WDTCSR |= (1<<WDCE) | (1<<WDE);
WDTCSR = (1<<WDIE) |(1<<WDE) | (1<<WDP2) | (1<<WDP0);
//WDTCSR = (0<<WDCE) |  (1<<WDIE) |(1<<WDE) | (1<<WDP2) | (1<<WDP0); 
sei();
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hate it when this happens.

 

A short while after posting, that thing with 'Within the next four clock cycles' rang a bell.

I had optimisation set to none - so debugwire breakpoints work correctly. When I set it to optimise then the WDP bits were set correctly and have got a 8s timeoutyes

 

Maybe a way round, so it will work with optimise set to none would be to do the WDT stuff in asm.

 

Apologies for this.

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

No-one in their right mind would debug with -O0.

If you are determined to use -O0 then use <avr/wdt.h> facilities.

 

Of course,   if you enjoy gobbledygook,   by all means use ASM.

 

David.

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

david.prentice wrote:

No-one in their right mind would debug with -O0.

If you are determined to use -O0 then use <avr/wdt.h> facilities.

 

Of course,   if you enjoy gobbledygook,   by all means use ASM.

 

David.

 

I cannot use wdt.h since that does not support ISR's (just resets).

 

I would think no one in the right mind would debug with debugwire without using -00. The breakpoints just don't work correctly.

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

I would think no one in the right mind would debug with debugwire without using -00.

IMO/IME, results of a "debug" session at -O0 are meaningless, as any "real" app will operate differently when not -O0.  IMO/IME, the breakpoint-setting situation, while annoying at times, can be handled.  Yes, sometimes a section of generated code needs to be examined.

 

Re WDT and interrupt-only mode and GCC and wdt.h:  There is a very recent thread on this.  Now, the thread is about Tiny24 and diversion to Tiny25 families, which are indeed a hair different than '48 family.  However, the links to past discussions go tho thread that deal with that family.

 

[One of my old bosses used to say that "RS232" stood for "2 wires connected 32 different ways".  When WD interrupt came out, figuring how to set up for the different modes, and safety levels, was like that.]

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: Sun. Dec 28, 2014 - 03:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If one wants to read the asm, do not use -O0 .

It can be bloated to the point that it is hard to read.

If neither -Os , -O2 nor -O3 works for you, try -O1 .
 

 

Iluvatar is the better part of Valar.

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

If all you want is the interrupt, you don't need to set WDE.  If you do, you will be enabling interrupt-and-reset mode.

In the datasheet, Atmel wrote:
The third mode, Interrupt and System Reset mode, combines the other two modes by first giving an interrupt and then switch to System Reset mode.

.

.

.

• Bit 6 – WDIE: Watchdog Interrupt Enable
When this bit is written to one and the I-bit in the Status Register is set, the Watchdog Interrupt is enabled. If WDE is cleared in combination with this setting, the Watchdog Timer is in Interrupt Mode, and the corresponding interrupt is executed if time-out in the Watchdog Timer occurs. If WDE is set, the Watchdog Timer is in Interrupt and System Reset Mode. The first time-out in the Watchdog Timer will set WDIF. Executing the corresponding interrupt vector will clear WDIE  and WDIF automatically by hardware (the Watchdog goes to System Reset Mode).

 

You want interrupt-only mode:

 

WDTCSR = (1<<WDCE) | (1<<WDE);
WDTCSR = (1<<WDIE) | (1<<WDP2) | (1<<WDP0);

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sun. Dec 28, 2014 - 11:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

If all you want is the interrupt, you don't need to set WDE.  If you do, you will be enabling interrupt-and-reset mode.

 

 

Thanks ... Had been setting WDIE in the ISR to deal with the reset.

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

theusch wrote:

I would think no one in the right mind would debug with debugwire without using -00.

IMO/IME, results of a "debug" session at -O0 are meaningless, as any "real" app will operate differently when not -O0.  IMO/IME, the breakpoint-setting situation, while annoying at times, can be handled.  Yes, sometimes a section of generated code needs to be examined.

 

Re WDT and interrupt-only mode and GCC and wdt.h:  There is a very recent thread on this.  Now, the thread is about Tiny24 and diversion to Tiny25 families, which are indeed a hair different than '48 family.  However, the links to past discussions go tho thread that deal with that family.

 

[One of my old bosses used to say that "RS232" stood for "2 wires connected 32 different ways".  When WD interrupt came out, figuring how to set up for the different modes, and safety levels, was like that.]

 

When I first started using DebugWire (about 6 months ago), went though a bad time with the breakpoints. Whenever an O1 was used the breakpoints would not set; well they would set  but as soon as DW finished writing to the chip all breakpoints disabled and could not be hit.

Atmel suggested setting Optimisation to None and to try again. It worked and from then on have used -OO.

 

Anyway have just tried again with Optimisation set (O1 and Os) and now the breakpoints do work. So please disregard the 'Can only debug with -OO nonsense', and thank for the heads up. Also to david.prentice.