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.
LPC2132FBD4 RS485 polling problem: random resets
Started by ●May 6, 2013
Reply by ●May 7, 20132013-05-07
Reply by ●May 7, 20132013-05-07
Reply by ●May 8, 20132013-05-08
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
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
Reply by ●May 11, 20132013-05-11
--- 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
>
> 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
Reply by ●May 14, 20132013-05-14
Reply by ●September 12, 20132013-09-12
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?
>
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?
>
