2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 , 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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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)?

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 , 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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 () 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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> 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 ;-)

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In , "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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In , "tsvetanusunov" <tusunov@m...> wrote: > --- In , "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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

These were very early devices, only the 210x family was affected. Very few were released, most as samples. --- In , "jamesradix1969" <jamesradix1969@y...> wrote: > --- In , "tsvetanusunov" <tusunov@m...> wrote: > > --- In , "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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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:] Sent: 10. september 2004 03:30 To: 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 , "jamesradix1969" <jamesradix1969@y...> wrote: > --- In , "tsvetanusunov" <tusunov@m...> wrote: > > --- In , "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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In , "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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 , "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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 , "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 , "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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 , "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 , "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 , "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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 , "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 , "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 , "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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 , "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 , "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 , "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 , "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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 , "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 , "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 , "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 , "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 , "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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 , 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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

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 , "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 , 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

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )