Hi, I use AT89S52 in a project. I send and receive data through TXD, RXD pins to a GSM module for sending SMS to another mobile equipment. I use watchdog facility and the watchdog counter is reset at every 256 counts. My crystal frequency is 11.0592 MHz. It happens once in a while that the uC doesn't respond and remains as if it hangs. Then it has to be RESET again. I doubt whether it happens while serial data reception and sending happens simultaneously. I wrote the program in C using KEIL IDE. My questions are 1) What are the special precautions to be taken in this case?(sending and receiving simultaneously) 2)why this happens even when the watchdog is active? It will be highly appreciated if anybody can give some guidance.
Firstly, how are you sure that the Watchdog is active?
Even if it is active, all a Watchdog does is to cause a reset if it is not "updated" within its timeout.
If your Watchdog "update" scheme is flawed such that "updates" can occur even when the program is "stuck" - that will obviously allow this to happen.
See: www.8052.com/.../173972 www.8052.com/.../174030 www.8052.com/.../174042
I use watchdog facility and the watchdog counter is reset at every 256 counts.
sounds like a watchdog update in a timer ISR which makes that watchdog TOTALLY useless
Erik
"makes that watchdog TOTALLY useless" Can you kindly elaborate this point or suggest some reading material to understand this point? A processor can go far astray and still have the timers running, thus feeding the WD in a timer ISR will make the watchdog NOT bite even if the code run astray.
Useful information. Thank you
I have moved the watchdog reset from timer ISR to the main program and did the update frequently . I checked and confirmed that systems gets reset if update is note done in time. But with this also I noticed that my program got stuck after two days of actual use(I had to switch the power ON and OFF to start again). What does this mean? Does this mean that the watchdog counter also stops counting under certain conditions. Can anybody please give some suggestion on how to handle this problem.
Do you understand why it was a bad idea to have it in a timer ISR in the first place?
If you haven't fully grasped that yet, then you (probably) haven't fully understood the requirements for using a watchdog effectively!
Perhaps you could give a detailed explanation of why you think it's a bad idea - then people may be able to spot if there's anything you're missing..
"...to the main program and did the update frequently"
So what, exactly, do you mean by "frequently" here?
"my program got stuck after two days of actual use"
So you still haven't got the watchdog right yet!
Again, the two possibilities are:
1. The watchdog is somehow getting disabled;
2. Your watchdog update scheme is flawed so that it can keep the watchdog running despite the program being stuck in a loop!
So you still haven't got the watchdog right yet! Again, the two possibilities are:
1. The watchdog is somehow getting disabled; 2. Your watchdog update scheme is flawed so that it can keep the watchdog running despite the program being stuck in a loop! 3 while the WD is now fed in the main it is still fed in the ISR as well. 4) the updated code is not what is in the chip
Not a C51 guy, but is it possible that only the "watchdog reset bit" was disabled (assuming that like in a LPC2400, the watchdog cannot be disabled once started) as some point ?
Because in that case the watchdog will get updated even when the program is stuck as the timer interrupt may work well in that condition also. Is it right? Another possibility ,I think, is that the program is stuck in some loop where the watchdog getting updated without causing a reset. Now I am tracing my program for that possibility. 1. The watchdog is somehow getting disabled; Is there any such possibility once the watchdog is enabled?
Do you think that I am moving in the right direction?
No. I think you would be better turning off the watchdog and concentrating on fixing the bug(s) in your code.
Fixing bugs may be the ideal thing. But what is wrong in using watchdog? What is it meant for?
no, it is not. The watchdog is not there to 'fix' code glitches, it is there to (among other things) detect them so they can bbe fixed.
It's not just "ideal" - it's the only thing!
You have (at least) two bugs that you need to fix:
1. You program has a bug in it which causes it to hang.
2. Your watchdog scheme has a bug in it which fails to "catch" bug No 1.
"what is wrong in using watchdog?"
Nothing wrong is using it per se - but you need to understand that it is not a substitute for fixing the bugs that cause watchdog resets!
"What is it meant for?"
Obviously, your program should never get itself into a situation where it is "stuck", and the only way to recover is a power-cycle. If it does ever get into such a state, then that indicates that there is a bug which needs to be fixed.
The purpose of a watchdog is to allow the system to escape from such a "lock-up" if it should ever occur.
The Datasheet for the specific processor will tell you that.
Obviously, your program should never get itself into a situation where it is "stuck", and the only way to recover is a power-cycle. If it does ever get into such a state, then that indicates that there is a bug which needs to be fixed. There are situations where a watchdog hit MAY not require added attention such as a lightning strike nearby that makes everything electric jump.
One more thing I noticed is that when the program get stuck, most of the time all the O/P pins goes high. This is not a condition the program can reach normally. Has this got any indication? Does it mean than it is not a normal program hanging?
O/P pins goes high
Is this the default situation after a reset...?
No
Must be a different AT89S52 to the one I've used.
Assuming Jack Sprat is right (and I tend to believe he is) then your chip could be resetting and failing to start up properly - hence, your program does not get stuck at all during normal operation. It fails, "getting stuck" in the aftermath of a reset or in a failure handler (again, not being a C51 guy I cannot elaborate). Have you ever consider to actually debug this instead of shooting blanks? Ever considered adding a tiny trace buffer to track your program behavior etc.? Your situation is indeed hopeless, and it shall remain so unless you decide to do something to change it.
this could explain why the watchdog has no effect - maybe your program does not even get the chance to configure it during startup after the failure...?
Or it could be that the watchdog did have the desired effect of resetting the processor, but the processor then hangs somewhere before the app starts.
Maybe there's a power supply glitch - is there a proper supervisor circuit in the system?
I couldn't clearly understand what is meant by default situation after reset. I thought whether my program makes all the O/P pins high initially. For that I said no since I make some low during initialization.
This seems to be very valid. My equipment works in a noisy (electrical noise) environment. I also think that the noise pick ups in the power supply may be coming to the reset pin and causing error. With RESET high all the O/P pins go high. Is it possible that a spike on the reset pin can cause all pins go to high state and remain like that? If so, can you suggest some solution for that? What do you mean by proper supervisor circuit?
I couldn't clearly understand what is meant by default situation after reset RTFDS all SFRs have their 'reset state' defined there. If not change manufacturer.
Yes. All O/P pins high is the default situation.
The equipment has been continuously working for the last two months. But it hanged 4 OR 5 times when I had to power OFF and ON .
All O/P pins high is the default situation.
All O/P pins high at reset
this thread has been going on for a long time and it is time for "exotic guesses"
one such would be that you hang on a non-initialized variable that by sheer coincidence happens to be good when the processor powers up (memory at power on is random) and makes you hang when a WD reset happens (where the memory contents are preserved).
1)It never went to a hang situation while switching ON. 2)It never went to such situation when tested in my place (actual working condition is electrically noisy) 3) I initialized all variables. Do you think that spikes in suply line OR RESET pin can cause similar situation?
OP: I think he might be suggesting you are using an uninitialised variable somewhere in your code. But I'm not too sure.
2)It never went to such situation when tested in my place (actual working condition is electrically noisy)
the methods to handle noise sensitivity are described here www.8052.com/.../119926
CLEARLY you have TWO problems a) you are noise sensitive b) you either miss a supervisor or your WD is handled wrong.
Yes!
That is precisely why a large variety of Supervisor circuits is widely available from a number of manufacturers...
Many of these also include a hardware watchdog...
You're not using an RC reset generator, are you...?
View all questions in Keil forum