This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

sci overrun error

Other Parts Discussed in Thread: TMS5701224

Hi,

 

I'm using the TMS5701224 for uart communication with a DSP.  I am trying to run the comms in polling mode, and it works, but only for a bit before I get an over run error.

 

Basically I wait and want to read 2 bytes of a message from the DSP, if they are #J, then I read 4 more bytes, a message length and a checksum.  Then I read the number of bytes the length indicates.

 

This works for a while, but eventually I get an overrun error. If I understand it correctly, that means that there is data in the receive buffer I haven't read yet that is going to be over written with new data.  Does it mean that I am just not reading the receive buffer quick enough?  We have another program that doesn't seem to have this issue, but it uses interrupt mode.  Is there an advantage over interrupt mode over polling from a speed point of view?  The program I am writing doesn't have an RTOS, so I thought polling mode would be simpler and work OK.

 

I have also had a check on sciIsRxReady, but it doesn't have an affect (although I should probably check anyway).

 

Does it sound like I am doing something wrong?  or any suggestions on how to overcome the overrun error?

 

My program flow is something like this:

while(1)
{
   sciError = sciRxError(sciREG);

   if(sciError == 0)
   {

	length = 2;
	sciReceive(sciREG, length, bytes);

	if (((bytes[0] & 0xFF) == '#') && ((bytes[1] & 0xFF) == 'J'))
	{
		msgOK = readMessage((uint32 *)&dspCmd, NUM_PARAMS_MAX + 3);
	}
	else
	{
		msgOK = FALSE;
	}

	if (msgOK)
	{
	         // act on msg
	         parseStatus = parseMsg(&dspCmd, &dspRsp);

	        //format and send response back to DSP
		sendResponse(&dspRsp);

		msgOK = FALSE;
	}

      }
}

 

Thanks,

David

  • Hello David,

    Using interrupts would be preferred so that you do not spend all the bandwidth polling for the receive data.

    If you are getting SCI Overrun set then its sure that the hardware had overwritten the receive buffer with new data before the older data was read by you.

    Any reason for you to not use interrupts ?
  • Hi,

     

    The application is a bootloader, so if it needs to flash the main app there is nothing else going on, it is just sitting waiting for a message, then flashes the appropriate memory, then waits for the next message until it is told it is done.  Since there is nothing else going on in the application I thought it would be quicker to implement using the polling method than to get the program set up to have the proper flow using interrupts.  Right not though, I am not doing any flashing, as soon as a message is read in I create a response and send it, so I'm surprised that it isn't able to keep up.

     

    I'm working on setting up a state machine with the interrupts now to see if that helps the issue.

     

    Thanks,

    David

  • David,

    Yeah I see why you are on to polling.

    But please check the baud rate in which you are receiving the data and the frequency at which you are running the device. Apparently if you are ending up with Overrun then you are spending more time in processing the received data before you go poll for the next.
  • Thanks.

    We have a main application that runs (same baud rate, frequency, etc) that has a lot more processing that it does and it doesn't see the error, so I am surprised that the minimal bootloader is seeing the error. Hopefully switching to interrupt mode fixes it.

    David
  • Hi,

    I switched to interrupt mode and saw the same behavior. It seems to be related to once the DSP starts multitasking, and there isn't anything inherently wrong with the communication mechanism because I can blast messages out in a while(1) before multitasking starts and I don't see any errors.
  • David,

    Thanks for confirming that. If your issue is solved, pls close this thread. Thanks.