Watchdog Timer

[rabhishek91]

Hi everyone.
Today i learnt about watchdog timer in my college and thought of trying it using ATmega32.

My objective is to set watchdog timer condition at 20 seconds (approx.) and light the LED.
Is it possible ? According to the datasheet(attached below) in the Watchdog Timer Prescaler select maximum time-out is 2.2 seconds.
Is it possible to generate timeout at 20 seconds ?

Can i make use some variable to keep track of its time out and then decide ?
Ex- If the variable equal to 10 (i.e 10 time outs ) then light an LED.

Also WDT oscillation cycles are nothing but WDT operating frequency right ?

I am sorry to post lot of questions.Please help.
Thanks in advance.

 

[BobK]

Yep, set it for 2 seconds, and each time it fires, increment a variable, which was initialized to zero. When the variable reaches 10 light the LED.

However, that said, that is it the typical use of the WDT. You could use normal timing techniques for that. The WDT is typically used for 1 of two purposes: to perform a reset if the firmware goes haywire, or to periodically wake up from sleep and perform some action.

Bob

 

[gorgon]

The problem with this is that the watchdog timer is not a normal periodic timer. If it times out, it will reset the mcu, and start the program again. Set to 2.2s it takes 2.2s before the program resets. The whole idea is for your program to reset the watchdog counter at a regular interval, before it reaches this state. If your program failes the reset, the watchfdog will restart the program from the beginning. To reset(or feed) the watchdog you need to do a special instruction or sequence of instructions.

If you want to make a timer circuit you should use a normal timer and set it up to interrupt at a periodic interval(PIT). You can then use these interupts to increment a counter and get your 20second timeout.

 

[rabhishek91]

The problem with this is that the watchdog timer is not a normal periodic timer. If it times out, it will reset the mcu, and start the program again. Set to 2.2s it takes 2.2s before the program resets. The whole idea is for your program to reset the watchdog counter at a regular interval, before it reaches this state. If your program failes the reset, the watchfdog will restart the program from the beginning. To reset(or feed) the watchdog you need to do a special instruction or sequence of instructions.

If you want to make a timer circuit you should use a normal timer and set it up to interrupt at a periodic interval(PIT). You can then use these interupts to increment a counter and get your 20second timeout.

Thanks for your reply sir. I agree you.
Sir is it impossible to set the timeout for more than 2.2 seconds?
The reason i am asking is as per my textbook the same principle is applied in ATM (Automated teller Machine) . But as i am aware of ATM timeout will be around 2 minutes. What improvements/changes are made there ?

 

[rabhishek91]

Yep, set it for 2 seconds, and each time it fires, increment a variable, which was initialized to zero. When the variable reaches 10 light the LED.

However, that said, that is it the typical use of the WDT. You could use normal timing techniques for that. The WDT is typically used for 1 of two purposes: to perform a reset if the firmware goes haywire, or to periodically wake up from sleep and perform some action.

Bob

Thank you .
Sir when the watchdog timer resets the processor, will all the initialized variables be reinitialized?

 

[gorgon]

The reset is equal to a normal warm start and any reset of variable RAM depends on the definitions in your program, I would assume that any variables with values defind in header files will reinitialize. If you initiate variables in your own code, you may test for warmstart/coldstart and keep variables when warmstarting.

 

[rabhishek91]

The reset is equal to a normal warm start and any reset of variable RAM depends on the definitions in your program, I would assume that any variables with values defind in header files will reinitialize. If you initiate variables in your own code, you may test for warmstart/coldstart and keep variables when warmstarting.

Got it sir. Thank you.

 

[BobK]

If you are using C, all variables are likely to be re-initialized. For assembler, not so. In C there should be a way to avoid the re-initialization. You would have to look at your compiler documentation.

But anyway, as both gorgon and I have pointed out, this is a silly use of the watchdog timer, making it more complicated that doing the normal way. So why do you want to do it that way?

Bob

 

[rabhishek91]

If you are using C, all variables are likely to be re-initialized. For assembler, not so. In C there should be a way to avoid the re-initialization. You would have to look at your compiler documentation.

But anyway, as both gorgon and I have pointed out, this is a silly use of the watchdog timer, making it more complicated that doing the normal way. So why do you want to do it that way?

Bob

Yes sir. I'll use the generic timers to implement this.

 

[(*steve*)]

There are ways around this.

I'm sure that if you dig deep into the register and flag settings you'll find something that tells you if a reset was caused by the watchdog, or by an external reset, or by power on, or even by brownout detection.

This is certainly possible with PICs as it is used to implement long delays on the PICaxe, for example.

You can write C to handle this. You simply do not initialize your variables on declaration, but do so in code. Your code could retain the existing values if the restart was from a watchdog event.

The coding is considerably more complex than just using a standard timer and waiting for it to go off a certain number of times.

The watchdog timer is also vastly less accurate.

 

[KrisBlueNZ]

ATM timeout will be around 2 minutes. What improvements/changes are made there ?

The two minute timeout will relate to user input. If the user doesn't enter their PIN or select a transaction, the firmware will time out. This timeout on user action has nothing to do with the watchdog timer. The watchdog timer will typically be set to a much shorter timeout, normally less than one second. Its purpose is to make sure that the firmware has not become stuck in an infinite loop or jumped off into never-neverland (e.g. jumped through an invalid pointer and started executing data as code, or something like that).