PIC18F locking up if sending data to quickly

Question

I'm working with a PIC18F and am trying to send data via hyperterminal. When I send data at a slow rate by pressing one key every half secondish it recieves the data and echos it correctly but when I start pressing the keys at a faster rate the MCU locks up. Not sure what causes this.

while(index<length){
    while(PIR1bits.RCIF==0); // Wait till char recieved
    sendData(str2,9); // confirm reception

    Delay1KTCYx(5); //delay because without it, it messes up.
    rxData[index]= RCREG; //char array
    index++;
}

baudrate is 2400 On both PIC and hyperterminal.

This is our receive loop. sendData is just debug code that we send saying "recieved". It's how we know when it has frozen.

It does not freeze at the same amount of loops everytime, it is solely on how fast we input data.

Answer 1

(I did work on MCUs but haven't a deal with PICs, so i'll try to help with common problems)

1. You do not check any receiver error flags. Receiver may lock up in Overrun Error state and do not receive further, until you clear Overrun flag. Add check for error conditions and resolve them accordinly to PIC documentation.

2. Good practice is to read received byte as early, as possible when receive complete is indicated, so try to move rxData[index]= RCREG; imediately after while(PIR1bits.RCIF==0);. This lowers possibility

3. You didn't shown code for sendData. There may be missed checking for TX ready state and error conditions, so it may also lock up.

4. Unmotivated delay indicates that you're already going wrong somewhere. Try to remove it and THEN debug code.

5. You should test your receive and transmit separately. At first, check transmitter: try to output long line of text through UART without any receiving. (Say, write "Hello world!" program:))

6. Check receiver code alone: remove transmission from program, connect LED (voltmeter, oscillosocope, whatever you have) to free GPIO pin, and then make it toggle logic level on it every time it receives a byte. Is it takes only several clock ticks to do, it should not intervene receiving or lockup.

Answer 2

Maybe when you send 2 characters while it is busy sending the "received" one of them is discarded and you never reach your length?

Answer 3

On most microcontrollers, a UART receiver overrun will cause the newly-received byte to be discarded and a flag to be set, but the receiver will continue to operate normally. On the PIC, a receiver overrun will cause the UART to die until the CREN bit is cleared and re-set.