I am at the very first step of trying to make sure I am able to add a debug console, so that when I make changes to the boot code, I can track it. As there is no IDE in place for this project, this might be only way to go about it. The existing project has a Borland compiler and builds and creates the boot hex file using cmdline make builds.
the boot hex and application file are then merged together and loaded on to the target.
I have tried loading the merged hex file without any changes to boot code and it works.(loaded at offset 0x30 0000)
but, after changing the boot code to add uart setup i have only loaded the boot hex file(without merge) at the same address.
Right now I am only dealing with the boot code, and thus have avoided the boot code from launching the application.

Limitations: Using make files to build, no IDE, no breakpoints can be added. Everytime the file is built, the hex file is loaded on the chip and added to target.

Problem : I am trying to just get the UART working with may be a character or a string or anything possible to see on tera term if the first step can take effect and if its feasible. So far with the code below i have not been able to see anything on the tera term or on the oscilloscope.
I realized watchdog (hardware)which exists might be resetting the PIC and thus reconfigured the port to which watchdog is connected and tried to toggle it using software. Seems like it doesnt work too. I cannot see a toggle on the scope at this pin.

Question: 1. Could someone throw light on how feasible the method sounds? Or am I heading right direction?
2. Would merge with application and not merging be a factor?

It's a great pleasure to know that 50 years in one business might just be helpful to a new generation. It also occurs to me that invading the boot code is still possible after you get everything else working.

Your inputs have also motivated me to be frank. I have got the first two steps up and running was able to print out hello world in a loop.
I just read your 3rd step3.Then put out fixed strings with CR-LF characters after a lines' worth of information

Good question! CR is an abbreviation for Carriage Return, and LF is an abbreviation for Line Feed. The origin of these two ASCII characters comes from an era where keyboard input and printing machines resembled typewriters.
CR = 0x0D and LF = 0x0A

On that note, As you already know I am trying to shrink the boot code. I have few questions:-
1.Would it be necessary to add the circular buffers and interrupts to RX and TX?
2. Or would it suffice to just keep something printed in a while loop and then try and make changes to the boot code?

That is actually a tough question to answer. It is the classic tradeoff between performance and availability of resources. The reason for the interrupts and circular buffers is to avoid "busy waiting". If you can construct your code in such a way that you always have other things to do when the UART transmitter is busy, then you can avoid using the Tx interrupt. The Rx interrupt is more problematical because you don't want to miss incoming characters from the keyboard. This means that all your processing tasks must be executable in less time than the fastest possible arrival time of key strokes. An average typist can hit 60 wpm and a really good one can hit 115 wpm.

Yes, thats true. But i do not need to reciev something typed from keyboard. The main goal is to reduce the memory occupied by the code and optimize it. I am thinking what would cut down the code size to create some space/manage memory.