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

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
	

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

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 

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.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
>
	

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.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 

(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.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@lpc2..., 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
>
	

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