I am looking for some help with a problem related to the eCos generic
serial driver and/or Intel PXA26X UART. It's rather baffling or I we are
missing something really obvious - perhaps you can help???????
We have been quite happily using the generic driver and UART to receive
but we are running into problems when transmitting. Sometimes with large
packets (4K) and sometimes small packets (50 bytes), but every once in a
while the Tx just stops. A lot of time has been spent investigating this
problem using eCos kernel instrumentation and the conclusion is somewhat
suprising. It looks like the UART is not always generating an interrupt
when the FIFO is half-empty or less.
The evidence to support this is as follows. We have flow control turned
off and we write a single block of data large enough to fill the BT-UART
buffer exactly. We then wait for this data to be sent by polling the
tx_count of the buffer info. If the data is not sent after 1 second
(plenty of time at 115.2Kb) then we dump the instrumentation log and the
contents of the interrupt and BT-UART regsiters.
The log shows us that we have stopped writing in xmit_char (serial.c) as
the FIFO is full. When this occurrs we should receive an interrupt when
the UART LSR=0x20 (THR/FIFO is ready for more data). What we actually
find is that the LSR=0x60 (both the TSR and the THR/FIFO are empty) but
no interrupt has been generated. Also there is no UART interrupt pending
(ICIP = 0x00000000) yet the IER = 0x5F (all UART interrupts are enabled)
and the interrupt is not masked (ICMR=04700480 and BT-UART is bit 21).
Up until the point of Tx stopping, the number of Tx interrupts raised =
the number of Tx interrupts serviced = the number of Tx DSRs serviced so
we do not appear to have problems servicing the UART interrupts.
So the question is, how can one have:
a) the UART interrupt unmasked, and
b) FIFO Tx interrupts enabled, and
c) the THR and TSR are empty, and
d) no interrupts pending, and
e) serial buffer (IO layer) contains data to be written.