Watchdog Timer

#include<p18f458.h>
#define data PORTD
#define rs PORTBbits.RB0
#define rw PORTBbits.RB1
#define en PORTBbits.RB2
void lcdcmd(unsigned char);
void lcddata(unsigned char);
void d(unsigned int);
void main()
{
TRISB=0;
TRISD=0;
en=0;
lcdcmd(0x38);
d(250);
lcdcmd(0x0E);
d(250);
lcdcmd(0x01);
d(255);
lcdcmd(0x80);
d(15);
lcddata('#');

}
void lcdcmd(unsigned char value)
{
data=value;
rs=0;
rw=0;
en=1;
d(1);
en=0;
}
void lcddata(unsigned char value)
{
data=value;
rs=1;
rw=0;
en=1;
d(1);
en=0;
}
void d(unsigned int t)
{
unsigned int i,j;
for(i=0;i<t;i++);
for(j=0;j<64;j++);
}

this is my program ...can anyone tell me what mistake made watchdog timer to reset?

Maybe there is an assemble instruction required to refresh or turn off the watchdog.
you probably need to refer to the data for your specific microcontroller/microprocessor.
E.g for the z86 micros which I mostly use the assember instruction 'wdt' needs to be included in the main program loop (or any long loops) to avoid reset. E.G i have a program which sits waiting to be interrupted by a timer interupt 64 times a second. In the timer_interrupt routine I include a wdt command.

BTW, I've had a very brief look at the program, I have no idea what it does, but it seems to just run straight through main and falls out the bottom, in which case it will be rescued by the watchdog. A flow chart would be easier to follow.

As an example, the program I mentioned perviously has a 'main' which basically says
while (1)
{
}
So it just sits in a loop forever being interrupted by the time which is where the real progam does the work.
Del

Guest,

From the first two statements in the main function, i.e.

TRISB=0;
TRISD=0;

it seems that the varriables TRISB and TRISD are not defined anywhere in the code - unless they are defined somewhere in the <p18f458.h> header file; in which case it be required of you to tell us what these varriables are about. Most standard IDEs (integrated development environments) should be able to forewarn about undefined varribales, unless your executing the code right away without any kind of IDE compiling / debbuging.

Otherwise, it might be a good idea to tell this forum what the code you have given is supposed to do. It is only then that thorough analyses of your code can be meaningfully done. Sometimes those non-terminating loops (referred to as infinte loops) can result from the kind arguments that are passed to functions, even though they may not syntactically be existent in the code.

So, please, enlighten us on what your code is supposed to do.

starmodi

Watchdog timers can provide seamless recovery from otherwise crippling events, like a static discharge, that scramble the program counter and possibly i/o port configurations.

http://ww1.microchip.com/downloads/en/DeviceDoc/41159e.pdf

page 285

Where is the "clrwdt" statement in your listing?

WARNING: Overuse of clrwdt statements by beginners is a good way to spend months debugging strange problems. Good code structure requires only a few strategically placed clrwdt statements.

I just don't have the patience to be a good teacher. Why make the effort when no one can be bothered to RTFM which supplies most if not all the answers

Since this looks like a homework subject, I give you an F-

As previous poster says .. RTFM.

You are not enabling the watchdog, using the watchdog or have any use for a watchdog. Without a loop a watchdog is less than useless.

Timing loops in software vary depending on everything else the processor has to do. Watchdog timers can provide an exact time interval independent of what the program is doing.

Well, if memory serves me - basically it's another way to 'interrupt' the system through hardware rather than software. This is usually reserved for 'protection' to the system, or can be used for other things too.

The system will 'save' current system state and then move to the 'watchdog' state and start executing pre-programmed software; although there are some defaults that the system may do such as a system reset... Although exact spec's for WatchDog systems vary from uC to uC and from uP to uP...

Apparently in newer systems they'll use the watchdog timer to keep the system from 'failure' by many ways such as hardware and software failures, etc. As someone mentioned, look up the specifications for your uP or uC's watchdog functions! :)

The watchdog is basically a method of ensuring your program is running as it should. Every now and then you have to 'kick the dog' within your program code, otherwise the dog will kick you and your program crashes.

If you can't be bothered with all this dog-kicking, disable the w-dog by clearing the appropriate configuration bit (refer to datasheet).

As you well know, the watchdog timer needs to be reset by the program, before it times out and resets the processor. Simple an easily said, but this hides several pitfalls that you can fall into!!

If you set your watchdog timer too short, you may end up with "race conditions" when servicing an interrupt (or two, that you had not thought about!!) for example.

You therefore need to set your WDtimer as long as possible to give the processor ALWAYS plenty of time to service it before it times out. Only you know just how long that you can allow your processor to "hang" without giving serious other problems. Often its far far longer than you thought of at first!!

While testing, I would suggest that as part of the resetting of the watchdog timer, you should display the (real) time taken since the last resetting on a PC or LCD display, continuosly.......

Adding extra code to a program that previously worked just fine is a common method to start getting WDTimer errors!!!

Knowing the length of time the watchdog timer is actually set for and looking at the time taken displayed will quickly show you if something needs to be adjusted......or not!!! Years ago, using basic, I traced my programs to see which parts were taking the longest to execute in a similar manner......

For very high speed applications, this method may simply be too slow to work correctly though, my application were real world(ly) and relatively slow in operation......

I have often programmed without doing a proper design first and had just such problems through my own stupidity.....once I draw my (flawed) logic out on paper, my errors were more easily found!!!