SOLVED!!

The cause was an incorrect setting of the MAM Timing register it should have been set to 3 and not 2 for a 60MHz clock. So yes it was technically a bug in the code.
This was a case where older versions of the chip such as rev D and
lower appeared to function ok for 6yrs of production until rev E of the chip was used. Of course to be clear rev E chips now work very well.
Thanks to all that gave their advice

Rgds
Chad

--- In l..., chadjw@... wrote:
>
> 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?
>

An Engineer's Guide to the LPC2100 Series

GSM SIM300 modules 500 nos in stock with me contact if any body can lift the stock with me.

--- In l..., chadjw@... wrote:
>
> 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.
This is a Sheldon Cooper moment !!

"Of course something has changed, but I don't get anything wrong."

Do you have a working board that you can change to a new chip ?

Do you have a new board you can put on old chip ?

Either way, you are going to change some code or change some chips.

don

There were some changes on the UART between the 2 releases of the
microcontroller and there are differences in other registers.
I think you should read:
http://www.nxp.com/documents/errata_sheet/ES_LPC2134.pdf
http://www.nxp.com/documents/errata_sheet/ES_LPC2134_01.pdf

and in my opinion the most probable errata that could interest you are:
UART.1 Coinciding VPB read and hardware register update
WDT.1 Accessing non-Watchdog APB registers in the middle of the feed
sequence causes a reset

Are spurious interrupts handled correctly, or at all?

Mike

My understanding is that the 2132 devices are software compatible.
The RTS line on UART1 is used to enable the RS485 transmit so
the upgrade to a 2134 required no hardware changes.

I was looking at the differences between the LPC2134/01 devices and
the original LPC2132 to see if any changes to the UART driver would
have been necessary but could not find any incompatibility that
could increase the error rate. Anyway the LPC2134/01 devices
have been a while with no "detected" issues.

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.

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

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

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:{)