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.
Not necessarily "square", but that's (probably) not important.
"In such case running an infinite loop without updating the internal watchdog timer will not cause a reset"
Incorrect: if the internal watchdog is properly enabled, it will cause a reset when it is not updated for any reason.
So, as noted previously, if your program is in a loop, and the wathdog is not causing a reset, there are two possible reasons:
1. The watchdog is not properly enabled;
2. Your software is updating the Watchdog - despite being stuck in a loop.
The benefit of an external watchdog is that No 1 cannot happen.
But updating an external watchdog from ALE most certanily will cause No 2!
if the internal watchdog is properly enabled, it will cause a reset when it is not updated for any reason. What I said is both the external and internal watchdogs to be used together to handle such situations. -internal to avoid running in an infinite loop and external to handle the situation where the program is not at all running and internal WDT not running.
Why complicate the issue?
IF you have an external watchdog, why not let it handle both situations?
"handle the situation where the program is not at all running"
Do you have any reason to suspect that this is actually happening in your case?
Yes. May be due to voltage spikes the program stops. After doing some additional filtering, this problems seems to be solved. But still I wanted to take an extra precaution.