Why pic24fj128ga310 uart not working?

Hi
My question is pic24fj128ga310 uart not working in application, but works with PuTTY.
I'm trying to connect a Microchip PIC24FJ128GA310 mounted on an Explorer 16 board with an embedded wireless module. I have been able to set up both to communicate perfectly well with PuTTY (an equivalent to Hyperterminal), but they won't communicate with each other!

I haven't configured UART for a microcontroller before, but here is my set-up code (which works for PuTTY

RPOR8bits.RP17R = 5; // RP5 as U2TX mapped for peripheral pin select
RPINR19bits.U2RXR = 10; // RP10 as U2RX mapped for selectable input source
U2BRG = 25; // 9600 baud rate
U2MODEbits.UARTEN = 1; // UART2 is enabled
U2MODEbits.ABAUD = 0; // Auto-baud disabled
U2MODEbits.RTSMD = 0; // 0 = Flow Control and 1 = Simplex
U2MODEbits.BRGH = 0; // Low baud rate
U2STAbits.UTXEN = 1; // Transmit enabled
Can anyone help? I have tried both straight-through and null modem cables. The microcontroller is able to show reception of a signal on the U2STAbits.URXDA 'Receive Buffer Data Available bit'.

I can send and receive a string of three character maximum, if flow control and echo settings are the same at both ends, and I terminate the string with '\0'. No hardware is connecting the two except for the RS232 cable and null modem adapter. However I need to reset the microcontroller after each attempt in order for it to show a signal received again. Why do I need to reset it, and why is 3 the maximum number of characters?

When I say it works with PuTTY, I mean that using this equivalent to Hyperterminal I am able to send messages to the microcontroller which are displayed on the Explorer 16 LCD display with no problems (if it echoes the characters received back to PuTTY).
I will be much appreciated for your help!

I've never used the PICs, but I've done tons of UARTs in 8051, ARM, MicroBlaze, and other MCUs. The most common problems getting two UARTs to talk to each other are:

(1) Incorrect baud rate. Make sure both are set for 9600, and if you have a scope, verify the bit time matches 9600 baud. Make sure you have the correct frequency crystal to be able to get close to the desired baud rate. RS-232 is fairly tolerant of frequency offsets, but there is a limit to how far off it can be and still work.

(2) TxD/RxD reversed - the TxD out of one must connect to the RxD in of the other UART. This is sometimes confusing, because each side is called TxD and RxD, from their own perspective. You can always put in a DB9 null-modem adapter (crossover) to swap the RxD/TxD for testing if it doesn't work connected straight together.

(3) Flow control/handshaking - turn it off on both ends to start with. All you need for an RS-232 comm link is three wires - TxD, RxD, and ground. If your application requires flow control, you can add it later, after you get the basic comm link working. Typically, the most common basic slow setup is 9600, n, 8, 1, which is 9600 baud, no parity bit, 8 data bits, and 1 stop bit, so each data byte transmission will require 10 bits to be sent over the serial link.

(4) Improperly-written interrupt service routine on one end. If you don't have your serial ISR set up correctly, it can go off "in the weeds" upon reception of serial data, or get stuck in the ISR. Since you have to reset your micro after each attempt, this could be your problem. Your ISR should push the received databyte into a circular buffer of sufficient size, and then exit back to the main program, which should then have a routine to parse the circular buffer. Do not try to do a bunch of stuff inside the ISR, you can cause problems, like overflowing your stack, or missing data. Get in and get out of the ISR fast, and process your data in the main loop or better yet, in a function called by the main loop.

You should be able to test each end of your comm link independently by sending and receiving data from your computer using Putty or another com program, like TeraTerm. Get each side working separately at the same baud rate, then connect them together.