Please read the steps wt the top of page 116 and page 118 of the data sheet. The UART on these devices must be configured in the correct order. WHle it is possible to set al of the bits in the various registers at the same time, I prefer to set the various configuration bits and then the 'enable' bits in the correct order - I have never had an issue with the UARTs doing this.
I assume that you will be using the 'baudRate' parameter in the 'UART_Init' function at some time in the future.
Your 'str' function is rather strange - again I assume this is test code.
The logic behind your functions to read and write strings will work (up to a point) with the tests you are using now, but will cause you all sorts of problems later on. For example, the external device will response with "OK\r\n" (typically) but you tell 'UART_Read_Text' to only read 2 characters. The external device will continue to send characters after the "OK" and the UART Rx hardware will process them but, because you are not reading them, will generate an "OERR" error and ignore all following characters that are received until the bit is cleared in your software. While you do check for the OERR error, it is not clear exactly what values can be read from the RCREG in this situation.
Although it is a bit more advanced, I would recommend that you use interrupts on the Rx side and save the characters into a ring buffer. Also you need to expect and process line termination characters. Further when you are looking for a specific response ("OK\r\n" i this case) you need to be ready to handle other characters that might be (erroneously) received.
I see that you are blocking the main loop for 3 seconds as you flash the LED - while this is not wrong, especially in the early stages of testing, it will exacerbate any problems with extraneous characters being received. Again, using a ring buffer to receive the UART characters will avoid this issue.
Susan