We just ran into a strange problem. We've had a product using the LPC2132
for over 5 years now in production.
We just bought another batch of chips, ran another production run, and now have
a problem never had before to date.
- We program the firmware into the MCU using FlashMagic through the UART.
- After the firmware is in, we then access the product/MCU again from our own
Windows app software to set other internal parameters, again over the COM
port.
Well this batch takes the firmware, but after that we cannot access the chip
again via UART at our standard 9600 baud!
Nothing in our firmware or app software has changed at all. Yet all of this
batch of chips is acting exactly the same.
They stopped talking over the UART after programming, or they are left with some
kind of different internal UART config.
These chips were recently purchased and have the /01 on them, do not recall the
Rev letter, probably F.
What I see in the datasheet is that the "/01" devices now have "fractional baud
rate". I guess that must be the new wrinkle.
Apparently I have to change my firmware for these /01 parts to setup the UART
differently.
Just curious if others have run into this.
Chris.
LPC2132 Rev Problem
Started by ●November 7, 2012
Reply by ●November 7, 20122012-11-07
Il 07/11/2012 08:49, Chris ha scritto:
>
>
> We just ran into a strange problem. We've had a product using the
> LPC2132 for over 5 years now in production.
> We just bought another batch of chips, ran another production run, and
> now have a problem never had before to date.
>
> - We program the firmware into the MCU using FlashMagic through the UART.
> - After the firmware is in, we then access the product/MCU again from
> our own Windows app software to set other internal parameters, again
> over the COM port.
>
> Well this batch takes the firmware, but after that we cannot access
> the chip again via UART at our standard 9600 baud!
> Nothing in our firmware or app software has changed at all. Yet all of
> this batch of chips is acting exactly the same.
> They stopped talking over the UART after programming, or they are left
> with some kind of different internal UART config.
>
> These chips were recently purchased and have the /01 on them, do not
> recall the Rev letter, probably F.
>
> What I see in the datasheet is that the "/01" devices now have
> "fractional baud rate". I guess that must be the new wrinkle.
> Apparently I have to change my firmware for these /01 parts to setup
> the UART differently.
>
You should check the register values you wrote in your original sw
because the new UxFDR register doesn't have impact on previous source
code because at reset the DIVADDL bits should be 0. So check your code
to see if you write (for an accident or not) to the address of these
registers (1 for every uart) as U0FDR - 0xE000 C028.
All parts exist in legacy versions and enhanced versions. Enhanced parts
are equipped with enhanced GPIO, BOD, ADC, UART peripherals. They are
also backward compatible to the "legacy" parts containing legacy
versions of the same peripherals.
Therefore, enhanced parts contain all features of legacy parts as well.
> Just curious if others have run into this.
>
> Chris.
>
>
>
>
> We just ran into a strange problem. We've had a product using the
> LPC2132 for over 5 years now in production.
> We just bought another batch of chips, ran another production run, and
> now have a problem never had before to date.
>
> - We program the firmware into the MCU using FlashMagic through the UART.
> - After the firmware is in, we then access the product/MCU again from
> our own Windows app software to set other internal parameters, again
> over the COM port.
>
> Well this batch takes the firmware, but after that we cannot access
> the chip again via UART at our standard 9600 baud!
> Nothing in our firmware or app software has changed at all. Yet all of
> this batch of chips is acting exactly the same.
> They stopped talking over the UART after programming, or they are left
> with some kind of different internal UART config.
>
> These chips were recently purchased and have the /01 on them, do not
> recall the Rev letter, probably F.
>
> What I see in the datasheet is that the "/01" devices now have
> "fractional baud rate". I guess that must be the new wrinkle.
> Apparently I have to change my firmware for these /01 parts to setup
> the UART differently.
>
You should check the register values you wrote in your original sw
because the new UxFDR register doesn't have impact on previous source
code because at reset the DIVADDL bits should be 0. So check your code
to see if you write (for an accident or not) to the address of these
registers (1 for every uart) as U0FDR - 0xE000 C028.
All parts exist in legacy versions and enhanced versions. Enhanced parts
are equipped with enhanced GPIO, BOD, ADC, UART peripherals. They are
also backward compatible to the "legacy" parts containing legacy
versions of the same peripherals.
Therefore, enhanced parts contain all features of legacy parts as well.
> Just curious if others have run into this.
>
> Chris.
>
>
Reply by ●November 11, 20122012-11-11
you shouldn't have to alter your firmware for the fractional divider if
you
never used it in the /00 chips. The fractional divider is disabled by
default. Assuming your app doesn't set turn it on unintentionally which can
happen if you set the right UART control bit where it was defined as
RESERVED in the /00 spec but is now used in the /01 spec.
never used it in the /00 chips. The fractional divider is disabled by
default. Assuming your app doesn't set turn it on unintentionally which can
happen if you set the right UART control bit where it was defined as
RESERVED in the /00 spec but is now used in the /01 spec.
Reply by ●November 12, 20122012-11-12
>> you shouldn't have to alter your firmware for
the fractional divider if you
>> never used it in the /00 chips. The fractional divider is disabled by
>> default. Assuming your app doesn't set turn it on unintentionally which can
>> happen if you set the right UART control bit where it was defined as
>> RESERVED in the /00 spec but is now used in the /01 spec.
That's what I thought too. The reg is: U0FDR = 0x10;
0x10 is the default, and is suppose to have FracDiv OFF.
Here's the other crazy thing. After these have been programmed once via UART,
they won't take programming again from UART ! FlashMagic cannot get them to respond.
UART just seems to be in a wierd state or baud rate.
This is really a surprise. I have to get this figured out tonight, so am working on it right now.
Chris.
>> never used it in the /00 chips. The fractional divider is disabled by
>> default. Assuming your app doesn't set turn it on unintentionally which can
>> happen if you set the right UART control bit where it was defined as
>> RESERVED in the /00 spec but is now used in the /01 spec.
That's what I thought too. The reg is: U0FDR = 0x10;
0x10 is the default, and is suppose to have FracDiv OFF.
Here's the other crazy thing. After these have been programmed once via UART,
they won't take programming again from UART ! FlashMagic cannot get them to respond.
UART just seems to be in a wierd state or baud rate.
This is really a surprise. I have to get this figured out tonight, so am working on it right now.
Chris.
Reply by ●November 12, 20122012-11-12
The way to get them programmed again is by powering down the LPC then pull the
isp pin low and power up the device, This should put the device into the
bootloader. After this flash magic should work.
I have used this trick on LPC2103's myself, they would sometimes refuse to be reprogrammed but with this trick i could reprogram them.
--- In l..., "Chris" wrote:
>
> >> you shouldn't have to alter your firmware for the fractional divider if you
> >> never used it in the /00 chips. The fractional divider is disabled by
> >> default. Assuming your app doesn't set turn it on unintentionally which can
> >> happen if you set the right UART control bit where it was defined as
> >> RESERVED in the /00 spec but is now used in the /01 spec.
>
> That's what I thought too. The reg is: U0FDR = 0x10;
>
> 0x10 is the default, and is suppose to have FracDiv OFF.
>
> Here's the other crazy thing. After these have been programmed once via UART,
> they won't take programming again from UART ! FlashMagic cannot get them to respond.
> UART just seems to be in a wierd state or baud rate.
>
> This is really a surprise. I have to get this figured out tonight, so am working on it right now.
>
> Chris.
>
>
I have used this trick on LPC2103's myself, they would sometimes refuse to be reprogrammed but with this trick i could reprogram them.
--- In l..., "Chris" wrote:
>
> >> you shouldn't have to alter your firmware for the fractional divider if you
> >> never used it in the /00 chips. The fractional divider is disabled by
> >> default. Assuming your app doesn't set turn it on unintentionally which can
> >> happen if you set the right UART control bit where it was defined as
> >> RESERVED in the /00 spec but is now used in the /01 spec.
>
> That's what I thought too. The reg is: U0FDR = 0x10;
>
> 0x10 is the default, and is suppose to have FracDiv OFF.
>
> Here's the other crazy thing. After these have been programmed once via UART,
> they won't take programming again from UART ! FlashMagic cannot get them to respond.
> UART just seems to be in a wierd state or baud rate.
>
> This is really a surprise. I have to get this figured out tonight, so am working on it right now.
>
> Chris.
>
>
Reply by ●November 12, 20122012-11-12
Il 12/11/2012 06:28, Chris ha scritto:
>
>
> >> you shouldn't have to alter your firmware for the fractional
> divider if you
> >> never used it in the /00 chips. The fractional divider is disabled by
> >> default. Assuming your app doesn't set turn it on unintentionally
> which can
> >> happen if you set the right UART control bit where it was defined as
> >> RESERVED in the /00 spec but is now used in the /01 spec.
>
> That's what I thought too. The reg is: U0FDR = 0x10;
>
> 0x10 is the default, and is suppose to have FracDiv OFF.
>
> Here's the other crazy thing. After these have been programmed once
> via UART,
> they won't take programming again from UART ! FlashMagic cannot get
> them to respond.
> UART just seems to be in a wierd state or baud rate.
>
> This is really a surprise. I have to get this figured out tonight, so
> am working on it right now.
>
You should use the JTAG interface and read the registers content, I hope
that JTAG will work if the only drawback is the UART baudrate.
Is it possible that for a mistake you write the fractional divider
register? I mean that it wasn't present in the original part and so
there is a (little) possibility to write an erroneous value on it.
> Chris.
>
>
>
>
> >> you shouldn't have to alter your firmware for the fractional
> divider if you
> >> never used it in the /00 chips. The fractional divider is disabled by
> >> default. Assuming your app doesn't set turn it on unintentionally
> which can
> >> happen if you set the right UART control bit where it was defined as
> >> RESERVED in the /00 spec but is now used in the /01 spec.
>
> That's what I thought too. The reg is: U0FDR = 0x10;
>
> 0x10 is the default, and is suppose to have FracDiv OFF.
>
> Here's the other crazy thing. After these have been programmed once
> via UART,
> they won't take programming again from UART ! FlashMagic cannot get
> them to respond.
> UART just seems to be in a wierd state or baud rate.
>
> This is really a surprise. I have to get this figured out tonight, so
> am working on it right now.
>
You should use the JTAG interface and read the registers content, I hope
that JTAG will work if the only drawback is the UART baudrate.
Is it possible that for a mistake you write the fractional divider
register? I mean that it wasn't present in the original part and so
there is a (little) possibility to write an erroneous value on it.
> Chris.
>
>
Reply by ●November 12, 20122012-11-12
Well the saga continues. After hooking the JTAG debugger up, the UART interface
was then working! It would work when the JTAG was connected, but would not work
when it was disconnected.
So instantly I thought it must be some PullUp issue on the JTAG pins. There were a couple differences between the pin voltages with/without JTAG hooked up.
So I added a couple PU resistors to make them identical with/without JTAG hooked up. Did not help. Problem remains. UART interface works with JTAG pod connected, does not work without it.
So something is changing/effecting the UART0 when the JTAG is hooked up. More work required...
Chris.
So instantly I thought it must be some PullUp issue on the JTAG pins. There were a couple differences between the pin voltages with/without JTAG hooked up.
So I added a couple PU resistors to make them identical with/without JTAG hooked up. Did not help. Problem remains. UART interface works with JTAG pod connected, does not work without it.
So something is changing/effecting the UART0 when the JTAG is hooked up. More work required...
Chris.
Reply by ●November 14, 20122012-11-14
Problem solved. Solution: Attach Serial Cable AFTER power up NOT before
It appears that the LPC2132/01 new parts have some different behavior in the
way they
handle the UART FIFO buffers and/or clear them. It was not a matter of
changing the hardware or firmware,
but how we connect the serial cable for testing.
With the original LPC2132 parts we connected the serial cable first then
powered up the unit.
We could instantly link via the serial port to the product. But this did
not work with the /01 new parts.
For some reason there are garbage chrs in the /01 UART/FIFO on power up.
They do not get cleared and the UART is basically locked up.
By connecting the cable after power is ON, we get transition garbage chrs
fed into the UART/FIFO
but this triggers an error and our firmware ISR then clears the buffer.
After that it then works.
Very odd problem, but this was the solution.
Thanks, Chris.
It appears that the LPC2132/01 new parts have some different behavior in the
way they
handle the UART FIFO buffers and/or clear them. It was not a matter of
changing the hardware or firmware,
but how we connect the serial cable for testing.
With the original LPC2132 parts we connected the serial cable first then
powered up the unit.
We could instantly link via the serial port to the product. But this did
not work with the /01 new parts.
For some reason there are garbage chrs in the /01 UART/FIFO on power up.
They do not get cleared and the UART is basically locked up.
By connecting the cable after power is ON, we get transition garbage chrs
fed into the UART/FIFO
but this triggers an error and our firmware ISR then clears the buffer.
After that it then works.
Very odd problem, but this was the solution.
Thanks, Chris.
Reply by ●November 14, 20122012-11-14
Il 14/11/2012 13:12, Chris ha scritto:
>
>
> Problem solved. Solution: Attach Serial Cable AFTER power up NOT before
>
Good to know.
> It appears that the LPC2132/01 new parts have some different behavior
> in the
> way they
> handle the UART FIFO buffers and/or clear them. It was not a matter of
> changing the hardware or firmware,
> but how we connect the serial cable for testing.
>
> With the original LPC2132 parts we connected the serial cable first then
> powered up the unit.
> We could instantly link via the serial port to the product. But this did
> not work with the /01 new parts.
>
> For some reason there are garbage chrs in the /01 UART/FIFO on power up.
> They do not get cleared and the UART is basically locked up.
>
I suppose that the garbage comes from the other side UART and cable
because at power up the GPIO pins are active. Anyway it is not a good
idea to don't clear the FIFOs during the UART initialization. I should
try to make a little modification to clear the FIFO buffers before to
start the application and to see if it works or not.
> By connecting the cable after power is ON, we get transition garbage chrs
> fed into the UART/FIFO
> but this triggers an error and our firmware ISR then clears the buffer.
> After that it then works.
>
> Very odd problem, but this was the solution.
>
> Thanks, Chris.
>
>
> Problem solved. Solution: Attach Serial Cable AFTER power up NOT before
>
Good to know.
> It appears that the LPC2132/01 new parts have some different behavior
> in the
> way they
> handle the UART FIFO buffers and/or clear them. It was not a matter of
> changing the hardware or firmware,
> but how we connect the serial cable for testing.
>
> With the original LPC2132 parts we connected the serial cable first then
> powered up the unit.
> We could instantly link via the serial port to the product. But this did
> not work with the /01 new parts.
>
> For some reason there are garbage chrs in the /01 UART/FIFO on power up.
> They do not get cleared and the UART is basically locked up.
>
I suppose that the garbage comes from the other side UART and cable
because at power up the GPIO pins are active. Anyway it is not a good
idea to don't clear the FIFOs during the UART initialization. I should
try to make a little modification to clear the FIFO buffers before to
start the application and to see if it works or not.
> By connecting the cable after power is ON, we get transition garbage chrs
> fed into the UART/FIFO
> but this triggers an error and our firmware ISR then clears the buffer.
> After that it then works.
>
> Very odd problem, but this was the solution.
>
> Thanks, Chris.
Reply by ●November 14, 20122012-11-14
How is your hardware PROG/RST<--->RTS/DTS configuration ?
2012/11/14 M. Manca
> **
> Il 14/11/2012 13:12, Chris ha scritto:
>
> >
> >
> > Problem solved. Solution: Attach Serial Cable AFTER power up NOT before
> >
> Good to know.
>
> >
> >
> > It appears that the LPC2132/01 new parts have some different behavior
> > in the
> > way they
> > handle the UART FIFO buffers and/or clear them. It was not a matter of
> > changing the hardware or firmware,
> > but how we connect the serial cable for testing.
> >
> > With the original LPC2132 parts we connected the serial cable first then
> > powered up the unit.
> > We could instantly link via the serial port to the product. But this did
> > not work with the /01 new parts.
> >
> > For some reason there are garbage chrs in the /01 UART/FIFO on power up.
> > They do not get cleared and the UART is basically locked up.
> >
> I suppose that the garbage comes from the other side UART and cable
> because at power up the GPIO pins are active. Anyway it is not a good
> idea to don't clear the FIFOs during the UART initialization. I should
> try to make a little modification to clear the FIFO buffers before to
> start the application and to see if it works or not.
>
> >
> >
> > By connecting the cable after power is ON, we get transition garbage chrs
> > fed into the UART/FIFO
> > but this triggers an error and our firmware ISR then clears the buffer.
> > After that it then works.
> >
> > Very odd problem, but this was the solution.
> >
> > Thanks, Chris.
> >
> >
>
>
>
2012/11/14 M. Manca
> **
> Il 14/11/2012 13:12, Chris ha scritto:
>
> >
> >
> > Problem solved. Solution: Attach Serial Cable AFTER power up NOT before
> >
> Good to know.
>
> >
> >
> > It appears that the LPC2132/01 new parts have some different behavior
> > in the
> > way they
> > handle the UART FIFO buffers and/or clear them. It was not a matter of
> > changing the hardware or firmware,
> > but how we connect the serial cable for testing.
> >
> > With the original LPC2132 parts we connected the serial cable first then
> > powered up the unit.
> > We could instantly link via the serial port to the product. But this did
> > not work with the /01 new parts.
> >
> > For some reason there are garbage chrs in the /01 UART/FIFO on power up.
> > They do not get cleared and the UART is basically locked up.
> >
> I suppose that the garbage comes from the other side UART and cable
> because at power up the GPIO pins are active. Anyway it is not a good
> idea to don't clear the FIFOs during the UART initialization. I should
> try to make a little modification to clear the FIFO buffers before to
> start the application and to see if it works or not.
>
> >
> >
> > By connecting the cable after power is ON, we get transition garbage chrs
> > fed into the UART/FIFO
> > but this triggers an error and our firmware ISR then clears the buffer.
> > After that it then works.
> >
> > Very odd problem, but this was the solution.
> >
> > Thanks, Chris.
> >
> >
>
>
>
