Zynq UART Transmitter Not Sending Data until 2nd message Received

[mrelko]

I am running into a problem where the UART does not send out a responce to an incoming message until it gets a second incoming message.  This causes the responce to the message to be delayed once and ultimatly is throwing off my PC app.  In the attached image, you see two messages sent to the Zynq (yellow bytes) before the Transmitter sends the first responce (white bytes).  No matter what interrupt manipulation I use, it is always delayed until the 2nd message comes in.  I posted a capture of how it is supposed to look, from our current system.  Could this be how I have the UART set up?  I will post that at the very bottom of the thread also. 

Here is how I have the interrupt handler configured.  

void UART_int_Handler(void *CallBackRef, u32 Event,
		unsigned int ByteCount)
{
	switch (Event) {

	case XUARTPS_EVENT_RECV_TOUT:
		break;

	case XUARTPS_EVENT_RECV_DATA: {
		XUartPs_Recv(&uartPtr, &incomingChar, 1); //Receive a byte
		tl_get((BYTE)incomingChar);  //Process on the byte and store it in a buffer
		break;  //The interrupt will fire again until the message is obtained
	}

	case XUARTPS_EVENT_SENT_DATA:
		tl_put(); //This sends data out byte by byte
		break;

	default:
		break;

	}
}

#define UART_IXR_MASK  (XUARTPS_IXR_RXOVR | XUARTPS_IXR_TXEMPTY)

uartConfig = XUartPs_LookupConfig(XPAR_PS7_UART_1_DEVICE_ID);
XUartPs_CfgInitialize(&uartPtr, uartConfig, uartConfig->BaseAddress);
XUartPs_SetBaudRate(&uartPtr, 19200);
setupIntr();
XUartPs_SetHandler(&uartPtr, UART_int_Handler, (void*) &uartPtr);
XUartPs_SetInterruptMask(&uartPtr, UART_IXR_MASK);
XUartPs_SetOperMode(&uartPtr, XUARTPS_OPER_MODE_NORMAL);

[mrelko · Accepted solution]

For some reason, the interrupt was not going off until 20 bytes were recieved.  I set the RX threshold to 1, and things work as expected.  

[muzaffer]

You realize that by setting the threshold to 1 you are going to incur an interrupt every byte which is a large overhead and you are completely ignoring the existence of the fifo. Why don't you set it to a higher number and read that many bytes so that you can get fewer interrupts? If your system is not loaded threshold of 1 might work but you are wasting a lot of bandwidth and when your system gets loaded, you might drop bytes that way.