MSP430FR5969: When using back channel UART do I have to pull uo the tx or rx line ?

UCA0 is the Backchannel (only) by virtue of being connected to the host via the RXD/TXD jumpers on the Bridge (J13) header on the Launchpad. I'm supposing you've removed those jumpers in order to connect your RS485 circuit.

I expect you would want a pullup on the MCU RXD pin, so it isn't susceptible to noise while disconnected. Since the TXD pin is always driven by the MCU, I think you don't need one there. I somewhat randomly picked an RS485 transceiver chip (THVD1449) and its datasheet (SLLSF79B, Section 9.2.2) suggests a 10k pullup on both R and /RE. (It also suggests a pulldown on DE.)

My observation (from reading the Forum) is that the most common RS485 data-integrity mistake is forgetting to wait until the final Tx byte is clocked out before switching DE (UCA0STATW:UCBUSY==0).

I am directly using the MSP430FR5969 IC. When I observed the Tx Pin it is low. Its not being driven high. 

If the UART is active (UCSWRST=0) I expect to see that TXD is (driven) high. How are you measuring?

Data sheet (SLAS704G) Table 6-52 says that to use UCA0 on P2.0/.1 you need PSEL=10 (P2SEL1.x=1, P2SEL0.x=0). 

The USCI can't drive RS485 directly. Can you describe your RS485 circuit?

I checked using a multimeter when no communication was happening. Saw that the Tx was low and rx high.

Also what i do this

1. USB to RS485

2. RS485 to TTL

The transceiver I use is an auto direction control THVD1406

Don't forget about RS485 termination.

I kept termination resistors but st some point the MCU stops responding one by one. Say I have 3 MCUs. Then as I poll over them continuously one by one stops responding at random times and all together stops. Why do you think that happens ?

I have no idea why. But something that worries me is that auto direction control. It has a very short timeout.

For all but the highest bit rates, the transmitter is going to turn off in the middle of a one bit. Now that particular part has receiver thresholds that are OK with that since the termination resistors will bring the line back to zero volts. Hopefully the other RS485 transceivers are similar.

I also assume that you have a ground connection to control common mode voltage.

I went through through the hardware once again and theres something I missed out. The USB to RS485 i use is manufactured by Waveshare and it comes with Hardware automatic control. So I was thinking maybe this direction control conflicts with the Transceivers direction control at some point ? 

Only if two try to transmit at the same time. Depending on the protocol you are using, that may or may not be possible.

The Waveshare device appears to be based on the FT232 which I have used for RS485 with no trouble. (It provides a signal which is perfect for RS485 transmitter control.) The RS485 chip mentioned on the other hand is a problem. Its receiver thresholds are not compatible with your automatic direction control. With the transmitter disabled, the line voltage will fall into that -200mV to +200mV indeterminate region. Not good.

This will require failsafe termination.

I am not using just the IC I am using the USB to RS485 converter itself.

I was trying all known possible debugging and did something as in open the serial port -> Clear the input output buffers ->  Perform some action -> Close the serial port for every call in the infinite loop. When I do this there is no issues encountered for some time.

When only opened the port -> Perform some action -> Close the port again some devices did not respond as in some calls to the device missed to respond if we skip that call when error encountered the next call will be successful. Over time only one device stops responding completely.