Reply by Robert Adsett October 17, 20082008-10-17
mlcchemtrac wrote:
> I have gone so far as to reinitialize the UART after every
> transmission, this has not helped. The only solution I have found is
> to do a hardware reset or cycle the power, this is not acceptable to
> our customers.
>
> I have not been able to find anything in documentation regarding this
> problem.
>
> Has anyone had experience with this type problem?

DO you have the FIFO enabled?

Robert

An Engineer's Guide to the LPC2100 Series

Reply by Mike Harrison October 17, 20082008-10-17
On Fri, 17 Oct 2008 19:39:38 -0000, you wrote:

>--- In l..., Michael Coffee wrote:
>>
>> Noltstein
>>
>> Thanks for the reply. I have poked around in the interrupt routine.
> When this occurs no interrupt is generated and no data appears in the
>receive register.

Do you have the Line Status Interrupt enabled ?

Reply by Michael Freeman October 17, 20082008-10-17
Michael,
What kind if ESD protection do you have? The NXP LPCxxxx io pads will
latchup at 6~7Volts and a power down is needed to reset the SCRs.

Hope this helps,
Michael Freeman
Principal Design Engineer
Update Systems, Inc.

-----Original Message-----
From: l... [mailto:l...]On Behalf Of
mlcchemtrac
Sent: Friday, October 17, 2008 11:01 AM
To: l...
Subject: [lpc2000] LPC2148 UART0 failure to receive
We need to be able to disconnect and reconnect our serial
communications without causing a system upset.

Here is the kicker... The UART operates correctly, RS232 9600 baud.
However, when the RS232 cable is disconnected then at some later time
reconnected the UART will not receive any data. I have scoped the
signal through the MAX3232 and it looks as I expect.

In my code the processor is transmitting data at regular intervals
regardless of the RS232 connection. When the RS232 cable is
reconnected this data comes through OK.

I have gone so far as to reinitialize the UART after every
transmission, this has not helped. The only solution I have found is
to do a hardware reset or cycle the power, this is not acceptable to
our customers.

I have not been able to find anything in documentation regarding this
problem.

Has anyone had experience with this type problem?

By the way, has NXP technical support been abducted. They certainly
have become scarce.

Michael,


Reply by jsm09a October 17, 20082008-10-17
--- In l..., Michael Coffee wrote:
>
> Noltstein
>
> Thanks for the reply. I have poked around in the interrupt routine.
When this occurs no interrupt is generated and no data appears in the
receive register. An interesting thing happens after reconnecting the
cable. After transmitting data a character receive timeout occurs. I
have not been able to see any sign of a received character and there
is no data ready flag.
>
> Mike and JC thanks also for the input. I have double checked that I
am clearing everything. I have looked at the uart.c code, and other
code examples, I see nothing that I have not done or tried. This is
not an isolated case, I have the same situation on 5 working prototypes.
>
> Michael

Things to try/check ...

- ALWAYS read LSR first on any non-transmit interrupt
(including CTI)
- If RDA or CTI, always read RBR
- ALWAYS write to VicVectAddress before leaving ISR

Reply by Michael Coffee October 17, 20082008-10-17
Noltstein

Thanks for the reply. I have poked around in the interrupt routine. When this occurs no interrupt is generated and no data appears in the receive register. An interesting thing happens after reconnecting the cable. After transmitting data a character receive timeout occurs. I have not been able to see any sign of a received character and there is no data ready flag.

Mike and JC thanks also for the input. I have double checked that I am clearing everything. I have looked at the uart.c code, and other code examples, I see nothing that I have not done or tried. This is not an isolated case, I have the same situation on 5 working prototypes.

Michael

----- Original Message ----
From: noltstein
To: l...
Sent: Friday, October 17, 2008 12:58:13 PM
Subject: [lpc2000] Re: LPC2148 UART0 failure to receive
--- In lpc2000@yahoogroups .com, "mlcchemtrac" wrote:
>
> We need to be able to disconnect and reconnect our serial
> communications without causing a system upset.
>
> Here is the kicker... The UART operates correctly, RS232 9600 baud.
> However, when the RS232 cable is disconnected then at some later time
> reconnected the UART will not receive any data. I have scoped the
> signal through the MAX3232 and it looks as I expect.

Have you spent any time poking around in your UART ISR?

It could be that the cable disconnect/connect introduces a parity
error / framing error / BREAK condition that you previously never
encountered, and that leg of code in the ISR is going wonky.

I've seen this exact kind of thing happen before. Just a thought...

__________________________________________________


Reply by "J.C. Wren" October 17, 20082008-10-17
You may want to look at the interrupt handler in the LPC2148 demo code
at http://jcwren.com/arm (uart/uart0.c). In another product I use it
in, I increment an error counter for errors, and indeed it increments
as it should for parity and framing errors. I suspect nolstein is
right about what's biting you.

--jc

On Fri, Oct 17, 2008 at 12:58 PM, noltstein wrote:
> --- In l..., "mlcchemtrac" wrote:
>>
>> We need to be able to disconnect and reconnect our serial
>> communications without causing a system upset.
>>
>> Here is the kicker... The UART operates correctly, RS232 9600 baud.
>> However, when the RS232 cable is disconnected then at some later time
>> reconnected the UART will not receive any data. I have scoped the
>> signal through the MAX3232 and it looks as I expect.
>
> Have you spent any time poking around in your UART ISR?
>
> It could be that the cable disconnect/connect introduces a parity
> error / framing error / BREAK condition that you previously never
> encountered, and that leg of code in the ISR is going wonky.
>
> I've seen this exact kind of thing happen before. Just a thought...

Reply by Mike Harrison October 17, 20082008-10-17
On Fri, 17 Oct 2008 16:58:13 -0000, you wrote:

>--- In l..., "mlcchemtrac" wrote:
>>
>> We need to be able to disconnect and reconnect our serial
>> communications without causing a system upset.
>>
>> Here is the kicker... The UART operates correctly, RS232 9600 baud.
>> However, when the RS232 cable is disconnected then at some later time
>> reconnected the UART will not receive any data. I have scoped the
>> signal through the MAX3232 and it looks as I expect.
>
>Have you spent any time poking around in your UART ISR?
>
>It could be that the cable disconnect/connect introduces a parity
>error / framing error / BREAK condition that you previously never
>encountered, and that leg of code in the ISR is going wonky.
>
>I've seen this exact kind of thing happen before. Just a thought...
>

I'd agree - chances are you are not clearing the UDR when you get a framing (or maybe overrun) error
so it just sits there waiting forever. Look at UxLSR in your debugger once it has got into this
state.

Reply by noltstein October 17, 20082008-10-17
--- In l..., "mlcchemtrac" wrote:
>
> We need to be able to disconnect and reconnect our serial
> communications without causing a system upset.
>
> Here is the kicker... The UART operates correctly, RS232 9600 baud.
> However, when the RS232 cable is disconnected then at some later time
> reconnected the UART will not receive any data. I have scoped the
> signal through the MAX3232 and it looks as I expect.

Have you spent any time poking around in your UART ISR?

It could be that the cable disconnect/connect introduces a parity
error / framing error / BREAK condition that you previously never
encountered, and that leg of code in the ISR is going wonky.

I've seen this exact kind of thing happen before. Just a thought...
Reply by Michael Coffee October 17, 20082008-10-17
JC
I am using 3 wire connection.

Yes I do have to detect the data and change setup or send specific data.

Michael

----- Original Message ----
From: J.C. Wren
To: l...
Sent: Friday, October 17, 2008 12:10:24 PM
Subject: Re: [lpc2000] LPC2148 UART0 failure to receive
Are you using a 3-wire connection (TXD, RXD, GND), or a full modem
set? And do you do anything with received data?

--jc

On Fri, Oct 17, 2008 at 12:01 PM, mlcchemtrac wrote:
> We need to be able to disconnect and reconnect our serial
> communications without causing a system upset.
>
> Here is the kicker... The UART operates correctly, RS232 9600 baud.
> However, when the RS232 cable is disconnected then at some later time
> reconnected the UART will not receive any data. I have scoped the
> signal through the MAX3232 and it looks as I expect.
>
> In my code the processor is transmitting data at regular intervals
> regardless of the RS232 connection. When the RS232 cable is
> reconnected this data comes through OK.
>
> I have gone so far as to reinitialize the UART after every
> transmission, this has not helped. The only solution I have found is
> to do a hardware reset or cycle the power, this is not acceptable to
> our customers.
>
> I have not been able to find anything in documentation regarding this
> problem.
>
> Has anyone had experience with this type problem?
>
> By the way, has NXP technical support been abducted. They certainly
> have become scarce.
>
> Michael,

__________________________________________________


Reply by leon Heller October 17, 20082008-10-17
----- Original Message -----
From: "mlcchemtrac"
To:
Sent: Friday, October 17, 2008 5:01 PM
Subject: [lpc2000] LPC2148 UART0 failure to receive
> We need to be able to disconnect and reconnect our serial
> communications without causing a system upset.
>
> Here is the kicker... The UART operates correctly, RS232 9600 baud.
> However, when the RS232 cable is disconnected then at some later time
> reconnected the UART will not receive any data. I have scoped the
> signal through the MAX3232 and it looks as I expect.
>
> In my code the processor is transmitting data at regular intervals
> regardless of the RS232 connection. When the RS232 cable is
> reconnected this data comes through OK.
>
> I have gone so far as to reinitialize the UART after every
> transmission, this has not helped. The only solution I have found is
> to do a hardware reset or cycle the power, this is not acceptable to
> our customers.
>
> I have not been able to find anything in documentation regarding this
> problem.
>
> Has anyone had experience with this type problem?

Some sort of ACK/NAK protocol should solve the problem.

Leon