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
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...?
For resetting during switch ON, I used an RC network with 10uF and 10K. But today I changed it to a single 0.1uF capacitor connected from Vcc to RESET pin. It works. I expect that this will make some improvement as far as sensitivity to power supply spikes are concerned.
You mean, you've tried it a couple of times on your bench, and you haven't noticed any problems?
That is not anywhere near a sufficient amount of testing to guarantee that it will always work under all conditions of power supplies, noise, etc, etc,...
You should understand this by now: you said you'd already tried it on your bench with no problems, and the problems only arise in the Real World - so it should be obvious that your bench is not a good simulation of the Real World!
The whole purpose of a Supervisor chip is to cope with these kind of Real World situations that don't occur in nice, clean bench tests and are not covered by simplistic RC reset circuits...
You should understand this by now: you said you'd already tried it on your bench with no problems, and the problems only arise in the Real World - We were discussing this as if a program bug. I also thought it is so. I pass this additional details expecting that experienced people may give some useful hints. It is not that I am unaware about new problems that can come in the real world.
For resetting during switch ON, I used an RC network with 10uF and 10K. no wonder your have problems INSTALL A SUPERVISOR CHIP
View all questions in Keil forum