UARTRxFifo Overruns


#1

with Q24PL I use UART2 to communicate serial device. the baud rate is 115200bps. I use UART1 to connect to TMT for debug.
Sometimes I will see this trace : “UART v24 UartRxFifo Overruns 1”. If this trace repeat for a few times module will reset.
Does anybody know the cause ?


#2

I just got the same issue, only not in RTE mode.

I kept getting a module reset and kept adding UART output to check variable states etc.
The more I added, the less I saw.

So, to reproduce, call startUARTfloodTimer() once at startup:

//////////////////////////////////////////////////////////
/*
If baudrate is low, crashes very soon and not as much output is shown.
If baudrate is high, crashes later, and more output is shown.
*/
void floodTimer(u8 id)
{
int i = 0;

UNSOUT("This is the flood timer. Some counter to generate text with: %d", i++);    
UNSOUT("This is the flood timer. Some counter to generate text with: %d", i++);    
UNSOUT("This is the flood timer. Some counter to generate text with: %d", i++);    
UNSOUT("This is the flood timer. Some counter to generate text with: %d", i++);    
UNSOUT("This is the flood timer. Some counter to generate text with: %d", i++);    
UNSOUT("This is the flood timer. Some counter to generate text with: %d", i++);    
UNSOUT("This is the flood timer. Some counter to generate text with: %d", i++);    

startUARTfloodTimer();

}

void startUARTfloodTimer(void)
{
adl_tmrSubscribe(FALSE, 2, ADL_TMR_TYPE_TICK, floodTimer);
}

//////////////////////////////////////////////////////////

“UNSOUT” is just adl response sent as unsolicited type.

I suppose the solution is simply to ensure you never overfill the UART buffer. This is not a hardware flow control issue, but a flow control issue internal to the module, perhaps just to the OS firmware.

Does anybody know of a way of preventing this in a nice clean manner, or at least checking the UART buffer state and then dropping output?
I have not tried outputting via the FCM yet, but suppose the same will happen.


#3

Terribly sorry, but for some reason the example above seems to work…
It’s when you use %f formats for you sprintfs that things go bad - in fact, using %f is discouraged by Wavecom somewhere. However, my original app still crashes and there is no %f anywhere. I suppose that there is just something else wrong…