Hi, I wonder if anyone has seen this before.

While developing the firmware for my LPC2138-featured board, I noticed 
that the bootloader is not always invoked after a reset with P0.14 low. 
Even when the bootloader is not invoked, the device still responds to 
reset.

I tested with the Philips bootloader utility, which, measured at the 
reset and P0.14 pins, gives me:

1) At T+0, P0.14 goes down from 3.3V to 0V sharply.
2) At T+0, Reset starts going down from 3.3V to 0V in an RC-type curve 
of 750S.
3) At T+750S both Reset and P0.14 are now 0V.
4) At T+500 mS reset starts going up, having been effectively low for 
499mS. The rising curve is also RC-type and takes about 2 mS to reach 
85%.
5) At T+840 mS, P0.14 goes up sharply. This is 338 mS *after* reset 
went high.

By the spec, these figures should be large enough to trigger the 
bootloader, and it does, except when I've been playing around with my 
firmware for a while (several cycles of compile+flash programming, 
tests, an occasional crash, watchdog triggered, etc.). When the 
bootloader stops responding, the only way to regain the bootloader is 
by removing power.
Any ideas?

Guille
	

Hi Guille,

I have seen this problem before on 2292 and the culprit appears to be what 
the boot loader does on watchdog resets when there is on-chip flash with 
external memory boot capability.

The "USAGE NOTES ON WATCHDOG RESET AND EXTERNAL START" section of 2292

explains (in a longish way) the limitations (see below).

If you cannot guarantee that certain GPIO signals (not just those 
documented) are not in a particular state when configured as input at the 
time watch dog timer fires, you can lock yourself up in ways and require 
hard reset.

It does not matter if you are not using the external boot feature, or for 
that matter, use the external memory interface.

It is a pity, this appears not to be a processor limitation, but a boot 
loader limitation or bug.  I have not had time to look at the boot loader 
source as yet.

Jaya

>USAGE NOTES ON WATCHDOG RESET AND EXTERNAL START
>
>When LPC2292/2294 is conditioned by components attached to the BOOT1:0 
>pins to start execution in off-chip memory, and is programmed to enable 
>the Watchdog Timer to reset the part if it is not periodically serviced, 
>care must be taken to avoid problems due to the interaction of these
features.
>
>First, the BOOT1 and/or BOOT0 pin(s) must be biased to ground using 
>pulldown resistors, not transistors driven from RESET low, because RESET 
>is not driven low during a Watchdog Reset.
>
>Second, if either or both of the BOOT1:0 pins are used as inputs in the 
>application, the application designer must ensure that the external driver 
>will not be enabled during an internal Reset generated by the Watchdog
Timer.
>
>(One way to do this is to use one of the CS3:0 outputs to enable the
driver.)
>
>If these two conditions cannot be met, an external Watchdog facility can 
>be used.
	>    Date: Mon, 06 Feb 2006 12:53:07 -0000
>    From: "Guillermo Prandi"
<yahoo.messenger@...>
>Subject: Bootloader not always invoked after reset with P0.14 low
>
>...
>
>5) At T+840 mS, P0.14 goes up sharply. This is 338 mS *after* reset
>went high.
>
>By the spec, these figures should be large enough to trigger the
>bootloader, and it does, except when I've been playing around with my
>firmware for a while (several cycles of compile+flash programming,
>tests, an occasional crash, watchdog triggered, etc.). When the
>bootloader stops responding, the only way to regain the bootloader is
>by removing power.
>Any ideas?
>
>Guille

Send instant messages to your online friends http://au.messenger.yahoo.com 

At 11:57 PM 2/6/06 +0000, you wrote:
>--- In lpc2000@lpc2..., "Guillermo
Prandi"
><yahoo.messenger@...> wrote:
>
>Hi, I wonder if anyone has seen this before.
>
>While developing the firmware for my LPC2138-featured board, I noticed
>that the bootloader is not always invoked after a reset with P0.14 low.
>Even when the bootloader is not invoked, the device still responds to
>reset.

Any chance you've triggered a watchdog or some such?

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
http://www.aeolusdevelopment.com/
	

> Any chance you've triggered a watchdog or some such?

Well, yes... the program might have triggered the watchdog but... why 
should it matter after the reset pin being low for half a second?

Guille

--- In lpc2000@lpc2..., Robert Adsett <subscriptions@...> 
wrote:
>
> At 11:57 PM 2/6/06 +0000, you wrote:
> >--- In lpc2000@lpc2..., "Guillermo Prandi"
> ><yahoo.messenger@> wrote:
> >
> >Hi, I wonder if anyone has seen this before.
> >
> >While developing the firmware for my LPC2138-featured board, I 
noticed
> >that the bootloader is not always invoked
after a reset with P0.14 
low.
> >Even when the bootloader is not invoked, the
device still responds 
to
> >reset.
> 
> Any chance you've triggered a watchdog or some such?
> 
> 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
> http://www.aeolusdevelopment.com/
>
	

Hi, Jayasooriah. What do you mean by "hard reset"? If you mean
having 
the reset pin low, then I *am* performing a hard reset. The problem 
shows up when I attempt to access ISP via serial port (DTR goes to 
RESET, RTS goes to P0.14).

Guille

--- In lpc2000@lpc2..., Jayasooriah <jayasooriah@...> wrote:
>
> Hi Guille,
> 
> I have seen this problem before on 2292 and the culprit appears to 
be what 
> the boot loader does on watchdog resets when there
is on-chip flash 
with 
> external memory boot capability.
> 
> The "USAGE NOTES ON WATCHDOG RESET AND EXTERNAL START" section of

2292 
> explains (in a longish way) the limitations (see
below).
> 
> If you cannot guarantee that certain GPIO signals (not just those 
> documented) are not in a particular state when configured as input 
at the 
> time watch dog timer fires, you can lock yourself
up in ways and 
require 
> hard reset.
> 
> It does not matter if you are not using the external boot feature, 
or for 
> that matter, use the external memory interface.
> 
> It is a pity, this appears not to be a processor limitation, but a 
boot 
> loader limitation or bug.  I have not had time to
look at the boot 
loader 
> source as yet.
> 
> Jaya
> 
> >USAGE NOTES ON WATCHDOG RESET AND EXTERNAL START
> >
> >When LPC2292/2294 is conditioned by components attached to the 
BOOT1:0 
> >pins to start execution in off-chip memory,
and is programmed to 
enable 
> >the Watchdog Timer to reset the part if it is
not periodically 
serviced, 
> >care must be taken to avoid problems due to
the interaction of 
these features.
> >
> >First, the BOOT1 and/or BOOT0 pin(s) must be biased to ground 
using 
> >pulldown resistors, not transistors driven
from RESET low, because 
RESET 
> >is not driven low during a Watchdog Reset.
> >
> >Second, if either or both of the BOOT1:0 pins are used as inputs 
in the 
> >application, the application designer must
ensure that the 
external driver 
> >will not be enabled during an internal Reset
generated by the 
Watchdog Timer.
> >
> >(One way to do this is to use one of the CS3:0 outputs to enable 
the driver.)
> >
> >If these two conditions cannot be met, an external Watchdog 
facility can 
> >be used.
> 
> 
> >    Date: Mon, 06 Feb 2006 12:53:07 -0000
> >    From: "Guillermo Prandi" <yahoo.messenger@>
> >Subject: Bootloader not always invoked after reset with P0.14 low
> >
> >...
> >
> >5) At T+840 mS, P0.14 goes up sharply. This is 338 mS *after* reset
> >went high.
> >
> >By the spec, these figures should be large enough to trigger the
> >bootloader, and it does, except when I've been playing around with

my
> >firmware for a while (several cycles of
compile+flash programming,
> >tests, an occasional crash, watchdog triggered, etc.). When the
> >bootloader stops responding, the only way to regain the bootloader 
is
> >by removing power.
> >Any ideas?
> >
> >Guille
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>
	

At 10:23 AM 2/7/06 +0000, Guillermo Prandi wrote:
> > Any chance you've triggered a watchdog
or some such?
>
>Well, yes... the program might have triggered the watchdog but... why
>should it matter after the reset pin being low for half a second?

Truthfully, I don't know.  I only raise the possibility because the User 
Manual indicates there is an internal flag set by the watchdog so that if 
it is the source of the interrupt the ISP pin is ignored.  If that flag is 
not cleared somehow then any subsequent reset could also ignore the 
pin.  Off hand I wouldn't expect the length of the reset pulse to make any 
difference on whether it entered ISP mode or not.

If you have an extra pin I'd set it on startup to indicate the startup 
source.  I seem to remember you can tell that on startup, I hope I'm not 
confusing the LPC with a different processor.

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
http://www.aeolusdevelopment.com/
	

Robert Adsett wrote:

>At 10:23 AM 2/7/06 +0000, Guillermo Prandi
wrote:
>  
>
>>>Any chance you've triggered a watchdog or some such?
>>>      
>>>
>>Well, yes... the program might have triggered the watchdog but... why
>>should it matter after the reset pin being low for half a second?
>>    
>>
>
>Truthfully, I don't know.  I only raise the possibility because the
User 
>Manual indicates there is an internal flag set by the watchdog so that if 
>it is the source of the interrupt the ISP pin is ignored.  If that flag is 
>not cleared somehow then any subsequent reset could also ignore the 
>pin.  Off hand I wouldn't expect the length of the reset pulse to make
any 
>difference on whether it entered ISP mode or not.
>
>  
>
I'd noticed something like that as well.  I played with the watchdog
a 
little and found that it didn't work as expected.  IIRC, I had to do a 
powerdown to get the system to run again.  I didn't look further than 
that, as I decided this watchdog thing was going to take some serious 
thought.  It doesn't work as a simple LTC590 monitor...

Probably over-engineered.

Tomw
	>If you have an extra pin I'd set it on startup to indicate the startup

>source.  I seem to remember you can tell that on
startup, I hope I'm not 
>confusing the LPC with a different processor.
>
>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
>http://www.aeolusdevelopment.com/
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>
	-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------
	

Yes, with LPC you can tell the source of the startup, but in this 
case the startup is hardware-originated, so I am pretty sure it is 
hardware. You suggest that the processor doesn't clear the proper 
bits for the bootloader to tell?

Guille

--- In lpc2000@lpc2..., Robert Adsett <subscriptions@...> 
wrote:
>
> At 10:23 AM 2/7/06 +0000, Guillermo Prandi wrote:
> > > Any chance you've triggered a watchdog or some such?
> >
> >Well, yes... the program might have triggered the watchdog but... 
why
> >should it matter after the reset pin being low
for half a second?
> 
> Truthfully, I don't know.  I only raise the possibility because the 
User 
> Manual indicates there is an internal flag set by
the watchdog so 
that if 
> it is the source of the interrupt the ISP pin is
ignored.  If that 
flag is 
> not cleared somehow then any subsequent reset
could also ignore the 
> pin.  Off hand I wouldn't expect the length of the reset pulse to 
make any 
> difference on whether it entered ISP mode or not.
> 
> If you have an extra pin I'd set it on startup to indicate the 
startup 
> source.  I seem to remember you can tell that on
startup, I hope 
I'm not 
> confusing the LPC with a different processor.
> 
> 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
> http://www.aeolusdevelopment.com/
>
	

--- In lpc2000@lpc2..., "Guillermo Prandi"
<yahoo.messenger@...> wrote:
>
> Yes, with LPC you can tell the source of the startup, but in this 
> case the startup is hardware-originated, so I am pretty sure it is 
> hardware. You suggest that the processor doesn't clear the proper 
> bits for the bootloader to tell?

I'm suggesting it needs to be verified one way or the other. 
Certainly the observed behaviour suggests that as a possibility.

There are, of course, many ways to implement this reset source
recognition but one way is to write a bit into a register for
occurances other than power on.  These bits are then never cleared and
so are always set the way they were last set.  A power on
automatically clears the register.  

ISTR a Motorola micro that behaved in that fashion, there was an
explicit line in the user manual saying that the reset source register
should be cleared in order to properly recognize the source of
subsequent resets.  Consider that an incentive to throughly read the
user manual, miss one line and spend days tracking down what seems to
be odd behaviour ;)

 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
 http://www.aeolusdevelopment.com/
	

Thanks, Richard. I'll try to dig deeper on it.

Guille

--- In lpc2000@lpc2..., "robertadsett" <subscriptions@...> 
wrote:
>
> --- In lpc2000@lpc2..., "Guillermo Prandi"
> <yahoo.messenger@> wrote:
> >
> > Yes, with LPC you can tell the source of the startup, but in this 
> > case the startup is hardware-originated, so I am pretty sure it 
is 
> > hardware. You suggest that the processor
doesn't clear the proper 
> > bits for the bootloader to tell?
> 
> I'm suggesting it needs to be verified one way or the other. 
> Certainly the observed behaviour suggests that as a possibility.
> 
> There are, of course, many ways to implement this reset source
> recognition but one way is to write a bit into a register for
> occurances other than power on.  These bits are then never cleared 
and
> so are always set the way they were last set.  A
power on
> automatically clears the register.  
> 
> ISTR a Motorola micro that behaved in that fashion, there was an
> explicit line in the user manual saying that the reset source 
register
> should be cleared in order to properly recognize
the source of
> subsequent resets.  Consider that an incentive to throughly read the
> user manual, miss one line and spend days tracking down what seems 
to
> be odd behaviour ;)
> 
>  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
>  http://www.aeolusdevelopment.com/
>