I have an interesting issue with a product thats been in production for 7 years
that now uses an LPC2134FBD64/01 it was originally designed using an
LPC2132FBD64 before the /01 parts where released, but the LPC2134FBD64/01
device has been used for years without any issues.

The product is polled from a PC via an Aten RS232 to RS485 converter
and for years this setup worked fine with very few polling transmission
errors.

A problem was detected recent production run where about 30% of units
had a high number of polling errors, with some units locking up completely
and requiring a hardware reset to recover. Leds on the unit flash as they
do on start-up indicating the unit is watch-dogging - automatically resetting.
What makes it difficult to analyse is that polling errors and subsequent
watch-dogging occurs randomly and 0.1% to 1% of the time over 1 - 2 hours test.

So far I've been able to rule out any issues with the power supply or the
RS485 transceiver used, the issue has been replicated on 2 different test
setups using different PC's for polling but using the same model of
Aten RS485 converter.

I have not seen any errata or other information that might suggest a
software workaround would be required to resolve the issue.

I'm out of ideas, can anyone suggest how to analyse this issue further
and develop a solution? Start a New Thread

Where does the converter get its power? How do you control RS485 direction tx v rx?

...Laurie:{) Start a New Thread

The converter is powered by its own AC plugpack which is plugged into the
same power outlet as is used to power the PC.
RS485 direction of the converter is controlled by the RTS line from the PC serial port.
I could try an isolated converter, but the point is it worked in the past, why not now. Start a New Thread

Are you connecting ground between the two nodes?

Mike Start a New Thread

Yes the ground is connected between nodes.
The cable distance between nodes is short, less than 0.5m
and they are powered from the same power outlet.
Chad Start a New Thread

Could their be a bug in the code that only manifests with a high error
rate? This could explain why you have not seen this behaviour before,
but it doesn't solve the problem of why there is a high error rate.

Since the cable is so short, likely termination will not matter either.

Mike Start a New Thread

What happens when you load the 2132 image on a 2134 device?
I note from the data sheet:
Standard modem interface signals included on UART1. (LPC2134/2136/2138 only)

The LPC2131/2132/2134/2136/2138 transmission FIFO control enables implementation of software (XON/XOFF) ßow control on both UARTs and hardware (CTS/RTS) ßow control on the LPC2134/2136/2138 UART1 only.

Will either of these differences impact you?

...Laurie:{) Start a New Thread

Hi,

If many devices is resetting continuously, and what is more, require hardware reset, there are mistakes in development.
- high sensitivity to ESD
- watchdog timer does not provide recovery
- software does not provide stable communication
- etc

But of course, it is nice idea to say that third party device (RS485 converter) is reason of troubles ;)

WBR
Vlad Start a New Thread

Its possible the cause is a bug, this would bring into question the depth
of previous testing and wether the polling errors where just tolerated
or put down to acceptable noise related error or not noticed.
But the product has been in production for 6 years so the hypothesis
is that something has changed to cause the high error rate.
Chad Start a New Thread

Mistakes I am sure, certainly I will avoid pointing the finger at NXP :)
I did the hardware design, someone else did the software.
The product itself was tested for EMC emissions and immunity
including ESD, powerline transients & harmonics 6 years ago and
passed all tests, its sold in Europe, US and Australia with no complaints in 6 years.
No hardware changes other than the CPU upgrade where made.
Software bug maybe. Start a New Thread