Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

DCD signal force LPC2xxx go into Bootloader during reset

DCD signal force LPC2xxx go into Bootloader during reset

2006-04-26 by misstero

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.

Re: DCD signal force LPC2xxx go into Bootloader during reset

2006-04-26 by brendanmurphy37

It's probably not much help to you, but we specifically don't use 
the DCD line in a connection to a modem for this very reason.

In other words, if there's even a chance that something connected to 
the line can fool the part into thinking it's being requested to 
enter bootloader mode, then you're best not to connect it. As you 
point out, there are failure modes that can lead to an unrecoverable 
state (in the field).

We connect all modem signals (RTS/CTS/RI etc.) as normal, but 
connect the DCD to an external interrupt line instead of the DCD 
line on the LPC part, and modify the UART driver software 
accordingly. If this isn't an option (i.e. you've finalised your 
hardware design, or you're really short on pins), then there is one 
possibility you can look at: if the (internal) watchdog resets the 
device, the external request to enter the boot-loader is ignored. 
You can probably make use of this to come up with a scheme for 
improving the situation.

However, it's difficult to see how you could prevent the lockout 
situation when an external reset is applied whilst a modem DCD is 
being asserted. Power fails are less of an issue: presumably the 
modem is powered off the same source, in which case DCD will be de-
asserted on power-up (unless there's some modem that can establish a 
connection in less than 3ms?). 

I doubt Philips would modify the boot-loader in such a way as you 
propose: there could be unintended side effects for parts already 
deployed if they did.

Sorry not to be of more help: I'd be interested to hear if you come 
up with some other suggestions.

Brendan

--- 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
Show quoted textHide quoted text
> prefer to solve by software first if it possible.
> 
> Thanks,
> Suriyan.
>

Re: DCD signal force LPC2xxx go into Bootloader during reset

2006-04-27 by jayasooriah

--- In lpc2000@yahoogroups.com, "misstero" <suriyant@...> wrote:

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

Have you considered using another pin for DCD purposes so that it does
not intefere with Bootloader functions?

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

One client had the same problem (was using this pin for a different
purpose though), and they patched the boot loader to use a different
pin to enter Bootloader mode.  Incidentally this pin is determined by
Bootloader firmware, not the hardware.

> Anyone have other ideas to solve this problem? Please share with me. I
> prefer to solve by software first if it possible.

The downside is that Philips will not guarantee your part if you patch
(or replace) the boot loader.

Hope this helps.

Jaya

Re: DCD signal force LPC2xxx go into Bootloader during reset

2006-04-27 by brendanmurphy37

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
> One client had the same problem (was using this pin for a different
> purpose though), and they patched the boot loader to use a different 
pin to enter Bootloader mode.

If you're producing product in any sort of volume this is a poor 
strategy, in my opinion. Apart from not guaranteeing the part, Philips 
are under no obligation to keep the boot loader the same: they can 
change it at any time (as long as the published interface and 
production functionality remain the same). If part of your production 
process is to patch the device before you use it, what happens when 
the patch location changes? Doesn't bear thinking about....

Brendan

Re: DCD signal force LPC2xxx go into Bootloader during reset

2006-04-27 by jayasooriah

Murphy's law of this forum seems to have struck yet again -- if there
is any way a comment can be misinterpreted, someone surely will :)

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendanmurphy37@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@> wrote:
> > One client had the same problem (was using this pin for a different
> > purpose though), and they patched the boot loader to use a different 
> pin to enter Bootloader mode.
> 
> If you're producing product in any sort of volume this is a poor 
> strategy, in my opinion.

Nobody said anything about this being a production stragegy.  The
original poster was looking at recovery options.

> Apart from not guaranteeing the part, Philips 
> are under no obligation to keep the boot loader the same: they can 
> change it at any time (as long as the published interface and 
> production functionality remain the same).

The bootloader in the parts out in the field do not change on their own.

> If part of your production 
> process is to patch the device before you use it, what happens when 
> the patch location changes? Doesn't bear thinking about....

If you do not know what you are doing, you deserve what you get.  One
patches blindly only when one does not know what one is doing.

If one knows what one is doing, then this approach is a recovery
strategy.  I have seen a number of cases being reported here.

Jaya

Re: [lpc2000] DCD signal force LPC2xxx go into Bootloader during reset

2006-04-27 by Branko Karaklajic

Hello misstero,

Wednesday, April 26, 2006, 8:42:10 PM, you wrote:

m> Dear All,

m> I have design which is connected modem signals to UART1 (Full UART) of
m> LPC2xxxx but I found serious problem with DCD signal.

m> DCD signal of UART1 is alternate function on P0.14 which is LPC2xxx
m> bootloader determine during reset to go into Bootloader mode if it low.

m> Our problem occur when modem connected that DCD is active (Active Low
m> same as bootloader mode request) and LPC2xxx is reseted which may
m> cause by unstable power or external reset via RESET pin by
m> supervisory. This made LPC2xxx  go into bootloader mode forever cannot
m> return back to our application code even modem's DCD inactive later.
m> Only power cycle both LPC2xxx and modem to restart it to application
m> code. This case unaccetable when devices are installed in unman location.

m> I have an idea to solve this problem but it need help from Philips by
m> add time-out in Bootloader mode if it does not have any activity for
m> short period of time (etc. 3s) it should be retry to execute
m> application code repeatly so I'd like to ask Philips is it possible?

m> Anyone have other ideas to solve this problem? Please share with me. I
m> prefer to solve by software first if it possible.

m> Thanks,
m> Suriyan.

In similar situation, I use one pin for powering up modem over MOSFET
which is always off after any kind of reset. MOSFET is controlled by
pin, and after reset pin is input, and MOSFET is off. after some
init, I turn ON modem and it works fine!

-- 
Best regards,
 Branko

Re: DCD signal force LPC2xxx go into Bootloader during reset

2006-04-27 by brendanmurphy37

I don't believe I did misinterpret what the original poster said: 
they expressed a concern that units in the field could potentially be 
left in a state that is unrecoverable without manual intervention. 

Whether you know what you're doing or not is immaterial when doing 
something like patching a boot loader: it's relying on undocumented 
and unsupported features. I'm happy to stand over my contention that 
this is a poor strategy for anyone putting product into the field, 
regardless of whether it works.

You are of course entitled to disagree with this, and to advise 
others as you see fit.

Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> Murphy's law of this forum seems to have struck yet again -- if 
there
> is any way a comment can be misinterpreted, someone surely will :)
> 
> --- In lpc2000@yahoogroups.com, "brendanmurphy37"
> <brendanmurphy37@> wrote:
> >
> > --- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@> 
wrote:
> > > One client had the same problem (was using this pin for a 
different
> > > purpose though), and they patched the boot loader to use a 
different 
> > pin to enter Bootloader mode.
> > 
> > If you're producing product in any sort of volume this is a poor 
> > strategy, in my opinion.
> 
> Nobody said anything about this being a production stragegy.  The
> original poster was looking at recovery options.
> 
> > Apart from not guaranteeing the part, Philips 
> > are under no obligation to keep the boot loader the same: they 
can 
> > change it at any time (as long as the published interface and 
> > production functionality remain the same).
> 
> The bootloader in the parts out in the field do not change on their 
own.
> 
> > If part of your production 
> > process is to patch the device before you use it, what happens 
when 
> > the patch location changes? Doesn't bear thinking about....
> 
> If you do not know what you are doing, you deserve what you get.  
One
Show quoted textHide quoted text
> patches blindly only when one does not know what one is doing.
> 
> If one knows what one is doing, then this approach is a recovery
> strategy.  I have seen a number of cases being reported here.
> 
> Jaya
>

Re: DCD signal force LPC2xxx go into Bootloader during reset

2006-04-27 by John Heenan

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
Show quoted textHide quoted text
> prefer to solve by software first if it possible.
> 
> Thanks,
> Suriyan.
>

Re: DCD signal force LPC2xxx go into Bootloader during reset

2006-04-27 by brendanmurphy37

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?
Show quoted textHide quoted text
> > 
> > Anyone have other ideas to solve this problem? Please share with 
> me. I
> > prefer to solve by software first if it possible.
> > 
> > Thanks,
> > Suriyan.
> >
>

Re: [lpc2000] Re: DCD signal force LPC2xxx go into Bootloader during reset

2006-04-27 by Mark Norton

Use a transceiver chip with an enable pin.  The enable
is controlled by the micro so on reset the transceiver
is disabled and thus the micro will not go into
bootloader mode.

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


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Re: DCD signal force LPC2xxx go into Bootloader during reset

2006-04-27 by John Heenan

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 
Show quoted textHide quoted text
> > me. I
> > > prefer to solve by software first if it possible.
> > > 
> > > Thanks,
> > > Suriyan.
> > >
> >
>

Re: DCD signal force LPC2xxx go into Bootloader during reset

2006-04-27 by brendanmurphy37

John,

I'm sure what you describe, or something close to it can be made to 
work OK. I guess we just took the easy way out and said: let's not 
use the pin for anything other than selecting the bootloader.

It just goes to show though how careful you have to be with multi-
purpose pins, especially one that can force you into a completely 
different mode that (your application) software can't get you out of.

Best to know of these things before you have tens or hundreds of 
thousands (or millions?) of units in the field.....

Like the original poster, I'd be curious to know if there's a 
software way out of this (without modifying the bootloader). If you 
restrict RESETs to just power-on resets and internal watchdog ones, 
you're probably fine (but can you guarentee 100% the modem you're 
connected to won't pull DCD low during power-on?). If there are 
other sources of (external) RESET, my guess is only something like 
your (hardware) suggestion would be guarenteed to work.

Brendan

--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:
>
> 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 
Show quoted textHide quoted text
> > > 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.
> > > >
> > >
> >
>

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.