Reply by Guillermo Prandi●February 28, 20062006-02-28
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@lpc2..., 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
>
--- In lpc2000@lpc2..., "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
Reply by Guillermo Prandi●February 25, 20062006-02-25
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@lpc2..., 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
>
Reply by Jayasooriah●February 25, 20062006-02-25
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
Reply by Guillermo Prandi●February 25, 20062006-02-25
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@lpc2..., 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
>
Reply by Jayasooriah●February 24, 20062006-02-24
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@yaho...>
>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@phil...>
>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
Reply by Guillermo Prandi●February 23, 20062006-02-23
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@lpc2..., "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@lpc2..., "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@lpc2..., "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@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.
> > > >
> > > > 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
> > > >
> > >
> >
>
Reply by philips_apps●February 23, 20062006-02-23
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@lpc2..., "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@lpc2..., "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@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.
> > >
> > > 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
> > >
> >
>
Reply by Guillermo Prandi●February 23, 20062006-02-23
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@lpc2..., 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@lpc2..., "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@lpc2..., "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
>
Reply by Jayasooriah●February 23, 20062006-02-23
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@lpc2..., "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@lpc2..., "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