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.
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
Erik
Normally what among the below can happen with a spike in RESET pin OR any other pin 1)uC will go to default condition (in this case all O/P high) and remain like that 2)The program will stop and remain where it was before hang up. 3) Result is totally unpredictable.
In my case my observation is that it goes to condition 1. Is it a mere coincidence OR has it got some meaning?
.. that with a RC reset you WILL get 'mysterious' errors on spikes.
When are you going to add that supervisor???
For the units already installed, there is some difficulty in adding a new IC. I will definitely add the supervisor circuit in the next unit onwards. However I am trying to get the supervisor IC and try to implement in the present unit also.
you can get a 'tripod' (a supervisor chip in a 'transistor package') such as DS1233 datasheets.maxim-ic.com/.../DS1233.pdf which can easily be added to an existing board.
NOTE!!!! do not know if the reset poarity of the DS1233 and your chip match DO CHECK. If they do not, there are other 'tripods' that do.
Thank you very much
I tried supervisor IC DS1232. Working well.It has got a watchdog also which is monitoring the ALE pin of my uC. I think, still it is better to use the internal watchdog also to avoid program getting stuck due to software issues. Am I right?
Am I right?
Quite the contrary. Using an external watchdog monitor guarantees correct behavior, once it is configured.
So, as long as the processor keeps accessing external memory - eg, fetching instructions - the watchdog will not fire.
Does that really sound like a good idea to you?!
Quite the contrary. Using an external watchdog monitor guarantees correct behavior, once it is configured. I thought there will be a square waveform at ALE pin as long as the program is running. In such case running an infinite loop without updating the internal watchdog timer will not cause a rest unless the internal watchdog is also used. Is it not true?
I don't use an external memory. This is as per the application circuit given in the data sheet of DS1232. Is it not true that monitoring the ALE pin is enough to confirm whether the program is running?
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!