We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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.
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
Erik
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...?