Lpc2000

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 750µS.
3) At T+750µS 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

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@yahoogroups.com, 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
>

Hi Guile, I should have said "power on reset".

I removed the problem (was not keen on solving it at that time) by avoiding 
use of GPIO pins that the boot loader has allocated for purposes of 
"external boot" feature (something that is not necessary and hence of 
dubious value in the context of embedded systems).

I believe there are some registers that the boot loader fiddles with which 
exhibit "stuck zero" behaviour -- when one writes a zero, these bits stays 
zero until power on reset event.

In the 2292 that I am now working on for POE application, I found that if 
you do not re-map interrupt vectors to your own memory space, UND, PRE, and 
ABT type exceptions can also cause the system to lock up in similar 
ways.  Power on reset got me out each time this happened.

Jaya

>    Date: Tue, 07 Feb 2006 13:07:11 -0000
>    From: "Guillermo Prandi" <yahoo.messenger@...>
>Subject: Re: Bootloader not always invoked after reset with P0.14 low
>
>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

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

Ooof... seems like a stinky sticking problem. I'll better attack it 
only if it becomes a real PITA. For the moment, instructing the 
programming operator to do a power-on reset by hand is perfectly 
acceptable.

Thanks a lot.

Guille

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Hi Guile, I should have said "power on reset".
> 
> I removed the problem (was not keen on solving it at that time) by 
avoiding 
> use of GPIO pins that the boot loader has allocated for purposes of 
> "external boot" feature (something that is not necessary and hence 
of 
> dubious value in the context of embedded systems).
> 
> I believe there are some registers that the boot loader fiddles 
with which 
> exhibit "stuck zero" behaviour -- when one writes a zero, these 
bits stays 
> zero until power on reset event.
> 
> In the 2292 that I am now working on for POE application, I found 
that if 
> you do not re-map interrupt vectors to your own memory space, UND, 
PRE, and 
> ABT type exceptions can also cause the system to lock up in similar 
> ways.  Power on reset got me out each time this happened.
> 
> Jaya
> 
> >    Date: Tue, 07 Feb 2006 13:07:11 -0000
> >    From: "Guillermo Prandi" <yahoo.messenger@>
> >Subject: Re: Bootloader not always invoked after reset with P0.14 
low
> >
> >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
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>

Hello Guille,

In case of a watchdog triggered reset, P0.14 pin is ignored by the
bootloader and the valid user application is executed. If valid user
application is not found then only isp is entered. In LPC2138 the WDT
flag is not cleared by pin reset. POR reset clears the WDT flag. What
you are observing is expected behavior. I am assuming that WD reset
happened since you have mention it.

Regards
Philips Apps

--- In lpc2000@yahoogroups.com, "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.
> 
> 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 750µS.
> 3) At T+750µS 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
>

My code is clearing the RISR flags at boot time by doing:

#define RSIR (*((volatile unsigned char *) 0xE01FC180))

RSIR = 0x0f;

After that, the boards still ignores P0.14 after a watchdog reset. 
Since I cleared the watchdog reset flag, I expected the bootloader to 
invoke ISP. Is there anything else I could do from software in order 
to make the bootloader honor the P0.14 pin?

Guille

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@...> 
wrote:
>
> Hello Guille,
> 
> In case of a watchdog triggered reset, P0.14 pin is ignored by the
> bootloader and the valid user application is executed. If valid user
> application is not found then only isp is entered. In LPC2138 the 
WDT
> flag is not cleared by pin reset. POR reset clears the WDT flag. 
What
> you are observing is expected behavior. I am assuming that WD reset
> happened since you have mention it.
> 
> Regards
> Philips Apps
> 
> --- In lpc2000@yahoogroups.com, "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.
> > 
> > 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 750µS.
> > 3) At T+750µS 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 Guile,

If you look at the user manual for WTOF bit which the boot loader checks, 
it is quite clear that "external reset" will clear this bit.

Can you try without arming the watchdog to see if the problem goes away?

Jaya

--- In lpc2000@yahoogroups.com, "Guillermo Prandi" <yahoo.messenger@...> wrote:
 >
 > My code is clearing the RISR flags at boot time by doing:
 >
 > #define RSIR (*((volatile unsigned char *) 0xE01FC180))
 >
 > RSIR = 0x0f;
 >
 > After that, the boards still ignores P0.14 after a watchdog reset.
 > Since I cleared the watchdog reset flag, I expected the bootloader to
 > invoke ISP. Is there anything else I could do from software in order
 > to make the bootloader honor the P0.14 pin?
 >
 > Guille
 >
 > --- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@>
 > wrote:
 > >
 > > Hello Guille,
 > >
 > > In case of a watchdog triggered reset, P0.14 pin is ignored by the
 > > bootloader and the valid user application is executed. If valid user
 > > application is not found then only isp is entered. In LPC2138 the
 > WDT
 > > flag is not cleared by pin reset. POR reset clears the WDT flag.
 > What
 > > you are observing is expected behavior. I am assuming that WD reset
 > > happened since you have mention it.
 > >
 > > Regards
 > > Philips Apps

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

Hi, Jayasooriah. Indeed the watchdog is the problem. At this stage of 
development I am only using the watchdog to provide a software reset 
function. Apparently this behavior is triggering only after using 
this function. And yes, you are right; the bit should be cleared by 
the external reset.

It looks like this behavior is 'by design' so there is no other 
workaround than switching off the unit.

Guille

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Hi Guile,
> 
> If you look at the user manual for WTOF bit which the boot loader 
checks, 
> it is quite clear that "external reset" will clear this bit.
> 
> Can you try without arming the watchdog to see if the problem goes 
away?
> 
> Jaya
> 
> --- In lpc2000@yahoogroups.com, "Guillermo Prandi" 
<yahoo.messenger@> wrote:
>  >
>  > My code is clearing the RISR flags at boot time by doing:
>  >
>  > #define RSIR (*((volatile unsigned char *) 0xE01FC180))
>  >
>  > RSIR = 0x0f;
>  >
>  > After that, the boards still ignores P0.14 after a watchdog 
reset.
>  > Since I cleared the watchdog reset flag, I expected the 
bootloader to
>  > invoke ISP. Is there anything else I could do from software in 
order
>  > to make the bootloader honor the P0.14 pin?
>  >
>  > Guille
>  >
>  > --- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@>
>  > wrote:
>  > >
>  > > Hello Guille,
>  > >
>  > > In case of a watchdog triggered reset, P0.14 pin is ignored by 
the
>  > > bootloader and the valid user application is executed. If 
valid user
>  > > application is not found then only isp is entered. In LPC2138 
the
>  > WDT
>  > > flag is not cleared by pin reset. POR reset clears the WDT 
flag.
>  > What
>  > > you are observing is expected behavior. I am assuming that WD 
reset
>  > > happened since you have mention it.
>  > >
>  > > Regards
>  > > Philips Apps
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>

The bootloader does not look at the RISR register. It looks at the
WDTOF flag in WDMOD register.
Even clearing of watchdog flag in user application may not help (if
timeout is too small) because the bootloader runs before application.

If you are using the watchdog only to trigger ISP then Reinvoke ISP
command might be a better choice. This was added to 213x,214x devices. 
Restore Timer1 to reset state if your application uses it.
Refer to Table 218 on page 235 of the user manual
http://www.semiconductors.philips.com/acrobat_download/usermanuals/UM10120_1.pdf

The LPC213x/214x user manual will be updated to reflect the WTOF clear
conditions.

Regards
Philips Apps

--- In lpc2000@yahoogroups.com, "Guillermo Prandi"
<yahoo.messenger@...> wrote:

>
> My code is clearing the RISR flags at boot time by doing:
> 
> #define RSIR (*((volatile unsigned char *) 0xE01FC180))
> 
> RSIR = 0x0f;
> 
> After that, the boards still ignores P0.14 after a watchdog reset. 
> Since I cleared the watchdog reset flag, I expected the bootloader to 
> invoke ISP. Is there anything else I could do from software in order 
> to make the bootloader honor the P0.14 pin?
> 
> Guille
> 
> --- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@> 
> wrote:
> >
> > Hello Guille,
> > 
> > In case of a watchdog triggered reset, P0.14 pin is ignored by the
> > bootloader and the valid user application is executed. If valid user
> > application is not found then only isp is entered. In LPC2138 the 
> WDT
> > flag is not cleared by pin reset. POR reset clears the WDT flag. 
> What
> > you are observing is expected behavior. I am assuming that WD reset
> > happened since you have mention it.
> > 
> > Regards
> > Philips Apps
> > 
> > --- In lpc2000@yahoogroups.com, "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.
> > > 
> > > 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 750�S.
> > > 3) At T+750�S 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
> > >
> >
>

Oh, thanks Richard!

After your words, the following sequence in my startup code seems to 
do the trick:

WDMOD = 0; // I don't know if this is actually required
WDFEED = 0xaa;
WDFEED = 0x55;

Guille

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@...> 
wrote:
>
> The bootloader does not look at the RISR register. It looks at the
> WDTOF flag in WDMOD register.
> Even clearing of watchdog flag in user application may not help (if
> timeout is too small) because the bootloader runs before 
application.
> 
> If you are using the watchdog only to trigger ISP then Reinvoke ISP
> command might be a better choice. This was added to 213x,214x 
devices. 
> Restore Timer1 to reset state if your application uses it.
> Refer to Table 218 on page 235 of the user manual
> 
http://www.semiconductors.philips.com/acrobat_download/usermanuals/UM1
0120_1.pdf
> 
> The LPC213x/214x user manual will be updated to reflect the WTOF 
clear
> conditions.
> 
> Regards
> Philips Apps
> 
> --- In lpc2000@yahoogroups.com, "Guillermo Prandi"
> <yahoo.messenger@> wrote:
> >
> > My code is clearing the RISR flags at boot time by doing:
> > 
> > #define RSIR (*((volatile unsigned char *) 0xE01FC180))
> > 
> > RSIR = 0x0f;
> > 
> > After that, the boards still ignores P0.14 after a watchdog 
reset. 
> > Since I cleared the watchdog reset flag, I expected the 
bootloader to 
> > invoke ISP. Is there anything else I could do from software in 
order 
> > to make the bootloader honor the P0.14 pin?
> > 
> > Guille
> > 
> > --- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@> 
> > wrote:
> > >
> > > Hello Guille,
> > > 
> > > In case of a watchdog triggered reset, P0.14 pin is ignored by 
the
> > > bootloader and the valid user application is executed. If valid 
user
> > > application is not found then only isp is entered. In LPC2138 
the 
> > WDT
> > > flag is not cleared by pin reset. POR reset clears the WDT 
flag. 
> > What
> > > you are observing is expected behavior. I am assuming that WD 
reset
> > > happened since you have mention it.
> > > 
> > > Regards
> > > Philips Apps
> > > 
> > > --- In lpc2000@yahoogroups.com, "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.
> > > > 
> > > > 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 750�S.
> > > > 3) At T+750�S 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 Guile,

I am looking at what appears to be a different manifestation of the problem 
you encountered in that power cycling is required to recover form a lockup 
in order to transfer control to ISP by pulling P0.14 low.

Philips explains this happens can if "timeout value is too small".  The 
user manual seems to say writing anything less than 0xff will result in 
minimum timeout of PCLK x 256 x 4.

The test code below then should create the lockup scenario, but it does not 
on my 2292.  I cannot see where I got it wrong.

Can you try this on your board please?

Thanks.

Jaya

GNU Source:

>@ ======================================================================
>@ Interrupt Vectors
>
>         .code   32
>
>         @ entry points vector
>start:
>         ldr     pc, =error
>         ldr     pc, =error
>         ldr     pc, =error
>         ldr     pc, =error
>         ldr     pc, =error
>         ldr     pc, =error
>         ldr     pc, =error
>         ldr     pc, =error
>
>         .ltorg
>
>@ End of Interrupt Vectors
>@ ======================================================================
>
>
>@ ======================================================================
>@ Error Scenario
>
>         .code   32
>
>error:
>         @ force reset
>         ldr     r0, =WATCH_DOG
>         mov     r1, #3
>         str     r1, [r0, #0]
>         str     r1, [r0, #4]    @ WDTC = 3
>         mov     r1, #0xaa
>         str     r1, [r0, #8]    @ WDFEED = 0xaa
>         mov     r1, #0x55
>         str     r1, [r0, #8]    @ WDFEED = 0x55
>         b       .
>
>@ End Error Scenario
>@ ======================================================================

HEX Binary: (vectors not check-sum patched)

>:1000000018F09FE514F09FE510F09FE50CF09FE5D8
>:1000100008F09FE504F09FE500F09FE504F01FE580
>:10002000240000000E02A0E30310A0E3001080E50E
>:10003000041080E5AA10A0E3081080E55510A0E3A5
>:08004000081080E5FEFFFFEA55
>:00000001FF


>Message: 17
>    Date: Thu, 23 Feb 2006 12:30:37 -0000
>    From: "Guillermo Prandi" <yahoo.messenger@...>
>Subject: Re: Bootloader not always invoked after reset with P0.14 low
>
>Hi, Jayasooriah. Indeed the watchdog is the problem. At this stage of
>development I am only using the watchdog to provide a software reset
>function. Apparently this behavior is triggering only after using
>this function. And yes, you are right; the bit should be cleared by
>the external reset.
>
>It looks like this behavior is 'by design' so there is no other
>workaround than switching off the unit.
>
>Guille


>Message: 8
>    Date: Thu, 23 Feb 2006 23:28:38 -0000
>    From: "philips_apps" <philips_apps@...>
>Subject: Re: Bootloader not always invoked after reset with P0.14 low
>
>The bootloader does not look at the RISR register. It looks at the
>WDTOF flag in WDMOD register.
>Even clearing of watchdog flag in user application may not help (if
>timeout is too small) because the bootloader runs before application.



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

I don't understand very well what is it that you want me to test. By 
clearing the watchdog flags my problem went away.

Guille

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Hi Guile,
> 
> I am looking at what appears to be a different manifestation of the 
problem 
> you encountered in that power cycling is required to recover form a 
lockup 
> in order to transfer control to ISP by pulling P0.14 low.
> 
> Philips explains this happens can if "timeout value is too small".  
The 
> user manual seems to say writing anything less than 0xff will 
result in 
> minimum timeout of PCLK x 256 x 4.
> 
> The test code below then should create the lockup scenario, but it 
does not 
> on my 2292.  I cannot see where I got it wrong.
> 
> Can you try this on your board please?
> 
> Thanks.
> 
> Jaya
> 
> GNU Source:
> 
> >@ 
======================================================================
> >@ Interrupt Vectors
> >
> >         .code   32
> >
> >         @ entry points vector
> >start:
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >
> >         .ltorg
> >
> >@ End of Interrupt Vectors
> >@ 
======================================================================
> >
> >
> >@ 
======================================================================
> >@ Error Scenario
> >
> >         .code   32
> >
> >error:
> >         @ force reset
> >         ldr     r0, =WATCH_DOG
> >         mov     r1, #3
> >         str     r1, [r0, #0]
> >         str     r1, [r0, #4]    @ WDTC = 3
> >         mov     r1, #0xaa
> >         str     r1, [r0, #8]    @ WDFEED = 0xaa
> >         mov     r1, #0x55
> >         str     r1, [r0, #8]    @ WDFEED = 0x55
> >         b       .
> >
> >@ End Error Scenario
> >@ 
======================================================================
> 
> HEX Binary: (vectors not check-sum patched)
> 
> >:1000000018F09FE514F09FE510F09FE50CF09FE5D8
> >:1000100008F09FE504F09FE500F09FE504F01FE580
> >:10002000240000000E02A0E30310A0E3001080E50E
> >:10003000041080E5AA10A0E3081080E55510A0E3A5
> >:08004000081080E5FEFFFFEA55
> >:00000001FF
> 
> 
> >Message: 17
> >    Date: Thu, 23 Feb 2006 12:30:37 -0000
> >    From: "Guillermo Prandi" <yahoo.messenger@...>
> >Subject: Re: Bootloader not always invoked after reset with P0.14 
low
> >
> >Hi, Jayasooriah. Indeed the watchdog is the problem. At this stage 
of
> >development I am only using the watchdog to provide a software 
reset
> >function. Apparently this behavior is triggering only after using
> >this function. And yes, you are right; the bit should be cleared by
> >the external reset.
> >
> >It looks like this behavior is 'by design' so there is no other
> >workaround than switching off the unit.
> >
> >Guille
> 
> 
> >Message: 8
> >    Date: Thu, 23 Feb 2006 23:28:38 -0000
> >    From: "philips_apps" <philips_apps@...>
> >Subject: Re: Bootloader not always invoked after reset with P0.14 
low
> >
> >The bootloader does not look at the RISR register. It looks at the
> >WDTOF flag in WDMOD register.
> >Even clearing of watchdog flag in user application may not help (if
> >timeout is too small) because the bootloader runs before 
application.
> 
> 
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>

Hi Guile,

I may be misunderstanding the problem.

You made the comment:

>It looks like this behavior is 'by design' so there is no other workaround 
>than switching off the unit.

Philips followed up:

>Even clearing of watchdog flag in user application may not help (if 
>timeout is too small) because the bootloader runs before application.

For purposes of ruling out watchdog issues in problem I am looking into, I 
want to recreate the above watchdog problem.

My sample code sets up the watchdog to trigger in minimum time, and does 
nothing but wait for the watchdog to trigger.

In had no problems getting back to ISP with this code on my 2292.  I did 
not need to switch off.

I wanted to try this on your board.  If it works without need to switch 
off, then my understanding of the problem is incorrect.  If it does need 
you to switch off, then the problem may be specific to the part of version 
of boot loader.

I like to find out which of the above is the case.

Regards,

Jaya 

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

OK. I'll run your code. What is exactly what you want me to report 
about it? Whether it can call the bootloader without a power-on reset?

Guille

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Hi Guile,
> 
> I may be misunderstanding the problem.
> 
> You made the comment:
> 
> >It looks like this behavior is 'by design' so there is no other 
workaround 
> >than switching off the unit.
> 
> Philips followed up:
> 
> >Even clearing of watchdog flag in user application may not help 
(if 
> >timeout is too small) because the bootloader runs before 
application.
> 
> For purposes of ruling out watchdog issues in problem I am looking 
into, I 
> want to recreate the above watchdog problem.
> 
> My sample code sets up the watchdog to trigger in minimum time, and 
does 
> nothing but wait for the watchdog to trigger.
> 
> In had no problems getting back to ISP with this code on my 2292.  
I did 
> not need to switch off.
> 
> I wanted to try this on your board.  If it works without need to 
switch 
> off, then my understanding of the problem is incorrect.  If it does 
need 
> you to switch off, then the problem may be specific to the part of 
version 
> of boot loader.
> 
> I like to find out which of the above is the case.
> 
> Regards,
> 
> Jaya 
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>

--- In lpc2000@yahoogroups.com, "Guillermo Prandi"
<yahoo.messenger@...> wrote:
>
> OK. I'll run your code. What is exactly what you want me to report 
> about it? Whether it can call the bootloader without a power-on reset?
> 

Yes, that will do.  Thanks.

Jaya

Jaya: with your code, bootloader is not invoked if the reset/P0.14 
signals don't run along with a power on. This was the expected 
behavior, isn't it?

Guille

--- In lpc2000@yahoogroups.com, Jayasooriah <jayasooriah@...> wrote:
>
> Hi Guile,
> 
> I am looking at what appears to be a different manifestation of the 
problem 
> you encountered in that power cycling is required to recover form a 
lockup 
> in order to transfer control to ISP by pulling P0.14 low.
> 
> Philips explains this happens can if "timeout value is too small".  
The 
> user manual seems to say writing anything less than 0xff will 
result in 
> minimum timeout of PCLK x 256 x 4.
> 
> The test code below then should create the lockup scenario, but it 
does not 
> on my 2292.  I cannot see where I got it wrong.
> 
> Can you try this on your board please?
> 
> Thanks.
> 
> Jaya
> 
> GNU Source:
> 
> >@ 
======================================================================
> >@ Interrupt Vectors
> >
> >         .code   32
> >
> >         @ entry points vector
> >start:
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >         ldr     pc, =error
> >
> >         .ltorg
> >
> >@ End of Interrupt Vectors
> >@ 
======================================================================
> >
> >
> >@ 
======================================================================
> >@ Error Scenario
> >
> >         .code   32
> >
> >error:
> >         @ force reset
> >         ldr     r0, =WATCH_DOG
> >         mov     r1, #3
> >         str     r1, [r0, #0]
> >         str     r1, [r0, #4]    @ WDTC = 3
> >         mov     r1, #0xaa
> >         str     r1, [r0, #8]    @ WDFEED = 0xaa
> >         mov     r1, #0x55
> >         str     r1, [r0, #8]    @ WDFEED = 0x55
> >         b       .
> >
> >@ End Error Scenario
> >@ 
======================================================================
> 
> HEX Binary: (vectors not check-sum patched)
> 
> >:1000000018F09FE514F09FE510F09FE50CF09FE5D8
> >:1000100008F09FE504F09FE500F09FE504F01FE580
> >:10002000240000000E02A0E30310A0E3001080E50E
> >:10003000041080E5AA10A0E3081080E55510A0E3A5
> >:08004000081080E5FEFFFFEA55
> >:00000001FF
> 
> 
> >Message: 17
> >    Date: Thu, 23 Feb 2006 12:30:37 -0000
> >    From: "Guillermo Prandi" <yahoo.messenger@...>
> >Subject: Re: Bootloader not always invoked after reset with P0.14 
low
> >
> >Hi, Jayasooriah. Indeed the watchdog is the problem. At this stage 
of
> >development I am only using the watchdog to provide a software 
reset
> >function. Apparently this behavior is triggering only after using
> >this function. And yes, you are right; the bit should be cleared by
> >the external reset.
> >
> >It looks like this behavior is 'by design' so there is no other
> >workaround than switching off the unit.
> >
> >Guille
> 
> 
> >Message: 8
> >    Date: Thu, 23 Feb 2006 23:28:38 -0000
> >    From: "philips_apps" <philips_apps@...>
> >Subject: Re: Bootloader not always invoked after reset with P0.14 
low
> >
> >The bootloader does not look at the RISR register. It looks at the
> >WDTOF flag in WDMOD register.
> >Even clearing of watchdog flag in user application may not help (if
> >timeout is too small) because the bootloader runs before 
application.
> 
> 
> 
> Send instant messages to your online friends 
http://au.messenger.yahoo.com
>