lpcware

Continuous UART Character Timeout Interrupts (CTI) but not characters in FIFO

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Mar 15, 2018 by Robert Hulsebos
Content originally posted in LPCWare by gregd on Thu Apr 09 09:51:02 MST 2015
There appears to be a problem with the UART driver in LPCOpen version 2_12, 2_16 and probably previous versions also.

This problem was seen on the LPC4350 but also seems to be occurring on other LPC microcontrollers according to internet searches.  See the following link for info:
http://www.embeddedrelated.com/showthread/lpc2000/24824.php

There seems to be a condition with the LPC4350 (and other LPC microcontrollers) where you can receive Character Timeout Interrupts (CTI) even when there are no characters in the receive FIFO.  This causes a continuous repeated interrupt which appears to lock up the application with the LPCOpen code.

Here are the details of what is happening:

A UARTx_IRQ is triggered.
The LPC_USARTx->IIR register indicates a UART_IIR_INTID_CTI interrupt.
The Chip_UART_IRQRBHandler function calls Chip_UART_RXIntHandlerRB.
Chip_UART_RXIntHandlerRB calls Chip_UART_ReadLineStatus but the UART_LSR_RDR bit is not set so Chip_UART_ReadByte is not called, this results in the CTI flag never being cleared.  The interrupt is continuously triggers as soon as it exits the handler and never allows normal application execution.

The solution presented in internet link above, always reads a character from the FIFO even if the RDR bit is not set in the line status register so that the CTI interrupt is cleared.  This seems to solve the problem but I have a concern with the logic:

1) Read the line status register into a variable.
2) Read character from the FIFO into a variable (even if RDR is not set so that CTI is cleared).
3) If the RDR flag is set in the line status variable then the saved character is processed (stored in the ring buffer etc...) and we go back to step 1 and repeat to empty FIFO.
4) If the RDR flag was not set then exit the loop.

My concern is what would happen if a character is actually received in the UART and written to the FIFO between steps 1 and 2 above.  The character would be missed and not processed since the RDR flag was not set when read in stop 1.


Are there any suggestions for solving this problem?  LPCOpen needs to be modified to fix this issue as well. I believe the interrupt and blocking versions of the UART driver in LPCOpen all have this same problem.


Thanks,
Greg Dunn





Outcomes