Lpc2000

I think the problem can be solved with a single OR gate.

1. As soon as power becomes available to a reset LPC2xxx any free 
port1 pin will be pulled high due to internal pullups on all port 1 
pins and due to port 1 default state as all inputs. This will 
probably occur before pin 0.14 is read. If not an external pull up 
resistor can be used.

2. The high signal can feed into an OR gate along with the DCD 
signal. No matter what the state of the DCD signal the output of the 
OR gate will be high. The output of the OR gate can be connected to 
pin 0.14.

3. Since pin 0.14 is high the LPC2xxx will not forced to enter the 
bootloader. During initialisation the port1 pin feeding the OR gate 
can be made an output and forced low. Pin 0.14 will now reflect the 
state of the DCD pin. However an approach this simple permanently 
forces a pulled up resistor low and so affects the power budget.

John Heenan


--- In lpc2000@yahoogroups.com, "brendanmurphy37" 
<brendanmurphy37@...> wrote:
>
> 
> John,
> 
> I don't think this approach would solve the basic problem, which as 
> I understand it is something like:
> 
> - system is using modem, which is on a call: hence DCD is asserted 
> (low)
> 
> - software fails on the LPC2xxx (e.g. enters an infinite loop)
> 
> - external supervisor detects the problem and asserts RESET to 
reset 
> the LPC2xxx
> 
> - as DCD (P0.14) is still low when reset happens, system enters 
boot 
> loader mode
> 
> - system is now unrecoverable without manual intervention (as the 
> original post said, a simple power cycle can do the actual recovery)
> 
> I guess you could use a hardware approach similar to the one you 
> suggest to ensure P0.14 is high when RESET is asserted, as well as 
> when power is 1st applied (on the basis that any re-flash will 
> probably require manual intervention and override in any case). A 
> simpler hardware fix as I previously suggested is just to avoid 
> using the pin as DCD.
> 
> Unless of course I'm misunderstanding both the original post and 
> your suggested fix....
> 
> Brendan
> 
> 
> --- In lpc2000@yahoogroups.com, "John Heenan" <l10@> wrote:
> >
> > What about a simple brute force hardware approach that 
> > 1. Forces P0.14 high as soon as power is available.
> > 2. Turns off the brute force during initialisation.
> > 
> > It is not pretty and depending on implementation may cost more 
> power 
> > than you might like.
> > 
> > John Heenan
> > 
> > 
> > 
> > --- In lpc2000@yahoogroups.com, "misstero" <suriyant@> wrote:
> > >
> > > Dear All,
> > > 
> > > I have design which is connected modem signals to UART1 (Full 
> UART) 
> > of
> > > LPC2xxxx but I found serious problem with DCD signal.
> > > 
> > > DCD signal of UART1 is alternate function on P0.14 which is 
> LPC2xxx
> > > bootloader determine during reset to go into Bootloader mode if 
> it 
> > low.
> > > 
> > > Our problem occur when modem connected that DCD is active 
> (Active 
> > Low
> > > same as bootloader mode request) and LPC2xxx is reseted which 
may
> > > cause by unstable power or external reset via RESET pin by
> > > supervisory. This made LPC2xxx  go into bootloader mode forever 
> > cannot
> > > return back to our application code even modem's DCD inactive 
> later.
> > > Only power cycle both LPC2xxx and modem to restart it to 
> application
> > > code. This case unaccetable when devices are installed in unman 
> > location.
> > > 
> > > I have an idea to solve this problem but it need help from 
> Philips 
> > by
> > > add time-out in Bootloader mode if it does not have any 
activity 
> for
> > > short period of time (etc. 3s) it should be retry to execute
> > > application code repeatly so I'd like to ask Philips is it 
> possible?
> > > 
> > > Anyone have other ideas to solve this problem? Please share 
with 
> > me. I
> > > prefer to solve by software first if it possible.
> > > 
> > > Thanks,
> > > Suriyan.
> > >
> >
>