Sriharsha Vedurmudi wrote:
-------------------------------
First:
MOV TCON,#00h was intentionally given so that the timer does not start until all other initializations are over. Later in the code you can find the start of the timer using SETB TR1

As Craig stated, we don't see that in the code you posted. However, I do see "SETB SCON.6". Perhaps you meant "SETB TCON.6", which is equivalent to "SETB TR1".

Second:
CLR TR1 in the ISR will only get executed when all the characters in the Transmission line (STR) are over. Once all the bytes are transferred, the transmission should stop, so I stopped the TR1.

Yes, sorry, I saw that after my original post. However, it's a little out of the ordinary to stop the baud clock after transmitting unless after doing so, you are going to then use Timer1 for something else entirely. If you ever implement receive functions too, then stopping the baud clock is bad.

Probably the most valid reason not to turn off the baud clock the way you are doing it is because TI becomes set after serial shift hardware has emitted the last data bit. At this point the stop bit has not been emitted yet and turning off the baud clock could prevent the stop bit from being emitted. If the MSB of the byte you were transmitting was a zero (quite likely for ASCII characters), then you've just introduced a framing error on the serial line.

Third:
RETI is written in the ISP. From the ISP I used a JUMP instruction and to return back I used RET. Is it not correct? I mean,a jump statements destination cant be used as a function?

If you ever add any code to run in the background while your interrupt-driven transmit is running, make sure to consider adding processor context save and restore code to your ISR.