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 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.
Erik
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.
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.