0
\$\begingroup\$

I'm trying to receive data from PIC18F4680's EUSART (using C18 compiler) module and if I type characters in my terminal emulator slow enough, like one or two characters per second, reception works fine. If I try to transmit several characters quickly it seems that reception stops and only device reset solves the problem. Transmission works fine.

The serial port is running at 115200 b/s and and is set-up using following code (clock is 40 MHz):

OpenUSART (USART_TX_INT_OFF & USART_RX_INT_OFF & USART_ASYNCH_MODE &
            USART_EIGHT_BIT & USART_CONT_RX & USART_BRGH_HIGH, f_usart);
//f_usart=86 for 40 MHz, 115200, or 1040 for 9600 (but it doesn't work at 9600)
    baudUSART(BAUD_16_BIT_RATE&BAUD_WAKEUP_OFF&BAUD_AUTO_OFF);

Here's the code I'm using to read from the port:

  if(DataRdyUSART())
  {
      temp=ReadUSART();
      WriteUSART(temp);

  }

This code is in a main loop which does some other processing too and sends out data over serial port. I don't expect this piece of code to work too good (I'm just testing to see if loopback works fine), since there's chance that it will miss some characters (or at least I think so, since a new character may be received before there's a chance for old one to be processed), but I didn't expect it to not work at all.

Interesting thing is that if I enable the Rx interrupt and put the exact same code in the ISR, the data can be received at much greater speed. I need to paste text into terminal window in order to cause the problem.

So any ideas what could be happening?

UPDATE

Looks like I'm getting a mix of framing errors and bit overrun errors. I don't think that I can make the data processing in this case much faster to get rid of the overrun errors, so I'll probably slow down the serial port, but I'm not sure what to do about framing errors.

UPDATE 2

At 9600 b/s, I get much less errors, but still if I copy a wall of text into the terminal, I get errors.

UPDATE 3

Looks like my laptop's USB to serial adapter is transmitting at 9900 b/s. Could that be the cause of the problem? If yes, is there anything I can do on the PIC side to help solve the problem other than setting the data rate at 9900 b/s?

\$\endgroup\$
  • \$\begingroup\$ Why not set the PIC to 9900? Or, why not get the PIC to automatically lock on to the exact baud rate by searching for the rate that produces fewest errors? \$\endgroup\$ – Rocketmagnet Jul 4 '12 at 21:31
  • \$\begingroup\$ @Rocketmagnet Well I could try out the automatic baud rate search. Do you have any examples of how that works? This is for a school project (which is due tomorrow :)) and I'm supposed to program the device for a GPS receiver that sends out data at 9600 b/s. Unfortunately the receiver is unavailable at the moment, so my idea was to demonstrate the operation of my device by capturing data from a mobile phone, sending it over bluetooth to a PC and then from a PC using a serial port to my microcontroller. \$\endgroup\$ – AndrejaKo Jul 4 '12 at 21:39
  • \$\begingroup\$ I doubt I'll have any problems if I set the device to operate at 9900 b/s, but since 9600 b/s is in my project specification, it would be nice if I could have it work on that speed. \$\endgroup\$ – AndrejaKo Jul 4 '12 at 21:39
  • \$\begingroup\$ Well, you'd have to have some way for the PIC to measure the error rate. Just try 9300, 9400, 9500, 9600, 9700, 9800, 9900, 10000. Measure the error rate at each, and pick the best one. Perhaps you could count how many times the PIC sees valid NMEA codes (GGA etc.) in one minute for each baud rate. However, that does mean that it would take 8 minutes to do the search. \$\endgroup\$ – Rocketmagnet Jul 4 '12 at 21:56
  • \$\begingroup\$ Or you could use the capture compare on the PIC to measure the bit times, and calculate the baud rate from that. Much faster, but I'm not sure what the accuracy would be. \$\endgroup\$ – Rocketmagnet Jul 4 '12 at 21:58
1
\$\begingroup\$

I know this is old but might be helpful incase anyone stumbles apon it like I did.

I was having issues with overrun errors in my PIC18F452 communicating to a beaglebone black over USART. With quite a busy program going on in both the beagle and the PIC, there was lots of data being sent between the two constantly. After some amount of time after using the instrument the PIC stopped receiving all messages.

After being stuck and baffled by this for more than 3 weeks, I found this:

http://www.piclist.com/techref/postbot.asp?by=thread&id=%5BPIC%5D+PIC18+UART+stops+receiving&w=body&tgt=post

which described PIC code to handle and clear Overrun Errors:

if(OERR)
{
    do
    {
        temp = RCREG;
        temp = RCREG;
        temp = RCREG;
        CREN = 0;
        CREN = 1;

    } while(OERR);
}

if(FERR)
{
    temp = RCREG;
    TXEN = 0;
    TXEN = 1;
}

Running this snippet every now and then in the PIC program allowed me to recover from occasional overrun errors without restarting the PIC.

Hope that helps anyone with similar issues

\$\endgroup\$
  • \$\begingroup\$ This way you may end up losing important data. Because you basically empty the receipt register without hadling the bytes. \$\endgroup\$ – hypers Aug 13 '17 at 15:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.