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.
Dear Sir, I am having a problem with at89s52 on power up. I am doing a project which demands serial communication via serial port. I have gone through one of the threads here, where you had advised one Mr.Bhagirath to use 3-pin rest(MX810). So, I get it that the problem MAY BE in reset button. But, I would also like to share with you the fact that earlier I did not have any arrangement for reset, then it never misbehaved. So, what are the other areas from where this anomaly is rising?
"So, what are the other areas from where this anomaly is rising?"
What anomaly?
If you have a reset issue, it affects the processor - not just the UART.
If you have just a serial link issue, it is not a reset issue unless you also have some bug in your code.
Thank you so much sir for those helping words. There is no bug in the code for sure. The anomaly I am talking about is that AT89S52 does'nt start recieving 8bit data immediately on power up. But this does not happen always. Sometimes, it works perfectly on power up with no problem whatsoever. So, what can be other sources of this anomaly. What if I do not use reset arrangement at all for this AT89S52? Will this fix my problem?
The anomaly I am talking about is that AT89S52 does'nt start recieving 8bit data immediately on power up does it start at all? after how long?
What if I do not use reset arrangement at all for this AT89S52? Will this fix my problem? why do you think specifications are published?
Erik
Hardly any processor can start receiving 8-bit data immediately on power up. The software normally have to set up baudrate etc for the UART to know what is expected.
Another thing is the state of the line when the UART gets activated - a character that is sent before the UART is ready will be lost. So two processors can't be powered up and expected to be able to directly talk with each other. First off, there should be a bit of delay so both are in ready state before communication is activated. But the communication protocol should also support resends if it is important that no transfer is missing. How can one side ever know the other side is ready if there isn't hw or sw handshaking between them?
But a correct reset solution is vital - lots of state in the processor that needs to be normalized. That also includes the interrupt state machines etc. Some of the states can't be corrected by the software.
Thank you Per Westermark for those helping words. I get your point. So, what you are basically saying is that problem that I have mentioned may be arising due to my inconsistent reset arrangement.If this is so, then reset is the first problem that I shall work on. At the same time,would you please suggest whether I am skipping any other useful information /point required to solve this problem?
Thank you Mr.Malund. "does it start at all? after how long?" yes, when it starts, it starts immediately without any problem and performs serial communication. However, sometimes it starts working after 5mins to 7mins.
"why do you think specifications are published?" what specifications are you talking about, sir?
Sir, I would like to tell you that initially when I had no reset arrangement, AT89S52 started serial communication without this timing delay or this anomaly at all. That is why , I have asked whether I should use reset arrangement at all.
"why do you think specifications are published?" what specifications are you talking about, sir? e.g. the specifications of reset in the datasheet AND the rest of them, spcifications are tere for a purpose, not for your reading enjoyment.
Ok, got your point. I shall do as you have said. Thank you very very much for giving me your valuable time, Mr.Malund.
Do you have a timer running other than the serial setup? The fact that something times out in 5 to 7 minutes sounds like a timer not being initialized correctly and after timer overflow the system appears to run.
Just a far out guess on my part.
Bradford
since the OP is not a believer in a proper "reset arrangement" I hold it far more likely that the uC is running garbage as 'code' and, somehow, after a lot of time, something manages to get it going properly.
No, Sir, I do not have any timer code in my program.I have tried a code that lights up a LED after 30secs and dims it after another 30secs(blinky), but even this UC does not start functioning properly on power up. It starts functioning after 1to 2 mins even thought there is no timer code associated.Could you tell me what is going wrong?
Mr.Malund, I shall not argue that I never believed in proper reset arrangement but thank you, Sir, that you have made me a bliever in it. Sir, the only thing I am asking is that in case after providing the proper reset arrangement, the problem still persists, what should be my next step ?
the only thing I am asking is that in case after providing the proper reset arrangement, the problem still persists, what should be my next step ? with a proper reset supervisor chip, there will be no next step.
kkjkkkvjchsj,gft
Can you post the code you are running? It might help demonstrate the issue. For instance, if you have an extended delay that you assumed was in ms but is actually in seconds, it's possible we could randomly guess this but it would save a lot of time to see the code you are working with. Please remember to use the "pre" tags when posting code (should be described above the text box when posting a reply).