Lpc2000

Ugh,

I seem to remember an email or two about this a while ago, but can't 
seem to find them - are there any requirements for the ordering of the 
core and IO voltage supplies? Don't see anything in the datasheets...

Realized I was about to implement a design where IO would come up 
before core (the part would still be in reset for 300ms after VCC_IO 
stabilized) - will that be ok?

Thanks!

Shannon

Hi Shannon,

the previous posting was message 1236 and following. Back then there
was a conclusion that sequencing matters, Philips says, sequencing
does not matter, in our tests sequencing did not matter and we did
numerous of them. So, your proposal will work but it is important that
reset stays active until both voltages are up as you mentioned. 

Cheers, Bob

--- In lpc2000@yahoogroups.com, Shannon Holland <holland@l...> wrote:

> Ugh,
> 
> I seem to remember an email or two about this a while ago, but can't 
> seem to find them - are there any requirements for the ordering of the 
> core and IO voltage supplies? Don't see anything in the datasheets...
> 
> Realized I was about to implement a design where IO would come up 
> before core (the part would still be in reset for 300ms after VCC_IO 
> stabilized) - will that be ok?
> 
> Thanks!
> 
> Shannon

At 05:31 AM 6/19/04 +0000, you wrote:
>Hi Shannon,
>
>the previous posting was message 1236 and following. Back then there
>was a conclusion that sequencing matters, Philips says, sequencing
>does not matter, in our tests sequencing did not matter and we did
>numerous of them. So, your proposal will work but it is important that
>reset stays active until both voltages are up as you mentioned.

I'll second that.  I did some testing on this as well and there appears to 
be no effect even when the supplies are sequenced seconds apart (in either 
order).

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Cool - thanks guys! That would mean one less thing for me to change 
(need to get this board done this weekend!).

Shannon

On Jun 19, 2004, at 8:38 AM, Robert Adsett wrote:

> At 05:31 AM 6/19/04 +0000, you wrote:
>> Hi Shannon,
>>
>> the previous posting was message 1236 and following. Back then there
>> was a conclusion that sequencing matters, Philips says, sequencing
>> does not matter, in our tests sequencing did not matter and we did
>> numerous of them. So, your proposal will work but it is important that
>> reset stays active until both voltages are up as you mentioned.
>
> I'll second that.  I did some testing on this as well and there 
> appears to
> be no effect even when the supplies are sequenced seconds apart (in 
> either
> order).
>
> Robert
>
>
> " 'Freedom' has no meaning of itself.  There are always restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try to
> chew a radio signal. "
>
>                          Kelvin Throop, III
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

1) Other than the report from Tsvetan (messages 1236/1249/1257), is 
anyone aware of problems related to Power Supply sequencing or rise 
times?

2) Is anyone aware of any other problems of the processor going into 
a latchup state?

3) Robert (messages 1256, 1281, & 2536) and Bob (message 2533) say 
they have made tests which were not able to reproduce a supply 
sequencing problem.

Do you feel that you have also ruled out supply rise time as the 
problem?

4) Assuming Tsvetan's report is accurate (including that he held 
reset until all supplies were stable), he apparently did get the chip 
into some sort of latchup state (on 10% of his boards).

Does anyone have a viable theory as to the cause?

5) Questions for Tsvetan (comments from others welcome):

a) Other than the fact that changing the capacitor seemed to cure the 
problem, have you managed to determine anything more specific?  Do I 
understand correctly that you currently feel the problem is something 
other than simple power supply sequencing?

b) When unplugging your power supply, did you wait for both 3.3V and 
1.8V to fully drain, before plugging it back in?  i.e.: Could the 
fact that changing the capacitor fixed the problem, be more related 
to how far the 3.3V supply fell when unit was unplugged, rather than 
how fast it rises?

c) As others have suggested, could the problem be related to the rise 
time of the 3.3V supply, as opposed to the sequence in which supplies 
are applied?

d) I was not able to read your schematic on the web.  Are all items 
connected to processor i/o pins fed from the same 3.3V supply as the 
processor?  If not, could latch-up be related to some voltage mis-
match there?  (The data sheet says that the i/o pins are only 5V 
tolerant when the 3.3V supply is present.)

e) Could it be that an incorrect level was present on one of the pins 
which get sampled at reset (P0.14, DBGSEL, RTCK)?

There is an opportunity here for Philips to step in if they have found out 
anything about this.

At 01:12 AM 7/12/04 +0000, you wrote:
<snip>
>3) Robert (messages 1256, 1281, & 2536) and Bob (message 2533) say
>they have made tests which were not able to reproduce a supply
>sequencing problem.
>
>Do you feel that you have also ruled out supply rise time as the
>problem?

Not absolutely, but likely.  If the problem is the power supply rising too 
fast than simply switching it on to the micro after it has stabilized 
(essentially what I did) will give a fast and rather dirty edge.  If it's 
too slow than adding extra capacitance (what Tsvetan did) will slow it down 
and presumably make the problem worse.  Mine was a quick and dirty test but 
it ruled out a simple sequencing explanation.


Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Hello Robert and group,

we used different devices of the LPC2000 family and different startup 
times / sequences and did not see any dependence which power was up 
first. At this point in time I can not exclude the theoretical 
possibility of a too fast or too slow rise time however, we did not 
see problems in our tests nor in simulation. 

In a nutshell, all tests and simulations we did were successful, 
meaning the device started up without latching up.  

Best regards, Robert


--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> There is an opportunity here for Philips to step in if they have 
found out 
> anything about this.
> 
> At 01:12 AM 7/12/04 +0000, you wrote:
> <snip>
> >3) Robert (messages 1256, 1281, & 2536) and Bob (message 2533) say
> >they have made tests which were not able to reproduce a supply
> >sequencing problem.
> >
> >Do you feel that you have also ruled out supply rise time as the
> >problem?
> 
> Not absolutely, but likely.  If the problem is the power supply 
rising too 
> fast than simply switching it on to the micro after it has 
stabilized 
> (essentially what I did) will give a fast and rather dirty edge.  
If it's 
> too slow than adding extra capacitance (what Tsvetan did) will slow 
it down 
> and presumably make the problem worse.  Mine was a quick and dirty 
test but 
> it ruled out a simple sequencing explanation.
> 
> 
> Robert
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try 
to

> chew a radio signal. "
> 
>                          Kelvin Throop, III

Hello Group,

I'm sorry I don't read all messages in this group and didn't saw that 
here are questions for me. Thank to Martin Koenig who e-mailed me 
directly and point this thread to me.

What we have so far is the following statistics:
In the first 500 pcs assembled boards we had with LPC2106 they were 
with 10/10 uf tant power supply capacitors and around 10% were with 
the problem of start-up. The problem was that if you plug and unplug 
the power supply to the board sometimes the code in LPC2106 is 
running and sometimes is not running, but oscillator is working in 
each cases, this happens no matter how long we hold reset low.
After the post in this group and the valuable comments from Bill 
Knight we changed the 3.3V capacitor to 47uF which decreased the 
boards with problems to only few.
Now with over 1700 boards assembled and tested I check today in our 
QC dept and they have only 6 boards with this problem left, which is 
too small quantity to worry about and to investigate (say to spend 
money on it from manufacturing point of view). 
I can send boards with such problem to Philips to investigate, in 
matter of fact Robert (philips_apps@yahoo) e-mailed me with such 
request after my first post. The problem is that this e-mail 
(tusunov@...) is used only to post on yahoo groups and I don't 
read it frequently. I read the message about one or two months later 
and reply to Robert asking for address where to send boards with this 
problem but never got reply (I suppose he doesn't read his Yahoo e-
mail often too :)))

Best regards
Tsvetan

> Now with over 1700 boards assembled and tested I check today in our 
> QC dept and they have only 6 boards with this problem left, which is 
> too small quantity to worry about and to investigate (say to spend 
> money on it from manufacturing point of view). 

I think we will soon see an onboard 1V8 regulator and a brownout
detector on board the LPC chips ;-)

--- In lpc2000@yahoogroups.com, "g2100g" <g2100g@e...> wrote:
> 1) Other than the report from Tsvetan (messages 1236/1249/1257), is 
> anyone aware of problems related to Power Supply sequencing or rise 
> times?
> 
> 2) Is anyone aware of any other problems of the processor going 
into 
> a latchup state?

This may be interesting to group members who have early revisions of 
LPC2106 still unused or in devices working in the field.
Philips have receive two sample boards which had the latchup problem 
described by me. This is the reply I received yesterday:

"The boards were experiencing a flash latchup problem associated with 
very early versions/samples of those parts (Rev. B).  The current 
revision (C) does not have this problem.  Make sure that the reset 
circuit provides at least a reset duration of a least 10ms at power 
up and 300ns thereafter. 

Richard"


Best regards
Tsvetan

--- In lpc2000@yahoogroups.com, "tsvetanusunov" <tusunov@m...> wrote:
> --- In lpc2000@yahoogroups.com, "g2100g" <g2100g@e...> wrote:
> > 1) Other than the report from Tsvetan (messages 1236/1249/1257), 
is 
> > anyone aware of problems related to Power Supply sequencing or 
rise 
> > times?
> > 
> > 2) Is anyone aware of any other problems of the processor going 
> into 
> > a latchup state?
> 
> This may be interesting to group members who have early revisions 
of 
> LPC2106 still unused or in devices working in the field.
> Philips have receive two sample boards which had the latchup 
problem 
> described by me. This is the reply I received yesterday:
> 
> "The boards were experiencing a flash latchup problem associated 
with 
> very early versions/samples of those parts (Rev. B).  The current 
> revision (C) does not have this problem.  Make sure that the reset 
> circuit provides at least a reset duration of a least 10ms at 
power 
> up and 300ns thereafter. 
> 
> Richard"
> 
> 
> Best regards
> Tsvetan

How can you tell which version of the chip you have?  Is it part of 
the printed markings on the chip?  Do other family members (2129) 
have this problem too?
Thanks,
James

These were very early devices, only the 210x family was affected.  
Very few were released, most as samples.



--- In lpc2000@yahoogroups.com, "jamesradix1969" 
<jamesradix1969@y...> wrote:
> --- In lpc2000@yahoogroups.com, "tsvetanusunov" <tusunov@m...> 
wrote:
> > --- In lpc2000@yahoogroups.com, "g2100g" <g2100g@e...> wrote:
> > > 1) Other than the report from Tsvetan (messages 
1236/1249/1257), 
> is 
> > > anyone aware of problems related to Power Supply sequencing or 
> rise 
> > > times?
> > > 
> > > 2) Is anyone aware of any other problems of the processor going 
> > into 
> > > a latchup state?
> > 
> > This may be interesting to group members who have early revisions 
> of 
> > LPC2106 still unused or in devices working in the field.
> > Philips have receive two sample boards which had the latchup 
> problem 
> > described by me. This is the reply I received yesterday:
> > 
> > "The boards were experiencing a flash latchup problem associated 
> with 
> > very early versions/samples of those parts (Rev. B).  The current 
> > revision (C) does not have this problem.  Make sure that the 
reset 

> > circuit provides at least a reset duration of a least 10ms at 
> power 
> > up and 300ns thereafter. 
> > 
> > Richard"
> > 
> > 
> > Best regards
> > Tsvetan
> 
> How can you tell which version of the chip you have?  Is it part of 
> the printed markings on the chip?  Do other family members (2129) 
> have this problem too?
> Thanks,
> James

Hi all...

I have some of the Rev B. (not many though) processors not mounted yet
should I throw these to the dogs to avoid problems or...? 

Regards
Lasse Madsen

-----Original Message-----
From: Richard [mailto:richas@...] 
Sent: 10. september 2004 03:30
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Re: Power Supply Sequencing - Latchup - FOLLOWUP

These were very early devices, only the 210x family was affected.  
Very few were released, most as samples.



--- In lpc2000@yahoogroups.com, "jamesradix1969" 
<jamesradix1969@y...> wrote:
> --- In lpc2000@yahoogroups.com, "tsvetanusunov" <tusunov@m...> 
wrote:
> > --- In lpc2000@yahoogroups.com, "g2100g" <g2100g@e...> wrote:
> > > 1) Other than the report from Tsvetan (messages 
1236/1249/1257), 
> is 
> > > anyone aware of problems related to Power Supply sequencing or 
> rise 
> > > times?
> > > 
> > > 2) Is anyone aware of any other problems of the processor going 
> > into 
> > > a latchup state?
> > 
> > This may be interesting to group members who have early revisions 
> of 
> > LPC2106 still unused or in devices working in the field.
> > Philips have receive two sample boards which had the latchup 
> problem 
> > described by me. This is the reply I received yesterday:
> > 
> > "The boards were experiencing a flash latchup problem associated 
> with 
> > very early versions/samples of those parts (Rev. B).  The current 
> > revision (C) does not have this problem.  Make sure that the 
reset 
> > circuit provides at least a reset duration of a least 10ms at 
> power 
> > up and 300ns thereafter. 
> > 
> > Richard"
> > 
> > 
> > Best regards
> > Tsvetan
> 
> How can you tell which version of the chip you have?  Is it part of 
> the printed markings on the chip?  Do other family members (2129) 
> have this problem too?
> Thanks,
> James




 
Yahoo! Groups Links

--- In lpc2000@yahoogroups.com, "Lasse Madsen" <lasse.madsen@e...> 
wrote:
> Hi all...
> 
> I have some of the Rev B. (not many though) processors not mounted 
yet
> should I throw these to the dogs to avoid problems or...? 

all 2x250 pcs which came to us in February this year were from this 
Rev.B 
after changing the filtering capacitors to 10uF/47uF almost all start 
working reliable at startup, the last two went to Philips for 
evaluation ;)
All next lots we received didn't had this problem (we though that 
this is due to the change with the capacitors we made, but now we 
learn that this is because the bug has been fixed)
of course it's not advisable to put Rev.B in something you want to 
rely on, but you can use them without problem in prototypes/first 
releases of something you develop

Best regards
Tsvetan

----- Original Message ----- 

From: "Lasse Madsen" <lasse.madsen@...>
To: <lpc2000@yahoogroups.com>
Sent: Friday, September 10, 2004 7:39 AM
Subject: RE: [lpc2000] Re: Power Supply Sequencing - Latchup - FOLLOWUP


> Hi all...
>
> I have some of the Rev B. (not many though) processors not mounted yet
> should I throw these to the dogs to avoid problems or...?

All the ones I've got ('2104 and '2106) are Rev. B. I've not had any
problems with my boards.

Leon

Hi Tsvetan & Leon

Thanks for the prompt response. 
That was what I wanted to hear I'll keep them for prototypes :)

Best Regards
Lasse Madsen

As described in the Errata Sheet, available on Philips web site: "The 
last letter in the third line (field `R') will identify the device 
revision." 

--- In lpc2000@yahoogroups.com, "jamesradix1969" 
<jamesradix1969@y...> wrote:

>
> How can you tell which version of the chip you have?  Is it part of 
> the printed markings on the chip?  Do other family members (2129) 
> have this problem too?
> Thanks,
> James

We appear to have this problem on the LPC2114.  Our prototype board
appears to latch into a state sometimes on powerup.  If you take the
reset line down and back up when in this state the processor still
doesn't come up.

Interestingly, if you attach the debugger to the processor it's
sitting in the "undefined instruction" handler, if you tell it to jump
to the reset handler it does so and starts to execute but then finds
it's way back into the undefined instruction handler....

This problem is most noticable when flicking the power on and off rapidly.

Philips, I think we have a problem......

--- In lpc2000@yahoogroups.com, "g2100g" <g2100g@e...> wrote:

> As described in the Errata Sheet, available on Philips web site: "The 
> last letter in the third line (field `R') will identify the device 
> revision." 
> 
> --- In lpc2000@yahoogroups.com, "jamesradix1969" 
> <jamesradix1969@y...> wrote:
> >
> > How can you tell which version of the chip you have?  Is it part of 
> > the printed markings on the chip?  Do other family members (2129) 
> > have this problem too?
> > Thanks,
> > James

When you "jump to the reset handler" with the debugger, what is 
MEMMAP set to?  I assume you want it set to FLASH Mode.

--- In lpc2000@yahoogroups.com, "moostieuk" <moostieuk@y...> wrote:
> 
> We appear to have this problem on the LPC2114.  Our prototype board
> appears to latch into a state sometimes on powerup.  If you take the
> reset line down and back up when in this state the processor still
> doesn't come up.
> 
> Interestingly, if you attach the debugger to the processor it's
> sitting in the "undefined instruction" handler, if you tell it to 
jump
> to the reset handler it does so and starts to execute but then finds
> it's way back into the undefined instruction handler....
> 
> This problem is most noticable when flicking the power on and off 
rapidly.
> 
> Philips, I think we have a problem......
> 
> --- In lpc2000@yahoogroups.com, "g2100g" <g2100g@e...> wrote:
> > As described in the Errata Sheet, available on Philips web 
site: "The 
> > last letter in the third line (field `R') will identify the 
device 
> > revision." 
> > 
> > --- In lpc2000@yahoogroups.com, "jamesradix1969" 
> > <jamesradix1969@y...> wrote:
> > >
> > > How can you tell which version of the chip you have?  Is it 
part of 
> > > the printed markings on the chip?  Do other family members 
(2129) 

> > > have this problem too?
> > > Thanks,
> > > James

If you find yourself in an exception handler, probably looping
indefinetly because it is not really a "handler", then you are not
latched up, yoou are executing code.

Richard

--- In lpc2000@yahoogroups.com, "moostieuk" <moostieuk@y...> wrote:
> 
> We appear to have this problem on the LPC2114.  Our prototype board
> appears to latch into a state sometimes on powerup.  If you take the
> reset line down and back up when in this state the processor still
> doesn't come up.
> 
> Interestingly, if you attach the debugger to the processor it's
> sitting in the "undefined instruction" handler, if you tell it to jump
> to the reset handler it does so and starts to execute but then finds
> it's way back into the undefined instruction handler....
> 
> This problem is most noticable when flicking the power on and off
rapidly.

> 
> Philips, I think we have a problem......
> 
> --- In lpc2000@yahoogroups.com, "g2100g" <g2100g@e...> wrote:
> > As described in the Errata Sheet, available on Philips web site: "The 
> > last letter in the third line (field `R') will identify the device 
> > revision." 
> > 
> > --- In lpc2000@yahoogroups.com, "jamesradix1969" 
> > <jamesradix1969@y...> wrote:
> > >
> > > How can you tell which version of the chip you have?  Is it part of 
> > > the printed markings on the chip?  Do other family members (2129) 
> > > have this problem too?
> > > Thanks,
> > > James

It's definately "latched up" in one way, cycling the reset line
doesn't bring the chip out of the mode (which you would expect it to
do).  Only thing to do is to completely power the board down so that
the rails have all collapsed.

The board starts up perfectly nearly every time, it's once in a while
it doesn't turn on when you apply power or you start switching the
power supply on and off rapidly, then you are able to make it happen
more often.

It's the lack of the processor not getting out of this state when
reset is toggled that indicates it's a problem with the processor.

And with regards to attaching the debugger, I just decided to give
that a go to see if I could actually talk to it, nobody on the list
here has ever mentioned trying this - when I attach the debugger and
break it's jumped to the undefined instruction handler (which branches
to itself).  I don't understand how it thinks it's able to get here
because the software/board runs perfectly 99% of the time.



--- In lpc2000@yahoogroups.com, "Richard" <richas@y...> wrote:
> 
> If you find yourself in an exception handler, probably looping
> indefinetly because it is not really a "handler", then you are not
> latched up, yoou are executing code.
> 
> Richard
> 
> --- In lpc2000@yahoogroups.com, "moostieuk" <moostieuk@y...> wrote:
> > 
> > We appear to have this problem on the LPC2114.  Our prototype board
> > appears to latch into a state sometimes on powerup.  If you take the
> > reset line down and back up when in this state the processor still
> > doesn't come up.
> > 
> > Interestingly, if you attach the debugger to the processor it's
> > sitting in the "undefined instruction" handler, if you tell it to jump
> > to the reset handler it does so and starts to execute but then finds
> > it's way back into the undefined instruction handler....
> > 
> > This problem is most noticable when flicking the power on and off
> rapidly.
> > 
> > Philips, I think we have a problem......
> > 
> > --- In lpc2000@yahoogroups.com, "g2100g" <g2100g@e...> wrote:
> > > As described in the Errata Sheet, available on Philips web site:
"The 
> > > last letter in the third line (field `R') will identify the device 
> > > revision." 
> > > 
> > > --- In lpc2000@yahoogroups.com, "jamesradix1969" 
> > > <jamesradix1969@y...> wrote:
> > > >
> > > > How can you tell which version of the chip you have?  Is it
part of 

> > > > the printed markings on the chip?  Do other family members (2129) 
> > > > have this problem too?
> > > > Thanks,
> > > > James

Check your power up reset signal length, it should be at least 10ms
(AFTER V18 is stable, check this).  If it is shorter than this the
processor may enter an "unknown state".

Richard

--- In lpc2000@yahoogroups.com, "moostieuk" <moostieuk@y...> wrote:
> 
> It's definately "latched up" in one way, cycling the reset line
> doesn't bring the chip out of the mode (which you would expect it to
> do).  Only thing to do is to completely power the board down so that
> the rails have all collapsed.
> 
> The board starts up perfectly nearly every time, it's once in a while
> it doesn't turn on when you apply power or you start switching the
> power supply on and off rapidly, then you are able to make it happen
> more often.
> 
> It's the lack of the processor not getting out of this state when
> reset is toggled that indicates it's a problem with the processor.
> 
> And with regards to attaching the debugger, I just decided to give
> that a go to see if I could actually talk to it, nobody on the list
> here has ever mentioned trying this - when I attach the debugger and
> break it's jumped to the undefined instruction handler (which branches
> to itself).  I don't understand how it thinks it's able to get here
> because the software/board runs perfectly 99% of the time.
> 
> 
> 
> --- In lpc2000@yahoogroups.com, "Richard" <richas@y...> wrote:
> > 
> > If you find yourself in an exception handler, probably looping
> > indefinetly because it is not really a "handler", then you are not
> > latched up, yoou are executing code.
> > 
> > Richard
> > 
> > --- In lpc2000@yahoogroups.com, "moostieuk" <moostieuk@y...> wrote:
> > > 
> > > We appear to have this problem on the LPC2114.  Our prototype board
> > > appears to latch into a state sometimes on powerup.  If you take the
> > > reset line down and back up when in this state the processor still
> > > doesn't come up.
> > > 
> > > Interestingly, if you attach the debugger to the processor it's
> > > sitting in the "undefined instruction" handler, if you tell it
to jump
> > > to the reset handler it does so and starts to execute but then finds
> > > it's way back into the undefined instruction handler....
> > > 
> > > This problem is most noticable when flicking the power on and off
> > rapidly.
> > > 
> > > Philips, I think we have a problem......
> > > 
> > > --- In lpc2000@yahoogroups.com, "g2100g" <g2100g@e...> wrote:
> > > > As described in the Errata Sheet, available on Philips web site:
> "The 
> > > > last letter in the third line (field `R') will identify the
device 
> > > > revision." 
> > > > 
> > > > --- In lpc2000@yahoogroups.com, "jamesradix1969" 
> > > > <jamesradix1969@y...> wrote:
> > > > >
> > > > > How can you tell which version of the chip you have?  Is it
> part of 
> > > > > the printed markings on the chip?  Do other family members
(2129) 

> > > > > have this problem too?
> > > > > Thanks,
> > > > > James

At 05:13 PM 1/19/05 +0000, you wrote:
>Check your power up reset signal length, it should be at least 10ms
>(AFTER V18 is stable, check this).  If it is shorter than this the
>processor may enter an "unknown state".

Also what's your decoupling like?  Marginal decoupling could give symptoms 
like this.

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                         Kelvin Throop, III

Lots of decoupling on all the rails.  I can't remember what the 
reset time is, but it's much longer (like 10 times or something - 
can't tell you as I'm not at work now!) than the spec says - 
Although the reset chip driven from the 3.3V, so it's possible that 
there is a problem there.  We'll check it out tomorrow.

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
wrote:
> At 05:13 PM 1/19/05 +0000, you wrote:
> >Check your power up reset signal length, it should be at least 
10ms
> >(AFTER V18 is stable, check this).  If it is shorter than this the
> >processor may enter an "unknown state".
> 
> Also what's your decoupling like?  Marginal decoupling could give 
symptoms 
> like this.
> 
> Robert
> 
> 
> " 'Freedom' has no meaning of itself.  There are always 
restrictions,
> be they legal, genetic, or physical.  If you don't believe me, try 
to

> chew a radio signal. "
> 
>                          Kelvin Throop, III

> We appear to have this problem on the LPC2114.  Our prototype board
> appears to latch into a state sometimes on powerup.  If you take the
> reset line down and back up when in this state the processor still
> doesn't come up.

this is very unlikely as we have many hundreds of LPC-P2114 and LPC-
E2114 in production and never ever experienced latchup behaviour like 
on the REV.B LPC2106.
Check our schematics which are posted on our web page, perhaps it's 
bad decouplung or reset circuit?

Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb 
(http://www.olimex.com/pcb)
PCB any volume assembly (http://www.olimex.com/pcb/protoa.html) 
Development boards for ARM, AVR, PIC, and MSP430 
(http://www.olimex.com/dev)

If your reset can go hi before the 1.8V supply has been stable long 
enough for the oscillator to stabilize, you will definitely have a 
problem.  Basically, the reset circuit must monitor the 1.8V supply, 
even though it must drive a 3.3V input on the processor.  (LPC213x 
series, with internal 1.8V regulator, does not have this problem.)

However, I still don't understand why a subsequent valid reset 
signal, after all supplies have long been stable, should not restore 
operation.  Since you are able to re-create the problem when running 
from debugger, you should be able to find the cause by single 
stepping.  Is there some register which is not at its "reset state", 
when you start execution from 0?  Typically, your code runs for a 
while before the JTAG grabs control - and your code may have modified 
some registers.  Personally, I find it good practice to explicitely 
set all registers to their "reset state" in the boot code.  Then you 
can start execution from 0, without worrying what came before - 
provided MEMMAP is set to properly (i.e.: not pointing to FLASH - 
which may not be initialized).

 

--- In lpc2000@yahoogroups.com, "moostieuk" <moostieuk@y...> wrote:
> 
> Lots of decoupling on all the rails.  I can't remember what the 
> reset time is, but it's much longer (like 10 times or something - 
> can't tell you as I'm not at work now!) than the spec says - 
> Although the reset chip driven from the 3.3V, so it's possible that 
> there is a problem there.  We'll check it out tomorrow.
> 
> --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@a...> 
> wrote:
> > At 05:13 PM 1/19/05 +0000, you wrote:
> > >Check your power up reset signal length, it should be at least 
> 10ms
> > >(AFTER V18 is stable, check this).  If it is shorter than this 
the
> > >processor may enter an "unknown state".
> > 
> > Also what's your decoupling like?  Marginal decoupling could give 
> symptoms 
> > like this.
> > 
> > Robert
> > 
> > 
> > " 'Freedom' has no meaning of itself.  There are always 
> restrictions,
> > be they legal, genetic, or physical.  If you don't believe me, 
try 

> to
> > chew a radio signal. "
> > 
> >                          Kelvin Throop, III