This turned out to be a (non-NXP) hardware problem that had some tricky
timing...sorry for the false alarm.
--- In l..., "Tom Tang" wrote: >
> Is it possible that it's nothing to do with UART, but
> a spurious interrupt or nesting interrupt issue?
> There are several NXP appnotes about how to deal with
> these interrupts.
>
> regards,
> Tom
>
> --- In l..., "dave_albert" wrote:
> >
> > I am using the LPC2368 and have reproduced this problem several times:
> >
> > In my application, there is a serial console for debugging on UART0. The
application is working normally, periodically sending a status message out TXD0
when suddenly, often in the middle of a message, no more characters come out
TXD0. My board has two interfaces (UART0 and an RF interface) so I'm able
to query it via the RF interface.
> >
> > It turns out U0LSR is stuck at 0x20 (THRE set but TEMT bit not set); it
stays that way permanently until I reset the processor. The UART still receives
characters just fine...I can send serial commands to the application via RXD0
and the commands are received and processed (as evidenced by LEDs and output on
the RF interface). U0IER=0x07, U0IIR=0xC1, U0TER=0x80 (the transmitter is
enabled).
> >
> > As far as I know, it should not be possible for UART0 TEMT to remain clear
while the UART is powered and otherwise functioning as its function is entirely
performed in hardware. Is this another race condition where if you read U0LSR
while it is being updated (e.g. while TEMT is being cleared), the update fails?
There is nothing in the errata about it. Is this a known issue? Is there a
workaround?
> >
> > NXP Apps - help please!
>
Is it possible that it's nothing to do with UART, but
a spurious interrupt or nesting interrupt issue?
There are several NXP appnotes about how to deal with
these interrupts.
regards,
Tom
--- In l..., "dave_albert" wrote: >
> I am using the LPC2368 and have reproduced this problem several times:
>
> In my application, there is a serial console for debugging on UART0. The
application is working normally, periodically sending a status message out TXD0
when suddenly, often in the middle of a message, no more characters come out
TXD0. My board has two interfaces (UART0 and an RF interface) so I'm able
to query it via the RF interface.
>
> It turns out U0LSR is stuck at 0x20 (THRE set but TEMT bit not set); it stays
that way permanently until I reset the processor. The UART still receives
characters just fine...I can send serial commands to the application via RXD0
and the commands are received and processed (as evidenced by LEDs and output on
the RF interface). U0IER=0x07, U0IIR=0xC1, U0TER=0x80 (the transmitter is
enabled).
>
> As far as I know, it should not be possible for UART0 TEMT to remain clear
while the UART is powered and otherwise functioning as its function is entirely
performed in hardware. Is this another race condition where if you read U0LSR
while it is being updated (e.g. while TEMT is being cleared), the update fails?
There is nothing in the errata about it. Is this a known issue? Is there a
workaround?
>
> NXP Apps - help please!
>
Reply by dave_albert●February 23, 20122012-02-23
I am using the LPC2368 and have reproduced this problem several times:
In my application, there is a serial console for debugging on UART0. The
application is working normally, periodically sending a status message out TXD0
when suddenly, often in the middle of a message, no more characters come out
TXD0. My board has two interfaces (UART0 and an RF interface) so I'm able
to query it via the RF interface.
It turns out U0LSR is stuck at 0x20 (THRE set but TEMT bit not set); it stays
that way permanently until I reset the processor. The UART still receives
characters just fine...I can send serial commands to the application via RXD0
and the commands are received and processed (as evidenced by LEDs and output on
the RF interface). U0IER=0x07, U0IIR=0xC1, U0TER=0x80 (the transmitter is
enabled).
As far as I know, it should not be possible for UART0 TEMT to remain clear while
the UART is powered and otherwise functioning as its function is entirely
performed in hardware. Is this another race condition where if you read U0LSR
while it is being updated (e.g. while TEMT is being cleared), the update fails?
There is nothing in the errata about it. Is this a known issue? Is there a
workaround?